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

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

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

기본 요건

• IAM의 기본 개념, 특히 Google Cloud 리소스 계층 구조를 이해합니다.

배경

다음 다이어그램은 Google Cloud 리소스 계층 구조의 예시를 보여줍니다.

IAM을 사용하면 리소스 계층 구조의 다음 수준에서 허용 정책을 설정할 수 있습니다.

• 조직 수준: 조직 리소스는 회사를 나타냅니다. 이 수준에서 부여된 IAM 역할은 조직의 모든 리소스에 상속됩니다. 자세한 내용은 IAM을 사용하여 조직 액세스 제어를 참조하세요.

• 폴더 수준: 폴더에는 프로젝트, 다른 폴더 또는 이 두 가지의 조합이 포함될 수 있습니다. 최상위 폴더 수준에서 부여된 역할은 상위 폴더에 포함된 프로젝트 또는 다른 폴더에 상속됩니다. 자세한 내용은 IAM을 사용하여 폴더의 액세스 제어를 참조하세요.

• 프로젝트 수준: 프로젝트는 회사 내에서 신뢰 경계를 나타냅니다. 같은 프로젝트에 있는 서비스는 기본 신뢰 수준을 갖습니다. 프로젝트 수준에서 부여된 IAM 역할은 프로젝트 내 리소스에 상속됩니다. 자세한 내용은 IAM을 사용하는 프로젝트의 액세스 제어를 참조하세요.

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

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

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

예시: Pub/Sub

Pub/Sub에서 주제 및 구독은 프로젝트의 하위에 있는 리소스입니다. project_1에 topic_a라는 주제가 있다고 가정해 보겠습니다. Kalani에 편집자 역할을 부여하는 허용 정책을 project_1에 설정하고 Nur에 게시자 역할을 부여하는 허용 정책을 topic_a에 설정하면 Kalani에게 편집자 역할을, Nur에게 topic_a에 대한 게시자 역할을 효과적으로 부여할 수 있습니다.

다음 다이어그램은 위의 예시를 나타낸 것입니다.

상속된 역할에 이미 주 구성원에게 필요한 모든 권한이 있는 경우 리소스 자체에 대한 추가 역할을 부여할 필요가 없습니다. 동일하거나 더 적은 권한이 포함된 다른 역할을 부여하는 것은 중복되며 아무런 효과가 없습니다.

예를 들어 소유자, 편집자, 뷰어라는 기본 역할을 생각해 보세요. 이 세 가지 역할의 권한은 동심원 형태로 겹칩니다. 즉, 소유자 역할에는 편집자 역할의 권한이 포함되며, 편집자 역할에는 뷰어 역할의 권한이 포함됩니다. 따라서 Kalani에게 프로젝트 수준에서 편집자 역할을 부여하는 경우 topic_a에 대한 뷰어 역할을 부여하는 것은 중복입니다. 이는 Kalani가 이미 프로젝트의 허용 정책에서 상속된 편집자 역할을 통해 뷰어 역할의 모든 권한을 가지고 있기 때문입니다.

다음 다이어그램은 위의 예시를 나타낸 것입니다.

예: Cloud Storage

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

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

• 데이터 처리 전문가인 Nur에게 스토리지 객체 관리자 역할(roles/storage.objectAdmin)을 부여합니다. 이 역할이 있으면 Nur는 프로젝트의 모든 버킷에 있는 어떠한 객체든지 읽고 추가하고 삭제할 수 있습니다.
• data-uploaders 그룹에 스토리지 객체 생성자 역할(roles/storage.objectCreator)을 부여합니다. 이 역할은 그룹 구성원이 버킷에 파일을 업로드할 수 있도록 허용하지만 다른 사용자가 업로드한 파일을 읽거나 삭제할 수는 없습니다.

다음 다이어그램은 위의 예시를 나타낸 것입니다.

예: Compute Engine

일반적으로 대기업에서는 개발팀이 아닌 전담팀이 방화벽과 같은 네트워크 및 보안 리소스를 관리합니다. 개발팀은 인스턴스를 실행하고 프로젝트의 인스턴스와 관련된 다른 작업을 수행할 수 있는 유연성을 필요로 할 수 있습니다.

이러한 상황에서는 다음과 같이 허용 정책을 구성할 수 있습니다.

• 조직 수준에서 네트워크 및 보안 관리자인 Kalani에게 Compute 네트워크 관리자 역할(roles/compute.networkAdmin)을 부여합니다. 이 역할을 가진 Kalani는 조직의 네트워크 리소스와 해당 조직의 모든 프로젝트를 변경할 수 있습니다.
• 개발팀 리드인 Nur에게 project_2 프로젝트에 대한 Compute 인스턴스 관리자 역할(roles/compute.instanceAdmin)을 부여합니다. 이 역할로 Nur는 인스턴스에 대한 모든 작업을 수행할 수 있지만 프로젝트에 연결된 네트워크 리소스를 변경하지 못하게 할 수 있습니다. 하지만 다른 프로젝트의 네트워크 리소스는 변경할 수 없습니다.

상속된 정책 보기 권한

상위 리소스에서 상속된 IAM 정책을 보려면 상위 리소스의 IAM 정책을 볼 수 있는 권한이 필요합니다. 예를 들어 프로젝트에 상속된 모든 IAM 정책을 보려면 프로젝트 상위 조직의 IAM 정책을 보고 상위 폴더의 IAM 정책을 볼 수 있는 권한이 필요합니다.

상위 리소스에서 상속된 IAM 정책을 보는 데 필요한 권한을 얻으려면 관리자에게 다음 IAM 역할을 부여해 달라고 요청하세요.

• 조직에서 상속된 IAM 정책 보기: 조직에 대한 조직 관리자(roles/resourcemanager.organizationAdmin)
• 폴더에서 상속된 IAM 정책 보기: 폴더에 대한 폴더 관리자(roles/resourcemanager.folderAdmin)
• 프로젝트에서 상속된 IAM 정책 보기: 프로젝트에 대한 프로젝트 IAM 관리자(roles/resourcemanager.projectIamAdmin)

역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.

이러한 사전 정의된 역할에는 상위 리소스에서 상속된 IAM 정책을 보는 데 필요한 권한이 포함되어 있습니다. 필요한 정확한 권한을 보려면 필수 권한 섹션을 펼치세요.

필수 권한

상위 리소스에서 상속된 IAM 정책을 보려면 다음 권한이 필요합니다.

• 조직에서 상속된 IAM 정책 확인: 조직의 resourcemanager.organizations.getIamPolicy
• 폴더에서 상속된 IAM 정책 확인: 폴더의 resourcemanager.folders.getIamPolicy
• 프로젝트에서 상속된 IAM 정책 확인: 프로젝트의 resourcemanager.projects.getIamPolicy

커스텀 역할이나 다른 사전 정의된 역할을 사용하여 이 권한을 부여받을 수도 있습니다.

권장사항

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

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

• 가능하면 개별 사용자가 아닌 그룹에 역할을 부여합니다. 허용 정책을 업데이트하기보다 그룹의 구성원을 관리하기가 더 쉽습니다. 허용 정책에 사용되는 그룹의 소유권을 제어해야 합니다.

  Google 그룹을 관리하는 방법에 관한 자세한 내용은 Google 그룹스 도움말을 참조하세요.

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

  사전 정의된 적절한 역할을 찾으려면 사전 정의된 역할 참조를 참조하세요. 사전 정의된 적절한 역할이 없는 경우 자체 커스텀 역할을 만들 수도 있습니다.

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

• 하위 리소스 허용 정책은 상위 리소스 허용 정책을 상속받습니다. 예를 들어 프로젝트 허용 정책이 사용자에게 Compute Engine 가상 머신(VM) 인스턴스를 관리할 수 있는 권한을 부여하면 사용자는 각 VM에 설정한 허용 정책에 관계없이 해당 프로젝트에서 모든 Compute Engine VM을 관리할 수 있습니다.

• 모든 프로젝트에서 주 구성원 최소 2명 이상에 소유자 역할(roles/owner)이 있는지 확인합니다. 또는 주 구성원이 최소 2명 이상 포함된 그룹에 소유자 역할을 부여합니다.

  이 방법을 사용하면 주 구성원 중 한 명이 퇴사하더라도 프로젝트를 계속 관리할 수 있습니다.

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

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

• 허용 정책이 규정을 준수하는지 감사합니다. 감사 로그에 setIamPolicy() 호출이 모두 기록되므로 허용 정책이 만들어지거나 수정된 시점을 추적할 수 있습니다.

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

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