보안, 개인정보 보호, 규정 준수

이 아키텍처 프레임워크 섹션에서는 보안 제어와 개인정보 보호 접근 방식을 계획하고 Google Cloud 규정 준수 관련 작업을 수행하는 방법을 설명합니다.

전체 프레임워크는 다음 문서 시리즈로 구성됩니다.

전략

다음과 같은 전략을 통해 보안, 개인정보 보호, 규정 준수를 달성하세요.

ID 및 승인 제어를 통해 최소 권한을 구현하세요. 중앙 집중식 ID 관리를 사용하여 최소 권한 원칙을 구현하고 적절한 승인 수준과 액세스 정책을 설정할 수 있습니다.

레이어로 구성된 보안 접근 방식을 빌드하세요. 심층 방어 방식을 적용하여 애플리케이션 및 인프라의 각 수준에서 보안을 구현합니다. 각 제품의 기능을 사용하여 액세스를 제한합니다. 암호화를 사용합니다.

민감한 작업의 배포를 자동화하세요. 배포 및 기타 관리 작업을 자동화하여 작업 스트림에서 수동 작업을 최소화합니다.

보안 모니터링을 구현하세요. 자동화된 도구를 사용하여 애플리케이션과 인프라를 모니터링합니다. 지속적 통합 및 지속적 배포(CI/CD) 파이프라인에서 자동화된 스캔을 통해 인프라의 취약점을 검사하고 보안 이슈를 감지합니다.

권장사항

보안, 개인정보 보호, 규정 준수를 달성하려면 다음 권장사항을 따르세요,.

  • 여러 제어 기능을 통한 위험 관리
  • 인증 및 승인 관리
  • 컴퓨팅 보안 제어 구현
  • 네트워크 보호
  • 데이터 보안 제어 구현
  • 애플리케이션 공급망 제어 기능으로 빌드
  • 감사 로그로 인프라 감사

여러 제어 기능을 통한 위험 관리

Google Cloud에서 리소스를 생성하고 배포하기 전에 내부 보안 요구사항과 외부 규제 요건을 충족하는 데 필요한 보안 기능을 평가해야 합니다.

다음 세 가지 제어 영역은 위험 완화에 중점을 둡니다.

  • 기술 제어는 환경을 보호하기 위해 사용하는 기능 및 기술을 의미합니다. 여기에는 방화벽 및 로깅 사용 설정과 같은 기본 클라우드 보안 제어가 포함되며, 보안 전략을 강화하거나 지원하기 위해 제3자 도구 및 공급업체도 포함될 수 있습니다.
  • 계약 보호는 Google Cloud 서비스에 대한 클라우드 공급업체의 법적 약속을 의미합니다.
  • 제3자 검증 또는 증명은 클라우드 제공업체가 규정 준수 요구사항을 충족하는지 제3자가 감사하는 것을 의미합니다. 예를 들어 Google은 ISO 27017 규정 준수에 대해 제3자의 감사를 받습니다.

새로운 퍼블릭 클라우드 서비스를 도입하는 경우 리스크를 완화하기 위해 세 가지 제어 영역을 모두 평가해야 합니다.

기술 제어

Google은 Google Cloud 고객이 데이터를 소유하고 사용 방식을 제어해야 한다는 기본 전제에서부터 시작합니다. 고객이 Google Cloud 시스템에 저장하고 관리하는 데이터는 해당 고객에게 Google Cloud 서비스를 제공하고 이러한 서비스가 보다 효과적으로 작동되도록 하는 용도로만 사용되며, 그 외 다른 목적으로는 사용되지 않습니다. Google은 고객 데이터에 내부자가 액세스하는 것을 방지하기 위해 강력한 내부 제어 및 감사 시스템을 갖추고 있습니다. 여기에는 고객에게 Google Cloud에서 Google 관리자 액세스에 대한 로그를 실시간으로 제공하는 것도 포함됩니다.

계약 관리

Google Cloud는 규정 준수 포트폴리오를 유지보수하고 확장하기 위해 최선을 다하고 있습니다. 데이터 처리 및 보안 약관(DPST) 문서에는 ISO 27001, 27017, 27018 인증을 유지하고 SOC 2 및 SOC 3 보고서를 12개월마다 업데이트한다는 Google의 노력이 명시되어 있습니다.

또한 DPST에서는 고객 환경에 대한 Google 지원 엔지니어의 액세스를 제한하기 위해 마련한 액세스 제어에 대해서도 간략하게 다룹니다. 여기에는 엄격한 로깅 및 승인 프로세스가 포함됩니다. DPST에는 액세스 제어 및 계약 약정에 대한 자세한 정보도 나와 있습니다.

제3자 증명

고객은 규정 준수 리소스 센터에서 Google Cloud의 현재 인증 및 증명서를 확인할 수 있습니다.

리소스

신뢰성 및 보안

인증 및 승인 관리

Google Cloud 고객은 ID 및 액세스 관리(IAM)를 사용하여 리소스 액세스 권한을 지정합니다. 관리자는 리소스 수준에 이르기까지 액세스 권한을 제한할 수 있습니다. IAM 정책은 '누가 어떤 리소스를 사용해 무엇을 할 수 있는지'를 규정합니다. IAM 정책을 올바르게 구성하면 리소스에 대한 무단 액세스를 방지하여 환경을 보호하는 데 도움이 됩니다.

보안 관리자는 적절한 권한이 있는 개인이 작업을 수행하는 데 필요한 리소스와 서비스에만 액세스할 수 있도록 보장합니다(최소 권한 원칙).

사용자의 권한은 작업을 완성하는 데 필요한 관리 권한, 그 이상도 그 이하도 아니어야 합니다. 권한 액세스를 과도하게 프로비저닝하면 내부자 위협, 잘못된 리소스 구성, 까다로운 감사 추적의 위험이 증가할 수 있습니다. 권한에 대한 프로비저닝이 부족하면 사용자가 작업을 완료하는 데 필요한 리소스에 액세스하지 못할 수 있습니다.

다양한 기술 제어 기능을 사용하면 액세스 관리 정책을 가다듬는 데 도움이 됩니다. 다음은 액세스를 제어하는 데 사용할 수 있는 주요 기능 및 서비스입니다.

적절한 역할 부여

역할이란 사용자에게 적용되는 권한의 모음입니다. 권한은 리소스에 대해 허용되는 작업을 결정하며, 일반적으로 REST 메서드에 해당합니다. 예를 들어 사용자 또는 사용자 그룹에 Compute Engine 인스턴스를 보고 수정할 수 있는 컴퓨팅 관리자 역할을 부여할 수 있습니다.

서비스 계정 사용 시기 확인

서비스 계정은 개별 최종 사용자가 아니라 애플리케이션 또는 가상 머신(VM)에 속한 특별한 Google 계정입니다. 애플리케이션은 서비스 계정을 사용하여 Google API 서비스를 호출하므로 사용자가 직접 관여하지 않습니다.

조직 정책 서비스 사용

IAM누구에 초점을 두며 이 기능을 통해 관리자는 권한을 기반으로 특정 리소스에 조치를 취할 수 있는 사용자를 승인할 수 있습니다. 조직 정책은 무엇에 초점을 두며 이 기능을 통해 관리자는 구성 방법을 결정하기 위해 특정 리소스에 제한을 설정할 수 있습니다.

Cloud 애셋 인벤토리 사용

이 서비스는 단 한번의 API 호출로 다양한 Google Cloud 리소스 및 정책에 대한 조직 전체의 인벤토리 스냅샷을 제공합니다. 그런 다음 자동화 도구는 스냅샷을 모니터링 또는 정책 시행에 사용하거나 규정 준수 감사를 위해 보관처리할 수 있습니다. 애셋 인벤토리에서는 애셋의 변경사항을 분석하는 데 사용하도록 메타데이터 기록 내보내기도 지원합니다.

Policy Intelligence 사용

추천자, 문제해결 도구, 검사기 도구는 IAM 역할 할당에 유용한 권장사항을 제공하고, 과도한 권한이 부여된 IAM 정책을 모니터링 및 방지하며, 액세스 제어 관련 문제 해결을 지원합니다.

설계 관련 질문

  • ID는 어떻게 관리하나요?
  • ID를 Google Cloud와 연계할 수 있나요?
  • 사용자 유형별로 어떤 액세스 권한이 필요한가요? 어떤 프로그래매틱 액세스 권한이 필요한가요?
  • 다양한 배포 환경(테스트, 개발, 프로덕션 등)에 따라 사용자에게 액세스 제어 역할 및 권한을 부여하고 감사하는 프로세스가 있나요?

권장사항

최소 권한

  • 기본 역할(예: roles/owner, roles/editor, roles/viewer)은 피합니다. 그 대신 가능하면 사전 정의된 역할이나 커스텀 역할을 부여하세요.
  • 다음과 같은 경우 기본 역할을 부여합니다.

    • Google Cloud 서비스가 사전 정의된 역할을 제공하지 않는 경우
    • 프로젝트와 관련하여 더 광범위한 권한을 부여하려는 경우. 개발 또는 테스트 환경에서 권한을 부여할 때 이러한 사례가 자주 발생합니다.
    • 팀원들의 권한을 세분화할 필요가 없는 소규모 팀에서 일하는 경우
  • 애플리케이션의 각 구성요소를 별도의 신뢰 경계로 취급합니다. 다양한 권한이 필요한 여러 가지 서비스가 있다면 서비스마다 별도의 서비스 계정을 생성한 다음 각 서비스 계정에 필요한 권한만 부여합니다.

  • 서비스 계정 권한으로 작업할 사용자를 제한합니다. 서비스 계정 작업자 역할을 부여받은 사용자는 서비스 계정이 액세스할 수 있는 모든 리소스에 액세스할 수 있습니다. 사용자에게 서비스 계정 행위자 역할을 부여할 때는 주의해야 합니다.

  • 모든 리소스에 부여된 정책을 확인하고 계층적 상속이 무엇인지 이해해야 합니다. 하위 리소스에 설정된 정책이 상위 리소스에 부여된 액세스를 제한하지 않습니다.

  • 필요한 최소 범위의 역할만 부여합니다. 예를 들어 사용자가 Pub/Sub 주제를 게시할 수 있는 권한만 필요로 하는 경우 사용자에게 해당 주제에 대한 게시자 역할을 부여합니다.

  • 구성원에게 소유자 역할을 부여하면 이 구성원은 IAM 정책을 수정하는 것을 포함해 거의 모든 리소스에 액세스하여 수정할 수 있는 권한을 갖게 됩니다. 이렇게 큰 권한은 잠재적인 위험성이 있습니다. 거의 전역적인 액세스가 필요할 때만 소유자 역할을 부여하세요.

  • 조직을 만들 때 도메인 내 모든 사용자에게 기본적으로 결제 계정 생성자 역할과 프로젝트 생성자 역할이 부여됩니다. 이러한 작업을 수행할 수 있는 사용자를 식별하고 다른 사용자에게서 해당 역할을 취소합니다.

  • 개별 사용자가 아닌 Google 그룹에 역할을 부여합니다. 이렇게 하면 IAM 정책을 업데이트하는 대신에 Google 그룹에서 구성원을 더 간편하게 추가하고 삭제할 수 있습니다.

  • 특정 작업을 허용하기 위해 여러 역할을 부여해야 하는 경우 Google 그룹을 만들고 해당 그룹에 역할을 부여한 다음 사용자를 추가합니다.

  • Cloud 애셋 인벤토리를 사용하는 조직의 모든 리소스를 추적합니다.

  • Policy Intelligence를 사용하여 정책 제어를 자동화하고 이를 검증하거나 문제를 해결합니다.

  • IAM 조건을 사용하여 리소스에 대한 조건부 속성 기반 액세스를 제어합니다.

  • VPC 서비스 제어로 심층 방어 방식을 구현하여 리소스에 대한 액세스를 추가로 제한합니다.

감사

  • Cloud 감사 로그를 사용하여 IAM 정책의 변경사항을 정기적으로 감사합니다.
  • Cloud Storage로 감사 로그를 내보내 로그를 장기 보관합니다.
  • 프로젝트에 대한 Cloud IAM 정책을 변경할 수 있는 권한이 있는 사람을 감사합니다.
  • 로깅 역할을 사용하여 로그에 대한 액세스를 제한합니다.
  • 로그 뷰어에 적용된 로그를 내보내는 데 사용하는 것과 동일한 액세스 정책을 Google Cloud 리소스에 적용합니다.
  • Cloud 감사 로그를 사용하여 서비스 계정 키에 대한 액세스를 정기적으로 감사합니다.

주요 서비스

IAM을 사용하면 특정 Google Cloud 리소스에 액세스하여 조치를 취할 수 있는 사용자를 승인하고 Google Cloud 클라우드 리소스를 중앙에서 관리하는 데 필요한 완전한 제어와 가시성을 얻을 수 있습니다.

컨텍스트 인식 액세스를 사용하면 사용자 ID 및 요청의 컨텍스트를 바탕으로 Google Cloud 워크로드와 웹 애플리케이션에 대한 세밀한 액세스 제어 정책을 적용할 수 있습니다. Google은 조직의 제로 트러스트 보안 모델을 지원합니다.

Cloud 애셋 인벤토리는 시계열 데이터베이스를 기반으로 인벤토리 서비스를 제공합니다. 이 데이터베이스는 애셋 메타데이터의 5주 기록을 보관합니다. 이 서비스를 이용하면 특정 타임스탬프의 모든 애셋 메타데이터를 내보내거나 특정 시간대에 이벤트 변경 내역을 내보낼 수 있습니다.

Cloud 감사 로그를 통해 Google Cloud 리소스에서 '누가, 언제, 어디서, 무엇을 했는지'를 확인할 수 있습니다.

리소스

Compute 보안 제어 구현

리소스가 네트워크에 노출되는 방식은 항상 보호하는 것이 좋습니다. 다음은 Google Kubernetes Engine(GKE)Compute Engine에서 사용할 수 있는 제어 기능입니다.

비공개 IP

조직 정책을 사용하여 프로덕션 VM에 대한 외부 IP 액세스를 사용 중지할 수 있습니다. GKE 내에 비공개 IP를 사용하는 비공개 클러스터를 배포하여 네트워크 공격 가능성을 제한할 수 있습니다. 또한 네트워크 정책을 정의하여 클러스터에서 pod 간 통신을 관리할 수도 있습니다.

Compute 인스턴스 사용량

서비스 중단 시 상당한 비용이 들 수 있으므로 IAM을 사용하여 인스턴스를 가동하고 액세스 제어를 수행할 수 있는 사용자를 파악해 두는 것도 중요합니다. Google Cloud에서 프로젝트에 대한 커스텀 할당량을 정의하여 이러한 활동을 제한할 수 있습니다. VPC 서비스 제어는 이 문제를 해결하는 데 도움이 될 수 있습니다. 자세한 내용은 네트워크 보안 섹션을 참조하세요.

Compute OS 이미지

Google은 정기적으로 유지보수 및 패치되는 선별된 OS 이미지를 제공합니다. 사용자 고유의 커스텀 이미지를 사용하여 Compute Engine에서 실행할 수 있지만 이 경우에도 패치, 업데이트, 유지보수 작업이 필요합니다. Google Cloud는 보안 게시판을 통해 확인된 새로운 취약점을 정기적으로 업데이트하고 기존 배포의 취약점을 해결하기 위한 구제 조치를 제공합니다.

GKE 및 Docker

App Engine은 모든 런타임에 실행할 수 있도록 Docker 컨테이너 내에서 애플리케이션 인스턴스를 유연하게 실행합니다. 또한 기본 인스턴스에 대해 SSH 액세스를 사용하도록 설정할 수도 있습니다. 단, 유효한 비즈니스 사용 사례가 없는 경우에는 이 방법을 사용하지 않는 것이 좋습니다.

GKE에 대해 Cloud 감사 로그가 사용 설정되어 있으므로 클러스터와 관련된 모든 활동을 자동으로 캡처하고 의심스러운 활동이 있는지 모니터링할 수 있습니다.

클러스터에 인프라 보안을 제공하기 위해 GKE는 IAM을 역할 기반 액세스 제어(RBAC)와 함께 사용하여 클러스터 및 네임스페이스에 대한 액세스를 관리할 수 있습니다.

Google에서 최신 패치로 클러스터 노드를 업데이트하도록 노드 자동 업그레이드를 사용 설정하는 것이 좋습니다. Google은 GKE 마스터가 정기적으로 업데이트 및 패치되도록 관리합니다. 또한 배포에 Google에서 선별한 컨테이너 최적화 이미지를 사용합니다. 이러한 이미지도 Google에서 정기적으로 패치되고 업데이트됩니다.

GKE Sandbox는 호스트 커널에서 격리와 추가 보안 레이어가 필요한 멀티 테넌트 애플리케이션을 배포하는 데 적합합니다.

런타임 보안

GKE는 런타임 보안을 위해 다양한 파트너 솔루션과 통합되어 배포를 모니터링하고 관리할 수 있는 강력한 솔루션을 제공합니다. 이러한 모든 솔루션은 Security Command Center에 통합하여 중앙의 한 곳에서 관리할 수 있도록 빌드할 수 있습니다.

호스트 보호를 위한 파트너 솔루션

Google에서 제공하는 선별된 강화 OS 이미지를 사용하는 것 외에도 다양한 Google Cloud 파트너 솔루션을 사용하여 호스트를 보호할 수 있습니다. Google Cloud에 제공되는 대부분의 파트너 솔루션은 Security Command Center와 통합되므로 여기에서 고급 위협 분석이나 런타임 보안 강화를 위해 파트너 포털로 이동할 수 있습니다. Forseti는 Security Command Center와 통합되는 또 다른 보안 솔루션으로 구성 위반을 모니터링하고 알림을 제공하도록 지원합니다.

설계 관련 질문

  • 컴퓨팅 노드의 보안은 어떻게 관리하나요?
  • 호스트 기반 보호가 필요한가요?
  • 선별된 강화 이미지를 유지보수하나요?
  • 프로덕션 환경에서 컴퓨팅 노드를 만들거나 삭제할 수 있는 사용자를 제어하려면 어떻게 해야 하나요?
  • 어떤 빈도로 컴퓨팅 생성 및 삭제를 감사하나요?
  • 샌드박스 환경의 배포에서 보안 테스트를 수행하나요? 이러한 작업을 얼마나 자주 수행하고 모니터링하며 현재 버전의 배포 노드와의 호환성을 업데이트하나요?

권장사항

  • 가능하면 서비스 계정을 사용하여 VM 간 통신을 격리합니다.
  • 명시적인 요청이 없으면 조직 수준에서 외부 IP 주소를 사용 중지합니다.
  • Google에서 선별한 이미지를 사용합니다.
  • 보안 게시판에서 새로운 취약점을 추적하고 인스턴스 문제를 해결합니다.
  • GKE를 사용하는 경우 비공개 마스터 배포를 사용합니다.
  • 워크로드 아이덴티티를 사용하여 GKE 클러스터에서 Cloud API 액세스를 제어합니다.
  • GKE 노드 자동 업그레이드를 사용 설정합니다.

주요 서비스

보안 VM은 루트킷과 부트킷으로부터 보호하는 데 도움이 되는 보안 제어로 강화된 Google Cloud의 가상 머신(VM)입니다. 보안 VM을 사용하면 원격 공격, 권한 에스컬레이션, 악의적인 내부 사용자와 같은 위협으로부터 엔터프라이즈 워크로드를 보호할 수 있습니다. 보안 VM은 안전하고 신중한 부팅, Virtual Trusted Platform Module(vTPM), UEFI 펌웨어, 무결성 모니터링과 같은 고급 플랫폼 보안 기능을 사용합니다.

워크로드 아이덴티티를 사용하면 정책 위반이나 보안 침해와 관리 오버헤드의 잠재적 '영향 범위'를 줄이는 동시에 GKE 환경에서 최소 권한의 원칙을 적용할 수 있습니다.

GKE Sandbox는 GKE에서 컨테이너식 워크로드 간의 2차 방어 레이어를 제공하는 컨테이너 격리 솔루션입니다. GKE Sandbox는 I/O가 적지만 확장성은 우수한 애플리케이션용으로 빌드되었습니다. 컨테이너화된 워크로드의 경우 속도와 성능을 유지해야 하지만 신뢰할 수 없는 코드가 포함될 수도 있어 추가적인 보안이 필요합니다. 컨테이너 런타임 샌드박스인 gVisor는 애플리케이션과 호스트 커널 간을 강력하면서도 안전하게 격리합니다. gVisor를 통해 추가 무결성 검사를 제공하거나 서비스에 대한 액세스 범위를 제한할 수 있습니다. 외부 위협으로부터 보호하기 위한 컨테이너 강화 서비스는 아닙니다.

리소스

네트워크 보호

새 프로젝트를 만들면 RFC 1918 IP 주소로 기본 Google Cloud Virtual Private Cloud(VPC)를 자동으로 프로비저닝합니다. 프로덕션 배포인 경우에는 이 기본 VPC는 피하는 것이 좋습니다. 그 대신 이 VPC를 삭제하고 원하는 서브넷으로 새로운 VPC를 프로비저닝합니다. VPC를 사용하면 비공개 IP 주소를 사용할 수 있기 때문에 충돌을 방지하기 위해서는 연결된 배포와 프로젝트 전체에서 네트워크 IP 주소 할당을 신중하게 설계하는 것이 좋습니다. 프로젝트에서는 여러 VPC 네트워크를 허용하지만 IAM을 효과적으로 적용하려면 이러한 네트워크를 프로젝트당 하나씩만 사용하는 것이 좋습니다.

Virtual Private Cloud는 중앙 집중식 배포, 관리, 제어를 제공합니다. 이를 통해 사용자는 단일 네트워크를 제공하고 워크로드를 여러 팀에서 관리하는 개별 프로젝트로 격리하는 강력한 프로덕션 배포를 구축할 수 있습니다. Virtual Private Cloud는 호스트와 서비스 프로젝트로 구성됩니다. 호스트 프로젝트는 면밀하게 계획된 VPC와 서브넷으로 구성된 기본 프로젝트입니다. 서비스 프로젝트는 호스트 프로젝트 서브넷에 연결되며 이를 통해 IAM을 사용하여 프로젝트 수준에서 사용자를 격리할 수 있습니다.

Cloud LoggingCloud Monitoring을 사용하면 다양한 서비스의 로그를 대규모로 수집하여 즉시 시각화할 수 있습니다. 이 기능을 외부 보안 정보 및 이벤트 관리(SIEM) 도구와 통합하면 고급 위협을 분석할 수 있습니다.

방화벽

Google Cloud의 방화벽은 높은 확장성을 가집니다. 따라서 프로젝트 수준에서 방화벽을 정의할 수 있으며 연결된 인스턴스 수준에서 평가됩니다. 방화벽 규칙을 사용하면 인그레스 및 이그레스 네트워크 트래픽을 타겟팅하는 여러 규칙을 정의할 수 있습니다. 이러한 방화벽 규칙을 적용할 수 있는 확장 가능한 접근 방식은 네트워크 태그 또는 서비스 계정에 타겟팅하는 것입니다.

방화벽 규칙을 보다 안전하게 배포하는 방법은 서비스 계정으로 방화벽 규칙을 사용하는 것입니다. 그러나 Virtual Private Cloud 배포를 사용하는 경우에는 항상 호스트 프로젝트에서 중앙 관리에 필요한 방화벽을 정의해야 합니다.

네트워크 침입 감지

많은 고객이 온프레미스에서 고급 보안 및 트래픽 검사 도구를 사용하고 있으며, 클라우드에서도 특정 애플리케이션에 동일한 도구를 사용할 수 있어야 합니다. VPC 패킷 미러링을 사용하면 기존 Virtual Private Clouds(VPC) 문제를 해결할 수 있습니다. Google Cloud 패킷 미러링을 사용하면 제3자 도구를 사용하여 규모에 맞게 네트워크 트래픽을 수집 및 검사하고 침입 감지, 애플리케이션 성능 모니터링, 보다 효과적인 보안 제어를 제공하여 Compute Engine 및 Google Kubernetes Engine(GKE)에서 실행되는 워크로드의 보안 및 규정 준수를 보장할 수 있습니다.

트래픽 관리

프로덕션 배포의 경우 엄격히 제한된 범위의 규칙에 따라 각 VPC에서 구성된 경로를 검토합니다. GKE 배포의 경우 Traffic Director를 사용하여 Envoy 관리를 확장하거나 Istio를 사용하여 트래픽 흐름을 관리할 수 있습니다.

네트워크 연결

Google Cloud 내에서 Virtual Private Cloud를 선택하거나 VPC 피어링을 사용합니다. 네트워크 태그 및 서비스 계정은 피어링된 프로젝트를 변환하지 않지만 Virtual Private Cloud는 호스트 프로젝트에서 이러한 프로젝트를 중앙화하는 데 도움을 줄 수 있습니다. Virtual Private Cloud를 사용하면 서비스 계정과 네트워크 태그를 보다 쉽게 중앙화할 수 있지만 할당량 및 제한사항을 관리하는 방법을 신중하게 계획해야 합니다. VPC 피어링에서 이러한 제어를 관리하려면 중복 작업이 수반될 수 있지만 할당량 및 제한사항을 보다 유연하게 구성할 수 있습니다.

외부에서 액세스할 경우 대역폭 요구 사항을 평가하고 Cloud VPN, Cloud Interconnect 또는 Partner Interconnect 중에서 선택합니다. 단일 VPC 또는 프로젝트를 통해 점프 포인트를 중앙화하여 네트워크 관리를 최소화할 수 있습니다.

VPC 서비스 제어는 IAM과 별개로 Google Cloud 서비스의 보안을 더욱 강화합니다. IAM은 세분화된 ID 기반 액세스 제어를 지원하지만 VPC 서비스 제어는 경계 간 데이터 이그레스 제어를 포함한 보다 광범위한 컨텍스트 기반 경계 보안을 지원합니다. 심층 방어를 위해 VPC 서비스 제어와 IAM을 모두 사용하는 것이 좋습니다.

기본 제공 도구

Security Command Center는 Event Threat Detection, Google Cloud Armor 로그, Security Health Analytics (SHA)와 같은 인프라의 보안을 분석하는 데 도움을 주는 여러 감지기를 제공합니다. 워크로드에 필요한 서비스를 사용 설정하고 필요한 데이터만 모니터링하고 분석합니다.

Network Intelligence Center에서는 네트워크 토폴로지와 아키텍처의 성능을 파악할 수 있습니다. 또한 네트워크 성능에 대한 자세한 정보를 확인하고 배포를 최적화하여 서비스에서 병목 현상을 제거할 수 있습니다. 네트워크 도달성은 네트워크 경로에 적용되는 방화벽 규칙 및 정책에 대한 유용한 정보를 제공합니다.

설계 관련 질문

  • 현재 네트워크 보안은 어떻게 관리하나요?
  • 경계 기반 방화벽 필터링이 있나요?
  • 애플리케이션 수준의 방화벽 필터링으로 전환할 수 있나요?
  • 네트워킹 액세스 제어는 어떻게 관리하나요?
  • 고정 IP 주소에 크게 의존하고 있나요?
  • 서비스 기반 액세스 제어로 전환할 수 있나요?
  • 네트워크 보안은 어떻게 모니터링하나요?
  • 네트워크 트래픽을 모니터링하기 위한 IDS/IPS가 있나요?
  • 프로덕션 환경에 대한 관리 액세스를 위한 네트워킹은 어떻게 관리하나요?
  • 네트워크 관리 액세스 활동을 모니터링하기 위한 감사를 자주 수행하나요?

권장사항

  • 민감한 정보에 VPC 서비스 제어를 사용하여 서비스 경계를 정의합니다.
  • 가능하면 Google Cloud 기반 방화벽 규칙으로 트래픽을 관리합니다.
  • 가능하면 더 적은 수의 광범위한 방화벽 규칙 집합을 사용합니다.
  • 보안 강화를 위해 방화벽 규칙이 있는 서비스 계정을 사용합니다.
  • 태그를 사용할 때 자동화를 사용하여 보안 정책을 모니터링합니다.
  • Security Command Center 외에 제3자 도구를 사용하여 네트워크를 안전하게 보호합니다.
  • 외부 액세스를 제한합니다.
  • VPC 기본 경로를 수정해야 하는 경우 Google API에 대한 명시적 경로를 추가합니다.
  • 동일한 서브넷에 Google API를 사용하는 인스턴스를 배포합니다.

주요 서비스

VPC 서비스 제어는 Cloud Storage와 BigQuery 같은 Google 관리 서비스의 데이터 무단 반출 위험을 완화하는 데 도움을 줍니다. VPC 서비스 제어를 사용하면 Google 관리형 서비스의 리소스 주위에 보안 경계를 구성하고 경계를 넘는 데이터 이동을 제어할 수 있습니다.

Traffic Director는 서비스 메시를 위한 Google Cloud의 완전 관리형 트래픽 제어 영역입니다. Traffic Director를 사용하면 여러 리전의 클러스터와 VM 인스턴스 간에 글로벌 부하 분산을 배포하고, 서비스 프록시에서 상태 확인을 오프로드하고, 정교한 트래픽 제어 정책을 구성할 수 있습니다. Traffic Director는 공개 표준 API(xDS v2)를 사용하여 데이터 영역의 서비스 프록시와 통신하므로 독점적 솔루션에 종속될 염려 없이 원하는 서비스 메시 제어 영역을 사용할 수 있습니다.

Security Command Center는 Google Cloud의 리소스와 보안 상태에 대한 가시성을 제공합니다. Security Command Center에서는 위협을 쉽게 예방 및 감지하고 위협에 대응할 수 있습니다. 또한 중앙 집중식 대시보드에서 가상 머신, 네트워크, 애플리케이션, 스토리지 버킷의 잘못된 구성을 식별하여 비즈니스 피해 또는 손실을 입지 않도록 조치를 취할 수 있습니다. 내장형 기능으로 사용자의 Cloud Logging 보안 로그에서 의심스러운 활동을 신속하게 식별하고 보안 침해된 가상 머신을 표시할 수 있습니다. 실행 가능한 권고사항을 따르거나 로그를 SIEM으로 내보내 추가 조사를 진행하여 위협에 대응할 수 있습니다.

Event Threat Detection은 다양한 유형의 로그를 자동으로 검사해 Google Cloud 환경에 의심스러운 활동이 있는지 확인해 줍니다. 업계 최고의 위협 인텔리전스를 사용하면 멀웨어, 암호화폐 채굴, Google Cloud 리소스 무단 액세스, DDoS 공격, SSH 무작위 공격 등 위험도가 높고 많은 비용이 드는 위협을 빠르게 감지할 수 있습니다. 보안팀에서 많은 양의 로그 데이터에서 중요한 데이터만 추출하여 고위험 이슈를 빠르게 식별하고 구제 조치를 마련하는 데 집중할 수 있습니다.

Istio는 동일한 방법으로 마이크로서비스의 연결, 관리, 보호를 지원하는 개방형 서비스 메시입니다. Istio에서는 마이크로서비스의 코드를 변경할 필요 없이 서비스 간 트래픽 흐름 관리, 액세스 정책 적용, 원격 분석 데이터 집계가 가능합니다. Google Kubernetes Engine의 Istio는 GKE용 부가기능으로, Istio 서비스 메시로 생성 및 실행해야 하는 모든 구성요소가 포함된 클러스터를 신속하게 생성할 수 있습니다.

패킷 미러링을 사용하면 네트워크 트래픽을 미러링하고 이를 IDS(Intrusion Detection Solution)와 같은 제3자 보안 솔루션으로 전송하여 위협을 사전에 감지하고 침입에 대응할 수 있습니다. PCI 11.4와 같은 규제 요건 및 규정 준수 요구사항을 지원하므로 침입 탐지 솔루션이 필요합니다.

리소스

데이터 보안 제어 구현

암호화, 스토리지, 데이터베이스의 세 가지 영역을 기준으로 데이터 보안 제어를 구현할 수 있습니다.

암호화

Google Cloud는 고객의 요구를 충족하기 위해 연속적인 암호화 키 관리 옵션을 제공합니다. 스토리지, 컴퓨팅, 빅데이터 워크로드 등 그 용도가 무엇이든 키 생성, 보관, 순환을 위한 요건에 가장 적합한 솔루션을 찾을 수 있습니다. 암호화를 보다 광범위한 데이터 보안 전략의 일부분으로 사용합니다.

기본 암호화: Google Cloud는 고객이 아무런 조치를 취하지 않아도 미사용 상태로 보관 중인 고객 데이터를 기본으로 암호화합니다. 봉투 암호화 작동 원리에 대한 자세한 내용은 Google Cloud의 저장 데이터 암호화를 참조하세요.

커스텀 암호화: Google Cloud에서는 Cloud Key Management Service(Cloud KMS)에 키 암호화 키를 저장하는 동안 봉투 암호화를 사용할 수 있습니다. Google Cloud는 필요한 경우 Cloud 하드웨어 보안 모듈(HSM)도 제공합니다. 개별 키의 사용자 수준에서 Cloud KMS/HSM과 함께 IAM 권한을 사용하면 액세스 및 암호화 프로세스를 관리하는 데 도움이 됩니다. 관리 활동 및 키 사용 로그를 보려면 Cloud 감사 로그를 사용하세요. 데이터를 보호하려면 Monitoring을 사용해 로그를 모니터링하여 키가 적절하게 사용되도록 하세요.

스토리지

Cloud Storage객체 버전 관리 기능을 제공합니다. 이 기능은 상태를 유지보수해야 하는 객체에 사용 설정하는 것이 좋습니다. 버전 관리를 사용하면 추가 스토리지 비용이 발생하므로 민감한 객체의 경우 신중하게 균형을 맞춰야 합니다.

객체 수명 주기 관리를 사용해 오래된 객체를 보관처리하거나 스토리지 클래스로 다운그레이드하여 비용을 줄일 수 있습니다. 이러한 작업에는 스토리지 클래스 변경 및 데이터 액세스와 관련된 비용이 발생할 수 있으므로 세심한 계획이 필요합니다.

버킷 잠금을 사용하는 보관 정책을 통해 규정 준수 및 소송자료 보존 조치를 위해 버킷의 객체를 보관할 기간을 지정할 수 있습니다. 특정 보관 정책으로 버킷을 잠그면 만료일 전에 버킷을 삭제할 수 없습니다.

액세스 제어

IAM 권한은 버킷에 대한 액세스 권한과 버킷의 객체에 대한 일괄 액세스 권한을 부여합니다. IAM 권한으로 프로젝트와 객체를 광범위하게 제어할 수 있지만 개별 객체를 세부적으로 제어할 수는 없습니다.

액세스 제어 목록(ACL)은 사용자에게 개별 버킷이나 객체에 대한 읽기 또는 쓰기 액세스 권한을 부여합니다. 대부분의 경우 ACL 대신 IAM 권한을 사용하는 것이 좋습니다. 개별 객체의 세부적인 제어가 필요한 경우에만 ACL을 사용하세요.

서명된 URL(쿼리 문자열 인증)은 사용자가 생성하는 URL을 통해 객체에 대해 제한된 시간 동안의 읽기 또는 쓰기 액세스 권한을 제공합니다. URL이 공유된 사람은 누구나 Google 계정이 있는지 여부에 관계없이 지정된 기간 동안 객체에 액세스 할 수 있습니다.

서명된 URL은 제한된 기간에만 비공개 객체에 대한 액세스를 위임하려는 경우에도 유용합니다.

서명된 정책 문서는 버킷에 업로드할 수 있는 항목을 지정합니다. 정책 문서를 통해 크기, 콘텐츠 유형, 서명된 URL 이외의 기타 업로드 문자를 더 세부적으로 제어할 수 있습니다. 또한 웹사이트 소유자는 정책 문서를 사용하여 방문자가 Cloud Storage에 파일을 업로드하도록 허용할 수 있습니다.

Cloud Storage 암호화를 사용하면 암호화 메커니즘을 제어할 수 있습니다. Cloud Storage는 데이터를 디스크에 쓰기 전에 서버 측에서 항상 암호화를 수행합니다. 다음 방법 중 하나를 사용하여 서버 측 암호화를 제어할 수 있습니다.

  • 고객 관리 암호화 키(CMEK). Cloud KMS를 사용하여 암호화 키를 생성 및 관리할 수 있습니다. 이러한 키는 표준 Cloud Storage 암호화에 더해지는 추가 암호화 레이어로 작동합니다.

  • 고객 제공 암호화 키(CSEK). 자체 암호화 키를 만들고 관리할 수 있습니다. 이러한 키는 표준 Cloud Storage 암호화에 대한 추가 암호화 레이어입니다.

Cloud KMS의 키는 Google에서 복제하여 제공할 수 있습니다. CSEK의 보안 및 가용성에 대한 책임은 사용자에게 있습니다. 따라서 신중한 결정을 내려야 합니다. 또한 언제든지 클라이언트 측 암호화를 수행하고 암호화된 데이터를 Cloud Storage에 저장하도록 선택할 수 있습니다. 이 데이터는 서버 측 암호화로 암호화됩니다.

영구 디스크는 자동으로 암호화되지만 자체 키를 제공하거나 관리하도록 선택할 수 있습니다. 이러한 키는 Cloud KMS 또는 Cloud HSM에 저장하거나 온프레미스 기기에서 제공할 수 있습니다. 고객 제공 키는 인스턴스 템플릿이나 Google 인프라에 저장되지 않습니다. 따라서 키를 분실하면 복구할 수 없습니다.

기본적으로 영구 디스크 스냅샷은 영구 디스크의 위치와 가장 가까운 멀티 리전에 저장되지만 리전 위치를 선택할 수도 있습니다. 스냅샷은 손쉽게 공유되므로 새로운 리전의 프로젝트 내에 새로운 머신을 복원할 수 있습니다. 이를 다른 프로젝트와 공유하려면 커스텀 이미지를 만들어야 합니다.

비용 관리. 캐시 관리 메타데이터를 사용하여 자주 액세스하는 객체를 분석하고 Cloud CDN을 사용하여 고정 공개 콘텐츠를 캐싱합니다.

설계 관련 질문

암호화

  • 암호화 키 설정에 사용할 수 있는 프로세스가 있나요?
  • 키의 수명 주기를 어떻게 관리하나요?
  • 암호화 키에 대한 액세스 제어를 어떻게 관리하나요?
  • 어떤 빈도로 키에 대한 액세스를 감사하나요?

스토리지

  • 스토리지를 어떻게 사용할 계획인가요? 지연 시간, IOP, 가용성 중 본인에게 중요한 요소는 무엇인가요?
  • 민감한 정보에 대한 액세스를 어떻게 저장하고 관리할 계획인가요?
  • 어떤 빈도로 데이터를 감사하고 어떤 방법으로 액세스를 제어하나요?
  • 데이터 무단 반출을 모니터링하기 위한 시스템이 있나요? 알림은 어떻게 처리하나요?

권장사항

암호화

  • Google 관리 키를 사용하여 키 관리 수명 주기를 단순화합니다.
  • IAM을 사용하여 Cloud KMS에 액세스할 수 있는 사용자를 제한합니다.
  • 암호화 키에 대한 액세스 제어를 자주 감사하고 불필요한 액세스는 취소합니다.

액세스 제어 및 스토리지

  • 객체 수준 액세스 제어를 사용하여 버킷 전체에 적용되는 액세스 권한을 제한합니다.
  • 민감한 정보에 객체 버전 관리를 사용 설정하면 데이터를 알려진 상태로 신속하게 복원할 수 있습니다.
  • Cloud Storage에서 객체 또는 버킷을 삭제할 수 있는 사용자에 제한을 둡니다.
  • IAM 액세스 권한을 부여할 때 최소 권한 원칙을 사용합니다.
  • 모르는 사람에게 setIamPolicy 권한을 부여하지 마세요.
  • 익명 사용자에게 권한을 부여할 때는 주의하세요.
  • Cloud Storage의 다양한 역할을 이해하고 커스텀 역할 및 권한을 사용하여 제한된 역할을 선별합니다.
  • 액세스할 수 없는 버킷과 객체를 생성하는 방식으로 권한을 설정하지 마세요.
  • 버킷의 관리 권한을 위임하세요.
  • Cloud Storage 버킷에 Bucket Policy Only가 사용 설정되었는지 확인합니다.

주요 서비스

Cloud Key Management Service로 수백만 개의 암호화 키를 유지하여 데이터 암호화의 세부적인 수준을 결정할 수 있습니다. 데이터를 암호화하는 기본 버전을 사용해 키가 정기적으로 자동 순환하도록 설정하고 단일 키 버전으로 액세스 가능한 데이터의 범위를 제한할 수 있습니다. 활성 키 버전을 원하는 만큼 유지할 수 있습니다.

리소스

데이터베이스 액세스 제어 사용

Cloud SQL을 배포하기 전에 보안 권장사항에 따라 보안 액세스를 제어하세요. 액세스 제어는 인스턴스 및 데이터베이스 레이어에서 발생합니다.

인스턴스 수준 액세스는 애플리케이션이나 클라이언트(App Engine 또는 외부에서 실행) 또는 다른 Google Cloud 서비스(예: Compute Engine)에서 Cloud SQL 인스턴스에 대한 액세스를 승인합니다.

데이터베이스 액세스는 MySQL 액세스 권한 시스템을 사용하여 어떤 MySQL 사용자가 인스턴스의 데이터에 액세스할 수 있는지 제어합니다.

가능하면 Cloud SQL 프록시를 사용하여 애플리케이션과 데이터베이스 간의 통신을 관리하세요. Cloud SQL 프록시는 Compute Engine 및 GKE 배포에도 사용할 수 있습니다.

Cloud Bigtable은 IAM을 사용하여 프로젝트 수준 및 인스턴스 수준에서 비슷한 제어를 사용합니다.

Cloud Spanner를 사용하면 프로젝트, 인스턴스, 데이터베이스 수준에서 사용자와 그룹의 액세스를 제어할 수 있습니다. 어떤 경우든 최소 권한으로 IAM을 사용하는 것이 좋습니다.

설계 관련 질문

  • 데이터베이스에 대한 액세스 권한을 부여하는 프로세스가 있나요? 어떤 빈도로 데이터베이스를 감사하나요?
  • 데이터베이스에서 민감한 정보를 검사하나요?
  • 어떤 빈도로 데이터베이스를 백업하고 스냅샷을 만드나요?
  • 암호화 키는 어떻게 관리하고 보호하나요?

권장사항

  • 데이터베이스에 대한 액세스를 제한합니다.
  • IAM 액세스 권한을 부여할 때 최소 권한 원칙을 사용합니다.
  • 모르는 사람에게 setIamPolicy 권한을 부여하지 마세요.
  • 익명 사용자에게 권한을 부여할 때는 주의하세요.
  • BigQuery 데이터 세트에 익명 또는 공개적으로 액세스할 수 있어서는 안 됩니다.

리소스

데이터 보안 구현

Cloud Data Loss Prevention(Cloud DLP)는 민감한 요소를 분류, 마스킹, 토큰화, 변환하는 도구를 제공하므로 비즈니스 또는 분석을 위해 수집, 저장 또는 사용하는 데이터를 보다 효과적으로 관리할 수 있습니다. 예를 들어 형식 보존 암호화 또는 토큰화와 같은 기능을 사용하면 결합 또는 분석에 데이터를 계속 활용하면서 민감한 원시 식별자를 난독화할 수 있습니다.

Cloud DLP 아키텍처에는 크고 작은 작업에서 간편하게 사용할 수 있는 몇 가지 기능이 포함되어 있습니다. 검사 및 익명화 처리를 위한 템플릿을 사용하면 구성을 한 번만 정의해 모든 요청에서 사용할 수 있습니다. Cloud DLP 작업 트리거 및 작업을 통해 검사 작업을 주기적으로 시작하고 작업 완료 시 Cloud Pub/Sub 알림을 생성할 수 있습니다.

유사 식별자는 부분적으로 식별 가능한 데이터의 요소 또는 조합으로, 한 사람 또는 아주 작은 그룹에 연결될 수 있습니다. Cloud DLP를 사용하면 k-익명성 및 l-다양성과 같은 통계 속성을 측정하여 데이터 개인정보 보호를 이해하고 개인정보 보호를 확대할 수 있습니다.

주요 서비스

Cloud DLP를 사용하면 민감한 정보를 보다 정확하게 이해하고 관리할 수 있습니다. 이를 통해 신용카드 번호, 이름, 주민등록번호, 미국 및 특정 국제 ID 번호, 전화번호, Google Cloud 사용자 인증 정보와 같은 민감한 정보 요소를 빠르고 확장 가능하게 분류하고 수정할 수 있습니다. Cloud DLP는 120개가 넘는 사전 정의된 감지기로 패턴, 형식, 체크섬을 확인하여 이 데이터를 분류하고 상황별 단서까지 파악합니다. 필요에 따라 마스킹, 보안 해싱, 토큰화, 버케팅, 형식을 보존하는 암호화와 같은 기술을 사용하여 데이터를 수정할 수 있습니다.

공급망 보안 제어를 통한 앱 빌드

자동화된 도구가 없으면 애플리케이션 환경의 배포, 업데이트, 배치 적용이 점점 더 복잡해지므로 보안 요구사항을 일관되게 적용하기가 어렵습니다. CI/CD 파이프라인을 빌드하면 이러한 문제 중 대다수가 해결됩니다. 자세한 내용은 운영 우수성을 참조하세요.

자동화된 파이프라인은 수동 오류를 제거하고 표준화된 개발 피드백 루프를 제공하며 빠른 제품 반복을 지원합니다. 따라서 이러한 파이프라인을 보호하는 것이 중요합니다. 공격자가 파이프라인을 손상시킬 경우 전체 스택에 영향을 미칠 수 있습니다. 따라서 배포에서 코드를 푸시하기 전에 이러한 파이프라인에 대한 액세스 권한을 최소 권한으로 보호하고 승인 절차를 마련하는 것이 좋습니다.

Cloud Source RepositoriesContainer Registry 서비스는 버전 제어 기능을 제공하므로 워크로드 전반에서 일관된 배포를 식별, 보호, 패치, 유지보수하는 데 도움이 됩니다.

컨테이너 보안

컨테이너 분석은 컨테이너 배포 전에 취약점을 스캔하여 문제를 해결할 수 있게 해줍니다. 컨테이너 분석은 최신 취약점을 식별하고 패치를 적용하거나 업데이트하는 데 도움이 될 수 있는 스캔된 이미지의 메타데이터를 저장합니다.

Binary Authorization은 하나 이상의 고유한 증명으로 컨테이너를 서명하는 데 도움이 됩니다. 이러한 증명을 정책 정의와 함께 사용하면 런타임 중에 승인된 컨테이너를 식별, 제어, 배포할 수 있습니다. 엄격한 정책 모델과 한 명 이상의 서명자를 설정하여 컨테이너 배포를 승인하는 것이 좋습니다.

Web Security Scanner는 런타임 중에 배포된 애플리케이션의 취약점을 검사합니다. 취약점을 검사하기 위해 다양한 페이지를 탐색하는 서명된 사용자로 애플리케이션과 상호작용하도록 Web Security Scanner를 구성할 수 있습니다. 의도하지 않은 동작을 방지하려면 프로덕션을 반영하는 테스트 환경에서 스캔을 실행하는 것이 좋습니다.

여러 팀과 기능에 걸쳐 있는 복잡한 배포의 경우 점진적으로 감사 및 검증되는 자동화를 통해 변경사항을 배포합니다.

설계 관련 질문

  • 프로덕션 환경에 새로운 변경사항을 배포하고 모니터링하는 방법을 보호하기 위한 잘 정의된 프로세스(예: 카나리아 테스트, 취약점 스캔, 승인 절차)가 있나요?
  • 최신 취약점을 완화하기 위해 애플리케이션 코드에서 취약점 스캔을 수행하나요?
  • 이 스캔을 테스트하고 모니터링하기 위한 샌드박스 환경이 있나요?
  • 배포의 보안 비밀은 어떻게 관리하나요?
  • 보안 비밀을 어떻게 감사하고 순환하나요?

권장사항

  • 최소한의 구성요소와 함께 승인된 기본 이미지를 사용합니다.
  • CI/CD 프로세스의 일부로 이미지 스캔 및 분석을 사용합니다.
  • 알림 및 문제를 추적하고 패치를 자동화합니다.
  • 보안 비밀 관리를 사용합니다.
  • 애플리케이션 배포 방법을 정기적으로 감사합니다.

주요 서비스

Container Registry는 팀이 Docker 이미지를 관리하고, 취약점 분석을 수행하며, 세분화된 액세스 제어 기능으로 액세스 허용 수준을 결정할 수 있는 단일 공간입니다. 기존 CI/CD와 통합하면 완전히 자동화된 Docker 파이프라인을 설정하여 피드백을 빠르게 얻을 수 있습니다. Container Registry는 Google Cloud에서 실행되는 비공개 컨테이너 이미지 레지스트리입니다. Container Registry는 Docker 이미지 매니페스트 V2와 OCI 이미지 형식을 지원합니다.

컨테이너 분석은 Container Registry의 컨테이너 이미지에 대한 취약점 정보 및 기타 메타데이터 유형을 제공합니다. 메타데이터는 메모로 저장됩니다. 이미지와 연결된 메모의 각 인스턴스에 대한 어커런스가 작성됩니다.

Binary Authorization은 Cloud에서 실행되는 애플리케이션에 소프트웨어 공급망 보안을 제공하는 서비스입니다. Binary Authorization은 Container Registry 또는 다른 컨테이너 이미지 레지스트리에서 GKE에 배포하는 이미지에서 작동합니다. Binary Authorization을 사용하면 애플리케이션을 프로덕션 환경에 배포하기 전에 소프트웨어의 품질과 무결성을 보호하는 내부 프로세스가 성공적으로 완료되었는지 확인할 수 있습니다.

Security Command Center는 App Engine, Compute Engine, Google Kubernetes Engine 웹 애플리케이션의 보안 취약점을 확인해 줍니다. 애플리케이션을 크롤링하여 시작 URL 범위 내에 있는 모든 링크를 확인하고 최대한 많은 사용자 입력과 이벤트 핸들러 실행을 시도합니다. 교차 사이트 스크립팅(XSS), 플래시 삽입, 혼합 콘텐츠(HTTPS 내 HTTP 삽입), 구버전 및 취약 라이브러리 등의 일반적인 취약점 4가지를 자동으로 스캔하여 탐지합니다. 조기 탐지가 가능하며 거짓양성률도 낮습니다. 보안 스캔을 쉽게 설정, 실행, 예약, 관리할 수 있으며 Google Cloud 사용자에게 무료로 제공됩니다.

리소스

인프라 감사

Cloud Logging은 Google Cloud 서비스에 감사 로깅을 제공합니다. Cloud 감사 로그는 보안팀이 Google Cloud에서 감사 추적을 유지보수하는 데 도움이 됩니다. Cloud Logging은 모든 Google Cloud 서비스에 통합되므로 장기 보관 및 규정 준수 요구사항에 대한 세부정보를 로깅할 수 있습니다. 데이터 액세스 로그를 로깅하는 데 비용이 많이 들 수 있으므로 이 기능을 사용 설정하기 전에 신중하게 계획해야 합니다.

실시간 스트리밍을 통해 감사 로그를 내보내고 이를 저장하여 규정 준수 요구사항을 충족할 수 있습니다. 로그는 Cloud Storage, BigQuery, Pub/Sub로 내보냅니다. BigQuery 또는 Cloud Storage로 로그를 이동하면 비용과 장기 스토리지를 줄일 수 있습니다.

액세스 투명성 로그에는 전화로 요청 시 지원팀에서 수행한 작업, 지원 요청에 대한 하위 수준의 엔지니어링 조사 또는 서비스 중단 복구와 같은 올바른 비즈니스 목적을 위해 수행된 기타 조사 등에 대한 데이터가 포함됩니다.

설계 관련 질문

  • 감사 로그는 얼마나 오래 보관해야 하나요?
  • 어떤 감사 로그를 보관해야 하나요?
  • 감사 로그를 내보내야 하나요?
  • 내보낸 감사 로그를 어떻게 사용하나요?

권장사항

  • 감사 로그는 보고 목적으로 BigQuery로 내보냅니다.
  • 보관해야 하지만 사용하거나 처리할 필요가 없는 로그의 경우 감사 로그를 Cloud Storage로 내보냅니다.
  • 조직 수준 싱크를 사용하여 조직의 모든 로그를 캡처합니다.
  • 로깅 싱크 필터를 사용하여 내보낼 필요가 없는 로그를 제외합니다.

주요 서비스

리소스