RBAC with AWS IAM

블로그에서 설명한 역할기반 접근제어 시스템을 테라폼 (Terraform)^[각주:1] 으로 구현하였다. 접근 제어와 권한 관리를 코드로 처리할 수 있기 때문에 이력관리, 자동화, 보안정책 리뷰에 장점이 있다. 이 프로젝트의 이름은 패스포트 (Passport)이며 모던 어플리케이션을 위한 다중 AWS 계정의 역할기반 접근제어 프레임워크이다. 자세한 내용은 저장소(https://github.com/Young-ook/terraform-aws-passport)에서 확인할 수 있다.

---

RBAC (Role-Based Access Control, 역할기반 접근제어)는 엔터프라이즈 (Enterprise)환경에서 각 개인이 시스템에 접근할 수 있는 권한을 역할 기준으로 통제하는 것이다. 간단한 예를 들면, 공항에서, 일반 직원과 관리책임자, 그리고 여행객이 갈 수 있는 공간이 구분되어 있는 것과 같다. 먼저 역할의 개념을 생각해 보자. 관리자라는 역할이 있다면 어떤 권한을 가져야 하는 지 쉽게 알 수 있다. 우리가 필요에 의해 어떤 담당자를 정의한다면, 그 순간 그 담당자가 해야할 일과 가져야 하는 권한을 함께 정의할 수 있는 것이다. 그리고, 이렇게 생각해 볼 수 있다. 역할은 어떤 특정 사람을 지칭하는 것이 아니므로 어떤 사람에게 역할을 부여하거나 변경하는 것만으로도 유연하고 효율적으로 권한을 부여하거나 회수 할 수 있다. 그래서 역할기반 접근제어를 하게 되면 유연하고 직관적이며, 효율적인 통제가 가능하다.

이러한 역할기반 접근제어가 엔터프라이즈 환경에서 필요한 것은 사람들이 많기 때문이다. 사람이 적을 때는 옆 집 살림살이를 서로 알 정도로 투명하다. 그래서 자연스럽게 서로 감시가 된다. 그러나 사람이 많으면 이러한 관심과 감시가 어렵기 때문에 신뢰를 기반으로하는 접근관리는 현실적인 대안이 되기 어렵다. 스타트업에서는 서로를 잘 알기 때문에 특별한 접근 통제의 필요성을 느끼기 어렵겠지만, 엔터프라이즈 환경에서는 다양한 사람들이 드나들기 때문에 역할과 권한을 관리하는 체계가 필요하다. 최근에는 엔터프라이즈 환경이라도 역할기반 접근통제방식만 사용하지 않는다. 빅데이터 (Big Data) 시스템을 이용하여 개인의 행적을 추적할 수 있기 때문에, 시스템에서 자동으로 권한을 조정하는 방법도 일부 활용하고 있다. 이 내용에 대해서는 다음에 기회가 된다면 다루어 보겠다.^[각주:2]

역할기반 접근통제는 장점도 있지만, 단점도 있다. 역할에 따라 권한정책을 정의하기 때문에 정책이 현실에 딱 맞게 떨어지지 않는다. 먼저 여러 역할에 조금씩 겹치는 권한정책이 있을 수 있다. 거의 비슷한 일을 하지만, 아주 약간 다른 일을 해야 한다면 각 역할을 별도로 만들어야 한다. 그래서 90% 비슷한 권한을 가진 역할이라도 목적이 다르면 역할을 변경해서 접속해야 한다. 다른 한 편으로는 역할에 지정하는 권한정책이 세밀하지 못하다는 단점이 있다. 여러 상황을 추상화해서 역할을 만들어야 하지만, 현실의 상황을 반영하여 딱 맞는 역할과 권한을 설계하는 것은 쉽지 않기 때문이다. 만약 세밀한 권한관리를 하기 위해 역할을 매우 작은 단위로 나누게 되면 사용자는 역할 전환을 자주해야 하는 상황이 생긴다. 반대로 역할을 큰 단위로 설계하면 필요이상으로 많은 권한을 열어 주게되므로 보안에 취약해 진다. 그래서 보안강화와 사용자 불편(또는 불만)을 잘 타협하여 적절한 역할 범위를 설계해야 한다.

스타트업에 참여하게 되면서 기존 환경을 역할기반 접근제어 환경으로 전환하는 일을 하였다. 회사의 성장에 따라 직원들이 급격하게 증가하였는데, 역할기반 접근제어를 적용하여 직원이 늘어나도 안전하게 클라우드 (Cloud Computing) 자원에 접근할 수 있도록 했다. 동시에 효과적으로 규제준수 (Compliance)를 할 수 있었다.

RBAC with AWS IAM

먼저 기존 개발/운영 환경인 단일 AWS 계정 외에 추가로 여러 AWS 계정을 만들었다. 그리고 자격증명을 담당하는 관문계정 (Identity Gateway Account)을 지정하였다. 이 계정에서는 IAM 사용자와 각 사용자가 속한 그룹 (Group)을 관리하도록 하였다. 그리고 각 그룹에 속한 사용자가 어떤 역할로 전환을 할 수 있는 지 결정해주는 권한 정책을 지정하였다. 따라서, 사용자가 어떤 그룹에 속하는 지에 따라 어떤 환경에서 어떤 역할을 맡을 지 결정된다. 또한 보안 강화를 위해서 각 IAM 사용자의 MFA (Multi-Factor Authentication) 활성화를 강제하였다. 그래서 처음 계정을 받으면 자신의 계정정보밖에는 접근할 수 없으며 여기서 MFA를 활성화해야만 그 다음부터 원하는 역할로 전환할 수 있도록 했다.

기존 사용자를 역할기반 접근제어로 바꾸는 전환은 조심스럽게 진행했다. 새 계정을 발급한 후 3주간의 충분한 전환기간을 주었고, 이 기간 후에 기존 계정을 비활성화하여 자연스럽게 역할기반 접근제어 체계로 넘어가도록 했다. 전환 과정에서 나왔던 질문에 대해서는 문제해결 (Troubleshooting)이라는 내용으로 안내 문서에 추가하였다. 또한 운영 장애 상황에 대한 긴급대응이 필요하다는 의견이 있어서 구조대 (Rescue) 역할과 권한을 새로 추가했다. 물론 구조대 역할 남용을 방지하기 위해서 사용자 역할 전환 추적기도 같이 제공했다.

---

1. https://youngookkim.tistory.com/21 [본문으로]
2. 세분화된 접근 제어 시스템과 대규모 감사 로그 분석이 가능해짐에따라, 자유도는 높여주되 보안과 감시는 효율적으로 수행하는 제로트러스트 (Zero Trust)가 등장하였다. [본문으로]