202003 AWS ISV/DNB IAM_webinar

© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
SECURITY
FIRST
AWS IAM
ISV/DNB Webinar
조이정 솔루션즈 아키텍트
March. 2020
IAM

목차
• Why security ?
• AWS IAM(Identity and Access Management)이란?
• IAM policy
• Identity Federation
• IAM Management
• IAM Best Practice
• Appendix. AWS IAM 정책 연습 & 퀴즈

클라우드 가속화 IAM

클라우드 보안 컨텍스트 IAM

클라우드 보안 컨텍스트 IAM
Only 7% of businesses have good visibility of all critical data. 58% say they only have slight control. (ForcePoint)
80% of security breaches involve privileged credentials. (Forrester)
49% of databases are not encrypted. (RedLock)
73% of security professionals who report that their organization has not implemented a privileged account security solution for DevOps (CyberArk)
Through 2022, at least 95% of cloud security failures are predicted to be the customer’s fault. (Gartner)
An average of 51% of organizations publicly exposed at least one cloud storage service. (RedLock)
Only 12% of global IT organizations understand how GDPR will affect their cloud services. (Commvault)
25% of organizations have cryptojacking activity within their environments. (RedLock)
84% of organizations say traditional security solutions don’t work in cloud environments. (Crowd Research Partners)
Public cloud account compromises are fueling new attack vectors, causing 27% of organizations to have users whose accounts are potentially compromised. (RedLock)
https://redlock.io/blog/13-cloud-security-statistics-to-know-in-2019-with-9-best-practices

AWS를 즐기는 방법 IAM
SDKAWS console Command Line Interface

자연스러운 흐름 … IAM
DOM 기반
프로비저닝 엔진 사용
Script 기반
Console 기반 작업
High
level
Low
level

결국, API IAM
AWS Cloud
VPC
CloudWatch Cloud Formation CloudTrail Event
ELB
API
API API

AWS에서의 API 인증
매 API호출 마다, AWS CLI 및 SDK 등에서 처리됨
IAM
POST https://dynamodb.us-east-2.amazonaws.com/ HTTP/1.1
Host: dynamodb.us-east-2.amazonaws.com
X-Amz-Date: 20180918T150746Z
X-Amz-Target: DynamoDB_20120810.ListTables
X-Amz-Security-Token: FQoGZXIvYXdzEKH////////// …
Content-Type: application/x-amz-json-1.0
Authorization: AWS4-HMAC-SHA256
Credential=ASIAXXXXXXXXXXXXXXXX/20180918/us-east-
1/dynamodb/aws4_request, SignedHeaders=content-
type;host;x-amz-date;x-amz-security-token;x-amz-target,
Signature=c1b4bc2df0c47c86cbcfa54d932e8aaa455b6b7c38e65
d840f722254add1ea9e
Amazon
DynamoDB

용어: Sig v4(Signature Version 4)
• AWS에 HTTP 요청을 보낼 경우, 요청자를 확인하기 위해 요청에 서명(sign)을 한 후 보내야
함 – HTTP 요청 헤더 또는 URL query string
• AWS CLI 또는 SDK를 사용할 경우, 별도의 작업 없이 자동 서명하여 요청함
• 모든 요청은 Timestamp가 포함된 서명이 있어 Replay 공격이 제한됨 (보통 5분 이내)
• 모든 리전과 서비스*는 SIG v4를 지원하므로 SIG v4 사용 권고

AWS의 shared responsibility model IAM
고객측 IAM
AWS IAM
방화벽 설정(S/G, NACL)
데이터
AWS IAM
데이터
어플리케이션
운영체제
네트워킹/방화벽
데이터
고객측 IAM
AWS IAM
Infrastructure
Services
Container
Services
Abstract
Services

AWS Identity and Access Management (IAM)
• I: Identity. ‘Identity’는 AWS로 요청을 할 수 있는 보안주체(Principal)를 AWS
어카운트 내에 만들어 줍니다.
• AM: Access Management. ‘Access Management’는 누가 어떤 리소스들에 대해
어떤 일을 할 수 있는 권한을 가지는지를 정의하는 도구입니다.
• IAM 은 AWS 전체의 권한 통제 시스템.
IAM

용어 : IAM 보안 주체(principal)
• IAM principal - AWS 어카운트 내에 정의된 요청 주체(Identity)
• CloudTrail ‘userIdentity’ 요소 기준, 다음 사용자 유형을 구별 :
1. Root– API 요청이 AWS Account 자격 증명을 사용
2. IAM User – API 요청이 IAM User의 자격 증명을 사용
3. Assumed Role – API 요청이 AWS STS AssumeRole API 호출을 통해 역할로 획득된 임시 보안 자격 증명을 사용
4. Federated User – API 요청이 AWS STS GetFederationToken API 호출을 통해 획득한 임시 보안 자격 증명을 사용
5. AWS Account – 다른 AWS Account에서 요청
6. AWS Service – AWS 서비스에 속한 AWS 계정을 통해 요청
• SAML이나 WebIdentity Federation을 하는 경우 :
1. SAMLUser – SAML 어설션이 이루어지는 요청
2. WebIdentityUser – 웹 자격 증명 연동 제공업체로 이루어지는 요청.
IAM

용어 : IAM 보안 주체(principal) IAM

I is for Identity : 실 사용자 è IAM 사용자(User) IAM

I is for Identity : 실 사용자 è IAM 사용자(User) IAM
IAM user
Human user
Human user
상시
Amazon DynamoDB
AWS Cloud
Long-term security
credential
IAM user
Long-term security
credential

I is for Identity : 인스턴스/타서비스 è IAM 역할 IAM
EC2 instance
Lambda
function
IAM 역할
IAM 역할
임시
Application
Auto Scaling
VPC
AWS Cloud
Amazon DynamoDB

I is for Identity: 외부 사용자 è IAM 역할
외부 사용자
(분석가)
IAM 역할:
개발자
외부 사용자
(개발자)
IAM 역할:
분석가
IAM
외부 사용자
관리 시스템
IAM
AWS Cloud
Amazon DynamoDB
임시

용어 : IAM 역할(Role)
• 권한의 위임 체계를 지원하기 위한 용도
• 신뢰정책(해당 역할을 할 수 있는 보안주체 규정)과 권한정책(해당 역할에 부여될 권한을 규정)이 할당됨.
• 보안주체를 규정할 때는 * 을 사용할 수 없으며, 수임(AssumeRole) 조건으로 MFA를 지원함.
• 동일 또는 타 어카운트, AWS 서비스(EC2, 람다 등), 외부인증연계(Federated) 사용자에 부여될 수 있음
• IAM 역할을 수임한 IAM 사용자에게는 본래 권한 대신 IAM역할에서 규정된 권한으로 대체됨.
• IAM 역할의 최대 세션 시간
• 관리 콘솔 : 1시간
• CLI / API : 기본 1시간, 15분 ~ 12시간
• Role Chaining 지원 : A -> B -> C의 경우, C를 수임하는 조건은 B가 아닌 A 기준임.
IAM

IAM 역할 vs. IAM 사용자 IAM
IAM 역할 IAM
사용자
• IAM 역할은 임시 자격증명으로
인증 받습니다.
• IAM 사용자는 상시
자격증명으로 인증 받습니다.
• 주로 IAM Group으로 관리

• IAM Group은 보안 주체가 아니며, IAM
권한을 한꺼번에 주기 위한 용도임.
• 그룹 간 포함(Nested) 관계는 불가.
• 자동 소속되는 기본 그룹은 없음.
• IAM사용자는 복수개의 그룹에 속할 수
있음(최대 10개까지, Hard Limit)
IAM
용어 : IAM Group

AM is Access Management: 요청의 처리 단계 IAM
보안주체가 콘솔, API, CLI를 통해 전송한 요청들은 다음 단계에 따라 평가되고 허용
여부가 판단 :
1. 요청자 인증 – 익명 요청을 허용하는 S3, Cognito 등 일부 서비스가 있음.
2. 요청 컨텍스트 수집 – 요청 주체, 요청된 리소스 및 관련 데이터, 요청된 작업, 환경 데이터(IP,
시간대) 등을 수집하고 적합한 접근제어 정책(들)을 찾음
3. 접근제어 정책 평가(*)
4. 요청의 허용/거부 결정(*)

AM is Access Management: 요청의 성공 조건
제출된 요청이 성공하기 위해선,
• IAM 보안 주체의 적법한 서명값이 포함되어 있고(인증),
AND
• 정책(Policy)에 의해 해당 요청이 정확하게 인가되어야 함.
Amazon DynamoDB
Amazon DynamoDB
Permissions

AM is Access Management: AWS에서의 인가 IAM
접근제어 정책
• AWS Root 어카운트는 기본적으로 AWS
리소스에 대한 모든 권한을 가짐.
• AWS 정책은 기본 디폴트가 Deny이고, 명시적
Allow < 명시적 Deny 의 우선순위.

AWS 정책의 JSON 구조
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:*"
],
"Resource": "*"
}
]
}
IAM
해석: 모든 DynamoDB
action들을 허용

정책을 좀더 상세하게 작성하기 : Actions
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:BatchGetItem",
"dynamodb:GetItem",
"dynamodb:Query"
],
"Resource": "*"
}
]
}
IAM
해석: DynamoDB의 특정
action만을 허용

Action : 샘플
• 서비스별로 허용 또는 거부되어야 할
Action 나열
• 문서 또는 정책 편집기(Policy Editor)를
통해서 Action의 종류 확인 가능
• Action 또는 NotAction 항목 정의 지원
IAM

"Action":"ec2:StartInstances"

"Action":"iam:ChangePassword"
<!– Amazon S3 action -->
"Action":"s3:GetObject"
<!– 복수개의 Action-->
"Action":["sqs:SendMessage","sqs:ReceiveMessage"]
<-- Action 이름에 와일드카드(* or ?) 지원 -->
"Action":"iam:*AccessKey*"

NotAction IAM
• 예외 처리할 Action항목을 정의.
• 여집합을 이용하여 정책 길이를 단축 : 예: IAM APIs를 제외한 모든 행위 허용
{
"Version": "2012-10-17",
"Statement": [ {
"Effect": "Allow",
"NotAction": "iam:*",
"Resource": "*"
}
]
}
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "iam:*",
"Resource": "*"
}
]
}
or
차이점은
?
CASE 1

정책을 좀더 상세하게 작성하기 : Resource-level
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:BatchGetItem",
"dynamodb:GetItem",
"dynamodb:Query",
],
"Resource": [
"arn:aws:dynamodb:us-east-2:<account-id>:table/MyTableName",
"arn:aws:dynamodb:us-east-2:<account-id>:table/MyTableName/index/*"
]
}
]
}
IAM
해석: DynamoDB의 지정된
테이블과 인덱스에 대해
특정 action만을 허용함

정책을 좀더 상세하게 작성하기 : Conditions(*)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:*“
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": [
"us-east-2"
]
}
}
]
}
IAM
해석: DynamoDB서비스를
us-east-2 리전에서만
이용하도록 허용

Condition : 샘플 IAM
“Condition” : {
"DateGreaterThan" : {"aws:CurrentTime" : "2017-01-01T11:00:00Z"},
"DateLessThan": {"aws:CurrentTime" : "2017-12-31T15:00:00Z"},
"IpAddress" : {"aws:SourceIp" : ["192.0.2.0/24", "203.0.113.0/24"]}
}
AND
OR
특정 시간대에 특정 IP 주소의 요청만 허용하거나 거부하고자 싶으면?
조건 연산자
해석: 다음 조건을 만족할 경우, 사용자가 자원에 접근하는 것을 허용,
{“01/01/2017 오전 11시 이후” AND “12/31/2017 오후 3시까지” AND
“[ IP주소 192.0.2.0 /24 OR 203.0.113.0 /24 대역 ]” 에서’
조건 키

Condition : 조건 연산자(condition operators) IAM
• 문자열
• 숫자
• 날짜 및 시간
• 부울(Bool)
• 이진 조건(Binary)
• IP 주소
• Amazon 리소스 이름(ARN)
• …IfExists : 다른 조건 연산자이름에 붙여서
사용. 리소스 타입 별로 조건 연산자가
있으면 확인하고 없으면 생략.
• Null : 조건 키의 존재를 확인. 주로
임시자격증명의 TokenIssueTime을
체크할때 사용
문자열 조건 연산자 설명
StringEquals 정확한 일치, 대소문자 구분
StringNotEquals 불일치
StringEqualsIgnoreCase 정확한 일치, 대소문자 무시
StringNotEqualsIgnoreCase 불일치, 대소문자 무시
StringLike 대소문자 구분 일치. 이 값에서는 문자열 어디든지
다중 문자 매칭 와일드카드(*) 또는 단일 문자 매칭
와일드카드(?)를 사용할 수 있습니다.
참고
키에 다수의 값이 저장되는 경우에는 설정
연산자(ForAllValues:StringLike, ForAnyValue:StringLik
e)를 사용해 StringLike를 한정할 수 있습니다. 자세한
내용은 여러 키 값을 테스트하는 조건 생성(설정
작업) 단원을 참조하십시오.
StringNotLike 대소문자 구분 불일치. 이 값에서는 문자열 어디든지
다중 문자 매칭 와일드카드(*) 또는 단일 문자 매칭
와일드카드(?)를 사용할 수 있습니다.
https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/reference_policies_element
s_condition_operators.html

Condition : 조건 키(Condition Key) IAM
• Global Condition Key
• 모든 서비스 공통 - aws:CurrentTime, aws:EpochTime, aws:MultiFactorAuthAge, aws:MultiFactorAuthPresent, aws:SecureTransport,
aws:UserAgent
• 일부 서비스에서만 - aws:PrincipalOrgID, aws:PrincipalTag/tag-key, aws:PrincipalType, aws:Referer, aws:RequestedRegion,
aws:RequestTag/tag-key, aws:SourceAccount, aws:SourceArn, aws:SourceIp(*), aws:SourceVpc, aws:SourceVpce, aws:TagKeys,
aws:TokenIssueTime, aws:userid, aws:username
• IAM Condition Key
• IAM 서비스 용 – iam:AWSServiceName, iam:PassedToService, iam:PermissionsBoundary, iam:PolicyARN, iam:ResourceTag/key-name,
• Web-Federation 용 – aws:FederatedProvider, Application ID / User ID, amr Key in Amazon Cognito
• SAML-Federation 용 - SAML Role Trust Policies, SAML Role Permission Policies
• 기타 서비스 별 Key
• 참조 : https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html

정책 변수(Policy Variable) IAM
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::myBucket"],
"Condition":
{"StringLike":
{"s3:prefix":["home/${aws:username}/*"]}
}
},
{
"Effect":"Allow",
"Action":["s3:*"],
"Resource": ["arn:aws:s3:::myBucket/home/${aws:username}",
"arn:aws:s3:::myBucket/home/${aws:username}/*"]
}
]
}
$(Condition Key) 형식으로, 다이내믹하게 변수화.
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html
2012-10-17 버전부터 변수 지원(필수)
Resource 항목의 ARN 마지막 부분에 변수 사용 가능
Condition 항목의 String, ARN에 변수 사용 가능

정책 변수 : 샘플 – 태그 기반의 동적 권한 부여 IAM
EC2 태그의 key 값 “Owner”의 Value가 “내이름” 인 경우에만 Action을 허용하고 싶다면?
해석:
다음 조건을 만족할
경우, 사용자가 자원에
접근하는 것을 허용,
전체 EC2 instance
중 ”Owner” 태그Key의
Value가 해당 정책을
사용하는 IAM User의
username과 일치해야
instance를 start /stop
할 수 있음.
조건 연산자 조건 키 정책 변수

용어 : ABAC ?
• ABAC : Attribute Based Access Control
IAM 보안 주체의 요소(attribute, 예: 태그)를 이용해서 단일 policy로 각기 다른 리소스에 재사용가능한 접근 제어
IAM

ABAC 시나리오 IAM
IAM role (security principal)
• Pegasus 프로젝트에 대해 access-project = peg
• Unicorn 프로젝트에 대해 access-project = uni
• 엔지니어링 팀에 대해 access-team = eng
• 품질 보증 팀에 대해 access-team = qas
목표
• 정책의 재사용
• 모든 직원은 프로젝트와 관계없이 팀의 리소스를 읽을 수 있음
• 모든 직원은 자신의 프로젝트가 소유한 리소스를
업데이트하고 삭제할 수 있음
• 모든 직원은 자신의 역할에 적용되는 리소스에 대해 역할과
동일한 태그값을 가진 리소스만 생성할 수 있음
대상 리소스
• AWS Secret Manager
CASE 2

사용자 정책사용자 태그
CASE 2

역할 정책
태그 수정 거부
정책 수정 거부
태그 기반 요청 허용
태그 기반 요청 허용
CASE 2

정책 - 역할 - 사용자 매핑
역할 정책 역할 이름 역할 태그 사용자 정책 IAM 사용자 사용자 태그
동일
access-peg-engineering
access-project = peg
access-team = eng
cost-center = 987654
동일
(assumerole)
프로젝트 Pegasus
엔지니어
access-team = eng
access-peg-quality-
assurance
access-team = qas
프로젝트 Pegasus 품질
보증
access-team = qas
access-uni-engineering
access-project = uni
access-team = eng
프로젝트 Unicorn
엔지니어
access-team = eng
access-uni-quality-
assurance
access-team = qas
프로젝트 Unicorn 품질
보증
access-team = qas
CASE 2

ABAC 이슈 IAM
CASE 3
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::company-app"
},
{
"Sid": "Read",
"Effect": "Allow",
"Action": [
"s3:GetObjectAcl",
"s3:GetObject",
"s3:GetObjectTagging"
],
"Resource": [
"arn:aws:s3::: company-app/${aws:PrincipalTag/app}/*"
]
},
……...
]
}
• 목표 : s3 에 AWS API 요청을 하고자 하는 보안 주체의 Tag 값에 따라
동적으로 하위 폴더에 대한 권한을 부여하고자 함.
• 이슈 : 만약. s3://company-app/${aws:PrincipalTag/app} 에 대해
정의한 read / write 작업이 access denied 됨.
• 해결 방법 :
Tag 지정 :
EC2에 지정했던 태그
Keyname : app
Value : app1
를 IAM role 에 지정

AWS 정책(Policy)의 종류 IAM
정책 설명 포맷 정의 및 관리
Identity-based 정
책
IAM 보안 주체(IAM 사용자, IAM 그룹의 사용자 집합, IAM 역할)에 할당되어 해당 주체의
권한을 규정
JSON IAM
Resource-based
정책
정책이 할당될 리소스를 기준으로 어떤 보안 주체가 할 수 있(없)는 작업을 규정. JSON 개별 서비스들
IAM Permission
Boundary 정책
IAM 보안 주체 별로 획득할 수 있는 권한의 최대치를 규정 JSON IAM
Organization
SCP
Organization의 OU 또는 개별 어카운트 별로 권한의 최대치를 규정
주로 Root 어카운트의 권한을 제한 시킬 때 사용.
JSON Organization
Session 정책
임시 자격증명의 기존 퍼미션을 해당 세션에 대해서만 제한할 때 사용
AssumeRole*, GetFederationToken API의 파라메터로 전달됨.
JSON STS
ACL 정책
리소스 기준으로 정의하며, 주로 Cross-Account 간의 리소스 공유시, 보안 주체에 대한 접
근을 규정
XML 개별 서비스들
Endpoint 정책 VPC G/W Endpoint에 적용되는 접근제어 정책. 일종의 Resource-based 정책 임. JSON VPC

Identity-based 정책 IAM
보안 주체(principal)에 연결할 수 있는 권한 정책
• 관리형 정책 – 정책이 독립적으로 존재(ARN 부여)하며, 필요한 주체(IAM사용자, 그룹, IAM 역할)와 연결하여 사용
• AWS 관리형 – AWS에서 생성 및 관리, 정책, AWS에서 업데이트, 내용 변경 불가. 직무별 필요 정책 적용 권고.
• 고객 관리형 정책 – 사용자가 요건에 맞게 직접 정의 및 관리, AWS 관리형 정책을 복제하여 커스터마이즈 가능.
• 인라인 정책 – IAM 사용자, 그룹 또는 IAM 역할 내에서 개별로 정의. 해당 객체와 라이프싸이클이 동일.
AWS 관리형 정책

관리형 정책 vs. 인라인 정책 IAM
기능 관리형 정책 인라인 정책
재사용성
다수의 보안 주체(사용자, 그룹 및 역할)에 추가
가능
재사용할 수 없음. 해당 보안주체와
라이프싸이클이 동일(1:1)
중앙 변경 관리
연결된 모든 보안 주체들에게 변경 사항이 일괄
적용됨.
일괄 변경 안됨. 연결된 보안 주체 별로
일일이 편집해야 됨.
버전 관리 및 롤백
고객 관리형 정책의 경우, 최대 5개 버전까지
저장되며 롤백 지원.
N/A
권한 위임 관리 정책 관리 위임 가능 불가능
정책의 자동 업데이트
AWS 관리형 정책의 경우는 자동으로 업데이트
됨.
N/A
• 대부분 경우 인라인 정책보다는 관리형 정책의 사용을 권장합니다.
• 인라인 정책은 그룹 등의 관계로 의도하지 않은 일괄 할당을 예방하거나, 예외 처리 등을
위해 주로 이용됩니다.

AWS 관리형 정책의 업데이트 IAM
• AWS 관리형 정책은 AWS가 업데이트를 진행하며, 추가/변경 내역이 고객의 기존 환경에
영향을 줄 수 있는 경우에는 신규 정책으로 만들어 집니다.
• 이 때, 기존의 Deprecated된 AWS 관리형 정책은 느낌표 표시되며, 고객 서비스에 영향을 줄
수 있기에, 보안주체와의 기존 연결은 유지됩니다.
• Deprecated 정책은 보안주체와의 신규 연결은 불허되며, 향후 보안 주체와의 모든 연결이
없어지면 콘솔에서 사라집니다.

고객 관리형 정책의 버저닝 및 롤백 IAM
유효버전
고객 관리형 정책의 경우, 최대 5개 버전까지 저장되며, 필요시 Default 버전을 이전 버전으로
변경하여 롤백 할 수 있습니다.
롤백

Resource-based 정책 IAM
AWS 리소스에 연결할 수 있는 권한 정책 –
지정된 보안 주체가 해당 리소스에 대해 수행할 수 있는 작업 및 이에 관한 조건을 규정.(인라인 정책만 존재)
• 지원 서비스: S3, Glacier, SNS, SQS, 람다, ECR, API G/W, KMS, Secret Manager, Glue 등
(https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html 참조)
모든 사용자 유형들에 대해 해당 S3 버킷을
공인 IP 54.240.143.0/24 대역 중,
54.249.143.188을 제외한 주소에서 접근해서
모든 S3작업을 수행할 수 있게 허용

Resource-based 정책 IAM
신뢰 정책(Trust Policy)
• IAM서비스에서 지원되는 Resource-based 정책
• 수임(AssumeRole)할 수 있는 IAM사용자나 어카운트에 대한 신뢰 규정. è IAM 역할에 할당됨.

Identity-based vs. Resource-based IAM
{
"Statement":[{
"Effect":"effect",
"Principal":"principal",
"Action":"action",
"Resource":"arn",
"Condition":{
"condition":{
"key":"value" }
}
}
]
}
Principal
Action
Resource
Condition
{
"Statement":[{
"Effect":"effect",
"Action":"action",
"Resource":"arn",
"Condition":{
"condition":{
"key":"value" }
}
}
]
}
Action
Resource
Condition
Identity-based 정책 Resource-based 정책

IAM 로 작업하는 AWS 서비스 IAM

IAM Permission Boundary 정책 IAM
• 권한 관리 위임 체계를 지원하고 사용자의 권한 남용을 최소화 하기 위해, IAM 사용자가 가질
수 있는 최대 권한을 제한시킴. è Identity-based 정책으로 부여된 권한과 교집합 형태로
적용됨(필터 역할)
• 추후 감사 용이하게 하기 위해 사용자가 생성하는 역할에 이름 규칙을 강제할 수 있음

Organization SCP(Service Control Policy) IAM
• Root 어카운트의 AWS서비스 API에 대한 접근을 통제하기 위한 목적(권한의 가드레일)
• 모든 OU, 어카운트는 디폴트로 ‘FullAWSAccess’라는 SCP를 가지고 있음.
• Organization 트리상에서 상속이 지원되며, 다른 정책의 퍼미션 집합과 교집합 처리됨.
• Organization의 Master 어카운트에는 적용 불가

AWS 정책(Policy)의 분류 IAM
AWS 정책 분류
Permission boundaries
: 권한의 제한 용도
Organization SCPs
IAM permission
boundaries
Session 정책
Permission policies
: 권한의 부여 용도
Identity-based 정책
Resource-based 정
책
Access controls lists
(ACLs)
필터 역할 (교집합)

AWS 정책 간의 상호작용 IAM
합집합 교집합 교집합

정책 평가
IAM
Session정책명시적
거부
API 요청
IAM Permission
Boundary
SCP
Identity-based
정책
Resource-based
정책
ACL

Tip : IAM policy 작성 툴
ü IAM Policy Generator :
https://awspolicygen.s3.amazonaws.com/policygen.html
IAM

ü IAM Policy Sentry :
https://policy-sentry.readthedocs.io/en/latest/introduction/home.html
pip 로 설치 가능한 라이브러리로, CRUD 관점에서 ARN 만 나열하면 최소 권한만 갖는 IAM
Policy를 생성
IAM

ü IAM Policy Simulator
https://policysim.aws.amazon.com/home/index.jsp?#
작성한 IAM 정책 테스트
IAM

AWS STS (Simple Token Service)
• AWS 리소스에 대한 액세스를 제어할 수 있는 임시 보안 자격증명을 생성하여 보안 주체에 전달해주는
서비스
• 보안 주체(ex. 사용자 혹은 역할) 는 STS를 호출할 수 있는 명시적인 권한이 있어야함.
• STS API요청에 대한 응답에는 temp credential이 포함되어 있음
• access key
• secret key
• session token : temp credential을 사용하기 위해 API 요청에 제출해야하는 토큰. 세션 토큰을
사용해 임시 보안 자격 증명의 유효성을 검증
• 15초 ~ 최대 12시간까지 지속가능
• https://sts.amazonaws.com 라는 글로벌 단일 엔드포인트를 사용
• 쿼리 API / SDK / CLI를 통해 STS 호출 가능

AWS STS API
AWS STS API 호출할 수 있는 사용자 사용 사례
AssumeRole
- IAM 사용자
- 기존 임시 보안 자격 증명이 있는 IAM 역할
기존 IAM 사용자가 아직 액세스 권한이 없는 AWS 리소스에 접근
AssumeRoleWithSAML
- 유효한 ID provider에서 받은 인증이 포함된 SAML
응답을 전달할 수 있는 (외부) 사용자
SAML 2.0과 호환되는 엔터프라이즈 자격 증명 공급자 (ex. Window AD ,
OpenLDAP) 를 통한 연동
AssumeRoleWithWebIdentity
- 유효한 ID provider에서 받은 인증이 포함된 Web
Identity token 을 전달할 수 있는 (외부) 사용자
웹 기반 자격 증명 공급자를 통한 연동
(ex. Login with Amazon, Facebook, Google 또는 OpenID Connect(OIDC)
호환 자격 증명 공급자)
GetFederationToken
- IAM 사용자
- AWS 계정 루트 사용자
- ** IAM 사용자는 “사람” 보다는 장기 크리덴셜을 가지고
있는 사용자 혹은 어플리케이션으로 이해하는 것이
좋음
연동 사용자에게 임시 자격증명을 반환
(Assumerole 계열과 비슷하지만, role을 assume하지 않고 calller의
권한을 사용하는 것이 차이점)
GetSessionToken
- IAM 사용자
- AWS 계정 루트 사용자
- ** IAM 사용자는 “사람” 보다는 장기 크리덴셜을 가지고
있는 사용자 혹은 어플리케이션으로 이해하는 것이
좋음
모바일 디바이스 혹은 웹 브라우저와 같이 덜 안전한 환경을 통해
접근하는 IAM사용자가 있을 때 MFA 를 활성화하여 엑세스 보안을 강화
참고 : https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_credentials_temp_request.html#stsapi_comparison
API reference : https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html

STS 를 호출할 수 있는 권한
• 역할을 수임 (AssumeRole)할 수 있는 권한을 부여하는 정책
• 연동 사용자에 대해 임시 보안 자격 증명을 생성할 수 있는 사용자 제한 권한을 부여하는 정책

용어 : Session policy IAM

STS 호출로 얻게 되는 권한 제어
MFAGetSessionToken 작업의
목적은 MFA를 사용하는
사용자를 인증하는 것 !

Condition 이슈 – STS 적용 IAM
CASE 3
이슈 : 특정 source ip에 제약을 두고 정책을 구성했는데, CloudFormation 혹은 ElasticBeanstalk 이용에 알 수 없는
제약이 생겼습니다.
EC2와 같은 서비스나 외부 연동자만 role 을 사용하는 것이 아니라, IAM user도 얼마든지 role을 사용할 수 있다!
이슈 원인 :
AWS 서비스들 중 사용자를 대신하여 호출을 수행하는 AWS CloudFormation혹은 Elastic Beanstalk과 같은 서비스는 대상 서비스(예: Amazon
EC2)가 원래 사용자의 IP 주소 대신 호출 서비스(Elastic Beanstalk)의 IP 주소를 보게 되기 때문
해결 방안 :
사용자로 하여금 적절한 권한을 가지고 있는 역할을 assume하게 만들고 그 role의 trust policy를 제어하여 ip 제한을 둘 수 있음.
일반적인 경우 사용자가 적절한 권한(ex. EC2에 대한 접근권한)을 가지고 바로 서비스에 접근을 하지만
이 경우에는 사용자가 STS 권한을 가지고 Role을 assume하고, 그 role이 사용자를 대신하여 서비스에 접근하게 됨
(사용자 > role > 서비스)
IAM User : sts:AssumeRole에 대한 permission policy를,
IAM role : 적절한 권한(ex. Admin권한) 에 대한 permission policy + sourceip 제한을 포함한 trust policy를 가지게 됩니다.
이때, IAM role을 만들 때 무엇을 신뢰정책으로는 Another AWS acccount를 선택하시고 Account ID는 동일 계정 ID를 입력
추가 고려사항 :
작업이 IAM 사용자가 아니라 사용자가 맡은 IAM 역할에 의해 실행되기 때문에 CloudTrail 로그에 지장.

IAM 주요 이슈
1. Static한 IAM 사용자 / 그룹을 통한 관리
체계 - 관리자의 라이프싸이클 기준에
따른 관리 부담
2. 기존 사용자 관리 환경과의 관리 이원화
- 동기화 필요
3. 멀티 어카운트 필요성 증가 – 통합 관리
및 위임 체계 필요
4. 협력업체, 외주 파트너, B2B 등 다양한
사용자 유형에 대한 지원 필요
5. ~ 5,000 IAM Users - Hard Limit
• 해결 방법:
• IAM 역할과 임시 자격증명 활용
• Identity federation
• Amazon Cognito
• AWS SSO
• Custom Identity Broker
• 효과 :
• 많은 수의 IAM 사용자를 줄일 수 있음.
• 기존 운영중인 계정 관리 프로세스를
그대로 활용
• 멀티 어카운트, 파트너/협력 관계 등
다양한 접근 유형들에 대한 유연한 지원

Identity Federation Options
Custom Identity Broker
IAM Federation AWS SSO
IAM Custom
Identity Broker
Cognito User Pool Cognito Identity Pool
저장소(Directory) 고객 / 소셜 고객 / AWS SSO 고객 Cognito User Pool 고객 / 소셜 / CUP
자격증명 공급자(IdP) 고객 / 소셜 AWS SSO 고객 Cognito User Pool 고객 / 소셜 / CUP
AWS 리소스 접근시,
자격증명 교환
IAM AWS SSO 고객
Cognito Identity
Pool
Cognito Identity Pool
주요 용도 AWS 관리콘솔 연계 AWS 관리콘솔 연계 AWS 관리콘솔 연계
비지니스 User 인증 /
인가
비지니스 User 인가
지원 방식 SAML / OIDC SAML Custom SAML / OIDC SAML / OIDC / Custom

Identity Federation Flow chart
멀티 어카운트 환경의 모든 IAM역할들에 대한,
모든 사용자 접근을 통합 관리하고자 할 때
그룹/
속성 기반
인가
SAML
어카운트
2018년 발표 기능 기준(향후 변경 가능)

AWS IAM Identity Federation
• IAM은 OIDC 기반 Web Identity Federation과 SAML 2.0 기반의 Federation을 지원
• OIDC 기반 Web Identity Federation은 IAM 보다 Cognito를 이용할 것을 권장 - Federation
코드(Identity Broker 코드) 작성 불필요
• Federated 사용자를 위한 1개 이상의 IAM 역할 필요

연동된 사용자 API 활동 기록

어카운트 간 접근 관리 : Resource-based 정책 이용 IAM
Resource-based
정책
S3 버킷 IAM principal
AND
IAM principal S3 bucket
1
2
1
2
Identity-based
정책
VPC
AWS Cloud
AWS Cloud
A의 IAM역할을 Principal로
하는 신뢰 정책 설정
B의 리소스에 대한 접근을
허용하는 정책 설정

어카운트 간 접근 관리 : Cross-account Role 이용 IAM
VPC
AWS Cloud
AWS Cloud
다른 어카운트의 IAM 역할을
Assume할 수 있는 in-line
정책을 IAM역할에 설정
A에 대한 신뢰 관계 설정
위임할 권한 정책 정의

IAM Access Advisor IAM
• IAM에 대해 서비스에서 마지막으로 액세스한 데이터를 조회
• 불필요한 권한을 제거하고 least privileged 를 유지할 수 있음
"ServicesLastAccessed": [
{
"LastAuthenticated": "2018-11-21T17:41:15Z",
"LastAuthenticatedEntity": "arn:aws:iam::123456789012:role
"ServiceName": "Amazon EC2",
"ServiceNamespace": "ec2", "TotalAuthenticatedEntities": 1
},

Credential Report IAM
• 계정의 모든 사용자와 암호, 액세스 키, MFA 디바이스 등 자격 증명 상태를 나열하는 보고서
• 감사 및 규정 준수에 도움
마지막으로 password를 바꾼 날짜
MFA 활성화 여부

New !! IAM Access Analyzer IAM
• 리소스에 대한 public 혹은 crosss-account access를 검사하여 과도하게 권한이 주어진 자원을 판별
• analyzer결과로 내 계정 내, 외부에서 액세스 가능한 리소스 리스트를 보여주고, Next step을 제안
• 상시 모니터링 / 탐색으로 정책이 변경되는 순간 탐지 è Security hub로 전달

New !! IAM Access Analyzer IAM

IAM 정책 생성 자동화 개발 팀 테스트 계정 Sandbox
Product 계정 보안 계정
1. 업로드된 IAM Policy
유효성 검증
2. 필수 ”명시적 Deny”
추가
3. 사용자 계정 내 최종
Policy 생성

오픈 소스를 활용한 IAM 권한 관리 IAM
Aardvark Repokid
미사용 서비스 삭제
Policy 사용 체크
90일 이상?
미사용 서비스?
커스텀 정책
Yes
Yes
Yes
No
No
No
반복 체크
IAM 의 Access Advisor 정보를 조회 불필요한 권한 삭제

주요 IAM Limit
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-limits.html
리소스 Limit
Root, IAM 사용자 당 할당되는 엑세스 키 2개
IAM 사용자 당 소속 그룹 수 10개
한 어카운트 내 IAM사용자 수 5,000명(*)
어카운트 당 SAML 제공자 수 100개
IAM 사용자, 역할, 그룹 당 관리형 정책 10개
IAM User, 역할 당 Permission Boundary 수 1개
EC2 프로파일 당 역할 수 1개
Root, IAM 사용자 당 MFA 디바이스 수 1개
IAM 사용자 당 SSH 퍼블릭 키 수 2개
항목 Limit
IAM 사용자/그룹/역할 이름 64 자 / 128자 / 64자
ARN내 Path 512자
IAM 역할 신뢰 정책 2,048자(**)
인라인 정책
IAM 사용자 : 2,048자(**)
IAM 역할 : 10,240자(**)
IAM 그룹 : 5,120자(**)
관리형 정책 6,144자(**)
IAM 사용자 인라인 정책 2048자(**)
임시 자격증명
IAM 정책 변수

1. AWS 계정 루트 사용자 액세스 키 잠금
2. 개별 IAM 사용자 만들기
3. 그룹을 사용하여 IAM 사용자에게
권한을 할당합니다.
4. 최소 권한 부여
5. AWS 관리형 정책으로 권한 사용 시작
6. 인라인 정책 대신 고객 관리형 정책 사용
7. 액세스 레벨을 이용한 IAM 권한 검토
8. 사용자에 대한 강력한 암호 정책 구성
9. 권한 있는 사용자에 대해 MFA 활성화
10. Amazon EC2 인스턴스에서 실행되는
애플리케이션에 역할 사용
11. 역할을 사용하여 권한 위임
12. 액세스 키를 공유하지 마십시오
13. 자격 증명을 정기적으로 교체
14. 불필요한 자격 증명 삭제
15. 보안 강화를 위해 정책 조건 사용
16. AWS 계정의 활동 모니터링
17. IAM 모범 사례에 대한 동영상
프레젠테이션
IAM 모범사례

1. AWS 계정 루트 사용자 액세스 키 잠금
2. 개별 IAM 사용자 만들기 3. 그룹을 사용하여 IAM 사용자에게 권한을 할당합니다.

4. 최소 권한 부여
일정 기간 또는 한번도 접근 안한 서비스들에 대한
권한은 점차적으로 회수할 것을 권장

5. AWS 관리형 정책으로 권한 사용 시작
Permission Policy와 Permission Boundary로 사용된 경우를 표시

6. 인라인 정책 대신 고객 관리형 정책 사용
고객 관리형 정책을 정의하고 적용전에 반드시, 시뮬레이션 해 볼 것을 권장

7. 액세스 레벨을 이용한 IAM 권한 검토
폴딩을 풀고, Policy Summary를 클릭해서 사용자에게 부여된 권한(Access Level)을 확인폴딩을 풀고, Policy Summary를 클릭해서 사용자에게 부여된 권한(Access Level)을
확인
폴딩을 풀고, Policy Summary를 클릭해서 사용자에게 부여된 권한(Access Level) 확인

8. 사용자에 대한 강력한 암호 정책 구성 9. 권한 있는 사용자에 대해 MFA 활성화

10. Amazon EC2 인스턴스에서 실행되는 애플리케이션에 역할 사용
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"iam:PassRole",
"iam:ListInstanceProfiles",
"ec2:*"
],
"Resource": "*"
}]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::<account-id>:role/Get-pics"
}
]
}
EC2에 IAM역할을 부여할 수 있는 정책 EC2에 특정 IAM역할만 부여할 수 있도록 제한
부여자 보다 많은 권한을 갖는
IAM역할을 EC2에 줄 수 있는 가능성
부여자에게 EC2에 줄 수 있는 역할을 한정시켜줌.

11. 역할을 사용하여 권한 위임
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource":
"arn:aws:iam::Account_B_ID:role/Account_B_IAM_Role_Name"
}
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
신뢰정책(Trust Policy)
VPC
AWS Cloud
AWS Cloud
다른 어카운트의 IAM 역할을
Assume할 수 있는 in-line
정책을 IAM역할에 설정
A에 대한 신뢰 관계 설정
위임할 권한 정책 정의

IAM
12. 액세스 키를 공유하지 마십시오
역할의 임시 자격증명이 유출되었을 경우, ‘활성세션 즉시 취소’를 통해 임시 자격증명을
무효화할 것을 권장
특정 IAM사용자의 엑세스키 페어가 유출되었을 경우,
즉시 키를 교체하고, 해당 키를 비활성화 처리

13. 자격 증명을 정기적으로 교체
콘솔이나 Credential Report를 통해 교체 주기를 지난
IAM사용자의 자격증명들을 파악해서 조치
콘솔이나 Credential Report를 통해 교체 주기를 지난
IAM사용자의 자격증명들을 파악해서 조치

14. 불필요한 자격 증명 삭제
사용하지 않는 리전에 대한 STS의 임시
자격증명 발급 기능 비 활성화
콘솔 로그인 이력과 엑세스키 사용이력을 통해
불필요한 IAM사용자 식별
콘솔 로그인 이력과 엑세스키 사용이력을 통해
불필요한 IAM사용자 식별

"Condition" : {
"DateGreaterThan" : {
"aws:CurrentTime" : "2013-08-16T12:00:00Z"
},
"DateLessThan": {
"aws:CurrentTime" : "2013-08-16T15:00:00Z"
},
"IpAddress" : {
"aws:SourceIp" : ["192.0.2.0/24", "203.0.113.0/24"]
}
}
15. 보안 강화를 위해 정책 조건 사용
ANDAND
OR

16. AWS 계정의 활동 모니터링
• AWS Solutions - https://aws.amazon.com/ko/solutions/real-time-insights-account-activity/
대쉬보드
• the number of API calls by service
• the total API calls and anomaly score
• the top 10 API calls
• the top 10 IAM users
• the maximum calls by IP
• the top calls by IP address
• the number of successful EC2 API calls

실전 시나리오

실전 시나리오
AWS Organization
Organizational Unit (OU)
이름: Zombie
Organizational Unit (OU)
이름: Unicorn

실전 시나리오
중요 작업을 금지
허용된 리전에서만
적법하게 IAM역할을 생성

실전 시나리오
권한을 분리

실전 시나리오
요건 1. 어카운트 간 권한 가드레일 설정
요건 2. 리소스 생성 시, 리전 조건 포함
요건 3. IAM 역할의 생성을 안전하게 통제
요건 4. 권한 관리의 확장성을 위해 태그 조건 사용
각 AWS 정책들과 요건 간 맵핑
S e r v ic e c o n tro l po lic ie s ( S C Ps)
Re so u rc e - base d 정책
IAM Pe r m issio n s bo u n dar ie s
세션 정책
E n dpo in t 정책
Ide n tity- base d 정책

실전 시나리오
Pro Tip: 명시적인 Deny
정책을 작성
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyUnapprovedAction",
"Effect": "Deny",
"Action": [
"ds:*",
"iam:CreateUser",
"cloudtrail:StopLogging"
],
"Resource": [
"*"
]
}
]
}
Don’t Forget!
Organization의 Root
OU에는 모든 작업을
허용하고 있는
‘FullAWSAccess’라는
Allow 정책이
있습니다.

실전 시나리오
Pro Tip: ‘RequestedRegion’
조건 이용
{
"Effect": "Allow",
"Action": [
"ec2:Describe*",
"ec2:Get*",
"s3:ListBucket",
"s3:ListAllMyBuckets",
"iam:list*"
],
"Resource": "*"
}
{
"Effect": "Allow",
"Action": [
"secretsmanager:*",
"lambda:*",
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion":[
"us-west-1",
"us-west-2"
]
}
}
}
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:key-pair/*",
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*::snapshot/*",
"arn:aws:ec2:*:*:launch-template/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:placement-group/*",
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*::image/*"
],
"Condition": {
"StringEquals": {
"aws:RequestedRegion":[
"us-west-1",
"us-west-2”
]
}
}
}

실전 시나리오
Pro Tip: 프로젝트 이름 기준
명명규칙 조건을 활용하고,
IAM Permission Boundary
조건 이용
{
"Effect": "Allow",
"Action": [
"iam:CreatePolicy",
"iam:CreatePolicyVersion",
"iam:DeletePolicyVersion"
],
"Resource": "arn:aws:iam::<account-id>:policy/unicorn-*"
}
{
"Effect": "Allow",
"Action": [
"iam:DetachRolePolicy",
"iam:CreateRole",
"iam:AttachRolePolicy"
],
"Resource": "arn:aws:iam::<account-id>:role/unicorn-*",
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::<account-id>:policy/region-restriction"
}
}
}
{
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:PassRole"
],
"Resource": "arn:aws:iam::<account-id>:role/unicorn-*"
}
Unicorn이름의 정책생성과 버전관리를
허용하는 권한정책을 Unicorn
개발자에게 부여
RegionRestriction 정책을 Permission Boundary조건으로
포함하고, Unicorn이름으로된 IAM역할 생성과 정책 할당
권한을 허용하는 권한 정책을 Unicorn 개발자에게 부여
Unicorn 개발자들이 EC2나 람다에 Unicorn이름의
IAM역할만 Pass 할 수 있도록 하는 정책을 적용

실전 시나리오
Pro Tip: ResourceTag,
RequestTag 등의 조건을 활용
{
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "RunInstances"
}
}
}
{
"Effect": "Allow",
"Action": "ec2:RunInstances"
"Resource": "arn:aws:ec2:*:*:instance/*”
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": ["project","name"]
},
"StringEquals": {
"aws:RequestTag/project": ["dorky"],
}
}
}
{
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/project": ["dorky"]
},
},
"StringEqualsIfExists": {
"aws:RequestTag/project": ["dorky"]
}
}
}
{
"Effect": "Allow",
"Action": [
"ec2:StartInstances",
"ec2:StopInstances"],
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/project": "dorky"
}
}
}

실전 시나리오
Pro Tip: Policy
Variable을 활용
{
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "RunInstances"
}
}
}
{
"Effect": "Allow",
"Action": "ec2:RunInstances"
"Resource": "arn:aws:ec2:*:*:instance/*”
"Condition": {
},
"StringEquals": {
"aws:RequestTag/project": ["${aws:PrincipalTag/project}"],
}
}
}
{
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/project": ["${aws:PrincipalTag/project}"]
},
},
"StringEqualsIfExists": {
"aws:RequestTag/project": ["${aws:PrincipalTag/project}"]
}
}
}
{
"Effect": "Allow",
"Action": [
"ec2:StartInstances",
"ec2:StopInstances"],
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/project": "${aws:PrincipalTag/project}"
}
}
}

IAM 샘플 정책
AWS
• 지정 날짜 범위 동안의 액세스 허용 (이 정책 보기)
• 지정 날짜 범위 동안 MFA를 사용하는 경우 특정 액세스를 허용(이 정책 보기)
• 소스 IP 주소를 바탕으로 AWS에 대한 액세스 거부(이 정책 보기)
정책 예제: AWS CodeCommit
• 프로그램 방식으로 콘솔에서 AWS CodeCommit 리포지토리에 대한 Read 액세스 허용(이 정책 보기)
정책 예제: AWS Data Pipeline
• 사용자가 생성하지 않은 파이프라인에 대한 액세스 거부(이 정책 보기)
정책 예제: Amazon DynamoDB
• 특정 Amazon DynamoDB 테이블에 대한 액세스 허용(이 정책 보기)
• 특정 Amazon DynamoDB 열에 대한 액세스 허용(이 정책 보기)
• Amazon Cognito ID를 기준으로 Amazon DynamoDB에 대한 행 수준 액세스를 허용(이 정책 보기)
정책 예제: Amazon EC2
• Amazon EC2 인스턴스가 볼륨을 연결 또는 분리하도록 허용 (이 정책 보기)
• 태그를 기준으로 Amazon EBS 볼륨을 Amazon EC2 인스턴스에 연결 또는 분리하도록 허용(이 정책 보기)
• 특정 서브넷에 있는 Amazon EC2 인스턴스를 프로그래밍 방식으로 콘솔에서 시작할 수 있도록 허용(이 정책 보기)
• 특정 VPC와 관련된 Amazon EC2 보안 그룹을 프로그래밍 방식으로 콘솔에서 관리할 수 있도록 허용(이 정책 보기)
• 사용자가 태그를 지정한 Amazon EC2 인스턴스를 프로그래밍 방식으로 콘솔에서 시작 또는 중지할 수 있도록 허용(이 정책 보기)
• 리소스 및 보안 주체 태그 기반의 Amazon EC2 인스턴스를 프로그래밍 방식으로 콘솔에서 시작 또는 중지할 수 있도록 허용(이 정책 보기)
• 리소스 및 주요 태그가 일치할 때 Amazon EC2 인스턴스를 시작 또는 중지할 수 있도록 허용(이 정책 보기)
• 특정 리전 내에서의 모든 Amazon EC2 액세스를 프로그래밍 방식으로 콘솔에서 허용(이 정책 보기)
• 프로그래밍 방식으로 콘솔에서 특정 Amazon EC2 인스턴스를 시작 또는 중지하고 특정 보안 그룹을 수정할 수 있도록 허용(이 정책 보기)
• Amazon EC2 인스턴스 종료를 특정 IP 주소 범위로 제한(이 정책 보기)

IAM 샘플 정책
AWS Identity and Access Management(IAM)
• 정책 시뮬레이터 API에 대한 액세스 허용(이 정책 보기)
• 정책 시뮬레이터 콘솔에 대한 액세스 허용(이 정책 보기)
• 프로그래밍 방식 및 콘솔에서 특정 태그가 있는 IAM 사용자에게 또 다른 특정 태그를 추가할 수 있도록 허용(이 정책 보기)
• 프로그래밍 방식 및 콘솔에서 IAM 사용자 또는 역할에게 특정 태그를 추가할 수 있도록 허용(이 정책 보기)
• 특정 태그가 있는 새 사용자만 만들 수 있도록 허용(이 정책 보기)
• 특정 태그를 관리하도록 허용(이 정책 보기)
• 특정 경로를 지닌 사용자에 대해 정책 시뮬레이터 API의 사용을 허용(이 정책 보기)
• 특정 경로를 지닌 사용자에 대해 정책 시뮬레이터 콘솔의 사용을 허용(이 정책 보기)
• IAM 사용자가 MFA 디바이스를 스스로 관리하도록 허용(이 정책 보기)
• IAM 사용자가 프로그램 방식으로 콘솔에서 자신의 자격 증명을 교체하도록 허용(이 정책 보기)
• 신규 IAM 사용자, 그룹 또는 역할에 적용 가능한 관리형 정책을 제한(이 정책 보기)
Amazon RDS
• 특정 리전에 있는 Amazon RDS에 대한 완전한 액세스 허용(이 정책 보기)
• Amazon RDS 데이터베이스를 프로그램 방식으로 콘솔에서 복원하도록 허용(이 정책 보기)
• 태그 소유자가 자신이 태그를 지정한 Amazon RDS 리소스에 대한 모든 액세스 권한을 가지도록 허용(이 정책 보기)
Amazon S3
• Amazon Cognito 사용자가 자신의 Amazon S3 버킷에 있는 객체에 액세스하도록 허용(이 정책 보기)
• IAM 사용자가 프로그램 방식으로 콘솔에서 Amazon S3에 있는 자신의 홈 디렉터리에 액세스하도록 허용(이 정책 보기)
• 사용자가 하나의 Amazon S3 버킷을 관리하고 다른 모든 AWS 작업 및 리소스를 거부하도록 허용(이 정책 보기)
• 특정 Amazon S3 버킷에 대한 Read 및 Write 액세스 허용(이 정책 보기)
• 특정 Amazon S3 버킷에 대해 프로그래밍 방식으로 콘솔에서 Read 및 Write 액세스 허용(이 정책 보기)

yijeong@amazon.com

202003 AWS ISV/DNB IAM_webinar

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 202003 AWS ISV/DNB IAM_webinar

Similar to 202003 AWS ISV/DNB IAM_webinar (20)

202003 AWS ISV/DNB IAM_webinar