클라우드 보안 기본 원칙: 최소 권한, 네트워크 격리, 감사 로그

클라우드 보안은 하나의 도구가 아니라 설계 원칙의 조합입니다. 최소 권한, 네트워크 격리, 감사 로그 — 이 세 가지가 클라우드 보안의 기본 축을 구성합니다.

핵심 요약

• 최소 권한(Least Privilege): 작업에 필요한 최소한의 권한만 부여합니다. 과잉 권한은 사고 시 피해 범위를 키웁니다.
• 네트워크 격리(Network Isolation): 리소스 간 통신 경로를 명시적으로 제한합니다. 기본값은 "차단"이어야 합니다.
• 감사 로그(Audit Log): 누가, 언제, 무엇을 했는지 기록합니다. 사고 대응과 규정 준수의 기반입니다.
• 이 세 가지는 독립적으로 동작하지 않습니다. 함께 적용해야 방어 깊이(Defense in Depth)가 확보됩니다.

1. 왜 필요한가

개발팀에서 새 서비스를 빠르게 배포하기 위해 IAM 사용자에게 AdministratorAccess를 부여하고, 모든 리소스를 Public Subnet에 배치하고, CloudTrail을 비활성화한 채로 운영한다고 가정합니다.

이 상태에서 Access Key가 유출되면 어떤 일이 벌어질까요?

• 공격자는 관리자 권한으로 모든 리소스에 접근할 수 있습니다.
• 네트워크 격리가 없으므로 내부 리소스까지 직접 도달할 수 있습니다.
• 감사 로그가 없으므로 어떤 작업이 수행되었는지 파악할 수 없습니다.

실제로 이런 사고는 드물지 않습니다. 2024년 기준 클라우드 보안 사고의 상당수는 과잉 권한, 네트워크 노출, 로그 부재가 복합적으로 작용한 결과입니다.

클라우드 보안의 기본 원칙은 이런 상황을 예방하거나, 발생 시 피해를 최소화하기 위한 설계 기준입니다.

2. 세 가지 원칙 개요

원칙	핵심 질문	방어 대상
최소 권한	"이 주체가 정말 이 권한이 필요한가?"	권한 남용, 자격 증명 유출
네트워크 격리	"이 리소스가 정말 이 경로로 통신해야 하는가?"	횡적 이동(Lateral Movement), 무단 접근
감사 로그	"누가, 언제, 무엇을 했는가?"	사고 탐지 지연, 규정 위반

이 세 가지는 각각 다른 계층을 보호합니다.

cloud-security-three-pillars

3. 최소 권한 원칙

3.1 정의

최소 권한 원칙(Principle of Least Privilege)은 주체(사용자, 서비스, 애플리케이션)에게 작업 수행에 필요한 최소한의 권한만 부여하는 원칙입니다.

3.2 왜 중요한가

권한이 넓을수록 사고 시 피해 범위(Blast Radius)가 커집니다.

시나리오	권한 범위	피해 범위
S3 읽기 전용 키 유출	특정 버킷 읽기	해당 버킷 데이터 노출
EC2 관리 키 유출	EC2 전체 관리	모든 인스턴스 조작 가능
관리자 키 유출	전체 AWS 계정	계정 전체 장악

3.3 실무 적용 방법

1단계: 역할 기반 권한 설계

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-app-data",
        "arn:aws:s3:::my-app-data/*"
      ]
    }
  ]
}

이 정책은 my-app-data 버킷에 대한 읽기만 허용합니다. s3:*이나 * 리소스를 사용하지 않습니다.

2단계: 임시 자격 증명 사용

장기 Access Key 대신 IAM Role + STS(Security Token Service)를 사용합니다.

• EC2: Instance Profile을 통해 Role 연결
• Lambda: 실행 역할(Execution Role) 지정
• EKS: IRSA(IAM Roles for Service Accounts) 사용

3단계: 권한 경계(Permission Boundary) 설정

개발자가 IAM Role을 생성할 수 있되, 부여할 수 있는 최대 권한을 제한합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "ap-northeast-2"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:CreateAccessKey",
        "organizations:*"
      ],
      "Resource": "*"
    }
  ]
}

3.4 권한 검토 자동화

• AWS IAM Access Analyzer: 외부 접근 가능한 리소스를 자동 탐지합니다.
• AWS IAM Access Advisor: 사용하지 않는 권한을 식별합니다.
• 정기 검토: 분기별로 미사용 권한을 제거하는 프로세스를 운영합니다.

Security Note
"일단 넓게 주고 나중에 줄이자"는 접근은 실무에서 거의 줄어들지 않습니다. 처음부터 좁게 시작하고, 필요할 때 확장하는 방향이 운영 가능한 전략입니다.

4. 네트워크 격리

4.1 정의

네트워크 격리는 리소스 간 통신 경로를 명시적으로 제한하여, 허가되지 않은 접근을 차단하는 원칙입니다.

4.2 왜 중요한가

네트워크 격리가 없으면 하나의 리소스가 침해되었을 때 공격자가 내부 네트워크를 자유롭게 이동할 수 있습니다. 이를 횡적 이동(Lateral Movement)이라고 합니다.

[공격자] → [Public 웹서버] → [내부 DB] → [관리 서버]

네트워크 격리가 적용되면:

[공격자] → [Public 웹서버] ✗→ [내부 DB] (접근 차단)
                            ✗→ [관리 서버] (접근 차단)

4.3 실무 적용 방법

계층 1: VPC/Subnet 분리

계층	Subnet	접근 허용
프론트엔드	Public Subnet	인터넷 → ALB
애플리케이션	Private Subnet	ALB → App만 허용
데이터베이스	Isolated Subnet	App → DB만 허용

계층 2: Security Group 규칙

# 애플리케이션 서버 Security Group
# 인바운드: ALB Security Group에서 8080 포트만 허용
aws ec2 authorize-security-group-ingress \
  --group-id sg-app-server \
  --protocol tcp \
  --port 8080 \
  --source-group sg-alb

# 데이터베이스 Security Group
# 인바운드: App Security Group에서 3306 포트만 허용
aws ec2 authorize-security-group-ingress \
  --group-id sg-database \
  --protocol tcp \
  --port 3306 \
  --source-group sg-app-server

계층 3: 서비스 간 통신 제한

• VPC Endpoint: AWS 서비스 접근 시 인터넷을 거치지 않고 Private 경로 사용
• PrivateLink: 서비스 간 Private 연결
• Network Firewall: VPC 수준의 트래픽 검사

4.4 Zero Trust 관점

전통적 네트워크 보안은 "내부는 신뢰, 외부는 차단"이었습니다. Zero Trust는 이 가정을 제거합니다.

전통적 모델	Zero Trust 모델
내부 네트워크는 안전하다고 가정	모든 접근을 검증
경계(Perimeter) 기반 방어	리소스 단위 접근 제어
VPN으로 내부 진입 시 자유 이동	매 요청마다 인증/인가

운영 환경에서 완전한 Zero Trust를 구현하기는 어렵지만, 네트워크 격리 + 최소 권한을 조합하면 Zero Trust에 가까운 구조를 만들 수 있습니다.

Tip
Security Group은 소스를 IP가 아닌 다른 Security Group ID로 지정하면, IP 변경에 영향받지 않고 논리적 그룹 단위로 접근을 제어할 수 있습니다.

5. 감사 로그

5.1 정의

감사 로그(Audit Log)는 시스템에서 발생하는 모든 관리 활동과 데이터 접근을 기록하는 것입니다. "누가, 언제, 어디서, 무엇을 했는가"를 추적할 수 있어야 합니다.

5.2 왜 중요한가

감사 로그가 없으면:

• 보안 사고 발생 시 원인을 파악할 수 없습니다.
• 내부자 위협을 탐지할 수 없습니다.
• 규정 준수(Compliance) 감사에 대응할 수 없습니다.
• 권한 남용 여부를 확인할 수 없습니다.

5.3 기록해야 하는 항목

분류	예시	AWS 서비스
관리 활동	IAM 변경, 리소스 생성/삭제	CloudTrail (Management Events)
데이터 접근	S3 객체 읽기/쓰기	CloudTrail (Data Events)
네트워크 흐름	허용/차단된 트래픽	VPC Flow Logs
애플리케이션 로그	로그인 시도, API 호출	CloudWatch Logs
설정 변경	Security Group 규칙 변경	AWS Config

5.4 실무 적용 방법

1단계: CloudTrail 전체 리전 활성화

aws cloudtrail create-trail \
  --name organization-trail \
  --s3-bucket-name my-audit-logs \
  --is-multi-region-trail \
  --enable-log-file-validation

--enable-log-file-validation은 로그 파일의 무결성을 검증할 수 있게 합니다. 공격자가 로그를 변조했는지 확인할 수 있습니다.

2단계: 로그 보호

• S3 버킷에 Object Lock 적용 (삭제 방지)
• 별도 보안 계정에 로그 저장 (운영 계정과 분리)
• 버킷 정책으로 삭제 권한 제한

3단계: 알림 설정

# CloudWatch 알람: Root 계정 사용 시 알림
aws cloudwatch put-metric-alarm \
  --alarm-name "RootAccountUsage" \
  --metric-name "RootAccountUsageCount" \
  --namespace "CloudTrailMetrics" \
  --statistic Sum \
  --period 300 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:ap-northeast-2:123456789012:security-alerts

5.5 로그 보존 기간

규정/목적	권장 보존 기간
일반 운영	최소 90일
보안 사고 대응	1년 이상
규정 준수 (금융, 의료)	HIPAA 6년, SOX 7년, PCI DSS 1년 (규정별 상이)

주의
CloudTrail Data Events(S3 객체 수준 로깅)는 호출량에 비례해 비용이 발생합니다. 모든 버킷에 활성화하기 전에 비용을 추정해야 합니다.

6. 세 원칙의 연계: Defense in Depth

세 가지 원칙은 독립적으로도 의미가 있지만, 함께 적용할 때 방어 깊이(Defense in Depth)가 확보됩니다.

cloud-security-defense-in-depth

 

공격 단계	방어 원칙	효과
자격 증명 유출	최소 권한	피해 범위 제한
내부 이동 시도	네트워크 격리	횡적 이동 차단
활동 은폐 시도	감사 로그	행위 추적 및 탐지

하나의 원칙이 실패해도 다른 원칙이 보완합니다.

• 권한이 유출되어도 네트워크 격리가 접근을 차단합니다.
• 네트워크를 우회해도 감사 로그가 활동을 기록합니다.
• 로그를 삭제하려 해도 최소 권한이 삭제 권한을 차단합니다.

7. 실무 시나리오

시나리오: 스타트업 웹 서비스 보안 설계

팀원 5명의 스타트업에서 웹 서비스를 AWS에 배포한다고 가정합니다. 빠른 개발이 중요하지만, 기본 보안은 확보해야 합니다.

최소 권한 적용:

역할	권한 범위
백엔드 개발자	EC2, RDS, S3 (개발 환경만)
프론트엔드 개발자	S3, CloudFront (정적 자산만)
DevOps 엔지니어	인프라 전체 (Terraform 실행용)
대표/PM	읽기 전용 + 비용 대시보드

모든 역할은 IAM Role + SSO로 접근하며, 장기 Access Key는 사용하지 않습니다.

네트워크 격리 적용:

VPC (10.0.0.0/16)
├── Public Subnet: ALB만 배치
├── Private Subnet: ECS Fargate 태스크
├── DB Subnet: RDS (App에서만 접근 가능)
└── VPC Endpoint: S3, ECR (인터넷 경유 없이 접근)

감사 로그 적용:

• CloudTrail: 전체 리전 활성화
• VPC Flow Logs: 거부된 트래픽 기록
• 알림: Root 계정 사용, IAM 정책 변경, Security Group 변경 시 Slack 알림

이 설계의 trade-off:

항목	이점	비용/부담
IAM Role + SSO	키 유출 위험 제거	SSO 초기 설정 필요
Private Subnet + NAT	외부 노출 차단	NAT Gateway 비용 발생
CloudTrail 전체 활성화	사고 대응 가능	S3 저장 비용
VPC Endpoint	인터넷 경유 제거	Endpoint 시간당 비용

스타트업 초기에는 NAT Gateway 비용이 부담될 수 있습니다. 이 경우 VPC Endpoint로 AWS 서비스 접근을 처리하고, 외부 API 호출이 적다면 NAT Instance(t3.nano)로 비용을 줄일 수 있습니다.

8. 클라우드별 구현 비교

원칙	AWS	Azure	GCP
최소 권한	IAM Policy + Role	Azure RBAC + PIM	IAM Role + Condition
네트워크 격리	VPC + Security Group	VNet + NSG	VPC + Firewall Rule
감사 로그	CloudTrail + Config	Activity Log + Defender	Cloud Audit Logs
권한 분석	IAM Access Analyzer	Entra Permissions Management	IAM Recommender
네트워크 로그	VPC Flow Logs	NSG Flow Logs	VPC Flow Logs

각 클라우드의 구현 방식은 다르지만, 적용해야 하는 원칙은 동일합니다. 멀티클라우드 환경에서는 원칙 수준에서 일관성을 유지하고, 구현은 각 플랫폼의 네이티브 도구를 사용하는 것이 운영 효율이 높습니다.

9. 비용/운영 고려사항

주의
보안 강화는 비용과 운영 복잡도를 증가시킵니다. 리스크 수준에 맞는 적절한 수준을 선택해야 합니다.

비용 발생 항목

항목	예상 비용 (월)	비고
CloudTrail (Management Events)	무료 (첫 번째 Trail)	추가 Trail은 이벤트당 과금
CloudTrail (Data Events)	$0.10 / 100,000 이벤트	S3 객체 수준 로깅 시
VPC Flow Logs	$0.50 / GB (CloudWatch)	트래픽 양에 비례
AWS Config	$0.003 / 구성 항목	리소스 수에 비례
NAT Gateway	~$32 + 데이터 전송	AZ당 1개 기준
GuardDuty	$4.00 / 100만 이벤트	위협 탐지 서비스

단계별 적용 전략

단계	적용 항목	대상
즉시	CloudTrail 활성화, MFA 적용, 최소 권한 IAM	모든 환경
1개월 내	VPC 분리, Security Group 정비, VPC Flow Logs	운영 환경
3개월 내	AWS Config, GuardDuty, 정기 권한 검토	운영 환경
6개월 내	SIEM 연동, 자동 대응, 침투 테스트	규모 확장 시

10. 자주 하는 실수

1. "개발 환경이니까 보안은 나중에": 개발 환경의 자격 증명이 운영 환경에 접근할 수 있는 경우가 많습니다. 환경 분리부터 시작해야 합니다.
2. AdministratorAccess를 기본 권한으로 사용: 초기에는 편하지만, 사고 시 피해 범위가 계정 전체로 확대됩니다.
3. Security Group에 0.0.0.0/0 인바운드 허용: SSH(22), RDP(3389) 포트를 전체 IP에 개방하는 것은 가장 흔한 보안 취약점입니다.
4. CloudTrail을 비활성화하거나 단일 리전만 활성화: 공격자는 CloudTrail이 비활성화된 리전에서 활동합니다.
5. 로그를 운영 계정에만 저장: 공격자가 계정을 장악하면 로그도 삭제할 수 있습니다. 별도 보안 계정에 저장해야 합니다.
6. 권한을 부여한 후 검토하지 않음: 프로젝트가 끝나도 권한이 남아있는 경우가 많습니다. 분기별 검토가 필요합니다.

11. 정리

• 클라우드 보안의 기본 축은 최소 권한, 네트워크 격리, 감사 로그입니다.
• 최소 권한은 피해 범위를 제한하고, 네트워크 격리는 횡적 이동을 차단하며, 감사 로그는 사고를 탐지하고 추적합니다.
• 세 원칙을 함께 적용하면 하나가 실패해도 다른 원칙이 보완하는 Defense in Depth가 구현됩니다.
• 보안 강화는 비용과 운영 복잡도를 증가시키므로, 리스크 수준에 맞는 단계별 적용이 현실적입니다.
• 처음부터 좁게 시작하고 필요할 때 확장하는 것이 운영 가능한 보안 전략입니다.

관련 글

• AWS VPC란 무엇인가: Subnet, Route Table, Internet Gateway 개념 정리

참고 문서

• AWS Well-Architected Framework - Security Pillar
• AWS IAM Best Practices
• AWS CloudTrail User Guide
• NIST Cybersecurity Framework
• Azure Security Best Practices