AWS IAM
IAM은 특정 AZ에 한정된 서비스가 아닌 Global service이다.
Root Account: 내가 계정을 처음 만들었을 때의 계정.
모든 권한을 가지고 있다.
이 계정을 공유하거나, 이 계정으로 AWS 서비스들을 직접 사용하는 건 권장되지 않는다.
만약 이 계정을 공유한다면..
- 데이터를 삭제 / 유출 또는 고비용 리소스를 임의로 생성
- 계정 자체에 대한 설정을 변경, 계정 소유자의 접속을 못하게 하고 계정 자체를 탈취할 수도 있음
- 누가 어떤 리소스를 변경하고 삭제했는지 추적할 방법이 없음.
모든 활동은 루트 계정에 의해 수행된 것으로 기록되기 때문
따라서 최소 권한 원칙(권한은 최소로, 필요 이상의 권한을 주지 않는다) 에 따라 작업을 수행하는 데 필요한 최소의 권한만을 주어야 한다.
그럼 직접 사용하지 않고 어떻게 사용할까?
User(사용자), Group(그룹)
User를 생성해서 진행한다.
IAM에서는 User를 생성할 수 있다.
하나의 User는 조직 내에 한 사람에 해당한다.
필요하다면 User들을 Group으로 묶을 수 있다.
- 그룹에는 사용자만 포함시킬 수 있다.
- 그룹 내에 그룹을 포함시킬 수 없다.
- 그룹에 포함되지 않은 사용자도 있을 수 있다.
- 한 사용자는 여러 그룹에 속할 수 있다.
User나 Group는 생성하면 처음엔 아무런 권한도 없는 상태이다.
즉, AWS에서 아무 서비스도 이용할 수도, 볼 수도 없는 상태다.
User이나 Group에 policy를 할당해서, 무언가를 하거나 볼 권한을 줄 수 있다.
이렇게 생성된 User는, 웹 콘솔에서 아이디와 비밀번호로 로그인하거나, 액세스 키를 발급받아 사용할 수 있다.
정책(policy)
특정 리소스에 대한 권한을 정의하는 JSON 형식으로 작성된 텍스트.
정책은 그룹에 연결해줄 수 있으며, 이럴 경우 모든 그룹 내 user에게 적용된다.
user별로 그룹에 속해있지 않아도 inline 정책을 적용해줄 수 있다.
최소 권한 원칙이 적용되어야 한다.
즉 user에게 필요 이상으로 권한을 주어서는 안 된다.
Statement 예시.
정책의 구조를 보면,
- version number(버전): 정책 언어 버전. 보통은 2012-10-17.
- id: 정책을 식별하는 ID. 관리용으로 내가 원하는 문자열을 붙인다. 선택사항이다.
- Statement
정책의 핵심 부분으로. 하나 이상의 개별 statement을 포함하는 Json Array이다.- 개별 Statement의 구성 요소
- Sid: statement ID. 문장의 식별자. 선택 사항.
- Effect(효과):
Allow또는Deny중 하나.
Statement가 나타내는 특정 대상이 특정 리소스에 대한 특정 API에 접근하는 것을 최종적으로 허용할지 거부할지를 나타내는 부분. - Principal: 리소스 기반 정책에서만 사용되며, 이 정책이 적용되는 account/user/role을 나타냄.
- Action: "이 정책은 다음 작업들에 대해 적용된다"는 것을 나타낸다.
즉 정책의 타겟 API. - Resource: 이 Action이 적용되는 대상 target resource들의 list이다.
- Condition: Condition에서 제약 조건을 명시해서 Statement가 해당 조건 하에서만 발효된다고 제한할 수 있다.(선택 사항)
- 개별 Statement의 구성 요소
User 계정 탈취 방지
IAM User(사용자)에 대한 계정 탈취를 방지하는 방법에는 크게 두 가지가 있다.
1. 비밀번호 정책
다양한 정책으로 비밀번호 조건을 설정해 줄 수 있다.
+User을 최초 생성할 때, 비밀번호를 강제로 최초 로그인 할 때 바꾸게 할지도 설정해줄 수 있다.
2. MFA(Multi-Factor Authentication)
AWS에서는 강력하게 권장되는 방법이다.
특히 루트 사용자나 관리자 권한을 가진 User에게는 필수이다.
MFA: 내 계정에 로그인할 때,
내가 알고 있는 비밀번호와 더불어 내가 가지고 있는 security device를 모두 사용해야만 로그인 할 수 있게 하는 방법.
따라서 이 방법을 사용하면,
비밀번호가 해킹당하거나 도난당했을 때도 계정에 대한 접속은 불가능하다.
웹 콘솔 기준, 계정 ID => 보안 자격 증명에서 설정할 수 있다.
AWS에서 지원하는 security device의 종류
- virtual MFA device
예시: Google Authenticator, Authy
단일 장치에서 여러 토큰을 지원한다.
즉, 기기 하나만 있으면 여러 계정에 대해 인증을 진행할 수 있다.
- Universal 2nd Factor(U2F) Security Key
물리적 장치. YubiKey by Yubico, AWS가 아닌 서드파티 제품이다.
단일 보안 키로 여러 루트/IAM 사용자에 대한 로그인을 진행할 수 있다.
이 물리적인 장치가 보안 키로 사용된다.
- Hardware Key Fob MFA Device
하드웨어 보안 토큰 MFA 장치.
- AWS GovCloud(미국 정부 클라우드)를 사용하고 있다면 타사인 SurePassID에서 제공하는 이런 보안 토큰도 있다.
+2024년 6월 11일부터 패스키를 지원한다.
+웹 콘솔에서는 FIDO2라고 나와 있는 부분이 U2F랑 같은 맥락의 프로토콜이다.
Security Key인 Yubikey는 FIDO2 프로토콜을 지원한다.
AWS 서비스에 액세스하는 방법
AWS Management Console
웹 인터페이스. username, password으로 접근 가능.
(mfa를 활성화 했다면 mfa 인증도 필요)
AWS Command Line Interface(CLI)
"Access Key(액세스 키)"에 의해 접근제어가 이루어진다.
Access Key(액세스 키)
access key는 Access Key ID와 Secret Access Key 쌍으로 이루어지는 AWS에서의 로그인 수단 중 하나이다.
CLI/SDK에서 이를 사용하여 로그인하며, 웹 콘솔에서 생성 가능하다.
타인과 공유해서는 안 되며, 루트 계정에 대한 access key를 만드는 것은 피해야 한다.
또한 장기 자격 증명으로, 유출에 특히 주의해야 한다.
터미널에 aws configure 명령어로 Access Key ID와 Secret Access Key를 입력하여 로그인할 수 있다.
AWS CLI(command-line-interface)를 통해 내 로컬 쉘에서 AWS 서비스들에 접근하고 이용할 수 있다.
CLI를 사용하면 AWS 서비스의 공용 API로 직접 액세스 가능하며,
CLI를 통해 스크립트를 개발하고 자동화할 수도 있다.
AWS Software Developer Kit(SDK)
특정 언어로 된 라이브러리들의 모음이다.
즉 프로그래밍 언어들에 따라 개별적인 SDK가 존재한다. (Language-specific APIs)
이 방식을 사용해서도 역시 AWS 서비스나 API에 접근 가능.
- SDKs (JavaScript, Python, PHP, .NET, Ruby, Java, Go, Node.js, C++)
- Mobile SDKs (Android, iOS, …)
- IoT Device SDKs (Embedded C, Arduino, …)
즉, 터미널 내에서가 아닌 미리 특정 언어로 aws에 접근하는 코드를 짜 놓는 식이다.
SDK에서도 CLI와 동일하게 access key를 통한 접근 제어가 이루어진다.
AWS CLI는 Boto라는 Python용 AWS SDK를 이용하여 구축되어 있다.
cloudshell
공식 문서
= 웹 콘솔에 내장되어 있는 터미널. 웹 콘솔에 있는 터미널 아이콘 클릭했을 때 사용 가능.
cloudshell의 기본 리전은 현재 웹 콘솔에서 로그인된 리전이다.
cloudshell에서의 권한은 웹 콘솔에 로그인한 권한 그대로 사용된다.
- 여러 탭을 열어둘 수 있다.
- cloudshell의 디렉토리에 파일 업로드 / 다운로드 가능하며,
내가 저장한 파일들은 재시작 시 그대로 남는다.
IAM Role
AWS 서비스 몇 가지는 실행되기 위해서 사용자와 마찬가지로 몇 가지 권한이 필요하다.
IAM role은 이와 같은 상황에서 쓰이는 서비스이다.
IAM role은 policy를 사용자에게 줄 때와 같이 정책을 정한다.
이때 role은 IAM 사용자가 아닌 AWS 서비스 / 다른 AWS 계정 등 여러가지 주체를 가질 수 있다.
예를 들어, EC2 인스턴스는 AWS 서비스들을 이용해서 작업을 하려는 상황에서,
EC2 인스턴스에 IAM Role이 필요하다. IAM Role을 올바르게 부여한 경우 EC2는 하려고 하는 호출에 접근할 수 있다.
ex:
EC2 Instance Roles
Lambda Function Roles
Roles for CloudFormation
IAM Role의 두 가지 구성 요소
한 IAM Role은 다음 두 가지 정책이 같이 붙는다.
- 권한 정책(Permissions Policy)
- 신뢰 정책(Trust Policy)
- 권한 정책(Permissions Policy)
IAM 사용자의 권한 정책과 동일하다.
(예: 특정 S3 버킷에 대한s3:GetObject권한 부여)
즉, 어떤 AWS 서비스의 어떤 리소스에 대한 어떤 작업을 Allow 하거나 Deny 할지를 명시한다. - 신뢰 정책(Trust Policy)
누가 이 Role을 맡을 수 있는지를 정의한다.
IAM User하고 Role이 구분되는 지점으로,
이 신뢰 정책에 명시된 Principal(주체)만이 해당 Role을 맡을 수 있다.
해당 Role을 맡는다는 건 권한 정책에 정의된 권한을 행사 가능하다는 뜻이다.
그럼 주체 자리에 뭐가 올 수 있을까?
- Principal(주체)의 종류
- AWS 서비스:ec2.amazonaws.com,lambda.amazonaws.com등
(시험을 위해서는 이부분만 알면 된다)
- 다른 AWS 계정: 특정 AWS 계정 ID
- 웹 자격증명 공급자(Google, Facebook), SAML 2.0 연동 공급자 등
신뢰 정책의 예시로, 다음의 신뢰 정책은 "EC2는 이 Role을 맡을 수 있음" 을 나타낸다.
IAM Security Tools(감사 목적 도구들)
IAM 보안 도구 로는 두 가지를 알면 된다.
- IAM Credentials Report: 자격 증명 상태 보기
- IAM Access Manager: 불필요한 권한 식별
1. IAM Credentials Report(account-level)
한글명: 자격 증명 보고서. account level의 보고서를 볼 수 있다.
보고서는 해당 AWS 계정에 있는 모든 IAM 사용자와 그 자격증명의 상태를 담고 있다.
.csv 형식으로 볼 수 있다.(엑셀로 열 수 있음)
| 카테고리 | 필드 이름 | 설명 |
|---|---|---|
| 사용자 기본 정보 | user |
IAM 사용자 이름 |
arn |
사용자의 ARN | |
user_creation_time |
사용자 생성 시각 | |
| 암호(Password) | password_enabled |
콘솔 로그인 암호 활성화 여부 |
password_last_used |
마지막으로 콘솔에 로그인한 시간 | |
password_last_changed |
마지막으로 암호를 변경한 시간 | |
password_next_rotation |
다음 암호 변경 예정 시간 | |
| 액세스 키 1 | access_key_1_active |
첫 번째 액세스 키의 활성화 여부 |
access_key_1_last_rotated |
첫 번째 액세스 키를 마지막으로 교체한 시간 | |
access_key_1_last_used_date |
첫 번째 액세스 키를 마지막으로 사용한 날짜 | |
access_key_1_last_used_region |
첫 번째 액세스 키를 마지막으로 사용한 리전 | |
access_key_1_last_used_service |
첫 번째 액세스 키로 마지막 호출한 서비스 | |
| 액세스 키 2 | access_key_2_active |
두 번째 액세스 키의 활성화 여부 |
access_key_2_last_rotated |
두 번째 액세스 키를 마지막으로 교체한 시간 | |
| ... | (나머지 필드는 액세스 키 1과 동일) | |
| 보안 | mfa_active |
멀티 팩터 인증(MFA) 활성화 여부 |
| 기타 (현재 잘 사용되지 않는 Legacy 기능들) |
cert_1_active |
첫 번째 서명 인증서 활성화 여부 |
| ... | (나머지 cert 관련 필드) |
이 보고서를 통해
- 계정의 모든 사용자에 대한 자격 증명 상태를 파악
- 보안 정책을 준수하지 않는 사용자를 식별해서 조치
할 수 있다.
csv로 다운로드되고 엑셀로 열면 여러가지 볼 수 있다.
2. IAM Access Advisor(user-level): 불필요한 권한 제거
IAM Access Advisor.
사용자에게 부여된 서비스의 권한과,
해당 서비스에 마지막으로 언제 엑세스 했는지를 볼 수 있다.
최소 권한 원칙을 따르고자 할 때, 매우 유용한 정보를 제공한다고 할 수 있다.
해당 도구를 사용해서 사용자에게 부여되었으나 실제로 사용하지 않는 권한을 알 수 있고,
이를 통해 사용자에게 인가된 권한을 줄여 최소 권한 원칙을 지킬 수 있다.
Access Advisor은 해당 사용자의 Last Access로 가면 볼 수 있다.
UI 업데이트로 인해 접근 위치가 바뀌었다.
IAM Best Practice
-
Root User의 사용은 최소로
AWS 계정의 기초 설정을 할 때 빼고는 root account를 사용하지 말 것.
Root User는 계정의 모든 리소스와 서비스에 대한 완전한 접근권한을 가지고 있기 때문. -
user를 활용할 것. user은 하나의 물리적인 사용자를 나타낼 수 있음.
즉 AWS 계정을 사용하는 모든 물리적인 사람에게 개별 IAM User를 생성해야 함.
내 친구가 AWS 계정 쓰고 싶다 함 => 아이디 비번 알려주는 대신 "user" 생성. -
user를 그룹에 할당하고 그룹에 permission을 줘서 보안을 그룹 수준에서 관리
직무(ex: 개발자, 데이터베이스 관리자)에 따라 그룹을 만들고 그룹에 권한 정책(policy)을 연결 -
비밀번호 정책은 강하게 만들 것
-
MFA 의무화(보안강화를 위해)
특히 권한이 높은 사용자와 Root User에게는 반드시 활성화할 것. -
AWS 서비스에 권한을 부여하고 싶다 => Role(역할) 을 활용
-
CLI나 SDK에서 AWS 서비스에 접근하고 싶다 => Access Key를 활용
-
Audit(감사)를 위해서는 IAM 자격증명 보고서나 IAM 액세스 관리자(Last Access) 를 사용한다.
-
IAM 사용자와 액세스 키를 절대로 공유하지 말 것