DEVELOPyo

[ IAM Conditions ]

명시한 두 아이피 대역을 제외한 모든 클라이언트 호출을 제한함

Deny everything(*) 

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 에 대한 권한 없음.

[ AWS CLI Configuration ] 

properly configure the CLI

1. Bad way

User 의 security credential 정보 (access key id/secret access key)를 사용하여(aws configure 명령어를 통해) EC2 에 인증 및 사용하는 방법은 보안에 취약하므로 로컬 및 사내망이 아닌 경우 지양

- We could run 'aws configure' on EC2.

- This ways is super insecure, never put your personal credentials on an EC2

- your personal credentials are personal and only belong on your personal computer

- If the EC2 is compromised, so is your personal account

- If the EC2 is shared, other people may perform AWS actions while impersonating you

> aws configure

> user 의 access key id 입력

> user 의 secret access key 입력

> region name 입력

> cat ~/.aws/credentials 로 로그인한 계정의 정보(access key id/secret access key)를 열람 할 수 있음 (보안에 취약)

2. Right way

IAM Role 과 policy를 설정하여 EC2 인스턴스에 인증하는 방식을 사용

- IAM Roles can be attached to EC2 instances

- IAM Roles can come with a policy authorizing exactly what the EC2 instance should be able to do

- EC2 Instances can the use these profiles automatically without any additional configurations

* JSON generator(설정권한 등을 UI로 확인 및 선택 가능) 를 사용하여 IAM JSON 을 쉽게 생성 할 수 있음

* Simulator 를 사용하여 설정한 IAM Role/policy에 대한 테스트가 가능

[ AWS EC2 Instance Metadata ]

CLI 에서 curl http://169.254.169.254/latest/meta-data 을 통해 메타데이터 정보를 가져올 수 있음

- AWS EC2 Instance Metadata is powerful but one of the least known features to developers

- It allows AWS EC2 instances to "learn about themselves" without using an IAM Role for the purpose

- The URL is http://169.254.169.254/latest/meta-data

- You can retrieve the IAM Role name from the metadata, but you cannot retrieve the IAM Policy

  Metadata = Info about the EC2 instance

  Userdata = launch script of the EC2 instance

ex) 1. curl http://169.254.169.254/latest/meta-data/hostname

     2. curl http://169.254.169.254/latest/meta-data/iam/security-credentials/{EC2RoleName}

[ AWS SDK ]

- What if you want to perform actions on AWS directly from your applications code? (without using CLI)

- You can use an SDK (software development kit)

- Official SDKs are Java/.NET/Node.js/PHP/Python etc.

- We have to use the AWS SDK when coding against AWS Services such as DynamoDB

- AWS CLI uses the Python SDK(boto3)

* If you don't specify or configure a default region, then us-east-1 will be chosen by deafult

- It's recommend to use the default credential provider chain

- The default credential provider chain works seamlessly with:

  AWS credentials at ~/.aws/credentials (only on our computers or on premise)

  Instance Profile Credentials using IAM Roles (for EC2 machines, etc..)

  Environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)

- Overall, Never Ever Store AWS Credentials in your code.

# Exponential Backoff

- Any API that fails because of too many calls needs to be retried with Exponential Backoff

- These apply to rate limited API

- Retry mechanism included in SDK API calls

[ 1. AZ (Availability Zones) ]

AWS 의 물리적 자원은 지역적 제약조건이 있다

region 은 지역, Availability Zones 은 지역 밑에 물리적으로 분리되어있는 더 작은 지역의 개념.

AZ 밑의 각각의 데이터센터는 서로 떨어져 있으므로 재난으로부터 동시에 영향을 받지 않는다

EC2 인스턴스는 region 기반, IAM 은 global (region 제약이 없음)

each region has many availability zones ( min 2, max 6)

eg) ap-southeast-2 has following AZs.

ap-southeast-2a

ap-southeast-2b

ap-southeast-2c

1) Each AZ is one or more discrete data centers with redundant power, networking and connectivity

2) They're separate from each other, so that they're isolated from disasters

3) They're connected with high bandwith, ultra-low latency networking

* EC2 based on region

* IAM is global

* Some service is not offered in some regions

(can check at AWS > Regional Table)

[ 2. IAM (Identity and Access Management) ]

AWS 보안 관련 설정으로 Users/Groups/Roles/Policies 등의 설정이 있다

IAM 설정은 Global

Root 계정(AWS계정)의 직접 사용을 지양하고 IAM 으로 Admin 계정/그룹을 생성하여 Admin policies 를 부여, Admin 계정을 대신 사용한다

Your whole AWS security is there:

- Users : physical person

- Groups : contains users

- Roles : internal usage within AWS resources (for machine)

- Policies : AdministratorAccess, ... 등

Root account should never be used (and shared)

Users must be created with proper permissions

IAM is at the center of AWS

Policies are written in JSON

IAM has a global view(can be across all the regions)

Permissions are governed by Policies(JSON)

MFA(Multi Factor Authentication) can be setup (do not use root account)

IAM has predefined "managed policies"

It is best to give users the minimal amount of permissions thy need to perform their job (least privilege principles)

# IAM Federation (for big enterprise)

big enterprises usually integrate their own repository of users with IAM

this way, one can login into AWS using their company credentials

Identity Federation uses the SAML standard (Active Directory)

*

One IAM User per physical person

One IAM Role per application

IAM credentials should never be shared

never write IAM credentials in code. ever.

and even less, never commit your IAM credentials.

never use the root account except for initial setup.

never use ROOT IAM credentials

[ IAM 최초 Admin 설정 ]

1. activate MFA (multi factor authentication)

continue to security credentials 버튼 클릭

virtual MFA device 클릭

google OTP app download 

OTP app으로 QR 코드 인식 후 auth code 1, 2 입력

2. User 생성 (Admin)

access type programatic access 체크

AWS management console access 체크

Console password : autogenerated password

require password reset : user must create a new password at next login 체크

Attach existing policies > AdministratorAccess 체크

Create user without a permissions boundary 체크

* user 생성 완료 페이지에서 유저 정보가 있는 .csv 파일 다운로드

3. Group 생성 (Admin)

AdministratorAccess policy 체크

4. Group 에 2에서 생성한 Admin User 추가

5. User의 Admin policy 재설정

User 설정에서 User 에 직접 부여된(Attached directly) Admin 권한 제거 

6. IAM password policy 설정

enable password expiration 등등

7. IAM users sign-in link 커스터마이징

IAM users sign-in link 우측의 customize 버튼 클릭 후 link alias 입력

8. link 에 접속후 생성한 Admin User 아이디로 로그인 및 패스워드 변경(최초 로그인은 2에서 다운로드 받은 .csv 파일에 적혀있음)