안전한 인프라 구축의 첫걸음: 무작정 VM 띄우기 전 알아야 할 클라우드 보안 핵심 4가지

클라우드 환경의 가장 큰 장점 중 하나는 콘솔에서 클릭 몇 번, 혹은 명령어 한 줄만으로 손쉽게 서버(VM)를 띄울 수 있다는 점입니다. 특히 Google Cloud Platform(GCP)은 직관적인 환경을 제공하여 신입 개발자도 빠르게 인프라를 구성할 수 있습니다.

하지만 클라우드가 제공하는 '편리한 기본 설정'을 그대로 프로덕션(운영) 환경에 노출하는 것은 매우 위험한 접근입니다.

기본 네트워크 설정과 기본 서비스 계정이 부여된 채 방치된 서버는 전 세계 해커들의 자동화된 스캐닝 봇(Bot)에게 아주 좋은 먹잇감이 됩니다. 단순히 웹 서비스가 다운되는 것을 넘어, 여러분의 서버 자원이 암호화폐 채굴기로 악용되어 수백만 원의 클라우드 과금 폭탄을 맞거나, 서버와 연결된 데이터베이스 전체가 삭제되는 치명적인 보안 사고로 이어질 수 있습니다.

따라서 본격적으로 애플리케이션을 배포하기 전에, 인프라 레벨에서 불필요한 접근을 원천 차단하고 최소한의 권한만 부여하는 안전한 설계가 필수적입니다.

이번 포스팅에서는 반드시 이해해야 할 4가지 핵심 보안 원칙을 짚어봅니다. 이 원리들을 명확히 이해한다면, 단순히 명령어를 따라 치는 것을 넘어 스스로 안전하고 탄탄한 클라우드 아키텍처를 설계할 수 있는 시야를 갖추게 될 것입니다.

네트워크 격리: 공인 IP(External IP) 제거의 중요성

GCP에서 가상 머신(VM)을 처음 생성할 때, 기본 설정을 유지하면 서버에는 인터넷과 통신할 수 있는 '공인 IP(External IP)'가 자동으로 부여됩니다. 많은 신입 개발자분들이 여기서 첫 번째 보안 착각을 경험합니다.

"공인 IP가 있어도, 방화벽(Firewall)에서 80(HTTP), 443(HTTPS), 그리고 내 집 IP에서만 22번(SSH) 포트를 열어두면 안전한 거 아닌가요?"

이론상으로는 맞는 말입니다. 하지만 프로덕션 환경에서는 공인 IP가 존재한다는 사실 자체만으로도 지속적인 위협에 노출됩니다.

방화벽으로 문을 굳게 잠가두었다 하더라도, 공인 IP가 부여된 서버는 전 세계의 인터넷망에 그 '집 주소'가 공개된 것과 같습니다. 전 세계의 해커들과 자동화된 악성 봇(Bot)들은 24시간 내내 무작위로 IP를 스캐닝하며 열려있는 포트와 취약점을 탐색합니다.

이러한 무차별 대입 공격(Brute-force)과 스캐닝 트래픽은 서버의 네트워크 대역폭과 CPU 자원을 불필요하게 낭비시킵니다. 더욱 치명적인 것은, 방화벽 설정에 작은 실수(예: 테스트를 위해 잠시 0.0.0.0/0으로 개방)가 발생하거나 OS 자체의 제로데이 취약점이 발견되는 순간, 서버는 즉각적으로 해킹의 표적이 된다는 점입니다.

해결책: 투명 인간이 되는 법, --no-address

가장 완벽한 네트워크 보안은 공격을 잘 막아내는 것이 아니라, 아예 공격 표면(Attack Surface)을 없애버리는 것입니다.

이를 위해 운영 환경의 서버를 띄울 때는 외부 공인 IP를 아예 할당하지 않고 내부 IP(Internal IP, 예: 10.x.x.x)만 가지도록 설정해야 합니다. 다음 포스팅의 gcloud 명령어 실습에서는 VM 생성 시 --no-address 옵션을 추가하여 이를 구현할 예정입니다.

공인 IP가 없는 '프라이빗 VM(Private VM)'은 외부 인터넷 세계에서는 그 존재조차 알 수 없는 투명 인간이 됩니다. 외부에서 서버로 직접 향하는 모든 공격 경로가 원천적으로 차단되는 것입니다.

여기서 생기는 새로운 의문점 공인 IP를 없애면 해커의 공격은 완벽히 막을 수 있습니다. 하지만 당장 인프라를 구축해야 하는 우리(개발자)조차도 외부에서 이 서버에 SSH로 접속할 길이 없어집니다. 문을 없애버렸으니 당연한 결과입니다.

그렇다면 공인 IP 없이 안전하게 격리된 이 서버에, 관리자는 어떻게 접속해서 명령을 내릴 수 있을까요? 이 딜레마를 해결해 주는 구글 클라우드의 핵심 보안 기술이 바로 IAP(Identity-Aware Proxy)입니다.

주체의 분리와 최소 권한 원칙: 전용 서비스 계정(IAM) 도입

가상의 서버가 띄워지고 그 안에서 애플리케이션이 실행될 때, 이 서버는 누구의 권한으로 클라우드 인프라와 상호작용하게 될까요? 여기서 많은 신입 개발자들이 간과하는 두 번째 보안 취약점이 발생합니다.

GCP에서 별도의 설정 없이 VM을 생성하면, 구글은 친절하게도 'Compute Engine 기본 서비스 계정'을 인스턴스에 자동으로 부착해 줍니다.

문제점: 너무 강력한 만능키, '기본 서비스 계정' 기본 서비스 계정은 편의성을 위해 프로젝트 내의 거의 모든 리소스를 조회, 수정, 삭제할 수 있는 '편집자(Editor)' 권한을 기본으로 가지고 있습니다. 개발할 때는 권한 오류가 나지 않아 매우 편합니다.

하지만 프로덕션 환경에서는 이 편의성이 치명적인 독이 됩니다. 만약 배포된 웹 애플리케이션의 취약점(예: 원격 코드 실행(RCE) 취약점)을 통해 해커가 VM 내부로 침투했다고 가정해 보겠습니다. 해커는 침투한 순간, 이 VM에 부여된 기본 서비스 계정의 막강한 권한을 그대로 물려받게 됩니다. 단순히 웹 서버 하나가 털리는 수준에서 끝나는 것이 아니라, 해커가 그 권한을 이용해 연결된 Cloud SQL 데이터베이스를 통째로 삭제하거나, 악성 코인 채굴용 고성능 VM을 수십 대 생성해 버릴 수 있습니다.

해결책: 내 서비스에 딱 맞는 '전용 서비스 계정' 만들기 이러한 참사를 막기 위한 보안의 대원칙이 바로 '최소 권한의 원칙(Principle of Least Privilege)'입니다.

서버가 구동되는 데 굳이 클라우드 전체를 조작할 권한은 필요 없습니다. 다음 포스팅에서 우리는 기본 계정 대신, 다음과 같이 우리의 애플리케이션에 딱 필요한 권한만 가진 '전용 커스텀 서비스 계정'을 만들어 VM에 부착할 것입니다.

• artifactregistry.reader: 도커 이미지 저장소에서 이미지를 가져오기(Pull) 위한 권한
• secretmanager.secretAccessor: 환경 변수나 DB 비밀번호를 안전하게 읽어오기 위한 권한
• cloudsql.client: Cloud SQL(데이터베이스)에 안전하게 연결하기 위한 권한

이렇게 꼭 필요한 권한만 부여하면, 설령 서버가 해킹당하더라도 공격자가 할 수 있는 행동 반경이 극도로 제한됩니다. 서버 하나가 뚫려도 인프라 전체가 붕괴하는 사태를 방지하는 가장 훌륭한 방화벽은, 다름 아닌 꼼꼼하게 분리된 IAM(Identity and Access Management) 권한 설정입니다.

안전한 쉘(Shell) 접속: IAP(Identity-Aware Proxy)와 방화벽 설정

우리의 서버는 외부(인터넷)에서 아예 보이지 않는 투명 인간 상태가 되었고, 서버 자체의 권한도 엄격하게 축소되었습니다.

이제 당면한 가장 큰 문제는 "개발자인 나는 도대체 이 갇힌 서버에 어떻게 접속해서 배포 작업을 할 것인가?" 입니다. 공인 IP가 없으니 기존처럼 터미널에서 ssh 아이디@서버IP 방식을 사용할 수 없고, 외부 인터넷과 통하는 22번 포트(SSH)도 열려있지 않기 때문입니다.

이 딜레마를 해결해 주는 구글의 핵심 보안 기술이 바로 IAP(Identity-Aware Proxy) 입니다.

네트워크(IP) 대신 신분(Identity)을 믿어라 IAP는 구글의 '제로 트러스트(Zero Trust)' 철학이 반영된 서비스입니다. "어느 IP에서 접속하는가?"는 중요하지 않습니다. 대신 "지금 접속하려는 네가 정말로 권한이 있는 구글 계정 사용자가 맞는가?"를 철저하게 검증합니다.

작동 원리는 이렇습니다.

1. 개발자가 gcloud 명령어나 클라우드 콘솔을 통해 접속을 시도합니다.
2. IAP 프록시는 먼저 이 개발자의 구글 계정이 유효한지, 그리고 해당 서버에 접속할 수 있는 '터널 통행증(IAM 권한)'을 가지고 있는지 확인합니다.
3. 인증이 무사히 완료되면, 외부 인터넷이 아닌 구글의 내부 전용망을 통해 사용자와 서버 사이에 일종의 '비밀 지하 터널'을 뚫어줍니다.

IAP 접속을 완성하는 두 가지 필수 조건 이 마법 같은 IAP 터널링이 정상적으로 동작하려면, 두 가지 설정이 반드시 선행되어야 합니다.

• 첫째, 내부 방화벽 규칙 추가: 서버 입장에서는 결국 누군가(IAP 프록시) 터널을 뚫고 22번 포트로 들어오는 것을 허락해 주어야 합니다. 따라서 0.0.0.0/0(전체 인터넷)이 아닌, 오직 구글 IAP 프록시가 사용하는 특정 내부망 IP 대역(35.235.240.0/20)에서만 22번 포트로 들어올 수 있도록 허용하는 전용 방화벽 규칙을 만들어 서버(Network Tag)에 연결해야 합니다.
• 둘째, 개발자 개인 계정의 IAM 권한 부여: 앞서 2장에서 만든 '서비스 계정(Service Account)'은 서버가 밖으로 나갈 때 쓰는 권한이었습니다. 반대로, 지금 필요한 것은 나(개발자)라는 개인 계정이 IAP 터널을 이용할 수 있도록 내 구글 계정(예: dev@gmail.com)에 roles/iap.tunnelResourceAccessor(보안 터널 사용자) 권한을 부여하는 것입니다. 이 두 가지 주체의 권한을 혼동하지 않는 것이 중요합니다.

이렇게 IAP 설정을 마치면 외부 방화벽을 단 한 포트도 열지 않고, 오직 IAM 인증만으로 전 세계 어디서든 안전하게 내 서버에 접속할 수 있게 됩니다.

갇힌 서버에 아웃바운드 인터넷 제공하기: Cloud NAT

우리는 서버를 외부망에서 완전히 격리하고, IAP라는 안전한 비밀 통로로만 접속하도록 구성했습니다. 외부의 공격으로부터 완벽하게 보호되는 상태가 된 것입니다. 하지만 막상 접속해서 개발 작업을 하려고 하면 곧바로 벽에 부딪히게 됩니다.

"서버 업데이트를 위해 apt-get update를 실행했는데, 멈춰서 움직이지 않아요!" "외부 저장소에서 필요한 패키지나 도커(Docker) 이미지를 다운로드할 수가 없습니다."

문제점: 들어오는 것도 안 되지만, 나가는 것도 안 된다 공인 IP가 없다는 것은 외부에서 서버로 들어오는 트래픽(인바운드)만 막는 것이 아닙니다. 서버가 외부 인터넷으로 나가는 트래픽(아웃바운드) 역시 길을 잃게 됩니다. OS 패키지를 업데이트하거나, 외부 API와 통신해야 하는 서버 입장에서는 치명적인 문제입니다.

해결책: 내부망의 똑똑한 대리인, Cloud NAT 이 딜레마를 안전하게 해결하기 위해 네트워크에 Cloud NAT(Network Address Translation)라는 관리형 라우터를 추가합니다.

Cloud NAT는 공인 IP가 없는 내부망 서버들이 외부 인터넷과 통신할 수 있도록 돕는 일종의 '대리인' 역할을 합니다.

1. 내부 서버가 외부(예: Ubuntu 패키지 저장소)로 요청을 보냅니다.
2. Cloud NAT가 이 요청을 가로채어, 자신의 공인 IP로 주소를 변환하여 외부로 대신 전달합니다.
3. 외부에서 응답이 오면, Cloud NAT가 다시 내부 서버로 안전하게 전달해 줍니다.

여기서 핵심 보안 포인트는, 오직 서버가 먼저 요청한 통신(아웃바운드)에 대해서만 응답이 허용된다는 점입니다. 외부의 해커가 Cloud NAT의 IP를 향해 먼저 악의적인 패킷을 보내봤자 철저히 무시됩니다.

결과적으로 외부의 접근은 차단하면서도, 서버는 인터넷을 자유롭게 사용할 수 있는 완벽한 프라이빗 환경이 완성됩니다.

결론: 완벽하게 제어되는 인프라를 향하여

지금까지 클라우드에 무작정 서버를 띄우기 전에, 반드시 짚고 넘어가야 할 4가지 보안 기초 원리를 알아보았습니다.

1. 공인 IP 제거: 공격 표면 자체를 없애는 투명 인간 전략
2. 전용 서비스 계정(IAM): 서버가 해킹되어도 피해를 최소화하는 권한 제어
3. IAP 터널링: 방화벽 개방 없이 안전하게 쉘(Shell)에 접근하는 방법
4. Cloud NAT: 격리된 서버에 안전한 아웃바운드 인터넷 통신을 제공하는 방법

이 4가지 원칙이 톱니바퀴처럼 맞물려 적용된 서버는 무차별 공격으로부터 안전하며, 최소한의 권한만 가지고 동작하는 단단한 '보안 요새'가 됩니다. 처음에는 이 설정들이 번거롭게 느껴질 수 있지만, 실무에서는 선택이 아닌 필수입니다.

물론, 오늘 소개한 아키텍처가 클라우드 보안의 100% 완벽한 정답은 아닐 수 있습니다. 운영하는 시스템의 규모와 요구사항이 커짐에 따라 VPC Service Controls를 도입하거나, 컨테이너 오케스트레이션(Kubernetes) 레벨의 더 고도화된 네트워크 설계가 필요해질 수도 있습니다. 이 글의 방식보다 더 효율적이거나 상황에 맞는 좋은 대안이 있을 수도 있습니다.

하지만 이 4가지 핵심 원칙을 확실히 이해해 둔다면, 앞으로 어떤 복잡한 인프라 환경을 만나더라도 흔들리지 않는 튼튼한 뼈대가 되어줄 것입니다.