이번 장은 IAM을 다룬다.
IAM은 Identity and Access Management의 약자다.
"누가(Identity) 무엇을 할 수 있는가(Access)"를 정하는 서비스다.
AWS 보안의 시작이자 가장 중요한 기반이다.
이 장의 목표는 다음과 같다.
- 사용자, 그룹, 역할, 정책의 차이를 구분한다.
- 최소 권한 원칙(least privilege)을 이해한다.
- 역할(Role)이 왜 액세스 키보다 안전한지 안다.
1. 왜 IAM이 필요한가
1장에서 루트 계정은 잠가 두라고 했다.
그럼 실제 작업은 누가 하는가? 바로 IAM 사용자다.
회사에 개발자가 5명 있다면, 각자에게 IAM 사용자를 하나씩 준다.
이렇게 하면 두 가지 이점이 있다.
첫째, 사람마다 권한을 다르게 줄 수 있다. 개발자는 EC2만, 회계는 결제 정보만.
둘째, 누가 무엇을 했는지 추적할 수 있다. (CloudTrail이 기록한다)
2. 네 가지 핵심 개념
IAM에는 네 가지 구성 요소가 있다.
사용자(User)는 사람 또는 애플리케이션 하나다.
로그인 비밀번호나 액세스 키를 가진다.
그룹(Group)은 사용자의 묶음이다.
"개발자" 그룹에 권한을 주고 사용자를 넣으면, 그 사용자들이 권한을 물려받는다.
권한을 사용자마다 일일이 주지 않고 그룹으로 관리하는 게 원칙이다.
정책(Policy)은 권한을 적은 문서(JSON)다.
"S3 버킷을 읽어도 된다" 같은 규칙을 담는다.
역할(Role)은 잠깐 빌려 쓰는 권한 꾸러미다.
사용자나 서비스가 필요할 때 역할을 "맡아(assume)" 권한을 얻는다.
3. 정책 문서 읽는 법
정책은 JSON으로 되어 있다. 예를 보자.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}
읽는 법은 간단하다.
Effect: 허용(Allow)인지 거부(Deny)인지.Action: 어떤 동작을 허용하는가. (s3:GetObject= S3 객체 읽기)Resource: 어떤 대상에 대해. (arn:...my-bucket/*= 이 버킷의 모든 객체)
이 정책은 "my-bucket 안의 객체를 읽고 쓸 수 있다"는 뜻이다.
기본적으로 모든 것은 거부(implicit deny)이고, 명시적으로 Allow 한 것만 허용된다.
단, Deny는 Allow보다 우선한다. 하나라도 Deny가 있으면 막힌다.
4. 역할이 액세스 키보다 안전한 이유
EC2 안에서 도는 애플리케이션이 S3에 접근해야 한다고 하자.
나쁜 방법: 액세스 키를 코드나 서버 파일에 적어 둔다.
키가 유출되면 그대로 뚫린다. 깃허브에 실수로 올려 사고가 나는 대표적 사례다.
좋은 방법: EC2에 IAM 역할을 붙인다.
그러면 EC2는 임시 자격 증명을 자동으로 발급받는다.
이 자격 증명은 몇 시간마다 자동으로 바뀌고, 코드에 키를 적을 필요가 없다.
원칙은 하나다. 사람은 사용자, 서비스는 역할.
5. 최소 권한 원칙과 MFA
최소 권한 원칙은 "딱 필요한 만큼만 준다"는 뜻이다.
처음부터 AdministratorAccess를 주면 편하지만 위험하다.
필요한 서비스의 권한만 주고, 부족하면 그때 추가하는 방향이 안전하다.
MFA(Multi-Factor Authentication)는 비밀번호 외에 한 단계를 더 두는 것이다.
휴대폰 앱(예: Google Authenticator)이 만드는 6자리 코드를 추가로 입력한다.
비밀번호가 유출돼도 MFA가 있으면 로그인되지 않는다.
루트 계정과 권한이 큰 사용자에게는 반드시 MFA를 건다.
정리
- 사람은 IAM 사용자, 여러 사용자는 그룹으로 묶어 권한을 준다.
- 정책은 Effect/Action/Resource로 권한을 적은 JSON이다.
- 서비스에는 액세스 키 대신 역할(Role)을 붙인다.
- 최소 권한 + MFA가 IAM 보안의 기본이다.
다음 장에서는 가장 많이 쓰는 컴퓨팅 서비스인 EC2를 다룬다.
댓글 0
댓글은 운영자만 작성할 수 있어요.