[AWS] aws 강의 섹션 29 (고급 IAM 정책)

AWS STS - Security Token Service

• STS는 임시 자격 증명을 생성해주는 서비스다. 이를 통해 최대 1시간 유효한 권한을 얻어 AWS 리소스에 액세스할 수 있다.
• 여러 가지 STS 관련 API를 알아보도록 하자.
  • AssumRole: 다른 AWS 계정에 있는 Role을 빌려온다.
    • 내 계정 또는 다른 계정에서 특정 권한이 있는 역할을 수행하고 싶을 때 사용한다.
  • AssumeRoleWithSAML: 사용자가 SAML로 로그인 한 경우 사용자에게 임시 보안 인증을 부여한다.
  • AssumeRoleWithWebidentity: 사용자가 소셜로그인을 통해 로그인 할 경우 Role을 반환한다.
    • 요즘엔 잘 사용하지 않고, 대신 cognito를 이용한 로그인을 사용한다고 한다.
  • GetSessionToken: 사용자나 루트 계정에서 MFA를 활성화 한 경우 임시 자격 증명을 얻기 위해 사용한다.
  • GetFederationToken: AWS 외부에서 인증한 사용자의 임시 자격증명이다.
    • AWS 계정에 속하지 않은 사용자가 AWS 리소스 사용 권한이 필요할 때 사용한다.
  • GetCallerIdentity: API 호출에 사용되는 IAM 사용자, 역할의 세부 사항을 반환한다.
    • 신원 정보를 알고 싶을 때 이 API를 통해 신원과 계정 정보를 반환받는다.
  • DecodeAuthorizationMessage: AWS API가 거부됐을 때 오류 메시지를 디코딩한다.
• 시험에 출제되는 것은 강조 표시 해두었다.

Using STS to Assume a Role

• 계정에 IAM 룰을 정의한다.
• 누가 Role을 사용할 수 있는 지 허용 범위를 정의한다.
  • 사용자, 서비스, 계정 등,,
• AssumeRole API를 사용해서 STS로부터 임시 자격 증명을 가져온다.
  이 자격 증명으로 역할을 가짜로 빌려서, 그 역할이 가진 권한을 사용할 수 있다.
• 임시 자격 증명은 최소 15분에서 최대 1시간까지 유효하다.

STS with MFA

• GetSessionToken API를 사용해 STS에서 세션 토큰을 얻어온다.
• 적적한 IAM 정책을 IAM condition을 통해 설정해둬야한다.
• aws:MultiFactorAuthPresent:true로 설정해둔다.
  • MFA에서만 특정 리소스를 중지하거나 가동할 수 있다는 내용이다.
• access Id, Secret Key, Session Token을 얻기 위해 수행한다.
• Expiration date도 포함하는데, 이를 통해 갱신을 언제 해야하는지 알려준다.

Advanced IAM - Authoriztion Model Evaluation of Policies, simplified

• 특정 작업을 수행하려 할 때 해당 작업의 권한이 있는지 판단하는 작업이다.
• 데이터베이스를 생성하려 할 때 명시적 거부가 정책에 있는지 확인한다.
  • 명시적 거부가 있다면 바로 deny가 반환된다.
• 명시적 허용이 존재한다면, 데이터베이스의 생성을 허용한다.
• 어느 경우에도 해당하지 않는다면 거부로 끝이난다.
• 여기서 알 수 있듯이, 만약 정책에 명시적 거부와 명시적 허용이 모두 적혀 있는 경우에는,
  거부가 먼저 판단이 되기 때문에, 데이터베이스 생성에 실패하고 끝이나게 된다.

IAM Policies & S3 Bucket Policies

• IAM 정책은 사용자, role, group에 연관되어 있다.
• S3 버킷 정책은 오로지 버킷에만 연관되어 있다.
  • 이 두 가지 모두 버킷에서 사용자가 할 수 있는 것을 정의한다.
• aws에서 특정 principal(사용자)이 특정 작업을 수행할 수 있는지를 확인할 때, iam 정책과 s3 버킷 정책을 합쳐서 평가한다.

Example 1

• ec2 인스턴스에 연결된 IAM role이 있고 버킷에 대한 읽기, 쓰기 권한을 허용한다.
• s3 버킷에 연결된 버킷 정책은 존재하지 않는다.
• 이 경우 인스턴스가 버킷에 읽기, 쓰기가 가능해진다.

Example 2

• ec2 인스턴스에 연결된 IAM role이 있고 버킷에 대한 읽기, 쓰기 권한을 허용한다.
• s3 버킷 정책은 IAM Role에 대한 명시적 거부가 적혀있다.
• 이 경우 읽기와 쓰기가 거부된다.

Example 3

• ec2 인스턴스에 연결된 IAM role이 있고 버킷과 관련된 어느 역할도 정의하지 않았다, 그냥 빈 역할이다.
• s3 버킷 정책은 명시적으로 읽기, 쓰기 권한을 허용한다.
• 이 경우 읽고, 쓸 수 있다.

Example 4

• ec2 인스턴스에 연결된 IAM role이 있고 버킷에 대한 명시적인 거부가 적혀있다.
• 버킷 정책은 명시적으로 읽기, 쓰기 권한을 허용한다.
• 이 경우 명시적 거부로 인해 버킷에 읽고 쓰는 게 불가능하다.

Dynamic Policies with IAM

• 각각의 사용자를 S3 버킷의 /home/(사용자 이름) 폴더에 할당하고 싶다. 이 경우 어떻게 해야할까?
  1. 사용자 당 한 개의 IAM 정책을 만들고, 사용자가 추가 될 때마다 새 정책을 만드는 방법
  2. IAM 에서 동적 정책을 활용하여 한 개의 정책만 만드는 방법
     • ${aws:username}이라는 변수를 사용한다.

Inline 정책 VS Managed 정책

• Managed 정책
  • AWS에서 모든 것을 관리해 제어할 것이 없다.
  • 새 서비스나 새 API를 도입하면 AWS에서 알아서 업데이트가 된다.
• Customer Managed 정책
  • 정책을 생성하고, 더 세분화된 제어가 필요할 때 사용한다.
  • 버전 관리도 가능하며, 롤백도 가능하다.
• Inline 정책
  • 정책과 법칙 간의 완전한 일대일 관계다.
  • 버전관리나 롤백을 할 수 없고, 쉽게 변경이 불가능하다.
  • IAM principal을 삭제하면 정책도 삭제된다.

Granting a User Permission to Pass a Role to an AWS Service

• aws 서비스를 구성할 때 IAM 룰을 서비스에 전달한다. 전달한 IAM Role을 기반으로 해당 서비스는 새로운 작업을 진행할 수 있다.
• 특정 서비스(EC2)에 IAM Role을 전달하기 위해선 iam:PassRole이라는 권한이 필요하다.
  • 이는 종종 전달된 권한을 확인하기 위한 iam:GetRole 권한과 함께 제공된다.
• 여기서 핵심은 다른 서비스로 IAM Role을 전달하기 위해선 IAM Role을 전달하는 권한이 있어야 한다는 것이다.

위의 코드를 예시로 들어보면 기존 ec2 관련 권한만 허용하는 것에서 추가로 밑에 passRole이라는 코드가 적혔다.

추가된 코드는 ec2에 권한을 전달해달라는 내용으로 ec2가 S3에 접근할 수 있도록 IAM Role을 전달하는 것이다.

 

이를 통해 ec2는 S3에 접근할 수 있는 권한을 전달받게 된다.

 

모든 서비스에 역할을 전달할 수 있을까?

• trust가 allow로 허용되어 있는 서비스에만 역할을 전달할 수 있다.

• 위의 예시는 ec2만이 AssumeRole을 갖고있기 때문에, 위의 예시에서는 ec2에만 역할 전달이 가능하다.

• 자세하게 살펴보면, 특정 Role에 설전된 Trusted entities가 있다.
• 저 곳에 적혀진 서비스에만 해당 Role을 전달할 수 있다.

Microsoft Active Directory (AD)

• AD 도메인 서비스를 사용하는 모든 윈도우 서버에서 볼 수 있는 소프트웨어를 의미한다.
• 중앙에서 모든 권한을 관리하고, 새로 생성된 유저에서 권한을 부여할 수 있다.
• 모든 객체는 트리로 만들어지고 트리가 모여 포레스트가 된다.
  • 객체는 사용자, 계정, 컴퓨터, 프린터, 보안 그룹 등등 모든 요소를 의미한다.

AWS Directory Services

• AWS에서 액티브 디렉터리를 생성할 수 있다.
• 세 가지 종류가 존재한다.
  1. AWS Managed Microsoft AD
     • AWS에서 관리하는 AD이다.
       로컬 환경에서 사용자를 관리하고 MFA를 지원한다.
     • on premiss AD와 신뢰관계를 맺는다.
       • 사용자가 로그인 시 AWS에 없는 계정으로 로그인을 한다면 온 프레미스 서버에서 찾아본다.
       • 반대로 온프레미스에서 AWS계정으로 로그인을 해도, AWS AD에서 계정을 찾아본다.
       • 둘 사이에 사용자를 공유하는 상황이다.
  2. AD Connector
     • 온 프레미스로 리다이렉트 하는 디렉터리 게이트웨이 프록시다.
     • MFA를 지원한다.
     • 온프레미스에서만 사용자를 관리한다.
     • 사용자가 AD Connector로 인증을 시도하면, 온프레미스 AD에 요청을 보내 사용자를 찾는다.
  3. Simple AD
     • AD와 호환 가능한 AWS 관리형 디렉터리다.
     • 마이크로소프트 디렉터리를 사용하지 않고, 온프레미스 AD와 결합될 수 없다.
     • 만약 디렉터리가 필요하다면 AWS 클라우드에 독립형 Simple AD를 만들어서 사용한다.