Korean - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP - Basic Information

htARTE (HackTricks AWS Red Team Expert)를 통해 제로에서 영웅까지 AWS 해킹을 배우세요 htARTE (HackTricks AWS Red Team Expert)!

HackTricks를 지원하는 다른 방법:

리소스 계층 구조

Google Cloud는 전통적인 파일 시스템과 개념적으로 유사한 리소스 계층 구조를 사용합니다. 이는 정책 및 권한을 위한 특정 첨부 지점을 갖춘 논리적인 부모/자식 워크플로우를 제공합니다.

높은 수준에서는 다음과 같습니다:

Organization
--> Folders
--> Projects
--> Resources

가상 머신(Compute Instance라고 함)은 리소스입니다. 리소스는 프로젝트에 속해 있으며 다른 Compute Instance, 스토리지 버킷 등과 함께 있을 수 있습니다.

프로젝트 이전

조직 없이 프로젝트를 조직으로 이전하는 것이 가능합니다. 권한 roles/resourcemanager.projectCreator 및 roles/resourcemanager.projectMover가 필요합니다. 프로젝트가 다른 조직 내에 있는 경우, 먼저 조직에서 이동하도록 GCP 지원팀에 문의해야 합니다. 자세한 내용은 여기를 확인하세요.

조직 정책

조직의 클라우드 리소스에 대한 통제를 중앙 집중화할 수 있습니다:

  • 조직의 리소스 사용 방법에 대한 제한 사항을 구성할 수 있습니다.

  • 개발 팀이 규정 준수 범위 내에 머무를 수 있도록 가이드라인을 정의하고 설정할 수 있습니다.

  • 프로젝트 소유자 및 그들의 팀이 규정 준수를 위반하지 않고 신속하게 이동할 수 있도록 돕습니다.

이러한 정책은 전체 조직, 폴더 또는 프로젝트에 영향을 줄 수 있습니다. 대상 리소스 계층 노드의 하위 항속은 조직 정책을 상속합니다.

조직 정책을 정의하려면, Google Cloud 서비스 또는 Google Cloud 서비스 그룹에 대한 특정 유형의 제한인 constraint를 선택합니다. 그 제한 사항을 원하는 제한 사항으로 구성합니다.

공통 사용 사례

  • 도메인을 기반으로 리소스 공유 제한.

  • Identity and Access Management 서비스 계정 사용 제한.

  • 새로 생성된 리소스의 물리적 위치 제한.

  • 서비스 계정 생성 비활성화

조직의 리소스를 세밀하게 제어하는 많은 제한 사항이 있습니다. 자세한 내용은 조직 정책 서비스 제한 사항 목록을 참조하세요.

기본 조직 정책

이것은 GCP 조직을 설정할 때 Google이 기본적으로 추가하는 정책입니다:

액세스 관리 정책

  • 도메인 제한된 연락처: 지정된 도메인 외부의 사용자를 필수 연락처에 추가하는 것을 방지합니다. 이렇게 하면 플랫폼 알림을 받기 위해 선택한 도메인의 관리 사용자 ID만 허용하는 필수 연락처로 제한됩니다.

  • 도메인 제한된 공유: 지정된 도메인 외부의 사용자를 IAM 정책에 추가하는 것을 방지합니다. 이렇게 하면 선택한 도메인의 관리 사용자 ID만이 이 조직 내의 리소스에 액세스할 수 있도록 제한됩니다.

  • 공개 액세스 방지: Cloud Storage 버킷이 공개로 노출되는 것을 방지합니다. 이렇게 하면 개발자가 Cloud Storage 버킷을 인증되지 않은 인터넷 액세스를 허용하도록 구성할 수 없습니다.

  • 일관된 버킷 수준 액세스: Cloud Storage 버킷의 객체 수준 액세스 제어 목록(ACL)을 방지합니다. 이렇게 하면 Cloud Storage 버킷의 모든 객체에 일관된 IAM 정책을 적용하여 액세스 관리를 단순화할 수 있습니다.

  • OS 로그인 필요: 새 프로젝트에서 생성된 VM에 OS 로그인이 활성화됩니다. 이를 통해 IAM을 사용하여 인스턴스의 SSH 액세스를 관리할 수 있으며 개별 SSH 키를 만들고 관리할 필요가 없습니다.

서비스 계정을 위한 추가 보안 정책

  • 자동 IAM 권한 부여 비활성화: App Engine 및 Compute Engine 서비스 계정이 프로젝트를 생성할 때 자동으로 Editor IAM 역할을 부여받지 못하도록 방지합니다. 이를 통해 서비스 계정이 생성될 때 지나치게 허용되는 IAM 역할을 받지 않도록 합니다.

  • 서비스 계정 키 생성 비활성화: 공개 서비스 계정 키의 생성을 방지합니다. 이를 통해 지속적인 자격 증명 노출 위험을 줄일 수 있습니다.

  • 서비스 계정 키 업로드 비활성화: 공개 서비스 계정 키의 업로드를 방지합니다. 이를 통해 노출되거나 재사용된 키 자료의 위험을 줄일 수 있습니다.

안전한 VPC 네트워크 구성 정책

  • VM 인스턴스용 허용된 외부 IP 정의: 공용 IP가 있는 Compute 인스턴스의 생성을 방지하여 인터넷 트래픽에 노출될 수 있는 것을 방지합니다.

  • VM 중첩 가상화 비활성화: Compute Engine VM에서 중첩 VM의 생성을 방지합니다. 이를 통해 감시되지 않은 중첩 VM의 보안 위험을 줄일 수 있습니다.

  • VM 시리얼 포트 비활성화: Compute Engine VM에 대한 시리얼 포트 액세스를 방지합니다. 이를 통해 Compute Engine API를 사용하여 서버의 시리얼 포트에 입력되는 것을 방지할 수 있습니다.

  • Cloud SQL 인스턴스의 인가된 네트워크 제한: 공용 또는 내부 네트워크 범위가 Cloud SQL 데이터베이스에 액세스하는 것을 방지합니다.

  • IP 주소 유형에 따른 프로토콜 전달 제한: 외부 IP 주소에 대한 VM 프로토콜 전달을 방지합니다.

  • Cloud SQL 인스턴스의 공용 IP 액세스 제한: 인터넷 트래픽에 노출될 수 있는 Cloud SQL 인스턴스의 생성을 방지합니다.

  • 공유 VPC 프로젝트 lien 제거 제한: 공유 VPC 호스트 프로젝트의 실수로 삭제되는 것을 방지합니다.

  • 새 프로젝트의 내부 DNS 설정을 Zonal DNS Only로 설정: 서비스 가용성이 감소하는 레거시 DNS 설정 사용을 방지합니다.

  • 기본 네트워크 생성 건너뛰기: 기본 VPC 네트워크 및 관련 리소스의 자동 생성을 방지합니다. 이를 통해 지나치게 허용되는 기본 방화벽 규칙을 피할 수 있습니다.

  • VPC 외부 IPv6 사용 비활성화: 외부 IPv6 서브넷의 생성을 방지하여 무단 인터넷 액세스에 노출될 수 있는 것을 방지합니다.

IAM 역할

이는 AWS의 IAM 정책과 유사한데 각 역할에는 권한 집합이 포함되어 있습니다.

그러나 AWS와 달리 역할의 중앙 저장소가 없습니다. 대신, 리소스는 X 액세스 역할을 Y 주체에게 부여하며, 리소스에 누가 액세스 권한을 가지고 있는지 알아내는 유일한 방법은 해당 리소스에 대해 get-iam-policy 메서드를 사용하는 것입니다. 이것은 문제가 될 수 있습니다. 왜냐하면 이는 주체가 가진 권한을 알아내는 유일한 방법이 각 리소스에게 권한을 부여하는 주체에게 물어보는 것이기 때문이며, 사용자가 모든 리소스에서 권한을 얻을 수 있는 것이 아닐 수 있습니다.

IAM에는 세 가지 유형의 역할이 있습니다:

  • 기본/원시 역할은 IAM 도입 이전에 존재했던 소유자, 편집자, 뷰어 역할을 포함합니다.

  • 사전 정의된 역할은 특정 서비스에 대한 세분화된 액세스를 제공하며 Google Cloud에서 관리됩니다. 많은 사전 정의된 역할이 있으며, 그들이 가지는 권한을 **여기**에서 모두 볼 수 있습니다.

  • 사용자 지정 역할은 사용자가 지정한 권한 목록에 따라 세분화된 액세스를 제공합니다.

GCP에는 수천 개의 권한이 있습니다. 역할이 특정 권한을 가지고 있는지 확인하려면 여기에서 권한을 검색하여 해당 권한을 가진 역할을 확인할 수 있습니다.

또한 각 제품이 제공하는 **여기에서 사전 정의된 역할을 검색**할 수 있습니다. 일부 역할은 사용자에게 부여할 수 없고 일부 권한을 포함하기 때문에 서비스 계정에만 부여할 수 있습니다. 또한 권한은 해당 서비스에 부여되어야만 유효합니다.

또는 특정 권한을 사용할 수 있는 사용자 지정 역할을 여기에서 확인할 수 있습니다](https://cloud.google.com/iam/docs/custom-roles-permissions-support).

pageGCP - IAM, Principals & Org Policies Enum

사용자

GCP 콘솔에는 사용자 또는 그룹 관리 기능이 없습니다. 이 기능은 Google Workspace에서 처리됩니다. 그러나 Google Workspace에서 다른 신원 공급자를 동기화할 수 있습니다.

https://admin.google.com에서 Workspaces의 사용자 및 그룹에 액세스할 수 있습니다.

MFA는 Workspaces 사용자에게 강제로 적용될 수 있지만, 공격자는 MFA로 보호되지 않는 GCP에 액세스하기 위해 토큰을 사용할 수 있습니다(사용자가 로그인하여 생성할 때만 MFA로 보호됨: gcloud auth login).

그룹

조직을 만들 때 여러 그룹을 생성하는 것이 강력히 권장됩니다. 이러한 그룹 중 하나를 관리하면 조직의 전체 또는 중요한 부분을 손상시킬 수 있습니다:

그룹

기능

gcp-organization-admins (체크리스트에 필요한 그룹 또는 개별 계정)

조직에 속하는 모든 리소스를 관리합니다. 이 역할은 절약해서 할당하십시오. org 관리자는 모든 Google Cloud 리소스에 액세스할 수 있습니다. 또는 이 기능이 매우 특권적이므로 그룹을 만들기보다는 개별 계정을 사용하는 것을 고려하십시오.

gcp-network-admins (체크리스트에 필요함)

네트워크, 서브넷, 방화벽 규칙, Cloud Router, Cloud VPN, 클라우드 로드 밸런서와 같은 네트워크 장치를 생성합니다.

gcp-billing-admins (체크리스트에 필요함)

청구 계정 설정 및 사용량 모니터링을 수행합니다.

gcp-developers (체크리스트에 필요함)

애플리케이션 설계, 코딩 및 테스트를 수행합니다.

gcp-security-admins

전체 조직의 보안 정책을 수립하고 관리합니다. 액세스 관리 및 조직 제약 정책을 포함합니다. Google Cloud 보안 기반 가이드에서 Google Cloud 보안 인프라를 계획하는 데 대한 자세한 내용은 Google Cloud 보안 기초 가이드를 참조하십시오.

gcp-devops

지속적 통합 및 전달, 모니터링 및 시스템 프로비저닝을 지원하는 엔드 투 엔드 파이프라인을 생성하거나 관리합니다.

gcp-logging-admins

gcp-logging-viewers

gcp-monitor-admins

gcp-billing-viewer (더 이상 기본값으로 제공되지 않음)

프로젝트의 지출을 모니터링합니다. 일반적으로 재무팀의 구성원입니다.

gcp-platform-viewer (더 이상 기본값으로 제공되지 않음)

Google Cloud 조직 전체에서 리소스 정보를 검토합니다.

gcp-security-reviewer (더 이상 기본값으로 제공되지 않음)

클라우드 보안을 검토합니다.

gcp-network-viewer (더 이상 기본값으로 제공되지 않음)

네트워크 구성을 검토합니다.

grp-gcp-audit-viewer (더 이상 기본값으로 제공되지 않음)

감사 로그를 확인합니다.

gcp-scc-admin (더 이상 기본값으로 제공되지 않음)

보안 명령 센터를 관리합니다.

gcp-secrets-admin (더 이상 기본값으로 제공되지 않음)

Secret Manager에서 비밀을 관리합니다.

기본 암호 정책

  • 강력한 암호 적용

  • 8자에서 100자 사이

  • 재사용 금지

  • 만료 없음

  • 사람들이 제3자 공급업체를 통해 Workspace에 액세스하는 경우 이러한 요구 사항이 적용되지 않습니다.

서비스 계정

이것은 리소스가 첨부하고 상호 작용하기 쉽게 GCP와 상호 작용할 수 있는 주체입니다. 예를 들어, VM에 첨부된 서비스 계정의 인증 토큰에 액세스할 수 있습니다. IAM 및 액세스 범위를 모두 사용할 때 일부 충돌이 발생할 수 있습니다. 예를 들어, 서비스 계정에 compute.instanceAdmin IAM 역할이 있을 수 있지만 침입한 인스턴스가 https://www.googleapis.com/auth/compute.readonly의 범위 제한으로 제한되어 있을 수 있습니다. 이로 인해 자동으로 할당된 OAuth 토큰을 사용하여 변경을 수행할 수 없습니다.

AWS의 IAM 역할과 유사합니다. 그러나 AWS와 달리 모든 서비스 계정이 모든 서비스에 첨부될 수 있습니다(정책을 통해 허용할 필요가 없습니다).

사용하는 서비스에 따라 GCP에서 자동으로 생성되는 여러 서비스 계정이 있습니다.

PROJECT_NUMBER-compute@developer.gserviceaccount.com
PROJECT_ID@appspot.gserviceaccount.com

그러나 사용자 정의 서비스 계정을 생성하고 리소스에 연결하는 것도 가능합니다. 이는 다음과 같이 보일 것입니다:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

액세스 범위

액세스 범위는 GCP API 엔드포인트에 액세스하기 위해 생성된 OAuth 토큰에 부착됩니다. 이들은 OAuth 토큰의 권한을 제한합니다. 이는 토큰이 리소스의 소유자에 속해 있지만 해당 리소스에 액세스할 수 있는 범위가 토큰에 없는 경우, 해당 토큰은 그 권한을 남용할 수 없습니다.

Google은 실제로 액세스 범위를 사용하지 않고 완전히 IAM에 의존하는 것을 권장합니다. 웹 관리 포털은 실제로 이를 강제하지만 액세스 범위는 여전히 사용자 지정 서비스 계정을 프로그래밍 방식으로 사용하여 인스턴스에 적용할 수 있습니다.

할당된 범위를 조회하여 무엇이 할당되어 있는지 볼 수 있습니다:

curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>'

{
"issued_to": "223044615559.apps.googleusercontent.com",
"audience": "223044615559.apps.googleusercontent.com",
"user_id": "139746512919298469201",
"scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth",
"expires_in": 2253,
"email": "username@testing.com",
"verified_email": true,
"access_type": "offline"
}

이전 scopes는 **gcloud**를 사용하여 기본적으로 생성된 것들입니다. 이는 **gcloud**를 사용할 때 먼저 OAuth 토큰을 생성한 다음 엔드포인트에 연락하기 위해 사용하기 때문입니다.

가장 중요한 scope 중 하나는 **cloud-platform**으로, 이는 기본적으로 GCP의 모든 서비스에 액세스할 수 있다는 것을 의미합니다.

여기에서 모든 가능한 scopes 목록을 찾을 수 있습니다.

gcloud 브라우저 자격 증명이 있는 경우, 다른 scopes로 토큰을 얻을 수 있습니다. 다음과 같이 수행할 수 있습니다:

# Maybe you can get a user token with other scopes changing the scopes array from ~/.config/gcloud/credentials.db

# Set new scopes for SDKs credentials
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/sqlservice.login,https://www.googleapis.com/auth/appengine.admin,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/accounts.reauth,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.domain,https://www.googleapis.com/auth/admin.directory.user

# Print new token
gcloud auth application-default print-access-token

# To use this token with some API you might need to use curl to indicate the project header with --header "X-Goog-User-Project: <project-name>"

Terraform IAM 정책, 바인딩 및 멤버십

https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam에서 terraform에 의해 정의된대로 GCP에서 terraform을 사용하면 리소스에 대한 주체의 액세스를 부여하는 다양한 방법이 있습니다:

  • 멤버십: 주체를 역할의 구성원으로 설정하고 역할이나 주체에 대한 제한 없이 설정합니다. 사용자를 역할의 구성원으로 설정한 다음 동일한 역할의 구성원으로 그룹을 설정하고 해당 주체(사용자 및 그룹)를 다른 역할의 구성원으로 설정할 수 있습니다.

  • 바인딩: 여러 주체를 역할에 바인딩할 수 있습니다. 이러한 주체는 여전히 바인딩되거나 다른 역할의 구성원이 될 수 있습니다. 그러나 역할에 바인딩되지 않은 주체가 바인딩된 역할의 구성원으로 설정되면 바인딩이 적용될 때 멤버십이 사라집니다.

  • 정책: 정책은 권한이 있는데, 역할과 주체를 나타내고, 해당 주체는 더 많은 역할을 가질 수 없으며 해당 역할은 더 많은 주체를 가질 수 없습니다. 해당 정책이 수정되지 않는 한(다른 정책, 바인딩 또는 멤버십에서도) 역할이나 주체가 정책에 지정된 경우 해당 정책에 의해 권한이 제한됩니다. 물론, 주체가 정책을 수정하거나 권한 상승 권한(새 주체를 만들고 새 역할을 바인딩하는 등)을 부여받은 경우 이를 우회할 수 있습니다.

참고 자료

htARTE (HackTricks AWS Red Team Expert)를 통해 제로에서 영웅까지 AWS 해킹을 배우세요!

HackTricks를 지원하는 다른 방법:

前へGCP Pentesting次へGCP - Federation Abuse

最終更新