GCP - Basic Information
Resource hierarchy
Google Cloud는 정책 및 권한에 대한 특정 부착 지점을 가진 논리적 부모/자식 워크플로를 제공하는 Resource hierarchy를 사용합니다. 이는 개념적으로 전통적인 파일 시스템과 유사합니다.
고수준에서 보면 다음과 같습니다:
가상 머신(Compute Instance라고 불림)은 리소스입니다. 리소스는 프로젝트에 존재하며, 아마도 다른 Compute Instances, 스토리지 버킷 등과 함께 있을 것입니다.
Projects Migration
roles/resourcemanager.projectCreator
와 roles/resourcemanager.projectMover
권한을 사용하여 조직 없이 프로젝트를 조직으로 마이그레이션하는 것이 가능합니다. 프로젝트가 다른 조직 내에 있는 경우, 먼저 조직에서 이동시키기 위해 GCP 지원팀에 연락해야 합니다. 자세한 내용은 여기를 참조하세요.
Organization Policies
조직의 클라우드 리소스에 대한 중앙 집중식 제어를 허용합니다:
조직의 리소스 사용 방법에 대한 제한을 구성하는 중앙 집중식 제어.
개발 팀이 준수 경계를 유지하도록 가드레일 정의 및 설정.
프로젝트 소유자와 팀이 준수 위반 걱정 없이 빠르게 이동할 수 있도록 지원.
이 정책들은 전체 조직, 폴더 또는 프로젝트에 영향을 미치도록 생성될 수 있습니다. 대상 리소스 계층 구조 노드의 하위 항목은 조직 정책을 상속합니다.
조직 정책을 정의하려면, 특정 Google Cloud 서비스 또는 Google Cloud 서비스 그룹에 대한 특정 유형의 제한인 제약 조건을 선택합니다. 원하는 제한으로 해당 제약 조건을 구성합니다.
Common use cases
도메인 기반 리소스 공유 제한.
Identity and Access Management 서비스 계정 사용 제한.
새로 생성된 리소스의 물리적 위치 제한.
서비스 계정 생성 비활성화.
조직의 리소스를 세밀하게 제어할 수 있는 많은 제약 조건이 있습니다. 자세한 내용은 모든 Organization Policy Service 제약 조건 목록을 참조하세요.
Default Organization Policies
IAM Roles
이들은 AWS의 IAM 정책과 유사하게 각 역할이 일련의 권한을 포함합니다.
그러나 AWS와 달리, 중앙 집중식 역할 저장소가 없습니다. 대신 리소스가 Y 주체에게 X 접근 역할을 부여하며, 리소스에 접근 권한이 있는 사람을 알아내는 유일한 방법은 해당 리소스에 대해 get-iam-policy
메서드를 사용하는 것입니다.
이것은 주체가 어떤 권한을 가지고 있는지 알아내는 유일한 방법이 모든 리소스에 권한을 부여하는 사람을 묻는 것을 의미하므로 문제가 될 수 있으며, 사용자가 모든 리소스에서 권한을 얻을 권한이 없을 수도 있습니다.
IAM에는 세 가지 유형의 역할이 있습니다:
기본/원시 역할, 이는 IAM 도입 이전에 존재했던 Owner, Editor, Viewer 역할을 포함합니다.
사전 정의된 역할, 이는 특정 서비스에 대한 세밀한 접근을 제공하며 Google Cloud에서 관리합니다. 사전 정의된 역할이 많이 있으며, 여기서 모든 역할과 그들이 가진 권한을 볼 수 있습니다.
사용자 정의 역할, 이는 사용자 지정 권한 목록에 따라 세밀한 접근을 제공합니다.
GCP에는 수천 개의 권한이 있습니다. 역할에 권한이 있는지 확인하려면 여기서 권한을 검색하고 어떤 역할이 있는지 확인할 수 있습니다.
또한 여기서 사전 정의된 역할을 각 제품이 제공하는지 검색할 수 있습니다. 일부 역할은 사용자에게 부여할 수 없으며 일부 권한 때문에 SAs에만 부여할 수 있습니다. 또한 권한은 관련 서비스에 부여된 경우에만 효과를 발휘한다는 점을 유의하세요.
또는 사용자 정의 역할이 특정 권한을 사용할 수 있는지 여기서 확인할 수 있습니다.
GCP - IAM, Principals & Org Policies EnumUsers
GCP 콘솔에는 사용자 또는 그룹 관리가 없습니다, 이는 Google Workspace에서 수행됩니다. Google Workspace에서 다른 ID 공급자를 동기화할 수 있습니다.
Workspaces 사용자 및 그룹에 접근하려면 https://admin.google.com을 방문하세요.
MFA는 Workspaces 사용자에게 강제할 수 있지만, 공격자는 cli를 통해 GCP에 접근할 수 있는 토큰을 사용할 수 있으며 이는 MFA로 보호되지 않습니다 (사용자가 이를 생성하기 위해 로그인할 때만 MFA로 보호됩니다: gcloud auth login
).
Groups
조직이 생성될 때 여러 그룹이 강력히 권장됩니다. 이들 중 하나를 관리하면 조직 전체 또는 중요한 부분을 손상시킬 수 있습니다:
Group | Function |
| 조직에 속한 모든 리소스를 관리합니다. 이 역할은 신중하게 할당해야 합니다; 조직 관리자에게는 모든 Google Cloud 리소스에 접근할 수 있는 권한이 있습니다. 대안으로, 이 기능이 매우 특권이 있으므로 그룹을 생성하는 대신 개별 계정을 사용하는 것을 고려하세요. |
| 네트워크, 서브넷, 방화벽 규칙 및 Cloud Router, Cloud VPN, 클라우드 로드 밸런서와 같은 네트워크 장치를 생성합니다. |
| 청구 계정을 설정하고 사용량을 모니터링합니다. |
| 애플리케이션을 설계, 코딩 및 테스트합니다. |
| 접근 관리 및 조직 제약 정책을 포함하여 전체 조직에 대한 보안 정책을 설정하고 관리합니다. Google Cloud 보안 인프라 계획에 대한 자세한 내용은 Google Cloud 보안 기초 가이드를 참조하세요. |
| 지속적인 통합 및 배포, 모니터링 및 시스템 프로비저닝을 지원하는 엔드 투 엔드 파이프라인을 생성하거나 관리합니다. |
| |
| |
| |
| 프로젝트의 지출을 모니터링합니다. 일반적인 구성원은 재무 팀의 일원입니다. |
| Google Cloud 조직 전체의 리소스 정보를 검토합니다. |
| 클라우드 보안을 검토합니다. |
| 네트워크 구성을 검토합니다. |
| 감사 로그를 검토합니다. |
| Security Command Center를 관리합니다. |
| Secret Manager에서 비밀을 관리합니다. |
Default Password Policy
강력한 비밀번호 강제
8자에서 100자 사이
재사용 금지
만료 없음
사람들이 타사 공급자를 통해 Workspace에 접근하는 경우, 이러한 요구 사항이 적용되지 않습니다.
Service accounts
이들은 리소스가 부착되어 GCP와 쉽게 상호작용할 수 있는 주체입니다. 예를 들어, 메타데이터에서 VM에 부착된 서비스 계정의 인증 토큰에 접근할 수 있습니다.
IAM 및 접근 범위를 모두 사용할 때 충돌이 발생할 수 있습니다. 예를 들어, 서비스 계정이 compute.instanceAdmin
IAM 역할을 가지고 있지만 침해된 인스턴스가 https://www.googleapis.com/auth/compute.readonly
범위 제한으로 인해 변경을 할 수 없습니다. 이는 인스턴스에 자동으로 할당된 OAuth 토큰을 사용하여 변경을 할 수 없게 합니다.
이는 AWS의 IAM 역할과 유사합니다. 하지만 AWS와 달리, 모든 서비스 계정은 모든 서비스에 부착될 수 있습니다 (정책을 통해 허용할 필요가 없습니다).
여러 서비스 계정은 실제로 GCP에서 자동으로 생성됩니다. 서비스를 사용하기 시작할 때:
그러나 custom service accounts를 생성하고 리소스에 연결하는 것도 가능합니다. 이는 다음과 같이 보일 것입니다:
Access scopes
Access scope는 GCP API 엔드포인트에 접근하기 위해 생성된 OAuth 토큰에 부여됩니다. 이는 OAuth 토큰의 권한을 제한합니다. 즉, 토큰이 리소스의 소유자에게 속해 있더라도 해당 리소스에 접근할 수 있는 토큰 범위가 없다면, 그 토큰은 그 권한을 (악용) 사용할 수 없습니다.
Google은 실제로 **access scope를 사용하지 않고 IAM에 전적으로 의존할 것을 권장**합니다. 웹 관리 포털은 실제로 이를 강제하지만, access scope는 여전히 프로그래밍 방식으로 커스텀 서비스 계정을 사용하여 인스턴스에 적용될 수 있습니다.
할당된 scope를 조회하여 확인할 수 있습니다:
이전의 scopes는 **gcloud
**를 사용하여 데이터를 액세스할 때 기본적으로 생성되는 것입니다. 이는 **gcloud
**를 사용할 때 먼저 OAuth 토큰을 생성한 다음 이를 사용하여 엔드포인트에 접속하기 때문입니다.
이 중 가장 중요한 scope는 **cloud-platform
**으로, 이는 기본적으로 GCP의 모든 서비스에 액세스할 수 있음을 의미합니다.
모든 가능한 scopes 목록을 여기에서 찾을 수 있습니다.
gcloud
브라우저 자격 증명이 있는 경우, 다음과 같이 다른 scopes로 토큰을 얻는 것이 가능합니다:
Terraform IAM Policies, Bindings and Memberships
Terraform에 의해 정의된 대로 https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam에서 terraform을 사용하여 GCP와 함께 리소스에 대한 principal 접근 권한을 부여하는 다양한 방법이 있습니다:
Memberships: 제한 없이 역할의 멤버로 principal을 설정합니다. 사용자를 역할의 멤버로 설정한 다음 그룹을 동일한 역할의 멤버로 설정하고, 또한 그 principal들(사용자와 그룹)을 다른 역할의 멤버로 설정할 수 있습니다.
Bindings: 여러 principal을 역할에 바인딩할 수 있습니다. 그 principal들은 여전히 다른 역할에 바인딩되거나 멤버가 될 수 있습니다. 그러나, 역할에 바인딩되지 않은 principal이 바인딩된 역할의 멤버로 설정되면, 다음 번에 바인딩이 적용될 때 멤버십이 사라집니다.
Policies: 정책은 권위적이며, 역할과 principal을 나타내고, 그 principal들은 더 많은 역할을 가질 수 없고, 그 역할들은 더 많은 principal을 가질 수 없습니다. 그 정책이 수정되지 않는 한(다른 정책, 바인딩 또는 멤버십에서도 마찬가지입니다). 따라서, 정책에서 역할이나 principal이 지정되면 모든 권한이 그 정책에 의해 제한됩니다. 물론, principal이 정책을 수정하거나 권한 상승 권한을 부여받는 경우(예: 새로운 principal을 생성하고 새로운 역할을 부여하는 경우) 이를 우회할 수 있습니다.
References
Last updated