[클라우드 활용 포트폴리오] AWS 클라우드 보안 실무 사례 분석과 대응 전략

공부/클라우드 활용

[클라우드 활용 포트폴리오] AWS 클라우드 보안 실무 사례 분석과 대응 전략

춤추는 선인장 2026. 6. 22. 02:19

SMALL

1. 학습 개요

이번 포트폴리오는 클라우드 활용 13주차 강의자료를 바탕으로, AWS 클라우드 환경에서 발생할 수 있는 주요 보안 위협과 실제 사고 사례, 그리고 이에 대응하기 위한 기본 보안 전략을 정리한 글이다.

이전 글에서는 IAM을 통한 사용자 권한 관리, S3의 퍼블릭 접근 제어, VPC와 보안 그룹을 이용한 네트워크 보호, CloudWatch와 CloudTrail을 통한 모니터링 및 감사, WAF와 GuardDuty를 활용한 웹 공격 방어와 위협 탐지를 학습했다. 13주차에서는 이러한 보안 개념들을 실제 사고 사례와 연결하여, 어떤 설정 실수가 어떤 보안 사고로 이어질 수 있는지 분석했다.

클라우드 보안에서 중요한 점은 보안 사고가 반드시 복잡한 해킹 기술 때문에만 발생하는 것은 아니라는 점이다. S3 버킷 공개, 과도한 IAM 권한, Access Key 유출, MFA 미설정, 보안 그룹 전체 개방처럼 비교적 단순한 설정 오류도 큰 사고로 이어질 수 있다.

이번 글에서는 다음 내용을 중심으로 정리한다.

클라우드 보안 위협이 증가하는 이유
대표적인 클라우드 보안 위협 유형
계정 도용
구성 오류
데이터 유출
악의적 내부자
서비스 거부 공격
안전하지 않은 인터페이스/API
기본 보안 대응 전략
S3 버킷 공개 사고 분석
루트 계정 탈취 시나리오
과도한 IAM 권한으로 인한 내부 위협
보안 점검 실습 및 문제 해결
13주차 학습 후기

2. 클라우드 보안 위협이 증가하는 이유

클라우드는 서버, 데이터베이스, 스토리지, API, 관리 콘솔 등 다양한 리소스를 인터넷 기반으로 빠르게 생성하고 운영할 수 있는 환경이다. 이 점은 클라우드의 큰 장점이지만, 동시에 공격 표면이 넓어진다는 의미이기도 하다.

온프레미스 환경에서는 물리적인 서버와 내부망 중심으로 보안이 구성되는 경우가 많았다. 반면 클라우드 환경에서는 리소스와 API가 인터넷을 통해 접근 가능하고, 관리 콘솔, CLI, SDK, API Gateway 등 다양한 경로로 리소스가 제어된다. 따라서 공격자가 물리적으로 접근하지 않아도, 노출된 자격 증명이나 잘못된 권한 설정을 이용해 클라우드 리소스를 악용할 수 있다.

클라우드 보안 위협이 증가하는 주요 이유는 다음과 같다.

이유설명

공격 표면 확대	서버, 스토리지, API, 관리 콘솔 등이 인터넷 기반으로 노출됨
빠른 배포 환경	DevOps와 자동화 환경에서 보안 검증 절차가 짧아질 수 있음
복잡한 권한 구조	IAM, 리소스 정책, 버킷 정책, 보안 그룹 등 설정 요소가 많음
멀티 테넌트 구조	논리적 격리 기반이므로 설정 오류의 영향이 커질 수 있음
API 중심 운영	콘솔, CLI, SDK가 모두 API 호출 기반으로 동작
자격 증명 중요성 증가	Access Key, Secret Key 유출 시 리소스 악용 가능

즉, 클라우드 보안은 단순히 서버에 백신을 설치하는 수준이 아니라, 계정, 권한, 네트워크, 데이터, API, 로그, 모니터링을 모두 함께 관리하는 문제라고 볼 수 있다.

3. 대표적인 클라우드 보안 위협 유형

13주차 자료에서는 대표적인 클라우드 보안 위협 유형으로 다음 항목들을 다루었다.

위협 유형설명

계정 도용	공격자가 정상 사용자의 계정을 탈취하여 클라우드 리소스를 악용
구성 오류	S3 공개, 보안 그룹 전체 개방, CloudTrail 비활성화 등 설정 실수
데이터 유출	민감 데이터가 외부로 노출되는 사고
악의적 내부자	권한을 가진 내부자가 데이터를 유출하거나 리소스를 악용
DoS/DDoS	대규모 트래픽으로 서비스 정상 운영 방해
안전하지 않은 인터페이스/API	인증, 권한, 입력 검증, 암호화가 부족한 API로 인한 사고

이러한 위협은 서로 독립적으로 발생하기도 하지만, 실제 사고에서는 여러 위협이 결합되는 경우가 많다. 예를 들어 Access Key가 GitHub에 노출되면 계정 도용으로 이어질 수 있고, 해당 계정에 과도한 IAM 권한이 부여되어 있다면 공격자가 EC2 인스턴스를 생성하거나 S3 데이터를 삭제할 수도 있다.

4. 계정 도용(Account Hijacking)

4.1 개념

계정 도용(Account Hijacking)은 공격자가 정상 사용자의 계정이나 자격 증명을 탈취하여 클라우드 리소스를 무단으로 사용하는 공격이다.

AWS에서는 콘솔 로그인 정보뿐만 아니라 Access Key와 Secret Access Key도 중요한 자격 증명이다. 이 정보가 외부에 노출되면 공격자는 해당 권한 범위 안에서 AWS API를 호출할 수 있다.

4.2 주요 원인

계정 도용의 주요 원인은 다음과 같다.

피싱 공격
약한 비밀번호 사용
MFA 미설정
Credential stuffing
Access Key 유출
GitHub 또는 공개 저장소에 자격 증명 업로드
사용하지 않는 Access Key 방치
루트 계정의 일상적 사용

특히 Access Key가 코드나 설정 파일에 포함된 상태로 GitHub에 업로드되면, 공격자가 이를 자동으로 탐지하여 매우 빠르게 악용할 수 있다.

4.3 피해 결과

계정 도용이 발생하면 다음과 같은 피해가 발생할 수 있다.

피해 유형설명

무단 API 호출	공격자가 AWS 리소스를 임의로 생성, 수정, 삭제
비용 폭증	EC2 인스턴스를 대량 생성해 암호화폐 채굴 등에 사용
데이터 삭제	S3, RDS, EBS 등 데이터 리소스 삭제
권한 변경	공격자가 IAM 사용자나 정책을 수정하여 지속 접근 확보
서비스 중단	주요 리소스를 중지하거나 보안 그룹을 변경
보안 로그 훼손	CloudTrail, GuardDuty 설정을 변경하여 추적 회피 시도

4.4 대응 전략

계정 도용을 예방하기 위한 대응 전략은 다음과 같다.

대응 전략설명

MFA 필수화	루트 계정과 주요 IAM 사용자에 MFA 적용
루트 계정 사용 최소화	일상 작업은 IAM 사용자 또는 역할로 수행
최소 권한 원칙	필요한 작업만 허용하고 과도한 권한 제거
Access Key 주기적 관리	사용하지 않는 키 삭제, 키 회전 적용
CloudTrail 활성화	로그인, API 호출, 권한 변경 내역 추적
GuardDuty 활성화	비정상 API 호출과 악성 활동 탐지
IAM Access Analyzer 활용	과도한 권한과 외부 공개 가능성 점검

5. 구성 오류(Misconfiguration)

5.1 개념

구성 오류(Misconfiguration)는 클라우드 서비스 설정이 잘못되어 보안 취약점이 발생하는 경우를 의미한다. 클라우드 보안 사고에서 가장 흔하게 언급되는 원인 중 하나이다.

구성 오류는 복잡한 공격 기술이 없어도 사고로 이어질 수 있다. 예를 들어 S3 버킷을 실수로 퍼블릭으로 열어두거나, 보안 그룹에서 SSH 포트를 0.0.0.0/0으로 개방하거나, CloudTrail을 비활성화하면 보안 위험이 커진다.

5.2 대표적인 구성 오류 예시

구성 오류위험

S3 버킷 Public Read 허용	민감 데이터 외부 노출
S3 Block Public Access 비활성화	의도치 않은 공개 가능성 증가
보안 그룹 0.0.0.0/0 전체 개방	누구나 SSH/RDP 접속 시도 가능
과도한 IAM 권한 부여	작은 계정 침해가 큰 사고로 확대
CloudTrail 비활성화	사고 발생 후 추적 어려움
암호화 미적용	데이터 탈취 시 정보 보호 어려움
불필요한 Access Key 방치	탈취 시 장기간 악용 가능

5.3 대응 전략

구성 오류를 줄이기 위한 대응 전략은 다음과 같다.

S3 Block Public Access 활성화
보안 그룹에서 관리 포트는 내 IP로 제한
IAM 최소 권한 원칙 적용
AWS Config로 리소스 설정 변경 추적
Security Hub로 보안 점검 결과 통합
CloudTrail로 API 호출 기록 저장
주기적인 권한 검토
태그와 계정 구조를 활용한 리소스 관리

구성 오류는 사람이 실수할 수 있다는 전제를 두고 관리해야 한다. 따라서 한 번 설정하고 끝내는 것이 아니라, Config, CloudTrail, Security Hub, GuardDuty 같은 도구를 통해 지속적으로 감시하는 구조가 필요하다.

6. 데이터 유출(Data Leakage/Breach)

6.1 개념

데이터 유출(Data Leakage/Breach)은 클라우드에 저장된 민감한 데이터가 외부로 노출되는 사고이다. S3 버킷 공개, 잘못된 ACL, 과도한 IAM 권한, 취약한 애플리케이션, 내부자 실수 등 다양한 원인으로 발생할 수 있다.

클라우드 환경에서 데이터 유출이 위험한 이유는 저장소가 인터넷과 쉽게 연결될 수 있고, 권한 설정 하나로 대량의 데이터가 외부에 노출될 수 있기 때문이다.

6.2 주요 원인

데이터 유출의 주요 원인은 다음과 같다.

S3 버킷 공개 설정
잘못된 ACL 또는 버킷 정책
IAM 권한 과다 부여
암호화 미적용
취약한 애플리케이션
내부자의 실수
로그 및 모니터링 부재
데이터 분류 체계 미흡

6.3 대응 전략

데이터 유출을 예방하기 위한 대응 전략은 다음과 같다.

대응 전략설명

S3 Block Public Access	의도치 않은 퍼블릭 공개 방지
서버 측 암호화	S3, EBS, RDS 데이터 암호화
IAM 최소 권한	필요한 사용자에게만 데이터 접근 허용
S3 Access Analyzer	외부 공개 가능성 분석
CloudTrail Data Events	S3 객체 수준 접근 추적
Macie 활용	민감 데이터 탐지 및 분류
버킷 정책 점검	Principal, Action, Resource 범위 확인
접근 로그 수집	누가 어떤 객체에 접근했는지 기록

특히 S3는 편리한 객체 스토리지이지만, 퍼블릭 접근 설정을 잘못하면 대규모 데이터 유출로 이어질 수 있다. 따라서 공개용 웹 리소스와 민감 데이터 저장소를 명확히 분리하고, 민감 데이터 버킷은 기본적으로 비공개 상태를 유지해야 한다.

7. 악의적 내부자(Malicious Insiders)

7.1 개념

악의적 내부자(Malicious Insiders)는 클라우드 서비스를 이용하는 조직 내부의 사용자가 의도적으로 또는 부주의하게 리소스를 악용하거나 데이터를 유출하는 경우를 의미한다.

내부자는 정상적인 계정과 권한을 가지고 있기 때문에 외부 공격자보다 탐지하기 어려울 수 있다. 특히 과도한 IAM 권한이 부여되어 있으면 내부자의 실수나 악의적 행동이 큰 사고로 이어질 수 있다.

7.2 위험 시나리오

악의적 내부자 또는 내부 실수로 인한 위험 시나리오는 다음과 같다.

직원이 고객 데이터가 담긴 S3 객체를 무단 다운로드
퇴사자가 Access Key를 계속 사용
개발자가 운영 DB에 직접 접근
관리자가 실수로 중요한 EC2 또는 RDS 삭제
불필요한 AdministratorAccess 부여
특정 사용자가 CloudTrail 로그 삭제 시도

7.3 대응 전략

내부자 위협에 대응하기 위한 전략은 다음과 같다.

최소 권한 원칙 적용
업무별 IAM Role 분리
중요 작업에는 MFA 요구
CloudTrail 로그 감시
GuardDuty Findings 확인
EventBridge와 SNS를 통한 이상 이벤트 알림
IAM Access Analyzer로 외부 접근 및 과도 권한 점검
퇴사자 및 미사용 계정 정리
권한 변경 이력 주기적 검토

내부자 위협 대응의 핵심은 “신뢰하지 않는다”가 아니라, 정상 사용자의 행동도 기록하고 검토할 수 있도록 하는 것이다. 즉, 권한은 최소화하고, 모든 중요한 작업은 로그로 남겨 추적 가능해야 한다.

8. 서비스 거부 공격(DoS/DDoS)

8.1 개념

서비스 거부 공격(DoS/DDoS)은 대규모 트래픽을 유입시켜 정상 사용자가 서비스를 이용하지 못하게 만드는 공격이다. 클라우드 환경에서는 인터넷에 직접 노출된 리소스가 공격 대상이 될 수 있다.

예를 들어 웹 서버, ALB, API Gateway, CloudFront 배포, 공개 API 등이 과도한 요청을 받으면 서비스 성능이 저하되거나 정상 응답이 어려워질 수 있다.

8.2 대응 전략

DoS/DDoS 공격에 대응하기 위한 AWS 서비스와 전략은 다음과 같다.

대응 방법설명

AWS Shield	DDoS 방어 서비스
AWS WAF Rate-based Rule	일정 요청 수를 넘는 IP 차단 또는 제한
CloudFront	글로벌 엣지 캐싱으로 원본 서버 부하 완화
ALB 분산	여러 서버로 요청 분산
Auto Scaling	트래픽 증가 시 인스턴스 자동 확장
CloudWatch Alarm	비정상 트래픽 증가 알림
보안 그룹 제한	불필요한 포트 차단

WAF의 Rate-based Rule은 특정 IP에서 일정 시간 동안 과도한 요청이 발생할 경우 자동으로 제한할 수 있어, 웹 계층의 간단한 DoS 완화에 유용하다.

9. 안전하지 않은 인터페이스/API

9.1 개념

AWS 클라우드 서비스는 대부분 API를 통해 접근하고 제어된다. 콘솔에서 버튼을 클릭하는 작업도 내부적으로는 API 호출로 처리되며, CLI와 SDK도 API 호출 기반으로 동작한다. 따라서 API는 클라우드 리소스의 “문”이자 “열쇠” 역할을 한다.

안전하지 않은 인터페이스/API는 인증, 인가, 입력 검증, 암호화, 로깅이 부족한 API를 의미한다. 이러한 API는 무단 접근, 권한 오용, Injection, 중간자 공격, 대량 요청 공격으로 이어질 수 있다.

9.2 주요 위험 시나리오

위험 시나리오설명

인증 우회	API Key 노출 또는 인증 검증 부족으로 무단 호출
권한 오용	API에 과도한 관리 권한 부여
입력 검증 부족	SQL Injection, Command Injection 발생 가능
암호화 미적용	HTTP 전송 시 중간자 공격 가능
Rate Limiting 미비	대량 요청에 의한 DoS 가능
로그 부재	이상 행위 발생 후 추적 어려움

9.3 대응 전략

안전한 API 운영을 위해서는 다음 전략이 필요하다.

API Gateway 인증 및 권한 설정
IAM Role 기반 권한 부여
최소 권한 원칙 적용
HTTPS 사용
입력값 검증
WAF 적용
Rate Limiting 또는 Throttling 설정
CloudWatch Logs 수집
CloudTrail로 API 호출 추적
GuardDuty로 의심 활동 탐지

API 보안은 애플리케이션 개발과 클라우드 운영이 함께 관리해야 하는 영역이다. API가 외부에 노출될수록 인증, 권한, 입력 검증, 로깅이 중요해진다.

10. 기본 보안 대응 전략

13주차 자료에서는 위협 유형을 이해하는 것뿐만 아니라, 실무에서 적용할 수 있는 기본 보안 대응 전략도 중요하게 다루었다.

클라우드 보안 대응은 크게 다음과 같이 정리할 수 있다.

보안 전략설명

최소 권한 원칙	사용자와 역할에 필요한 최소 권한만 부여
MFA 적용	루트 계정과 중요 계정에 다단계 인증 적용
S3 공개 차단	Block Public Access로 의도치 않은 공개 방지
네트워크 접근 제한	보안 그룹과 NACL로 필요한 포트만 허용
암호화	저장 데이터와 전송 데이터 보호
로그 수집	CloudTrail, CloudWatch Logs로 활동 기록
위협 탐지	GuardDuty로 이상 활동 탐지
설정 점검	AWS Config, Security Hub로 구성 오류 확인
자동 대응	EventBridge, Lambda, SNS로 알림 및 조치 자동화
정기 점검	IAM 권한, Access Key, S3 정책 주기 검토

보안은 한 번 설정하고 끝나는 것이 아니라 지속적인 점검과 개선이 필요하다. 특히 클라우드에서는 리소스가 빠르게 생성되고 삭제되므로, 자동화된 탐지와 알림이 중요하다.

11. 사례 1: S3 버킷 공개로 인한 데이터 유출

11.1 사고 개요

첫 번째 실무 보안 사고 사례는 S3 버킷 공개로 인한 데이터 유출이다. S3 버킷은 기본적으로 안전하게 비공개 상태를 유지하는 것이 원칙이다. 그러나 사용자가 버킷 정책이나 ACL을 잘못 설정하거나, Block Public Access를 비활성화하면 외부 사용자가 버킷 내 객체에 접근할 수 있다.

S3는 정적 웹사이트 호스팅에도 사용되기 때문에, 공개가 필요한 버킷과 민감 데이터를 저장하는 비공개 버킷을 명확히 구분해야 한다. 실습이나 개발 과정에서 임시로 퍼블릭 접근을 허용한 뒤 다시 닫지 않으면 사고로 이어질 수 있다.

11.2 원인 분석

S3 버킷 공개 사고의 주요 원인은 다음과 같다.

원인설명

Block Public Access 비활성화	퍼블릭 정책이 적용될 수 있는 상태
Public Read 허용	누구나 객체를 읽을 수 있음
잘못된 버킷 정책	Principal *에 과도한 권한 부여
ACL 설정 오류	객체 단위 공개 권한 부여
접근 로그 미수집	누가 접근했는지 추적 어려움
IAM 권한 과다	필요 이상으로 S3 정책 수정 권한 부여

예를 들어 다음과 같은 버킷 정책은 모든 사용자가 객체를 읽을 수 있도록 허용한다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadExample",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

정적 웹사이트 호스팅에는 이러한 공개 읽기 정책이 필요할 수 있지만, 개인정보나 과제 자료, 로그 파일, 백업 파일이 들어 있는 버킷에는 절대 적용해서는 안 된다.

11.3 대응 및 예방

S3 버킷 공개 사고를 예방하기 위한 방법은 다음과 같다.

S3 Block Public Access 활성화
공개용 버킷과 비공개 버킷 분리
버킷 정책에서 Principal: "*" 사용 여부 점검
S3 Access Analyzer로 외부 공개 가능성 확인
서버 측 암호화 적용
CloudTrail로 버킷 정책 변경 추적
S3 서버 액세스 로그 또는 CloudTrail Data Events 활성화
IAM 최소 권한 적용
불필요한 ACL 사용 지양

11.4 실습 기록: S3 공개 설정 점검

이번 실습에서는 S3 버킷의 퍼블릭 접근 설정을 확인하고, 의도치 않은 공개가 발생하지 않도록 점검하는 과정을 정리했다.

실습 단계 1: S3 버킷 권한 탭 확인

S3 콘솔에서 실습용 버킷을 선택하고, 권한 탭에서 퍼블릭 액세스 차단 상태를 확인했다.

실습 단계 2: 버킷 정책 확인

버킷 정책에 Principal: "*" 또는 Action: "s3:*"처럼 과도한 권한이 포함되어 있지 않은지 확인했다.

실습 단계 3: Access Analyzer 확인

S3 Access Analyzer 또는 IAM Access Analyzer를 통해 외부 계정이나 인터넷에 공개된 리소스가 있는지 확인했다.

실습 단계 4: CloudTrail에서 정책 변경 추적

CloudTrail Event History에서 PutBucketPolicy, DeleteBucketPolicy, PutPublicAccessBlock 같은 이벤트를 검색하여 누가 S3 정책을 변경했는지 확인할 수 있음을 학습했다.

11.5 실습 중 문제점 및 해결 방안

문제점

S3 정적 웹사이트 실습을 하면서 공개가 필요한 버킷과 민감 데이터를 저장하는 버킷의 보안 기준을 혼동할 수 있었다. 정적 웹사이트 호스팅에서는 외부 사용자가 index.html을 읽을 수 있어야 하지만, 일반 데이터 저장용 버킷에서는 퍼블릭 접근을 막아야 한다.

해결 방안

버킷의 목적에 따라 접근 정책을 분리해서 이해했다.

버킷 유형권장 설정

정적 웹사이트 공개 버킷	필요한 객체에만 읽기 권한 부여
민감 데이터 저장 버킷	Block Public Access 활성화
로그 저장 버킷	외부 공개 금지, 쓰기 주체 제한
백업 버킷	암호화 적용, 제한된 IAM Role만 접근

이 과정을 통해 S3 보안에서는 “퍼블릭 접근이 가능한가?”만 보는 것이 아니라, 버킷의 목적에 맞는 공개 범위인지를 확인해야 한다는 점을 배웠다.

12. 사례 2: 루트 계정 탈취 시나리오

12.1 사고 개요

두 번째 사례는 루트 계정 탈취이다. AWS 루트 계정은 계정의 모든 권한을 가진 최상위 계정이다. 따라서 루트 계정이 탈취되면 공격자는 결제 정보, IAM 설정, 리소스 삭제, Access Key 생성 등 매우 위험한 작업을 수행할 수 있다.

루트 계정은 일반적인 실습이나 개발 작업에 사용해서는 안 되며, 반드시 MFA를 적용하고 비상용으로만 사용하는 것이 좋다.

12.2 주요 원인

루트 계정 탈취의 주요 원인은 다음과 같다.

루트 계정에 MFA 미설정
약한 비밀번호 사용
피싱 사이트에 로그인 정보 입력
루트 계정 Access Key 생성
결제 및 계정 관리 외 작업에 루트 계정 사용
이메일 계정 보안 취약
비밀번호 재사용

12.3 피해 결과

루트 계정이 탈취되면 다음과 같은 피해가 발생할 수 있다.

피해설명

전체 리소스 제어	EC2, S3, RDS 등 모든 리소스 조작 가능
IAM 권한 변경	공격자가 새 관리자 계정 생성 가능
데이터 삭제	중요 데이터 및 백업 삭제 가능
비용 폭탄	고사양 EC2 대량 생성 가능
보안 로그 조작	CloudTrail 설정 변경 시도
계정 복구 어려움	루트 이메일과 MFA까지 탈취되면 복구 복잡

12.4 대응 및 예방

루트 계정 보호를 위한 기본 전략은 다음과 같다.

루트 계정 MFA 필수 설정
루트 계정 Access Key 생성 금지
일상 작업은 IAM 사용자 또는 IAM Role 사용
강력한 비밀번호 사용
계정 이메일 보안 강화
CloudTrail에서 루트 로그인 이벤트 감시
루트 계정 사용 시 SNS 또는 EventBridge 알림 설정
AWS Budgets로 비용 이상 징후 감시

12.5 실습 기록: 루트 계정 보호 점검

실습 단계 1: 루트 계정 MFA 상태 확인

AWS 콘솔의 보안 자격 증명 메뉴에서 루트 계정 MFA 설정 여부를 확인했다.

실습 단계 2: 루트 Access Key 존재 여부 확인

루트 계정의 Access Key가 존재하는지 확인하고, 가능하면 생성하지 않는 것이 안전하다는 점을 정리했다.

실습 단계 3: CloudTrail에서 루트 계정 이벤트 확인

CloudTrail Event History에서 루트 계정 로그인 또는 민감 작업 이벤트를 확인할 수 있음을 학습했다. 루트 계정 활동은 반드시 추적 가능해야 하며, 필요하면 EventBridge와 SNS를 통해 알림을 받을 수 있다.

12.6 실습 중 문제점 및 해결 방안

문제점

처음에는 루트 계정이 모든 권한을 가지고 있으므로 실습할 때 편하다고 생각했다. 그러나 루트 계정을 자주 사용하면 계정 탈취 시 피해 범위가 너무 커진다는 문제가 있다.

해결 방안

루트 계정은 계정 관리, 결제 설정, Organizations 초기 구성처럼 꼭 필요한 경우에만 사용하고, 일반적인 EC2, S3, IAM 실습은 별도의 IAM 사용자로 수행하는 방식으로 정리했다. 또한 루트 계정에는 MFA를 설정하고, Access Key는 만들지 않는 것이 안전하다는 점을 확인했다.

13. 사례 3: 과도한 IAM 권한으로 인한 내부 위협

13.1 사고 개요

세 번째 사례는 과도한 IAM 권한으로 인한 내부 위협이다. IAM은 AWS 보안의 핵심 서비스이지만, 권한을 너무 넓게 부여하면 내부자의 실수나 악의적 행동이 큰 사고로 이어질 수 있다.

예를 들어 개발자에게 업무상 S3 읽기 권한만 필요함에도 AdministratorAccess를 부여하면, 해당 사용자는 EC2 삭제, IAM 정책 변경, S3 버킷 공개, RDS 삭제 등 거의 모든 작업을 수행할 수 있다. 이 경우 계정 탈취나 내부 실수의 피해 범위가 매우 커진다.

13.2 주요 원인

과도한 IAM 권한이 발생하는 원인은 다음과 같다.

편의상 AdministratorAccess 부여
Action: "*" 남용
Resource: "*" 남용
사용자별 권한 검토 부족
오래된 IAM 사용자 방치
사용하지 않는 Access Key 방치
개발/운영 환경 권한 미분리
Role 대신 장기 Access Key 사용

13.3 위험 결과

과도한 IAM 권한은 다음과 같은 위험을 만든다.

위험설명

실수로 인한 리소스 삭제	운영 EC2, RDS, S3 삭제 가능
데이터 유출	필요 이상의 S3, RDS 접근 가능
권한 상승	IAM 정책 변경을 통해 더 큰 권한 획득
비용 증가	불필요한 리소스 생성 가능
내부자 위협 확대	권한 있는 사용자의 악의적 행동 탐지 어려움
사고 영향 범위 확대	작은 계정 침해가 전체 계정 사고로 확대

13.4 대응 및 예방

과도한 IAM 권한을 줄이기 위한 대응 전략은 다음과 같다.

최소 권한 원칙 적용
사용자 대신 Role 기반 접근 활용
업무별 그룹과 정책 분리
AdministratorAccess 사용 최소화
IAM Access Analyzer 활용
CloudTrail로 권한 사용 기록 추적
미사용 사용자와 Access Key 정리
정기적인 권한 검토
AWS Organizations와 SCP로 계정 단위 제한 적용

13.5 실습 기록: IAM 권한 점검

실습 단계 1: IAM 사용자 권한 확인

IAM 콘솔에서 사용자를 선택하고, 연결된 정책을 확인했다. 특정 사용자에게 과도한 관리 권한이 연결되어 있지 않은지 점검했다.

실습 단계 2: 최소 권한 정책 적용

S3 읽기만 필요한 사용자에게는 전체 관리자 권한이 아니라 AmazonS3ReadOnlyAccess 또는 특정 버킷에 대한 읽기 전용 커스텀 정책을 적용하는 것이 적절하다.

예시 정책은 다음과 같다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadOnlySpecificBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::example-bucket",
        "arn:aws:s3:::example-bucket/*"
      ]
    }
  ]
}

실습 단계 3: IAM Access Analyzer 확인

IAM Access Analyzer를 통해 외부 계정에 공개된 리소스나 과도한 접근 가능성이 있는 정책을 점검할 수 있음을 확인했다.

실습 단계 4: CloudTrail에서 IAM 변경 이벤트 확인

CloudTrail에서 AttachUserPolicy, PutUserPolicy, CreateAccessKey, DeleteAccessKey 같은 이벤트를 검색하여 IAM 권한 변경 내역을 추적할 수 있음을 확인했다.

13.6 실습 중 문제점 및 해결 방안

문제점

IAM 정책을 작성할 때 Action과 Resource를 너무 넓게 설정하면 편리하지만 보안상 위험하다는 점을 처음에는 놓칠 수 있었다. 특히 s3:*, Resource: "*"와 같은 설정은 실습에서는 편해 보이지만 실제 운영 환경에서는 위험하다.

해결 방안

정책을 작성할 때 다음 기준을 적용했다.

점검 항목확인 내용

Action 범위	필요한 API만 허용했는가?
Resource 범위	특정 리소스로 제한했는가?
Principal 범위	불특정 다수에게 열려 있지 않은가?
사용 목적	업무에 필요한 권한인가?
기간	임시 권한으로 대체 가능한가?
로그	CloudTrail로 추적 가능한가?

이 과정을 통해 IAM 정책은 “잘 동작하는가”뿐만 아니라, “필요 이상으로 열려 있지 않은가”를 함께 봐야 한다는 점을 배웠다.

14. 보안 실무 대응 흐름

13주차 내용을 바탕으로 보안 사고 대응 흐름을 정리하면 다음과 같다.

1. 예방
   - MFA 적용
   - 최소 권한 원칙
   - S3 Block Public Access
   - 보안 그룹 제한
   - 암호화 적용

2. 탐지
   - CloudTrail API 로그 확인
   - GuardDuty Findings 확인
   - CloudWatch Alarm 확인
   - Security Hub 보안 결과 확인

3. 대응
   - 노출된 Access Key 비활성화
   - 과도한 IAM 권한 제거
   - S3 퍼블릭 정책 수정
   - 보안 그룹 규칙 제한
   - 의심 인스턴스 격리

4. 복구 및 개선
   - 피해 범위 분석
   - 로그 보존
   - 정책 재설계
   - 자동 알림 구성
   - 재발 방지 체크리스트 작성

보안 사고 대응에서 중요한 점은 사고가 발생한 뒤에만 움직이는 것이 아니라, 사전에 탐지와 알림 체계를 만들어두는 것이다. CloudTrail, GuardDuty, Security Hub, Config, EventBridge, SNS를 함께 활용하면 보안 이벤트를 더 빠르게 발견하고 대응할 수 있다.

15. 보안 점검 실습 체크리스트

이번 주차 내용을 바탕으로 실습 계정에서 점검할 수 있는 항목을 정리했다.

점검 영역확인 항목

루트 계정	MFA 설정 여부, Access Key 존재 여부
IAM	AdministratorAccess 남용 여부, 미사용 사용자 여부
Access Key	오래된 키, 사용하지 않는 키, 외부 노출 가능성
S3	Block Public Access 활성화 여부
S3 정책	Principal * 사용 여부, Public Read 허용 여부
보안 그룹	22, 3389 포트가 0.0.0.0/0으로 열려 있는지
CloudTrail	Event History 확인, Trail 활성화 여부
GuardDuty	Findings 확인, 샘플 Findings 생성 가능 여부
Config	리소스 설정 변경 추적 가능 여부
Security Hub	보안 기준 점검 결과 확인
Budget	예상치 못한 비용 증가 알림 설정 여부

이 체크리스트는 실제 보안 실습 수행 여부를 보여주기에도 좋다. 각 항목별로 캡처를 남기면 블로그 과제에서 “실습 과정의 상세 기록”을 보여줄 수 있다.

16. 기존 학습 내용과의 연결

13주차 보안 사례 분석은 이전에 학습한 여러 AWS 서비스와 직접 연결된다.

기존 학습 내용13주차와의 연결

IAM	과도한 권한, 최소 권한 원칙, Role 기반 접근
S3	버킷 공개, Block Public Access, 암호화
VPC	보안 그룹, NACL, 네트워크 접근 제한
CloudTrail	API 호출 추적, 보안 사고 분석
CloudWatch	이상 지표 모니터링, 알람
GuardDuty	계정 도용, 악성 통신, 이상 API 탐지
WAF	웹 공격, Rate-based Rule, DDoS 완화
Security Hub	보안 점검 결과 통합
AWS Config	설정 변경 추적과 규정 준수 점검
Organizations/SCP	계정 단위 권한 제한

즉, 13주차는 새로운 서비스를 단순히 배우는 주차라기보다, 지금까지 배운 보안 관련 기능들을 실제 사고 사례에 연결하여 “어떤 상황에서 어떤 서비스를 써야 하는가”를 이해하는 주차라고 볼 수 있다.

17. 13주차 학습 정리

이번 13주차 학습을 통해 클라우드 보안 사고의 상당수는 복잡한 해킹 기술보다 잘못된 설정, 과도한 권한, 자격 증명 관리 부주의, 로그 부재에서 시작될 수 있다는 점을 이해했다.

핵심 내용을 정리하면 다음과 같다.

핵심 개념정리

계정 도용	탈취된 계정이나 Access Key로 리소스를 악용하는 공격
구성 오류	S3 공개, 보안 그룹 전체 개방, CloudTrail 비활성화 등 설정 실수
데이터 유출	민감 데이터가 외부로 노출되는 사고
내부자 위협	권한을 가진 사용자의 실수 또는 악의적 행동
DDoS	대규모 트래픽으로 서비스 장애를 유발하는 공격
Unsafe API	인증, 권한, 입력 검증, 암호화가 부족한 API
MFA	계정 탈취 방지를 위한 필수 보안 설정
최소 권한	필요한 권한만 부여하여 사고 영향 범위 축소
S3 Block Public Access	의도치 않은 S3 공개 방지
CloudTrail	누가 어떤 작업을 했는지 추적
GuardDuty	이상 행위와 위협 탐지
Security Hub/Config	보안 설정 점검과 규정 준수 확인

18. 학습 후기

이번 13주차 학습을 통해 클라우드 보안은 단순히 보안 서비스를 켜는 것이 아니라, 실제 사고가 발생하는 원인을 이해하고 그에 맞는 예방·탐지·대응 체계를 구성하는 과정이라는 점을 알게 되었다.

특히 S3 버킷 공개 사고는 이전 S3 실습과 직접 연결되어 이해하기 쉬웠다. 정적 웹사이트 호스팅을 위해 일부 객체를 공개하는 것과, 민감 데이터가 들어 있는 버킷을 퍼블릭으로 여는 것은 완전히 다르다. 이번 주차를 통해 S3 버킷을 만들 때는 항상 Block Public Access 설정, 버킷 정책, ACL, 암호화, 접근 로그를 함께 확인해야 한다는 점을 배웠다.

루트 계정 탈취 시나리오도 중요하게 느껴졌다. 루트 계정은 모든 권한을 가지고 있기 때문에 편리하지만, 그만큼 탈취되었을 때의 피해가 매우 크다. 따라서 루트 계정에는 반드시 MFA를 설정하고, 일상적인 작업은 IAM 사용자나 역할을 통해 수행하는 것이 안전하다. 또한 루트 계정 Access Key는 만들지 않는 것이 좋고, CloudTrail을 통해 루트 계정 사용 여부를 추적할 필요가 있다.

과도한 IAM 권한 사례를 보면서 최소 권한 원칙의 중요성도 다시 확인했다. 실습에서는 편의를 위해 넓은 권한을 주고 싶은 경우가 있지만, 실제 운영 환경에서는 사용자가 필요한 작업만 수행할 수 있도록 권한을 제한해야 한다. 특히 AdministratorAccess, Action: "*", Resource: "*" 같은 설정은 반드시 필요한 경우가 아니라면 피해야 한다.

이번 주차에서 가장 중요하게 느낀 점은 보안 사고를 완전히 없애기는 어렵지만, 사고의 가능성과 피해 범위를 줄일 수는 있다는 것이다. MFA, 최소 권한, S3 공개 차단, 보안 그룹 제한, CloudTrail 로그, GuardDuty 탐지, Security Hub 점검을 함께 적용하면 실수나 공격이 발생하더라도 더 빠르게 발견하고 대응할 수 있다.

앞으로 AWS 기반 서비스를 설계할 때는 리소스를 생성하는 것뿐만 아니라, 해당 리소스가 외부에 과도하게 노출되어 있지는 않은지, 누가 접근할 수 있는지, 로그가 남는지, 이상 행위를 탐지할 수 있는지까지 함께 점검하는 습관을 가지려고 한다.

LIST

저작자표시 비영리 변경금지 (새창열림)

'공부 > 클라우드 활용' 카테고리의 다른 글

[클라우드 활용 포트폴리오] 디지털 전환 사례와 AWS 서버리스 활용 전략 (0)	2026.06.22
[클라우드 활용 포트폴리오] 멀티 AZ와 ELB를 활용한 고가용성 및 장애 복구 설계 (1)	2026.06.22
[클라우드 활용 포트폴리오] AWS Organizations와 SCP를 활용한 계정 구조 및 조직 관리 (1)	2026.06.22
[클라우드 활용 포트폴리오] CloudWatch와 CloudTrail을 활용한 모니터링 및 사용자 활동 추적 (0)	2026.06.22
[클라우드 활용 포트폴리오] AWS 아키텍처 기초 설계 실습 (0)	2026.06.22

현재글[클라우드 활용 포트폴리오] AWS 클라우드 보안 실무 사례 분석과 대응 전략

코딩장이

학교에서 배우는 교과목들과 제가 개발하면서 알게된 점, 알고리즘 공부하는것들을 올릴 예정입니다.

AWS, 클라우드 활용, 프로그래밍, 선형대수학, 10828, cloudwatch, cpp, Cloudtrail, 메모리 구조, 조합, 벡터, 백준, 내적, EC2, C언어, 자료구조론, 선형대수, Stack, 확률론, 자료구조,

Today :
Yesterday :

« 2026/07 »
일	월	화	수	목	금	토
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31