AWS IAM (Identity and Access Management)

Public 공간에 오픈된 AWS 서비스를 관리하고자 할때 수많은 사용자들의 접근과 제어 요구사항들..

어떤 사용자는 웹 브라우저로 또 어떤 사용자는 CLI 환경으로 액세스하여 테스트 및 확인하길 원하며, 또 그 환경은 개발/테스트/운영 환경 별로 또한 요구사항이 다릅니다.

또한 온 프레미스 환경 기반 SSO, LDAP 등의 통합 인증 체계와의 연동이 필요할 수도 있고, 보안 팀에서는 AWS 환경을 누가 수정하고 있고 어떠한 내용을 점검했는지 감사 로그를 확인하고 싶기도 합니다.

모바일 앱은 수천 명의 사용자를 동시에 인증해야 하기도 합니다.

자 이러한 환경에서 운영자는 AWS를 운영하기 위해 어떻게 해야 할까요?

 

# 본 포스팅은 개인적으로 또는 회사 차원에서 진행한 TF의 다양한 학습 결과 그리고 Architecting On AWS 교육 등을 통해 습득한 지식을 리마인드하며 공유하는 것임을 알려드립니다.

 

지금부터 살펴볼 AWS IAM (Identity adn Access Management) - 리소스 접근 제어는 이러한 문제를 속시원하게 풀어줄 방법을 제시합니다.

먼저 AWS에서 제공하는 다양한 인증 관련 Component를 살펴보겠습니다.

---

- IAM : 사용자, 그룹 및 역할 관리
- 자격 증명 연동 관리
- Amazon Cognito : Mobile 등의 애플리케이션이 AWS에 접근하고자 할 경우 인증
- AWS Organizations : 빌링 그룹

---

먼저 계정 사용자 및 IAM의 이해 과정을 살펴보고 본격적으로 세부사항을 살펴보겠습니다.
- 사용자의 접근 정책에 따른 자격 증명 방식입니다.
Web Console : ID/PW (자격 증명)
CLI : AccessKey/SecretKey
- 앱 또는 서버에서의 접근 정책
SDK API : AccessKey/SecretKey
- 정책 부여 방식에 따른 권한 부여
1) 사용자에게 권한 부여
2) 그룹에게 권한 부여
3) 롤을 부여
- 다른 계정에 부여할 롤 : 다른 계정에서 나의 리소스를 접근하고자 할 경우 롤을 생성하여 권한을 부여
- 기존 인증 시스템과의 연동 롤 : SAML 2.0 스펙 기준 LDAP / DX 등으로 AWS에 접근 가능하도록 롤을 생성 할 수 있음
- WEB Identity 인증 업체와의 연동 롤 : Amazon, Facebook, Google 연동
- AWS Service용 롤 : 자격 증명을 STS를 이용해서 임시 자격 증명을 받을 수 있음 (기간 베이스 자격 증명 발급)

자 그럼 어떻게 하면 안전하게 AWS 환경을 관리할 수 있을까에 대한 고민부터 시작해 봐야 할 텐데요.

바로 IAM 관리 사용자 생성하고 막강한 힘이 있는 루트 사용자 자격 증명을 잠가 버리는 것입니다. (자격 증명 키를 파기하라. 언제든 다시 만들수 있음)
권한에 관련된 사항은 IAM 관리 사용자를 이용하고 액세스 권한을 세분화하여 관리하는 것이 중요 (개발, 테스트, 운영) 합니다. 프로젝트 초기에 이와 같은 세분화된 사용자 / 그룹 / 환경 정책을 세우고 정형화 하는 것이 굉장히 머리 아프고 힘든일이 되겠지만, 이는 이후 프로젝트의 성패를 결정할 정도로 굉장히 사소하지만 중요한 부분이라는 것을 깨달을 것입니다.

따라서 다소 번거롭더라도 초기에 이에 대한 권한 구분이 있는 IAM 관리 사용자를 생성하는 것은 굉장히 중요합니다.

AWS IAM (AWS Identity and Access Management)

일반적으로 AWS에 국한 되지 않더라고 사용자 관리 정책은 관리자와 운영자 그리고 개발자로 구분하여 설계하게 됩니다.

다만 AWS의 경우 비용에 따른 결제 시스템이 존재하여 기존 설계 방식에서 비용을 차지하는 용도의 Organization 역할을 수행하는 그룹 관리자를 추가로 설계하게 됩니다.

- 기존 온-프렘 인증 서비스와 연동 가능
- 다른 AWS 서비스와 통합
- 애플리케이션의 안전한 액세스가 가능함
- 세부적인 권한 설정이 가능함
- IAM 사용자는 기본적으로 부여되는 권한이 없으며, 명시적으로 권한(Policy)을 부여해야 함
- IAM에서 명시적으로 거부되어 있는지를 판단하고 명시적으로 허용되어 있는지를 판단함. 둘다 없으면 거부로 판단.
- 자격 증명 기반 정책 : 사용자, 그룹, 역할 등에 수행 작업(기동, 종료), 리소스 대상(특정 버킷), 필요한 조건(특정 소스 IP) 등을 부여 (AWS 관리형, 고객 관리형, 리소스 자체에서 인라인 형태로 제공 가능)
- 리소스 기반 정책 : AWS 리소스 (Amazon S3, Amazon S3 Glacier 및 AWS KMS)에 특정 보안 주체가 허용한 작업, 필요한 조건, 항상 인라인 정책이며, AWS 관리형 리소스 기반 정책은 없음

AWS IAM 역할

AWS IAM 역할은 다음과 같은 경우에 사용될 수 있습니다.

- AWS 리소스에 aws 서비스에 대한 액세스를 제공하는 경우
- 외부 인증 사용자에게 액세스를 제공하는 경우 (SAML 2.0)
- Web Identity 액세스를 제공하는 경우
- 자신의 AWS 계정, 다른 AWS 계정에서 리소스에 액세스하게 하는 경우

또한 역할은 콘솔, CLI, AssumRole API 및 AWS Security Token Service (AWS STS)를 사용하여 위임될 수 있습니다.

STS 자격 증명 브로커

- 사용자가 브로커에 액세스 요청 -> 사용자 액세스 자격 증명 브로커 -> 자격 증명 브로커 인증 사용자(SSO/LDAP 등) -> 브로커는 AWS STS와 통신하여 임시 자격 증명을 발급 -> 임시 자격 증명을 기반으로 사용자는 AWS 서비스 또는 콘솔에 액세스

 

SAML

사용자 관점에서는 프로세스가 투명하게 처리 됩니다. 사용자는 조직의 내부 포털에서 시작하여 AWS 자격 증명을 제공할 필요 없이 콘솔로 로그인하게 됩니다. JWT 방식과 함께 대표적인 클라이언트 인증 방식 중 하나입니다.

 

AWS Cognito

AWS Cognito는 웹 및 모바일 앱에 대한 인증, 권한 부여 및 사용자 관리를 제공하는 완전 관리형 서비스로 인증 및 토큰 가져오기 (사용자 풀), AWS 자격 증명용 토큰 관리 (자격 증명 풀)로 구성되어 있습니다.

AWS Organizations

중앙 집중식 계정 관리 방식으로 그룹 기반 계정 관리, AWS 서비스에 대한 정책 기반 액세스와 자동화된 계정 생성 및 관리를 지원합니다.

또한 통합 결제, API 기반 호출 처리등을 지원합니다.

 

이번 포스팅은 다소 지루한 내용이었지만, 네트워크와 마찬가지로 굉장히 중요한 AWS 지침 중 하나라고 볼 수 있습니다.

AWS의 다양한 정책 기반 IAM을 파악하고 보다 효과적인 관리 체계를 만드는 것은 굉장히 중요합니다.

 

다음 포스팅에서는 마이크로 서비스 아니 클라우드 환경 만을 놓고 봤을때도 매우 중요한 포인트라고 단정지어 말할 수 있는 Telemetry 관련 요소들 탄력성, 고가용성 및 모니터링을 위한 방안 등을 이야기 해보도록 하겠습니다.