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 버킷을 잠글 수 있다.
- Access Advisor
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}/" 형식인 경우
- "Condition": {"StringEquals" : {"aws:PrincipalTag/job-category" : "iamuser-admin"} }
- 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(다중 인증 요소)가 설정되어야 한다는 의미
- "Condition" : { "Bool" : { "aws:SecureTransport" : "true" } }
- (Not)IPAddress :
- "Condition" : { "IpAddress" : { "aws:SourceIp" : "203.0.113.0/24" } }
- "aws:SourceIp"는 요청의 소스 IP 주소를 나타내며, "203.0.113.0/24"는 IP 주소 범위를 의미
- "Condition" : { "IpAddress" : { "aws:SourceIp" : "203.0.113.0/24" } }
- ArnEquals, ArnLike
- ArnEquals : ARN이 정확히 일치하는지 확인
- ArnLike : ARN에 와일드카드 문자를 포함하여 확인
- Null
- "Condition" : { "Null" : { "aws:TokenIssueTime" : "true" } }
- "aws:TokenIssueTime"이 null인지 확인한다. "aws:TokenIssueTime"은 AWS 보안 토큰의 발급 시간을 나타낸다. 특정 작업에 대한 보안 토큰이 발급되지 않았을 때 액세스를 제한하기 위해 사용한다.
- "Condition" : { "Null" : { "aws:TokenIssueTime" : "true" } }
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에 대한 전체 계정 제한을 사용할 필요가 없기 때문이다.
'프로그래밍 > AWS Solutions Architect' 카테고리의 다른 글
AWS SAA - Amazon S3 (0) | 2022.05.19 |
---|---|
AWS SAA - Amazon Route 53 (0) | 2022.05.18 |
AWS SAA - Amazon ElastiCache (0) | 2022.05.17 |
AWS SAA - Amazon Aurora (0) | 2022.05.17 |
AWS SAA - Amazon RDS (0) | 2022.05.15 |