aws:SourceIP: restrict the client IP from which the API calls are being made
명시한 두개의 region 에게 ec2/rds/dynamodb 의 모든 액션을 허용
aws:RequestedRegion: restrict the region The API calls are made to
restrict based on tags
force MFA
[ IAM for S3 ]
ListBucket permission applies to
arn:aws:s3:::test
=> bucket level permission
GetObject, PutObject, DeleteObject applies to
arn:aws:s3:::test/*
[ IAM Roles vs Resource Based Policies ]
Attach a policy to a resource (ex: S3 bucket policy) vs attaching of a using a role as a proxy
way1. Account A 가 Account B 의 S3 를 사용하려면 STS 를 사용하여 role assume 후 Account B 의 S3 접근
=> When you assume a role (user, application or service), you give up your original permissions and take the permissions assigned to the role
way2. S3 bucket policy 생성 후 Account A 의 액세스를 허용.
=> When using a resource based policy, the principal doesn't have to give up his permissions
way1의 role assume 을 사용할 때의 문제점 :
Account A 의 DynamoDB 테이블 스캔 후 타계정의 S3 bucket 에 저장할 때 Account B의 권한만 갖게 되므로 Account A 의 권한이 없어짐. 이와 같은 경우 Resource Based policy 를 사용해야함.
ex: User in account A needs to scan a DynamoDB table in Account A and dump it in an S3 bucket in AccountB
Resource Based policy Supported by : Amazon S3 buckets, SNS topics, SQS queues
[ IAM Permission Boundaries ]
IAM Permission Boundaries are supported for users, groups and roles
Advanced feature to use a managed policy to set the maximum permissions and IAM entity can get
IAM Policy 로 유저생성 권한을 주었지만 IAM Permission Boundary 로 S3, cloudwatch, ec2 에 대한 권한만 주었기 때문에 실제론 아무 권한이 없음.
=> IAM Policy 로 권한을 부여해도 IAM Permission Boundary 가 우선적으로 권한을 제어
[ IAM Permission Boundaries ]
Can be used in combinations of AWS Organizations SCP
Organizagions SCP , Permissions boundary, Identity-based policy 를 조합하여 효율적인 권한제어 가능
특정 유저에게만 권한 제어 가능, 개발자들이 스스로 admin 권한을 주는 것을 막을 수 있음.. 등등
1. Delegate responsibilities to non administrators within their permission boundaries, for example create new IAM users
2. Allow developers to self-assign policies and manage their own permissions, while making sure they can't escalate their privileges (make themselves admin)
3. Useful to restrict one specific user (instead of a whole account using Organizations & SCP)
[ IAM Policy Evaluation Logic ]
[ Example IAM Policy ]
1.sqs:CreateQueue 권한 없음 : sqs:* 가 Deny
2.sqs:DeleteQueue 권한 없음 : Deny on sqs:* 이로 다른블럭에 allow 로 명시되어 있어도 Deny.
3.ec2:DescribeInstance 권한 없음 : EC2에 대해 Allow 명시되어 있지 않으므로 (no explicit Allow) EC2 에 대한 권한 없음.
Create your own AD in AWS, managed users locally, supports MFA
Establish "trust" connections with your on-premise AD
- AD Connector
Directory Gateway (proxy) to redirect to on-premise AD, supports MFA
Users are managed on the on-premise AD
- Simple AD
AD-compatible managed directory on AWS
Cannot be joined with on-premise AD
[ AWS Organizations ]
- Global sevice
- Allows to manage multiple AWS accounts
- The main account is the master account - you cannot change it
- Other accounts are member accounts
- Member accounts can only be part of one organization
- Consolidated(병합된) Billing across all accounts - single payment method
- Pricing benefits from aggregated usage (volume discount for EC2, S3..)
- API is available to automate AWS account creation
[ Multi Account Strategies ]
- Create accounts per department, per cost center, per dev/test/prod, based on regulatory restrictions (using SCP), for better resource isolation (ex:VPC), to have separate per-account service limits, isolated account for logging
- Multi Account vs One Account Multi VPC
- Use tagging standards for billing purposes
- Enable CloudTrail on all accounts, send logs to central S3 account
- Send CloudWatch Logs to central logging account
- Establish Cross Account Roles for Admin purposes
[ Organizational Units (OU) - Examples ]
[ Service Control Policies (SCP) ]
IAM 작업에 대한 화이트/블랙 리스트
OU 혹은 계정에 적용
마스터 계정엔 적용되지 않음
ROOT 를 포함한 모든 계정 및 Role 에 적용
service-linked role 엔 적용되지 않음
SCP 는 명시적 허용이 있어야함 (default 는 모든 권한이 없음)
특정 서비스에 대한 액세스 제한 등 권한 제한용으로 사용 가능
- Whitelist or blacklist IAM actions
- Applied at the OU or Account level
- Does not apply to the Master Account
- SCP is applied to all the Users and Roles of the Account, including ROOT
- The SCP does not affect service-linked roles
Service-linked roles enable other AWS services to integrate with AWS Organizations and can't be restricted by SCPs
- SCP must have an explicit Allow (does not allow anything by default)
- Use cases :
Restrict access to certain services (for example : can't use EMR)
Enforce PCI compliance by explicitly disabling services
[ SCP - Hierarchy ]
하위 계층의 OU는 상위 계층의 OU 의 Access/Deny 정책을 따름
ex: Account B 는 Lambda와 Redshift 액세스 불가, Account A 는 Redshift 액세스 불가
[ AWS Organization - Moving Accounts ]
다른 organization 으로 계정 옮길 땐 asis organization 에서 계정 제거 후 tobe organization 에 초대 및 초대 수락하여 옮김
