AWS Certified Solutions Architect Associate [17] Identity and Access Management (IAM) Advanced

AWS STS

AWS STS - Security Token Service

• STS는 이름 대로 AWS 리소스에 대한 제한되고 일시적인 액세스 권한을 허용합니다.
• 토큰을 발급하는데 그 토큰은 일시적이며 1시간까지 유효합니다.
• AssumeRole
  • 보안을 강화하기 위해 개인 계정 내에서 AssumeRole을 사용
  • AssumeRole은 교차 계정 액세스로도 이용할 수 있음
• AssumeRoleWithSAML
  • SAML을 통한 페더레이션 된 사용자에게 자격 증명을 반환하기 유용합니다.
• AssumeRoleWithWebIdentity
  • 자격 증명 제공자를 통해 로그인할 사용자에게 자격 증명을 반환합니다.
  • AWS는 이것을 사용하지 말라고 권고합니다.
    • 대신 Cognito를 사용해야 합니다.
• GetSessionToken
  • 사용자 혹은 AWS 루트 계정 사용자에 대한 멀티팩터 인증, 즉 MFA를 말합니다.

STS는
사용자에게 애플리케이션을 제공하는 데 중심에 있습니다.
ASW 리소스와 소통할 수 있는 권한을 주는 토큰을 제공하죠.

---

Using STS to Assume a Role

• 여러분의 계정이나 교차 계정 내에서 IAM 역할을 정의합니다.
• 이 IAM 역할에 액세스할 수 있는 원칙 어떤 사용자, 어떤 역할 등이 액세스할 수 있는지를 정의합니다.
• STS를 사용해 보안 인증을 받고 AssumeRole을 이용해 액세스 가능한 IAM 역할을 가장합니다.
• 보안 인증 정보는 15분에서 한 시간 가량 유효합니다.

---

Cross account access with STS

---

Identity Federation in AWS

• 모든 사용자를 AWS 내에서 관리하지 않기 위해서 ID 페더레이션이라는 게 필요할 때가 생깁니다.
• 사용자를 위한 외부 진실 공급원이 필요하고 그 진실 공급원을 통해 AWS 리소스에 액세스할 수 있게 해야 합니다.
• 페더레이션은 AWS 밖 사용자가 AWS 리소스에 액세스하는 임시 역할을 수행하게 합니다.
• 해당 사용자는 ID가 제공된 액세스 역할을 수행합니다.
• 방법
  • SAML 2.0
  • Custom Identity Broker
  • 웹 ID 페더레이션 ( Amazon Cognito 유/무 둘다 )
  • SSO
  • AWS Microsoft AD를 통한 Non-SAML
• 사용자 페더레이션을 사용하면 IAM 사용자를 만들 필요 없습니다.
  • 사용자 관리가 AWS 밖에서 이뤄지기 때문입니다.

---

SAML 2.0 Federation

• Active Directory나 ADFS (SAML 2.0 사양과 호환되는 다른 디렉터리도 있습니다.)
• AWS 콘솔이나 CLI에 액세스할 수 있습니다.
• 직원별로 IAM 사용자를 만들 필요가 없습니다.
  
  
• 신뢰하기 위해 IAM과 SAML 간에 신뢰를 구축해야 합니다.
• SAML 2.0은 웹 기반의 교차 도메인 SSO를 활성화합니다.
• STS API인 AssumeRoleWithSAML API를 사용합니다.
• SAML 페더레이션은 오래된 방식이며 새로운 서비스가 있다는 걸 알아두세요.
• Amazon Single Sing On 즉 SSO인데 페더레이션을 생성하는 새로운 방법입니다.

---

SAML 2.0 Federation – Active Directory FS

• SAML 2.0 compatible IdP와 같은 과정

---

Custom Identity Broker Application

• 만약 현재의 온프레미스 저장소가 SAML 2.0과 호환되지 않는다면,
  사용자 지정 자격 증명 브로커 애플리케이션을 직접 작성해야 합니다.
• 작성할 자격 증명 브로커는 사용자들을 위한 적절한 IAM 정책을 결정해야 합니다.
• AssumeRole 혹은 GetFederationToken API 이용합니다.

---

Web Identity Federation – AssumeRoleWithWebIdentity

• 먼저 이건 웹 ID 페더레이션을 하는 정확한 방법이 아니기 때문에 권장되지 않는다는 걸 알아두세요.

---

AWS Cognito

• 목표
  • 클라이언트 측에서의 AWS 리소스에 대한 직접 액세스 제공입니다.
    (모바일 또는 웹 애플리케이션이 될 수 있습니다.)
• 예시
  • Facebook으로 로그인하여 S3 버킷에 쓰기 작업을 할 수 있는 임시 액세스를 주고 싶다고 가정.
• 문제
  • 문제는 계정 내 애플리케이션을 위해 IAM 사용자를 생성할 수 없다는 겁니다.
• 방법
  • 자격 증명 제공자 또는 익명으로 로그인해서 Cognito API로 AWS 자격 증명을 받습니다.
  • 자격 증명에 IAM 역할이 첨부되어 있어 S3 버킷에 액세스할 수 있게 됩니다.

---

Microsoft Active Directory (AD)

• AD 도메인 서비스를 사용하는 모든 Windows 서버에서 볼 수 있는 소프트웨어입니다.
• 객체 데이터베이스인데 객체로는 사용자 계정 컴퓨터, 프린터, 파일 공유 보안 그룹 등이 있습니다.
• 중앙식 보안 관리로 계정을 생성하거나 권한을 부여할 수 있습니다.
• 모든 객체는 트리(tree)로 만들어지고 트리가 모여 포리스트(forest)가 됩니다.

---

AWS Directory Services

• AWS Managed Microsoft AD
  • AWS에 액티브 디렉터리를 생성합니다.
  • 로컬 환경에서 사용자를 관리하고 멀티팩터 인증(MFA)을 지원합니다.
  • 독립형 액티브 디렉터리로 온프레미스 AD와 "신뢰" 관계를 생성합니다.
• AD Connector
  • 온프레미스로 리디렉트하는 디렉터리 게이트웨이 프록시로 멀티팩터 인증(MFA)을 지원합니다.
  • 온프레미스 AD가 총괄하여 사용자를 관리합니다.
• Simple AD
  • AD와 호환 가능한 AWS의 관리형 디렉터리입니다.
  • Microsoft 디렉터리를 사용하지 않고 온프레미스 AD와 결합될 수 없습니다.

---

AWS Organizations

• 글로벌 서비스
• 조직의 여러 AWS 계정을 관리할 수 있습니다.
• 메인 계정은 마스터 계정이라고 부르고 바꿀 수 없습니다.
• 조직 내 다른 계정들은 멤버 계정입니다.
  • 멤버 계정은 하나의 조직에만 속할 수 있지만 다른 조직으로 이동할 수 있습니다.
  • 이를 마이그레이션이라고 합니다.
• 좋은 점은 모든 계정에서 단일 결제 수단으로 통합 결제를 할 수 있다는 점입니다.
• 통합 사용으로 가격 혜택을 얻을 수 있고 이는 조직 수준에서 얻을 수 있는 것입니다.
• AWS 계정 생성을 자동화할 수 있는 API가 있습니다.
  
  
• 계정을 여러 개 갖는 것 vs 여러 VPC가 있는 하나의 계정을 갖는 것
  • 여러 계정이 있는 경우 계정이 정말 잘 분리되어 있고 다른 사용자 계정 등을 가지게 됩니다.
  • 여러 VPC가 있는 큰 계정이 하나 있는 경우 리소스가 서로 통신할 수 있고 인스턴스와 사용자도 여러 VPC 등에 액세스할 수 있습니다.
• 결제 목적으로 태그 표준을 지정할 수 있습니다.
• 모든 계정에서 CloudTrail을 활성화해서 Amazon S3 계정 같은 중앙 계정에 로그를 보내고 CloudWatch 로그를 중앙 로깅 계정으로 보낼 수도 있습니다.
• 모든 계정을 관리하려고 하면 관리 목적을 위해 교차 계정 역할을 설정할 수 있습니다.

---

Service Control Policies (SCP)

• IAM의 블랙 또는 화이트리스트
• 마스터 계정에는 적용되지 않습니다.
• SCP는 마스터 계정에는 영향을 미치지 않습니다.
• 루트를 포함하여 계정의 사용자와 역할에만 적용할 수 있습니다.
• SCP는 서비스 연결 역할에는 적용되지 않습니다.
  • 다른 서비스가 조직과 상호 작용하는 데에 사용되는 서비스 역할입니다.
• SCP는 명시적인 허용이 있어야 허용이 됩니다.
  • 기본값으론 아무것도 허용하지 않습니다.
• 사용 사례 :
  • 특정 서비스에 대한 액세스를 제한하는 것입니다. (EMR을 쓸 수 없다고 하거나)
  • AWS에서 아직 PCI를 준수하지 않는 서비스를 명시적으로 비활성화하는 것.

---

SCP 계층

---

SCP 예시

---

AWS Organization – 계정 이동 (마이그레이션)

• 하나의 계정을 한 조직에서 다른 조직으로 이동
  1. 먼저 멤버 계정을 이전 조직에서 제거합니다.
  2. 새로운 조직에 해당 계정을 포함하도록 초대를 보냅니다.
  3. 멤버 계정이 포함될 수 있도록 새로운 조직에 대한 초대를 수락합니다.
  4. 첫 조직을 떠나고 두 번째 조직으로부터 초대를 받으면 마이그레이션이 됩니다.
• 마스터 계정을 마이그레이션
  1. 마스터 계정 내의 모든 단일 계정을 마이그레이션해야 합니다.
  2. 그 작업이 끝나면 조직을 삭제합니다.
  3. 독립 실행형 계정을 다시 다른 조직으로 마이그레이션합니다.

---

IAM Conditions

• API를 호출하는 곳으로부터 클라이언트 IP를 제한하는 aws:SourceIP
• NotIPAddress 두 SourceIP의 범위로부터 나오는 것 외에는 전부 다 거부하라는 뜻이 됩니다.

• API 호출이 일어나는 리전을 제한하는 Aws:RequestedRegion
• IAM 정책 예시 이름은 AllowOnlyInsideEU인데 즉 EU 리전 안에서만 허용하란 뜻입니다.
• Effect는 Allow고 Action은 ec2: rds: , dynamodb: *입니다.
  • 즉 이 세 가지 서비스 내의 모든 리소스가 허용되어야 하는 거죠.

• 태그로 제한하는 방법입니다.
• 오직 프로젝트가 데이터 분석이면서 부서가 데이터일 때만 EC2 인스턴스를 시작하고 중지시킬 수 있습니다.

• 다요소 인증을 강제
• 다요소 인증이 있는 경우에만 인스턴스를 중단하거나 종료할 수 있다는 것입니다.

---

IAM for S3

• ListBucket은 test 버킷에 적용되는 권한입니다.
  • arn은 버킷이 있는 곳 : arn:aws:s3:::test
• 버킷 수준 권한이므로 / 없이 버킷 이름만 들어갑니다.
  
  
• GetObject, PutObject, DeleteObject
  • 버킷 내부의 모든 것에 적용됩니다.
  • 고려되어야 하는 리소스는 버킷의 이름 /와 *입니다.
  • 버킷 내 모든 객체에 적용되기 때문입니다.
• 객체 수준의 권한

---

IAM 역할 vs 리소스 기반 정책

• 사용자, 애플리케이션 또는 서비스의 역할을 수임하게 되면 원래의 권한을 포기하고 역할에 할당된 권한을 갖게 됩니다.
• 리소스 기반 정책을 사용할 때 권한을 포기할 필요 없이 리소스 버킷 정책을 통해 권한을 잃지 않고 그냥 사용할 수 있습니다.
  • 리소스 기반 정책은 Amazon S3 버킷, SNS 주제, SQS 대기열과 같은 이런 모든 것들에서 쓰일 수 있습니다.

---

IAM Permission Boundaries

• 권한 경계는 사용자와 역할만 지원하고 그룹은 지원하지 않습니다.
• 최대 권한과 IAM 개체를 정의하는 고급 기능입니다.
• iam:CreateUser 액션과 * 리소스를 같은 사용자에 연결하면
  권한 경계와 IAM 정책을 통한 권한이 완성됩니다.
  결과적으로 어떤 권한이 생길까요?
  놀랍게도 아무 권한도 생기지 않습니다.
  • IAM 정책은 IAM 권한 경계 밖에 있기 때문에 사용자가 다른 IAM 사용자를 생성할 수 없습니다.
    
    
• IAM 권한 경계는 AWS Organizations SCP와 함께 사용될 수 있어요.

사용 사례 :

• 관리자가 아닌 사용자에 책임을 위임하기 위해
  권한 경계 내에서 새 IAM 사용자를 생성하거나
  개발자가 권한을 스스로 부여하고 관리하는데
  특권을 남용해 스스로를 관리자로 만들지 못하게 할 수 있어요.

• 계정에 SCP를 적용해서 계정의 모든 사용자를 제한하지 않고
  AWS Organization의 특정 사용자만 제한할 수도 있죠

---

IAM 정책 평가 로직

---

AWS Resource Access Manager

• 소유하고 있는 AWS 리소스를 다른 계정과 공유할 수 있게 하는 서비스입니다.
• 어떤 계정과도 공유 가능하고 또는 조직 내에서 공유할 수 있습니다.
• 리소스 중복을 피하는 게 중요합니다.
• VPC 서브넷
  • 모든 리소스가 동일한 서브넷 내에서 실행되도록 할 수 있습니다.
  • 모두 동일한 조직 내에서 가져와야 합니다.
  • 현재로서는 보안 그룹이나 기본 VPC를 공유할 수 없습니다.
  • 참가자는 공유 VPC에서 자신의 리소스를 관리할 수 있습니다.
  • 참가자는 자신에게 속하지 않은 리소스를 보거나 수정하거나 삭제할 수 없습니다.
• AWS Transit Gateway
  • Route53 ResolverRules
  • License Manager Configurations

---

Resource Access Manager – VPC example

• 각 계정은
  • 자체 리소스에 대한 책임이 있습니다.
  • 다른 계정의 다른 리소스를 보거나 수정하거나 삭제할 수 없습니다.
• 네트워크는 공유되므로
  • VPC에 배포된 모든 것이 VPC의 다른 리소스와 통신 가능합니다.
  • 이는 애플리케이션이 사설 IP를 이용해 서로 액세스할 수 있다는 겁니다.
  • 보안 그룹을 참조해서 계정 전체에 최대한의 보안을 유지할 수 있습니다.

---

AWS Single Sign-On (SSO)

• 중앙에서 관리하여 다수의 계정과 타사 애플리케이션에 액세스할 수 있습니다.
• 한 번 로그인하면 싱글 사인온이 액세스하도록 구성된 모든 항목에 액세스할 수 있습니다.
• SAML 2.0 마크업을 지원하므로 SAML과도 통합됩니다.
• 온프레미스 Active Directory와 긴밀하게 통합됩니다.
• 권한 관리가 중앙 집중화되게 하여 싱글 사인온 내에서 사용자의 모든 권한을 관리할 수 있습니다.
• CloudTrail로 로그인에 대해 중앙 집중화된 감사를 받을 수 있습니다.
• 비즈니스 애플리케이션의 인증에 대한 사용 사례

---

SSO vs AssumeRoleWithSAML

---

From
AWS Certified Solutions Architect Associate 시험합격!