Chef InSpec을 사용하는 자동화된 규정 준수 테스트를 위한 패턴

Last reviewed 2023-11-24 UTC

이 문서에서는 오픈소스 인프라 테스트 프레임워크인 Chef InSpec을 사용하여 Google Cloud 리소스의 정책 및 규정 준수 검사를 자동화하는 패턴을 설명합니다. 이 문서는 소프트웨어 개발 워크플로에 지속적인 규정 준수 테스트를 통합하기를 원하는 설계자와 DevOps 실무자를 대상으로 합니다.

Google Cloud의 정책 및 규정 준수

Google Cloud는 정책 및 규정 준수 요구사항을 적용하고 감사하는 데 도움이 되는 다양한 도구를 제공합니다.

서비스	설명
리소스 계층 구조	리소스 계층을 사용하여 회사의 운영 구조를 Google Cloud로 매핑하고 관련 리소스 그룹에 대해 액세스 제어 및 권한을 관리할 수 있습니다. 관련 리소스 그룹을 정의하고 그룹의 모든 리소스에 일관적으로 제어를 적용할 수 있습니다. 예를 들어 결제 카드 산업 데이터 보안 표준(PCI DSS) 규정 준수가 적용되는 모든 Google Cloud 프로젝트를 특정 폴더로 그룹화할 수 있습니다. 그런 다음 해당 폴더에 있는 모든 프로젝트에 관련 제어를 적용하면 됩니다.
조직 정책 서비스	조직 정책 서비스를 사용하여 Google Cloud 서비스의 가용성 또는 기능을 제한하는 제약조건을 정의합니다. 예를 들어 리소스 위치 제약조건을 사용하여 가상 머신과 같은 위치 기준 리소스를 만들 수 있는 리전 집합을 제한할 수 있습니다. 조직 정책 서비스는 리소스 계층과 함께 작동합니다. 계층의 여러 수준에서 조직 정책을 적용할 수 있습니다. 예를 들어 PCI 규정 준수를 따르는 프로젝트에 대해 조직 정책을 정의하고 이 정책을 PCI 폴더에 적용할 수 있습니다.
Security Command Center	Security Command Center를 사용하면 모든 Google Cloud 리소스를 중앙에서 파악할 수 있습니다. Security Command Center는 클라우드 리소스의 알려진 취약점을 자동으로 분석하고 단일 사용자 인터페이스와 데이터 플랫폼을 제공하여 보안 발견 항목을 집계 및 관리합니다. Security Health Analytics는 PCI DSS와 같은 규정 준수 표준과 인터넷 보안 센터(CIS) 벤치마크와 같은 업계 표준에 대해 모니터링 및 보고를 제공할 수 있습니다. 규정 준수 대시보드에서 보고서를 보고 이를 내보낼 수 있습니다. Security Command Center는 여러 타사 보안 소스와 통합되며 커스텀 발견 항목을 추가하고 관리할 수 있도록 API를 제공합니다. Security Command Center는 모든 보안 및 규정 준수 발견 항목에 대해 통합 인터페이스를 제공합니다.
구성 동기화	GKE Enterprise를 사용하는 경우 구성 동기화를 사용하여 Kubernetes 클러스터를 Git 저장소에 정의된 구성과 동기화된 상태로 유지할 수 있습니다. Git 저장소는 클러스터 구성 및 정책에 대한 단일 신뢰 소스로 작동합니다. 구성 동기화는 GKE Enterprise 환경을 지속적으로 감사하여 저장소에 정의된 구성을 벗어나는 클러스터를 식별하고 해결합니다.
Policy Controller	GKE Enterprise를 사용하는 경우 Kubernetes 동적 허용 컨트롤러인 정책 컨트롤러를 사용하여 클러스터에 완전히 프로그래밍 가능한 정책을 적용할 수 있습니다. 정책 컨트롤러를 사용하면 정책 요구사항을 충족하지 않는 객체가 클러스터 내에 생성되지 않도록 방지할 수 있습니다. 예를 들어 pod 보안을 시행하는 정책을 만들 수 있습니다.

Chef InSpec 소개

Chef InSpec은 사람이 읽을 수 있는 도메인별 언어(DSL)를 사용하여 규정 준수, 보안, 정책 요구사항을 지정하는 오픈소스 인프라 테스트 프레임워크입니다.

Chef InSpec을 사용하면 다음을 수행할 수 있습니다.

규정 준수 요구사항을 코드로 정의하고 해당 요구사항에 따라 클라우드 인프라를 테스트합니다.
개발팀이 프로덕션 환경에 변경사항을 푸시하기 전에 애플리케이션별 테스트를 추가하고 애플리케이션의 보안 정책 규정 준수를 평가할 수 있습니다.
CI/CD 파이프라인 및 출시 프로세스의 일환으로 규정 준수 확인을 자동화합니다.
다른 클라우드 환경에서 인프라를 테스트할 때와 동일한 방법으로 Google Cloud 인프라를 테스트합니다.

Google Cloud에서는 Chef InSpec을 시작하는 데 도움이 되는 몇 가지 리소스를 제공합니다.

Google Cloud InSpec 리소스 팩에는 Google Cloud 객체에 대한 Chef InSpec 테스트를 작성할 수 있는 기준 리소스가 포함되어 있습니다.
Google Cloud InSpec CIS 프로필에는 인터넷 보안 센터(CIS) 벤치마크를 기준으로 Google Cloud 프로젝트의 보안 상태를 평가하는 Chef InSpec 테스트 집합이 포함되어 있습니다.

Google Cloud에서 Chef InSpec을 사용하기 위한 권장사항

다음은 Chef InSpec을 사용하기 위한 일반적인 권장사항입니다.

Chef InSpec 테스트에서 발견된 위반을 수정하는 프로세스를 정의하여 도입합니다. Chef InSpec은 정책 및 규정 준수 요구사항의 위반을 표시하지만 해결은 수행하지 않습니다.
Chef InSpec 테스트 실행을 위해 사용하는 서비스 계정에 적절한 IAM 권한을 부여합니다. 예를 들어 Cloud Storage 버킷을 테스트하는 경우 서비스 계정에 적절한 Cloud Storage에 대한 IAM 역할이 있어야 합니다.
테스트 및 결과를 설명하는 형식이 지정된 보고서를 생성하도록 Chef InSpec 보고자를 구성합니다. 보고서를 저장하여 이전 레코드를 제공할 수 있습니다. 이 보고서를 다른 보안 및 규정 준수 도구의 입력으로 사용할 수도 있습니다. 예를 들어 Chef InSpec 및 Security Command Center를 통합할 수 있습니다.
관련 Chef InSpec 테스트를 프로필로 그룹화합니다. 서로 다른 사용 사례에 맞게 서로 다른 프로필을 만들 수 있습니다. 예를 들어 예약된 야간 테스트 중에 포괄적인 엔드 투 엔드 프로필을 실행할 수 있습니다. 또는 실시간 이벤트에 대한 응답으로 더 짧고 더 집중된 프로필을 실행할 수 있습니다.

Chef InSpec 테스트 작성

감사 제어를 작성하는 Ruby DSL인 Chef InSpec DSL을 사용하여 Chef InSpec 테스트를 작성합니다.

다음 코드는 Cloud Storage 버킷의 속성 검증에 대한 제어를 보여줍니다.

control 'policy_gcs_bucket' do
 title 'Cloud Storage bucket policy'
 desc 'Compliance policy checks for Cloud Storage bucket'
 impact 'medium'

 google_storage_buckets(project: project_id).bucket_names.each do |bucket|
   describe "[#{project_id}] Cloud Storage Bucket #{bucket}" do
     subject { google_storage_bucket(name: bucket) }
     its('storage_class') { should eq 'STANDARD' }
     its('location') { should be_in ['EUROPE-WEST2', 'EU'] }
     end
   end
 end

이 제어에서는 다음 정보를 지정합니다.

제어를 설명하는 메타데이터
장애 영향 또는 심각도
프로젝트에 포함된 각 Cloud Storage 버킷의 속성을 확인하는 정책 검사

Cloud Build를 사용한 Chef InSpec 테스트 실행

이 문서에 설명된 패턴은 Cloud Build 및 Chef InSpec 컨테이너 이미지를 사용하여 InSpec 테스트를 실행합니다. Cloud Build를 사용하여 컨테이너 이미지를 실행하고 빌드 단계를 하나로 연결하여 파이프라인을 만들 수 있습니다. 예를 들어 하나의 빌드 단계에서 Chef InSpec 테스트를 실행하고 이후 단계에서는 생성된 보고서를 내보내거나 분석할 수 있습니다. 하지만 Cloud Build 사용은 필수가 아닙니다. 사용되는 어떤 도구와도 Chef InSpec을 통합시킬 수 있습니다.

다음 Cloud Build 구성 파일에서는 2가지 빌드 단계가 포함된 파이프라인을 보여줍니다.

steps:
- id: 'run-inspec-cis'
  name: chef/inspec:latest
  entrypoint: '/bin/sh'
  args:
   - '-c'
   - |
     inspec exec https://github.com/GoogleCloudPlatform/inspec-gcp-cis-benchmark.git \
     --target gcp:// \
     --input gcp_project_id=${PROJECT_ID} \
     --reporter cli json:/workspace/report.json \
     --chef-license accept || touch fail.marker

- id: 'store-report'
  name: gcr.io/cloud-builders/gsutil:latest
  args:
   - cp
   - /workspace/report.json
   - gs://${_REPORTS_BUCKET}/cis-report-${BUILD_ID}.json

첫 번째 단계에서는 Google Cloud CIS 벤치마크를 실행하고 JSON 형식으로 보고서를 생성합니다. 빌드 단계에서는 chef/inspec 컨테이너 이미지를 사용하고 공개 Google Cloud CIS GitHub 저장소에서 테스트를 가져옵니다. 두 번째 빌드 단계에서는 생성된 보고서를 Cloud Storage 버킷에 복사합니다.

편의상 앞의 예시에서는 모든 컨테이너 이미지에 대해 latest 태그를 참조합니다. 빌드를 재현 가능하도록 하려면 latest와 같은 롤링 버전 대신 특정 고정 컨테이너 이미지 버전을 참조하는 것이 좋습니다.

테스트 중 하나라도 실패하면 Chef InSpec에서 오류를 반환합니다. 빌드가 실패해도 첫 번째 빌드 단계에서 fail.marker 파일을 쓰고 Chef InSpec 테스트 중 하나가 실패하더라도 두 번째 빌드 단계가 실행됩니다. 오류를 표시하기 위해 빌드를 명시적으로 실패시키려는 경우에는 최종 빌드 단계에서 fail.marker 파일을 확인하고 이 파일이 존재하는 경우 빌드를 실패시키면 됩니다.

Chef InSpec 보고서 분석

Chef InSpec 보고자를 구성하면 InSpec 테스트 및 결과를 설명하는 형식이 지정된 보고서를 생성할 수 있습니다. 보고서를 저장하여 이전 레코드를 제공할 수 있습니다. 이 보고서를 다른 보안 및 규정 준수 도구의 입력으로 사용하거나 시각화 또는 알림을 생성하는 데 사용할 수도 있습니다. 이 문서의 뒷부분에 설명된 패턴의 경우 Chef InSpec 보고서를 Cloud Storage 버킷에 저장하는 것이 좋습니다.

다음 다이어그램은 보고서를 저장하고 추가 작업을 자동으로 트리거하는 방법을 보여줍니다.

보고서에서 트리거되는 이벤트

Cloud Storage 버킷에 보고서를 추가하면 이벤트가 생성됩니다. 이 이벤트에 대한 응답으로 추가 작업 또는 보고서 분석을 트리거할 수 있습니다. 앞의 다이어그램에서는 Chef InSpec 테스트 세부정보를 BigQuery에 기록하는 Cloud 함수와 발견 항목을 Security Command Center에 추가하는 또 다른 Cloud 함수를 트리거합니다.

Chef InSpec 및 Security Command Center 통합

Security Command Center는 Google Cloud의 보안 및 위험 데이터베이스입니다. Security Command Center를 사용하면 모든 Google Cloud 리소스를 중앙에서 파악하고 클라우드 리소스를 자동으로 분석하여 알려진 취약점이 있는지 확인할 수 있습니다. 조직의 Security Command Center를 사용 설정하는 것이 좋습니다.

Chef InSpec 테스트 결과를 Security Command Center에 추가할 수 있습니다. Security Command Center는 여러 소스로부터 보안 발견 항목을 집계 및 관리하기 위한 중앙화된 데이터 플랫폼으로 작동합니다.

Security Command Center에는 Security Health Analytics가 포함됩니다. Security Health Analytics는 Google Cloud 프로젝트 및 리소스에서 일반적인 취약점을 자동으로 스캔합니다. 예를 들어 Security Health Analytics는 CIS Google Cloud Foundation 1.0 벤치마크에 대해 프로젝트를 평가하는 스캔을 실행합니다. 또한 Google Cloud InSpec CIS 프로필을 사용하여 비슷한 테스트 집합을 실행할 수 있습니다. 테스트에서 Security Health Analytics에서 수행되는 검사가 중복되지 않도록 Chef InSpec 테스트 범위를 비교해야 합니다.

Security Command Center에 Chef InSpec 발견 항목을 추가하는 방법은 몇 가지가 있습니다.

Security Command Center용 Chef Automate를 사용하여 Chef InSpec 테스트 결과를 Security Command Center로 자동 통합합니다.
Security Command Center API를 사용하여 Chef InSpec의 커스텀 소스를 만든 후 발견 항목을 만들어 Chef InSpec 테스트에서 발견된 위반을 캡처합니다.

패턴

이 섹션에서는 일상적인 작업에 Chef InSpec을 통합하기 위한 패턴을 설명합니다. 이러한 패턴을 결합하여 연속적인 규정 준수 테스트를 달성할 수 있습니다.

Chef InSpec 테스트 예약

이 패턴에서는 정해진 일정에 따라 Chef InSpec 테스트 집합을 실행합니다. 기존 프로세스를 수정하지 않고 Chef InSpec 테스트를 도입할 수 있으므로 정해진 일정을 사용하는 이 접근방식은 Chef InSpec를 시작하는 데 좋습니다.

다음 다이어그램은 일정에 따라 테스트를 실행하는 방법을 보여줍니다.

Chef InSpec 테스트를 예약합니다.

이전 다이어그램에서는 원하는 빈도로 실행되는 Cloud Scheduler 작업을 만듭니다. 작업이 실행될 때마다 Chef InSpec 테스트를 실행하고 테스트 보고서를 Cloud Storage로 출력하는 Cloud Build 파이프라인을 트리거합니다. 자세한 내용은 빌드 예약을 참조하세요.

이 패턴의 장점은 다음과 같습니다.

기존 프로세스를 최소한으로 변경하며 Chef InSpec 테스트를 도입할 수 있습니다.
인프라 및 앱을 프로비저닝하고 관리하는 데 사용하는 프로세스와 독립적으로 Chef InSpec 테스트를 사용할 수 있습니다.

이 패턴에는 다음과 같은 제한사항이 있습니다.

Chef InSpec 테스트가 인프라 프로비저닝에서 분리되어 실패한 Chef InSpec 테스트의 원인이 되는 특정 변경사항을 파악하기가 어렵습니다.
Chef InSpec 테스트는 주기적으로만 실행되므로, 규정 준수 또는 정책 위반을 식별하기 전 일부 지연이 발생할 수 있습니다.

직접적인 CI/CD 파이프라인 통합

많은 조직이 Terraform 또는 Config Connector와 같은 도구를 사용하여 인프라 프로비저닝 및 관리를 자동화합니다. 일반적으로 인프라는 CI/CD 파이프라인 중에만 생성되거나 변경됩니다. Google Cloud의 CI/CD 개념에 대한 자세한 내용은 GKE Enterprise를 사용한 최신 CI/CD를 참조하세요.

이 패턴에서는 배포 파이프라인을 실행할 때마다 인프라를 검증할 수 있도록 인프라 배포 파이프라인에서 Chef InSpec 테스트를 추가 단계로 추가합니다. 규정 준수 위반이 있으면 빌드가 실패할 수 있습니다.

다음 다이어그램은 인프라 변경사항을 포함하는 커밋에 따라 배포 파이프라인이 트리거되는 일반적인 워크플로를 보여줍니다.

Chef Inspec을 CI/CD 파이프라인과 통합합니다.

위의 다이어그램에서는 인프라 변경사항이 테스트 또는 스테이징 환경에 적용된 후 환경에 대한 Chef InSpec 테스트가 실행됩니다. 모든 Chef InSpec 검사에서 규정을 준수하는 것으로 확인되면 인프라 변경사항을 프로덕션 환경에 병합 및 적용할 수 있으며 프로덕션 환경에 대한 Chef InSpec 테스트가 다시 실행됩니다.

이 패턴의 장점은 다음과 같습니다.

Chef InSpec 테스트가 배포 프로세스에 직접 통합되어 위반을 빠르게 식별할 수 있습니다.
Chef InSpec 테스트가 검사를 통과하지 못하면 배포를 명시적으로 실패시킬 수 있습니다.

이 패턴에는 다음과 같은 제한사항이 있습니다.

Chef InSpec 테스트가 빌드 파이프라인에 직접 통합되므로 빌드 파이프라인을 관리하는 팀이 Chef InSpec 테스트를 이해해야 합니다.
Chef InSpec 테스트가 필요한 빌드가 여러 개인 경우 Chef InSpec 단계를 개별 빌드에 각각 추가해야 하므로 Chef InSpec 작업을 유지보수하고 확장하기가 더 어려울 수 있습니다.

간접적인 CI/CD 파이프라인 통합

이 패턴은 이전 패턴과 비슷하지만 배포 파이프라인 내에서 하나의 단계로 Chef InSpec 테스트를 직접 실행하는 대신 개별 파이프라인으로 Chef InSpec 테스트를 실행합니다. 이 개별 파이프라인은 배포 파이프라인으로 트리거됩니다. Chef InSpec 논리를 인프라 파이프라인과 별도로 유지할 수 있지만 배포 워크플로의 일부로 규정 준수 및 정책 테스트를 실행할 수 있습니다.

빌드 상태가 변경(예: 빌드가 생성되거나 작동 상태로 전환되거나 완료되는 경우)되면 Cloud Build에서 빌드 알림을 자동으로 생성합니다. 알림 메시지가 Pub/Sub 주제에 게시되며 이 메시지에는 개별 빌드 단계 및 인수를 포함한 빌드 관련 정보가 포함되어 있습니다.

다음 다이어그램은 빌드 알림 Pub/Sub 주제에 메시지가 게시될 때마다 자동으로 트리거되는 Cloud 함수를 만드는 방법을 보여줍니다.

Chef InSpec을 CI/CD 파이프라인과 간접적으로 통합합니다.

위 다이어그램의 함수는 빌드 알림 메시지를 검사한 후 필요할 때 Chef InSpec 파이프라인을 트리거할 수 있습니다. 예를 들어 특정 빌드 단계를 포함하는 성공적인 빌드에 대한 응답으로 Chef InSpec 파이프라인만 트리거할 수 있습니다.

이 패턴의 장점은 다음과 같습니다.

Chef InSpec 테스트는 배포 파이프라인과 무관합니다. 배포 파이프라인을 관리하는 팀이 Chef InSpec과 상호작용할 필요가 없습니다.
Chef InSpec 테스트를 중앙 집중화하면 Chef InSpec 작업을 보다 쉽게 유지보수하고 확장할 수 있습니다.
결과 및 업스트림 빌드 출력에 따라 Chef InSpec 테스트를 선택적으로 실행할 수 있습니다.

이 패턴에는 다음과 같은 제한사항이 있습니다.

Chef InSpec 테스트를 실행할지 결정하고 Chef InSpec 테스트에 매개변수를 전달하려면 빌드 알림 메시지를 파싱하고 분석하는 코드를 작성하고 유지보수해야 합니다.
Cloud Build 알림이 동일한 프로젝트의 Pub/Sub 주제에 게시됩니다. 여러 프로젝트에 빌드가 있으면 각 프로젝트에 Cloud 함수를 배포해야 합니다.

Cloud 애셋 인벤토리 알림에 대한 응답으로 Chef InSpec 테스트 트리거

Cloud 애셋 인벤토리는 모든 Google Cloud 리소스의 인벤토리를 제공합니다. Cloud 애셋 인벤토리를 사용하여 Google Cloud 프로젝트, 폴더, 조직 간에 애셋 및 애셋 메타데이터 검색, 분석, 내보내기를 수행할 수 있습니다. 또한 Cloud 애셋 인벤토리를 사용하여 변경사항에 대한 실시간 알림을 클라우드 리소스 및 정책에 전송할 수 있습니다.

다음 다이어그램은 Cloud 애셋 인벤토리의 알림을 기준으로 Chef InSpec 테스트를 실행하는 방법을 보여줍니다.

알림을 기준으로 Chef InSpec 테스트를 트리거합니다.

이전 다이어그램은 규정을 준수하지 않는 모든 새로운 또는 업데이트된 클라우드 리소스에 대해 거의 실시간에 가까운 피드백을 얻을 수 있는 방법을 보여줍니다. 특정 유형의 리소스에 대한 변경사항만 알림이 제공되도록 알림을 필터링할 수 있습니다. 이러한 알림을 사용하여 대상이 지정된 리소스 관련 Chef InSpec 테스트를 트리거할 수 있습니다. 예를 들어 Cloud Storage 버킷이 생성될 때마다 특정 테스트 집합을 실행하고 IAM 정책이 업데이트되었을 때는 다른 Chef InSpec 테스트 집합을 실행할 수 있습니다.

이 패턴의 장점은 다음과 같습니다.

Cloud 애셋에 대한 특정 변경사항에 따라 대상이 지정된 리소스 관련 Chef InSpec 테스트를 트리거할 수 있습니다.
Cloud 애셋 인벤토리 알림이 거의 실시간으로 전송되므로 규정 준수 또는 정책 위반을 빠르게 식별할 수 있습니다.
인프라를 프로비저닝하고 관리하는 데 사용하는 프로세스와 독립적으로 이 패턴을 사용할 수 있습니다. 개별 개발자 또는 CI/CD 파이프라인에 의해 인프라가 생성되거나 변경되었는지 여부에 관계없이 Chef InSpec 테스트가 실행됩니다.
Cloud 애셋 인벤토리는 전체 조직 간의 리소스 또는 선택된 폴더 또는 프로젝트의 변경사항에 대한 알림을 생성할 수 있습니다. 변경사항이 시작된 폴더 또는 프로젝트에 따라 특정 Chef InSpec 테스트 집합을 실행할 수 있습니다.
이 패턴을 다른 패턴과 함께 사용할 수 있습니다. 예를 들어 많은 조직에서 개발 또는 샌드박스 환경에 자동화된 배포를 사용하지 않습니다. 이 패턴을 사용하면 이러한 환경에서 선택된 정책 검사를 수행하고, 프로덕션 및 스테이징 환경에 대해 CI/CD 파이프라인과 통합할 수 있습니다.

이 패턴에는 다음과 같은 제한사항이 있습니다.

클라우드 애셋에 대량의 변경사항이 있는 경우 Chef InSpec 테스트가 각 변경사항에 의해 트리거될 수 있으므로 이 패턴은 실용성이 떨어질 수 있습니다.
Chef InSpec 테스트를 실행할지 결정하려면 Cloud 애셋 인벤토리 알림 메시지를 파싱하고 분석하는 코드를 작성하고 유지보수해야 합니다.

다음 단계

Cloud Shell 둘러보기를 사용하여 Cloud Shell 인스턴스에 Chef InSpec을 빠르게 설치하고 CIS 벤치마크를 기준으로 Google Cloud 프로젝트의 인프라를 스캔하기
Google Cloud 규정 준수 리소스 센터 방문하기
엔터프라이즈 기반 청사진 읽기
클라우드 아키텍처 센터에서 참조 아키텍처, 다이어그램, 권장사항 자세히 살펴보기