이 글은 gasida님의 스터디 AHSS1기의 내용 및 실습으로 작성된 글입니다.
IAM(Identity and Access Management)
- What? AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스
- Can access? 액세스할 수 있는 AWS 리소스를 제어하는 권한을 중앙에서 관리
- Who? 리소스를 사용하도록 인증(로그인) 및 권한 부여(권한 있음)된 대상을 제어
IAM 작동 방식
1. 실제 사용자나 애플리케이션이 AWS를 통해 로그인 보안 인증을 사용하여 인증
2. AWS 계정에서 신뢰하는 보안 주체(IAM 사용자, 페더레이션 사용자, IAM 역할 또는 애플리케이션)와 로그인 보안 인증 정보를
일치시키는 방식
3. 보안 주체에게 리소스 액세스 권한을 부여하도록 요청
4. 권한 부여 요청에 따른 응답으로 액세스 권한 부여
5. 인증된 후에 보안 주체가 AWS 계정에서 리소스에 조치하거나 작업 등 액션을 할 수 있음 (ex. EC2 재부팅, S3 삭제 등)
IAM 정책 및 권한
- 정책을 생성하고 IAM 자격 증명(사용자, 사용자 그룹 또는 역할) 또는 AWS 리소스에 연결하여 AWS에서 액세스를 관리
- AWS는 IAM 보안 주체(사용자 또는 역할)가 요청을 보낼 때 이러한 정책을 평가하며 정책에서 허용/거부를 결정
- 대부분 정책은 JSON 문서로 저장
1. 자격 증명 기반 정책
- 어떤 작업을 어느 리소스에서 어떤 조건에서 수행할 수 있는지를 제어하는 JSON 권한 정책 문서
- 관리형 정책과 인라인 정책이 있음
2. 리소스 기반 정책
- Amazon S3 버킷과 같은 리소스에 연결하는 JSON 정책 문서
- 지정된 보안 주체에 해당 리소스에 대한 특정 작업을 수행할 수 있는 권한을 부여하고 이러한 권한이 적용되는 조건을 정의
- IAM 서비스는 역할 신뢰 정책이라고 하는 리소스 기반 정책 유형 하나만 지원
3. IAM 권한 경계
- 권한 경계는 자격 증명 기반 정책을 통해 IAM 엔터티에 부여할 수 있는 최대 권한을 설정하는 고급 기능
- 사용자나 역할을 보안 주체로 지정하는 리소스 기반 정책은 권한 경계에 제한을 받지 않음
4. 서비스 제어 정책(SCP)
- AWS Organizations는 기업이 소유하는 AWS 계정을 그룹화하고 중앙에서 관리할 수 있는 서비스
- SCP는 조직 또는 조직 단위(OU)에 최대 권한을 지정하는 JSON 정책
- 각 AWS 계정 루트 사용자를 비롯하여 멤버 계정의 엔터티에 대한 권한을 제한
5. ACL(액세스 제어 목록)
- 리소스에 액세스할 수 있는 다른 계정의 보안 주체를 제어할 수 있는 서비스 정책
- JSON 정책 문서 형식을 사용하지 않은 유일한 정책 유형
- Amazon S3, AWS WAF 및 Amazon VPC는 ACL을 지원하는 대표적인 서비스
6. 세션 정책
- 역할 또는 페더레이션 사용자에 대해 임시 세션을 프로그래밍 방식으로 생성할 때 파라미터로 전달하는 고급 정책
정책 평가 로직
- 보안 주체가 AWS로 요청을 보내 보안 주체의 엔터티와 동일한 계정에 있는 리소스에 액세스한다고 가정
- AWS에서는 요청된 컨텍스트에 적용될 수 있는 모든 정책을 평가
- 기본적으로 모든 요청은 암시적으로 거부가 되는데 전체 접근 권한이 있는 Root 사용자는 예외처리
1. Deny Evaluation
- AWS 적용 코드는 해당 요청에 적용될 수 있는 계정 내의 모든 정책을 평가
- AWS Organizations SCP, 리소스 기반 정책, 자격 증명 기반 정책, IAM 권한 경계 및 세션 정책이 포함
- 적용되는 명시적 거부가 하나라도 발견되면 이 적용 코드는 최종 거부 결정을 반환하며, 명시적 거부가 없을 시 계속 적용 코드 평가 진행
2. Organization SCPs
- 적용 코드가 요청에 적용되는 AWS Organizations 서비스 제어 정책(SCP)을 평가
- 적용 가능한 Allow 문이 SCP에 없는 경우 거부가 암시적이더라도 요청이 명시적으로 거부되고, 적용코드가 최종 거부로 반환
- SCP가 없거나 요청한 작업이 SCP에서 허용된 경우 계속 적용 코드 평가 진행
3. Resource-based policies
- 같은 계정에서 리소스 기반 정책은 접근하는 보안주체의 유형, 리소스 기반 정책에서 허용되는 주체에 따라 정책 평가에 다르게 영향을 줌
- 대부분의 리소스는 접근 권한을 부여하는 자격 증명 기반이나 리소스 기반 정책의 보안 주체에 대한 명시적인 허용이 필요
- IAM 역할 신뢰 정책, KMS 키 정책은 보안 주체에 대한 접근 권한을 명시적으로 허용하여 해당 로직에서 제외
* IAM 역할: ARN에 권한을 부여하는 리소스 기반 정책은 권한 경계나 세션 정책의 암시적 거부로 인해 제한
arn:aws:iam::111122223333:role/examplerole
* IAM 역할 세션: 같은 계정 내에 IAM 역할 세션 ARN에 권한을 부여하는 리소스 기반 정책은 수임된 역할 세션에
직접 권한을 부여
역할을 맡고 요청을 할 때 요청을 수행하는 보안 주체는 역할 자체의 ARN이 아니라 IAM 역할 세션 ARN
arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname
# ARN
- Amazon 리소스 이름(ARN)은 AWS 리소스를 고유하게 식별
ex) Amazon S3에서 리소스 식별자는 슬래시(/)를 포함하여 경로를 구성할 수 있는 객체 이름이며,
IAM 사용자 이름과 그룹 이름에 경로를 포함
- Tag, API 호출과 같은 AWS의 모든 리소스를 지정해야 할 필요가 있는 경우 사용
* IAM 사용자: IAM 사용자 ARN에게 권한을 부여하는 리소스 기반 정책은 자격 증명 기반 정책 또는 권한 경계에서 암시적 거부에
의해 제한되지 않음
arn:aws:iam::111122223333:user/exampleuser
* IAM 페더레이션 사용자 세션: IAM 페더레이션 사용자 세션은 GetFederationToken 호출을 통해 생성된 세션
arn:aws:sts::111122223333:federated-user/exampleuser
4. Identity-based Policies
- 적용 코드는 보안 주체에 대한 자격 증명 기반 정책을 확인
- IAM 사용자의 경우 이러한 정책에는 사용자 정책과 사용자가 속한 그룹의 정책이 포함
- 자격 증명 기반 정책이 없거나 요청된 작업을 허용하는 자격 증명 기반 정책에 대한 설명이 없는 경우,
적용 코드는 최종 Deny(거부) 결정을 반환
5. IAM permission boundaries
- 코드가 보안 주체에 사용되는 IAM 엔터티에 권한 경계가 지정되어 있는지 여부를 확인
- 권한 경계를 설정하는 데 사용되는 정책에서 요청한 작업을 허용하지 않는 경우 요청이 묵시적으로 거부
6. Session Policies
- 코드에서는 그 다음 보안 주체가 세션 보안 주체인지 확인
- 세션 보안 주체에는 IAM 역할 세션 또는 IAM 페더레이션 사용자 세션이 포함
- 보안 주체가 세션 보안 주체가 아닌 경우 적용 코드는 허용 최종 결정을 반환
7. Error
- AWS 적용 코드를 평가하는 도중 오류가 발생할 경우 코드는 예외를 생성한 후 닫음
IAM 액세스
1. AWS Management Console
- IAM 및 AWS 리소스 관리를 위한 브라우저 기반 인터페이스
2. AWS 명령줄 도구
- 시스템 명령줄에서 명령을 실행하여 IAM 및 AWS 작업 수행 가능
3. AWS SDK
- 다양한 프로그래밍 언너 및 플랫폼을 위한 라이브러리, 샘플코드로 구성된 소프트웨어 개발 키드를 제공
- IAM이나 AWS에 프로그래밍 방식으로 액세스 가능
4. IAM 쿼리 API
- 서비스로 직접 HTTPS 요청을 실행할 수 있는 IAM 쿼리 API를 사용하여 프로그래밍 방식으로 접근 가능
- 쿼리 API를 사용할 때는 자격 증명을 사용하여 요청에 디지털 방식으로 서명하는 코드를 포함
IAM 생성
- IAM의 계정이 유출되면 외부인에 노출되는 것이기에 안전하지 않다.
항상 Git hub나 Public한 곳에 노출시키지 말아야 한다!
- 나는 항상 실습이나 과제 등 IAM을 사용하고 나서 항상 삭제하고, 이유는 100% 보안은 없다고 생각하기 때문이다.
1. Identity and Access Management에 접근하여 액세스 관리 사용자를 클릭 후 사용자 생성
2. IAM 사용자 이름 기재
3. 권한 설정에서 '그룹에 사용자 추가' 클릭 후 사용자 그룹에서 이전에 생성한 그룹을 선택
4. 사용자 생성
5. 만들어진 사용자를 클릭하여 액세스 키 생성
- 키를 만들 때 Command Line Interface (CLI) 선택하고 아래 확인 체크 박스 체크
6. 생성된 키 값 저장,
- 나는 CSV 파일로 저장해서 사용하고 있다.
AWS Configure 설정
- 위에서 말한대로 나는 항상 IAM을 사용하고 나면 삭제를 진행한다.
매번 터미널에 Config 설정을 하는게 귀찮지만 혹시라는 마음이 더 커서 매번 새로 생성하고 있다!
aws configure list 명령어를 사용하면 key를 확인할 수 있다.
이전에 사용한 IAM 키가 터미널에 설정되어있을 때 나는 .aws 디렉터리를 삭제한다!
(Command: rm -r .aws)
위에서 만든 IAM Key 값을 아래와 같이 터미널에서 aws configure 명령어를 사용 후 적용한다!
AWS IAM 기초 실습 (1)
▶ Local PC에서 IAM 자격 증명 설정한 상태로 Stack 배포
- gasida 님께서 제공해주신 yaml 및 Stack으로 배포 진행
# KEYNAME 변수 지정
KEYNAME=<SSH Keypair NAME>
# EC2 IP 확인
aws cloudformation describe-stacks --stack-name iamlab --query 'Stacks[*].Outputs[*].OutputValue' --output text
- Stack 생성완료 후, EC2 2대에 SSH로 접근
▶ WebShell 접근
- EC2의 Public IP로 Webshell에 접속할 수 있다. → EC2 IMDS 확인
- Webshell 접근 방법
EC2 → 인스턴스 → webserver 클릭 → 퍼블릭 IPv4 주소 Copy → 브라우저 URL 창에 IP 넣어 접근
- 하단의 apach@WebServer:/var/www/html# 이곳에 Command를 입력하면 된다.
# Aws EC2 확인
whoami
pwd
ls -al
cat /etc/passwd
uname -a
hostnamectl
◆ IMDS 정보 확인
ip route
curl -s http://169.254.169.254/latest/meta-data/
curl -s http://169.254.169.254/latest/meta-data/local-ipv4 ; echo
curl -s http://169.254.169.254/latest/meta-data/public-ipv4 ; echo
curl -s http://169.254.169.254/latest/meta-data/iam/
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/IAMLabInstanceRole ; echo
IAMLabInstanceRole curl 로 확인해보니 EC2의 Accesskey, SecretAccesskey, Tocken 등의 정보를 확인할 수 있다.
* Token 이란?
- 서버가 각각의 클라이언트를 구분할 수 있는 암호화 데이터
- 사용자의 정보를 암호화하여 브라우저에 저장하고 웹 페이지 접근 시 저장된 정보로 사용자마다 화면을 보여줌.
★ EC2 Webserver web 액세스 로그 확인
webshell에서 본 EC2의 값과 EC2에서 IAM의 인스턴스 룰은 동일하다.
tail -f /var/log/httpd/access_log
내 EC2에는 외부로부터의 침입시도는 확인되지 않았다.
▶ EC2 Attacker에서 Webserver 자격 증명 사용
# 자격 증명 없이 S3 접근
aws s3 ls
# Webserver의 자격증명 임시 적용
export AWS_ACCESS_KEY_ID="ASIA5ILF2FJIV56CCEH2"
export AWS_SECRET_ACCESS_KEY="NpvNZl5HKOTQLepywvi/XSkKRX07o5Nes8zCSfNL"
export AWS_SESSION_TOKEN="IQoJb3JpZ
S3 조회 시, 아까와 다르게 조회가 가능하다.
EC2 정보를 조회 하려고 했으나, error 문구를 뱉어낸다.
해당 error 문구는 EC2에 대한 권한이 없기 때문에 발생하는 문구로 확인된다.
마지막에 조회한 caller id 에는 Webserver의 인터턴스 ID가 호출된 것을 확인했다.
▶ AWS CloudTrail 에서 인스턴스 ID 값으로 이벤트 확인
- AWS CloudTrail → 이벤트 기록 → 사용자 이름 선택 후 인스턴스 ID 검색
- AWS CloudTrail → 이벤트 기록 → 이벤트 이름 선택 후 AssumeRole 검색
검색 후 이벤트 클릭해서 상세 정보 확인
▶ AWS IAM 관리 콘솔에서 IAM, EC2 정보 확인
- IAM → 역할 → IAMLabInstanceRole
- EC2 → 인스턴스 → 작업 → 인스턴스 설정 → 인스턴스 메타데이터 옵션 수정 → 확인
AWS IAM User 기초 실습
▶ [Local PC] 관리자 수준의 자격증명 환경
# AWS Cli 설치 및 버전 확인
aws --version
# Caller ID 확인
aws sts get-caller-identity
# AWS 계정 ID 변수 지정
export ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text)
echo $ACCOUNT_ID
# Pager 비활성화
export AWS_PAGER=""
▶ IAM User 생성 및 정책 연동
# user1 사용자 생성
aws iam create-user --user-name user1
# user2 사용자 생성
aws iam create-user --user-name user2
# user1 사용자의 AWS Web Console 로그인 profile 생성
cat <<EOF > create-login-profile-user1.json
{
"UserName": "user1",
"Password": "Ahss\$1234",
"PasswordResetRequired": false
}
EOF
cat create-login-profile-user1.json | jq
aws iam create-login-profile --cli-input-json file://create-login-profile-user1.json
# user2 사용자의 AWS Web Console 로그인 profile 생성
cat <<EOF > create-login-profile-user2.json
{
"UserName": "user2",
"Password": "Ahss\$1234",
"PasswordResetRequired": false
}
EOF
cat create-login-profile-user2.json | jq
aws iam create-login-profile --cli-input-json file://create-login-profile-user2.json
# iam 사용자 리스트 확인
aws iam list-users | jq
# 사용자에게 프로그래밍 방식 액세스 권한 부여
aws iam create-access-key --user-name user1
{
"AccessKey": {
"UserName": "user1",
"AccessKeyId": "AKIA5ILF2FJITUNS2S5S",
"Status": "Active",
"SecretAccessKey": "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",
"CreateDate": "2023-09-03T06:21:17+00:00"
}
}
aws iam create-access-key --user-name user2
{
"AccessKey": {
"UserName": "user2",
"AccessKeyId": "AKIA5ILF2FJIR2IDM5VK",
"Status": "Active",
"SecretAccessKey": "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",
"CreateDate": "2023-09-03T06:21:27+00:00"
}
}
# 사용자 정책 추가
aws iam attach-user-policy --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --user-name user1
aws iam attach-user-policy --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess --user-name user2
User1에는 AdminAccess 권한을 User2에는 ReadOnlyAccess 권한을 부여했다.
- AWS → IAM → 사용자 확인 시, User1/2 확인 가능
User1을 클릭해서 권한을 보면 Admin 권한 확인이 된다.
▶ 크롬에 MultiLogin 실행하여 각 User 계정으로 로그인
- 자신의 계정 ID 기재하여 생성한 user1/2로 각각 로그인
★ 각 계정에서 인스턴스 재부팅 시도해보기!
# User1 = Administrator
결과는 User1은 Admin 권한이 있기 때문에 재부팅이 되었다.
# User2 = ReadOnly
결과는 권한이 ReadOnly이기 때문에 재부팅에 실패하고 실패했다는 내용의 메시지가 출력된다.
▶ [EC2 Attacer] AWS CLI 자격 증명 설정
# 자격 증명 설정 전 S3 조회 시도
aws s3 ls
# user1 자격증명 profile 생성
aws configure --profile user1
AWS Access Key ID [None]: AIDAVIBP4QIJBBY6ELRDJ
AWS Secret Access Key [None]: rePWIHIEgreodM6 t2Bg5MaF8W9xkKCwy×8R2yy0r
Default region name [None]: ap-northeast-2
Default output format [None]:
# user2 자격증명 profile 생성
aws configure --profile user2
AWS Access Key ID [None]: AKIAVIBP40IJAFINQSOQ
AWS Secret Access Key [None]: VN95msWDMyhUeR9LX1989e6f3Zhj4TTasykpWNGs
Default region name [None]: ap-northeast-2
Default output format [None]:
# 자격 증명 정보 저장되는 파일 확인
cat ~/.aws/credentials
Attacker에서 S3 조회 시 조회가 되지 않는다.
user1/2의 aws configure 추가
▶ [EC2 Attacer] 추가된 권한으로 시도
# caller id 확인
aws sts get-caller-identity --profile user1 | jq
aws sts get-caller-identity --profile user2 | jq
# 자격증명 사용 확인
aws s3 ls --profile user1
aws s3 ls --profile user2
aws ec2 describe-vpcs --profile user1 | jq
aws ec2 describe-vpcs --profile user2 | jq
# S3 버킷 생성
NICKNAME=hee
aws s3 mb s3://ahss-2w-$NICKNAME --region ap-northeast-2 --profile user1
aws s3 mb s3://ahss-2w-$NICKNAME-2 --region ap-northeast-2 --profile user2
# S3 버킷 조회
aws s3 ls --profile user2
S3 버킷 생성 시, User1은 생성이 되지만 User2는 생성되지 않는 것을 확인할 수 있다.
이것 또한 계정에 추가된 권한으로 인해 user1은 생성 가능하고, user2는 생성이 되지 않는 것으로 보인다.
▶ IAM 임시자격 증명 및 사용
# user2 사용자에 인라인 정책을 추가
# STS 서비스의 AssumeRole Action 허용
cat <<EOF > allow-assume-role.json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "allowassumerole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "*"
}
]
}
EOF
cat allow-assume-role.json | jq
aws iam put-user-policy --user-name user2 --policy-name allow-assume-role --policy-document file://allow-assume-role.json
◆ AmazonS3FullAccess 권한을 가진 IAM Role 생성
export ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text)
cat <<EOF > MyAccount-AssumeRole.json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Principal": {
"AWS": "$ACCOUNT_ID"
},
"Condition": {}
}
]
}
EOF
cat MyAccount-AssumeRole.json | jq
# assume-role-s3full IAM Role 에 AmazonS3FullAccess 정책 적용
aws iam create-role --role-name assume-role-s3full --assume-role-policy-document file://MyAccount-AssumeRole.json --max-session-duration 7200
IAM User2의 권한에 allow-assume-role 생성된 것을 확인할 수 있다!
IAM 역할에도 assume-role-s3full 역할이 생긴 것을 볼 수 있다!
▶ [EC2 Attacker] AssumeRole 을 통해 임시자격증명 요청 및 임시자격증명 실행 및 S3 접속 시도
# AssumeRole 을 통해 임시자격증명 발급
export ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text --profile user2)
aws sts assume-role --role-arn arn:aws:iam::"$ACCOUNT_ID":role/assume-role-s3full --role-session-name HeeS3accessSession --profile user2
# 위에서 출력된 AccessKeyId , SecretAccessKey , SessionToken 으로 임시자격증명 적용
export AWS_ACCESS_KEY_ID="ASIAVIBP4QIJHYBVRWEY"
export AWS_SECRET_ACCESS_KEY="pFbWPyjCTDQZEfSJLJ27smDjsAR056EwBVMkmthj"
export AWS_SESSION_TOKEN="IQoJb3JpZ2luX2VjEM///////////wEaDmFwLW5vcnRoZWFzdC0yIkgwRgIhAI9C/Z7tIHg7twvGii1jO7WAF03iBY6dZgd7ZoHTO/KoAiEA2HqSU5SoxpHtluxPMMjllkZrvH+ltM3/m0sRkBr7HtwqqAIIqP//////////ARAAGgwzNjA4Nzc2ODczMTQiDGdjLfBrswtiNA84Jir8AQVKH2hY1ixKflI46kbNovK11IGGjjV0flVzSMSfEeSDQvqSChXgCmmEfPewXv07tjmMvn7ucKoLw7z4Ot9AT3yMv+L4YmbqujmHxZnz9BUar0XzBa3+FIs2bNnNHAc3TqJyCJJC2dRrwclBegYeKjRnLRX9MSctcBI6h4sLTnRS0IjYjh0fm2uGjmNVi2vMco9vvA/644owibi7YBsglBZsuRQ2UAxlGaPcW7WrdKHkSqAzzXl/GhPC1fciOhr58SdWqvThdL3VkPgO7LrJzYSBw17SVE7XCU8jfqUoJ4gPZraTV5rayXCPGF3OlYV7cjb99Z0ewV/qY4yLTDCT9uynBjqcAaeKDsWebSMMMb8NASKDf2zGt9A9Vp8vm347hmZH+IRX62v9XSP5d68yc1QXL7yqcpA2Ua9OSBerTlScfKiD9s01MkXtU8zv4wd8riZZjDZwtiMo4ePy3tIf5M3zuIvy4kwksieqwtD5PFp7Tj7/c1Yh57/gnSWrwoqBVfWBc7hc+gIsi8u/bCpr34JerNUCiipy8B7CmMq3QHivZQ=="
# caller id 확인
aws sts get-caller-identity | jq
# S3 버킷 생성
NICKNAME=hee
aws s3 mb s3://ahss-2w-$NICKNAME-2 --region ap-northeast-2
# S3 버킷 조회
aws s3 ls
# S3 버킷 삭제
aws s3 rb s3://ahss-2w-$NICKNAME
aws s3 rb s3://ahss-2w-$NICKNAME-2
# (참고) 임시자격증명 제거
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
■ IAM Role 에서 ‘콘솔에서 역할 전환 링크’ 확인
- IAM → 역할 → assume-role-s3full 클릭 → User2 웹에서 URL 붙여넣기 → 역할 전환
■ 역할 전환 후에 S3 버킷 생성해보기
- S3 → 버킷 생성
- 실습 완료 후 버킷하고 다시 전환으로 user2로 원복
※ 실습 후 Stack, IAM User, IAM Role 삭제 필수
'CloudNetaStudy > [Study] AHSS' 카테고리의 다른 글
| [1주차] S3 취약점 및 보안 정리 (0) | 2023.08.28 |
|---|
