클라우드 컴퓨팅 환경 도입은 개발 속도를 높이고 인프라 관리 부담을 줄여주지만, 동시에 새로운 보안 과제를 안겨줍니다. 특히 AWS의 EC2, Lambda, 그리고 GCP의 Cloud Run과 같은 핵심 서비스들은 그 유연성만큼이나 보안 설정에 대한 깊은 이해를 요구합니다. 개발 지식이 필요한 기획자나 PM이라면 이 막연한 불안감 속에서 어떤 부분을 점검하고 의사결정해야 할지 고민이 많으실 것입니다.
이 글에서는 클라우드 서비스 보안에 대한 널리 퍼진 오해들을 하나씩 짚어보고, 실제 프로젝트에서 PM의 관점에서 놓치지 말아야 할 실전 점검 사항을 제시합니다. 각각의 장단점을 살펴보며 더욱 견고한 클라우드 환경을 구축하는 데 필요한 인사이트를 얻어가시길 바랍니다.
📑 목차
Image by fotoblend on Pixabay
클라우드 제공자가 알아서 다 해줄 거라는 오해
많은 분들이 클라우드를 도입하면 보안도 클라우드 제공자가 전적으로 책임진다고 생각하기 쉽습니다. 하지만 이는 책임 공유 모델(Shared Responsibility Model)에 대한 오해에서 비롯됩니다. 클라우드 제공자는 '클라우드 자체의 보안(Security of the Cloud)'을 책임지지만, '클라우드 내의 보안(Security in the Cloud)'은 사용자의 몫입니다.
즉, AWS나 GCP는 물리적 인프라, 전력, 네트워크, 하이퍼바이저와 같은 기반 시설의 보안을 담당합니다. 하지만 그 위에서 실행되는 운영체제, 네트워크 구성, 애플리케이션 코드, 데이터 암호화, 그리고 IAM(Identity and Access Management) 권한 관리는 전적으로 사용자의 책임입니다.
EC2, Lambda, Cloud Run 각 서비스별로 PM이 어떤 부분까지 보안 책임 범주에 포함해야 하는지 명확히 이해하는 것이 중요합니다.
| 서비스 | 클라우드 제공자 책임 (예시) | 사용자 책임 (PM/개발팀) |
|---|---|---|
| EC2 (Elastic Compute Cloud) | 물리적 인프라 보안, 하이퍼바이저, 기본 네트워크 | 운영체제(OS) 보안 패치, 애플리케이션 보안, 네트워크 보안 그룹/ACL 설정, 데이터 암호화, IAM 역할 및 사용자 관리 |
| Lambda | 런타임 환경 관리, 기본 인프라, 스케일링 | 함수 코드 보안, 외부 라이브러리 취약점 관리, 환경 변수 보안, IAM 권한 부여, API 게이트웨이 보안 |
| Cloud Run | 컨테이너 런타임 환경, 기본 인프라, 자동 스케일링 | 컨테이너 이미지 보안, 애플리케이션 코드 보안, 서비스 계정 권한 관리, 네트워크 설정 (VPC Connector), 환경 변수 관리 |
예를 들어, EC2 인스턴스에 웹 서버를 운영할 때 SSH 접속 포트인 22번을 모든 IP 주소(0.0.0.0/0)에 대해 개방해두는 것은 전적으로 사용자 책임입니다. 이는 클라우드 제공자가 막아주지 않으며, 쉽게 공격의 대상이 될 수 있습니다. PM은 개발팀과 함께 이러한 기본적인 네트워크 접근 제어부터 꼼꼼히 확인해야 합니다.
서버리스는 서버가 없으니 보안 걱정 없다는 오해
Lambda나 Cloud Run과 같은 서버리스 서비스는 서버 관리 부담을 덜어주어 매력적입니다. 그러나 '서버가 없으니 보안도 필요 없다'는 생각은 큰 오해입니다. 서버리스는 물리적인 서버를 직접 관리하지 않을 뿐, 여전히 컴퓨팅 자원을 사용하며 새로운 형태의 보안 위협이 존재합니다.
과도한 IAM 권한은 치명적입니다
서버리스 환경에서 가장 중요하게 점검해야 할 부분은 바로 IAM 권한 관리입니다. Lambda 함수나 Cloud Run 서비스에 부여되는 권한이 과도하면, 해당 함수나 서비스가 악의적으로 이용될 경우 클라우드 환경 전체에 치명적인 영향을 줄 수 있습니다.
- 최소 권한의 원칙(Principle of Least Privilege): 항상 서비스가 동작하는 데 필요한 최소한의 권한만을 부여해야 합니다. 예를 들어, Lambda 함수가 S3 버킷의 특정 경로에만 파일을 업로드해야 한다면, S3 전체에 대한 'Full Access' 권한이 아닌 해당 경로에 대한 'PutObject' 권한만 부여해야 합니다.
- 와일드카드 권한 경계:
iam:*:*와 같은 와일드카드 권한은 절대적으로 피해야 합니다. 이는 잠재적인 보안 구멍이 됩니다.
PM은 개발팀이 각 서비스에 부여하는 IAM 역할이나 서비스 계정의 권한 목록을 주기적으로 검토하고, 불필요하거나 과도한 권한이 없는지 확인하는 프로세스를 구축해야 합니다.
환경 변수에 민감 정보를 넣는 것은 위험합니다
API 키, 데이터베이스 접속 정보, 암호화 키 등 민감한 정보들을 Lambda 함수나 Cloud Run 서비스의 환경 변수에 직접 저장하는 경우가 많습니다. 이는 코드나 설정이 외부로 노출될 경우 민감 정보가 그대로 유출될 수 있는 매우 위험한 방식입니다.
대신, AWS의 Secrets Manager나 GCP의 Secret Manager와 같은 전용 보안 서비스를 활용해야 합니다. 이 서비스들은 민감 정보를 암호화하여 안전하게 저장하고, 필요한 시점에만 서비스가 접근할 수 있도록 관리합니다. 이를 통해 코드와 민감 정보의 분리를 이루고 보안성을 크게 강화할 수 있습니다.
Image by WebTechExperts on Pixabay
방화벽 설정만 잘하면 안전할 거라는 오해
네트워크 방화벽(AWS 보안 그룹, GCP VPC 네트워크 방화벽)은 클라우드 인프라의 첫 번째 방어선으로서 매우 중요합니다. 하지만 방화벽 설정만으로 모든 보안 위협을 막을 수 있다는 생각은 위험합니다. 방화벽이 외부 침입을 막아주더라도, 내부 권한 관리가 부실하면 내부자 위협이나 인가된 사용자의 오남용에 취약해질 수 있습니다.
예를 들어, EC2 인스턴스의 웹 서버가 Public IP로 외부에 직접 노출되어 있지 않더라도, 내부에서 너무 많은 IAM 권한을 가진 사용자가 접근하여 중요 데이터를 유출하거나 시스템 설정을 변경할 수 있습니다. 즉, 네트워크 보안과 IAM 권한 관리가 균형을 이루어야 합니다.
인스턴스 프로파일과 서비스 계정의 중요성
EC2 인스턴스에서 AWS 서비스에 접근해야 할 때, 직접 액세스 키(Access Key)와 시크릿 키(Secret Key)를 하드코딩하거나 파일에 저장하는 것은 보안상 매우 취약합니다. 대신 IAM 역할(Instance Profile)을 사용해야 합니다. EC2 인스턴스에 IAM 역할을 연결하면, 인스턴스 내에서 실행되는 애플리케이션이 임시 자격 증명을 자동으로 사용하여 안전하게 AWS 서비스에 접근할 수 있습니다.
Cloud Run 또한 마찬가지로 서비스 계정을 통해 GCP 서비스에 접근합니다. 각 서비스 계정에는 필요한 최소한의 권한만 부여하고, 민감한 작업에 대한 권한은 더욱 엄격하게 관리해야 합니다.
코드 예시를 통해 접근 방식의 차이를 이해해 보세요.
# BAD Practice: Hardcoding credentials directly in code or config
# s3_client = boto3.client('s3', aws_access_key_id='YOUR_ACCESS_KEY', aws_secret_access_key='YOUR_SECRET_KEY')
# GOOD Practice: Using IAM Role / Instance Profile
# EC2 인스턴스에 연결된 IAM 역할이 자동으로 자격 증명을 제공합니다.
import boto3
s3_client = boto3.client('s3')
# 이 클라이언트는 인스턴스 프로파일의 권한으로 S3에 접근합니다.
PM은 개발팀이 클라우드 서비스 간의 통신에 IAM 역할이나 서비스 계정을 올바르게 사용하고 있는지, 그리고 이 역할/계정에 최소 권한의 원칙이 적용되었는지 정기적으로 점검해야 합니다.
보안 그룹/네트워크 방화벽 정책은 필요 최소한으로
네트워크 방화벽 설정은 항상 '필요 최소한의 허용' 원칙을 따라야 합니다. 인바운드(Inbound) 규칙은 웹 서비스라면 HTTP(80), HTTPS(443) 포트와 특정 관리용 SSH(22) 포트만 열고, 소스 IP도 특정 IP 대역이나 VPC 내부로 제한해야 합니다. 아웃바운드(Outbound) 규칙 또한 애플리케이션이 외부로 통신해야 하는 특정 목적지(예: 외부 API, DB)만 허용하도록 설정하는 것이 안전합니다.
PM은 개발팀이 구성한 보안 그룹이나 네트워크 방화벽 규칙을 검토하여, 불필요하게 넓은 범위의 접근이 허용되지는 않았는지 확인해야 합니다. 이는 서비스의 잠재적인 공격 노출 면적을 줄이는 데 큰 도움이 됩니다.
마무리하며: PM의 적극적인 보안 점검이 핵심
클라우드 서비스 보안은 단순히 기술적인 문제에 그치지 않습니다. 책임 공유 모델을 정확히 이해하고, 최소 권한의 원칙을 모든 서비스에 적용하며, 민감 정보 관리에 각별히 신경 쓰는 것이 중요합니다. 또한 네트워크 보안과 IAM 권한 관리의 균형을 맞추는 것이 핵심입니다.
EC2, Lambda, Cloud Run과 같은 클라우드 핵심 서비스의 특성을 이해하고, 개발 지식을 가진 기획자/PM의 관점에서 이러한 실전 점검 사항들을 능동적으로 확인하고 의사결정하는 것이 안전한 클라우드 환경을 구축하는 첫걸음입니다. 개발팀과의 긴밀한 협업을 통해 프로젝트의 보안 수준을 한 단계 높여나가시길 바랍니다.
여러분은 클라우드 보안 강화를 위해 어떤 노력을 하고 계신가요? 댓글로 경험을 공유해주세요!