Ver3.5 ☁️ 클라우드 환경 보안
☁️ 클라우드 환경 보안
클라우드 시대에 살고 있는 우리... AWS 한 번쯤은 써봤거나 들어봤죠? 🌐
근데 막상 쓰다 보면 보안 설정이 얼마나 중요한지 처음엔 잘 모르는 경우가 많아요.
오늘은 AWS 보안의 핵심 중의 핵심, IAM(Identity and Access Management)과 보안 그룹(Security Group)에 대해서 진짜 제대로 파헤쳐볼게요! 🔐
✅ 최소 권한 원칙(Least Privilege)이 뭔지 알게 됨
✅ 보안 그룹 vs NACL 차이점 파악
✅ 실무에서 바로 쓸 수 있는 보안 설정 노하우
✅ 흔히 저지르는 보안 실수들 예방
AWS는 전 세계 클라우드 시장의 약 32%를 점유하고 있는 압도적인 1위 플랫폼이에요. 🏆
근데 그만큼 해커들의 타깃이 되기도 하죠... ㅋㅋㅋ 무서운 얘기지만 사실이에요.
사례 1: 개발자가 GitHub에 AWS 액세스 키를 실수로 커밋 → 5분 만에 봇이 감지 → 비트코인 채굴 인스턴스 수백 개 생성 → 하루 만에 수천만원 요금 발생 💸
사례 2: 보안 그룹에서 22번 포트(SSH)를 0.0.0.0/0으로 오픈 → 브루트포스 공격으로 서버 침투 → 고객 데이터 유출 😱
사례 3: 퇴사한 직원의 IAM 계정 삭제 안 함 → 악의적 접근으로 데이터 삭제 → 서비스 장애 발생 🔥
이런 사고들의 공통점이 뭔지 알아요? 전부 기본적인 보안 설정만 제대로 했어도 막을 수 있었던 것들이에요!
자, 이제 본격적으로 AWS 보안의 핵심을 파헤쳐봅시다! 💪
IAM은 Identity and Access Management의 약자예요.
한국어로 하면 신원 및 접근 관리... 뭔가 딱딱하죠? ㅋㅋㅋ
쉽게 말하면 "누가, 무엇을, 어디서, 어떻게 할 수 있는지"를 관리하는 시스템이에요! 🎯
IAM 사용자는 AWS 계정 안에서 만드는 개별 접근 주체예요.
사람일 수도 있고, 애플리케이션일 수도 있어요! 🤖
🔑 인증 방식 두 가지
콘솔 접근 아이디 + 비밀번호 (+ MFA 권장)
→ AWS 웹 콘솔에 로그인할 때 사용
프로그래밍 접근 액세스 키 ID + 시크릿 액세스 키
→ CLI, SDK, API 호출할 때 사용
- ⚠️ 절대 하면 안 되는 것들!
- ❌ 루트 계정으로 일상적인 작업 수행
- ❌ 액세스 키를 코드에 하드코딩
- ❌ 액세스 키를 GitHub 같은 공개 저장소에 올리기
- ❌ 한 명이 여러 사람이 공유하는 IAM 계정 사용
그룹은 여러 사용자를 묶어서 한 번에 권한을 관리하는 단위예요.
예를 들어 "개발팀", "운영팀", "데이터팀" 이런 식으로 그룹을 만들고,
각 그룹에 맞는 권한을 부여하면 훨씬 관리가 편해지죠! 😎
📌 그룹의 특징
✅ 그룹 안에 그룹을 넣는 건 불가능 (중첩 그룹 X)
✅ 한 사용자가 여러 그룹에 속할 수 있음
✅ 그룹에 정책을 연결하면 그룹 내 모든 사용자에게 적용
✅ 사용자가 그룹에서 나가면 해당 권한도 자동으로 사라짐
역할은 IAM에서 가장 강력하고 유연한 기능 중 하나예요!
특정 사용자나 서비스에게 임시로 권한을 위임하는 개념이에요. 🎯
🎭 역할이 쓰이는 주요 상황들
EC2 → S3 접근 EC2 인스턴스에 S3 읽기 역할 부여
Lambda 실행 Lambda 함수가 DynamoDB에 접근할 때
크로스 계정 A 계정의 리소스를 B 계정에서 접근할 때
외부 IdP 연동 Google, Facebook 등 소셜 로그인 연동
정책은 JSON 형식으로 작성된 권한 문서예요.
"이 사람은 S3 버킷을 읽을 수 있다", "이 사람은 EC2를 시작/중지할 수 있다" 이런 걸 정의하는 거죠! 📝
📋 정책의 종류
관리형 정책 AWS가 미리 만들어놓은 정책 (예: AmazonS3ReadOnlyAccess)
고객 관리형 정책 내가 직접 만든 정책 (재사용 가능)
인라인 정책 특정 사용자/그룹/역할에만 직접 붙이는 정책 (재사용 불가)
정책 JSON 구조를 한번 살펴볼까요? 처음 보면 무서워 보이지만 사실 별거 없어요 ㅋㅋㅋ
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::my-bucket/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
}
}
}
]
}🔍 정책 JSON 핵심 요소 해설
Version → 정책 언어 버전 (항상 "2012-10-17" 사용)
Effect → Allow(허용) 또는 Deny(거부)
Action → 허용/거부할 AWS 서비스 작업
Resource → 적용 대상 리소스 (ARN 형식)
Condition → 추가 조건 (IP 제한, MFA 필수 등)
1️⃣ 명시적 Deny → 무조건 거부 (최우선)
2️⃣ 명시적 Allow → 허용
3️⃣ 기본값 → 암묵적 Deny (아무 정책도 없으면 거부)
즉, Deny는 Allow보다 항상 강해요! 이거 모르면 나중에 왜 안 되지? 하고 삽질함 ㅋㅋㅋ
보안의 황금 법칙이에요! ✨
필요한 것만, 딱 그만큼만 권한을 주자!는 원칙이죠.
이 사람이 실제로 무슨 작업을 해야 하는지 먼저 파악해요. "개발자니까 다 줘야지"가 아니라 "이 개발자는 EC2 조회와 S3 업로드만 필요하다" 이런 식으로요!
AWS가 미리 만들어놓은 정책들이 꽤 잘 만들어져 있어요. AmazonS3ReadOnlyAccess, AmazonEC2ReadOnlyAccess 같은 것들이요. 처음엔 이걸 활용하는 게 좋아요!
AWS에서 제공하는 도구로, 실제로 사용하지 않는 권한을 찾아줘요. "이 사람한테 S3 쓰기 권한 줬는데 6개월 동안 한 번도 안 썼네?" 이런 걸 발견할 수 있어요!
분기마다 한 번씩은 IAM 사용자 목록과 권한을 검토하는 게 좋아요. 퇴사자 계정은 즉시 비활성화! 이건 진짜 중요해요 ㅠㅠ
→ 외부에서 접근 가능한 리소스 자동 탐지
→ 사용하지 않는 권한 식별 및 제거 권고
MFA는 Multi-Factor Authentication의 약자예요.
비밀번호 하나만으로는 부족하니까, 추가 인증 수단을 하나 더 요구하는 거예요! 📱
📱 MFA 종류
가상 MFA Google Authenticator, Authy 같은 앱 → 가장 많이 씀
하드웨어 MFA YubiKey 같은 물리적 장치 → 고보안 환경에서 사용
SMS MFA 문자 메시지 → AWS에서는 권장하지 않음 (SIM 스와핑 공격 위험)
루트 계정에는 무조건 MFA 설정해야 해요! 이건 선택이 아니에요 ㅋㅋㅋ
그리고 가능하면 모든 IAM 사용자에게도 MFA를 강제하는 게 좋아요.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyWithoutMFA",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:GetUser",
"iam:ListMFADevices",
"sts:GetSessionToken"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}보안 그룹은 EC2 인스턴스 같은 AWS 리소스에 대한 가상 방화벽이에요! 🔥
인바운드(들어오는 트래픽)와 아웃바운드(나가는 트래픽)를 제어하죠.
🔑 알아야 할 특징들
Stateful 인바운드 허용 시 응답 트래픽은 자동 허용 (반대 방향 규칙 불필요)
화이트리스트 방식 기본적으로 모든 인바운드 트래픽 차단, 허용 규칙만 추가
인스턴스 레벨 EC2 인스턴스, RDS, Lambda 등 개별 리소스에 적용
다중 적용 하나의 인스턴스에 여러 보안 그룹 적용 가능 (최대 5개)
Deny 규칙 없음 명시적 거부 규칙 추가 불가 (NACL과의 차이점!)
보안 그룹 규칙에는 다음 요소들이 들어가요:
| 요소 | 설명 | 예시 |
|---|---|---|
| 타입 | 프로토콜 유형 | HTTP, HTTPS, SSH, Custom TCP |
| 프로토콜 | TCP, UDP, ICMP | TCP |
| 포트 범위 | 허용할 포트 번호 | 80, 443, 22, 3306 |
| 소스/대상 | IP 범위 또는 다른 보안 그룹 | 0.0.0.0/0, 10.0.0.0/8 |
| 설명 | 규칙 설명 (선택사항) | "웹 서버 HTTP 허용" |
실무에서 자주 쓰는 3계층 아키텍처 보안 그룹 설계를 알아볼게요! 🎯
→ 각 계층이 독립적으로 보호됨
→ 소스를 IP가 아닌 보안 그룹으로 지정하면 IP 변경에도 유연하게 대응
→ 감사 및 트러블슈팅이 쉬움
보안 그룹이랑 NACL(Network Access Control List)... 둘 다 방화벽인데 뭐가 다른 거야? 🤔
이거 헷갈리는 분들 진짜 많아요 ㅋㅋㅋ 한번에 정리해드릴게요!
| 구분 | 보안 그룹 | NACL |
|---|---|---|
| 적용 레벨 | 인스턴스 레벨 | 서브넷 레벨 |
| 상태 추적 | Stateful (응답 자동 허용) | Stateless (응답도 명시 필요) |
| 규칙 방식 | 허용 규칙만 가능 | 허용 + 거부 규칙 모두 가능 |
| 규칙 평가 | 모든 규칙 동시 평가 | 번호 순서대로 평가 (낮은 번호 우선) |
| 기본값 | 인바운드 전체 차단 | 모든 트래픽 허용 (기본 NACL) |
| 적용 대상 | 명시적으로 연결된 인스턴스 | 서브넷 내 모든 인스턴스 |
예: HTTP(80) 인바운드 허용 시
→ 인바운드: 포트 80 허용
→ 아웃바운드: 임시 포트(1024-65535) 허용 필수!
이거 모르면 왜 안 되지? 하고 몇 시간 삽질함 ㅋㅋㅋ
실무에서 가장 많이 쓰는 패턴 중 하나가 EC2 인스턴스에 IAM 역할 부여예요!
예전에는 EC2에 AWS 키를 직접 저장했는데... 이건 진짜 위험한 방법이에요 😱
# 이렇게 하면 절대 안 됨!
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY2. 필요한 정책 연결 (예: S3 읽기 권한)
3. EC2 인스턴스에 역할 연결
4. 코드에서 자동으로 임시 자격증명 사용!
# Python boto3 예시 - 역할 사용 시 자격증명 불필요!
import boto3
# 역할이 연결된 EC2에서는 이렇게만 해도 됨
s3 = boto3.client('s3')
response = s3.list_buckets()
print(response['Buckets'])신뢰할 수 있는 엔터티 유형: AWS 서비스 선택
EC2가 이 역할을 사용할 수 있도록 신뢰 관계 설정
필요한 최소 권한만 선택 (예: AmazonS3ReadOnlyAccess)
명확한 이름 사용 (예: ec2-s3-readonly-role)
인스턴스 선택 → 작업 → 보안 → IAM 역할 수정
보안 설정을 잘 해놨다고 끝이 아니에요! 🚨
누가 언제 무엇을 했는지 추적하는 것도 보안의 핵심이에요.
AWS 계정에서 발생하는 모든 API 호출을 기록하는 서비스예요.
"누가 S3 버킷을 삭제했어?", "언제 보안 그룹이 변경됐어?" 이런 걸 추적할 수 있어요! 🕵️
AWS GuardDuty는 머신러닝 기반의 위협 탐지 서비스예요.
비정상적인 API 호출, 알려진 악성 IP에서의 접근, 크립토마이닝 활동 등을 자동으로 탐지해요!
활성화하는 것만으로도 보안 수준이 확 올라가요 ㅋㅋㅋ 진짜로요!
AWS Config는 리소스 설정 변경을 추적하고, 규정 준수 여부를 자동으로 평가해요.
"보안 그룹에 0.0.0.0/0 규칙이 추가되면 알림 보내기" 같은 규칙을 만들 수 있어요!
✅ GuardDuty → 위협 자동 탐지
✅ AWS Config → 설정 변경 추적
✅ Security Hub → 보안 상태 통합 대시보드
✅ CloudWatch → 메트릭 및 알람 설정
재능넷 같은 플랫폼에서 개발자들이 AWS를 처음 쓸 때 자주 저지르는 실수들을 모아봤어요! 😅
이거 미리 알면 나중에 엄청난 삽질을 피할 수 있어요 ㅋㅋㅋ
자, 이제 실제로 내 AWS 계정이 얼마나 안전한지 체크해볼 시간이에요! 📋
아래 체크리스트를 하나씩 확인해보세요. 다 체크되면 기본 보안은 갖춘 거예요! 💪
☐ 루트 계정에 MFA 설정 완료
☐ 루트 계정 액세스 키 없음 (또는 삭제)
☐ 일상 작업용 IAM 사용자 생성 완료
☐ 모든 IAM 사용자에 MFA 적용
☐ 최소 권한 원칙 적용 (AdministratorAccess 남발 없음)
☐ 사용하지 않는 IAM 사용자 비활성화
☐ 액세스 키 90일 이내 교체
☐ IAM 비밀번호 정책 강화 (최소 14자, 복잡도 요구)
☐ 퇴사자 계정 즉시 삭제/비활성화
☐ IAM Access Analyzer 활성화
☐ 보안 그룹에 0.0.0.0/0 SSH(22) 규칙 없음
☐ 보안 그룹에 0.0.0.0/0 RDP(3389) 규칙 없음
☐ DB 포트(3306, 5432 등) 외부 노출 없음
☐ 불필요한 보안 그룹 규칙 정리
☐ VPC 기본 보안 그룹 사용 안 함
☐ 퍼블릭 서브넷에 DB 인스턴스 없음
☐ S3 버킷 Block Public Access 활성화
☐ NACL 추가 방어선 구성
☐ CloudTrail 모든 리전 활성화
☐ GuardDuty 활성화
☐ AWS Config 활성화
☐ Security Hub 활성화
☐ 루트 계정 로그인 알림 설정
☐ 비정상 요금 알림 설정 (Billing Alert)
☐ CloudWatch 보안 관련 알람 설정
특히 보안 체크 항목들을 자동으로 스캔해서 문제점을 알려주니까 꼭 활용해보세요! 😊
AWS 콘솔 → Trusted Advisor → 보안 탭 확인
자, 이제 실제 시나리오로 배운 내용을 정리해볼게요! 🚀
재능넷처럼 서비스를 운영하는 스타트업이 AWS를 처음 설정한다고 가정해볼게요.
팀 구성:
- 개발팀 3명 (백엔드 2명, 프론트엔드 1명)
- 운영팀 1명
- 데이터 분석가 1명
사용 서비스:
- EC2 (웹 서버, 앱 서버)
- RDS (MySQL 데이터베이스)
- S3 (파일 저장)
- CloudFront (CDN)
- Lambda (서버리스 함수)
group-developers → EC2 읽기/쓰기, S3 읽기/쓰기, CloudWatch 읽기
group-operations → EC2 전체, RDS 읽기, CloudWatch 전체
group-data-analysts → S3 읽기, Athena 전체, QuickSight 전체
각 팀원별 개인 IAM 계정 생성
해당 그룹에 배정
MFA 설정 강제화
role-ec2-s3-access → EC2에서 S3 접근용
role-lambda-rds-access → Lambda에서 RDS 접근용
role-ec2-cloudwatch → EC2에서 CloudWatch 로그 전송용
SG-ALB 로드밸런서용
→ 인바운드: 80(HTTP), 443(HTTPS) from 0.0.0.0/0
SG-WebApp 웹/앱 서버용
→ 인바운드: 8080 from SG-ALB only
→ 인바운드: 22(SSH) from SG-Bastion only
SG-RDS 데이터베이스용
→ 인바운드: 3306(MySQL) from SG-WebApp only
SG-Bastion 배스천 호스트용
→ 인바운드: 22(SSH) from 회사 IP only (예: 203.0.113.0/32)
→ SSH는 배스천 호스트를 통해서만 접근
→ 배스천 호스트는 회사 IP에서만 접근
→ 각 계층이 독립적으로 보호됨
→ 최소 권한 원칙 적용으로 피해 범위 최소화
보안은 한 번 설정하고 끝이 아니에요! 🔄
지속적인 모니터링과 자동화가 필요해요. AWS에서 제공하는 자동화 도구들을 알아볼게요!
AWS Config Rules로 보안 정책 위반을 자동으로 탐지할 수 있어요!
restricted-ssh 보안 그룹에 SSH 전체 오픈 규칙 있으면 알림
mfa-enabled-for-iam-console-access MFA 없는 IAM 사용자 탐지
s3-bucket-public-read-prohibited S3 버킷 퍼블릭 읽기 허용 탐지
root-account-mfa-enabled 루트 계정 MFA 미설정 탐지
access-keys-rotated 90일 이상 된 액세스 키 탐지
보안 이벤트 발생 시 자동으로 대응하는 시스템을 만들 수 있어요!
# 예시: 루트 계정 로그인 감지 시 자동 알림
import boto3
import json
def lambda_handler(event, context):
# CloudTrail 이벤트에서 루트 로그인 감지
if event['detail']['userIdentity']['type'] == 'Root':
sns = boto3.client('sns')
sns.publish(
TopicArn='arn:aws:sns:ap-northeast-2:123456789:security-alerts',
Subject='🚨 루트 계정 로그인 감지!',
Message=f"루트 계정 로그인 감지!\n시간: {event['time']}\nIP: {event['detail']['sourceIPAddress']}"
)
return {'statusCode': 200}CIS AWS Foundations Benchmark 같은 보안 표준을 자동으로 체크해주기도 해요!
보안 점수를 숫자로 보여주니까 "우리 계정 보안이 몇 점이야?" 하고 확인할 수 있어서 편해요 ㅋㅋㅋ
AWS 보안은 정말 깊이 파면 팔수록 끝이 없는 분야예요! 🌊
재능넷에서도 AWS 보안 관련 전문가들의 재능을 찾아볼 수 있으니 참고해보세요 😊
아래 리소스들로 더 깊이 공부해보세요!
AWS 공식 문서 docs.aws.amazon.com/iam
→ IAM 사용 설명서 (한국어 지원)
AWS Security Specialty AWS 보안 전문가 자격증
→ 클라우드 보안 전문가로 인정받는 자격증
AWS Well-Architected 보안 필러
→ AWS 모범 사례 가이드 (무료)
CIS AWS Foundations 보안 벤치마크
→ 업계 표준 보안 설정 가이드
AWS Free Tier 무료로 실습 가능
→ 12개월 무료 + 영구 무료 서비스 포함
CloudGoat 취약한 AWS 환경 실습
→ 보안 취약점을 직접 찾아보는 실습 도구
Prowler AWS 보안 감사 도구
→ 오픈소스 AWS 보안 점검 도구
ScoutSuite 멀티 클라우드 감사
→ AWS 보안 설정 자동 분석
오늘 AWS IAM과 보안 그룹에 대해서 진짜 많은 내용을 다뤘어요! 🎊
처음엔 복잡해 보이지만, 하나씩 적용해나가다 보면 어느새 자연스럽게 보안을 생각하는 개발자가 되어있을 거예요!
👤 사용자/그룹/역할/정책의 관계 이해
⚖️ 최소 권한 원칙 = 보안의 황금 법칙
🔒 MFA = 루트 계정과 IAM 사용자 모두 필수
🌐 보안 그룹 = 인스턴스 레벨 Stateful 방화벽
🧱 NACL = 서브넷 레벨 Stateless 방화벽
📊 CloudTrail + GuardDuty = 지속적 모니터링
🤖 AWS Config = 보안 정책 자동 검사
보안은 개발자 혼자 감당하기 어려운 분야예요.
팀 전체가 보안 의식을 갖고, 자동화 도구를 활용하고, 지속적으로 개선해나가는 것이 중요해요! 🤝
궁금한 점이 있다면 재능넷에서 AWS 보안 전문가를 찾아 도움을 받아보는 것도 좋은 방법이에요! 😊
여러분의 클라우드 환경이 항상 안전하길 바랍니다! 🛡️✨
댓글 작성
이 글에 대한 여러분의 생각을 들려주세요
로그인이 필요합니다
댓글을 작성하려면 먼저 로그인해주세요.
댓글 0
지식인의 숲 - 지적 재산권 보호 고지
지적 재산권 보호 고지
- 저작권 및 소유권: 본 컨텐츠는 재능넷의 독점 AI 기술로 생성되었으며, 대한민국 저작권법 및 국제 저작권 협약에 의해 보호됩니다.
- AI 생성 컨텐츠의 법적 지위: 본 AI 생성 컨텐츠는 재능넷의 지적 창작물로 인정되며, 관련 법규에 따라 저작권 보호를 받습니다.
- 사용 제한: 재능넷의 명시적 서면 동의 없이 본 컨텐츠를 복제, 수정, 배포, 또는 상업적으로 활용하는 행위는 엄격히 금지됩니다.
- 데이터 수집 금지: 본 컨텐츠에 대한 무단 스크래핑, 크롤링, 및 자동화된 데이터 수집은 법적 제재의 대상이 됩니다.
- AI 학습 제한: 재능넷의 AI 생성 컨텐츠를 타 AI 모델 학습에 무단 사용하는 행위는 금지되며, 이는 지적 재산권 침해로 간주됩니다.
아직 댓글이 없습니다.