개발자를 위한 AWS 클라우드 보안: ①클라우드 설계 원칙과 IAM

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

이번 글은 딥러닝 기술을 활용해 사람처럼 친근한 대화를 할 수 있는 관계 지향형 AI 챗봇을 개발하는 AI 스타트업 '스캐터랩'의 Engineering 팀의 이야기입니다. 스캐터랩이 효율적인 클라우드 인프라를 구축하기 위해 진행한 작업을 살펴보고, 어떤 방식으로 AWS 클라우드 보안 강화를 했는지 알아보겠습니다.

스캐터랩에서는 루다를 비롯한 회사의 서비스를 배포하고 운영하기 위해 AWS를 사용하고 있습니다. 컴퓨팅, 네트워크 장비를 직접 구매해서 모든 것을 세팅할 필요 없이, 클라우드에서 인프라 구축, 자동 스케일링, 네트워크, DNS 구성 등을 간편하게 할 수 있는 것은 클라우드의 매우 큰 장점입니다. 이와 같은 클라우드의 장점을 최대한 활용하기 위해서는 클라우드를 효율적으로 사용하는 방법을 알아야 할 것입니다.

그래서 핑퐁팀에서는 AWS Well-Architected Framework를 참고하여 효율적인 클라우드 인프라를 구축하기 위해 어떤 것들을 고려해야 하는지 조사했습니다. 그리고 스캐터랩의 여러 서비스를 안전한 환경에서 운영하기 위해 클라우드 보안 강화에 집중하기로 결정했고, 약 5개월에 걸쳐 클라우드 보안을 점검하고 강화했습니다.

이 시리즈에서는 핑퐁팀이 AWS 클라우드 보안 강화를 위해 어떤 작업을 했고, 그 결과가 어땠는지 총 3편의 글로 소개하고자 합니다. 먼저 AWS Well-Architected Framework에 대한 간략한 설명으로 시작하여 보안의 5가지 영역을 소개하고 각각을 핑퐁팀에 적용한 사례를 상세히 정리했습니다.

AWS Well-Architected Framework

AWS Well-Architected Framework는 AWS에서 제공하는 클라우드 설계 원칙입니다.

(2022년 기준) 총 6가지 원칙이 있어, 보안상 안전하며 탄력적이고 효율적인 인프라 구축을 위해 어떤 것들을 신경 쓰고 또 지켜야 하는지 설명합니다. 이 원칙은 구체적인 클라우드 아키텍처나 구현 방법을 설명하지는 않지만, 클라우드를 효율적으로 사용하기 위한 개괄적인 아이디어를 제시하는 점에서 굉장히 유용한 자료입니다.

다만 기업별로 클라우드 환경이 다르기 때문에 설계 원칙이 절대적인 기준은 아니며, AWS 측에서도 클라우드 사용 용도에 따라 원칙을 적절하게 적용하는 것을 권장합니다. 실제로 AWS는 Well-Architected Tool을 통해 고객의 클라우드 사용 용도에 알맞게 아키텍처를 검토하고 모범 사례를 제시해주며 개선 사항을 알려주는 서비스를 제공하고 있습니다.

6가지 설계 원칙

각 설계 원칙에 대해 간략하게 정리했습니다.

운영 효율성(Operational Excellence) 원칙은 클라우드 리소스를 효율적으로 준비하고, 운영하며, 발전하는 방법을 설명합니다. IaC를 이용한 점진적, 가역적인 변화, 지속적인 개선 및 효율적인 클라우드 운영을 추구합니다.

보안(Security) 원칙은 클라우드의 모든 리소스와 시스템, 정보를 보호하고 사고 대응 정책을 수립하는 방법을 설명합니다. 정보와 시스템의 보호를 통해 안전한 환경에서 서비스를 운영하는 것을 목표로 합니다.

안정성(Reliability) 원칙은 클라우드 리소스가 그 기능을 정확하고 일관되게 수행하도록 하는 방법을 설명합니다. 장애로부터 빠르게 복구하고, 가용성을 확보하고 스케일링을 통해 안정적인 서비스 운영을 추구합니다.

성능 효율성(Performance Efficiency) 원칙은 컴퓨팅 자원을 효율적으로 사용하여 시스템 요구사항을 만족하며 서비스를 운영하는 방법을 설명합니다. 관리형 서비스를 사용하고, 실험과 모니터링을 통해 클라우드의 자원을 효율적으로 사용할 것을 제안합니다.

비용 최적화(Cost Optimization) 원칙은 서비스 운영에 필요한 비용을 최적화하는 방법을 설명합니다. 클라우드 재무 관리 및 지출 분석을 통해 불필요한 비용이 발생하지 않도록 주의하는 것에 초점을 두고 있습니다.

지속 가능성(Sustainability) 원칙은 클라우드를 사용하면서 환경을 보호하고 지속 가능한 발전을 하기 위한 방법을 설명합니다. 비즈니스 요구사항을 만족하면서도 환경 문제에 대해 함께 고려해야 한다는 내용입니다.

위 6가지 원칙은 서로 독립적이지 않고 상호 보완적인 성격을 갖기 때문에, 핑퐁팀에서는 보안 원칙에 집중하여 클라우드 아키텍처의 전반적인 강화를 목표로 했습니다. 그 결과 실제로 핑퐁팀에서는 클라우드 보안을 강화하면서 운영 및 개발 효율성이 증대되었고, 서비스를 안정적으로 할 수 있게 되었으며, 불필요한 비용도 꽤 줄일 수 있었습니다.

보안 원칙

보안 원칙에는 5가지 하위 영역이 있어 핑퐁팀에서는 영역별로 집중하여 클라우드 인프라를 강화했습니다. 각 영역의 세부 내용은 뒤에서 정말 자세하게 설명할 예정이기 때문에 간략하게 언급만 하고 넘어가겠습니다.

보안의 5가지 영역 (5 Pillars of Security)

1. 권한 관리 및 접근 제어: 클라우드 서비스와 리소스에 대한 접근을 안전하게 관리할 수 있는 환경을 만드는 방법
2. 로깅 및 모니터링: 클라우드 서비스와 리소스의 로그를 수집하고 모니터링 환경을 구성하는 방법
3. 데이터 보호: 클라우드의 모든 데이터를 기술적인 조치를 통해 안전하게 보호하는 방법
4. 인프라 보안: 클라우드 인프라에서 발생하는 위협을 탐지하고 차단할 수 있는 기술적 보호조치를 적용하는 방법
5. 사고 대응: 클라우드 환경에서 보안 사고 발생 시 원인을 분석, 조사, 식별하고 대응하는 프로세스를 구성하는 방법

이번 글에서는 클라우드 보안에서 가장 중요한 권한 관리 및 접근 제어 영역에 대해 집중적으로 살펴보려고 합니다.

Identity & Access Management

권한 관리 및 접근 제어(IAM) 영역은 AWS 서비스와 리소스에 관한 접근을 안전하게 관리할 수 있는 환경 구축 방법을 설명합니다. IAM이 잘 구성되어야 나머지 4개의 영역을 수월하게 적용할 수 있으며, 반대로 접근 통제가 이뤄지지 않으면 보안에 취약한 것이나 다름없어 나머지 작업이 의미를 상실하게 됩니다. 이처럼 IAM은 클라우드 보안에서 근본이 되는 부분이기 때문에 매우 중요하며 작업이 가장 많이 필요한 부분입니다.

핑퐁팀에서 IAM 원칙을 실천하기 위해 적용한 6가지 사항에 대해 소개하겠습니다.

Multi-Account Strategy

먼저 AWS 계정 구조부터 점검해야 했습니다. 스캐터랩의 기존 AWS 환경은 하나의 AWS 계정(Account) 아래에서 관리되고 있었습니다. 하나의 계정 아래에 개발자마다 IAM 사용자(User)를 발급했고, 사용자마다 권한을 일일이 관리하고 있었습니다. 그러나 이와 같은 단일 계정 환경은 관리가 어렵고, 조직이 성장할 때 확장성이 매우 떨어집니다.

예를 들어 여러 팀이 있는 조직이 하나의 계정을 사용하게 되면, 각 팀에서 생성한 리소스(자주 사용되는 EC2, S3, RDS 등)가 하나의 계정에 모두 존재하게 됩니다. 이러면 팀 간 리소스 구분이 어려워지고, 보안상 팀 단위로 리소스 권한을 통제하기 매우 불편해집니다. 개발/프로덕션 환경별 리소스 격리도 어렵고, 무엇보다 개발자가 실수할 위험이 커지게 되며, 팀 내에서 클라우드 보안 사고가 발생했을 때 다른 팀의 리소스에도 영향을 줄 수 있게 됩니다.

이에 따라 다중 계정 환경을 구성하는 것이 매우 권장됩니다. 팀별로, 환경별로 계정을 분리하면 리소스가 자연스럽게 분리되기 때문에 권한 관리를 수월하게 할 수 있고, 다른 계정이기 때문에 권한 관리와 접근 통제가 자연스럽게 이뤄집니다. 또 사용하는 계정 내의 리소스를 모두 파악할 수 있게 되므로 미사용 리소스를 효율적으로 정리할 수 있을 뿐만 아니라 실수가 발생하거나 사고가 발생해도 영향 범위가 계정 내로 한정되는 장점이 있습니다.

그래서 스캐터랩에서는 운영 중인 서비스와 환경별로 계정을 적절히 분리하는 구조를 선택했습니다. 예를 들어, 개발용 계정(Dev)과 프로덕션용 계정(Production)이 분리되어 있습니다. 하지만 다중 계정을 사용하는 것이 장점만 있는 것은 아닙니다. 당장 개발자들 입장에서는 사용하는 계정이 늘어났기 때문에 계정 전환이 불편해지는 문제가 있습니다. (그렇지 않아도 AWS 콘솔 로그인은 불편합니다!)

그래서 스캐터랩 전체에 AWS Single Sign-On(SSO)을 도입하여 통합 로그인 환경을 제공하기로 했습니다. 개발자는 SSO 콘솔로의 로그인 한 번으로 여러 개의 계정에 쉽게 접속할 수 있게 되고 계정 전환이 훨씬 수월해집니다.

AWS SSO 로그인 방식

AWS SSO를 이용해 로그인하기 위해서는 다음 3가지를 설정해야 합니다.

1. 누가? (SSO User/Group)
2. 어떤 권한을 가지고? (Permission Set)
3. 어떤 계정에 로그인할 것인가? (Account)

이를 위해 우선 계정별로 이 계정에 어떤 사람들이 접근하게 될 것인지 정리했습니다. 예를 들어 루다 개발용 계정에는 루다 개발을 담당하는 모든 사람이 접근할 수 있어야 할 것입니다. 그런데 루다 개발자 중에는 프론트엔드 직군도 있고 백엔드 직군도 있습니다. 직군에 따라 필요한 권한이 다를 것이기 때문에 팀 내 직군별로 SSO Group을 생성하도록 했습니다. SSO User를 사용하지 않은 이유는 인원 변동이 생길 때마다 사용자의 권한을 각각 모두 변경하는 것보다 Group에 사용자를 추가/삭제하는 편이 훨씬 간단하고, 로그인 목적으로 IAM 사용자를 생성하지 않아도 되기 때문입니다. 인원 변동이 생길 때마다 각 계정에서 모두 권한 설정을 변경해야 한다고 생각하면 끔찍합니다!

그리고 권한 세트(Permission Set)를 팀 내 직군 단위 또는 서비스 단위로 생성했습니다. 권한 세트는 말 그대로 권한의 집합으로, SSO User/Group에게 집합에 포함된 권한을 부여하는 역할을 합니다. 권한 세트는 재사용성을 위해 별도로 관리됩니다. 계정이 여러 개인 경우 같은 Group, 같은 권한 세트를 여러 개의 계정에 할당할 수도 있기 때문입니다. 예를 들어 관리자 Group의 경우 Admin 권한이 포함된 권한 세트를 모든 계정에 할당해야 합니다.

이상으로 SSO 로그인을 위한 설계를 모두 마쳤고, 이를 실제로 적용하면 개발자들이 SSO 콘솔에 로그인했을 때 다음과 같은 화면이 보이게 됩니다.

개발자 본인에게 접속 권한이 부여된 계정의 목록이 보이며, 계정별로 어떤 권한 세트를 이용할 수 있는지 나옵니다. 사진 속 Route53PermissionSet의 경우 Route 53 서비스에 접근할 수 있는 권한만 포함되어 있으며, Management console을 클릭하면 이 권한 세트를 이용해 해당 계정에 접근하게 됩니다. 그러면 계정 내에서 Route 53 서비스만 이용할 수 있고, 나머지에 대해서는 접근이 거부됩니다.

하지만 이 모든 것을 수작업으로 하게 되면, 계정의 생성 및 관리와 SSO 세팅, 권한 부여, 분산된 요금 청구 등으로 인해 과정이 매우 번거롭게 되고, 다중 계정 환경의 단점이 드러나게 됩니다.

AWS Control Tower

위와 같은 단점은 AWS Control Tower 서비스를 이용해 효율적으로 해결할 수 있습니다. Control Tower(CT)는 다중 계정 환경을 빠르게 구성하고 안전하게 관리할 수 있도록 해주는 서비스입니다. CT는 Account Factory를 이용해 새로운 계정을 쉽게 만들 수 있도록 해주고, SSO와 같이 다중 계정을 통합적으로 관리할 수 있는 account federation 기능을 지원합니다. 더 나아가 Control Tower라는 이름에 걸맞게 중앙 관리를 위한 기능들을 제공합니다.

AWS Organizations

Control Tower에서는 AWS Organizations 서비스를 적극적으로 활용하여 중앙에서 계정을 트리 형태로 관리할 수 있도록 해줍니다. 기업 내에 부서가 있고 부서만의 규칙이 있는 것처럼, AWS Organizations 서비스는 Organization Unit(OU)라는 단위를 제공하여 계정을 OU 단위로 묶고, OU 단위로 공통적인 권한을 부여할 수 있도록 해줍니다. 또 Control Tower를 생성한 계정(이하 Management 계정)은 최상단 OU인 Root OU에 속하게 되어 모든 하위 OU에 속한 계정들의 비용을 통합하여 청구받게 됩니다.

Guardrails

Control Tower는 가드레일(guardrail)을 제공하여 중앙에서 정책적으로 권한을 통제하고 계정을 감사하는 장치를 제공합니다. 계정 수준에서 통제하거나 감사해야 하는 부분이 있다면 가드레일을 활용해서 OU 단위에서 권한을 통제하게 됩니다. 가드레일에는 2가지 종류가 있는데, 예방적(preventive) 가드레일과 탐지형(detective) 가드레일이 있습니다.

예방적 가드레일은 어떤 동작을 거부하여 사고를 예방하는 데 사용합니다. 예를 들어, 클라우드 감사 로그인 CloudTrail을 비활성화하는 동작은 보안상 중앙에서 전체적으로 금지하는 것이 좋을 것입니다. 이렇게 여러 계정에 공통으로 적용하고자 하는 규칙을 동시에 적용할 수 있게 됩니다. 단, 내부적으로 AWS Organizations의 Service Control Policy를 이용하기 때문에 IAM Policy Evaluation 로직 상 우선순위가 상당히 높아 주의해서 설정해야 합니다. 각 계정에서 명시적으로 동작을 허용하더라도 SCP에서 거부하면 최종적으로 거부되며, 예방적 가드레일을 지나치게 적용하면 각 계정의 권한을 부여하다가 가드레일을 수정하게 되는 불편함이 발생할 수 있습니다.

탐지형 가드레일은 예방적 가드레일과 달리 동작을 허용하지만 이를 탐지하여 Control Tower에 알려주는 역할을 합니다. 주로 보안 위험을 탐지하기 위해 사용합니다. 예를 들어 중요한 자료가 담긴 S3 버킷이 외부에 공개적으로 노출되어 있다면 이를 탐지하여 알려줍니다.

Control Tower를 사용하면 보안 및 권한 관리 강화를 위해 기본 가드레일이 제공되고, 이 밖에도 조직의 요구사항에 따라 추가적인 가드레일을 생성해서 적용할 수 있습니다. 공식 문서에도 AWS가 추천하는 가드레일이 나와 있어 대부분의 내용을 적용했습니다.

로그 보관 계정 및 감사 계정

Control Tower를 사용하면 Security OU에 로그 보관용 계정(Log Archive Account)과 감사용 계정(Audit Account)을 추가로 생성해줍니다. 말 그대로 보안팀에서 사용하는 계정으로, 로그 보관용 계정의 경우 Control Tower에 속한 모든 계정에서 발생하는 보안 로그가 모이는 곳입니다. 감사용 계정은 로그 보관용 계정의 로그를 분석하거나 계정의 규정 준수를 감사할 때 사용하는 계정입니다. 이 두 계정은 다음 글의 로깅 및 모니터링 원칙에서 적극적으로 활용하게 됩니다.

가장 어려운 부분인 OU/계정 구조 설계와 Control Tower 배포를 통한 SSO 적용이 완료되었습니다. 실제로 설계 논의를 위해 가장 많은 시간을 투자했던 것 같습니다. 다음은 스캐터랩의 다중 계정 환경 구조입니다.

서비스 혹은 팀 단위로 먼저 OU를 나눈 뒤 OU 안에서 제품에 따라, 필요한 경우 환경에 따라 계정을 분리했습니다. 계정의 개수가 많아 보이지만 Control Tower가 있기 때문에 통합된 중앙 환경에서 손쉽게 관리할 수 있습니다.

Credential Management

SSO를 사용하면서 로그인 목적으로 IAM User를 생성할 이유는 사라졌지만, CI/CD Tool에서는 여전히 Access Key가 필요합니다. 또 EC2의 키페어 등과 같이 로그인 정보(credential)를 사용하게 되는 경우가 많습니다. 그래서 자격 증명을 안전하게 구성하고 관리하는 프로세스가 확립되어야 합니다.

로그인 정보의 경우 정책적으로 비밀번호 복잡성을 강제하거나 SSO 로그인 시 MFA를 강제하고, 90일마다 주기적으로 비밀번호를 변경하도록 설정하여 효율적으로 관리할 수 있습니다.

그 밖의 Access Key 발급이나 임시 권한 요청의 경우 요청하고 발급하는 프로세스를 도입하고 그 이력을 관리하는 것이 좋습니다. 누가, 언제, 어떤 권한을 요청해서 발급했는지 기록해야 하고, 권한의 사용이 완료되면 말소까지 확실하게 해야 합니다. Access Key는 공유되거나 CI/CD Tool에서 한 번 설정하고 오래 쓸 수도 있기 때문에 유출 방지 및 안전한 관리를 위해 발급을 최소화해야 하며, 가능하다면 주기적으로 키를 교체(rotate)해 주거나, 장기 미사용 키를 발견하면 삭제해야 합니다.

핑퐁팀에서는 되도록 Access Key 발급을 지양하고 있어, GitHub Actions 이외의 목적으로 요청하는 경우 담당자가 면밀하게 검토하여 다른 방법이 없는지 확인합니다. 예를 들어 애플리케이션에서 S3 접근 권한이 필요한 경우에도 키를 발급해주지 않고 S3 Read Only 권한이 있는 역할(role)을 생성해서 해당 역할을 사용하도록 안내합니다. 이와 같은 방법으로 계정의 개수는 많으나 Access Key를 효율적으로 관리하고 있습니다.

Principle of Least Privilege

최소 권한 부여 원칙은 IAM에서 가장 중요한 원칙으로, 그 어떠한 사용자도 필요한 것 이상으로 권한을 가지고 있어서는 안 된다는 원칙입니다. 하지만 동시에 실현이 어려워 가장 지키기 어려운 원칙이기도 합니다. 예를 들어 Full Access를 남용하다가 갑자기 권한을 최소화하려고 하면 업무에 분명 차질이 생길 것입니다. 그래서 최소 권한 원칙은 점진적인 도입이 중요합니다.

AWS IAM의 Action은 크게 4단계로 나눌 수 있습니다.

1. Full Access (*:*)
2. 서비스에 대한 Full Access (s3:*)
3. 서비스에 대한 읽기/쓰기 전용 (s3:Get*, s3:Put*)
4. 구체적인 Action (s3:GetObject)

최소 권한 원칙을 만족시키기 위해서는 4단계의 Action으로만 구성해야 합니다. 하지만 개발자들에게 필요한 권한을 4단계 수준으로 모두 파악하는 것은 현실적으로 어려울 뿐만 아니라 추가 권한 요청이나 권한 말소 작업이 빈번하게 발생할 것입니다. 이 경우 권한 관리 복잡도가 상승하기 때문에 전담 조직이 없다면 권한 관리 작업이 번거로워질 수 있습니다.

그래서 핑퐁팀에서는 우선 팀/직무 단위로 어떤 서비스를 사용하고 있는지 조사한 뒤, 2~4단계 Action으로 권한 세트를 구성했습니다. 루다 백엔드 개발자에게 부여된 권한을 예시로 들자면, 우선 서버 관리를 위해 EC2에 대한 Full Access(2단계)가 필요할 것입니다. 그리고 ALB를 생성할 때 인증서 목록을 조회하기 위해 ACM Read Only(3단계) 권한을, 디버깅 및 역할 할당 용도로 IAM Read Only(3단계) 권한을 부여했습니다. (인증서 생성과 역할 생성은 관리자만 할 수 있습니다) 마지막으로 eksctl을 사용하기 위한 권한에는 4단계 Action이 여러 개 포함되어 있습니다.

또한 최소 권한 원칙을 지키기 위해서는 주기적으로 권한을 검사하여 미사용 권한을 삭제해주는 작업도 필요합니다. 미사용 권한은 AWS Access Advisor를 사용하여 어떤 권한을 언제 마지막으로 사용했는지 쉽게 확인할 수 있습니다. 장기 미사용된 (90일 이상) 권한이 있다면 관련된 인원에게 권한 삭제에 대한 확인을 받고 지우면 됩니다.

Resource-based Policy

AWS IAM Policy는 크게 자격 증명 기반 정책(identity-based policy)과 리소스 기반 정책(resource-based policy)으로 나뉩니다. (공식 문서) 이 둘의 차이점은 다음과 같습니다.

• 자격 증명 기반: 이 User/Role은 Action A를 할 수 있다/없다. (User/Role 관점)
• 리소스 기반: 이 리소스에 P라는 User/Role은 Action A를 할 수 있다/없다. (리소스 관점)

자격 증명 기반 정책은 당연히 권한 세트로 관리하고 있지만, 리소스 기반 정책까지 추가로 관리해야 하는 이유는 같은 계정 내에서는 리소스 기반 정책에서만 허용해도 (정확히는 자격 증명 기반 정책에 거부가 없고) 최종적으로 Action을 허용하기 때문입니다. 그래서 어떤 리소스에 어떤 리소스 기반 정책이 포함되어 있는지 추가로 관리해야 합니다.

추가로 다중 계정 환경을 구성하게 되면 S3, ECR 등의 리소스를 여러 계정에서 공유해야 하는 상황이 발생하게 됩니다. 이런 경우 요청하는 계정(A)과 리소스가 존재하는 계정(B)이 다르기 때문에, 자격 증명 기반 정책과 리소스 기반 정책을 모두 설정해야 합니다.

• A에서 자격 증명 기반 정책을 사용해 B의 리소스에 대한 접근을 허용
• B의 리소스에서 리소스 기반 정책 접근을 사용해 A의 접근을 허용

예를 들어 컨테이너를 사용하는 서비스의 경우 Dev와 Prod 계정에서 같은 ECR repository를 사용하게 되므로, ECR repository에서는 리소스 기반 정책을 사용해 두 계정의 이미지 pull 요청을 허용해야 하고, 두 계정에서는 각각 자격 증명 기반 정책을 사용해 이미지 pull 권한을 부여해야 합니다.

이 밖에도 S3, KMS Key 등에서 리소스 기반 정책을 활용하여 추가적인 권한 관리를 하고 있기 때문에, 핑퐁팀은 서비스와 관련된 S3 버킷과 ECR Repository의 목록과 각각의 접근 권한을 정리하여 관리하고 있습니다. 마찬가지로 최소 권한 원칙이 적용되기 때문에 권한이 필요하면 추가하고, 미사용 시 삭제도 하고 있습니다.

Documentation

마지막으로 이 모든 과정이 추후 가이드나 레퍼런스로 사용될 수 있도록 잘 문서화되어 있어야 하고, 문서의 이력이 관리되고 있어야 합니다. 크게 다음과 같은 내용들이 문서화 되어있어야 합니다.

• 운영 방법의 문서화: Control Tower를 세팅하는 방법, 계정을 새롭게 추가하는 방법, 권한 세트의 생성 및 할당 방법, EKS 노드/Pod에서 Role 사용하는 방법, 디버깅 방법 등
• 권한의 정리: 부여된 권한 세트의 정리, 리소스 기반 정책 정리, Access Key/키페어의 이력 관리
• 정책의 정리: 계정 구조와 OU의 구조 정리, Control Tower에서 적용된 가드레일의 정리, 로그인 및 암호 정책 등

핑퐁팀에서는 이와 같은 내용들을 모두 노션에 문서화했고, 수정할 때마다 이력을 남기고 개발자들이 가이드로 언제든지 찾아볼 수 있도록 한곳에 모아 관리하고 있습니다.

IAM은 완벽하게 실천하기 어렵고 끝이 없지만, 보안 원칙의 기본이 되는 만큼 중요한 원칙이기 때문에 조금만 적용해도 보안성이 크게 향상되는 가성비가 좋은 원칙입니다. 하지만 계정 구조와 같이 한 번 설계를 마치고 나중에 변경하려고 하면 대공사가 될 수도 있으므로 신중하게 접근하고 결정해야 합니다. (대공사가 되는 이유는 계정 때문이 아니라 계정에 존재하는 워크로드 때문입니다) 그리고 IAM 원칙을 과하게 적용하는 경우 개발자들의 효율성을 해칠 수도 있으며, 역으로 보안 담당자 입장에서 수많은 권한 요청으로 인해 관리 복잡도가 상승할 수도 있습니다.

조직의 상황에 맞게 개발 효율성과 보안의 균형을 맞춰나가며 클라우드를 운영하는 과정은 정말 어려운 것 같습니다. 실제로 핑퐁팀에서도 IAM에 가장 오랜 기간을 쏟았고, 그 결과 개발자와 보안 담당자 양쪽을 다 만족시킬 수 있는 적절한 운영 체계를 갖출 수 있었습니다.

다음 두 편의 글에서는 나머지 4개의 영역에 대해 상세히 정리할 예정입니다. 다음 편에도 클라우드 보안 강화를 위해 손쉽게 적용할 수 있는 내용을 많이 소개할 예정이니 기대해 주세요!

<원문>

개발자를 위한 AWS 클라우드 보안 (1) - 클라우드 설계 원칙과 IAM

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.