[SAA] IAM 고급

IAM Conditions

• 조건에 따라 IAM 정책을 좀 더 제한적으로 만드는 것

1. aws:SourceIp : API를 호출하는 곳으로부터 클라이언트 IP를 제한
   아래 예시의 경우 전부를 거부(Deny)하고 조건(Condition)으로 NotIpAddress에 두 IP 범위를 넣어
   두 SourceIp의 범위로부터 나오는 것 외에는 전부 거부하라는 뜻이 됨
   즉, 강화된 보안을 위해 사전 정의된 IP 목록에서 온 것이 아닌 경우 거부하는 것이며
   aws:SourceIp가 AWS로 API 호출을 하는 클라이언트의 IP 이름을 바꾼다는 것
   
2. aws:RequestedRegion : API 호출이 일어나는 리전을 제한
   IAM 정책 예시의 이름이 AllowOnlyInsideEU이므로 EU 리전 안에서만 허용하라는 뜻이므로
   Effect는 Allow, Action은 ec2:*, rds:*, dynamodb:*, Resource는 *이므로 세 가지 서비스 내의 모든 리소스가 허용됨
   Condition은 StringEquals에 요청 리전이 오직 eu-central-1이나 eu-west-1일 때만을 의미하므로
   만일 이러한 서비스에서 API 호출을 하고 있다면 요청 리전이 eu-central-1이나 eu-west-1일 때만 수락하라는 뜻이며
   이외에 US 같은 다른 리전에서 온 것은 수락하지 않음
   클라이언트가 어디 있느냐가 아니라 클라이언트가 API 호출을 어디로 시도하려고 하느냐에 따라 수락이 달라짐
3. Restrict based on tage : 태그로 제한하는 방법
   EC2 인스턴스를 시작하고 중지시키기 위해서는 오직 프로젝트가 데이터 분석이면서 부서가 데이터일 때만 가능
   EC2 인스턴스의 ResourceTag와 사용자의 보안 주요 태그를 통해 태그 기반 보안을 설정
4. Force MFA : 다요소 인증을 강제하는 방법
   다요소 인증이 있는 경우에만 인스턴스를 중단하거나 종료할 수 있게 하며, 없는 경우 거부함

IAM for S3

• S3에 연동해서 사용하는 IAM
• 여기서는 어떤 때는 /*가 있고 어떤 때는 없는지를 알아야 함
• 버킷 수준의 권한
  리소스에 대해 test라는 이름의 버킷에 ListBucket 권한을 허용하며
  이것은 버킷 수준 권한이므로 / 없이 버킷 이름만 들어가게 됨
  +) arn은 버킷이 있는 곳
• 객체 수준의 권한
  putObject, GetObject, DeleteObject는 버킷 내부의 모든 객체에 적용되므로
  고려 되어야 하는 리소스에는 버킷 이름 / 와 *가 들어가야 함

버킷 수준, 객체 수준

IAM Roles vs Resource Based Policies

• IAM 역할과 리소스 기반 정책의 차이점
• 예) S3 버킷 정책의 리소스를 가져온다고 하면
  S3 버킷 정책을 쓰는 것과 IAM 역할을 프록시로 사용해서 S3 버킷에 액세스하려는 경우의 차이점
  
• 사용자가 계정 A에 있고 S3 버킷이 계정 B에 있고 여기에 액세스하려고 할 때
  첫 번째 옵션 : IAM Roles)
  계정 B에서 역할을 만들고 STS를 사용해 해당 역할을 수임한 다음,
  계정 B에서 해당 역할을 수임하면 계정 B의 S3 버킷에 대해 API 호출이 가능해짐
  두 번째 옵션 : Resource Based Policies)
  계정 A의 사용자 계정이 S3 버킷에 직접 액세스할 수 있도록 허용하는 S3 버킷 정책을 생성
  
  

첫 번째 옵션, 두 번째 옵션

• 첫 번째 옵션의 경우 (IAM Roles)
  사용자, 애플리케이션 또는 서비스의 역할을 수임하게 되면 원래의 권한을 포기하고 역할에 할당된 권한을 갖게 됨
  예) 계정 B에서 S3 버킷에 작업을 하기 위해  IAM 역할을 사용하는 경우 계정 A에 있는 DynamoDB에서는 아무 작업도 불가능
  
• 두 번째 옵션의 경우 (Resource Based Policies)
  리소스 기반 정책을 사용할 때는 권한을 포기할 필요 없이 리소스 버킷 정책을 통해 권한을 잃지 않고 사용할 수 있음
  그러므로 계정 A와 계정 B 모두에서 작업이 가능해짐
  예) 계정 A의 사용자가 계정 A의 DynamoDB 테이블을 읽고 계정 B의 S3 버킷에 덤프해야하는 경우
  
• 그러므로 리소스 기반 정책은 S3 버킷, SNS Topic, SQS 대기열과 같은 것들에 사용됨

IAM Permission Boundaries

• IAM 권한 경계는 사용자와 역할에 대해 지원되며 그룹에는 사용될 수 없으며
  IAM 객체가 얻을 수 있는 최대 권한을 정의하도록 해주는 고급 기능
• 예)
  S3, CloudWatch, EC2의 모든 것을 IAM 사용자와 연결하게 되면
  권한 경계가 생겨 S3, CloudWatch, EC2 내에서만 작업을 수행할 수 있음
  또한 정책을 통해 IAM 권한을 지정해야 하며 동일한 IAM이 Resource가 *인 사용자를 생성할 수 있도록 연결되었다면
  경계가 있고 권한이 있는 IAM 정책이 되지만
  이 경우 IAM 정책이 IAM 권한 경계 밖에 있기 때문에 허가된 것이 없으므로 이 사용자는 다른 IAM 사용자를 생성할 수 없음
  

<IAM 정책 평가 로직 실습>

• 사용자 생성
  이름을 john으로 한 후 Programmatic access를 클릭하고 Permissions에는 아무 설정하도 하지 않은 후 사용자 생성

• 사용자 권한 경계 설정
  john에 대한 정책을 할당하여 사용자 권한 경계를 갖게할 수 있음
  Add permissions을 클릭하고 john을 관리자 액세스에 연결하게 되면 john은 모든 작업을 다 할 수 있는 슈퍼 사용자가 되지만
  john에게 권한 경계를 설정해주어 Set boundary를 클릭해서 AmazonS3FullAccess만 가능하게 설정
  그러므로 AmazonS3FullAccess 정책에 따라 john이 관리자 액세스를 갖고 있지만 수행할 수 있는 유일한 작업은 S3 액세스
  즉, john에게 관리자 액세스를 부여하는 정책이 연결되어 있다고 해도 경계가 실제로는 더 제한적이게 됨

IAM Permission Boundaries

• IAM 권한 경계가 생성되는 위치
• 따라서 IAM 권한 경계는 AWS Organizations SCP와 조합하여 쓸 수 있음
• ID 기반 정책의 중간에 유효 권한이 존재하며
  사용자나 그룹에 연결된 모든 권한 경계는 사용자나 역할에만 적용되고 그룹에는 적용되지 않음
  그리고 조직 SCP는 계정의 모든 단일 IAM 개체에 적용됨
  즉, 중간에 있는 영역이 사용자가 할 수 있는 것들
  

• 예1) 권한 경계 내에서 새 IAM 사용자를 생성해 관리자가 아닌 사용자에게 책임을 위임하는 것
  예2) 개발자가 자신의 권한을 자체 할당하거나 관리할 수 있도록 허용하면서도
           스스로의 권한을 상승시킬 수 없게 하여 스스로를 관리자로 만드는 것
  예3) 계정 전체에 SCP를 적용하고 전체 계정에서 모든 사람을 제한하는 것 대신에
            AWS Organizations 내에서 매우 특정한 사용자 한 명을 제한 가능

IAM Policy Evaluation Logic

• IAM 정책이 평가되는 방식

1. 첫 결정은 거부로 시작하여 기본값으로 AWS에서 하는 어떠한 작업도 다 거절됨
2. 조직 SCP, 리소스 기반 정책, IAM 권한 경계, 세션 정책, 자격 증명 기반 정책이 있어
   만일 이 중에 하나라도 명시적인 거부(explicit deny)가 있으면 최종 결정은 거부가 됨
   그러므로 명시적인 거부는 가장 강력한 조치 중 하나
   

Example IAM Policy

• 예) SQS:*가 있고 Resource:*에 Deny가 있고 Action으로 sqs:DeleteQueue에 Resource:*에 Allow

1. sqs:CreateQueue를 수행할 수 있나요? 아니요
   sqs에 Deny, *가 있고 CreateQueue는 Deny가 있는 블록에 있으므로 당연히 거부됨
2. sqs:DeleteQueue를 수행할 수 있나요? 아니요
   가장 위에 Deny가 있고 밑에는 Allow가 있어 허용과 거부가 동시에 있어 충돌되지만
   sqs:*안에 sqs:deleteQueue가 있으며 명시적인 거부가 하나라도 있으므로 최종 결정은 거부가 되어 이 작업도 거부됨
   즉, sqs:deleteQueue는 두 번째 블록에서 명시적으로 허용했다고 해도 수행할 수 없음
   
3. ec2:DescribeInstances를 수행할 수 있나요?
   EC2에 대해서는 아무것도 없고 아래는 IAM 정책이며 명시적인 거부는 없지만 명시적인 허용도 없기 때문에 수행될 수 없음