IAM(Identity and Access Management)은 계정들의 리소스들에 대한 접근 권한을 관리하기 위해 제공하는 AWS의 서비스이다. user와 user에 대한 permission을 부여할 수 있다.
IAM은 global service로 모든 리전에서 동일하게 사용할 수 있는 서비스이다.

IAM 항목들

User

사용자가 누구인지(인증)와 어떤 권한을 가지고 있는지를 설정한다.
제거하기 전까지 영구적인 key 값을 갖는다.
따라서 일반적으로 long term credential에 사용된다.

보안, 권한 관리 등의 목적으로 root 계정보다 IAM user를 등록하는 것을 권장한다.

  • IAM을 사용하지 않고 root account로 진행해도 되지만 root account는 모든 권한을 가지고 있어 제어를 할 수 없는 문제가 있음.

Group

여러 User들을 그룹화하여 권한을 부여한다.

Role

Role에 권한을 부여하고 user나 service에 role을 주는 방식으로 권한을 할당한다.
user에게 일시적으로 권한을 부여할 수 있기 때문에 short term credential에서 많이 사용된다. (STS와 함께)

IAM Policies

IAM policy는 JSON으로 관리되며 Effects, Action, Resource, Condition, Policy Variables를 가지고 있는다.

예시

policy 예시: MFA를 사용한 특정 액세스 허용

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": [
            "service-prefix-1:*",
            "service-prefix-2:action-name-a",
            "service-prefix-2:action-name-b"
        ],
        "Resource": "*",
        "Condition": {
            "Bool": {"aws:MultiFactorAuthPresent": true},
            "DateGreaterThan": {"aws:CurrentTime": "2017-07-01T00:00:00Z"},
            "DateLessThan": {"aws:CurrentTime": "2017-12-31T23:59:59Z"}
        }
    }
}

정책으로 권한을 부여한다.
DENY가 명시되어 있다면 ALLOW 보다 우선 처리된다.
Best Practice는 보안을 위해 최소한의 권한만을 부여하는 것이다.

AWS managed Policies

AWS에 의해 정의된 policy가 있고 이런 policy들은 서비스가 업그레이드 됨에 따라 변경되기도 한다.
specific한 작업들에 관한 policy.
대표적으로 AdministratorAccess, PowerUserAcess가 있다.

  • AWS에서 관리하는 policy list - link

AWS manag4ed Policy들을 보면 policy 사용법을 더 이해할 수 있다.

AdministratorAccess:
*을 사용해서 모든 권한을 허용하는 policy.

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

PowerUserAccess:
NotAction을 명시하여 대부분의 권한을 허용하지 않는다.
"Effect":"Deny"를 쓰지 않는 것은, deny를 하게되면 이후에 허용하고 싶은 action들이 모두 무시되기 때문이다.

{
    "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": "*"
        }
    ]
}

IAM Policy Conditions

IAM policy condition은 policy의 효력이 발생하는 시점을 지정할 수 있는 요소이다.
이렇게 생겼다.

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

operator type에 따라 여러가지 연산을 제공한다.

  • String의 경우, String Equals, StringNotEquals, String Like …
  • Date의 경우, DateEquals, DateLessThan …
  • condition list - link

IAM Policies Variables and Tags

Variable이란 policy에서 사용할 수 있는 aws에서 정의한 변수들이고,
Tag란 User나 Resource에 Tag를 하여 Variable처럼 사용할 수 있는 key 값이다.

  • variable과 tag aws docs - link

Example: ${aws:username}

  • “Resource”: [“arn:aws:s3:::mybucket/${aws:username}/*”]
  • username으로 시작하는 bucket에 접근할 수 있다.
  • 모든 유저가 s3에 각자의 bucket을 갖도록 명시할 수 있다.

AWS specific variables

  • aws:CurrentTime, aws:TokenIssueTime, aws:principaltype, aws:SecureTransport …

Service specific variables

  • s3:prefix, s3:max-keys, s3:x-amz-acl, sns:Endpoint, sns:Protocol…

Tag Based

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

IAM Role vs Resource Based Policies

role(user, application, service)을 assume할 때 original permission을 포기하고 role에 설정된 permission을 갖게 된다.
resource-based policy를 사용하면 이런 permission을 포기하지 않을 수 있다.

예시

A가 dynamoA에 role을 가지고 있다.
B가 S3B에 role을 가지고 있다.

A가 dynamoA에서 S3B로 data를 dump하고 싶다.

  1. A가 B의 role을 받아가면 A의 permission을 포기해야 하기 때문에 dynamoA의 role을 잃는다.
  2. A가 S3B의 resoure-based policy에 추가되면 dynamoA의 policy를 잃지 않을 수 있다.

IAM Permission Boundaries

Bouddary는 user나 role에 대한 maximum permission을 설정하는 것이다.
Boundary는 user와 role에 대해 지원되고 group은 지원하지 않는다.

Boundary를 명시하면 policy가 있더라도 permission을 갖지 못하게 할 수 있다. boundary에서 명시한 permission 중 plicy가 추가된 permission만 효력이 있다.
boundray.png

  • boundary와 policy들 사이의 effective를 diagram으로 확인 - link

예시

IAM permission boundary

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "cloudwatch:*",
                "ec2:*"
            ],
            "Resource": "*"
        }
    ]
}

IAM permission

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "iam:CreateUser",
    "Resource": "*"
  }
}

위와 같이 boundray와 permission이 있다면 iam action은 boundary에 없으므로 permission이 있더라도 effective하지 않다.

refernce

  • AWS docs
  • udemy, Ultimate AWS Certified Solutions Architect Professional 2022