이 시나리오는 조직의 규정 준수 요구사항을 충족하기 위해 Cloud Logging에서 Cloud Storage로 로그를 내보내는 방법을 보여줍니다. 조직은 로깅 파일을 만들고 보존하는 데 있어 여러 요구사항을 충족해야 합니다. 예를 들어 Sarbanes Oxley(SOX) 규정 준수가 중요한 경우에는 사용자, 데이터베이스, 콘솔 활동의 로그를 유지할 수 있습니다. 기본 및 구성 가능한 로그 보관 기간에 대한 자세한 내용은 클라우드 로깅 할당량 및 한도를 참조하세요.
이 시나리오에서 내보낸 로그는 사용자가 구성한 Cloud Storage 버킷으로 전달됩니다. 사용자는 상황에 맞게 권한을 부여하여 로그에 대한 액세스 권한을 제어합니다. 장기 스토리지 비용을 줄이기 위해 Cloud Storage의 객체 수명 주기 관리 기능을 사용하여 Nearline 또는 Coldline Storage 클래스로 로그를 이동하고 필수 보관 기간이 경과하면 이 로그를 삭제할 수 있습니다.
이 시나리오에서는 가상 머신(VM), 데이터베이스와 이를 지원하는 스토리지 시스템을 갖춘 Google Cloud에서 실행되는 일반적인 N등급 웹 아키텍처를 사용한다고 가정합니다. 이 환경에서는 모든 감사 로그, 가상 머신 관련 로그, 스토리지 로그, 데이터베이스 로그와 같은 로그 유형을 내보냅니다. 예시에서 로깅 필터를 조정하면 내보내는 로그 유형을 변경할 수 있습니다.
로깅 내보내기 설정
다음 다이어그램은 Cloud Storage로 로깅 내보내기를 사용할 수 있도록 설정하는 단계를 보여줍니다.
Cloud Storage에서 로깅 내보내기 버킷 설정
내보낸 로그를 호스팅하는 Cloud Storage 버킷을 설정하는 안내에 따릅니다. 기본 스토리지 클래스의 경우 멀티 리전, Nearline 또는 Coldline Storage 클래스가 필요하지 않으면 리전을 선택합니다.
Cloud Storage 버킷의 객체 수명 주기 관리 구성
이 시나리오에서는 모든 로그에 7년의 보관 요구사항이 있다고 가정합니다. 스토리지 비용을 최소화하기 위해 Cloud Storage에 객체 수명 주기 규칙을 추가하여 지정된 일수 이후에 Nearline Storage 또는 Coldline Storage로 로그를 옮기고 이 로그를 더 이상 보관하지 않아도 되면 삭제할 수 있습니다.
권장사항: Nearline 또는 Coldline으로 로그를 이동한 다음 삭제하면 로그를 유지하는 데 드는 지속적인 운영 비용을 관리할 수 있습니다.
안내에 따라 수명 주기 규칙을 만들 수 있습니다. 다음 스크린샷은 60일 후 스토리지 클래스를 Nearline으로 변경하고, 120일 후 Coldline으로 변경한 다음 2555일(약 7년) 후에 로그를 삭제하는 단계식 규칙을 보여줍니다.
모든 서비스에 감사 로깅 사용 설정
BigQuery를 제외한 데이터 액세스 감사 로그는 기본적으로 사용 중지되어 있습니다. 모든 감사 로그를 사용 설정하려면 감사 정책 문서에 나와 있는 구성으로 Identity and Access Management(IAM) 정책을 업데이트하는 방법 안내를 따르세요. 그 단계는 다음과 같습니다.
- 현재 IAM 정책을 파일로 다운로드
- 감사 로그 정책 JSON 또는 YAML 객체를 현재 정책 파일에 추가
- 변경된 정책 파일로 Google Cloud 프로젝트 업데이트
다음은 모든 서비스의 모든 감사 로그를 사용 설정하는 JSON 객체의 예시입니다.
"auditConfigs": [
{
"service": "allServices",
"auditLogConfigs": [
{ "logType": "ADMIN_READ" },
{ "logType": "DATA_READ" },
{ "logType": "DATA_WRITE" },
]
},
]
로깅 내보내기 구성
집계 내보내기 또는 로그 내보내기를 설정한 후에는 로깅 필터를 감사 로그, 가상 머신 관련 로그, 스토리지 로그, 데이터베이스 로그를 내보내도록 세부적으로 조정해야 합니다. 아래의 로깅 필터는 관리자 활동 및 데이터 액세스 감사 로그와 특정 리소스 유형의 로그를 포함합니다.
logName:"/logs/cloudaudit.googleapis.com" OR resource.type:gce OR resource.type=gcs_bucket OR resource.type=cloudsql_database OR resource.type=bigquery_resource
Google Cloud CLI에서 gcloud logging sinks create 명령어 또는 organizations.sinks.create API 호출을 사용하여 적절한 필터로 싱크를 만듭니다. 아래의 gcloud 예시 명령어는 조직에 gcp_logging_sink_gcs라는 싱크를 만듭니다. 이 싱크에는 모든 하위 프로젝트가 포함되며 개별 감사 로그를 선택하는 필터링을 지정합니다.
gcloud logging sinks create gcp_logging_sink_gcs \
storage.googleapis.com/gcp-logging-export-000100011000 \
--log-filter='logName: "/logs/cloudaudit.googleapis.com" OR \
resource.type:\"gce\" OR \
resource.type=\"gcs_bucket\" OR \
resource.type=\"cloudsql_database\" OR \
resource.type=\"bigquery_resource\"' \
--include-children \
--organization=324989855333
명령어 출력은 다음과 비슷합니다.
Created [https://logging.googleapis.com/v2/organizations/324989855333/sinks/gcp_logging_sink_gcs]. Please remember to grant `serviceAccount:gcp-logging-sink-gcs@logging-o324989855333.iam.gserviceaccount.com` full-control access to the bucket. More information about sinks can be found at /logging/docs/export/configure_export
API 호출에서 반환된 serviceAccount 항목에는 gcp-logging-sink-gcs@logging-o324989855333.iam.gserviceaccount.com ID가 포함됩니다. 이 ID는 내보내기를 위해 생성된 Google Cloud 서비스 계정을 나타냅니다. 이 ID에 대상에 대한 쓰기 액세스 권한을 부여하기 전까지 이 싱크에서 수행되는 로그 항목 내보내기는 실패합니다. 자세한 내용은 다음 섹션 또는 리소스에 대한 액세스 권한 부여 문서를 참조하세요.
Cloud Storage 버킷의 IAM 정책 권한 설정
gcp-logging-sink-gcs@logging-o324989855333.iam.gserviceaccount.com 서비스 계정을 스토리지 객체 생성자 권한이 있는 gcp-logging-export-000100011000 버킷에 추가하여 서비스 계정에 버킷에 쓰기 권한을 부여합니다.
이 권한을 추가할 때까지는 싱크 내보내기가 실패합니다.
gcp-logging-export 버킷에 권한을 추가하려면 다음 단계를 따르세요.
Google Cloud Console에서 Storage 브라우저를 엽니다.
gcp-logging-export버킷을 선택합니다.정보 패널 표시를 클릭한 다음 스토리지 객체 생성자 권한을 선택합니다.
이 필터를 사용하여 로깅 내보내기를 만들면 로그 파일이 구성된 프로젝트의 Cloud Storage 버킷을 채우기 시작합니다.
권장사항: 필요에 따라 최소한의 권한 정책을 구현할 수 있습니다. 특정 Google Cloud 사용자 계정, Google 그룹스, Google Cloud 서비스 계정을 기반으로 버킷 권한을 구성합니다. IAM 권한을 사용하여 Cloud Storage 버킷에 대한 액세스 권한과 버킷의 객체에 대한 일괄 액세스 권한을 부여합니다.
예시 권한 집합으로 다음을 수행할 수 있습니다.
- Cloud Storage 버킷 권한에서 중요하지 않은 모든 사용자를 삭제합니다.
- Cloud Storage 관리자에게 전체 제어 권한을 추가합니다.
- 내보내기 사용자에게 로깅 내보내기 파일에 쓸 수 있는 권한을 부여합니다.
- 다른 개별 사용자에게 Google Cloud 로깅 내보내기에 대한 보기 액세스 권한을 부여합니다.
Google Cloud Console, gsutil 명령줄 도구 또는 IAM API를 통해 버킷의 IAM 권한을 직접 업데이트할 수 있습니다. 다음 예시는 Google Cloud Console의 Cloud Storage 버킷에 연결된 권한 및 스크린샷의 샘플 세트를 보여줍니다.
역할: 스토리지 관리자
- IAM 설명: Cloud Storage 리소스 전체 제어
- 사용: Cloud Storage에 저장된 콘텐츠를 수정할 수 있는 액세스 권한을 부여하지 않고 Cloud Storage 리소스의 관리자인 사용자에게 액세스 권한을 부여하려면 이 역할을 사용합니다.
계정 예시:
storage-admin@example.com
역할: 스토리지 객체 관리자
- IAM 설명: Cloud Storage 객체 전체 제어
- 사용: Cloud Storage 리소스 구성을 수정할 수 있는 액세스 권한을 부여하지 않고 Cloud Storage 파일 객체의 관리자인 사용자에게 전체 액세스 권한을 부여하려면 이 역할을 사용합니다.
계정 예시:
storage-object-admin@example.com: user1@example.com, user2@example.com
역할: 스토리지 객체 뷰어
- IAM 설명: Cloud Storage 객체에 대한 읽기 액세스 권한
- 사용: 사용자의 Google Cloud 로그에 읽기 전용 액세스 권한을 부여하려면 이 역할을 사용합니다.
계정 예시:
storage-viewer@example.com: user3@example.com
권장사항: Google 작업공간 또는 소비자 Google 그룹스를 사용하는 경우 스토리지 객체 뷰어 권한이 있는 gcp-logging-export-viewers@example.com과 같은 Google 그룹을 추가할 수 있습니다. 그러면 사용자 보기 권한이 변경될 때마다 Cloud Storage 버킷 권한을 수정하지 않고 gcp-logging-export-viewers@example.com 그룹에 사용자를 추가하거나 삭제할 수 있습니다.
내보낸 로그 사용
위와 같은 필터를 사용하여 로깅 내보내기를 만들면 로그 파일이 구성된 프로젝트의 Cloud Storage 버킷을 채우기 시작합니다.
각 로그는 버킷에 별도의 폴더를 만들며 이 폴더는 날짜를 기반으로 한 계층 구조로 분류됩니다. Google Cloud Console, gsutil 명령줄 도구 또는 IAM API를 통해 로그에 액세스할 수 있습니다.
다음 스크린샷은 Google Cloud Console의 예시 폴더 구조를 보여줍니다.
각 로그 파일은 textPayload, protoPayload, jsonPayload 로그 항목 형식을 따르는 JSON 데이터로 구성됩니다. 시간이 지나면서 Cloud Storage 버킷의 로그 파일은 Cloud Storage 수명 주기 프로세스의 영향을 받습니다. 이 프로세스는 먼저 로그를 Nearline Storage로 이동한 다음 Coldline Storage로 이동하고 최종적으로 구성에 따라 이 로그를 삭제합니다.
외부 액세스 권한 부여
특정 사용자에게 내보낸 로그에 대한 액세스 권한(예: 보안 분석가, DevOps팀, 감사관)을 부여할 수 있습니다.
로그 위치 전략
Cloud Storage의 로그에 대한 액세스 권한을 부여하는 몇 가지 옵션은 다음과 같습니다.
공유할 로그의 복사본을 만듭니다.
개별 로그 파일 또는 로그 파일 집합의 복사본을 수동으로 또는 프로그래매틱 방식으로 만들고 별도의 Cloud Storage 버킷에 이 복사본을 배치합니다. 그런 다음 별도의 버킷 권한을 사용하여 특정 사용자와 로그를 적절히 공유합니다.
장점: 복사된 데이터에만 노출되는 데이터의 양을 제한할 수 있습니다.
단점: 개별 데이터 세트 및 권한을 만들고 공유하고 관리해야 하므로 비용이 높아질 수 있습니다.
모든 로그에 대한 읽기 전용 액세스 권한을 부여합니다.
Cloud Storage 로깅 내보내기 버킷에 대한 뷰어 권한을 수동으로 또는 프로그래매틱 방식으로 설정합니다. 그러면 모든 로그 내보내기에 대한 액세스 권한이 부여됩니다.
장점: 액세스 권한 부여가 쉽습니다.
단점: 특정 로그 파일이 아닌 모든 로그에 대한 액세스 권한을 부여해야 합니다.
사용자 액세스 제어 전략
Cloud Storage 버킷 권한을 사용하여 로깅 내보내기 Cloud Storage 버킷을 특정 Google 계정 또는 Google 그룹스와 공유할 수 있습니다.
Google 그룹을 사용합니다.
로깅 내보내기 Cloud Storage 버킷에 대한 읽기 전용 액세스 권한이 있는
auditors@example.com과 같은 Google 그룹을 만듭니다. 그런 후 Google 그룹에 감사관을 추가하거나 삭제하여 Google 계정 목록을 관리합니다.장점: 그룹을 통해 액세스 권한을 쉽게 관리할 수 있으며 사용자 액세스 목적이 명확합니다.
단점: 그룹의 멤버십을 보지 않으면 누가 액세스 권한이 있는지 알 수 없습니다.
개별 Google 계정을 사용합니다.
액세스 권한이 필요한 사용자마다 로깅 내보내기 Cloud Storage 버킷에 대한 개별 Google 계정 액세스 권한을 부여합니다.
장점: 각 사용자를 수동으로 또는 프로그래매틱 방식으로 추가하기가 쉽습니다.
단점: 다른 뷰어와 감사 사용자를 구분할 수 없습니다.
다음 단계
- Elastic Cloud로 로그 내보내기
다른 내보내기 시나리오 살펴보기
Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기. Cloud 아키텍처 센터 살펴보기