액세스 투명성 로그 이해 및 사용

이 페이지에서는 액세스 투명성 로그 항목 콘텐츠와 이를 보고 사용하는 방법을 설명합니다.

액세스 투명성 로그 세부정보

액세스 투명성 로그를 기존 보안 정보 및 이벤트 관리(SIEM) 도구와 통합하여 Google 직원이 콘텐츠에 액세스할 때 감사를 자동화할 수 있습니다. 액세스 투명성 로그는 Cloud 감사 로그와 함께 Google Cloud Console에서 사용할 수 있습니다.

액세스 투명성 로그 항목에는 다음과 같은 유형의 세부정보가 포함됩니다.

  • 영향을 받는 리소스와 작업
  • 작업 수행 시간
  • 작업 이유(예: 고객 지원 요청과 관련된 사례 번호)
  • 콘텐츠 작업을 수행한 직원에 대한 데이터(예: Google 직원의 위치)

액세스 투명성 사용 설정

Google Cloud 조직에 액세스 투명성을 사용 설정하는 방법은 액세스 투명성 사용 설정을 참조하세요.

액세스 투명성 로그 보기

Google Cloud 조직에 액세스 투명성을 구성한 후에는 사용자 또는 그룹에 비공개 로그 뷰어 역할을 할당하여 액세스 투명성 로그에 액세스할 수 있는 사용자에 대한 제어를 설정할 수 있습니다. 자세한 내용은 Cloud Logging 액세스 제어 가이드를 참조하세요.

액세스 투명성 로그를 보려면 다음 Google Cloud Observability 로깅 필터를 사용합니다.

logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Faccess_transparency"

로그 탐색기에서 액세스 투명성 로그를 확인하는 방법은 로그 탐색기 사용을 참조하세요.

Cloud Monitoring API나 Cloud Run Functions를 사용하여 로그를 모니터링할 수도 있습니다. 시작하려면 Cloud Monitoring 문서를 참조하세요.

선택사항: 로그 기반 측정항목을 만든 후 알림 정책을 설정하면 이러한 로그를 통해 발생한 문제를 신속하게 확인할 수 있습니다.

샘플 액세스 투명성 로그 항목

다음은 액세스 투명성 로그 항목의 예입니다.

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  principalJobTitle: "Engineering"
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  eventId: "asdfg12345asdfg12345asdfg12345"
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/BUCKET_NAME/objects/foo123"
    }
  ]
  accessApprovals: [
   0: "projects/123/approvalRequests/abcdef12345"
  ]
 }
 logName:  "projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

로그 필드 설명

필드 설명
insertId 로그의 고유 식별자입니다.
@type 액세스 투명성 로그 식별자입니다.
principalOfficeCountry 액세스한 Google 직원의 사무실이 위치한 국가의 국가 코드(ISO 3166-1 alpha-2)입니다. 위치를 확인할 수 없는 경우에는 ??이고 인구가 적은 국가에 위치한 경우에는 문자 3개로 구성된 대륙 식별자가 표시됩니다.
principalEmployingEntity 액세스한 Google 직원이 소속된 법인입니다(예: Google LLC).
principalPhysicalLocationCountry 액세스가 발생한 국가의 국가 코드(ISO 3166-1 alpha-2)입니다. 위치를 확인할 수 없는 경우에는 ??이고, Google 직원이 인구가 적은 국가에 위치한 경우에는 문자 3개로 구성된 대륙 식별자가 표시됩니다.
principalJobTitle 액세스한 Google 직원의 작업 계열입니다.
product 액세스된 고객의 Google Cloud 제품입니다.
reason:detail 상세 이유입니다(예: 지원 티켓 ID).
reason:type 액세스 이유 유형입니다(예: CUSTOMER_INITIATED_SUPPORT)).
accesses:methodName 수행된 액세스 유형입니다. 예를 들면 GoogleInternal.Read입니다. methodName 필드에 표시될 수 있는 메서드에 대한 자세한 내용은 accesses: methodName 필드 값을 참조하세요.
accesses:resourceName 액세스된 리소스 이름입니다.
accessApprovals 액세스를 승인한 액세스 승인 요청의 리소스 이름이 포함됩니다. 이러한 요청에는 제외지원되는 서비스가 적용됩니다.

이 필드는 액세스된 리소스에 액세스 승인이 사용 설정된 경우에만 채워집니다. 2021년 3월 24일 이전에 게시된 액세스 투명성 로그에는 이 필드가 채워지지 않습니다.
logName 로그 위치 이름입니다.
operation:id 로그 클러스터 ID입니다.
receiveTimestamp 로깅 파이프라인이 액세스를 수신한 시간입니다.
project_id 액세스된 리소스와 연결된 프로젝트입니다.
type 액세스된 리소스 유형입니다(예: project).
eventId 단일 액세스 이벤트 근거와 연결된 고유한 이벤트 ID(예: 단일 지원 케이스)입니다. 동일한 근거에 로깅되는 모든 액세스는 동일한 event_id 값을 가집니다.
severity 로그 심각도입니다.
timestamp 로그가 작성된 시간입니다.

accesses:methodNames 필드 값

액세스 투명성 로그의 accesses:methodNames 필드에 다음 메서드가 표시될 수 있습니다.

  • 표준 메서드: 이러한 메서드는 List, Get, Create, Update, Delete입니다. 자세한 내용은 표준 메서드를 참조하세요.
  • 커스텀 메서드: 커스텀 메서드는 5개의 표준 메서드 이외의 API 메서드를 참조합니다. 일반적인 커스텀 메서드에는 Cancel, BatchGet, Move, Search, Undelete가 있습니다. 자세한 내용은 커스텀 메서드를 참조하세요.
  • GoogleInternal 메서드: 다음 GoogleInternal 메서드는 accesses:methodNames 필드에 나타날 수 있습니다.
메서드 이름 설명
GoogleInternal.Read 타당한 비즈니스 근거가 있는 고객 콘텐츠에 수행된 읽기 작업을 나타냅니다. 읽기 작업은 Google Cloud 서비스 관리를 위해 특별히 설계된 내부 API를 사용하여 수행됩니다. 이 메서드는 고객 콘텐츠를 변형하지 않습니다. IAM 권한 읽기
GoogleInternal.Write 타당한 비즈니스 근거가 있는 고객 콘텐츠에 수행된 쓰기 작업을 나타냅니다. 쓰기 작업은 Google Cloud 서비스 관리를 위해 특별히 설계된 내부 API를 사용하여 수행됩니다. 이 메서드는 고객 콘텐츠 또는 구성을 업데이트할 수 있습니다.
  • 리소스에 대한 IAM 권한 설정
  • Compute Engine 인스턴스 정지
GoogleInternal.Create 타당한 비즈니스 근거가 있는 고객 콘텐츠에 수행된 만들기 작업을 나타냅니다. 만들기 작업은 Google Cloud 서비스 관리를 위해 특별히 설계된 내부 API를 사용하여 수행됩니다. 이 메서드는 신규 고객 콘텐츠를 만듭니다.
  • Cloud Storage 버킷 만들기
  • Pub/Sub 주제 만들기
GoogleInternal.Delete Google Cloud 서비스 관리를 위해 특별히 설계된 내부 API를 사용하여 고객 콘텐츠에 수행된 삭제 작업을 나타냅니다. 이 메서드는 고객 콘텐츠 및/또는 구성을 변형합니다.
  • Cloud Storage 객체 삭제
  • BigQuery 테이블 삭제
GoogleInternal.List 타당한 비즈니스 근거가 있는 고객 콘텐츠에 수행된 나열 작업을 나타냅니다. 나열 작업은 Google Cloud 서비스 관리를 위해 특별히 설계된 내부 API를 사용하여 수행됩니다. 이 메서드는 고객 콘텐츠 또는 구성을 변형하지 않습니다.
  • 고객의 Compute Engine 인스턴스 목록
  • 고객의 Dataflow 작업 목록
GoogleInternal.SSH 타당한 비즈니스 근거가 있는 고객의 가상 머신에서 수행된 SSH 작업을 나타냅니다. SSH 액세스는 Google Cloud 서비스 관리를 위해 특별히 설계된 내부 API를 사용하여 수행됩니다. 이 메서드는 고객 콘텐츠 및 구성을 변형할 수 있습니다. Compute Engine 또는 Google Distributed Cloud 중단 시 복구하기 위한 긴급 액세스 권한입니다.
GoogleInternal.Update 타당한 비즈니스 근거가 있는 고객 콘텐츠에 수행된 수정을 나타냅니다. 업데이트 작업은 Google Cloud 서비스 관리를 위해 특별히 설계된 내부 API를 사용하여 수행됩니다. 이 메서드는 고객 콘텐츠 및/또는 구성을 변형합니다. Cloud Storage에서 HMAC 키를 업데이트합니다.
GoogleInternal.Get 타당한 비즈니스 근거가 있는 고객 콘텐츠에 수행된 가져오기 작업을 나타냅니다. 가져오기 작업은 Google Cloud 서비스 관리를 위해 특별히 설계된 내부 API를 사용하여 수행됩니다. 이 메서드는 고객 콘텐츠 또는 구성을 변형하지 않습니다.
  • 리소스의 IAM 정책 검색
  • 고객의 Dataflow 작업 검색
GoogleInternal.Query 타당한 비즈니스 근거가 있는 고객 콘텐츠에 수행된 쿼리 작업을 나타냅니다. 쿼리 작업은 Google Cloud 서비스 관리를 위해 특별히 설계된 내부 API를 사용하여 수행됩니다. 이 메서드는 고객 콘텐츠 또는 구성을 변형하지 않습니다.
  • BigQuery 쿼리 실행
  • 고객 콘텐츠에 대한 AI Platform 디버깅 콘솔 조회

GoogleInternal 액세스는 정당하고 감사 가능한 액세스를 위해 승인된 직원으로 엄격하게 제한됩니다. 메서드가 있다고 해서 모든 역할에 대한 가용성을 나타내지는 않습니다. 프로젝트 또는 조직의 관리 액세스에 대한 향상된 제어를 원하는 조직은 액세스 승인을 활성화하여 액세스 세부정보에 따라 액세스 승인 또는 거부를 사용 설정할 수 있습니다. 예를 들어 액세스 승인 사용자는 Customer Support 역할을 가진 Google 직원이 수행한 요청에 대해 CUSTOMER_INITIATED_SUPPORT 근거가 있는 요청만 허용하도록 선택할 수 있습니다. 자세한 내용은 액세스 승인 개요를 참조하세요.

이벤트가 엄격한 긴급 액세스 기준을 충족하는 경우 액세스 승인에서 auto approved 상태로 긴급 액세스를 로깅할 수 있습니다. 액세스 투명성 및 액세스 승인은 긴급 액세스 시나리오에 대비한 중단 없는 로깅을 포함하도록 특별히 설계되었습니다.

워크로드에 대한 더 많은 데이터 보안 제어가 필요한 경우 Assured Workloads를 사용하는 것이 좋습니다. Assured Workloads 프로젝트는 데이터 상주, 주권 제어, Compute Engine의 컨피덴셜 컴퓨팅과 같은 기능에 대한 액세스와 같은 향상된 기능을 제공합니다. 외부 관리 암호화 키에 키 액세스 근거를 활용합니다.

정당성 이유 코드

이유 설명
CUSTOMER_INITIATED_SUPPORT 고객이 시작한 지원(예: 'Case Number: ####')
GOOGLE_INITIATED_SERVICE

시스템 관리 및 문제해결을 위해 Google에서 시작한 액세스를 참조합니다. Google 직원은 다음과 같은 이유로 이러한 유형의 액세스를 허용할 수 있습니다.

  • 복잡한 지원 요청 또는 조사에 필요한 기술적인 디버깅을 수행하기 위해
  • 스토리지 오류 또는 데이터 손상과 같은 기술 문제를 해결하기 위해
THIRD_PARTY_DATA_REQUEST Google에서 고객의 데이터에 액세스하도록 요구하는 고객의 법적 절차에 대한 응답을 포함한 법적 요청 또는 법적 절차에 대한 응답으로 Google에서 시작한 액세스입니다.
GOOGLE_INITIATED_REVIEW 보안, 사기, 악용, 규정 준수 목적으로 Google이 시작한 액세스로, 다음이 포함됩니다.
  • 고객 계정 및 데이터의 안전과 보안 보장
  • 계정 보안에 영향을 미칠 수 있는 이벤트로 인해 데이터가 영향을 받았는지 여부 확인(예: 멀웨어 감염)
  • 고객이 Google 서비스 약관을 준수하면서 Google 서비스를 사용하고 있는지 확인
  • 다른 사용자와 고객의 불만사항이나 기타 악성 활동 조짐이 있는지 조사
  • Google 서비스가 관련 규정 체제에 맞게 사용되고 있는지 확인(예: 자금세탁방지 규정)
GOOGLE_RESPONSE_TO_PRODUCTION_ALERT

시스템 안정성을 유지하기 위해 Google에서 시작한 액세스 권한을 참조합니다. Google 직원은 다음과 같은 이유로 이러한 유형의 액세스를 허용할 수 있습니다.

  • 의심되는 서비스 중단이 고객에게 영향을 미치지 않는지 조사하고 확인합니다.
  • 서비스 중단 및 시스템 장애 시 백업 및 복구를 보장합니다.

액세스 투명성 로그 모니터링

Cloud Monitoring API를 사용하여 액세스 투명성 로그를 모니터링할 수 있습니다. 시작하려면 Cloud Monitoring 문서를 참조하세요.

로그 기반 측정항목을 설정한 후 알림 정책을 설정하면 이러한 로그를 통해 발생한 문제를 신속하게 확인할 수 있습니다. 예를 들어 Google 직원의 콘텐츠 액세스를 캡처하는 로그 기반 측정항목을 만든 후 Monitoring에서 알림 정책을 만들어 특정 기간 동안의 액세스 수가 지정된 기준점을 초과되는지 확인할 수 있습니다.

다음 단계