AWS IAM 고급

AWS Organizations

글로벌 서비스, 다수의 AWS계정을 동시에 관리할 수 있도록 해준다.

조직을 생성하면 조직의 메인 계정이 관리 계정이 된다. 조직에 가입 한 기타 계정이나, 

조직에서 생성한 계정은 멤버 계정이라고 불린다. ( 멤버 계정은 한 조직에만 소속됨 )

 

OU라는(루트 조직 단위) 것 안에 멤버 계정을 만들 수 있고 OU안에 또 OU를 만들어서 관리할 수 있다.

 

Organization의 장점은 무엇일까

다수의 계정을 가지므로 다수의 VPC를 가진 단일 계정에 비해 보안이 뛰어나다.

계정이 VPC보다 독립적이기 때문이다. 청구 목적의 태그 기준을 적용할 수 있다.

한 번에 모든 계정에 대해 cloudtrail을 활성화 해서 모든 로그를 중앙 S3계정으로 전송할 수 있다.

SCP라는 특정 OU또는 계정에 적용되는 IAM정책으로 해당 사용자와 역할 모두가 계정 내에서 할 수 있는 일을 제한한다.

일반적으로 루트 OU에는 FullAWSAccess SCP를 적용한다. 따라서 루트 OU내의 계정은 모두 계정에 대한 전체 권한을 갖는다.

만약 이 계정에 deny권한을 넣더라도 적용되지 않는다. 

관리 OU에는 DenyRedshift SCP를 적용. 하는 등 다른 하위의 OU에 대해서 각 각의 SCP를 적용할 수 있다.

OU에도 SCP를 적용하고 계정에도 SCP를 적용할 수 있다. OU안에 있는 계정들은 OU에 있는 권한이 자동 적용이 된다.

 

만약 A라는 OU에 denyRedshift SCP가 적용되어있고 그 안에 b라는 계정을 만들어 계정에 authorizeRedshift SCP를 적용 시켜도 

redshift에는 접근할 수 없다. 정책에 명시적 거부가 하나라도 포함되면 기본적으로 액세스가 거부된다. 

 

또 A OU밑에 C OU가 있고 d 계정이 있다면

d계정은 최상위 OU A OU 의 SCP를 상속받는다. 최상위 SCP fullAWSAccess를 를 상속 받지만

A OU에서 denyRedshift, C OU에서 denyLambda를 상속받으면 fullAWSAccess에서 점점 권한이 줄어들게 되는 것이다.

 

권한을 줄 때 처음에 전부 다 주고 하나하나씩 블록해 나가는 방식과

아무 권한이 없는 상태로 필요한 권한을 하나 하나씩 허용해주는 방식이 있다.

 

이게 같은 계정 내에 있는 IAM유저에게 적용하는 것이아니라

아예 다른 계정에 있는 것에 적용하는 것이다.

s3 deny access ou에 있는 계정은 자신의 계정에서 s3에 접속이 안되는 것을 확인할 수 있다.

심지어 루트 계정으로 로그인해도 아예 그냥 계정자체의 권한을 다 막아버린 것이다.

 

 

IAM Conditions

iam 조건은 iam 내부의 정책에 적용되며

사용자 정책일 수도 있고,

s3버킷에 대한 리소스 정책일 수도 있다.

엔드포인트 정책 등 어떤 정책도 될 수 있다.

 

첫번째 조건은 aws:SourceIp이다.

API호출이 생성되는 클라이언트 IP를 제한하는데 사용되는 조건이다.

effect : deny

notIpAddress

 aws:sourceIP : [회사 IP들]

여기에 적힌 회사 아이피 말고는 API호출이 거부된다는 뜻이다. 

 

다음 조건은 aws:ReqeustedRegion이다.

aws로 시작하므로 글로벌 조건이며, api호출 리전을 제한한다.

effect : deny

action [ec2:*,rds:*,dynamodb:*]

stringEqules

 aws:RequestRegion ; [리전들]

여기에 적힌 리전들에서 오는 ec2, rds, dynamoDB호출을 제한한다.

특정리전에서 특정서비스에 대한 액세스를 거부한다.

 

다음은 ec2:ResourceTag이다.

태그의 접두사가 ec2이다. 따라서 이 조건은 ec2 인스턴스의 태그에 적용된다. 

 

s3버킷에 resource에서 object레벨에 관한 제어를하려면 마지막에 /*를 적어주어야한다. 

test/* 이렇게 적으면 객체 레벨 제어 가능

test 만적으면 버킷 레벨 제어만

 

aws:PrincipalPrgID라는 조건은 

AWS조직의 멤버 계정만 리소스 정책이 적용되도록 제한하는 것이다.

 

다수의 멤버가 포함된 조직이 있고, s3버켓이 있다고 가정하 ㄹ때 

aws:PrincipalOrgID에 조직의 아이디를 적어두면 그 조직에 해당된 멤버들이 해당 권한을 가질 수 있다. 

( 액세스, 입력 ) 조직 외부자는 s3버킷 정책에 의해 액세스 거부된다.

 

IAM역할과 리소스 기반 정책의 근본적인 차이점

교차 계정의 경우 가령 s3버킷 교차 계정에서 api호출을 수행하려면 두가지 방법이 있다.

s3버킷에 s3정책을 적용하는 것처럼 리소스에 리소스 기반 정책을 추가할 수도 있고,

리소스에 액세스할 수 있는 역할을 사용할 수도 있다.

 

 

계정 A , B가 있고 계정 B에 버킷이 하나 있다고 가정해보자 S3에 접근하는 방법은 2가지 있다./

 

계정 A 의 사용자가 S3버킷에 대한 액세스 권한이 있는 계정 B의 역할을 사용한다.

아니면 계정 A의 사용자가 계정 B의 S3버킷에 적용된 버킷 정책을 통해 S3 버킷에 액세스 할 수도 있다.

 

첫번째는 IAM역할이 S3버킷에 액세스를 했고 

두번째는 s3버킷 정책이 사용자의 액세스를 허용했다.

 

역할을 맡으면 가지고 있던 기존의 권한을 모두 포기하고 해당 역할에 할당된 권한을 상속하게 된다.

따라서 해당 역할에 부여된 작업은 할 수 있지만 기존의 권한은 사용할 수 없다.

 

대신 리소스 기반 정책을 사용하면 본인이 역할을 맡지 않으므로 권한을 포기할 필요가 없다.

예를들어 한 계정이 본인 계정의 dynamoDB테이블을 스캔해 계정B의 s3버킷에 넣을 경우에는

리소스 기반 정책을 사용하는 것이 좋다. 

 

역할을맡을 필요가 없으므로 dynamoDB테이블을 스캔하고 다른 계정의 s3버킷에 쓰기 작업도 할 수 있다.

( 자신의 계정에 db에 접ㅈ근할 수있는 역할이 따로 존재 해도 되고 , 다른 계정의 s3버킷에는 리소스 정책으로 나의 아이피같은걸 열어두면 되니까 이렇게 사용가능한데 만약 다른 계정의 iam역할을 사용하게되면 다른계정의 s3버킷에는 들어갈 수 있을지 몰라도 자신의 계정 db에는 못들어 간다. 그 이유는 위에서 말했듯이 기존의 권한은 사용할 수 없게 되니까 ) 

 

이 차이는 eventBridge에서 사용할 때 가장 크게 드러난다. 특정 서비스들은 리소스 정책을 사용하여 접근할 수 있는 반면 특정 서비스는 iam role을 사용하여 접근해야한다. ( 리소스 정책이 아직 구현안된듯  ? )

 

IAM permission Boundaries

권한 경계는 사용자와 역할만 지원하고 그룹은 지원하지 않는다.

IAM개체의 최대 권한을 정의하는 고급기능이다.

한 사용자에 IAM permission Boundaries를 지정하고, 개별 policy로 특정 권한을 주면,

그 policy에 지정된 권한은 적용되지 않는다.

 

1. IAM유저 하나 생성 ( 생성시 권한 적용 X )

2. IAM유저에게 슈퍼어드민 권한 부여 

3. permission boundaries 로 AmazonS3FullAccess를 지정

4. 권한 경계를 부여 했기 때문에 (AmazonS3FullAccess) 슈퍼 어드민 권한이 있어도 슈퍼 어드민 권한 무시됨

5. 권한 경계인 S3내부에만 액세스 할 수 있다.\

-> 관리자 액세스를 부여하는 정책을 연결했음 에도 권한 경계 때문에 제한이 생김

 

IAM 권한 경계는 AWS Organizations SPC와 함께 사용될 수 있다.

 

사용자 그룹에 부여된 자격 증명 기반 정책과 

그룹이 아닌 사용자나 역할에만 적용도는 권한 경계와

계정상 모든 IAM 갳체에 적용되는 Organizations SCP 이 세개가 겹치는 곳 , 교집합 부분의 권한만

사용자에게 주어진다.

 

action : sqs:*

effect : deny

resource : *

 

action : sqs:deleteQueue

effect : allow

resource : *

 

sqs:createQueue 작동 가능 ? -> 안됨 deny로 모든 sqs 권한 거부

sqs:deleteQueue 작동 가능 ? -> 안됨 deny로 모든 sqs 권한 거부 

아무리 명시적 허용이 있어도 명시적 거부가 존재하면 안됨

그냥 거부 적히면 절대 안된다고 생각

ec2:describeInstances 작동 가능 ? -> 안됨 명시적 거부도 없지만 명시적 허용도 없음, 안적히면 기본적으로 안됨

 

Cognito

사용자에게 웹 및 모바일 앱과 상호작용 할 수 있는 자격 증명을 부여한다.

일반적으로 이 사용자들은 aws계정 외부에 있다 

모르는 사용자(AWS외부의 사용자)들에게 자격 증명을 부여해 사용자를 인식(cognito)한다.

2종류의 기능이 있다.

1. 앱 사용자에게 가입 기능을 제공하는 Coginto 사용자 풀이 있다.

API gateway 및 애플리케이션 로드 밸런서와 원활히 통합된다.

 

2. 페더레이션 자격증명이라고 불리는 cognito 자격 증명 풀이 있다.

이는 앱에 등록된 사용자에게 임시 AWS자격증명을 제공해서 일부 aws리소스에 직접 액세스할 수 있도록 해준다.

Cognito 사용자 풀과 원활히 통합된다.

 

시험에서 hundreds of users, mobile users, authenticate with SAML이 나오면 coginto를찍어라 

 

Cognito user pool (CUP) congnito 사용자 풀

웹 및 모바일 앱을 대상으로 하는 서버리스 사용자 데이터 베이스이다.

사용자 이름 또는 이메일 비밀번호 조합으로 간단한 로그인 절차를 정의할 수 있음

비밀번호 재설정 기능이 있고 이메일 및 전화번호 검증 및 사용자 멀티팩텅 ㅣㄴ증도 가능

facbook google도 통합되어 소셜로그인도 가능

coginto 사용자 풀은 api gateway나 애플리케이션 로드 밸런서와 통합된다.

 

사용자는 cognito사용자 풀에 접속해서 토큰을 받고 검증을 위해 토큰을 api gateway로 전달한다.

확인이 끝나면 사용자 자격증명으로 반환되어 백엔드 lambda함수로 전달된다.

 

또 다른 방법이 있는데 완전히 동일한 작업이 가능하다.

cognito 사용자 풀을 애플리케이션 로드 밸런서 위에 배치하면 된다.

 

시험 : 사용자 풀과 api gateway, 로드밸런서와 통합할 수 있다는 점 기억

 

Cognito Identity Pools (Federated Identities ) 페더레이션 자격 증명

사용자에게 자격 증명을 제공하지만 API gateway나 애플리케이션 로드 밸런서를 통해서

애플리케이션에 액세스 하지 않고 임시 AWS자격증명을 사용해 aws계정에 직접 액세스 한다.

 

웹이나 모바일 애플리케이션에서 s3버킷 또는 dynamoDB 테이블에 직접 액세스 하고 싶다면

처음에 웹 모바일 앱이 로그인해서 토큰을 받을 것이다. cognito 사용자 풀에 대한 로그인일 수도 있고, 소셜 로그인이나 SAML OpenID일 수도 있다.

그런 다음 받은 토큰을 cognito 자격 증명 풀 서비스에 전달해서 토큰을 임시 aws 자격증명과 교환한다. 이를 위해 cognito자격 증명 풀은 전달 받은 토큰이 올바른지, 즉 유효한 로그인인지 평가한다. 그 다음 해당 사용자에게적용되는 iam정책을 생성한다. 관련 iam정책이 적용된 임시자격 증명 덕분에 aws의 버킷이나 dynamodb 테이블에 직접 액세스할 수 있다.

api gateway나 load밸런서를 거치지 않고도 말이다. 

 

IAM Identity Center IAM 자격 증명 센터

한번만 로그인 하면 모든 것에 액세스할 수 있다.

시험에서는 여러 AWS계정을 한 번에 로그인 하는 것에 대해 나올 것이다.

 

로그인 페이지로 이동하여 사용자 이름과 비밀번호를 입력하고 바로 AWS IAM 자격 증명 센터로 이동한다.

거기서 원하는 계정을 클릭하면 그 계정으로 로그인된 홈페이지로 직접 이동한다. 그 콘솔에 로그인하는 방법을 알 필요가 없다.

 

현실에서 여러개의 AWS 계정을 가지고 있다면 이 서비스를 사용하는 것을100% 추천한다.

 

브라우저 인터페이스는 AWS IAM 자격증명 센터의 로그인 페이지에 연결된다.

그걸 다른 사용자 스토어와 통합해야 한다.클라우드 또는 온프레미스의 active directory도 가능하다.