정책 및 액세스 문제 해결

이 문서에서는 Google Cloud 액세스 정책 시행 제어 및 액세스 문제 해결을 위해 제공되는 도구에 대한 개요를 제공합니다. 이 문서는 조직 내 고객의 Google Cloud 리소스 액세스와 관련된 문제 해결을 돕길 원하는 지원 팀을 대상으로 합니다.

Google Cloud 액세스 정책 시행 제어

이 섹션에서는 사용자 또는 사용자 조직의 관리자가 Google Cloud 리소스 액세스에 영향을 주도록 구현할 수 있는 정책에 대해 설명합니다. 다음 제품 및 도구 중 일부 또는 전체를 사용하여 액세스 정책을 구현합니다.

라벨, 태그 및 네트워크 태그

Google Cloud에서는 리소스 라벨 및 그룹 지정을 위해 몇 가지 방법이 제공됩니다. 라벨, 태그, 네트워크 태그를 사용하여 정책 적용을 도울 수 있습니다.

라벨은 Google Cloud 리소스를 구성하는 데 도움이 되는 키-값 쌍입니다. 라벨은 많은 Google Cloud 서비스에서 지원됩니다. 예를 들어 프로덕션 환경에 있는 리소스와 반대로 테스트 환경에 있는 모든 리소스를 식별하기 위한 목적과 같이 다른 사용 사례를 위해 리소스를 필터링하고 그룹을 지정할 때에도 라벨을 사용할 수 있습니다. 정책 시행 측면에서 라벨은 리소스를 배치할 위치를 식별하기 위해 사용될 수 있습니다. 예를 들어 테스트용으로 라벨이 지정된 리소스에 적용하는 액세스 정책은 프로덕션용으로 라벨이 지정된 리소스에 적용하는 액세스 정책과 다릅니다.

태그는 리소스를 식별하고 정책을 적용하기 위한 메커니즘을 제공하는 키-값 쌍입니다. 조직, 폴더, 프로젝트에 태그를 연결할 수 있습니다. 태그는 해당 태그가 적용되는 계층 구조 수준의 모든 리소스에 적용됩니다. 태그를 사용하면 리소스에 특정 태그가 있는지 여부에 따라 액세스 정책을 조건부로 허용하거나 거부할 수 있습니다. 또한 방화벽 정책과 함께 태그를 사용하여 Virtual Private Cloud(VPC) 네트워크의 트래픽을 제어할 수 있습니다. 태그가 상속되고 액세스 및 방화벽 정책과 결합되는 방식을 이해하는 것이 문제 해결에 중요합니다.

네트워크 태그는 이전의 Resource Manager 태그와 다릅니다. 네트워크 태그는 VM 인스턴스에 적용되며, VM에 대한 네트워크 트래픽을 제어하기 위한 또 다른 방법으로 사용됩니다. Google Cloud 네트워크에서 네트워크 태그는 방화벽 규칙이 적용되는 VM과 네트워크 경로를 식별합니다. 방화벽 규칙에서 소스 및 대상 값으로 네트워크 태그를 사용할 수 있습니다. 또한 네트워크 태그를 사용하여 특정 경로가 적용되는 VM을 식별할 수 있습니다. 네트워크 및 라우팅 규칙을 정의하기 위한 목적으로 네트워크 태그가 사용되기 때문에 네트워크 태그를 이해하면 액세스 문제를 해결하는 데 도움이 될 수 있습니다.

VPC 방화벽 규칙

가상 머신(VM) 인스턴스 및 VM에서 빌드된 제품에 대한 트래픽을 허용하거나 거부하도록 VPC 방화벽 규칙을 구성할 수 있습니다. 모든 VPC 네트워크는 분산형 방화벽으로 작동합니다. VPC 방화벽 규칙은 네트워크 수준에서 정의되지만 연결은 인스턴스별로 허용되거나 거부됩니다. VPC 네트워크, 태그로 그룹화된 VM, 서비스 계정으로 그룹화된 VM에 VPC 방화벽 규칙을 적용할 수 있습니다.

VPC 서비스 제어

VPC 서비스 제어는 Cloud Storage 및 BigQuery와 같이 Google Cloud 서비스에서 데이터 무단 반출을 완화하는 데 도움이 되는 경계 보안 솔루션을 제공합니다. Google Cloud 리소스 주위에 보안 경계를 만드는 서비스 경계를 만들고, 해당 경계 내부 및 외부에서 허용되는 항목을 관리할 수 있습니다. VPC 서비스 제어는 또한 IP 주소 및 ID와 같은 상황별 속성을 기준으로 정책을 구현하여 컨텍스트 인식 액세스 제어를 제공합니다.

Resource Manager

Resource Manager를 사용하여 조직 리소스를 설정합니다. Resource Manager는 애플리케이션 개발 방법을 리소스 계층에 맞게 매핑할 수 있게 해주는 도구를 제공합니다. 논리적인 리소스 그룹화에 도움을 주는 것 외에도 Resource Manager는 액세스 제어 및 조직 정책을 위한 연결 지점과 상속성을 제공합니다.

Identity and Access Management

Identity and Access Management(IAM)를 사용하면 누가(ID) 어떤 리소스에 대해 어떤 액세스 권한(역할)을 갖는지 정의할 수 있습니다. IAM 정책은 읽기 또는 쓰기 액세스 권한과 같이 누가 어떤 액세스 권한 유형을 갖고 있는지를 정의하는 구문 모음입니다. IAM 정책이 리소스에 연결되고 사용자가 리소스 액세스를 시도할 때마다 정책에 따라 액세스 제어가 시행됩니다.

IAM의 한 가지 특성은 IAM 조건입니다. 정책 정의 중 IAM 조건을 구현할 때는 구성된 조건이 충족될 때만 ID(주 구성원)에 리소스 액세스 권한을 부여하도록 선택할 수 있습니다. 예를 들어 IAM 조건을 사용하여 회사 사무실에서 요청을 수행하는 직원만 리소스에 액세스할 수 있도록 제한할 수 있습니다.

조직 정책 서비스

조직 정책 서비스를 사용하면 조직 계층 간에 지원되는 리소스에 제약조건을 적용할 수 있습니다. 조직 정책이 지원하는 각 리소스에는 해당 리소스에 가능한 제한 방법을 설명하는 제약조건 모음이 포함되어 있습니다. 리소스 구성을 제한하는 특정 규칙을 정의하는 정책을 정의합니다.

조직 정책 서비스를 사용하면 승인된 관리자가 필요에 따라 폴더 또는 프로젝트 수준에서 기본 조직 정책을 재정의할 수 있습니다. 조직 정책은 리소스 구성 방법을 주로 지정하고 IAM 정책은 해당 리소스에 대해 ID에 부여되는 권한을 주로 지정합니다.

할당량

Google Cloud는 리소스에 대한 할당량을 통해 프로젝트에 사용할 수 있는 특정 Google Cloud 리소스의 양을 제한합니다. 현재 프로젝트 수도 할당량의 영향을 받습니다. 할당량에 따라 제한되는 리소스 사용량 유형은 다음과 같습니다.

  • 비율 할당량: 예를 들어 일일 API 요청이 있습니다. 이 할당량은 지정된 시간(예: 1분 또는 하루) 후 재설정됩니다.
  • 할당 할당량: 예를 들어 프로젝트에 사용되는 부하 분산기 또는 가상 머신의 수가 있습니다. 이 할당량은 시간이 경과해도 재설정되지 않습니다. Google Kubernetes Engine(GKE) 클러스터를 삭제할 때와 같이 리소스를 더 이상 사용할 필요가 없으면 할당량을 명시적으로 해제해야 합니다.

할당량 한도에 도달하면 새 리소스를 시작할 수 없습니다. 비율 할당량에 도달하면 API 요청을 완료할 수 없습니다. 이러한 두 문제는 모두 액세스 관련 문제로 보일 수 있습니다.

BeyondCorp Enterprise

BeyondCorp Enterprise는 여러 Google Cloud 제품을 사용하여 사용자의 ID 및 요청 컨텍스트를 기반으로 세부적인 액세스 제어를 적용합니다. Google Cloud Console 및 Google Cloud API에 대한 액세스를 제한하도록 BeyondCorp Enterprise를 구성할 수 있습니다.

BeyondCorp Enterprise 액세스 보호는 다음 Google Cloud 서비스를 사용하여 작동합니다.

  • IAP(Identity-Aware Proxy): 사용자 ID를 확인하고 컨텍스트를 사용하여 사용자에게 리소스 액세스 권한을 부여해야 하는지 여부를 결정하는 서비스입니다.
  • IAM: Google Cloud의 ID 관리 및 승인 서비스입니다.
  • Access Context Manager: 세밀한 액세스 제어를 가능하게 하는 규칙 엔진입니다.
  • 엔드포인트 확인: 사용자 기기 세부정보를 수집하는 Chrome 확장 프로그램입니다.

IAM 추천자

IAM에는 Google Cloud를 사용할 때 효율성 및 보안 성능 향상에 도움을 줄 수 있도록 포괄적이고 사전적인 가이드 모음을 제공하는 Policy Intelligence 도구가 포함되어 있습니다. 권장 작업은 Console에서 직접 또는 Pub/Sub 주제에 전송되는 이벤트를 사용하여 적용할 수 있는 알림을 통해 제공됩니다.

IAM 추천자는 Policy Intelligence 제품군 중 일부이며, 최소 권한의 원칙을 적용하는 데 도움이 됩니다. 추천자는 프로젝트 수준의 역할 부여를 이전 90일 동안 각 주 구성원에 사용된 권한과 비교합니다. 사용자가 주 구성원에 프로젝트 수준 역할을 부여했는데, 주 구성원이 해당 역할의 모든 권한을 사용하지 않을 경우, 추천자는 역할 취소를 추천합니다. 또한 필요에 따라 추천자는 대신 이보다 낮은 수준의 역할을 부여하도록 추천합니다.

권장사항을 자동으로 적용할 경우에는 잘못해서 특정 리소스에 대한 사용자 또는 서비스 계정의 액세스가 거부될 수 있습니다. 자동화를 사용하기로 결정할 때는 IAM 추천자 권장사항에 따라 자신에게 맞는 자동화 수준이 어느 정도인지 판단하는 것이 좋습니다.

Kubernetes 네임스페이스 및 RBAC

Kubernetes는 Google Cloud에서 Google Kubernetes Engine(GKE)와 같은 관리형 서비스로 운영됩니다. GKE는 GKE 클러스터가 실행되는 위치에 관계없이 일관성 있는 정책을 적용할 수 있습니다. 리소스 액세스에 영향을 주는 정책은 기본 제공되는 Kubernetes 제어 및 Google Cloud 특정 제어로 조합됩니다.

VPC 방화벽 및 VPC 서비스 제어 외에도 GKE는 네임스페이스, 역할 기반 액세스 제어(RBAC), 워크로드 ID를 사용하여 리소스 액세스에 영향을 주는 정책을 관리합니다.

네임스페이스

네임스페이스는 동일한 물리적 클러스터로 지원되는 가상 클러스터이며, 이름 범위를 제공합니다. 리소스 이름은 네임스페이스 내에서 고유해야 하지만 다른 네임스페이스에서는 같은 이름을 사용해도 무방합니다. 네임스페이스를 사용하면 리소스 할당량을 사용하여 여러 사용자 간에 클러스터 리소스를 구분할 수 있습니다.

RBAC

RBAC에는 다음 기능이 포함됩니다.

  • 클러스터에서 실행되는 API 리소스를 사용자가 사용하는 방법을 미세하게 제어합니다.
    • 사용자 및 서비스 계정이 액세스할 수 있는 작업 및 리소스를 정의하는 세부 정책을 만들 수 있습니다.
    • Can control access for Google 계정, Google Cloud 서비스 계정, Kubernetes 서비스 계정에 대한 액세스를 제어할 수 있습니다.
  • 전체 클러스터 또는 클러스터 내의 특정 네임스페이스에 적용되는 RBAC 권한을 만들 수 있습니다.
    • 클러스터 전체 권한은 특정 사용자의 특정 API 리소스 액세스를 제한하는 데 유용합니다. 이러한 API 리소스에는 보안 정책 및 보안 비밀이 포함됩니다.
    • 네임스페이스별 권한은 고유 네임스페이스 내에서 작동하는 여러 사용자 그룹이 있는 경우에 유용합니다. RBAC는 해당 네임스페이스 내에 있는 클러스터 리소스에 대해서만 사용자가 액세스할 수 있도록 보장하는 데 도움이 됩니다.
  • 단일 네임스페이스 내의 리소스에 대해 액세스 권한을 부여하는 데에만 사용할 수 있는 역할입니다.
  • 권한 집합을 나타내는 규칙을 포함하는 역할입니다. 권한은 완전히 가산적이며 거부 규칙이 없습니다.

IAM 및 Kubernetes RBAC가 서로 연동되어 둘 중 하나의 도구에 따라서만 충분한 권한을 갖고 있는 경우 사용자의 작업 수행이 승인됩니다.

그림 1은 RBAC 및 네임스페이스와 함께 IAM을 사용하여 정책을 구현하는 방법을 보여줍니다.

그림 1. IAM과 Kubernetes RBAC는 함께 작동하여 GKE 클러스터에 대한 액세스를 제어합니다.

그림 1은 다음 정책 구현을 보여줍니다.

  1. 프로젝트 수준에서 IAM은 클러스터 관리자가 클러스터를 관리하고 컨테이너 개발자가 클러스터 내의 API에 액세스할 수 있게 해주는 역할을 정의합니다.
  2. 클러스터 수준에서 RBAC는 개별 클러스터에 대한 권한을 정의합니다.
  3. 네임스페이스 수준에서 RBAC는 네임스페이스에 대한 권한을 정의합니다.

워크로드 아이덴티티

RBAC 및 IAM 외에도 워크로드 아이덴티티의 영향을 이해해야 합니다. 워크로드 아이덴티티를 사용하면 Google 서비스 계정으로 작동하도록 Kubernetes 서비스 계정을 구성할 수 있습니다. Kubernetes 서비스 계정으로 실행되는 모든 애플리케이션은 Google Cloud APIs에 액세스할 때 자동으로 Google 서비스 계정으로 인증됩니다. 이러한 인증을 통해 클러스터의 애플리케이션에 대해 세분화된 ID 및 승인을 할당할 수 있습니다.

워크로드 아이덴티티에는 GKE 애플리케이션이 액세스할 수 있는 Google Cloud API를 제어하기 위해 IAM 권한이 필요합니다. 예를 들어 IAM 권한이 변경될 경우 GKE 애플리케이션이 Cloud Storage에 쓰기를 수행하지 못할 수 있습니다.

문제 해결 도구

이 섹션에서는 정책 문제 해결을 돕기 위해 제공되는 도구에 대해 설명합니다. 여러 제품 및 기능을 사용하여 정책 조합을 적용할 수 있습니다. 예를 들어 방화벽 및 서브넷을 사용하여 환경 내에서 그리고 사용자가 정의한 보안 영역 내에서 리소스 간 통신을 관리할 수 있습니다. 또한 IAM을 사용하여 사용자가 정의한 VPC 서비스 제어 영역 및 보안 영역 내에서 누가 무엇에 액세스할 수 있는지 제어할 수 있습니다.

로그

문제가 발생하면 일반적으로 문제 해결을 위해 가장 먼저 로그를 조사하는 것이 좋습니다. 액세스 관련 문제에 관해 유용한 정보를 제공하는 Google Cloud 로그는 Cloud 감사 로그, 방화벽 규칙 로깅, VPC 흐름 로그입니다.

Cloud 감사 로그

Cloud 감사 로그는 각 프로젝트, 폴더, 조직에 대한 감사 로그 스트림으로 구성되며, 여기에는 관리자 활동, 데이터 액세스, 시스템 이벤트가 포함됩니다. Google Cloud 서비스는 이러한 로그에 감사 로그 항목을 기록하여 Google Cloud 프로젝트 내에서 어떤 사용자가 어떤 작업을 수행했는지, 작업을 수행한 위치와 시간은 언제인지 식별할 수 있게 해줍니다.

  • 관리자 활동 로그에는 API 호출이나 리소스의 구성 또는 메타데이터를 수정하는 기타 관리 작업과 관련된 로그 항목이 포함됩니다. 관리자 활동 로그는 항상 사용 설정되어 있습니다. 관리자 활동 로그 가격 책정 및 할당량에 대한 자세한 내용은 Cloud 감사 로그 개요를 참조하세요.
  • 데이터 액세스 로그는 사용자가 제공한 데이터를 생성하거나 수정하거나 읽는 API 호출을 기록합니다. BigQuery를 제외하고 데이터 액세스 감사 로그는 기본적으로 중지되어 있습니다. 데이터 액세스 로그는 크기가 커지고 비용을 발생시킬 수 있습니다. 데이터 액세스 로그 사용량 한도에 대한 자세한 내용은 할당량 및 한도를 참조하세요. 예상 비용에 대한 자세한 내용은 가격 책정을 참조하세요.
  • 시스템 이벤트 로그는 Compute Engine이 시스템 이벤트를 수행하는 시기에 관한 로그 항목을 포함합니다. 예를 들어 각 라이브 마이그레이션은 시스템 이벤트로 기록됩니다. 시스템 이벤트 로그 가격 책정 및 할당량에 대한 자세한 내용은 Cloud 감사 로그 개요를 참조하세요.

Cloud Logging에서 protoPayload 필드에는 감사 로깅 데이터를 정의하는 AuditLog 객체가 포함됩니다. 감사 로그 항목 예시는 샘플 감사 로그 항목을 참조하세요.

관리자 활동 감사 로그를 보려면 로그 뷰어 역할(roles/logging.viewer) 또는 기본 뷰어 역할(roles/viewer)이 있어야 합니다. 가능한 경우 태스크를 완료하는 데 필요한 최소 권한이 포함된 역할을 선택하세요.

개별 감사 로그 항목은 지정된 기간 동안 저장됩니다. 보관 기간을 늘리려면 로그 항목을 Cloud Storage, BigQuery, Pub/Sub로 내보내면 됩니다. 조직의 모든 프로젝트, 폴더, 청구 계정에서 로그 항목을 내보내려면 집계 내보내기를 사용하면 됩니다. 집계 내보내기를 사용하면 조직 내에서 로그를 중앙 집중식으로 검토할 수 있습니다.

문제 해결을 돕기 위해 감사 로그를 사용하려면 다음을 수행하세요.

  • 로그를 보기 위해 필요한 IAM 역할이 있는지 확인합니다. 로그를 내보낼 경우에도 싱크에서 내보낸 로그를 보기위한 권한이 필요합니다.
  • 감사 로그 사용 권장사항에 따라 감사 전략을 충족시킵니다.
  • 로그를 보기 위한 팀 전략을 선택합니다. Cloud 감사 로그에서는 로그를 보기 위한 여러 방법이 존재하며, 문제 해결 팀의 모든 사람이 동일한 방법을 사용해야 합니다.
  • 활동 로그에 대한 개요는 Google Cloud Console 활동 페이지를 참조하세요.
  • 로그를 내보낸 싱크에서 내보낸 로그를 확인합니다. 보관 기간이 지난 로그만 싱크에서 볼 수 있습니다. 또한 내보낸 로그를 사용하여 정상 작동 시간과의 비교 조사 등을 수행할 수 있습니다.

방화벽 규칙 로깅

방화벽 규칙 로깅을 사용하면 방화벽 규칙의 영향을 감사, 확인, 분석할 수 있습니다. 예를 들어 트래픽을 거부하도록 디자인된 방화벽 규칙이 의도한 대로 작동하는지 확인할 수 있습니다.

연결을 로깅해야 하는 각 방화벽 규칙에 방화벽 규칙 로깅을 개별적으로 사용 설정합니다. 방화벽 규칙 로깅은 방화벽 규칙의 작업(허용 또는 거부) 또는 방향(인그레스 또는 이그레스)에 관계없이 모든 방화벽 규칙에 대한 옵션입니다. 방화벽 규칙 로깅은 많은 양의 데이터를 생성할 수 있습니다. 방화벽 규칙 로깅은 관련 비용이 청구되므로, 로깅할 연결을 신중하게 계획해야 합니다.

방화벽 로그를 저장할 위치를 결정합니다. 조직 전체의 로그 보기가 필요하면 방화벽 로그를 감사 로그와 동일한 싱크로 내보냅니다. 필터를 사용하여 특정 방화벽 이벤트를 검색합니다.

방화벽 통계

방화벽 통계는 방화벽 사용에 대한 정보 및 VPC 네트워크에 대한 다양한 방화벽 규칙의 영향을 포함하는 보고서를 제공합니다. 방화벽 통계를 사용하여 방화벽 규칙이 의도된 연결을 허용하거나 차단하는지 확인할 수 있습니다.

또한 방화벽 통계를 사용하여 다른 규칙에 의해 섀도 처리된 방화벽 규칙을 확인할 수 있습니다. 섀도 처리된 규칙이란 IP 주소 범위 및 포트와 같은 관련 속성이 모두 해당 규칙보다 우선 순위가 높거나 같은 하나 이상의 다른 방화벽 규칙의 속성과 겹치는 방화벽 규칙을 의미합니다. 섀도 처리된 규칙은 방화벽 규칙 로깅을 사용 설정한 후 24시간 내에 계산됩니다.

방화벽 규칙 로깅을 사용 설정하면 방화벽 통계가 로그를 분석하여 지정된 관찰 기간(기본적으로 이전 24시간) 동안 사용된 모든 거부 규칙의 통계를 표시합니다. 거부 규칙 통계는 방화벽 패킷 드롭 신호를 제공합니다. 패킷 드롭 신호를 사용하면 보안 보호로 인해 패킷 드롭이 예상되는지 또는 잘못된 네트워크 구성 등의 문제로 인해 패킷 드롭이 예상되지 않는지 확인할 수 있습니다.

VPC 흐름 로그

VPC 흐름 로그는 VM 인스턴스에서 전송되거나 수신되는 네트워크 흐름의 샘플을 기록합니다. VPC 흐름 로그에는 VM에 영향을 주는 트래픽이 포함됩니다. 이그레스 거부 방화벽 규칙으로 트래픽이 차단될 경우에도 모든 이그레스(송신) 트래픽이 로깅됩니다. 인그레스(수신) 트래픽은 인그레스 허용 방화벽 규칙으로 트래픽이 허용될 경우에 로깅됩니다. 인그레스 거부 방화벽 규칙이 트래픽을 차단할 경우 인그레스 트래픽이 로깅되지 않습니다.

흐름 로그는 각 VM 연결에서 특정 간격으로 수집됩니다. 지정된 연결에 대해 지정된 기간(집계 기간) 동안 수집된 모든 샘플링된 패킷이 단일 흐름 로그 항목으로 집계됩니다. 그런 후 로그 흐름 항목이 Cloud Logging으로 전송됩니다.

VPC 흐름 로그는 각 VPC 서브넷에 대해 사용 설정 또는 중지됩니다. VPC 흐름 로그를 사용 설정하면 대량의 데이터가 생성됩니다. VPC 흐름 로그를 사용 설정할 서브넷을 신중하게 관리하는 것이 좋습니다. 예를 들어 개발 프로젝트에 사용되는 서브넷에는 오래 동안 흐름 로그를 사용 설정하지 않는 것이 좋습니다. 내보낸 싱크 또는 Cloud Logging을 사용하여 직접 VPC 흐름 로그를 쿼리할 수 있습니다. 감지된 트래픽 관련 문제를 해결할 때는 VPC 흐름 로그를 사용하여 트래픽이 예상된 포트를 통해 VM에서 전송 또는 수신되는지 확인할 수 있습니다.

알림

알림을 사용하면 Google Cloud 리소스 액세스에 영향을 줄 수 있는 정책 위반 이벤트에 대한 알림을 일찍 받아 볼 수 있습니다.

실시간 알림

Cloud 애셋 인벤토리는 Google Cloud 애셋 메타데이터를 5주 간 보관합니다. 애셋은 지원되는 Google Cloud 리소스입니다. 지원되는 리소스에는 방화벽 규칙 및 GKE 네임스페이스, 역할 및 클러스터 역할 바인딩과 같은 연관된 네트워크 기능이 있는 IAM, Compute Engine이 포함됩니다. 위의 모든 리소스는 Google Cloud 리소스 액세스에 영향을 줍니다.

방화벽 규칙 및 전달 규칙과 같은 리소스 구성의 위반 사항을 모니터링하려면 실시간 알림을 구독하면 됩니다. 리소스 구성이 변경되면 실시간 알림이 즉시 Pub/Sub를 통해 알림을 전송합니다. 알림은 지원 호출을 선점하여 문제를 조기에 알려줄 수 있습니다.

Cloud 감사 로그 및 Cloud Functions

실시간 알림 사용을 보완하기 위해 민감한 작업 호출에 대해 Cloud Logging 및 알림을 모니터링할 수 있습니다. 예를 들어 호출을 조직 수준의 SetIamPolicy필터링하는 Cloud Logging 싱크를 만들 수 있습니다. 싱크는 Cloud 함수 트리거를 위해 사용할 수 있는 Pub/Sub 주제에 로그를 전송합니다.

연결 테스트

액세스 문제가 네트워크 관련 또는 권한 관련 문제인지 확인하려면 Network Intelligence Center 연결 테스트 도구를 사용합니다. 연결 테스트는 소스와 대상 엔드포인트 사이의 연결을 확인할 수 있게 해주는 정적 구성 분석기 및 진단 도구입니다. 연결 테스트는 Google Cloud 네트워크 구성과 연관된 네트워크 관련 액세스 문제의 근본 원인을 식별하는 데 도움이 됩니다.

연결 테스트는 온프레미스 네트워크에 대해 VPC 네트워크, VPC 네트워크 피어링, VPN 터널을 포함한 테스트를 수행합니다. 예를 들어 연결 테스트를 통해 연결을 차단하는 방화벽 규칙을 식별할 수도 있습니다. 자세한 내용은 일반 사용 사례를 참조하세요.

정책 문제 해결 도구

Google Cloud의 많은 태스크에 IAM 역할 및 연관된 권한이 필요합니다. 역할 내에 포함된 권한을 확인하고 태스크를 완료하는 데 필요한 각 권한을 확인하는 것이 좋습니다. 예를 들어 Compute Engine 이미지를 사용하여 인스턴스를 만들기 위해서는 9개 권한이 포함된 compute.imageUser 역할이 필요합니다. 따라서 사용자에게는 이러한 9개 권한이 모두 포함된 역할 및 권한의 조합이 필요합니다.

정책 문제 해결 도구는 사용자나 서비스 계정에 리소스에 액세스할 수 있는 권한이 없는 이유를 디버깅하는 데 도움이 되는 Google Cloud Console 도구입니다. 액세스 문제 해결을 위해서는 정책 문제 해결 도구의 IAM 부분을 사용합니다.

예를 들어 다른 사용자는 안되고 특정 사용자만 프로젝트의 버킷에서 객체를 만들 수 있는 이유를 확인해야 할 수 있습니다. 정책 문제 해결 도구를 사용하면 첫 번째 사용자에게만 있고 두 번째 사용자에게는 없는 권한이 무엇인지 확인할 수 있습니다.

정책 문제 해결 도구에는 다음을 입력해야 합니다.

  • 주 구성원(개별 사용자, 서비스 계정 또는 그룹)
  • 권한(IAM 역할이 아닌 기본 권한)
  • 리소스

IAM 추천자

이전 추천자 섹션에서 설명한 대로 IAM 추천자는 정책 시행 제어 기능이지만, 문제 해결 도구로도 사용될 수 있습니다. 추천자는 이전 60일 동안의 IAM 액세스 로그 데이터 및 부여된 권한을 분석하는 일일 작업을 실행합니다. 추천자를 사용하면 이전에 허용된 리소스에 대한 사용자 액세스에 영향을 줄 수 있는 추천이 최근에 승인 및 적용되었는지 여부를 확인할 수 있습니다. 이 경우 삭제된 권한을 부여할 수 있습니다.

고객 관리로 에스컬레이션

액세스 관련 문제를 해결할 때는 클라우드 고객 관리로 에스컬레이션할 수 있도록 올바른 내부 지원 프로세스 및 잘 정의된 프로세스를 준비하는 것이 중요합니다. 이 섹션에서는 지원 설정 예시를 보여주고 신속한 문제 해결을 돕기 위해 고객 관리와 커뮤니케이션하는 방법을 설명합니다.

이 문서에 설명된 도구를 사용하여 문제를 해결할 수 없으면 명확하게 정의된 지원 프로세스에 따라 고객 관리가 사용자 문제를 해결할 수 있습니다. Google 사이트 안정성 엔지니어링(SRE) 교재의 효율적인 문제 해결 장에 설명된 대로 체계적인 문제 해결 방법을 따르는 것이 좋습니다.

내부 지원 프로세스로는 다음을 수행하는 것이 좋습니다.

  • 문제가 있는 경우 따라야 할 절차를 자세히 설명합니다.
  • 명확하게 정의된 에스컬레이션 경로를 포함합니다.
  • 통화 시 프로세스를 설정합니다.
  • 이슈 대응 계획을 만듭니다.
  • 버그 추적 또는 헬프 데스크 시스템을 설정합니다.
  • 지원 담당자가 고객 관리와 커뮤니케이션하도록 승인되었고 연락처 이름으로 지정되었는지 확인합니다.
  • Google Cloud 지정 담당자에게 연락하는 방법을 포함하여 내부 직원들에게 지원 프로세스를 알려줍니다.
  • 정기적으로 지원 이슈를 분석하고 학습된 내용을 바탕으로 지원 프로세스를 반복하고 개선시킵니다.
  • 표준화된 소급 적용 양식을 포함합니다.

고객 관리로 에스컬레이션해야 할 경우 액세스 문제 해결 시 고객 관리에 알려줄 수 있도록 다음 정보를 준비합니다.

  • 액세스를 요청하는 ID(사용자 또는 서비스 계정 이메일)
    • 이 문제가 영향을 주는 범위가 모든 ID인지 또는 특정 ID인지 여부
    • 일부 ID만 영향을 받을 경우 작동되는 예시 ID와 실패하는 예시 ID
  • 해당 ID가 최근에 재생성되었는지 여부
  • 사용자가 액세스하려고 시도한 리소스(프로젝트 ID 포함)
  • 호출되는 요청 또는 메서드
    • 요청 또는 응답의 복사본을 제공합니다.
  • 이 액세스를 위해 ID에 부여된 권한
    • IAM 정책의 복사본을 제공합니다.
  • ID가 리소스를 액세스하려고 시도한 소스(위치). 예를 들면 Google Cloud 리소스(예: Compute Engine 인스턴스), Google Cloud Console, Google Cloud CLI, Cloud Shell에서 또는 온프레미스나 인터넷과 같은 외부 소스에서 액세스를 시도하는 경우입니다.
    • 소스가 다른 프로젝트에 있는 경우, 소스 프로젝트 ID를 제공합니다.
  • 오류가 처음 발생한 시간(타임스탬프) 및 현재도 문제가 되는지 여부
  • ID가 리소스에 성공적으로 액세스한 것으로 알려진 마지막 시간(타임스탬프 포함)
  • 문제가 시작되기 전에 수행된 모든 변경사항(타임스탬프 포함)
  • Cloud Logging에 기록된 모든 오류. 고객 관리에 정보를 알려주기 전 액세스 토큰, 사용자 인증 정보, 신용 카드 번호 등의 민감한 데이터를 모두 없애야 합니다.

다음 단계