“그냥 거부하세요”: IAM Deny 및 조직 정책으로 심층 방어 구축

오늘날의 클라우드 환경에서 클라우드 환경을 보호하려면 허용 정책과 최소 권한 원칙 이상으로 IAM(Identity and Access Management) 접근 방식을 강화해야 합니다. 방어를 강화하기 위해, Google은 강력한 도구인 IAM Deny 정책(IAM Deny Policies)을 제공합니다.

IAM Allow 정책에만 의존하면 잠재적인 과도한 권한 부여가 발생할 수 있으며, 보안팀이 대규모로 권한 수준 제한을 일관되게 적용하기 어려울 수 있습니다. 이때 IAM 거부가 필요합니다.

IAM Deny는 부여된 역할과 관계없이 주체(principal)가 수행할 수 없는 작업을 명시적으로 정의할 수 있는 중요하고 확장 가능한 보안 계층을 제공합니다. 이 사전 예방적 접근 방식을 통해 무단 액세스를 방지하고 전반적인 보안 태세를 강화하여 관리팀에 환경 전반에 걸쳐 우선적인 보호 정책을 제공할 수 있습니다.

IAM Deny 이해

IAM 거부의 기본은 IAM Allow 정책을 기반으로 구축됩니다. 허용 정책은 Google Cloud 조직에서 누가 무엇을 어디서 할 수 있는지를 정의하며, 주체(사용자, 그룹, 서비스 계정)를 다양한 수준(조직, 폴더, 프로젝트, 리소스)에서 리소스에 대한 액세스 권한을 부여하는 역할에 연결합니다.

반대로, IAM Deny는 제한을 정의합니다. 또한 주체를 대상으로 하지만, 연결은 리소스 수준이 아닌 조직, 폴더 또는 프로젝트 수준에서 발생합니다.

허용 및 거부 정책의 주요 차이점

• IAM Allow: 역할 연결을 통해 주체에 권한을 부여하는 데 중점을 둡니다.

• IAM Deny: 계층적 수준에서 IAM 허용에 의해 부여된 역할 연결을 무시하여 권한을 제한하는 데 중점을 둡니다.

IAM Deny 작동 방식

IAM Deny 정책은 몇 가지 핵심 구성 요소를 사용하여 제한을 설정합니다.

• 거부된 주체(누가): 제한하려는 사용자, 그룹 또는 서비스 계정입니다. 조직의 "모든 사람" 또는 조직에 관계없이 모든 주체(allUsers 식별자로 표시)가 될 수도 있습니다

• 거부된 권한(무엇을): 거부된 주체가 사용할 수 없는 특정 작업 또는 권한입니다. 대부분의 Google Cloud 서비스는 IAM Deny를 지원하지만, 새로운 서비스에 대한 지원 여부를 확인하는 것이 중요합니다.

• 연결 지점(어디에): 거부 정책이 적용되는 조직, 폴더 또는 프로젝트입니다. 거부 정책은 개별 리소스에 직접 연결할 수 없습니다.

• 조건(어떻게): 선택 사항이지만, 거부 정책이 적용되는 시점에 대한 더 세부적인 제어를 가능하게 합니다. 조건은 CEL(Common Expression Language) 표현식을 사용하는 리소스 태그로 설정되어 특정 환경에서만 또는 특정 태그가 존재하지 않는 경우에만 거부 정책을 조건부로 적용할 수 있습니다.

IAM Deny 시작하기

IAM Deny의 중요한 측면은 평가 순서입니다. 거부 정책은 모든 허용 정책보다 먼저 평가됩니다. 거부 정책이 주체의 작업에 적용되는 경우, 주체가 어떤 역할을 가지고 있든 관계없이 해당 요청은 명시적으로 거부됩니다. 거부 정책이 적용되지 않는 경우에만 시스템은 허용 정책을 평가하여 작업이 허용되는지 여부를 결정합니다.

IAM Deny 사용 사례

IAM Deny 정책은 다음과 같은 일반적인 보안 보호 장치를 구현하는 데 사용될 수 있습니다.

• 높은 권한 제한: 개발 환경에서 개발자가 IAM 역할을 생성 또는 관리하거나, 조직 정책을 수정하거나, 민감한 결제 정보에 액세스하는 것을 방지합니다.

• 조직 표준 적용: 특정 역할을 사용할 수 없도록 권한을 제한함으로써, 과도하게 허용적인 기본 역할(Basic Roles)의 오용을 방지하거나 특정 폴더에서 Google Cloud 서비스 활성화를 제한할 수 있습니다.

• 보안 프로필 구현: 청구, 네트워킹, 보안 팀을 비롯한 다양한 팀에 대해 거부된 권한 집합을 정의하여 직무 분리를 적용합니다.

• 태그가 지정된 리소스 보호: 특정 태그(예: iam_deny=enabled)가 있는 리소스에 조직 수준의 거부 정책을 적용합니다.

• 폴더 수준 제한 생성: 태그가 적용되지 않은 특정 폴더 내 리소스에 대해 청구, 네트워킹, 보안을 포함한 광범위한 권한 범주를 거부합니다.

보완적인 보안 계층

IAM Deny는 다른 보안 제어 기능과 함께 사용할 때 가장 효과적입니다. Google Cloud는 IAM Deny를 보완하는 몇 가지 도구를 제공합니다.

• 조직 정책: 리소스 사용 제한 정책(Resource Usage Restriction)을 통해 조직에서 사용 가능한 API를 제한하는 등 Google Cloud 계층 구조 전반에 걸쳐 조직 제약 조건을 중앙에서 구성하고 관리할 수 있습니다. 어떤 역할을 부여할 수 있는지 제한하기 위해 IAM 커스텀 제약조건(IAM Custom Constraints)을 정의할 수도 있습니다.

• Policy troubleshooter: 주체가 리소스에 대한 액세스 권한을 가지거나 거부된 이유를 이해하는 데 도움이 될 수 있습니다. 허용 및 거부 정책을 모두 분석하여 액세스 결과의 정확한 원인을 찾아낼 수 있습니다.

• Policy Simulator: 거부 정책을 실제 환경에 적용하기 전에 변경사항의 영향을 시뮬레이션할 수 있습니다. 잠재적인 서비스 중단을 식별하고 정책을 개선하는 데 도움이 될 수 있습니다. Deny Simulator는 현재 미리보기로 제공됩니다.

• IAM Recommender: 머신러닝을 사용하여 IAM 권한을 적용한 방법을 분석하고 과도하게 허용적인 역할 할당을 줄이기 위한 권장사항을 제공합니다. 이를 통해 진정한 최소 권한 원칙으로 나아갈 수 있습니다.

• 권한 있는 액세스 관리(Privileged Access Management, PAM): 거부 정책의 예외가 필요할 수 있는 주체에 대한 임시적, Just-in-time 권한 상승 액세스를 관리할 수 있습니다. PAM 솔루션은 비상용 계정 및 기타 권한 있는 액세스 시나리오에 대한 감사 및 제어 기능을 제공합니다.

• 주체 액세스 경계(Principal Access Boundaries): 조직의 주체가 액세스할 수 있는 리소스를 정의할 수 있습니다. 예를 들어, 이를 사용하여 주체가 다른 조직의 리소스에 액세스하는 것을 방지함으로써 피싱 공격이나 데이터 유출을 막을 수 있습니다.Implementing IAM Deny with Terraform

The provided GitHub repository offers a Terraform configuration to help you get started with implementing IAM Deny and Organization Policies. This configuration includes:

제공된 GitHub 저장소는 IAM Deny 및 조직 정책 구현을 시작하는 데 도움이 되는 Terraform 구성을 제공합니다. 이 구성에는 다음이 포함됩니다.

• 태그가 지정된 리소스에 대한 특정 관리 권한을 대상으로 하는 조직 수준 IAM Deny 정책

• 태그가 없는 리소스에 대한 결제, 네트워킹 및 보안 권한을 제한하는 폴더 수준 IAM Deny 정책

• roles/owner 역할 사용을 방지하는 커스텀 조직 정책 제약조건

• 지정된 폴더 내에서 특정 Google Cloud 서비스 사용을 제한하는 조직 정책

Terraform 구성을 사용하는 주요 단계:

1. 저장소 복제:

2. examples/iam-deny 폴더로 이동한 후 Terraform 디렉토리로 전환:

3. terraform.tfvars 준비: terraform.tfvars.example을 terraform.tfvars로 복사하고, Organization ID, Target Folder ID, 예외를 적용할 주체 그룹 이메일을 포함하도록 수정합니다.

4. 이 정책들을 활성화하기 위해 조직에 태그 키와 태그 값을 생성합니다.

1. 1. 이름은 원하는 대로 지정할 수 있지만, 예시에서는 태그 키를 iamdeny, 태그 값을 enabled로 사용할 수 있습니다.

5. main.tf의 태그 ID 업데이트: 각 정책의 denial_condition 섹션에 있는 자리표시자 태그 키와 값 ID를 실제 태그 ID로 교체합니다.

a. 참고: 선택 사항으로, 정책이 적용될 때 모든 리소스를 거부하도록 이 표현식을 사용할 수도 있습니다.

billing.json, networking.json, securitycenter.json 파일(terraform/profiles/ 디렉토리에 위치) 및 denied_perms.tf 파일에 있는 미리 정의된 거부된 권한들을 검토하여 조직의 보안 요구 사항에 맞게 조정해야 합니다.

6. Terraform 초기화, 검토 및 적용:

이 정책들을 배포하기 전에 항상 보안팀과 상의하세요.

‘거부'의 힘을 활용하세요

IAM은 보안을 강화하는 데 중요한 요소이며, 전략적 구현은 포괄적인 심층 방어 전략의 핵심입니다. (IAM을 시작하는 방법에 대한 자세한 내용은 'IAM이 싫지만 절실하게 필요합니다(I hate IAM but I need it desperately)' 및 'IAM 산을 확장하기(Scaling the IAM mountain, an in-depth guide)' 가이드를 참고하세요.)

IAM 거부 정책을 구현하는 것은 Google Cloud 보안 태세를 강화하는 데 중요한 단계입니다. 주체가 할 수 없는 작업을 명시적으로 정의함으로써, 의도치 않은 잘못된 구성과 악의적인 행위자 모두에 대한 강력한 방어 계층을 추가할 수 있습니다.

조직 정책, 정책 문제 해결 도구, 정책 시뮬레이터 및 IAM 추천기와 결합된 IAM 거부는 최소 권한 원칙을 더욱 효과적으로 적용하고 더 안전한 클라우드 환경을 구축할 수 있도록 지원합니다. 제공된 Terraform 예시를 살펴보며 Google Cloud 보안 전략에서 '거부'의 힘을 발견해 보세요.

이 콘텐츠는 Google Cloud 컨설팅이 엔터프라이즈 Google Cloud 고객과의 업무를 통해 얻은 경험을 바탕으로 작성되었습니다. Google의 최고의 전문가 및 혁신가들과 함께 Google Cloud 여정을 가속화하고 싶으시다면, Google Cloud Consulting에 문의하여 시작하세요.