ConsoleMe: 스타트업에서 AWS IAM 권한 관리 잘하는 법

국내 유명 IT 기업은 한국을 넘어 세계를 무대로 할 정도로 뛰어난 기술과 아이디어를 자랑합니다. 이들은 기업 블로그를 통해 이러한 정보를 공개하고 있습니다. 요즘IT는 각 기업들의 특색 있고 유익한 콘텐츠를 소개하는 시리즈를 준비했습니다. 이들은 어떻게 사고하고, 어떤 방식으로 일하는 걸까요?

이번 글은 ‘성과 극대화를 위한 머신러닝. 모바일 마케팅 성과분석 솔루션’ 에어브릿지(airbridge.io)를 만드는 AB180 엔지니어링 팀의 이야기입니다. AWS 권한 부여 프로세스의 변화 이후 겪은 고충과 그것을 해결해 나간 과정을 공유합니다.

IAM 최소 권한 정책

처음 AB180 백엔드 팀에 들어왔을 때 AWS 상의 거의 모든 권한을 가지고 개발할 수 있었습니다. “어떻게 개발자한테 모든 권한을 줄 수 있냐!”라고 할 수 있지만 제가 입사할 당시에 백엔드 팀이 10명 남짓했고 스타트업의 특성상 개발자 한 명이 여러 가지 업무를 할 수 있기 때문입니다. 개발한 애플리케이션 배포, 인프라 수정, QA 용 데이터 조회 등 여러 업무를 원활히 진행하기 위해 팀 내 대부분의 개발자가 많은 권한을 가지고 있도록 했습니다. 풍부한 권한으로 불편함 없이 지내던 중 외부 회사와 파트너십을 맺기 위해 보안 감사를 받아야 했습니다. 보안 감사를 진행하면서 몇몇 개선사항이 있었고 그중 한 가지 수정해야 할 사항이 ‘개발자에게 너무 많은 권한이 부여되고 있다.’였습니다.

개발자에게 어떻게 권한을 주어야 하는지는 AWS의 IAM 보안 모범 사례에 잘 나와 있습니다.

IAM 정책을 생성할 때는 최소 권한 부여의 표준 보안 조언을 따르거나, 작업 수행에 필요한 최소한의 권한만 부여합니다. 사용자(역할)가 수행해야 하는 작업을 파악한 후 사용자들이 해당 작업만 수행하도록 사용자에 대한 정책을 작성합니다. 최소한의 권한 조합으로 시작하여 필요에 따라 추가 권한을 부여합니다. 처음부터 권한을 많이 부여한 후 나중에 줄이는 방법보다 이 방법이 안전합니다.

팀 내에서도 AWS의 권장 사항처럼 최소 권한 정책으로 권한을 지급하기로 했습니다. 권한 맥시멀리스트에서 권한 미니멀리스트로 변경돼야 했을 때 팀 내에서도 “이제 일을 어떻게 하냐” 등 말이 많았습니다. 만약 필요한 권한을 신청할 수 있다면 일단 최소 권한 정책으로 바꾸면 ‘한두 달 정도만 힘들고 권한 문제는 안 생기지 않을까?’라는 생각에 팀 내에 권한 신청 프로세스를 만들어보기로 합니다.

Jira를 활용한 권한 신청 프로세스 도입기

내부적으로 권한 신청 프로세스에 필요한 요구사항은 크게 두 가지였습니다.

1) 개발자에게는 기본적으로 최소한의 권한만 부여될 것

2) 작업 시 추가로 필요한 권한에 대해 신청할 수 있되 사유와 사용 기한이 기록으로 남아야 함

팀 내에서 업무 관리를 위해 이미 지라를 쓰고 있었습니다. 지라 티켓에서는 본문 내용도 적을 수 있고 티켓 상태를 나눌 수도 있으니 ‘권한 신청 기록을 남기는 데 쓸 수 있지 않을까?’ 해서 지라를 권한 신청에 써보기로 합니다. 지라를 쓴 권한 신청 프로세스를 간단히 정리해 보면 아래 세 가지 단계로 이루어졌습니다.

1) IAM 신청용 지라 티켓 생성

a) 필요한 IAM policy를 작성해서 티켓 본문에 첨부

b) 권한이 필요한 이유와 사용 기한을 티켓에 추가

2) 보안팀의 리뷰 후 티켓 상태를 Approve로 변경

3) Terraform에 IAM policy를 추가 후 적용

위 사진처럼 IAM 권한 신청용 지라 프로젝트를 분리하고 티켓 본문에 IAM 요청 시 필요한 사항들을 적을 수 있게 만들었습니다. 모든 권한은 Terraforming 해놓고 권한 신청 리뷰 후 Terraform 파일에 추가만 해서 적용할 수 있게끔 했습니다. 이론적으로는 권한 추가에 필요한 대부분의 기능을 커버할 수 있었습니다. 실전에 들어가기 전까지는 말이죠....

이상과 현실의 차이

팀에서 최소 권한으로 바뀌었기 때문에 권한 신청할 일이 많았지만 Jira 기반의 프로세스의 처리되는 속도가 너무 느려 전체적인 일정이 지체되는 일이 자주 생겼습니다. 권한 신청 프로세스의 병목 지점은 크게 네 가지 부분이 있었습니다.

1) Terraform apply 하는데 3~5분 정도 시간이 필요

모든 권한을 Terraforming 해놓으니 Terraform의 특성상 모든 Policy의 변경사항을 확인해야 하기 때문에 Policy를 추가할 때마다 속도가 점점 더 느려졌었습니다. Plan 단계에서 확인하는 게 오래 걸리다 보니 가끔 다른 작업을 하면서 기다리다가 Apply를 놓치는 경우도 종종 발생했습니다.

2) 개발자의 IAM policy에 대한 낮은 이해도로 인한 시간 오래 걸림

권한 신청이 왔는데 ”AWS 상에 MSK 대시보드에 접근하고 싶은데 권한이 없다네요” 혹은 “이 API를 쓰고 싶은데 무슨 권한이 필요한지 모르겠어요”와 같은 요청이 오면 필요한 권한을 찾아 넣느라 시간이 오래 걸렸습니다. 또한 Jira가 IAM Policy를 Validation 해주는 것은 아니라서 오타가 나거나 하면 수정하는데 또 시간이 드는 경우도 있었습니다

3) 권한 추가 신청이 잦음

AWS에서 IAM 관련 에러는 없는 권한이 모두 나오는 게 아닌 마지막으로 실패한 권한 한 개만 나옵니다. 개발자는 해당 권한이 없다고 해서 권한을 신청 후 다시 시도하면 또 다른 권한이 없다고 나와 다시 신청하는 일이 잦았습니다. 그럼 또다시 시간이 오래 걸리는 1, 2번 문제를 겪게 됩니다.

4) 자주 변경되는 IAM 특성상 Github과 싱크가 안 맞는 경우가 많음

Terraform과 같은 IaC 툴은 가능하면 실제 상태와 코드가 싱크가 맞아야 합니다. 하지만 IAM 변경이 잦다 보니 간혹 권한 신청 처리해 주는 관리자분의 로컬에만 변경사항이 반영되는 일이 많아지며 싱크를 맞추기가 어려워졌었습니다. 이후 다른 관리자분이 권한 신청을 처리할 때 싱크가 안 맞아서 적용하는데 시간이 더 오래 걸렸습니다.

이런 문제들 때문에 권한 한 개를 신청하고 실제 작업할 수 있기까지 최소 10분에서 최대 하루까지 걸리면서 팀원 모두 권한 신청을 꺼려 했습니다. 또한, 두 달 정도면 권한이 어느 정도 정리될 줄 알았지만 새 팀원이 오거나 새로운 컴포넌트 작업을 해야 할 일이 많아지면서 끊임없이 고통받고 있었습니다. IAM 권한 신청을 좀 쉽게 하는 방법이 없을까 하다가 넷플릭스 블로그에서 글을 보게 됩니다.

IAM 권한 신청계의 한줄기 빛 ConsoleMe

ConsoleMe는 Netflix에서 2020년에 공개한 AWS 다중 계정에서 쉽게 IAM 권한 관리를 도와주는 오픈소스 프로젝트입니다. Netflix에서도 저희 팀이 겪었던 것처럼 너무 많은 유저 요청, 잘못된 IAM 요청, 그리고 계속 반복되는 작업 때문에 다른 중요한 문제들을 해결할 수 없어 이를 해결하려 만든 툴입니다. 크게 ConsoleMe의 기능을 간단히 설명하자면 IAM 권한 신청을 쉽게 할 수 있도록 도와주고 IAM Role에 대한 임시 권한을 획득할 수 있도록 도와줍니다.

쉬운 IAM 권한 신청

ConsoleMe는 IAM을 통합해서 관리할 수 있는 웹 콘솔을 제공합니다. 권한 신청, IAM Policy 확인, 권한 신청 기록 확인, AWS 대시보드 접근 등 많은 기능을 제공하고 있고 먼저 제일 많이 쓰게 되는 권한 신청 페이지를 확인해 보도록 하겠습니다.

ConsoleMe 웹 콘솔에 접속해 권한 신청 페이지에서 먼저 권한을 부여할 대상을 선택합니다. 웹 콘솔에서는 AWS 상에 모든 IAM Role, User, Policy를 DynamoDB를 이용해 저장해두기 때문에 권한 신청 대상을 빠르게 찾을 수 있습니다.

이후 지급할 권한을 선택하는 단계에서 어떤 서비스에 권한이 필요한지를 선택합니다. ConsoleMe에는 S3, SQS와 같은 일부 서비스에는 List, Get, Put, Delete로 각 Operation 별로 필요한 권한을 미리 정의해둬서 필요한 권한을 쉽게 획득할 수 있습니다. 이렇게 미리 정의된 권한 외에도 IAM Policy JSON을 작성할 수 있는 Advanced Editor가 포함돼있습니다. 에디터에서는 IAM Action에 대한 자동완성을 지원하고 또한 IAM Policy에 대한 Validation도 해줘 문법적으로 틀린 부분이 있는지 체크할 수 있습니다.

이후 권한 신청 페이지에서 보안팀의 리뷰를 받은 후 Approve를 하게 되면 IAM User 혹은 IAM Role에 권한이 부여되게 됩니다. 이런 신청부터 권한 리뷰 그리고 적용까지 5분이 채 안 되는 시간 안에 클릭 몇 번으로 끝낼 수 있습니다.

SSO(Single sign-on)을 사용한 임시 권한 발급

위에서 얘기한 권한 신청이 간편해지는 것 외에도 IAM User를 만들 필요 없이 SSO를 통해 로그인해 AWS STS(Secure Token Service)를 통한 임시 권한 발급 기능도 제공합니다. AWS 상에서 AWS STS를 사용해 IAM Role에 대한 임시 권한을 받는 것 자체는 꽤 일반적인 Practice입니다. IAM User의 Access Key 같은 경우 해당 키를 Revoke 하기 전까지 영구적이기 때문에 유출이 되면 치명적일 수 있습니다. 이런 문제에 대비해서 주기적으로 Access Key Rotation을 해주거나 해야 하는 등 추가적인 보안 작업을 거쳐 가야 합니다. 이와 반대로 STS는 특정 IAM Role에 대한 임시 권한을 발급받아 해당 Role의 권한을 사용하고 최대 24시간 이후 자동으로 권한이 만료됩니다. 이러한 장점 때문에 IAM 모범 사례집에서도 IAM User 대신 STS를 통한 임시 권한 발급을 더 권장하고 있습니다.

ConsoleMe에서는 STS를 통한 임시 권한 발급을 더 쉽게 할 수 있도록 도와줍니다. Google workspace, Auth0와 같은 SSO provider를 통해 접근한 유저 혹은 그룹별로 어떤 Role에 접근할 수 있는지 Tag에 정의해두면 ConsoleMe 대시보드에서 Role에 대한 임시 권한을 발급받아 AWS 대시보드에 언제든 접근할 수 있습니다. 이 역시 STS를 사용해 임시 권한을 발급받는 형식으로 작동하고 ConsoleMe에서 대신 권한을 발급받아 유저에게 전달하는 형식으로 사용됩니다.

보안 측면 외에도 AWS 계정 여러 개를 운영할 때 계정관리가 편해진다는 장점도 있습니다. 조금 규모가 있는 회사 같은 경우 간단하게는 개발 환경과 프로덕트 환경의 AWS 계정을 나눠서 운영한다던가 비용 관리를 위해 서비스별로 여러 개의 AWS 계정을 운영하는 경우가 있습니다. 이때 IAM User를 사용하게 되면 각 AWS 계정별로 IAM User를 여러 개 만들어야 하지만 ConsoleMe를 통해서 할 경우 여러 AWS 계정의 IAM Role에 대한 접근만 잘 관리를 해두면 Google 계정 하나로 여러 AWS 계정에 접근해서 작업을 할 수 있습니다.

그래서 도입하고 나아졌나요?

처음 팀 내에 ConsoleMe를 도입하자고 할 때 아직 도입 사례도 잘 없는 툴이라 도입을 망설였던 때도 있었습니다. 아마 비슷한 고민을 하고 계신 분들이 있을 듯해서 약 6개월 넘게 사용해 보면서 느낀 장점과 아쉬운 점을 몇 가지 뽑아봤습니다.

장점

1) IAM 신청이 쉽고 빠름

권한 발급 때문에 작업이 하루 이상 미뤄지던 걸 클릭 몇 번으로 신청하고 슬랙에서 권한 신청 알림을 받아 Approve만 되면 5분 만에도 권한 신청이 끝나게 됩니다. 추가 권한 신청이 여러 번 이뤄지더라도 관리자가 Approve를 하는 것 이외에 추가적인 행동이 필요가 없어서 권한 부여 작업에 대해서도 부담감이 없어져 더 빠르게 업무를 진행할 수 있게 됐습니다. 이런 점들 덕분에 팀원들 모두 만족하면서 사용하고 있습니다.

2) 권한 신청 기록이 모두 DynamoDB에 저장됨

어떤 툴을 사용하던 어떤 유저가 무슨 이유로 해당 권한을 받았고 언제까지 사용할 건지에 대한 정보는 남아있어야 하는 게 권한 관리의 가장 큰 요구사항이었습니다. ConsoleMe에서는 모든 권한 신청을 DynamoDB 상에 신청 사유와 언제까지 사용할 건지를 저장해놓고 있어 이런 요구사항을 만족했고 보안팀에서 주기적인 보안 감사를 할 때도 확인하기 좋았다는 후기를 들을 수 있었습니다.

3) 관리자 여러 명이 언제든 권한을 부여할 수 있음

이전에 Terraform을 이용해 관리할 때는 담당자분이 부재 중일 경우 새로운 Policy를 생성해야 하는 등의 프로세스가 잘 정리돼있지 않아 다른 분이 대신해서 권한 부여하기가 어려웠습니다. ConsoleMe에서는 여러 명의 관리자를 지정해놓고 문제가 되는 권한이 있는지 정도만 확인해서 Approve 해주면 되기 때문에 담당자 부재 시에도 권한이 필요할 때 빠르게 필요한 권한을 얻을 수 있게 됐습니다.

아쉬운 점

1) IAM User와 IAM Group에 대한 지원이 불완전함

위에서 설명한 것처럼 ConsoleMe는 STS를 통해 IAM Role의 임시 권한을 사용하는 걸 기본 전제로 만들어진 툴입니다. 만약 팀에서 IAM User 기반의 권한 관리를 하고 있다면 IAM Group에 User를 붙이거나 Managed Policy를 Attach 하는 등의 작업을 지원하지 않고 있기 때문에 불편할 수 있습니다. 현재 저희도 IAM User을 사용하고 있어 이런 점들이 불편할 때도 있습니다. 하지만 대부분 새로운 작업을 할 때 필요한 임시 권한을 신청하는 용도이기 때문에 ConsoleMe를 통해 IAM User에 필요한 권한을 Inline Policy로 신청해 대부분의 상황에서 불편함 없이 사용 중이고 장기적으로는 IAM Role 기반의 권한 체계로 넘어갈 준비 중입니다.

2) Terraform과 같은 IaC 툴로 관리하던 IAM의 싱크를 맞추기 어려움

ConsoleMe의 웹 콘솔 상에서 작업하다 보니 아무래도 Terraform에 변경사항들을 적용하기는 어려워졌습니다. IAM User에 attach 되는 Inline policy의 경우 어차피 임시 권한 부여용으로만 사용되니 Terraform에서 관리를 안 하기로 했고 대신 IAM Group에 attach 되는 Policy나 Managed Policy를 수정해야 하는 경우는 Terraform에서 관리해 주기로 했습니다.

3) 최소 권한을 잘 지키는지 확인

ConsoleMe는 권한 신청 및 Role에 대한 권한을 쉽게 할 수 있도록 도와주지 이 요청이 실제로 안전한 요청인지를 구별할 수 있는 능력은 없습니다. 그렇기 때문에 담당자가 이게 실제로 필요한 권한인지 asterisk(*)가 들어가 있지 않은지 항상 잘 확인해 줘야 합니다.

운영 시 알면 좋은 점들

처음 ConsoleMe를 배포하고 운영하면서 좀 헷갈렸던 부분들이 일부 있었습니다. 알고 있으면 좋은 점들 두 가지만 추가적으로 정리했습니다.

1) Central Account와 Spoke Account

맨 처음 ConsoleMe를 소개했던 것처럼 AWS 다중 계정을 운영할 때 권한 관리를 도와주는 툴입니다. 그렇기 때문에 ConsoleMe 자체도 여러 계정상에서 운영될 걸 가정하고 설계돼 있습니다. 크게 두 가지 계정 타입이 있는데 웹 콘솔과 실제 서비스가 작동하고 데이터가 저장될 DB가 운영되는 Central Account, 실제 권한 관리가 필요한 계정인 Spoke Account로 나뉘게 됩니다.

즉 한 개의 Central Account에서 여러 개의 Spoke Account에 접근해 각 계정에 있는 AWS 리소스들과 IAM에 대해 권한 제어를 해주는 방식입니다. 권한 제어를 해주기 위해 Central Account에 있는 ConsoleMe instance에서 각 Spoke Account에 있는 Worker Role을 사용할 수 있도록 Assume Role을 허용해 주어야 정상적으로 작동할 수 있습니다. Central Account와 Spoke Account를 분리하기 어려운 환경에서는 Central Account만 운영해도 충분히 가능하지만 ConsoleMe Instance Role이 IAM을 수정할 수 있는 막강한 권한을 가지고 있음으로 허가받지 않은 유저가 해당 권한을 획득할 수 없도록 추가적인 설정이 필요합니다.

2) AWS 상의 Resource들의 캐싱 주기

ConsoleMe에서는 Task queue인 Celery를 사용해 AWS의 Resource들과 IAM을 주기적으로 크롤링해서 DynamoDB와 Redis에 저장해둡니다. 주기적인 캐싱 때문에 가끔 AWS Console 혹은 Terraform에서 IAM을 수정했을 때 ConsoleMe에 변경 사항이 바로바로 안 되는 경우가 있습니다. 대표적으로 IAM 관련 리소스들은 45분 간격으로 크롤링 해옵니다. 각 Job 별로 어느 주기로 실행되는지는 문서를 참고하면 나와있습니다. 만약 ConsoleMe 웹 콘솔에서 안 보일 경우 조금 기다리거나 직접 해당 job을 Celery에 트리거 시켜주면 바로 확인할 수 있습니다.

3) 추가적인 편리한 기능들

• Slack Integration
• CloudTrail 연동을 통한 최근 퍼미션 에러 났던 퍼미션 알림 기능
• CLI환경에서 권한 획득을 위한 Weep
• 임시 권한 자동 회수

정리

지금까지 AB180에서 어떻게 ConsoleMe를 써서 권한 신청 관리를 하고 있는지 설명드렸습니다. 좀 더 자세한 설명은 Docs와 제가 지난번에 발표했던 AWSKRUG ConsoleMe 발표 영상을 참고하시면 좀 더 자세히 나와 있습니다. 또한 데모 사이트에서 직접 권한 신청 프로세스를 테스트해 볼 수도 있으니 도입하기 전 원하는 툴이 맞는지 그리고 어떻게 사용하는 건지 먼저 체험해 보시는 걸 추천해 드립니다.

ConsoleMe를 쓰게 된 이후로 보안팀은 권한 신청 관련 증적과 로그 관리가 편해지고 개발팀은 최소 30분 최대 하루까지 걸리던 프로세스가 5분 정도밖에 안 걸리는 쉬운 권한 신청 프로세스로 바뀌어, 모두가 만족할 수 있었습니다. 만약 팀이 점점 커지는 개발팀이라면 적은 노력으로 더 안전한 환경을 마련할 수 있는 ConsoleMe 도입을 고려해 보는 건 어떨까요? 물론 가장 좋은 건 이미 ConsoleMe가 도입돼있는 저희 팀에 오시는 것입니다.

<원문>

ConsoleMe: 스타트업에서 AWS IAM 권한 관리 잘 하는법