준비 계획
1. IAM
1-1 자격증명
AWS 사용자에게는 장기 자격 증명이 주어지고, 그룹을 지정할 수도 있고 역할을 정의할 수 있다.
역할을 지정하면 단기 자격 증명이 되는데, 이때 STS(보안 토큰 서비스)를 이용하여 해당 역할을 부여하고 일시적인 해당 자격 증명으로 주어진 권한으로 할 수 있는 작업을 진행한다.
EC2의 역할은 EC2 메타데이터 서비스를 이용하며 EC2 인스턴스에 대한 단기 자격 증명을 부여한다.
보통, 인스턴스당 하나의 역할만 할당할 수 있으나 단기 자격 증명의 경우 해당 인스턴스는 S3 버킷이나 DynamoDB 테이블 등에 액세스할 수 있습니다
이 외에도 서비스를 바로 할당할 수 있는 서비스 역할이 있다.
API Gateway나 CodeDeploy처럼 오토 스케일링 그룹 혹은 Lambda 함수 등에 대한 작업이 필요한 서비스의 경우에는 역할이 있어야 하는데 해당 역할은 요구되는 모든 작업을 할 수 있게 활성화와 프로비저닝되어야 한다.
끝으로 교차 계정 역할이 있다. 이 역할은 한 계정에서 다른 계정으로 가는 액세스가 필요한 작업에서 유용하게 쓰인다.
교차 계정에서 사용자의 자격 증명을 공유해서는 안 되기 때문에 역할에 그 권한을 대신 부여해야 한다.
1-2 IAM 정책 - 역할과 사용자가 할 수 있는 작업을 정의
관리형 정책
AWS가 정의한 정책으로 시간이 지남에 따라 변할 수 있으나 특정 작업을 수행
고객 관리형 정책은 우리가 직접 정책을 생성할 수 있고 해당 정책에 여러 사용자나 역할을 할당할 수 있다. 발전시키거나 다음 버전을 생성할 수도 있다.
인라인 정책
한 명의 사용자 또는 하나의 역할을 할당할 수 있고, 이후 더 발전시킬 수 있으나
사용자 또는 역할 간 이를 공유할 수는 없다.
리소스 기반 정책
S3 버킷 정책 혹은 SQS 대기열 정책 등이 속하며 이들 정책을 통해 여러 패턴을 실행할 수 있다.
1-3 IAM 정책 - JSON 문서
IAM 정책은 JSON 문서이고,그 안에는 네 가지 혹은 다섯 가지 사항이 포함되어 있다
Effect, Action Resource, Conditions, 정책 변수(Policy Variables)가 포함된다.
JSON 정책은 그림과 같이 생겼고, 여기에는 문장이 포함된다.
Allow나 ec2:AttachVolume ec2:DetachVolume Resource로 모든 EC2 인스턴스를 나타내는 문장도 있다.
Condition은 StringEquals ResourceTag/Department: Development로 해당 태그가 있는 EC2 인스턴스만 볼륨에 연결 또는 분리할 수 있다는 정책이다.
명시적으로 DENY가 포함된 IAM 정책의 경우에는 이는 모든 ALLOW 명령보다 선행하므로
명시적 DENY가 언제나 최우선 순위가 된다.
1-4 최대 보안을 위한 최소 권한의 원칙
모범 사례는 최대 보안을 위한 최소 권한의 원칙을 따라야 한다.
즉, IAM 정책이 허용 상태여야 하며 할당된 작업만을 수행하도록 해야 하는데, 이를 위한 도구가 몇 가지 있다.
IAM Access Advisor
IAM 정책에 부여된 모든 권한을 살펴보고 각 권한의 마지막 액세스가 언제였는지를 확인할 수 있다.
1년 가량 사용한 적이 없는 정책 등이 있는 경우에는 최소 권한을 유지할 수 있도록 이를 해당 IAM 정책에서 삭제하는 것이 좋다.
Access Analyzer
Access Analyzer는 S3 버킷과 같은 외부 개체와 공유한 리소스를 분석할 수 있고, 또한 S3 버킷에 다른 계정이 액세스할 수 있는지를 확인할 수도 있다는 장점이 있다.
외부 계정의 액세스를 원치 않는다면, 해당 S3 버킷을 잠글 수도 있음!
1-5 일반적인 IAM 정책
AdministratorAccess
모든 리소스에 대해 액세스가 Allow 상태여야 한다는 정책으로 사용자가 직접 지정해야 하는 정책이고, IAM 정책에 설정한 바가 없으면 기본적으로 모든 액세스가 거부된다.
ALLOW, , 으로 설정했다면, 모든 액세스가 허용되고 AdministratorAccess를 얻게 된다.
이는 관리자에게는 아주 일반적인 권한으로, AWS에서는 관리형 정책으로 제공하고 있다.
PowerUserAccess
이 정책은 권한이 좀 더 적은 정책으로, 정책의 처음을 보면 Effect는 Allow, NotAction은 iam, organizations account, Resource에 대해서도 *인데
IAM 조직 및 계정에 대한 어떤 액세스도 허용하지 않는다고 설정되어 있는 것이다.
그럼에도 일부 허용하는 IAM Action이 있는데, CreateServiceLinkedRole
DeleteServiceLinkedRole, ListRoles DescribeOrganization, ListRegions이다.
좌측에 "Effect": "Deny"가 아닌 "NotAction"을 쓴 이유?
단순히 "Effect":"Deny"와 다음의 세 가지 작업을 지정한 뒤, "Effect":"Allow"로 다음 다섯 가지 작업을 지정하면 뒤에 오는 다섯 가지 작업도 자동으로 거부된다. 좌측에 명시적 DENY 명령이 있기 때문이다.
모든 작업을 거부하지 않고 일부 작업은 명시적으로 허용하고자 할 때 DENY 대신 NotAction을 사용해서 거부와 허용이라는 명령이 동시에 존재하도록 할 수 있다.
1-6 Condition
Operators:
• 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:
• "Condition": {"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}}
• ArnEquals, ArnLike
• Null: "Condition":{"Null":{"aws:TokenIssueTime":"true"}}
Condition은 condition-operator condition-key, condition-value 의 모습으로 존재하며, 각종 작업을 할 수 있다
- String 연산자
가령 PrincipalTag/job-category를 iamuser-admin로 설정하고자 할 때, 태그 지정에 해당 연산자를 사용할 수 있다
또한, 그 외에도 이 연산자를 통해 S3 버킷 정책에 대한 prefix를 사용자의 특정 홈 디렉터리에만 액세스 가능하도록 설정할 수도 있다.
- Numeric 연산자
여기에는 Equals, NotEquals LessThan 등이 포함된다.
- Dates (날짜 비교 연산자)
이 연산자는 특정 서비스에 일시적인 액세스 권한을 부여할 때 유용히 쓰인다.
- Booleans 연산자
SSL에 대한 평가, 즉 SecureTransport이 true인지를 판단할 때 아주 유용하다
또한, 그 외에도 MFA, 즉 MultiFactorAuthPresent가 true인지를 확인할 때도 쓰인다.
- IpAddress, NotIpAddress 연산자
이 Condition은 S3 버킷 정책이나 서비스에 특정 소스 IP만이 액세스하도록 설정할 때에 활용할 수 있고, IpAddress를 통해 SourceIp가 CIDR 블록의 IP, 그리고 /24일 때만 액세스 가능하도록 지정할 수 있다.
- ArnEquals, ArnLike과 Null 연산자
특정 요소가 Null인지 여부를 확인할 수 있다.
시험에서 문제를 해결할 때 IAM 정책을 사용하라고 하면 이와 같은 IAM 정책이 있다고 기억만 하면 되며,
사용자 지정 스크립트 대신 이런 정책을 떠올리자.
1-7 IAM Policies Variables and Tags
- S3 버킷 정책에서 가장 흔히 쓰이는 정책변수 & 태그
Example: ${aws:username}
• "Resource": ["arn:aws:s3:::mybucket/${aws:username}/*"] "Resource": mybucket 그 뒤에 변수 ${aws:username}/*라고 입력 할시에, aws:username 접두사로 시작하는 username에 대해서만 작업을 수행하도록 허가할 수 있다.
즉, 모든 사용자에게 여러분의 S3 버킷에 대한 디렉터리가 부여된다는 뜻이다.
AWS Specific:
• aws:CurrentTime, aws:TokenIssueTime, aws:principaltype, aws:SecureTransport, aws:SourceIp, aws:userid, ec2:SourceInstanceARN- AWS 전용 정책 변수와 태그
CurrentTime, TokenIssueTime, principaltype, SSL에서 쓰이는 SecureTransport, SourceIp, userid 그리고 ec2:SourceInstanceARN는 AWS에서 제공하는 정책 변수이다.
- 서비스 전용 정책 변수와 태그
Service Specific:
• s3:prefix, s3:max-keys, s3:x-amz-acl, sns:Endpoint, sns:Protocol…s3:prefix, s3:max-keys sns:Endpoint, sns:Protocol 등이 있다.
- 태그 기반 정책 변수
Tag Based:
• iam:ResourceTag/key-name, aws:PrincipalTag/key-name…iam:ResourceTag/key-name aws:PrincipleTag/key-name 등을 들 수 있다.
1-8 IAM Roles vs Resource Based Policies
정책 연결에는 두 가지 옵션이 있음.
S3 버킷과 같은 리소스에 정책을 연결 / 역할을 프록시로 씀으로써 연결하는 방법
예를 들자면, A 계정을 쓰는 사용자가 있고 이 사용자가 B 계정의 S3 버킷에 액세스하려고 한다면 두 가지 방법을 통해 액세스할 수 있다.
- 계정 B에 대한 역할 이용
계정 B에 대한 역할을 이용하는 것, 그리고 이 역할은 A 계정에서 인수해야 한다.
B 계정에서 해당 역할을 인수하면 해당 S3 버킷에 대한 액세스 권한이 있는 역할이면 액세스가 가능하다.
- S3 버킷 정책을 사용
S3 버킷 정책을 통해 A 계정 사용자가 B 계정에 있는 Amazon S3 버킷에 액세스할 수 있도록 지정하는 방법
이 두 방법을 통해 A 계정 사용자가 B 계정의 Amazon S3 버킷에 액세스할 수 있다.
하지만 둘 사이에는 큰 차이점이 존재한다. 여러분이 역할을 인수할 때 즉, 사용자/애플리케이션 서비스를 인수할 때에 기존의 권한은 모두 포기하고 해당 역할에 할당된 권한만을 얻게 된다.
다시 말해 B 계정에서의 역할을 인수한다면 즉, 그림에 보이는 주황색 상황에서 A 계정의 사용자는 A 계정의 모든 권한을 포기하고 B 계정에 있는 역할만을 인수한다는 것이다.
즉 사용자, 애플리케이션 혹은 서비스로서 역할을 인수한다는 것은 기존의 권한을 모두 포기한다는 의미이며 해당 역할에 할당된 권한만을 얻게 된다는 겁니다
이와 다르게 리소스 기반 정책에서는 Principal이 권한을 포기할 필요가 없다.
그렇다면 리소스 기반 정책은 언제 사용하는 것일까?
- 리소스 기반 정책 사용 예시
나의 A 계정 DynamoDB를 스캔해야 하는 A 계정 사용자가 있다고 해 보자.
A 사용자는 해당 콘텐츠를 B 계정의 S3 버킷에 처분해야 하는데 이 경우 해당 사용자는 계정 2개에 대한 작업을 해야 할 것이다.
즉, 계정 A에 대한 IAM 역할이 있어야 하고, B 계정의 S3 버킷에 대한 리소스 기반 정책도 있어야 된다는 것이다.
점점 더 많은 AWS 서비스가 리소스 기반 정책을 지원하고 있다.
Amazon S3 버킷, SNS 주제 SQS 대기열, Lambda 함수, ECR, Backup, EFS Glacier, Cloud9 등
AWS의 주요 리소스 대부분을 지원한다.
1-9 IAM 권한 경계 (IAM Permission Boundaries)
IAM에는 권한 경계가 존재하며 그룹이 아닌 사용자와 역할이 이를 지원하고 있다.
또한, 고급 기능으로 IAM 개체에 대한 최대 권한을 설정할 수 있다.
아래와 같이 IAM 권한 경계를 연결한다고 해보자.
- IAM Permission Boundary + IAM Permissions Through IAM Policy
s3:, cloudwatch: ec2:*를 IAM 권한으로 설정 했고 그리고,
이 IAM 정책을 iam:CreateUser 그리고 "Resource":*라고 설정했다.
"Action": iam:CreateUser가 우측에서 승인되었다고 하더라도 IAM 권한 설정에서 s3, cloudwatch ec2에 대해서만 권한을 부여하고 있기 때문에 결과적으로 사용자에게는 부여되는 권한이 없다.
AWS Organizations SCP
- 이해 안되는 내용
AWS Organizations SCP에서도 IAM 권한 경계를 활용할 수 있는데
유효 권한이라고 적힌 SCP의 중간 영역을 보면 SCP 간 중첩되는 부분, 즉 권한 경계와 자격 증명 기반 정책에서 사용할 수 있다고 한다.
따라서 IAM 권한 경계를 이용하면 관리자가 아닌 사용자에게 권한 경계와 함께 역할을 위임할 수 있습니다
가령 새로운 IAM 사용자를 생성하거나, 개발자가 특정 권한 내에서만 스스로 정책을 할당하고 그 권한의 범위를 관리하도록 설정하는 방식이다.
또한, 특정 사용자 한 명의 권한을 제한할 때에도 유용한데 이를 이용하면 Organizations와 SCP에 대한 전체 계정 제한을 사용할 필요가 없다.
