오늘은 AWS 계정 간 권한 관리에 대해 이야기해볼까 해요.

과거에는 하나의 단일 AWS 계정에서 모든 서비스를 실행하였다면, 시간이 지나고 클라우드라는 개념이 팀 혹은 회사 내에 안착되고 다루는 서비스의 범위가 커지자 워크로드도 점점 커졌어요.

마치 과거 Legacy 환경 처럼요...

그래서, 우리는 이러한 AWS 리소스 인증 관리의 어려움을 겪었을 거예요.

• 부서별, 서비스별, 환경별로 늘어나는 AWS 계정과 관리하는 인력의 제한

• 회사 규모와 compliance에 따라 복잡한 정책과 권한 및 인증 관리

• 기존 SSO 솔루션과 AWS 연계의 어려움

과거 호랑이 담배 피우던 시절에는 이러한 어려움을 극복하기 위해 SAML 2.0을 지원하는 SSO 솔루션을 각 AWS 계정의 roles에 assume 해서 사용하기도 하였어요.

가장 대표적인 솔루션이 ADFS(Active Directory Federation Services)가 있죠.

하지만 관리 포인트는 존재하였으니...

1. ADFS에서 rules을 수정할 때 syntax error 발생하게 되면 ADFS 인증 웹 페이지가 출력이 안 됨... ㅜㅜ

2. AD의 group에 시작하는 인자의 규칙이 있어서 준수하여야 함.

3. AWS 계정별로 SAML 설정과 roles 설정을 관리자가 직접 해주어야 함.(개귀..찮..)

그래서 이런 점을 보완하기 위해 AWS에서는 서비스를 내놓았는데!!

그 거 슨 바로!!

AWS Single Sign-On(SSO) 되시겄다 이말입니다!!

그럼 AWS SSO를 좀 더 자세히 알아보도록 하죠.

AWS Single Sign-On(SSO) 란?

• AWS 계정 및 비즈니스 애플리케이션에 대한 접근제어를 중앙에서 관리하는 클라우드 싱글 사인온(SSO) 서비스

장점 #01: 다중 AWS 계정에 대한 접근 관리

장점 #02: 손쉽게 설정 가능 (진짜 간단함..)

장점 #03: 기존 인증 서비스 연계 가능 (External IdP와..)

장점 #04: AWS SSO를 중심으로 SaaS 앱 연동 가능 (Github, Salesforce, Tableau ….)

으마으마한 장점이쥬..

일단 AWS SSO를 사용하려면 몇 가지 제약 조건을 먼저 확인해야 해요.

• AWS Organization 서비스가 설정되어 있어야 하며, managed account에서 SSO를 활성화 할 수 있어야 해요. (member 상태에선 SSO를 활성화 시킬 수 없음)

• 만약 External IdP를 연결할 경우

  • IdP에서 SAML 2.0을 지원하는지 확인

  • IdP에서 SCIM을 지원하는지 확인

제약조건에 걸리는 게 없다면 AWS SSO를 활성화해야 하는데요.

그 전에 앞서 AWS SSO도 리전 단위 서비스로 리전을 선택해야 해요!

• AWS SSO supported regions

리전을 선택할 때에는 보통 서울 리전을 선택하시겠지만, 일부 AWS SSO를 사용하시는 이유가 특정 AWS 서비스를 이용하기 위함이라면, 해당 서비스를 지원하는 리전에서 활성화하시길 권해 드려요.

자, 이제 AWS SSO를 시작해 봐요.

과정은 아래와 같아요.

1. AWS Organization 설정

2. AWS SSO 활성화

   • • Option) External IdP 설정

3. AWS SSO 기본 설정들

   • • 사용자 URL 변경

     • MFA 인증 방식 선택

     • User/Group 생성

     • Permission sets 정의

SSO 서비스를 활성화 하는 것은 정말 간단해요.

이 마법 버튼 하나만 클릭하면 활성화 끝.

물론 만약 리전을 잘못 선택하였다면, 삭제하고 다른 리전에 다시 만들면 돼요.

(AWS SSO는 계정에 한 개의 리전에서만 활성화 가능)

활성화하게 되면 Organization의 모든 AWS account가 표시돼요. 💫

(실제 테스트한 스크린샷을 넣고 싶었으나, 보안상 아쉽게 못 넣었어요...😭)

이제 Users와 Groups를 생성해요.

(만약 External IdP를 사용한다고 하면 불필요한 과정이겠쥬?)

Users나 Groups에 matching 시킬 permission sets도 정의해요.

Permission sets은 IAM policy와 동일한 형태로 사용할 수 있어서 작성하기 비교적 편하더라구요.

혹시 assume role을 통한 cross account 구현을 해보셨나요?

AWS SSO에서 assign 한다는 것은 assume role을 자동화한 것으로 생각하시면 돼요.

실제로 assign 한 후에 해당 계정에 접근하면 AWS SSO 서비스가 배포한 role이 존재하고, 사용자들은 이 role을 통해 콘솔 화면에 접근하는 것이예요.

하위 계정에선 이러한 role을 확인할 수 있을 거예요!!

자자, 우리는 금방 User/Group과 Permission sets를 만들어봤어요.

그리고 어떻게 사용자 전환이 되는지 알아봤죠.

이제 User의 관점에서 로그인하면 어떻게 하면 될까요?

이런 식으로 Assign한 AWS Account와 permission sets만 보이면 돼요.

각 AWS 계정의 사용자는 손쉽게 계정별로 제어가 가능해지는 것이예요.

그리고 하위 계정으로 접근하게 되면 CloudTrail에서도 깔끔하게 접근 로그가 남아요.

이 말인즉슨, CloudTrail 로그를 취합해서 가시성을 가질 수도 있겠죠.

이만 포스터는 끄읕!!

(다음에는 뭘 써볼까.. 흠..)