[SAA] 보안 토큰 서비스 (STS) 개요

AWS STS – Security Token Service

• AWS 리소스에 대한 제한되고 일시적인 액세스 권한을 허용
• 그에 대한 토큰을 발급하며 토큰은 일시적이며 1시간까지 유효하므로
  토큰을 재사용하고 싶다면 새로고침을 해야 하며 보안 인증 정보를 재증명해 새 토큰을 발급 받아야 함
• 여러 API가 존재

1. AssumeRole
   보안을 강화하기 위해 개인 계정에서 사용하며 교차 계정 액세스로도 이용
   예1) 실수로 EC2 인스턴스를 삭제하지 못하도록 보안 계층 추가를 위해 삭제를 허가하는 역할을 사용자가 수임하여 수행하게 함
   예2) 교차 계정 액세스로 사용하기 위해 우리 계정이 아닌 대상 계정이 역할을 수임해 수임한 계정의 리소스를 이용해 작업 수행
2. AssumeRoleWithSAML
   SAML을 통한 페더레이션 된 사용자에게 자격 증명을 반환
3. AssumeRoleWithWebIdentity
   자격 증명 제공자를 통해 로그인할 사용자에게 자격 증명을 반환하지만 AWS는 이것의 사용을 자제하도록 권고하며
   이 대신 Cognito의 사용을 권장
   예) Facebook, Google OIDC 호환 로그인 등
4. GetSessionToken
   사용자 혹은 AWS 루트 계정 사용자에 대한 멀티팩터 인증인 MFA를 뜻하며
   사용자가 MFA를 받으면 이를 이용해 콘솔이나 CLI 등에 액세스할 수 있게 해주는 토큰을 발급받음

Using STS to Assume a Role

• 역할 수임 방법

1. IAM 역할을 계정이나 교차 계정 내에서 정의
2. IAM 역할에 액세스할 수 있는 원칙(어떤 사용자, 어떤 역할 등이 액세스할 수 있는지)을 정의
3. STS를 사용해 보안 인증을 받고 AssumeRole을 이용해 액세스 가능한 IAM 역할을 가장
   즉, AssumeRole API를 이용해 STS를 실행하며 STS는 IAM을 확인해 권한이 있는지를 확인하고 임시 보안 인증을 반환
   이 보안 인증을 통해 계정 내 역할에 액세스할 수 있음
   API를 어떻게 구성하냐에 따라 보안 인증 정보는 15분에서 한 시간 가량 유효함
   
   

Cross account access with STS

• 교차 계정 액세스 과정
• STS를 활용해 실행되므로 절대 자격 증명을 다른 계정에 공유해서는 안 됨
  예) 새 사용자를 만들어 보안 인증을 전송하지 않아야 함
• 그러므로 역할을 만들고 사용자에게 역할을 수임하게 하면 STS가 임시 역할 자격 증명을 반환해서 
  그 자격 증명을 잃어버리더라고 훨씬 피해가 적게 됨

1. 관리자가 프로덕션 계정에서 UpdateApp 역할을 생성
2. 개발 계정의 관리자는 개발자 그룹이 UpdateApp 역할에 액세스할 수 있는 허가를 내림
3. 사용자가 UpdateApp 역할에 대한 액세스를 요청
4. STS는 자격 증명을 반환
5. 해당 계정에서 역할을 사용할 수 있는 자격 증명이 생기게 됨
   그러므로 사용자는 이 자격 증명으로 다른 계정에 있는 S3 버킷 등에 액세스가 가능해짐