액세스 제어에 리소스 계층구조 사용

Cloud Platform 리소스는 계층구조로 되어 있습니다. 조직 노드는 계층구조의 루트 노드이고 프로젝트는 조직의 하위 항목이며 기타 리소스는 프로젝트의 하위 항목입니다. 사용자는 서로 다른 수준의 리소스 계층구조에서 IAM 정책을 설정할 수 있습니다. 리소스는 상위 리소스의 정책을 상속합니다. 리소스의 유효 정책은 해당 리소스에 설정된 정책과 상위 리소스에서 상속된 정책의 합집합입니다.

이 페이지에서는 IAM 정책 상속의 작동 방식에 대한 몇 가지 예를 설명하며 IAM 배포 중에 리소스를 만들 때 고려해야 하는 권장사항을 설명합니다.

기본 요건

배경

다음 다이어그램은 Cloud Platform 리소스 계층구조의 예시입니다.

리소스 계층구조

IAM을 통해 다음 리소스 계층구조 수준에서 정책을 설정할 수 있습니다.

  • 조직 수준: 조직 리소스는 회사를 나타냅니다. 이 수준에서 부여된 IAM 역할은 조직의 모든 리소스에 상속됩니다.

  • 프로젝트 수준: 프로젝트는 회사 내에서 신뢰 경계를 나타냅니다. 같은 프로젝트에 있는 서비스는 기본 신뢰 수준을 갖습니다. 예를 들어 App Engine 인스턴스는 같은 프로젝트의 Cloud Storage 버킷에 액세스할 수 있습니다. 프로젝트 수준에서 부여된 IAM 역할은 해당 프로젝트의 리소스에 상속됩니다.

  • 리소스 수준: 기존의 Cloud Storage 및 BigQuery ACL 시스템 외에도 Genomics 데이터세트 및 Pub/Sub 주제와 같은 추가 리소스는 리소스 수준의 역할을 지원하므로 특정 사용자에게 단일 리소스에 대한 권한을 부여할 수 있습니다.

IAM 정책은 계층구조이며 위에서 아래로 전파됩니다. 리소스의 유효 정책은 해당 리소스에 설정된 정책과 상위 리소스에서 상속된 정책의 합집합입니다.

다음 예에서는 정책 상속이 실제로 어떻게 작동하는지 설명합니다.

예: Cloud Pub/Sub

Cloud Pub/Sub에서 주제 및 구독은 프로젝트의 하위에 있는 리소스입니다. 예를 들어 project_a에 topic_a라는 주제가 있다고 가정해보겠습니다. 만약 bob@gmail.com에 편집자 역할을 부여하는 정책을 project_a에 설정하고 alice@gmail.com에 게시자 역할을 부여하는 정책을 topic_a에 설정하면 topic_a에서 bob@gmail.com에게 편집자 역할과 alice@gmail.com에게 게시자 권한을 효과적으로 부여할 수 있습니다.

다음 다이어그램은 위의 예를 보여줍니다.

Pub/Sub 예시

소유자와 편집자와 뷰어 역할은 동심원 형태로 겹칩니다. 즉, 소유자 역할에는 편집자 역할의 권한이 포함되며 편집자 역할에는 뷰어 역할의 권한이 포함됩니다. 동일한 사람에게 더 광범위한 역할과 제한된 역할(예: 편집자 및 뷰어)을 모두 부여하면 더 광범위한 역할만 부여됩니다. 예를 들어 bob@gmail.com에게 프로젝트 수준에서 편집자 역할을 부여하고 topic_a에서 뷰어 역할을 부여하면 Bob에게는 topic_a의 편집자 역할이 부여됩니다. 이는 이미 Bob에게 project_a에서 설정한 정책에서 상속된 topic_a의 편집자 역할을 부여했기 때문입니다.

다음 다이어그램은 위의 예를 보여줍니다.

Pub/Sub 예시

예: Cloud Storage

Cloud Storage에서 버킷 및 객체는 리소스이며 버킷은 객체를 담는 컨테이너입니다. Cloud Storage에서 Cloud IAM을 사용하는 예는 업로드된 파일에 대한 읽기 액세스를 허용하는 것입니다.

여러 사용자가 파일을 버킷에 업로드하며 다른 사용자가 업로드한 파일을 읽거나 삭제할 수는 없다고 가정해보겠습니다. 데이터 처리 전문가는 업로드된 파일을 읽고 삭제할 수 있어야 하지만 다른 사용자가 버킷 위치를 통해 파일을 업로드하므로 버킷을 삭제해서는 안 됩니다. 이 경우 프로젝트에 다음과 같은 정책을 설정합니다.

  • Storage 객체 관리자를 데이터 처리 전문가인 Alice(alice@example.com)에게 부여합니다.
    • Alice는 프로젝트 수준에서 객체 관리자 권한을 가지며 프로젝트의 모든 버킷에 있는 어떠한 객체든지 읽고 추가하고 삭제할 수 있습니다.
  • Storage 객체 생성자를 사용자 그룹인 data_uploaders@example.com에 부여합니다.
    • 이 정책을 통해 data_uploaders@example.com의 모든 구성원은 파일을 버킷에 업로드할 수 있습니다.
    • 그룹 구성원은 본인이 업로드한 파일을 소유하지만 다른 사용자가 업로드하는 파일을 읽거나 삭제할 수는 없습니다.

다음 다이어그램은 위의 예를 보여줍니다.

Cloud Storage 예시

예: Compute Engine

일반적으로 대기업에서는 개발팀이 아닌 전담팀이 방화벽과 같은 네트워크 및 보안 리소스를 관리합니다. 개발팀은 인스턴스를 실행하고 프로젝트의 인스턴스와 관련된 다른 작업을 수행할 수 있는 유연성을 필요로 할 수 있습니다. 조직 수준에서 bob@example.com에게 Compute 네트워크 관리자 역할을 부여하고 project_2 프로젝트에서 alice@example.com에게 Compute 인스턴스 관리자 역할을 부여하면 Alice는 프로젝트와 관련된 네트워크 리소스를 변경하지 않고 모든 인스턴스 작업을 수행할 수 있습니다. 오직 Bob만이 조직의 네트워크 리소스와 해당 조직의 모든 프로젝트를 변경할 수 있습니다.

Cloud Storage 예시

권장사항

  • IAM 정책 계층구조를 조직 구조에 반영합니다. IAM 정책 계층구조는 회사가 스타트업이든 SME든 대기업이든 상관없이 회사의 조직 구성 방식을 반영해야 합니다. 스타트업은 조직 리소스가 없는 수평적인 정책 계층구조로 시작할 수 있습니다. 점차 프로젝트에서 공동 작업하는 사람들과 프로젝트 수가 증가하게 되면 조직 리소스를 갖추는 것이 합리적일 수 있습니다. 여러 부서와 팀이 있고 각 팀이 자체 애플리케이션 및 서비스 모음을 담당하는 대기업의 경우 조직 리소스를 갖추는 것이 좋습니다.

  • Cloud Platform 프로젝트를 사용하여 동일한 신뢰 경계를 공유하는 리소스를 그룹화합니다. 예를 들어 같은 제품 또는 마이크로서비스의 리소스는 동일한 Cloud Platform 프로젝트에 속할 수 있습니다.

  • 정책을 리소스 수준이 아닌 조직 수준 및 프로젝트 수준에서 설정합니다. 이는 새로운 리소스가 추가될 경우 상위 리소스의 정책이 자동으로 상속되도록 하기 위해서입니다. 예를 들어 자동 확장을 통해 새로운 가상 머신이 프로젝트에 추가되면 자동으로 프로젝트의 정책을 상속합니다.

  • 최소 권한의 보안 원칙을 사용하여 IAM 역할을 부여합니다. 이를 통해 리소스에 필요한 최소한의 액세스 권한만 부여할 수 있습니다.

  • 가능하면 개별 사용자가 아닌 Google 그룹에 역할을 부여합니다. 이렇게 하면 Cloud IAM 정책을 업데이트할 필요 없이 Google 그룹에서 구성원을 더욱 간편히 추가하고 삭제할 수 있습니다.

  • IAM 정책에 사용되는 Google 그룹의 소유권을 제어합니다.

  • 필요한 최소 범위의 역할만 부여합니다. 예를 들어 Pub/Sub 주제에 메시지를 게시하기 위한 액세스 권한만 필요한 사용자에게 해당 주제의 게시자 역할을 부여합니다.

  • 하위 리소스에 설정된 정책은 상위 리소스에 부여된 액세스를 제한할 수 없습니다. 모든 리소스에 부여된 정책을 확인하여 계층적 상속에 대해 이해하세요.

  • 여러 프로젝트에 걸쳐 있는 사용자 또는 그룹에 역할을 부여해야 하는 경우 프로젝트 수준이 아닌 조직 수준에서 역할을 설정하세요.

  • 라벨을 사용하여 리소스에 주석을 달고 그룹화하고 필터링합니다.

  • 정책이 규정을 준수하는지 감사합니다. Cloud 감사 로그에는 setiampolicy에 대한 모든 호출이 포함되므로 정책이 적용된 시점을 추적할 수 있습니다

  • 정책에 사용된 Google 그룹의 소유권 및 멤버십을 감사합니다.

  • 조직에서 프로젝트 생성을 제한하려면 조직 액세스 정책을 변경하여 프로젝트 생성자 역할을 관리 중인 그룹에 부여합니다.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

Cloud ID 및 액세스 관리 문서