프로그래밍/AWS Solutions Architect

AWS SAP - IAM

병인 2024. 2. 27. 15:19

IAM

  • Users(AWS 사용자) : 장기 자격 증명
  • Groups(그룹)
  • Role(역할) : 단기자격 증명, STS(Secure-Token-Service, 보안 토큰 서비스) 이용하여 해당 역할 부여
    • EC2 Instance Roles : EC2 메타데이터 서비스 이용. 인스턴스 당 1개의 Role 할당 가능
    • Service Roles : API Gateway, CodeDeploy, Auto Scale Groups, Lambda Function, etc...
    • Cross Account Roles : 하나의 계정에서 다른 계정으로 가는 액세스가 필요한 작업에서 사용
  • Policies(정책)
    • AWS Managed : AWS가 정의한 정책으로 시간이 지남에 따라 변할 수 있으나 특정 작업을 수행한다.
    • Customer Managed : 사용자가 직접 정책을 생성할 수 있고, 해당 정책에 여러 사용자나 역할을 할당할 수 있다.
    • Inline Policies : 한 명의 사용자 혹은 하나의 역할을 할당할 수 있고 정책 수정이 가능하나 사용자 또는 역할 간 공유할 수 없다.
  • Resource Based Policies(리소스 기반 정책)
    • S3 Bucket, SQS Queue, etc...

IAM 정책

  • JSON 타입으로 정의되어 진다.
    • Effect, Action, Resource, Conditions, Policy Variables 등 포함된다.
{
    "Version": "2012-10-17"
    "Statement": [
        {
            "Effect" : "Allow",
            "Action": [
                "ec2:AttachVolume",
                "ec2:DetachVolume"
            ],
            "Resource" : "arn:aws:ec2:*:*:instance/*",
            "Condition" : {
                "StringEquals" : {"ec2:ResourceTag/Department": "Development"}
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:AttachVolume",
                "ec2:DetachVolume"
            ],
            "Resource": "arn:aws:ec2:*:*:volume/*",
            "Condition": {
                "StringEquals" : {"ec2:ResourceTag/VolumeUser": "${aws:username}"}
            }
        }
    ]
}

해석

  • EC2 인스턴스에 대한 볼륨 연결 및 분리 작업을 허용하려면 해당 인스턴스의 "ec2:ResourceTag/Department" 태그의 값이 "Development"과 일치해야 한다. 해당 정책을 가진 IAM 사용자는 "Department" 태그 값이 "Development"인 EC2 인스턴스에 대해서만 볼륨 연결 및 분리 작업을 수행할 수 있다.
  • EC2 인스턴스의 볼륨에 대한 연결 및 분리 작업을 허용하려면 IAM 사용자의 이름과 "ec2:ResourceTag/VolumeUser" 태그의 값이 일치해야 한다. 해당 정책을 가진 IAM 사용자가 자신의 이름과 일치하는 태그 값을 가진 EC2 인스턴스의 볼륨에 대해 연결 및 분리 작업을 수행할 수 있다.
  • 명시적으로 DENY가 포함된 IAM 정책의 경우에는 모든 ALLOW 명령보다 선행하므로 명시적 DENY가 언제나 최우선 순위가 된다.
  • 모범 사례로 구축하려면 최대 보안을 위해선 최소 권한의 원칙을 따라야 한다.
    • Access Advisor
      • IAM 정책에 부여된 모든 권한을 확인하고 각 권한의 마지막 액세스가 언제였는지 확인할 수 있다.
    • Access Analyzer
      • S3 버킷과 같은 외부 개체와 공유한 리소스를 분석할 수 있다.
      • S3 버킷에 다른 계정이 액세스 할 수 있는지 확인할 수 있다.
      • 외부 계정의 액세스를 원치 않으면 해당 S3 버킷을 잠글 수 있다.

IAM AWS Managed Policies

AdministratorAccess

{
    "Version": "2012-10-17",
    "Statement" : [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}
  • 모든 리소스에 대해 액세스가 Allow 상태여야 한다는 정책
  • 사용자가 직접 지정해야 하는 정책
  • IAM 정책에 설정한 바가 없으면 기본적으로 모든 액세스가 거부된다.
  • 위의 정책을 설정하면 모든 액세스가 허용되고 AdministratorAccess를 얻게 된다.
  • 관리자에게 일반적인 권한이다.

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",
                "account:GetAccountInformation"
            ],
            "Resource" : "*"
        }
    ]  
}
  • iam:*, organizations:*, account:*를 제외한 모든 작업에 대한 액세스를 허용하고, 모든 리소스에 대한 액세스를 허용
  • iam:CreateServiceLinkedRole, iam:DeleteServiceLinkedRole, iam:ListRoles, organizations:DescribeOrganization, account:ListRegions, account:GetAccountInformation와 같은 작업에 대한 액세스를 허용하고, 모든 리소스에 대한 액세스를 허용
  • PowerUserAccess 정책은 대부분의 AWS 서비스와 리소스에 대한 액세스를 허용하지만, IAM, 조직, 계정과 관련된 특정 작업에 대한 액세스를 제한한다.

IAM Policies Conditions

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

Operators(연산자)

  • String (StringEquals, StringNotEquals, StringLike ...)
    • "Condition": {"StringEquals" : {"aws:PrincipalTag/job-category" : "iamuser-admin"} }
      • "aws:PrincipalTag/job-category" 태그 값이 "iamuser-admin"인 경우
    • "Condition": {"StringLike" : {"s3:prefix": [ "", "home/", "home/${aws:username}/" ] } }
      • "s3:prefix" 값이 "", "home/", 또는 "home/${aws:username}/" 형식인 경우
  • Numeric (NumericEquals, NumericNotEquals, NumericLessThan ...)
  • Date (DateEquals, DateNotEquals, DateLessThan ...)
  • Boolean (Bool) :
    • "Condition" : { "Bool" : { "aws:SecureTransport" : "true" } }
      • "aws:SecureTransport"이 "true"인지 확인하는 조건, 액세스가 보안 전송(HTTPS 등)으로 이루어져야 한다는 의미
    • "Condition" : { "Bool" : { "aws:MultiFactorAuthPresent" : "true" } }
      • "aws:MultiFactorAuthPresent"가 "true"인지 확인하는 조건, MFA(다중 인증 요소)가 설정되어야 한다는 의미
  • (Not)IPAddress :
    • "Condition" : { "IpAddress" : { "aws:SourceIp" : "203.0.113.0/24" } }
      • "aws:SourceIp"는 요청의 소스 IP 주소를 나타내며, "203.0.113.0/24"는 IP 주소 범위를 의미
  • ArnEquals, ArnLike
    • ArnEquals : ARN이 정확히 일치하는지 확인
    • ArnLike : ARN에 와일드카드 문자를 포함하여 확인
  • Null
    • "Condition" : { "Null" : { "aws:TokenIssueTime" : "true" } }
      • "aws:TokenIssueTime"이 null인지 확인한다. "aws:TokenIssueTime"은 AWS 보안 토큰의 발급 시간을 나타낸다. 특정 작업에 대한 보안 토큰이 발급되지 않았을 때 액세스를 제한하기 위해 사용한다.

IAM Policies Variables and Tag

Example : ${aws:username}

  • "Resource" : ["arn:aws:s3:::mybucket/${aws:username}/*"]
    • "arn:aws:s3:::mybucket/"로 시작하는 S3 버킷 내에서 ${aws:username}으로 시작하는 모든 리소스에 대한 액세스 허가

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(S3 버킷에 적용되는 액세스 제어 목록(ACL)을 설정하는 데 사용), sns:Endpoint(엔드포인트는 이메일 주소, SMS 전화번호, HTTP 엔드포인트 등이 될 수 있다), sns:Protocol...

Tag Based

  • iam:ResourceTag/key-name, aws:PrincipalTag/key-name...

IAM Roles VS Resource Based Policies

  • Resource(예. S3 버킷 정책)에 정책을 연결
  • Role을 프록시로 사용해 연결

  • Role (user, application, service)를 인수할 때 기존의 권한은 모두 포기하고 해당 역할에 할당된 권한만을 얻게 된다. (주황색)
    • Account B의 역할을 인수하면, Account A의 User는 Account A 의 모든 권한을 포기하고 Account B에 있는 역할만을 인수한다.
  • Resource Based Policy에서는 Principal이 권한을 포기할 필요가 없다. (회색)
  • 사용 예
    • Account A의 DynamoDB를 스캔해야 하는 User가 존재한다. 이 User는 해당 콘텐츠를 Account B의 S3 Bucket에 넣어야 한다.
    • 이 경우 해당 User는 Account A의 IAM Role과 Account B의 S3 Bucket Resource Based Policy 가 필요하다.

IAM Permission Boundaries

  • IAM에는 Permission Boundary가 존재하며 Group이 아닌 User와 Role이 이를 지원하고 있다.
  • 고급 기능으로 IAM 개체에 대한 최대 권한을 설정할 수 있다.
  • IAM Permission Boundary
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "cloudwatch:*",
                "ec2:*"
            ],
            "Resource": "*"
        }
    ]
}
  • IAM Permissions Through IAM Policy
{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "iam:CreateUser",
        "Resource": "*"
    }
}
  • 위의 IAM Permission Boundary와 IAM Policy를 합치면 아무 권한을 부여하지 않게 설정된다.
  • "Action": "iam:CreateUser"가 정책으로 승인되었다고 하더라도 IAM 권한 설정에서 s3, cloudwatch, ec2만 권한을 부여하고 있기 때문이다.

 

  • AWS Organizations SCP에서도 IAM Permission Boundary 활용

  • Effective permissions 부분을 보면 SCP간 중첩되는 부분, 즉 Permission boundary와 Identity-Based policy에서 사용할 수 있다.
  • IAM Permission Boundary를 이용하면 관리자가 아닌 사용자에게 Permission boundary와 Role을 위임할 수 있다.
  • 예를 들면 새로운 IAM 사용자를 생성하거나 개발자가 특정 권한 내에서만 스스로 정책을 할당하고 그 권한의 범위를 관리하도록 설정할 수 있다. 부여한 권한 밖으로는 권한을 스스로 올리지 못한다.
  • 특정 사용자 한 명의 권한을 제한할 때에도 유용하다. Organizations와 SCP에 대한 전체 계정 제한을 사용할 필요가 없기 때문이다.
저작자표시 비영리 변경금지