[Architecting on AWS] IAM

• 누가 (인증, Authentication)

• 무엇을 할지 (인가, Authorization)

User

• 사용자

• email/password 기반 인증은 콘솔 접속을 제외하고 제공하지 않는다.

• IAM 유저에게 AccessKeyID, SecretAccessKey 를 발급.

Policy

• 1개 이상의 permission 을 모아서 정의해놓은 것 (JSON 형식)

• user-based policy (자격증명 기반 정책)
• 유저의 자격증명에 정책 정의 (어느 리소스에 어떤 동작을 허용/거부하는지 정책을 해당 유저/그룹에게 부여)

• resource-based policy (리소스 기반 정책)
• 리소스에 정책 정의 (어느 유저/그룹에게 어떤 동작을 허용/거부하는지 정책을 리소스에게 부여)

Permission

• AWS 리소스에 대한 권한 (어느 리소스에 어떤 동작을 허용/거부하는지)

Group

• 유저 모음

Role

• temporary permission 부여에 사용한다. ex) prod 환경 리소스에 임시로 접근이 필요할 경우

• role 생성 시 해당 role 에 trust relationship (role 을 행사할 수 있는 유저를 지정하는 것)을 설정한다.

• role 을 부여받은 유저는 STS (Simple Token Service) 에 AssumeRole() API 를 호출할 권한이 있어야 한다. https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html

• role 을 부여받은 유저가 해당 role 을 가지고 리소스 접근하는 과정
• 1. 내부적으로 STS 서비스에 AssumeRole() API 요청.
• 2. AssumeRole() API 는 요청한 유저에게 임시 보안 자격증명에 해당하는 AccessKey, SecretAccessKey 를 응답.
• 3. 유저는 STS 으로부터 받은 AccessKey, SecretAccessKey 를 가지고 리소스 접근 행사.

user-based policy vs resource-based policy

Effect = "Deny" (explicit deny) > Effect = "Allow" > default (implicit deny)

• Statement 에서 Effect = "Allow" 로 되어있지 않은 액션은 기본적으로 Deny 처리되어 (implicit deny) IAM 유저가 실행할 권한이 없다.

• user-based policy 와 resourced-based policy 중 하나라도 Statement 에서 Effect = "Allow" 되어있으면 IAM 유저는 해당 액션을 실행할 권한이 있다.

• IAM policy 와 ECR policy 중 하나라도 Statement 에서 액션이 Effect = "Deny" 되어있으면 (explicit deny) 다른 policy 에서 Effect = "Allow" 되어 있더라도 IAM 유저는 해당 액션을 실행할 권한이 없다.

• 자세한 내용은 여기 참고.

심층 방어

• VPC endpoint policy
• vpc 내에 있는 리소스 접근 시 vpc 계층에서 접근 제어를 하는 것. (리소스 기반 정책에 포함.)

AWS Organizations

• 여러 계정을 중앙에서 관리.

• SCP(Service Control Policy) : source of truth.