이제 AWS STS에 대해 이야기해 볼 것입니다
모든 AWS의 중추에 있는 보안 서비스입니다.
Security Token Service의 약자이고
AWS 리소스에 대한 제한적이고
일시적인 접근을 허용합니다
테크 토큰은 한시간 정도
유효할 수 있고
유효하지 않을 경우 갱신되어야 합니다
따라서 이런 토큰을 원할 때는
먼저 API Call(호출)을 STS 서비스에 요청해야 합니다
예를 들어 역할을 가정할 때
STSAssumeRoleAPI Call(호출)인데
강화된 보안을 위해 여러분의
계정에서 역할을 수행하게 됩니다
시간이 지나면 자격 증명이 무효가 될 수도 있고 계정 간 액세스 설정에서
역할을 수행할 수도 있습니다 타깃 계정에서 역할을 수행하는 것입니다
AssumeRole가 자격 증명을
주면 어느 시점에서 만료되는 것입니다
자격증이 만료될 때 역할 가정해야 합니다
AssumeRoleWithSAML도 있는데
사용자가 SAML로 로그인하면
그 SAML 토큰을 확장해 STS에서 자격 증명을
받는다는 것입니다
당연히 SAML 토큰을 교환하고 확인하기 위해
먼저 STS 구성을 설정해야 합니다
AssumeRoleWithWebIdentity도 있습니다
이는 Facebook 로그인이나 Google Doc 로그인
아니면 OIDC와 호환되는 무엇이든
사용자가 IDP와 식별될 때 사용됩니다
이런 자격 증명을
임시 STS의 자격 증명과
교환하게 되는 것입니다
이제 해당 API Call(호출)의 사용은 지양되고 있습니다
AWS는 대신 코그니토를
사용하도록 권장합니다
GetSessionToken입니다
MFA를 할 경우 사용되는데
사용자나 계정 루트 사용자로부터
MFA에 로그인한 후 실제 자격 증명을
얻고자 할 때 사용합니다
역할 가정하기 위해 STS를 사용할 때는
먼저 IAM 역할을 계정 내에서 혹은 계정간에
정의해야 합니다
그리고 어떤 원칙이 IAM 역할에
접근할 수 있는지 정의해야 합니다
그런 다음 STS 서비스를 이용해 자격
증명을 얻고 엑세스 권한이 있는
IAM 역할을 수행하는 겁니다
예를 들어 AssumeRole API를 사용해서 말입니다
말씀드린 것처럼 일시적인 자격증이 있어요
여길 보시면 예를 들어 사용자가 같은 계정의
역할에 액세스하길 원하거나 다른 계정이 AssumeRole
API를 STS에 할 것입니다
물론 API 호출을 수행하려면 권한이 있어야 합니다
그러면 STS는 사용 권한을 보고
인증을 결정하고 임시 자격 증명을 부여합니다
이 자격 증명들은 사용될 것이고
자격 증명으로 인해 역할을
가정할 수 있게 된 것입니다
STS의 계정 간 액세스를 보면
Dev 계정과 Prod 계정이 있고 Prod에는 S3
버킷이 있는데 Dev에 있는 그룹의 IAM 사용자로부터
액세스하고자 한다고 생각해 봅시다
가장 먼저 할 일은 프로덕션 계정에 IAM 역할을 만드는 겁니다
이 IAM 역할은 S3 버킷에
엑세스 권한을 갖습니다
다음으로 IAM 그룹에 UpdateApp IAM 역할을
다른 계정에서 할 수 있는 권한을 부여하죠
그렇게 하면 역할을 가정할 수 있습니다
그런 다음 STS 역할 자격 증명을 얻습니다
이런 자격 증명을 통해 대상 계정의 버킷에
액세스할 수 있습니다
그래서 프로덕션 계정에서 정의한 IAM역할도
당연히 개발 계정을
승인해야 합니다
따라서 권한이 없는 IAM 그룹 Tester가
있다면 여러분의 제품 계정에
접근할 수 없습니다
일시적인 자격을 얻기 위해 STS를
사용하는 과정을 보여드렸습니다
마음에 드셨으면 좋겠습니다
다음 강의에서 뵙겠습니다