AWS Solution Architect Associate(SAA) - Study

LEE EUI JOO·2023년 1월 11일

sts

AWS Certificate

목록 보기

2/9

1. STS

STS는 동일한 계정 내에서 다른 계정 간 역할 인수를 막고 자격 증명 페더레이션을 활성화한다.

나의 계정, 혹은 역할을 인수하려는 교차계정에 IAM 역할을 정의한다.
어떤 Principal 요소가 해당 IAM 역할에 액세스 할 수 있는지 정의한다.
이때, 보안 토큰 서비스 일명 STS 서비스를 사용해서 임시 자격 증명을 발급한다.
STS로 AssumeRole API를 사용하여 액세스가 있는 IAM 역할을 부여할 수 있다.
앞서 말한 것처럼, 임시 자격 증명이므로 15분에서 12시간의 유효 기간을 갖는다.

역할에 액세스하고자 하는 사용자가 있고, 동일한 계정 내에 존재하거나 다른 계정에 있을 수 있다.

이를 위해 STS의 AssumeRole API를 사용할 텐데 STS가 권한을 확인하고 설정이 제대로 됐는지를 확인한다.

확인이 완료됐다면, 임시 보안 자격 증명이 발급된다.
보안 자격 증명이 발급됐다면, 대상 역할에 액세스할 수 있다.

어떤 상황에서 STS를 사용하여 역할을 인수해야 할까?

내 계정의 IAM 사용자가 다른 계정 리소스에 액세스할 수 있도록 권한을 부여할 때 사용할 수 있다.
타사 AWS 계정 내 IAM 사용자가 내 계정에 액세스할 수 있도록 권한을 부여하거나 서비스 역할을 이용하여 AWS 서비스의 작업을 지정할 때 사용할 수도 있다.
자격 증명 페더레이션을 실행할 때도 사용할 수 있다.

STS의 기능

STS 에는 active 세션과 역할에 대한 자격 증명을 취소하는 기능이 있다.
사용방법은 아주 간단한데 정책을 변경하고, 시간 표시 문장을 추가하거나 AWSRevokeOlderSession 관리형 정책을 사용하면 된다.
시간에 관한 Condition을 사용하면 역할을 더 이상 사용할 수 없다고 지정할 수 있으므로 추가 보안 조치가 가능하다.
STS를 사용해서 사용자나 애플리케이션, 서비스에 역할을 인수할 시 기존의 권한은 포기하고 해당 역할에 할당된 권한을 얻게 된다.

내 계정이나 다른 AWS 계정에 있는 IAM 사용자에게 액세스를 부여하는 방법

<조건>
예를 들어 A 계정 혹은 또 다른 A* 계정에 EC2 인스턴스를 종료하는 역할을 생성한다고 해보고 이때, 이 모든 계정은 나의 소유여야 한다.

사용자가 역할을 인수한다고 했을 때, 해당 역할에서 받은 권한으로 EC2인스턴스를 종료할 수 있다.

장점

사용자 권한을 명시적으로 부여함으로써 EC2 인스턴스 종료라는 작업을 수행할 역할을 인수하도록 할 수 있다.
사용자가 관리 콘솔이나 CLI AssumeRoleAPI를 이용해 역할을 바꾸도록 강제할 수도 있다.
역할에 멀티 팩터 인증(mfa)를 추가 할 수 있으며, 오직 MFA를 사용이 지정된 사용자만이 역할을 인수할 수 있도록
최소 권한의 법칙을 만족시키고 CloudTrail을 통한 감사 또한 가능하다.

교차 계정 액세스에 대해 STS를 사용하는 사례

상황

S3 버킷이 있는 프로덕션 계정이 있고 두 개의 사용자 그룹이 있는 개발 계정이 있다.
그리고, 두 그룹은 테스터와 개발자이다.
이때, 개발자 그룹에게 S3 bucket: productionapp에 대한 액세스를 주고자 한다.

프로덕션 계정에서 관리자는 개발 계정에 productionapp 버킷을 읽고 쓸 수 있도록 액세스를 부여하는 역할을 생성해야한다.
이 역할을 이용해 S3버킷에 액세스 할 수 있다.
개발 계정의 관리자는 개발자 그룹의 구성원이 UpdateApp 역할을 인수할 수 있도록 권한을 부여해야 한다.
그룹의 사용자, 즉 개발자 그룹만이 해당 STS API를 이용하여 역할에 액세스하거나 액세스를 요청할 수 있다.
다음으로 STS는 임시 자격 증명을 반환한다.
임시 자격 증명을 이용하여 사용하는 S3 버킷에 액세스 할 수 있다.

타사의 AWS 계정에 액세스를 부여하고자 할 경우 - 외부 ID 사용

신뢰 영역

이 신뢰 영역에는 우리가 소유한 모든 계정과 조직이 들어가고,이 신뢰 영역을 벗어나면 타사라고 한다.

서비스를 제공받는 파트너사가 있거나 컨설팅 회사가 있는 경우 즉, 해당 컨설팅 회사에 여러분 계정에 대한 액세스를 부여하고자 할 때가 있다.

하지만, 이들은 우리의 신뢰 영역 밖에 있고, 우리 조직의 일환이 아니다.
이때, IAM Access Analyzer로 우리 계정의 신뢰 영역을 벗어나는 리소스가 무엇인지 알 수 있다.

타사에게 우리의 리소스 중 일부에 대한 액세스를 부여할 경우 당연하게도 타사 AWS 계정 ID가 필요할 것이다.

이때 가장 중요한 건 바로 여러분이 외부 ID를 정의해야 한다는 점이고, 이 외부 ID는 우리와 타사 간의 비밀로 우리가 직접 정의해야한다.

이를 통해 우리 계정의 역할에 대한 액세스를 타사에 부여하고 해당 역할에는 그 타사에게만 액세스가 있도록 정의하는 것이다.
따라서, 이 외부 ID는 우리와 타사 간 해당 역할에만 관련이 있다.

또한 외부 ID는 신뢰를 정의하고 역할을 인수할 때 설정되어야 하며, 타사가 반드시 이를 선택해야 할 것이다.

그리고 여러분은 IAM 정책에서 권한을 정의하면 끝이다.

혼동된 대리자 (Confused deputy)

위 그림에서 왼쪽은 나의 계정 가운데는 타사 계정 오른쪽은 나의 계정을 공격하려는 계정이다.

그리고 공격을 위해서는 가운데에 있는 계정을 이용해야 한다.

외부 ID를 사용하지 않는 경우

먼저 좌측의 계정이 ExampleRole이라는 역할을 생성.
이 ExampleRole은 중간 계정으로 인수된다,

해당 ExampleRole의 ARN이 있으니 ExampleRole을 인수하고
해당 역할을 사용하는 우리의 계정 내 일부 리소스에 액세스할 수 있다.

이때 오른쪽은 또 다른 AWS 계정이 우리의 계정을 공격하려 한다면, 중간에 있는 계정에 먼저 접근할 것이다.

오른쪽 계정은 중간 계정에 역할을 제시하며 이 역할로 공격하려는 계정에 액세스할 수 있다고 할 것이다.

이때 공격을 주도하는 계정에서 역할을 주는 대신 중간 계정에게 동일한 AWS1:ExampleRole ARN을 제공한다.

중간 계정은 해당 역할이 좌측과 우측 계정 중 어디에서 왔는지 검증할 수가 없기 때문에 중간 계정은 그대로 역할을 인수할 수 밖에 없다.

해당 역할에 대한 인수가 이루어지며 중간 계정은 우측 계정이 아닌 좌측 계정으로부터 역할을 인수한다. 알지도 못한 채!

이에 중간 계정은 우측에 대해 액세스가 이루어진다고 생각하겠으나, 실제 액세스는 좌측에 대해서 이루어지는 것이다.

이것을 혼동된 대리자라고 한다.

중간 계정은 우측의 계정에서 작업을 수행한다고 생각했지만, 실제로는 좌측의 계정에서 작업을 수행하니 말입니다

외부 ID를 사용하는 경우

하지만 이번에는 해당 역할을 인수할 때 외부 ID를 정의한다고 하자.
이 외부 ID는 나의 계정과 중간에 있는 계정이 공유하는 시크릿이다.

인수해야 하는 계정 ARN이 있는데, 해당 ARN을 인수할 때에 미리 두 계정이 함께 정의한 외부 ID를 입력하는 방식이다.

두 계정 모두 아는 외부 ID를 입력했을 때 역할에 액세스할 수 있도록 하는 것

그렇기 때문에, 우측에 있는 또 다른 AWS 계정이 공격을 시도할 때, 좌측 계정의 역할을 이용하려 할 텐데 외부 ID는 알 수 없을 테니 또 다른 외부 ID를 중간 계정에 제공하게 될 것이다.

하지만 해당 외부 ID는 미리 설정한 외부 ID와는 상이할 테고, 따라서 중간 계정이 틀린 외부 ID를 이용하여 여러분의 AWS 계정에 액세스할 수도 없다.

정리하자면, 타사 계정을 사용하면서

우리의 AWS 계정에 대한 액세스를 부여하고 이 과정의 보안을 유지하려 할 때

STS AssumeRole API와 외부 ID를 이용하도록 권장하는 바임.

주요 API

AssumeRole(가장 기본적) : 나의 계정 내, 혹은 계정 간 액세스를 돕는 API
AssumeRoleWithSAML : 패더레이션 자격 증명을 위한 API
AssumeRoleWithWebIdentity : idP를 이용하여 Amazon Cognito Amazon login Facebook, Google, OpenID, Connect 호환 IdP
현재 AWS 는 권장하지 않지만, Cognito 사용을 지향한다.
GetSessionToken API : 자격증명을 얻기 위해 MFA를 사용하는 경우에 해당
GetFederationToken API : 프록시 앱을 사용하는 경우, 임시 자격 증명을 얻을 때 사용 예를 들면, 회사 네트워크 내 토큰을 분배해야 하는 경우