서버리스 아키텍처를 사용하면 서버를 프로비저닝하거나 유지관리하지 않고도 소프트웨어와 서비스를 개발할 수 있습니다. 서버리스 아키텍처를 사용하여 다양한 서비스를 위한 애플리케이션을 빌드할 수 있습니다.
이 문서에서는 DevOps 엔지니어, 보안 설계자, 애플리케이션 개발자에게 Cloud Functions(2세대)를 사용하는 서버리스 애플리케이션 보호 방법을 전문가의 의견과 함께 안내합니다. 이 문서는 다음으로 구성된 보안 청사진의 일부입니다.
- Terraform 구성 및 스크립트 집합이 포함된 GitHub 저장소
- 청사진(이 문서)으로 구현하는 아키텍처, 디자인, 보안 제어에 대한 가이드
먼저 Google Cloud 엔터프라이즈 기반 청사진을 배포하지 않고 이 청사진을 배포할 수 있지만 이 문서에서는 Google Cloud 엔터프라이즈 기반 청사진에 설명된 대로 기본적인 보안 제어 세트를 이미 구성했다고 가정합니다. 이 문서에 설명된 아키텍처는 기반에 추가 제어를 계층화하여 서버리스 애플리케이션을 보호하는 데 유용합니다.
Cloud Security Alliance(CSA)는 서버리스 애플리케이션과 관련된 주요 보안 제어를 정의하는 데 도움이 되도록 서버리스 애플리케이션에 대한 12가지 주요 위험을 게시했습니다. 이 청사진에 사용된 보안 제어는 이 문서에서 설명하는 다양한 사용 사례와 관련된 위험을 해결하기 위해 설계되었습니다.
서버리스 사용 사례
이 청사진은 다음 사용 사례를 지원합니다.
- Cloud Functions를 사용하여 서버리스 아키텍처 배포(이 문서)
- Cloud Run을 사용하여 서버리스 아키텍처 배포
Cloud Functions와 Cloud Run의 차이점은 다음과 같습니다.
- Cloud Functions는 데이터베이스의 데이터 변경 또는 Pub/Sub와 같은 메시징 시스템에서 메시지 수신과 같은 이벤트에 의해 트리거됩니다. Cloud Run은 HTTP 요청과 같은 요청에 의해 트리거됩니다.
- Cloud Functions는 지원되는 런타임 집합으로 제한됩니다. 모든 프로그래밍 언어에서 Cloud Run을 사용할 수 있습니다.
- Cloud Functions는 코드에 집중할 수 있도록 웹 서버 또는 언어 런타임을 제어하는 컨테이너 및 인프라를 관리합니다. Cloud Run은 컨테이너 구성을 제어할 수 있도록 이러한 서비스를 직접 실행할 수 있는 유연성을 제공합니다.
Cloud Run과 Cloud Functions 간의 차이점에 대한 자세한 내용은 Google Cloud 컴퓨팅 옵션 선택을 참조하세요.
아키텍처
이 청사진은 Cloud Functions가 서비스 프로젝트에 배포되고 다른 VPC 네트워크에 있는 리소스에 액세스할 수 있는 공유 VPC 아키텍처를 사용합니다.
다음 다이어그램은 대략적인 아키텍처를 보여 주며, 뒤에 나오는 예시 아키텍처에서 자세히 설명합니다.
이전 다이어그램에 표시된 아키텍처에는 다음 Google Cloud 서비스 및 기능 조합이 사용됩니다.
- Cloud Functions를 사용하면 함수를 서비스로 실행하고 사용자를 대신하여 인프라를 관리할 수 있습니다. 기본적으로 이 아키텍처는 공개 인터넷에 액세스하지 않고 내부 IP 주소만 사용하여 Cloud Functions를 배포합니다.
- 트리거 이벤트는 Cloud Functions를 트리거하는 이벤트입니다. 예시 아키텍처에 자세히 설명된 대로 이는 Cloud Storage 이벤트, 예약된 간격 또는 BigQuery의 변경사항일 수 있습니다.
- Artifact Registry는 Cloud Functions 애플리케이션의 소스 컨테이너를 저장합니다.
- 공유 VPC를 사용하면 서비스 프로젝트의 서버리스 VPC 액세스 커넥터를 호스트 프로젝트에 연결할 수 있습니다. 각 환경(프로덕션, 비프로덕션, 개발)에 대해 별도의 공유 VPC 네트워크를 배포합니다. 이 네트워킹 설계는 서로 다른 환경 간에 네트워크 격리를 제공합니다. 공유 VPC 네트워크를 사용하면 공통 네트워크의 네트워크 리소스를 중앙에서 관리하는 동시에 서비스 프로젝트의 관리 책임을 위임할 수 있습니다.
서버리스 VPC 액세스 커넥터는 서버리스 VPC 액세스를 사용하여 서버리스 애플리케이션을 VPC 네트워크에 연결합니다. 서버리스 VPC 액세스를 사용하면 서버리스 애플리케이션에서 VPC 네트워크로의 요청이 인터넷에 노출되지 않습니다. 서버리스 VPC 액세스를 사용하면 Cloud Functions가 VPC 서비스 제어를 지원하는 다른 서비스, 스토리지 시스템, 리소스와 통신할 수 있습니다.
공유 VPC 호스트 프로젝트 또는 서비스 프로젝트에서 서버리스 VPC 액세스를 구성할 수 있습니다. 기본적으로 이 청사진은 공유 VPC 호스트 프로젝트에 서버리스 VPC 액세스를 배포하여 네트워크 구성 리소스를 중앙 집중화하는 공유 VPC 모델과 일치시킵니다. 자세한 내용은 구성 방법 비교를 참조하세요.
VPC 서비스 제어는 승인, 액세스 제어 및 안전한 데이터 교환을 설정하여 Cloud Functions 서비스와 리소스를 격리하는 보안 경계를 만듭니다. 이 경계는 추가 액세스 제어 및 모니터링을 설정하여 애플리케이션과 관리형 서비스를 격리하고 Google Cloud 거버넌스를 애플리케이션에서 분리하도록 설계되었습니다. 거버넌스에는 키 관리 및 로깅이 포함됩니다.
소비자 서비스는 Cloud Functions로 작동하는 애플리케이션입니다. 소비자 서비스는 내부 서버이거나 Cloud SQL과 같은 다른 Google Cloud 서비스일 수 있습니다. 사용 사례에 따라 이 서비스는 Cloud 차세대 방화벽 뒤에 있거나 다른 서브넷, Cloud Functions와 동일한 서비스 프로젝트 또는 다른 서비스 프로젝트에 있을 수 있습니다.
보안 웹 프록시는 필요한 경우 이그레스 웹 트래픽을 보호하도록 설계되었습니다. Cloud ID 및 웹 애플리케이션을 기반으로 유연하고 세분화된 정책을 사용할 수 있습니다. 이 청사진은 Cloud Functions의 빌드 단계 중에 웹 트래픽을 이그레스하기 위해 세분화된 액세스 정책에 보안 웹 프록시를 사용합니다. 청사진은 허용된 URL 목록을 게이트웨이 보안 정책 규칙에 추가합니다.
Cloud NAT는 필요한 경우 인터넷에 대한 아웃바운드 연결을 제공합니다. Cloud NAT는 공개 IP 주소가 없는 컴퓨팅 리소스에 대해 소스 네트워크 주소 변환(SNAT)을 지원합니다. 인바운드 응답 패킷은 대상 네트워크 주소 변환(DNAT)을 사용합니다. Cloud Functions에 인터넷 액세스가 필요하지 않으면 Cloud NAT를 사용 중지할 수 있습니다. Cloud NAT는 보안 웹 프록시에 연결된 이그레스 네트워크 정책을 구현합니다.
Cloud Key Management Service(Cloud KMS)는 이 청사진에 서버리스 애플리케이션, Artifact Registry 및 Cloud Functions를 포함하여 서비스에서 사용하는 CMEK(고객 관리 암호화 키)를 저장합니다.
Secret Manager는 Cloud Functions 보안 비밀을 저장합니다. 청사진은 보안 비밀을 환경 변수로 전달하는 것보다 높은 수준의 보안을 제공하기 위해 보안 비밀을 볼륨으로 마운트합니다.
Identity and Access Management(IAM) 및 Resource Manager는 액세스를 제한하고 리소스를 격리하는 데 도움이 됩니다. 액세스 제어 및 리소스 계층 구조는 최소 권한의 원칙을 따릅니다.
Cloud Logging은 분석 및 조사 도구를 통해 Google Cloud 서비스에서 스토리지 및 검색을 위한 모든 로그를 수집합니다.
Cloud Monitoring은 Google Cloud 서비스에 대한 성능 정보 및 측정항목을 수집하고 저장합니다.
Cloud Storage를 사용하는 서버리스 애플리케이션이 있는 아키텍처 예시
다음 다이어그램은 Cloud Storage에서 특정 이벤트가 발생할 때 내부 서버에 액세스하는 서버리스 애플리케이션을 실행하는 방법을 보여줍니다.
이 아키텍처 예시는 아키텍처에 설명된 서비스 외에도 다음과 같은 Google Cloud 서비스 및 기능 조합을 사용합니다.
- Cloud Storage는 클라우드 리소스, 애플리케이션 또는 사용자가 버킷에 웹 객체를 만들 때 이벤트를 내보냅니다.
- Eventarc는 다른 리소스에서 이벤트를 라우팅합니다. Eventarc는 전송 중인 이벤트와 저장 이벤트를 암호화합니다.
- Pub/Sub는 Cloud Functions의 입력 및 트리거로 사용되는 이벤트를 큐에 추가합니다.
- Virtual Private Cloud(VPC) 방화벽 규칙은 내부 서버와 같이 리소스를 호스팅하는 서브넷으로의 데이터 흐름을 제어합니다.
- 내부 서버는 Compute Engine 또는 Google Kubernetes Engine에서 실행되며 내부 애플리케이션을 호스팅합니다. 내부 서버 예시를 사용하여 안전한 Cloud Functions를 배포하는 경우 Hello World HTML 페이지로 Apache 서버를 배포합니다. 이 예시에서는 VM 또는 컨테이너를 실행하는 내부 애플리케이션에 대한 액세스를 시뮬레이션합니다.
Cloud SQL을 사용한 아키텍처 예시
다음 다이어그램은 Cloud Scheduler에 정의된 일정한 간격으로 Cloud SQL 호스팅 서비스에 액세스하는 서버리스 애플리케이션을 실행하는 방법을 보여줍니다. 로그 수집, 데이터 집계 등을 수행해야 할 때 이 아키텍처를 사용할 수 있습니다.
이 아키텍처 예시는 아키텍처에 설명된 서비스 외에도 다음과 같은 Google Cloud 서비스 및 기능 조합을 사용합니다.
- Cloud Scheduler는 정기적으로 이벤트를 내보냅니다.
- Pub/Sub는 Cloud Functions의 입력 및 트리거로 사용되는 이벤트를 큐에 추가합니다.
- Virtual Private Cloud(VPC) 방화벽 규칙은 Cloud SQL에 저장된 회사 데이터와 같이 리소스를 호스팅하는 서브넷으로의 데이터 흐름을 제어합니다.
- Cloud SQL 인증 프록시는 Cloud SQL에 대한 액세스를 제어합니다.
- Cloud SQL은 VPC 네트워크에 피어링되고 서버리스 애플리케이션이 액세스할 수 있는 서비스를 호스팅합니다. Cloud SQL로 Cloud Functions 보호 예시를 배포하는 경우 샘플 데이터베이스를 사용하여 MySQL 데이터베이스를 배포합니다.
BigQuery 데이터 웨어하우스를 사용한 아키텍처 예시
다음 다이어그램은 BigQuery에서 이벤트가 발생할 때 트리거되는 서버리스 애플리케이션을 실행하는 방법을 보여줍니다(예: 데이터 추가 또는 테이블 생성).
이 아키텍처 예시는 아키텍처에 설명된 서비스 외에도 다음과 같은 Google Cloud 서비스 및 기능 조합을 사용합니다.
- BigQuery는 데이터 웨어하우스를 호스팅합니다. BigQuery 에서 트리거된 보안 Cloud Functions 예시를 배포할 경우 샘플 BigQuery 데이터 세트 및 테이블을 배포합니다.
- Eventarc는 BigQuery에서 특정 이벤트가 발생할 때 Cloud Functions를 트리거합니다.
조직 구조
Resource Manager를 사용하면 프로젝트, 폴더, 조직별로 리소스를 논리적으로 그룹화할 수 있습니다.
다음 다이어그램은 부트스트랩, 공통, 프로덕션, 비프로덕션(또는 테스트), 개발 등의 여러 다른 환경을 나타내는 폴더로 나눠진 리소스 계층 구조를 보여줍니다. 이 리소스 계층 구조는 엔터프라이즈 기반 청사진에 설명된 계층 구조를 기반으로 합니다.
청사진에서 지정하는 프로젝트를 Common, Production, Non-production, Dev 폴더에 배포합니다.
다음 섹션에서는 이 다이어그램에 대해 더 자세히 설명합니다.
폴더
폴더를 사용하여 프로덕션 환경 및 거버넌스 서비스를 비프로덕션 및 테스트 환경에서 격리합니다. 다음 표에서는 이 청사진에 사용되는 엔터프라이즈 기반 청사진의 폴더에 대해 설명합니다.
| 폴더 | 설명 |
|---|---|
Bootstrap
|
엔터프라이즈 기반 청사진을 배포하는 데 필요한 리소스를 포함합니다. |
Common
|
보안 프로젝트와 같은 조직의 중앙화된 서비스를 포함합니다. |
Production
|
테스트를 거쳐 고객이 사용할 준비가 된 클라우드 리소스가 있는 프로젝트를 포함합니다. 이 청사진의 Production 폴더에는 서비스 프로젝트 및 호스트 프로젝트가 포함되어 있습니다. |
Non-production
|
현재 출시용으로 테스트 및 스테이징된 클라우드 리소스가 있는 프로젝트가 포함됩니다. 이 청사진의 Non-production 폴더에는 서비스 프로젝트 및 호스트 프로젝트가 포함되어 있습니다. |
Development
|
현재 개발 중인 클라우드 리소스가 있는 프로젝트를 포함합니다. 이 청사진의 Development 폴더에는 서비스 프로젝트 및 호스트 프로젝트가 포함되어 있습니다. |
조직의 폴더 구조에 맞게 이러한 폴더 이름을 변경할 수 있지만 폴더 구조를 비슷하게 유지하는 것이 좋습니다. 자세한 내용은 조직 구조를 참조하세요. 다른 폴더 구조는 Google Cloud 랜딩 영역의 리소스 계층 구조 결정을 참조하세요.
프로젝트
프로젝트를 사용하여 환경의 리소스를 격리합니다. 다음 표에서는 조직 내에 필요한 프로젝트에 대해 설명합니다. 이러한 프로젝트 이름을 변경할 수 있지만 프로젝트 구조를 비슷하게 유지하는 것이 좋습니다.
| 프로젝트 | 설명 |
|---|---|
| 공유 VPC 호스트 프로젝트 | 이 프로젝트에는 방화벽 인그레스 규칙과 내부 IP 주소가 있는 리소스가 포함됩니다(VPC 네트워크에 연결에 설명된 대로). 공유 VPC를 사용할 때는 프로젝트 하나를 호스트 프로젝트로 지정하고 여기에 하나 이상의 다른 서비스 프로젝트를 연결합니다. Terraform 코드를 적용할 때 이 프로젝트의 이름을 지정하면 청사진이 서버리스 VPC 액세스 커넥터, Cloud NAT, Cloud Secure Web Proxy를 배포합니다. |
| 공유 VPC 서비스 프로젝트 | 이 프로젝트에는 서버리스 애플리케이션, Cloud Functions, 서버리스 VPC 액세스 커넥터가 포함됩니다. 서비스 프로젝트가 공유 VPC 네트워크에 참여할 수 있도록 서비스 프로젝트를 호스트 프로젝트에 연결합니다. Terraform 코드를 적용할 때 이 프로젝트의 이름을 지정합니다. 청사진은 Cloud SQL, Cloud Scheduler, Cloud Storage 또는 BigQuery와 같이 사용 사례에 필요한 Cloud Functions와 서비스를 배포합니다. Terraform 코드를 적용할 때 이 프로젝트의 이름을 지정하면 청사진이 Cloud KMS를 배포합니다. Cloud Functions용 서버리스 청사진에서 보안 서버리스 하네스 모듈을 사용하면 Artifact Registry도 배포됩니다. |
| 보안 프로젝트 | 이 프로젝트에는 Cloud KMS 및 Secret Manager와 같은 보안 관련 서비스가 포함됩니다.
보안 프로젝트의 기본 이름은 엔터프라이즈 기반 청사진 없이 이 청사진의 여러 인스턴스를 배포하는 경우 각 인스턴스에는 자체 보안 프로젝트가 있습니다. |
프로젝트에 역할 및 그룹 매핑
조직 내 다른 사용자 그룹에 서버리스 아키텍처를 구성하는 프로젝트에 대한 액세스 권한을 부여해야 합니다. 다음 표에서는 생성된 프로젝트에서 사용자 그룹 및 역할 할당을 위한 청사진 권장사항에 대해 설명합니다. 조직의 기존 구조에 맞게 그룹을 맞춤설정할 수 있지만 책임 구분 및 역할 할당을 비슷하게 유지하는 것이 좋습니다.
| 그룹 | 프로젝트 | 역할 |
|---|---|---|
| 서버리스 관리자 grp-gcp-serverless-admin@example.com |
서비스 프로젝트 | |
| 서버리스 보안 관리자 grp-gcp-serverless-security-admin@example.com |
보안 프로젝트 |
|
| Cloud Functions 개발자 grp-gcp-secure-cloud-run-developer@example.com |
보안 프로젝트 | |
| Cloud Functions 사용자 grp-gcp-secure-cloud-run-user@example.com |
공유 VPC 서비스 프로젝트 |
보안 제어
이 섹션에서는 서버리스 아키텍처의 보안을 유지하는 데 사용하는 Google Cloud의 보안 제어에 대해 설명합니다. 고려해야 할 중요한 보안 원칙은 다음과 같습니다.
- 최소 권한의 원칙에 따라 액세스를 보호하여 주 구성원에게 작업을 수행하는 데 필요한 권한만 부여합니다.
- 네트워크 세분화, 조직 정책, 방화벽 정책이 포함된 트러스트 경계 설계를 통해 네트워크 연결을 보호합니다.
- 각 서비스에 대한 구성을 보호합니다.
- 서버리스 워크로드를 호스팅하는 인프라의 규정 준수 또는 규제 요구사항을 식별하고 위험 수준을 할당합니다.
- 보안 운영 및 사고 관리를 위한 감사 추적을 지원하기에 충분한 모니터링 및 로깅을 구성합니다.
시스템 제어 빌드
서버리스 애플리케이션을 배포할 때 Artifact Registry를 사용하여 컨테이너 이미지 및 바이너리를 저장합니다. Artifact Registry는 CMEK를 지원하므로 자체 암호화 키를 사용하여 저장소를 암호화할 수 있습니다.
네트워크 및 방화벽 규칙
Virtual Private Cloud(VPC) 방화벽 규칙은 경계로의 데이터 흐름을 제어합니다. restricted.googleapis.com 특수 도메인 이름에서의 특정 TCP 포트 443 연결을 제외하고 모든 이그레스를 거부하는 방화벽 규칙을 만듭니다. restricted.googleapis.com 도메인을 사용하면 다음과 같은 이점이 있습니다.
- 워크로드가 Google API 및 서비스와 통신할 때 비공개 Google 액세스를 사용해서 네트워크가 공격에 노출되는 영역을 줄이는 데 도움이 됩니다.
- VPC 서비스 제어를 지원하는 서비스만 사용하도록 보장합니다.
또한 *.googleapis.com을 restricted.googleapis.com으로 변환하기 위해 DNS 레코드를 만듭니다.
자세한 내용은 비공개 Google 액세스 구성을 참조하세요.
경계 제어
아키텍처 섹션에 표시된 것처럼 서버리스 애플리케이션의 리소스를 별도의 VPC 서비스 제어 보안 경계에 배치합니다. 이 경계는 시스템 또는 서비스의 손상으로 인한 광범위한 영향을 줄이는 데 도움이 됩니다. 그러나 Cloud Build가 코드를 컨테이너 이미지로 자동으로 빌드하고 해당 이미지를 Artifact Registry로 푸시하면 Cloud Functions 빌드 프로세스에 이 보안 경계가 적용되지 않습니다. 이 시나리오에서는 서비스 경계에서 Cloud Build 서비스 계정에 대해 인그레스 규칙을 만듭니다.
액세스 정책
특정 주 구성원(사용자 또는 서비스)만 리소스 및 데이터에 액세스할 수 있도록 IAM 그룹 및 역할을 사용 설정합니다.
특정 리소스만 프로젝트에 액세스하도록 하려면 Google 조직에 대해 액세스 정책을 사용 설정합니다. 자세한 내용은 액세스 수준 속성을 참조하세요.
서비스 계정 및 액세스 제어
서비스 계정은 개별 최종 사용자가 아닌 애플리케이션 또는 컴퓨팅 워크로드에 대한 계정입니다. 최소 권한의 원칙과 업무 분리 원칙을 구현하려면 세부적인 권한과 리소스에 대한 제한된 액세스 권한이 있는 서비스 계정을 만듭니다. 서비스 계정은 다음과 같습니다.
다음 역할이 있는 Cloud Functions 서비스 계정(
cloudfunction_sa):- Compute 네트워크 뷰어(
roles/compute.networkViewer) - Eventarc 이벤트 수신자(
roles/eventarc.eventReceiver) - Cloud Run Invoker 호출자(
roles/run.invoker) - Secret Manager 보안 비밀 평가자(
roles/secretmanager.secretAccessor)
자세한 내용은 Cloud Functions가 보안 비밀에 액세스하도록 허용을 참조하세요.
Cloud Functions는 이 서비스 계정을 사용하여 특정 Pub/Sub 주제에 대한 권한만 부여하고 Cloud Storage를 사용하는 서버리스 애플리케이션이 있는 아키텍처 예시 및 BigQuery 데이터 웨어하우스를 사용한 아키텍처 예시의 Cloud Functions 컴퓨팅 리소스에서 Eventarc 이벤트 시스템을 제한합니다.
- Compute 네트워크 뷰어(
Compute 네트워크 사용자(
roles/compute.networkUser) 역할이 있는 서버리스 VPC 액세스 커넥터 계정(gcp_sa_vpcaccess)입니다.Compute 네트워크 사용자(
roles/compute.networkUser) 역할이 있는 두 번째 서버리스 VPC 액세스 커넥터 계정 (cloud_services)입니다.서버리스 VPC 액세스 커넥터에 대한 이러한 서비스 계정은 커넥터가 호스트 프로젝트에 방화벽 인그레스 및 이그레스 규칙을 생성할 수 있도록 하기 위해 필요합니다. 자세한 내용은 서비스 프로젝트의 서비스 계정에 권한 부여를 참조하세요.
Cloud Functions를 실행하는 서비스 ID(
cloudfunction_sa)에는 [서버리스 VPC 액세스 사용자(roles/vpcaccess.user)](/iam/docs/understanding-roles#vpcaccess.user)및 서비스 계정 사용자(roles/iam.serviceAccountUser) 역할이 있습니다.사용자를 대신하여 내부 Google 프로세스 실행할 Compute 네트워크 사용자(
roles/compute.networkUser) 역할이 있는 Google API의 서비스 계정(cloud_services_sa)입니다.Artifact Registry 리더(
roles/artifactregistry.reader) 역할이 있는 Cloud Functions(cloud_serverless_sa)의 서비스 ID입니다. 이 서비스 계정은 Artifact Registry 및 CMEK에 대한 액세스 권한을 제공합니다.Cloud KMS CryptoKey 복호화(roles/cloudkms.cryptoKeyDecrypter) 및 Cloud KMS CryptoKey 암호화(
roles/cloudkms.cryptoKeyEncrypter) 역할이 있는 Eventarc의 서비스 ID(eventarc_sa)입니다.CryptoKey 복호화(
roles/cloudkms.cryptoKeyDecrypter) 및 Cloud KMS CryptoKey 암호화(roles/cloudkms.cryptoKeyEncrypter) 역할이 있는 Artifact Registry(artifact_sa)의 서비스 ID입니다.
키 관리
무결성을 확인하고 저장 데이터를 보호하기 위해 Artifact Registry, Cloud Functions, Cloud Storage, Eventarc에서 CMEK를 사용합니다. CMEK를 사용하면 암호화 키를 더 세밀하게 제어할 수 있습니다. 다음 CMEK가 사용됩니다.
- 서버리스 애플리케이션의 코드를 증명하는 Artifact Registry용 소프트웨어 키
- Cloud Functions가 배포하는 컨테이너 이미지를 암호화하는 암호화 키
- 저장 중인 메시징 채널을 암호화하는 Eventarc 이벤트의 암호화 키
- Cloud Storage에서 데이터를 보호하는 데 도움이 되는 암호화 키
Terraform 구성을 적용할 때 키가 저장되는 지리적 위치를 결정하는 CMEK 위치를 지정합니다. CMEK가 리소스와 동일한 리전에 있는지 확인해야 합니다. 기본적으로 CMEK는 30일마다 순환됩니다.
보안 비밀 관리
Cloud Functions는 Secret Manager를 지원하여 서버리스 애플리케이션에 필요할 수 있는 보안 비밀을 저장합니다. 이러한 보안 비밀에는 API 키와 데이터베이스 사용자 이름 및 비밀번호가 포함될 수 있습니다. 보안 비밀을 마운트된 볼륨으로 노출하려면 기본 모듈에서 service_configs 객체 변수를 사용합니다.
엔터프라이즈 기반 청사진을 사용하여 이 청사진을 배포할 때는 Terraform 코드를 적용하기 전에 보안 비밀 프로젝트에 보안 비밀을 추가해야 합니다. 청사진은 Cloud Functions 서비스 계정에 Secret Manager 보안 비밀 평가자(roles/secretmanager.secretAccessor) 역할을 부여합니다. 자세한 내용은 보안 비밀 사용을 참조하세요.
조직 정책
이 청사진은 엔터프라이즈 기반 청사진에서 사용하는 조직 정책 제약조건에 제약조건을 추가합니다. 엔터프라이즈 기반 청사진에 사용되는 제약조건에 대한 자세한 내용은 조직 정책 제약조건을 참조하세요.
다음 표에서는 이 청사진의 Secure Cloud Functions Security 모듈에 정의된 추가 조직 정책 제약조건을 설명합니다.
| 정책 제약조건 | 설명 | 권장 값 |
|---|---|---|
허용되는 인그레스 설정(Cloud Functions)constraints/cloudfunctions.allowedIngressSettings |
내부 서비스 또는 외부 HTTP(S) 부하 분산기에서만 인그레스 트래픽을 허용합니다.
기본값은 |
ALLOW_INTERNAL_ONLY
|
VPC 커넥터 필요(Cloud Functions)constraints/cloudfunctions.requireVPCConnector |
함수를 배포할 때 서버리스 VPC 액세스 커넥터를 지정해야 합니다. 이 제약조건이 적용되면 함수에서 서버리스 VPC 액세스 커넥터를 지정해야 합니다.
기본값은 |
true
|
허용되는 VPC 커넥터 이그레스 설정(Cloud Functions)cloudfunctions.allowedVpcConnectorEgressSettings |
Cloud Functions에서 서버리스 VPC 액세스 커넥터를 사용하도록 모든 이그레스 트래픽이 필요합니다.
기본값은 |
ALL_TRAFFIC
|
운영 제어
Security Health Analytics 및 위협 감지와 같은 로깅 및 Security Command Center 프리미엄 등급 기능을 사용 설정할 수 있습니다. 이러한 제어는 다음을 수행하는 데 도움이 됩니다.
- 데이터 액세스를 모니터링합니다.
- 적절한 감사가 설정되어 있는지 확인합니다.
- 조직의 보안 작업 및 사고 관리 기능을 지원합니다.
로깅
감사 요구사항을 충족시키고 프로젝트를 확인하기 위해서는 추적하려는 서비스에 대한 데이터 로그를 사용해서 Google Cloud Observability를 구성합니다. Terraform 코드를 적용하기 전에 프로젝트에 Cloud Logging을 배포하여 청사진이 방화벽, 부하 분산기, VPC 네트워크에 대한 로깅을 구성할 수 있는지 확인합니다.
청사진을 배포한 후에는 다음을 구성하는 것이 좋습니다.
- 모든 프로젝트 간에 집계된 로그 싱크를 만듭니다.
- 로깅 싱크에 CMEK를 추가합니다.
프로젝트 내의 모든 서비스에 대해서 데이터 쓰기 및 관리 액세스에 대한 정보가 로그에 포함되는지 확인합니다. 로깅 권장사항에 대한 자세한 내용은 감지 제어를 참조하세요.
모니터링 및 알림
청사진을 배포한 후에는 보안 관련 활동이 발생했음을 보안 운영 센터(SOC)에 알릴 수 있도록 알림을 설정할 수 있습니다. 예를 들어 알림을 사용하여 IAM 역할에서 권한이 변경되었을 때 이를 보안 분석가에게 알릴 수 있습니다. Security Command Center 알림 구성에 대한 자세한 내용은 발견 항목 알림 설정을 참조하세요.
Cloud Functions 모니터링 대시보드를 사용하면 Cloud Functions의 성능과 상태를 모니터링할 수 있습니다. 문제를 식별하고 해결하는 데 사용할 수 있는 다양한 측정항목과 로그를 제공합니다. 대시보드에는 알림 및 할당량을 설정하는 기능 등 함수 성능을 개선하는 데 도움이 되는 다양한 기능이 포함되어 있습니다.
자세한 내용은 Cloud Functions 모니터링을 참조하세요.
알림을 내보내려면 다음 문서를 참조하세요.
디버깅 및 문제 해결
연결 테스트를 실행하여 Cloud Functions와 서브넷 내 리소스 간의 네트워크 구성 문제를 디버깅할 수 있습니다. 연결 테스트는 패킷의 예상 경로를 시뮬레이션하고 리소스 간 연결 분석을 포함한 연결에 대한 세부정보를 제공합니다.
연결 테스트는 Terraform 코드에서 사용 설정되지 않았으므로 별도로 설정해야 합니다. 자세한 내용은 연결 테스트 만들기 및 실행을 참조하세요.
Terraform 배포 모드
다음 표에서는 이 청사진을 배포하는 방법과 각 배포 모드에 적용되는 Terraform 모듈을 설명합니다.
| 배포 모드 | Terraform 모듈 |
|---|---|
엔터프라이즈 기반 청사진을 배포한 후 이 청사진을 배포합니다(권장). 이 옵션은 엔터프라이즈 기반 청사진에 사용되는 것과 동일한 VPC 서비스 제어 경계에 이 청사진의 리소스를 배포합니다. 자세한 내용은 보안 Cloud Functions 배포를 위해 Foundation v3.0.0을 맞춤설정하는 방법을 참조하세요. 이 옵션도 엔터프라이즈 기반 청사진을 배포할 때 만든 보안 비밀 프로젝트를 사용합니다. |
다음 Terraform 모듈을 사용합니다. |
보안 기반 청사진을 설치하지 않고 이 청사진을 설치합니다. 이 옵션을 사용하려면 VPC 서비스 제어 경계를 만들어야 합니다. |
다음 Terraform 모듈을 사용합니다.
|
총정리
이 문서에 설명된 아키텍처를 구현하려면 다음을 수행합니다.
- 청사진의 리드미를 검토하고 모든 기본 요건을 충족해야 합니다.
- 테스트 환경에서 청사진이 실제로 작동하는 것을 보려면 예시 중 하나를 배포합니다.
이 예시는 아키텍처에 설명된 아키텍처 예시와 일치합니다.
테스트 프로세스 중 다음을 고려합니다.
- Security Command Center를 사용하여 일반적인 규정 준수 요구사항에 따라 프로젝트를 스캔합니다.
- 샘플 애플리케이션을 실제 애플리케이션(예: 1)으로 바꾸고 일반적인 배포 시나리오를 통해 실행합니다.
- 엔터프라이즈의 애플리케이션 엔지니어링 및 운영팀과 협력하여 프로젝트에 대한 액세스를 테스트하고, 그들이 예상한 방식으로 솔루션과 상호 작용할 수 있는지 확인합니다.
- 환경에 청사진을 배포합니다.
다음 단계
- 기준 보안 환경에 대한 Google Cloud 엔터프라이즈 기반 청사진 검토하기
- 청사진의 세부정보를 보려면 Terraform 구성 리드미 참조하기
- Cloud Run을 사용하여 서버리스 애플리케이션을 배포하려면 Cloud Run을 사용하여 보안 서버리스 아키텍처 배포를 참조하세요.