<div id="readability-page-1" class="page"><div><div><div><p><a href="https://harrisonjung.medium.com/?source=post_page-----4412f213827d-----------------------------------" rel="noopener follow"><img alt="Harrison Jung" src="https://miro.medium.com/fit/c/96/96/1*brdt-AwDa36Qn5mc1Ju2aQ@2x.jpeg" width="48" height="48"></a></p></div><p id="e910">최근 고객사에서 엄격한 수준의 보안 수준을 요구해서 자체적으로 시스템보안을 확인한 일이 있습니다.</p><p id="8157">기본적으로 저희 회사는 GKE ( k8s )를 사용하고 있고, 그것에 맞춰 모든것이 돌아가고 있기 때문에 보안에 대해서는 전혀 걱정하고 있지 않았었으나, 최근 Log4j 이슈도 있고 고객사의 점검 요청도 있기에 이번기회에 전반적으로 전부 검토하는 시간을 가졌었습니다.</p><p id="c948">이번 점검을 통해 VPC의 방화벽은 조금더 타이트하게 정리하였습니다.</p><p id="03cc">( 사실 조금더 강력하게 타이트하게 할 수는 있는데, 그건 단계적으로 적용하기로 했습니다. 현실과 이상의 괴리라는게 있으니까요 )</p></div><div><p id="dc05">기본적으로 GCP 프로젝트를 생성하면 생각보다 많은 보안 홀이 있습니다.</p><p id="75f6">당연한 이야기지만 RDP나 SSH 등등 많은 포트들이 0.0.0.0/0 으로 열려 있습니다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*6OfTeE6GyHQtM2h6N1VUbg.png" width="700" height="252" role="presentation"></p></div><figcaption>거의 다 오픈</figcaption></figure><p id="2040">위의 기본값을 보면 RDP , SSH , ICMP 는 외부에 완전히 열려 있고, 내부망은 모든 포트가 열려 있는것으로 되어 있습니다.</p><p id="39af">물론 RDP를 사용할만한 윈도우 서버 자체는 당연히 안쓰고, SSH 도 기본적으로 구글의 시스템이 보호를 해주니 크게 이슈는 없습니다.</p><p id="cfa1">그런데 여기에 GKE 가 들어가면 방화벽이 저절로 복잡해 지기 시작합니다.</p><p id="726d">기본적으로 GKE 클러스터를 생성하는 순간 자동으로 등록되는 룰이 생기고, 그 룰들이 생기면서 위에 있는 룰과 겹치거나 혼용되는 경우가 생깁니다.</p><p id="73e7">이번에 정리했던 내용들은 그 부분들을 정리했습니다.</p></div><div><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*nCdilQdgTa-BB3po4qxVXQ.png" width="700" height="404" role="presentation"></p></div></figure><p id="e58f"># gclb-allow-health-checks</p><p id="09e2">우선 GCLB ( 로드밸런서 )와 연결을 하기 위해서는 방화벽에서 GCLB의 IP를 허용 리스트에 추가해야 합니다.</p><p id="3438">해당 내용은 다음 링크에서 확인할 수 있습니다.</p><p id="41ab">여기서 주의할점은 gke-node 입니다.</p><p id="52cf">저희의 경우에는 여러 gke cluster 를 사용하기 때문에 공통적으로 편하게 네트워크를 묶을 수 있게 gke-node 라는 네트워크 태그명을 부여하였습니다.</p><p id="3772">따라서 gke cluster 를 생성할때 네트워크 태그에 gke-node 를 추가하면 방화벽 설정을 편리하게 할 수 있습니다.</p><p id="bb60">위의 목록을 보면 gke-node 를 사용하는 방화벽룰은 크게 2개 입니다.</p><p id="e44c"># gke-master</p><p id="bcc7">GKE 의 경우 기본적으로 Managed 서비스이기 때문에 master 를 우리가 관리하지 않습니다. 하지만, 접속할 IP는 필요하기 때문에 해당 대역을 cluster 를 생성할때 설정해주고 방화벽을 열어줘야 합니다.</p><p id="9748">당연히 대상은 gke-node 로 IP 범위는 cluster 에서 설정한 대역으로 동일하게 하면 됩니다.</p><p id="2502"># datastudio</p><p id="367b">저희 회사는 Data Studio 를 매우 잘 애용하고 있기 때문에 해당 포트도 열어야 합니다. Data Studio 에서 Cloud SQL을 통해서 데이터를 편하게 볼 수 있는 기능을 제공하기 때문입니다.</p><p id="5311">다음 링크를 참조하여 방화벽을 설정합니다.</p><p id="feed"># client-access , remote-access</p><p id="fa6d">마지막으로 고객사에서 접속이 가능한 전용 SQL 서버 방화벽과, 회사에서 접속할 IP를 설정합니다.</p><p id="a751">물론 범위는 최소한으로 포트도 최소한으로 설정해야 합니다.</p></div><div><p id="b01e">사실, 이정도의 방화벽은 매우 러프한 수준입니다.</p><p id="3467">좀 더 보안에 신경을 쓰려면 타이트하게 설정을 변경해야 할 부분이 많이 있습니다.</p><p id="c3c7">예를들면 위에서는 Ingress 만 신경썼는데 Egress 쪽을 설정을 추가할 수도 있습니다.</p><p id="8f2c">또한 내부 네트워크도 기본적으로 ALL 이 아닌 일부 제한을 거는 방법으로 보안을 올릴 수도 있습니다.</p><p id="04f2">하지만, 대개의 경우 일반적으로는 위와 같은 수준의 설정으로도 충분한 보안을 얻을 수 있습니다.</p><p id="39b1">( 저는 과도한 보안 또한 오버엔지니어링이라고 생각합니다. )</p><p id="4e06">다음 포스팅들에서는 실제로 설정을 변경하는 방법을 확인해 보겠습니다.</p></div></div></div>

Stories by Harrison Jung on Medium

VPC Network — Firewall
최근 고객사에서 엄격한 수준의 보안 수준을 요구해서 자체적으로 시스템보안을 확인한 일이 있습니다.
기본적으로 저희 회사는 GKE ( k8s )를 사용하고 있고, 그것에 맞춰 모든것이 돌아가고 있기 때문에 보안에 대해서는 전혀 걱정하고 있지 않았었으나, 최근 Log4j 이슈도 있고 고객사의 점검 요청도 있기에 이번기회에 전반적으로 전부 검토하는 시간을 가졌었습니다.
이번 점검을 통해 VPC의 방화벽은 조금더 타이트하게 정리하였습니다.
( 사실 조금더 강력하게 타이트하게 할 수는 있는데, 그건 단계적으로 적용하기로 했습니다. 현실과 이상의 괴리라는게 있으니까요 )
기본적으로 GCP 프로젝트를 생성하면 생각보다 많은 보안 홀이 있습니다.
당연한 이야기지만 RDP나 SSH 등등 많은 포트들이 0.0.0.0/0 으로 열려 있습니다.
위의 기본값을 보면 RDP , SSH , ICMP 는 외부에 완전히 열려 있고, 내부망은 모든 포트가 열려 있는것으로 되어 있습니다.
물론 RDP를 사용할만한 윈도우 서버 자체는 당연히 안쓰고, SSH 도 기본적으로 구글의 시스템이 보호를 해주니 크게 이슈는 없습니다.
그런데 여기에 GKE 가 들어가면 방화벽이 저절로 복잡해 지기 시작합니다.
기본적으로 GKE 클러스터를 생성하는 순간 자동으로 등록되는 룰이 생기고, 그 룰들이 생기면서 위에 있는 룰과 겹치거나 혼용되는 경우가 생깁니다.
이번에 정리했던 내용들은 그 부분들을 정리했습니다.
# gclb-allow-health-checks
우선 GCLB ( 로드밸런서 )와 연결을 하기 위해서는 방화벽에서 GCLB의 IP를 허용 리스트에 추가해야 합니다.
해당 내용은 다음 링크에서 확인할 수 있습니다.
Creating health checks | Load Balancing | Google Cloud
여기서 주의할점은 gke-node 입니다.
저희의 경우에는 여러 gke cluster 를 사용하기 때문에 공통적으로 편하게 네트워크를 묶을 수 있게 gke-node 라는 네트워크 태그명을 부여하였습니다.
따라서 gke cluster 를 생성할때 네트워크 태그에 gke-node 를 추가하면 방화벽 설정을 편리하게 할 수 있습니다.
위의 목록을 보면 gke-node 를 사용하는 방화벽룰은 크게 2개 입니다.
# gke-master
GKE 의 경우 기본적으로 Managed 서비스이기 때문에 master 를 우리가 관리하지 않습니다. 하지만, 접속할 IP는 필요하기 때문에 해당 대역을 cluster 를 생성할때 설정해주고 방화벽을 열어줘야 합니다.
당연히 대상은 gke-node 로 IP 범위는 cluster 에서 설정한 대역으로 동일하게 하면 됩니다.
# datastudio
저희 회사는 Data Studio 를 매우 잘 애용하고 있기 때문에 해당 포트도 열어야 합니다. Data Studio 에서 Cloud SQL을 통해서 데이터를 편하게 볼 수 있는 기능을 제공하기 때문입니다.
다음 링크를 참조하여 방화벽을 설정합니다.
MySQL에 연결하기
# client-access , remote-access
마지막으로 고객사에서 접속이 가능한 전용 SQL 서버 방화벽과, 회사에서 접속할 IP를 설정합니다.
물론 범위는 최소한으로 포트도 최소한으로 설정해야 합니다.
사실, 이정도의 방화벽은 매우 러프한 수준입니다.
좀 더 보안에 신경을 쓰려면 타이트하게 설정을 변경해야 할 부분이 많이 있습니다.
예를들면 위에서는 Ingress 만 신경썼는데 Egress 쪽을 설정을 추가할 수도 있습니다.
또한 내부 네트워크도 기본적으로 ALL 이 아닌 일부 제한을 거는 방법으로 보안을 올릴 수도 있습니다.
하지만, 대개의 경우 일반적으로는 위와 같은 수준의 설정으로도 충분한 보안을 얻을 수 있습니다.
( 저는 과도한 보안 또한 오버엔지니어링이라고 생각합니다. )
다음 포스팅들에서는 실제로 설정을 변경하는 방법을 확인해 보겠습니다.
꿈많은청년들
클라우드튜링 | 챗봇제작 챗봇빌더
VPC Network — Firewall was originally published in Dreamyoungs on Medium, where people are continuing the conversation by highlighting and responding to this story.

VPC Network — Firewall

댓글