AWS로 클라우드 시작하기: ⑤IAM & Organizations

요즘 많은 기업이 채용 과정에서 클라우드 사용 경험을 요구하고 있습니다. 비즈니스 요구사항이 다변화하면서 자유롭게 서버를 확장∙축소할 수 있는 클라우드가 많은 기업에게 사랑받고 있습니다. AWS, GCP, NCP, Azure 등 다양한 클라우드 환경에서 가장 사랑받는 서비스를 꼽자면 AWS일 것 같습니다.

기존 온프레미스에 익숙한 개발자들에게 클라우드는 설정할 것들이 너무 많은 어려운 존재인데요. AWS를 처음 접하는 개발자들이 AWS를 친숙하게 이해하고, 클라우드 설계를 진행할 수 있도록 기초적인 내용을 전달하고자 총 6개의 시리즈로 아래와 같이 진행될 예정입니다. 오늘은 기업이 AWS를 사용하는 다양한 행태를 보완하기 위해 제공하는 IAM과 Organizations 기능을 살펴보겠습니다.

AWS 계정과 IAM, Organizations

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

따라서 기업이 AWS를 사용하는 다양한 행태를 보완하기 위해 AWS는 IAM(Identity & Access Management)과 Organizations 기능을 제공합니다. IAM는 사용자 단위로 부여할 수 있는 계정이며, Organizations는 기업∙조직 전체를 관리하기 위한 관리 체계로 제공되는 기능입니다.

IAM

IAM은 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개씩 부여합니다.

1) 버킷 목록 조회 권한

2) 버킷 내 오브젝트 조회 권한

3) 버킷 내 오브젝트 삭제 권한

작업 가능 권한을 모두 부여한 뒤에는, 어느 리소스에 접근할 수 있게 할지 정할 수 있습니다. 리소스 메뉴에서 특정 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로 운영이 가능한지 고민해보고 결정하면 좋겠습니다.