이 글은 아래의 책을 읽고 공부 목적으로 작성됨.
칼 길버트, 벤자민 카우딜, 「AWS 침투 테스트」
AWS의 IAM 서비스: 사용자의 계정을 인증하는 여러 방법 제공함. 일반적으로 사용자 계정과 역할의 인증 지원.
- IAM 사용자: 환경에 장기적으로 접근해야 할 때 자격증명을 구성하는 방법 제공.
- 역할: 사용자/서비스/애플리케이션에 임시로 필요한 자격증명을 위임하는 방법 제공.
- AWS IAM 그룹: 자주 사용되는 공통 권한을 사용자 그룹에 부여할 수 있음. 사용자는 최대 10개 그룹에 속할 수 있음.
(1) IAM 사용자, 그룹, 역할과 관련 권한 생성
사용자 생성
- AWS 웹 콘솔에 로그인 후 IAM 서비스 페이지로 이동
- 사용자 추가 버튼 클릭
- 액세스 유형:
- 프로그래밍 방식 액세스: 사용자의 액세스 키 ID와 비밀 액세스 키 생성
- AWS Management Console 액세스: 사용자가 AWS 웹 콘솔을 접근할 암호를 자동 생성하거나 직접 설정 가능 - 사용자 이름 적고 다음 버튼
- 권한 설정 3가지 옵션:
- IAM 그룹에 사용자 추가
- 다른 기존 사용자의 권한 복사
- 기존 IAM 정책을 사용자에게 바로 연결 - 검색 상자에 AmazonEC2FullAccess 입력 후 체크박스에 체크
*해당 정책은 사용자에게 EC2 서비스 + EC2와 자주 사용되는 기타 서비스에 대한 전체 액세스 권한 제공
IAM 정책 2가지 유형:
- AWS가 관리하는 정책: AWS에서 관리하는 사전에 정의된 권한 집합
- 고객이 관리하는 정책: 정책을 사용자 맞춤 설정 가능 - 다음 버튼 - 사용자 추가 버튼
- 액세스 키 ID와 비밀 액세스 키를 조회하거나 다운하는 옵션 제공됨
역할 또는 그룹 생성 시에도 동일한 과정으로 생성.
- 그룹: 그룹 생성 후 IAM 그룹 페이지에서 '그룹에 사용자 추가' 버튼을 클릭하면 새로운 사용자 추가 가능. 사용자가 속한 그룹 및 적용되는 정책 확인하려면 그룹 탭을 클릭
- 역할: 신뢰 관계라는 중요 기능 존재, 이는 역할을 맡을 수 있는 개체와 어떤 조건에서 발생할 수 있는지 등을 명시함.
(2) IAM 정책으로 API 액션과 접근 가능한 자원 제한
IAM 정책: 계정의 사용자, 역할, 그룹이 권한을 위임하는 방법. 권한이 허용/거부, 권한으로 사용/사용불가 자원, 규칙 적용 조건들이 명시된 JSON 문서.
IAM 정책 구조 예제(JSON)
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "MyGeneralEC2Statement"
"Effect": "Allow",
"Action": "ec2:*", "Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:GetUser"
],
"Resource": "arn:aws:iam::123456789012:user/TestUser"
},
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "*",
"Condition":
{
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
- Version 키: 사용된 정책 언어의 버전 명시. 최신 버전을 사용하는 것이 권장됨.
- Statement 키: JSON 오브젝트의 statement 목록. Statement는 각 권한의 개별 선언과 관련된 설정. Sid, Effect, Action, NotAction, Principal, Resource, Condition 키로 구성 가능.
- Sid: 선택적 필드, 정책의 여러 statement를 구분하는 데 도움되도록 사용자가 정한 문자열. 입력 시 읽는 사람의 이해를 도울 수 있음.
- Effect: 필수적 필드, Allow/Deny로 설정 가능. 열거된 AWS 권한이 허용됐는지, 거부됐는지를 선언함.
- Action / NotAction: 둘 중 하나는 필수적, AWS 권한 집합 명시. 거의 NotAction보다 Action이 사용됨. 권한은 [AWS 서비스] : [권한] 형식으로 설정됨.
- Principal: 다른 종류의 IAM 정책에 사용됨. 이 키는 statement가 적용되어야 할 자원을 나타내지만 사용자, 역할, 그룹의 권한 정책에 자동으로 포함됨.
- Resource: 필수적 필드, Action/NotAction에서 명시된 권한들이 어떤 AWS 자원에 적용되는지에 관한 목록.
- Condition: 선택적 필드, 어떤 조건에서 statement가 적용되는지 명시.
공격자 입장: IAM 정책이 동작하는 방법을 이해하는 것 중요.
→ 정책을 분석할 수 있으면 현재 환경에서의 정확한 접근 권한, 허용될 거 같은 특정 API 호출이 접근 거부 오류로 실패하는 원인을 파악 가능하기 때문.
키 분석 시, 공격자가 보고 싶은 구문:
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}위의 구문은 관리자 수준의 권한을 제공함.
- * 문자는 와일드카드이고, AWS와 관련한 모든 권한을 허용함을 의미.
- 자원 역시 와일드카드로 명시됐으므로 타깃 계정의 모든 자원에 대해 API 호출 실행 가능.
인라인 정책: 관리형 정책과는 달리 사용자, 역할, 그룹에 직접 생성 가능. 그러나 보안 모범 사례에서는 인라인 정책 사용X를 권장.
(3) IAM 액세스 키 사용
AWS API 호출
- AWS 명령줄 인터페이스(CLI) 설치:
pip install awscli --upgrade --user - 설치 성공 확인:
aws --version - AWS CLI에 사용자 자격 증명을 추가해 API를 호출하려면, 테스트 프로파일에 자격증명을 저장하도록 함:
aws configure --profile [사용자명] - 액세스 키 ID, 비밀 키 등 값 입력: 앞에서 사용자 생성 시에 표시됐음. 리전 선택, 디폴트 추력 형식=json.
- 해당 프로파일의 자격증명/설정 업데이트하려면 동일한 명령을 다시 실행. 프로파일 이름은 추가하는 키에 따라 적절하게 변경. 자격증명 사용 시 명심할 것은 API 호출 시 올바른 자격증명이 사용되도록 모든 AWS CLI 명령에 --profile [사용자명] 인자를 포함해야 하는 것.
- STS(Security Token Service)에서 제공하는 명령어 GetCallerIdentity API: 모든 AWS 사용자 및 역할에서 호출 가능, IAM 정책으로 거부될 수 없음.
aws sts get-caller-identity --profile [사용자명] - 위 명령 후에 출력에는 사용자 ID, 계정 ID, 현재 사용자의 ARN(Amazon 리소스 이름)이 포함됨.
- 사용자 ID: API의 백엔드에서 사용자를 참조하는 방법.
- 계정 ID: 사용자가 속한 계정의 ID. 이를 획득한 경우, 타깃 계정에 로그를 남기지 않으면서 계정에 존재하는 사용자와 역할을 열거 가능. 이는 사회 공학 기법에 도움됨.
서비스 목록 출력 or 참조하는 방법 확인:
#서비스가 인자로 주어지지 않았으므로 이용 가능한 모든 서비스 출력
aws a
#EC2 서비스를 타깃으로 한 실행 가능한 명령어
aws ec2 a
#설명, 제한, 지원되는 인자 등 AWS 서비스/API에 관해 더 많은 정보를 보려면 help 명령 사용
aws ec2 help
#특정 API에 관한 help
aws ec2 describe-instances help
(4) AWS API 요청 서명
대부분의 API는 AWS 서버로 전송 전 포함하고 있는 일부 데이터 서명이 필요. 이는 API 호출자의 신원 확인, 데이터 변조 방지, 재전송 공격을 막는 등의 이유가 존재.
서명은 5분 동안 유효하기 때문에 5분 이내에 요청을 가로채고 다시 전송한다면 재전송 공격은 가능.
대부분의 경우 AWS CLI, AWS SDK가 자동으로 요청 서명을 처리하므로 신경 쓸 필요X. 그러나 수동으로 API 요청을 서명해야 하는 경우가 존재.
→ AWS SDK가 지원되지 않는 프로그래밍 언어 사용하는 경우 / AWS 서버로 전송되는 요청을 완전하기 제어하기를 원하는 경우
AWS API 요청을 서명 v4로 수동 서명하는 프로세스:
- 표준 요청 생성
- 서명할 문자열 생성
- 문자열의 서명 연산
- HTTP 요청에 서명 추가
자세한 사항은 AWS 문서 확인.
'보안 > 클라우드' 카테고리의 다른 글
| [7장]정찰 - 취약한 S3 버킷 탐색 (0) | 2026.05.28 |
|---|---|
| AWS 환경에서 Athena + Stratus Red Team 사용 (1) | 2026.05.20 |
| [9장~12장] 새 VPC로 기존 아키텍처 마이그레이션 하기 ~ 인스턴스 관리 방법 알아보기 (0) | 2026.05.12 |
| [7장~8장] Route 53과 ACM으로 도메인 연결하기 ~ VPC 사용하기 (0) | 2026.05.05 |
| [4장~6장] RDS 사용하기 ~ DMS 설명 (0) | 2026.04.17 |
