Section 29. 고급 자격 증명

STS(Security Token Service) Basic

• STS는 최대 1시간까지 임시 보안 자격 증명을 얻어 AWS 리소스에 바로 액세스할 수 있는 서비스이다.
  STS 요소들을 알아보자.(까만 부분이 시험 출제 높음)
• AssumeRole | 가장 핵심적인 계정이나 교차 내 역할을 추정하도록 한다.
• AssumeRoleWithSAML | 사용자가 SAML로 로그인한 경우, 사용자에게 임시 보안 인증을 부여한다.
• AssumeRoleWithWebIdentity | 사용자가 신분 제공자로 로그인하면 역할을 반환한다.
  - 요즘에는 Cognito 자격증명 풀을 사용한다.
• GetSessionToken | 사용자나 AWS 루트 계정에 MFA가 있는 경우를 말한다.
• GetFederationToken | 연합된 사용자의 임시 자격 증명을 얻는다.
• GetFCallerIdentity | API 호출에 사용된 역할이나 IAM 사용자의 세부 사항을 반환한다.
• DecodeAuthorizationMessage | AWS API가 거부되었을 때, 에러 메시지를 디코딩한다.

Using STS to Assume a Role

만일 계정 내 AssumeRole을 원할 경우에는 다음과 같이 작업을 한다.

1. 계정이나 교차 계정일 경우, 계정이나 다른 계정의 IAM 역할을 정의하고, IAM 역할에 액세스할 수 있는 원칙을 정의한다.
2. IAM 정책으로 전체에 권한을 부여한다.
3. AWS STS를 사용해서 신원을 검색하고 'AssumeRole API'에 액세스하는 IAM 역할을 가장한다.
4. 그러면 보안 인증은 15분~1시간까지 유효해진다!

 

 

 

 

 

Cross account access with STS

교차 계정 액세스도 위 과정과 유사하다.

다른 계정에서 역할을 생성하고, 자체 계정이나 타깃 계정으로 올바른 권한을 작성해
AssumeRole API를 실행해서 타깃 계정에 액세스하도록 하는데 역할을 통해 S3에 액세스한다면 S3 버킷을 액세스할 수 있는 원리이다.

STS with MFA

시험에 출제되니 잘보자!

MFA를 이용한 STS는 GetSessionToken API를 사용한다.

• API나 MFA 기기로 로그인하면 적합한 IAM 조건의 IAM 정책을 요구한다.
• 그러면 이를 충족시키기 위해 IAM 역할에서 aws:MultiFactorAuthPresent:true를 추가해야한다.

그렇다면 왜 "GetSessionToken API"가 필요할까?
이유는 다음과 같다.

• 액세스 ID와 비밀 키 뿐만 아니라 포함해야 하는 세션 토큰도 반환하기 때문이다.
• GetSessionToken은 마지막에 만료일도 반환하는데 이는 갱신을 언제해야할지 알려주는 용도로 사용된다!

---

고급 IAM

1. Authorization Model Evaluation of Policies, simplified

• 해당 모델은 단순화되어 있지만 실제로는 복잡하다. 그래서 잘 이해하는 것이 중요하다.
• 정책을 명시적으로 거부하면 거부로 결정하고, 허용이면 허용으로 결정한다.
• 사용자가 DynamoDB 테이블을 생성하고자 하면 거부로 시작하며 기본적으로는 이용할 수 없다.
  명시적으로 거부가 되어있기에 별도의 설정을 취하지 않으면 무조건 거부가 된다.
  하지만 허용한다는 말이 있다면 결과는 허용이다. 당연한 말일지도

2. IAM Policies & S3 Bucket Policies

IAM 정책이 S3 버킷과 어떻게 실행되는지 알아보자.

• IAM 정책은 사용자, 역할, 그룹에 연결되어 있고, S3 버킷 정책은 버킷에 연결되어 있고 두 가지 모두 버킷에서 사용자가 할 수 있는 것을 정의한다.
• 만일 IAM 원칙이 버킷에 객체를 추가할 수 있다면 평가할 때, IAM 정책과 S3 버킷 정책의 통합을 평가하게 된다.

정책이 통합된다!

3. Dynamic Policies with IAM

각 사용자들은 S3 버킷에 특정 폴더(/home/<user>)를 어떻게 할당할까?

여기 각 옵션들이 있다.

• Option 1
  • 조지가 /home/georges에 액세스하도록 허용하는 IAM 정책을 만든다.
  • 사라가 /home/sarah에 액세스하도록 허용하는 IAM 정책을 만든다.
  • 매트가 /home/matt에 액세스하도록 허용하는 IAM 정책을 만든다.
  • 일일이 만들기에는 번거롭다!
• Options 2
  • 하나의 동적인 IAM 정책을 만든다.
  • ${aws:username}이라는 특수 정책 변수를 활용한다.
  • 동적 정책이기에 런타임은 AWS 사용자 이름의 값으로 대체된다.

${aws:username}을 사용하여 동적으로 이름을 할당해준다!

4. Inline vs. Managed Policies

• 인라인 정책과 관리형 정책의 차이를 알아보자!
• AWS에는 3가지 유형이 존재한다.
• AWS Managed Policy는 이름과 같이 AWS로 관리해 제어할 것이 없으며
  파워유저나 관리자를 정의하거나 작업 기능을 기반으로 할 때 유용하다.
  또한 새로운 서비스나 API를 도입하면 AWS에서 업데이트 된다.
• Customer Managed Policy는 더 세분화된 제어가 필요할 때 사용한다.
  재사용이 가능하며 원하는 만큼 많은 법칙에 적용할 수 있다.
  버전 관리도 가능하며 이러한 정책을 롤백할 수도 있다.
• Inline은 법칙 안에 존재하는 정책이다. 정책과 법칙 간의 완전한 일대일 관계로 버전 관리나 롤백을 하기 어렵다!
  그래서 IAM 정책을 삭제하면 정책도 같이 삭제가 된다.
  인라인 정책을 사용하고 싶다면 IAM의 사용자 그룹에 들어가서 변경하면 된다!

---

사용자에게 AWS 서비스에 역할을 전달할 수 있는 권한 부여하기

• 많은 AWS 서비스를 구성할 때, 사용자는 서비스를 이용하기 위해 IAM 역할을 보내야한다!
  그래서 서비스에 IAM 역할을 부여하면 역할을 수행하고 필요한 작업을 수행할 수 있다!
• 다른 서비스에 역할을 보내면 어떻게 될까?
  • EC2 인스턴스 역할을 생성해 EC2 인스턴스로 할당하면 실제로 그 역할을 전달한다.
  • IAM 역할을 생성한 람다 함수에 전달해서 Amazon S3나 ECS 태스크를 호출하도록 할 수도 있다.
  • CodePipeline로 역할을 전달해서 다른 서비스를 호출하도록 할 수도 있다.
• 따라서 다른 AWS 서비스로 역할을 전달하려면 iam:PassRole이라는 IAM 권한이 필요하고,
  이는 종종 전달된 역할을 보기 위한 iam:GetRole이라는 다른 권한과 함께 제공된다.

❓그렇다면 어떤 서비스든지 역할을 전달할 수 있을까❓

결론부터 말하자면 전달할 수 없다. 역할을 신뢰가 허용하는 것을 기반으로만 전달할 수 있으며 역할에 관한 신뢰 정책은
어떤 서비스가 역할을 맡을 수 있는지 나타내는 것이다.

위 그림은 EC2에 대한 서비스만 허용하는 신뢰를 가지고 있다.

---

AWS 디렉터리 서비스

1. Microsoft Active Directory(AD)

• AD 도메인 서비스를 사용하는 모든 Windows 서버에서 볼 수 있는 소프트웨어이다.
• 객체 데이터베이스로 객체로는 사용자 계정, 컴퓨터, 프린터 파일 공유 보안 그룹 등이 있다.
• 온프레미스 Microsoft 생태계 내의 모든 사용자 관리 사항이 Microsoft AD에 관리된다.
• 모든 객체는 tree로 만들어지고 tree가 모여 forest가 되는 구조이다.

어느 머신에서든 John의 password를 사용하면 도메인 컨트롤러에서 확인 후 로그인이 가능하다!

2. AWS Directory Services

• AWS에서도 Active Directory를 사용할 수 있다!
• 유형에는 3가지가 있으며 차이점을 명확히 구분하는 것이 좋다.

1. AWS Managed Microsoft AD
   • AWS에 Active Directory를 생성한다.
   • 로컬 환경에서 사용자를 관리하고 멀티팩터 인증(MFA)을 지원한다.
   • 독립형 AD로 온프레미스 AD와 신뢰 관계를 형성한다.(=AWS AD와 온프레미스 AD 사이에 사용자를 공유)
2.  AD Connector
   • 온프레미스로 리디렉트하는 Directory Gateway 프록시로 MFA를 지원한다.
   • 온프레미스 AD가 총괄하여 사용자를 관리한다.
     즉, 사용자가 AD 커넥터로 인증을 시도하면 온프레미스 AD에 프록시 요청을 보내 사용자를 찾아본다.
3. Simple AD
   • AD와 호환 가능한 AWS의 관리형 디렉토리이다.
   • Microsoft를 사용하지 않고 온프레미스 AD와 결합하지 않는다.
   • AWS Cloud에 AD가 필요하다면 독립형 Simple AD를 가질 수 있다.