AWS

[AWS IAM] IAM Basics

Sean 션 2024. 6. 21. 11:22

IAM을 구성하는 여러가지 리소스

  • IAM Users: long term credentials
  • IAM Groups
  • IAM Roles: short term credentials으로, IAM Role은 STS를 사용하여 권한을 받는다.
    • EC2 Instance Role: 인스턴스에 하나씩 붙일 수 있고, EC2 metadata를 사용한다.
    • Service Roles: API Gateway, CodeDeploy같은 서비스가 Auto Scaling Group이나 Lambda같은 서비스에 액션을 취하기 위해선 권한이 필요한데 이 때 Service Role을 사용한다.
    • Cross Account Roles: 계정 간 권한을 제공하기 위함. IAM User의 credential을 공유하면 안됨.
  • IAM Policies
    • AWS Managed
    • Customer Managed: 정책을 만들어 여러 User나 Role에 붙일 수 있음
    • Inline Policies: 하나의 특정 User나 Role에 붙이는 Policy
  • Resource Based Policies (S3 Bucket, SQS queue 등)

IAM Policy 분석

IAM Policy는 Json document로 작성되며, 5개의 섹션으로 구성되어 있습니다.

  • Effect
  • Action
  • Resource
  • Conditions
  • Policy Variables

 

기본적으로 IAM 규칙이 명시되어 있지 않다면 액션을 Deny 하며, 명시적인 Deny 규칙이 있다면 Allow 규칙이 있어도 Deny가 우선순위를 갖게 됩니다.

Best Practice를 따르기 위해선 최소 권한의 원칙에 따릅니다.

  • IAM Access Advisor를 통해 IAM 정책으로 부여된 모든 권한들을 볼 수 있고, 각각의 권한이 언제 마지막으로 사용되었는지 볼 수 있습니다.
  • IAM Access Analyzer는 리소스가 외부의 자원과 공유되어있는지 분석해주는 도구로, 가령 S3 버킷이 외부와 공유되었을 경우 이를 알 수 있도록 도와줍니다.

IAM AWS Managed Policies

  1. AdministratorAccess
{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action":"*",
         "Resource":"*"
      }
   ]
}

모든 행동에 대해 Allow하는 정책입니다.

  1. PowerUserAccess
{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "NotAction":[
            "iam:*",
            "organizations:*",
            "account:*"
         ],
         "Resource":"*"
      }, 
 
...(생략)
 
			{
         "Effect":"Allow",
         "Action":[
            "iam:CreateServiceLinkedRole",
            "iam:DeleteServiceLinkedRole",
            "iam:ListRoles",
            "organizations:DescribeOrganization", 
            "account:ListRegions"
				 ],
				 "Resource": "*" 
			 }
		]
}
  • 윗부분의 NotAction을 통해 IAM Account와 Origanizaitons에 대한 어떠한 것도 허용하지 않고, 뒷부분의 Action을 통해 몇몇의 예외를 허용합니다.
  • NotAction은 지정된 작업의 목록을 제외한 모든 작업과 명시적으로 일치하는 고급 정책 요소입니다. 예를 들어, S3 버킷의 삭제 권한을 제외한 모든 권한을 Allow 하고 싶다면 다음과 같이 기술합니다:
"Effect": "Allow",
"NotAction": "s3:DeleteBucket",
"Resource": "arn:aws:s3:::*",
  • Effect: Deny를 사용하지 않고 NotAction을 사용하는 이유는, 윗부분의 내용을 Deny하고 뒤에서 Allow를 해도 항상 Deny가 높은 우선순위를 가지기 때문에 권한이 거부될 것이기 때문입니다.
  • NotAction에 지정된 작업은 정책 설명의 Allow 또는 Deny 효과의 영향을 받지 않습니다.

IAM Policies Conditions

"Condition": {"{condition-operator}": {"{condition-key}":"{condition-value}"}}

Operator의 종류:

  • String (StringEquals, StringNotEquals, StringLike, …)
"Condition": {"StringEquals": {"aws:PrincipalTag/job-category":"iamuser-admin"}}

"Condition": {"StringLike": {"s3:prefix": [ "", "home/", "home/${aws:username}/"}}
  • Numeric (NumericEquals, NumericNotEquals, NumericLessThan, …)
  • Date (DateEquals, DateNotEquals, DateLessThan, …): 특정 기간에만 권한 부여하기 좋음
  • Boolean (Bool)
"Condition": {"Bool": {"aws:SecureTransport": "true"}}
"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  • (Not)IpAddress: S3 버킷에서 특정 IP만 엑세스를 허용하도록 구성하기 좋음
 "Condition": {"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}}
  • ArnEquals, ArnLike
  • Null: 조건이 Null인지 아닌지 체크하는데 사용
"Condition": {"Null": {"aws:TokenIssueTime":"true"}}

IAM Policies Variables and Tags

${aws:username} 같은 형태로 사용하고, 특히 S3버킷 정책에서 많이 쓰이고, $ 을 통해 기술합니다.

"Resource":["arn:aws:s3:::mybucket/${aws:username}/*"]
  • 이렇게 설정하면 각각의 유저에게 자신의 유저네임에 해당하는 prefix(디렉토리)에서만 작업할 수 있도록 강제할 수 있습니다.

다양한 종류의 Variable이 있습니다.

  • AWS Specific: aws:CurrentTime, aws:TokenIssueTime, aws:principaltype, aws:SecureTransport, aws:SourceIp, aws:userid, ec2:SourceInstanceARN, …
  • Service Specific: s3:prefix, s3:max-keys, s3:x-amz-acl, sns:Endpoint, sns:Protocol, …
  • Tag Based: iam:ResourceTag/key-name, aws:PrincipalTag/key-name, …

IAM Roles vs Resource Based Policies

예를 들어 타 계정에 있는 S3 버킷에 접근해야 하는 경우, 두 가지 방법이 있습니다.

  • Option A. IAM Role을 Proxy 삼아 사용
  • Option B. Policy를 S3에 할당

 

두 가지 모두 가능한 시나리오이지만, 다른 점이 있습니다. 옵션 A의 경우 User가 Role Account B를 할당하는 순간부터 기존에 가지고 있던 A의 권한이 모두 적용되지 않습니다. User나 Service가 Role을 Assume(할당) 하는 순간, 기존에 가지고 있던 권한은 없어집니다. Resource-based policy를 사용하는 경우엔 기존에 유저가 가지고 있던 권한이 그대로 유지됩니다. 가령, User A가 계정 A의 DynamoDB를 스캔하고 계정 B의 S3 버킷에 업로드를 해야 한다면 resource-based Policy를 사용해야 합니다.

IAM Permission Boundaries

 

IAM Permission Boundaries는 IAM User와 Role에 적용 가능합니다. (IAM Group에는 적용 불가) Permission Boundary는 IAM 엔티티가 가질 수 있는 최대 권한을 정의할 수 있는 기능입니다. 예를 들어, IAM Permission Boundary에 정의되지 않은 IAM Policy를 만든다고 하더라도 이 정책을 사용하는 리소스는 권한을 부여받지 못합니다. Permission Boundary로 인해 권한이 제한되었기 때문입니다.

 

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html

 

Organizations SCP와 Permission Boundaries, IAM Policy가 결합하여 효율적인 권한 구성이 가능합니다.

 

IAM Access Analyzer

어떤 리소스가 외부로 공유되는지 분석해줍니다.

분석 가능한 리소스들:

  • S3 Bucket
  • IAM Roles
  • KMS Keys
  • Lambda Functions and Layers
  • SQS queues
  • Secrets Manager Secrets

AWS Account, AWS Organization으로 Zone of Trust를 정의하고, 이 Zone을 벗어난 접근을 찾아서 보고해줍니다.

  • IAM Access Analyzer Policy Validation:
    • Policy 문법이나 best practice 등에 대해 검사를 수행하고 여러 종류의 Recommendation을 제공합니다.
  • IAM Access Analyzer Policy Generation:
    • 접근 기록에 근거하여 IAM Policy를 만들어줍니다.
    • API Call에 따라 CloudTrail로 로그가 생성되고, IAM Access Analyzer가 이를 통해 Policy를 생성합니다. 이 과정을 통해 손쉽게 fine-grained permission을 얻을 수 있습니다.
    • 최근 90일간의 CloudTrail Log를 통해 생성합니다.