AWS 계정과 IAM, Organizations

AWS에 계정을 생성하면, 기본적으로 루트 사용자로 생성되며, 해당 루트 사용자는 계정에 대한 모든 권한을 갖은 채로 생성됩니다. 루트 사용자를 가지고 계정을 관리, 운영하게 될 경우, 1개의 계정을 여러 사람이 사용하게 되어 누가 어떤 작업을 수행했는지 관리하기 어렵고, 모든 권한을 보유하고 있어 보안 측면에서도 권장되지 않습니다.

따라서, 기업이 AWS를 사용하는 다양한 행태를 보완하기 위해 AWS는 IAM과 Organizations 기능을 제공합니다. IAM는 사용자 단위로 부여가능한 계정으로, Organizations는 기업,조직 전체과 관리하기 위한 관리 체계로 제공되는 기능입니다.

IAM

IAM은 Identity & Access Management의 약자로, AWS 콘솔과 AWS CLI, AWS SDK 등 다양한 AWS 기능 별로 권한을 부여할 수 있는 사용자 단위의 계정입니다.

하나의 AWS 계정에 IAM 계정을 여러개 생성할 수 있으며, 각각의 IAM 계정에는 목적별로 권한을 부여할 수 있습니다. 예를 들어, 아래와 같은 방식으로 계정에 하위 IAM을 만들어 각 개발 구성원들에게 적합한 기능과 권한을 부여할 수 있습니다.

  • CTO: Administrator 권한이 부여된 계정
  • 개발자: EC2FullAccess 권한이 부여된 계정
  • 외부 컨설턴트: ReadOnlyAccess 권한이 부여된 계정
  • 데이터 엔지니어: AmazonRDSDataFullAccess 권한이 부여된 계정

하나의 루트 사용자에 이용 중인 모든 서비스에 대해서, 각 서비스별 또는 전체 서비스에 대해 Read,Full 액세스 권한이 부여 가능하고, 세부 권한 부여를 위해 정책을 직접 생성하고 관리할 수 있습니다.

예를 들어 S3만을 관리하는 팀원에게는 S3FullAccess 권한만을 부여할 수 있으며, S3에 업로드되는 컨텐츠의 모니터링을 담당하는 봇을 만들때는 Read 권한과 Delete 권한만을 부여하여 읽고, 삭제하는 역할만 부여할 수 있습니다.

S3에서 파일을 읽고, 삭제하는 권한만 부여한 IAM 만들기
IAM 사용자 생성

위에서 예를 든 S3 모니터링 봇을 위한 IAM를 생성해보겠습니다. 먼저 IAM 메뉴로 이동하여, 사용자 메뉴로 이동한 후, 사용자 추가를 눌러 아래 화면을 입력합니다. 봇으로 사용할 IAM 사용자이기 때문에, AWS 콘솔 접속을 위한 비밀번호 대신 액세스 키 방식으로 자격 증명 유형을 선택합니다.

IAM 사용자 권한 부여

S3에서 읽기와 삭제만 가능한 특수한 권한을 부여해야 하니, 권한 설정 메뉴에서 정책을 새로 만들고, 해당 정책을 S3-monitoring-bot에게 부여해보겠습니다. 권한 설정 메뉴에서 기존 정책 직접 연결을 누른 후, 바로 밑에 정책 생성을 눌러 이동합니다.

입맛에 맞는 정책 생성

IAM 정책을 편집할 때, AWS는 시각적 편집기라는 편리한 툴을 통해 수천개가 넘는 권한을 손쉽게 등록할 수 있도록 돕습니다. 서비스 항목에서 S3를 선택하고, 작업 항목에서 버킷 읽기, 오브젝트 가져오기, 오브젝트 삭제 권한을 1개씩 부여합니다.

버킷 내 오브젝트 삭제 권한

버킷 내 오브젝트 조회 권한

버킷 목록 조회 권한

작업 가능 권한을 모두 부여한 뒤에는, 어느 리소스에 접근 가능하게 할지 정할 수 있습니다. 리소스 메뉴에서 특정 Bucket과 특정 Object 만 가능하게 부여하거나, 전체 리소스에 대해 지정할 수 있습니다.

최종적으로 정책을 검토하는 화면에서 정책 이름과 설명을 입력한 후, 정책 생성을 클릭하면 정책 생성이 완료됩니다.

생성한 정책 연결

이제 다시 IAM 사용자 생성 메뉴로 돌아가, 기존 정책 직접 연결 하단의 새로고침 버튼을 클릭한 후, 조금 전 만든 s3-monitoring-bot-policy를 검색하여 선택합니다.

생성한 IAM 사용자 액세스키 확인

정책 생성 후 단계들을 마무리하고, 사용자 추가를 완료하면, 해당 IAM의 접속 권한 정보를 확인할 수 있습니다. 비밀 액세스 키는, 생성 직후 1번만 조회가 가능하기 때문에 반드시 csv 다운로드 버튼을 눌러 파일로 저장해두거나, 기억할 수 있는 공간에 보관해두어야 합니다. 만일 비밀키를 잃어버린 경우, IAM 계정의 세부 메뉴로 들어가 새로운 액세스 키를 만들고, 기존 키를 비활성화 할 수 있습니다. 이 경우, 동일한 액세스 키를 사용할 수는 없습니다.

이제 AWS CLI 또는 다양한 AWS third party library를 통해 작동가능한 IAM 계정이 생성되었습니다. 이 계정은 S3의 버킷 리스트와 버킷 내 오브젝트 리스트를 조회할 수 있고, 신규 업로드나 수정은 불가능하지만, 오브젝트를 버킷에서 삭제할 수 있습니다.

Organizations

단일 서비스를 제공하는 기업은 AWS 계정에 생성한 루트 사용자 1개와 IAM를 이용해, 별도의 추가 계정없이 1개의 루트 사용자를 이용하는 것을 권장합니다. AWS는 계정(루트 사용자) 단위로 비용이 청구/정산되고, 계정간에는 이용중인 서비스에 대한 접근이나 변경이 막혀있기 때문입니다. 하나의 개발팀이 여러 서비스를 운영할때도 여러 루트 사용자를 생성하는 것 보다는, 1개의 루트사용자를 생성하는 것이 개발 효율성 면에서도 도움이 됩니다. 여러 루트 사용자를 이용할 경우, 장애 발생시나 모니터링 시에 원인 파악에 있어서 계정간 정보가 공유되지 않아 여러 계정을 탐색해야 하기 때문입니다.

하지만, 여러 팀이 각각 하나의 서비스를 운영하는 큰 조직이라면 한개의 AWS 계정에 너무 많은 서비스가 들어가 관리하기가 어려워집니다. 이러한 상황에서 사용이 권장되는 것이 Organizations 기능입니다.

여러 AWS 계정을 1개의 Organizations(조직) 에 초대 및 연결하여, 루트 계정을 통해 조직 내 모든 하위 계정의 비용을 관리하고, 청구할 수 있습니다. 더 나아가 계정 별로 정책을 생성해 계정의 행동/권한에 제약을 둘 수 있습니다.

  • Company – Root 계정이 생성한 Organizations
    – Engineer 팀 (조직 내 하위 그룹)
        – 서비스 1팀 계정(루트 사용자)– 서비스 2팀 계정– Data 팀 (조직 내 하위 그룹)
        – 데이터 분석 계정– 파이프라인 계정

위와 같이 부서별로 목적에 맞게 계정을 생성하고, 각 계정의 자율성을 보장하되, 회사의 전체 AWS 비용을 하나의 계정(Root 계정)이 조회할 수 있도록 합니다. 또, 위 예시의 Data 팀이 부가적인 서비스 신청/작업이 불가능하도록 권한을 차단할 수도 있습니다.

언제 Organizations (조직) 기능을 사용해야 할까요?

Organizations 기능은 대규모 조직에게는 없어선 안될 필수 기능이지만, 기업의 규모가 작을때는 권장되지 않습니다. 특히, 1개나 2개 정도의 연관된 서비스를 운영하는 팀/기업이라면 계정이 분리되는 시점부터 능동적이고 빠른 대응이 어렵고, 계정별로 관리/운영하고 있는 AWS 서비스에 대한 별도 관리가 추가적으로 필요하기 때문입니다.

AWS에서는 크게 2가지 경우에 대해 Organizations 기능 사용을 권하고 있으며, 이 외 경우에는 IAM 기능을 활용한 단일 AWS 계정을 권장합니다.

  • 보안성 규정 준수가 필요할 때: HIPAA 또는 PCI와 같은 규정 준수나 기업 내 특정 보안 요구사항이 필요할 때
  • 비즈니스 프로세스가 분화되고 규제 및 예산 요구사항이 부서별로 필요할 때: 부서별/서비스 별 예산을 설정하고 예산 단위로 계정을 운영해야 하거나, 비즈니스가 다양하게 분화되어 하나의 AWS 계정이 하나의 서비스/비즈니스를 관리해야할 필요성이 있을 때
Organizations 기능 깊게 파보기

Organizations 메뉴로 이동하면, AWS 조직 생성 버튼이 노출되며, 조직을 생성할 수 있습니다. 조직 생성 과정은 단순히 Root 계정으로 사용할 AWS 계정으로 콘솔에 접근해 조직을 생성하면 됩니다.

이후, 조직에 각각의 AWS 계정을 초대하고 각 계정별로 그룹을 만들어 그룹 단위로 권한을 설정하거나 조정할 수 있습니다. 기본적으로 조직이 생성되면 Organizations 정책이 모두 비활성화 된 채로 생성되는데, 조직 기능을 통해 특별한 권한 부여가 필요한 것이 아니라면, 그대로 사용할 수 있습니다.

계정 초대하기

조직에 계정을 추가할 때는 크게 2가지 방법을 사용할 수 있습니다.

  • 이미 생성되어 이용중인 AWS 계정을 조직에 초대하기
  • AWS 계정을 임의로 생성하여, 조직에 초대하기

대부분의 경우 조직이 커졌을때 이미 AWS 계정이 있기 때문에, 해당 계정을 루트 사용자 이메일 또는 계정 ID (12자리 숫자: XXXX-XXXX-XXXX)로 초대할 수 있습니다.

계정을 생성하여 초대할 경우, 계정 내 카드 정보가 등록되지 않아, 조직에서 제거할 수 없으니, 생성하여 초대된 계정을 조직에서 내보낼때는 반드시 카드 정보를 등록해야 합니다.

SCP – 서비스 제어 정책 활용하기

만일, 계정별로 서비스 사용 정책을 부여하고자 한다면, 조직 > 정책 메뉴에서 서비스 제어 정책을 활성화 하여 시작할 수 있습니다.

서비스 제어 정책은 조직에 포함된 계정들이 특정 AWS 서비스를 이용하지 못하게 해야하는 경우 사용됩니다. 기본적으로 AWS 계정은 내 계정 내에서는 모든 권한을 부여받은 상태이지만, 조직에 초대된 이후부터는 특정 서비스의 사용 권한이 차단될 수 있습니다. 조직의 AWS 계정에 대한 정책 설정은 IAM의 정책 생성 과정과 동일하며, Json 형식으로도 작성할 수 있습니다.

해당 정책을 생성하여, 그룹(조직 내 하위 구조) 단위 또는 계정 단위로 해당 정책을 적용하여 줄 수 있습니다.

AWS 계정 관리를 위해 주의할 것

처음 AWS를 이용하기 시작할때, 계정을 다중으로 잘못 생성하거나, 개발자별로 계정을 생성해 해당 계정 정보가 없어지거나, 매달 청구되는 비용을 해지하지 못하는 경우가 발생하기도 합니다. 대부분의 경우 스타트업은 1개의 AWS 계정을 운영하는 것이 권장되고, 다중 서비스를 운영하는 경우에도 개발팀의 규모가 크지 않다면 1개 AWS 계정을 운영하는 것이 좋습니다.

특히 AWS 파트너(위시켓, 베스핀글로벌, 메가존 등)들의 할인 혜택을 받고자 한다면 해당 파트너가 보유한 조직의 하위 계정으로 초대받는 방식으로 할인 적용이 이루어지기 때문에, 서버의 비용이 부담되는 기업들은 1개의 AWS 계정을 운영하는 것이 더 효과적일 수 있습니다.

다만, 개발팀의 규모가 커져 여러 서비스를 운영하고, 팀별로 완전히 독립적인 서비스/비즈니스 운영이 이루어진다면 보안을 위해 계정을 분리하고 조직을 생성하는 것이 좋습니다.

현재 AWS를 사용하면서 계정을 분리할지, 1개로 유지할지 고민중이라면, 현재 개발팀이 운영하고 있는 서비스나 비즈니스가 여러 개발팀으로 나뉘어 1:1로 운영이 가능한지 고민해보고 결정하면 좋겠습니다.

Categorized in:

개발,

Tagged in: