Well-Architected Framework의 보안 부문에서 이 원칙을 따르면 클라우드 애플리케이션, 서비스, 플랫폼의 설계에 강력한 보안 기능, 제어, 관행을 통합하기 위한 권장사항을 제공합니다.Google Cloud 아이디어 구상부터 운영까지 보안은 설계 프로세스의 모든 단계에 필수적인 부분으로 포함될 때 더 효과적입니다.
원칙 개요
Google의 보안 설계 약속 개요에서 설명한 대로 기본 보안과 보안 설계는 종종 같은 의미로 사용되지만 보안 시스템을 빌드하는 고유한 접근 방식을 나타냅니다. 두 접근 방식 모두 취약점을 최소화하고 보안을 강화하는 것을 목표로 하지만 범위와 구현이 다릅니다.
- 기본 보안: 시스템의 기본 설정이 보안 모드로 설정되어 사용자와 관리자가 시스템을 보호하기 위해 조치를 취할 필요성을 최소화하는 데 중점을 둡니다. 이 접근 방식은 모든 사용자에게 기본 보안 수준을 제공하는 것을 목표로 합니다.
- 보안 설계: 시스템의 개발 수명 주기 전반에 걸쳐 보안 고려사항을 사전에 통합하는 것을 강조합니다. 이 접근 방식은 잠재적인 위협과 취약점을 미리 예측하고 위험을 완화하는 설계 선택을 하는 것입니다. 이 접근 방식에는 보안 코딩 관행 사용, 보안 검토 수행, 설계 프로세스 전반에 보안 포함이 포함됩니다. 보안 설계 접근 방식은 개발 프로세스를 안내하고 보안이 사후 고려사항이 아니라 시스템 설계의 필수적인 부분임을 보장하는 데 도움이 되는 포괄적인 철학입니다.
권장사항
클라우드 워크로드에 보안 설계 원칙을 구현하려면 다음 섹션의 권장사항을 고려하세요.
워크로드를 보호하는 데 도움이 되는 시스템 구성요소 선택
이 권장사항은 모든 중점사항과 관련이 있습니다.
효과적인 보안을 위한 기본적인 결정은 플랫폼, 솔루션 또는 서비스를 구성하는 하드웨어 및 소프트웨어 구성요소를 모두 포함한 강력한 시스템 구성요소를 선택하는 것입니다. 보안 공격 표면을 줄이고 잠재적인 손상을 제한하려면 이러한 구성요소의 배포 패턴과 구성을 신중하게 고려해야 합니다.
애플리케이션 코드에서는 취약점 클래스를 제거하기 위해 간단하고 안전하며 안정적인 라이브러리, 추상화, 애플리케이션 프레임워크를 사용하는 것이 좋습니다. 소프트웨어 라이브러리의 취약점을 검사하려면 서드 파티 도구를 사용하면 됩니다. 또한 Google에서 사용하고 보호하는 오픈소스 소프트웨어 (OSS) 패키지를 사용하여 소프트웨어 공급망의 위험을 줄이는 데 도움이 되는 Assured 오픈소스 소프트웨어를 사용할 수 있습니다.
인프라는 안전한 운영을 지원하고 보안 요구사항 및 위험 수용 수준에 부합하는 네트워킹, 스토리지, 컴퓨팅 옵션을 사용해야 합니다. 인프라 보안은 인터넷 연결 워크로드와 내부 워크로드 모두에 중요합니다.
이 권장사항을 지원하는 다른 Google 솔루션에 대한 자세한 내용은 다음 시프트-레프트 보안 구현을 참조하세요.
레이어로 구성된 보안 접근 방식 빌드
이 권장사항은 다음 중점사항과 관련이 있습니다.
- AI 및 ML 보안
- 인프라 보안
- ID 및 액세스 관리
- 데이터 보안
심층 방어 접근 방식을 적용하여 애플리케이션 및 인프라 스택의 각 레이어에서 보안을 구현하는 것이 좋습니다.
플랫폼의 각 구성요소에서 보안 기능을 사용합니다. 보안 사고 발생 시 액세스를 제한하고 잠재적인 영향의 경계 (즉, 폭발 반경)를 식별하려면 다음 단계를 따르세요.
- 가능한 경우 유연성을 수용하도록 시스템 설계를 간소화합니다.
- 각 구성요소의 보안 요구사항을 문서화합니다.
- 복원력 및 복구 요구사항을 해결하기 위해 강력한 보안 메커니즘을 통합합니다.
보안 레이어를 설계할 때는 위험 평가를 수행하여 내부 보안 요구사항과 외부 규제 요건을 충족하는 데 필요한 보안 기능을 결정합니다. 클라우드 환경에 적용되고 규제 요건과 관련된 업계 표준 위험 평가 프레임워크를 사용하는 것이 좋습니다. 예를 들어 Cloud Security Alliance (CSA)는 Cloud Controls Matrix (CCM)를 제공합니다. 위험 평가는 위험 카탈로그와 이를 완화하기 위한 해당 보안 제어를 제공합니다.
위험 평가를 수행할 때는 클라우드 제공업체와 공유 책임이 있음을 기억하세요. 따라서 클라우드 환경의 위험은 온프레미스 환경의 위험과 다릅니다. 예를 들어 온프레미스 환경에서는 하드웨어 스택의 취약점을 완화해야 합니다. 반면에 클라우드 환경에서는 클라우드 제공업체가 이러한 위험을 부담합니다. 또한 공유 책임의 경계는 각 클라우드 제공업체의 IaaS, PaaS, SaaS 서비스 간에 다르다는 점을 기억하세요.
잠재적인 위험을 식별한 후에는 기술적, 관리적, 운영적 제어는 물론 계약상의 보호 및 서드 파티 증명을 사용하는 완화 계획을 설계하고 만들어야 합니다. 또한 OWASP 애플리케이션 위협 모델링 방법과 같은 위협 모델링 방법을 사용하면 잠재적인 차이를 식별하고 차이를 해결하기 위한 조치를 제안할 수 있습니다.
강화되고 증명된 인프라 및 서비스 사용
이 권장사항은 모든 중점사항과 관련이 있습니다.
성숙한 보안 프로그램은 보안 게시판에 설명된 대로 새로운 취약점을 완화합니다. 보안 프로그램은 기존 배포의 취약점을 해결하고 VM 및 컨테이너 이미지를 보호하기 위한 조치도 제공해야 합니다. 이미지의 OS 및 애플리케이션 에 특정한 강화 가이드와 인터넷 보안 센터 (CIS)에서 제공하는 것과 같은 벤치마크를 사용할 수 있습니다.
Compute Engine VM에 커스텀 이미지를 사용하는 경우 이미지를 직접 패치해야 합니다. 또는 정기적으로 패치되는 Google 제공 선별된 OS 이미지를 사용할 수 있습니다. Compute Engine VM에서 컨테이너를 실행하려면 Google에서 선별한 Container-Optimized OS 이미지를 사용하세요. Google은 이러한 이미지를 정기적으로 패치하고 업데이트합니다.
GKE를 사용하는 경우 Google에서 최신 패치로 클러스터 노드를 업데이트하도록 노드 자동 업그레이드 를 사용 설정하는 것이 좋습니다. Google은 자동으로 업데이트되고 패치되는 GKE 제어 영역을 관리합니다. 컨테이너의 공격 표면을 더 줄이려면 사용할 수 있습니다. Distroless 이미지는 보안에 민감한 애플리케이션, 마이크로서비스, 이미지 크기와 공격 표면을 최소화하는 것이 가장 중요한 상황에 적합합니다.
민감한 워크로드의 경우 보안 VM을 사용합니다. 이는 VM 부팅 주기 동안 악성 코드가 로드되지 않도록 합니다. 보안 VM 인스턴스는 부팅 보안을 제공하고 무결성을 모니터링하며 vTPM (가상 신뢰 플랫폼 모듈)을 사용합니다.
SSH 액세스를 보호하기 위해 OS 로그인 을 사용하면 직원이 정보의 출처로 SSH 키를 활용하는 대신 Identity and Access Management (IAM) 권한 을 사용하여 VM에 연결할 수 있습니다. 따라서 조직에서 SSH 키를 관리할 필요가 없습니다. OS 로그인은 관리자의 액세스 권한을 직원 수명 주기에 연결하므로 직원이 역할을 변경하거나 조직을 떠나면 해당 사용자의 액세스 권한이 취소됩니다. OS 로그인은 Google 2단계 인증도 지원하므로 계정 탈취 공격에 대한 보안이 한층 강화됩니다.
GKE에서 애플리케이션 인스턴스는 Docker 컨테이너 내에서 실행됩니다. 정의된 위험 프로필을 사용 설정하고 직원이 컨테이너를 변경하지 못하도록 하려면 컨테이너가 스테이트리스(Stateless)이자 변경 불가능이어야 합니다. 불변성의 원칙은 직원이 컨테이너를 수정하거나 대화식으로 액세스하지 않는다는 것을 의미합니다. 컨테이너를 변경해야 하는 경우 새 이미지를 빌드하고 해당 이미지를 다시 배포합니다. 특정 디버깅 시나리오에서만 기본 컨테이너에 대한 SSH 액세스를 사용 설정합니다.
환경 전반에서 구성을 전역적으로 보호하기 위해 조직 정책 을 사용하여 클라우드 애셋의 동작에 영향을 미치는 리소스에 제약조건 또는 가드레일을 설정할 수 있습니다. 예를 들어 다음 조직 정책을 정의하고 조직 전체에 전역적으로 적용하거나 폴더 또는 프로젝트 수준에서 선택적으로 적용할 수 있습니다. Google Cloud
- VM에 대한 외부 IP 주소 할당을 사용 중지합니다.
- 리소스 생성을 특정 지리적 위치로 제한합니다.
- 서비스 계정 또는 키 생성을 사용 중지합니다.
저장 데이터 및 전송 중 데이터 암호화
이 권장사항은 다음 중점사항과 관련이 있습니다.
- 인프라 보안
- 데이터 보안
데이터 암호화는 민감한 정보를 보호하는 기본적인 제어이며 데이터 거버넌스의 핵심 부분입니다. 효과적인 데이터 보호 전략에는 액세스 제어, 데이터 세분화 및 지리적 저장 위치, 감사, 및 요구사항에 대한 신중한 평가를 기반으로 하는 암호화 구현이 포함됩니다.
기본적으로, Google Cloud 사용자가 아무런 조치를 취하지 않아도 저장된 고객 데이터를 암호화합니다, . 기본 암호화 외에도 Google Cloud 봉투 암호화 및 암호화 키 관리를 위한 옵션을 제공합니다. 스토리지, 컴퓨팅 또는 빅데이터 워크로드 등 어떤 용도의 키를 선택하든 키 생성, 보관, 순환을 위한 요구사항에 가장 적합한 솔루션을 찾아야 합니다. 예를 들어, 고객 관리 암호화 키 (CMEK) 는 Cloud Key Management Service (Cloud KMS)에서 만들 수 있습니다. CMEK는 암호화 키를 정기적으로 순환해야 하는 요구사항과 같은 규제 또는 규정 준수 요구사항을 충족하기 위해 소프트웨어 기반 또는 HSM으로 보호될 수 있습니다. Cloud KMS Autokey를 사용하면 CMEK의 프로비저닝 및 할당을 자동화할 수 있습니다. 또한 Cloud 외부 키 관리자 (Cloud EKM)를 사용하여 서드 파티 키 관리 시스템에서 가져온 자체 키를 가져올 수 있습니다.
전송 중 데이터를 암호화하는 것이 좋습니다. Google은 전송 중인 데이터를 암호화하고 인증합니다. Google이나 Google의 대리인이 제어하지 않는 물리적 경계 외부로 데이터가 이동하면 네트워크 계층 하나 이상에서 VPC 네트워크 내 및 피어링된 VPC 네트워크 간의 모든 VM 간 트래픽이 암호화됩니다. Cloud Interconnect 연결을 통한 트래픽 암호화에 MACsec 를 사용할 수 있습니다. IPsec는 Cloud VPN 연결을 통한 트래픽 암호화를 제공합니다. 컨테이너화된 애플리케이션의 경우 Apigee 및 Cloud Service Mesh에서 TLS 및 mTLS 구성과 같은 보안 기능을 사용하여 클라우드에서 애플리케이션 간 트래픽을 보호할 수 있습니다.
기본적으로 Google Cloud 네트워크 전체에서 저장 데이터와 전송 중 데이터를 암호화합니다. 하지만 기본적으로 데이터는 메모리에서 사용되는 동안 암호화되지 않습니다. 조직에서 기밀 데이터를 처리하는 경우 애플리케이션 또는 시스템 메모리에 있는 데이터의 기밀성 및 무결성을 약화시키는 위협을 완화해야 합니다. 이러한 위협을 완화하기 위해 컴퓨팅 워크로드에 신뢰할 수 있는 실행 환경을 제공하는 컨피덴셜 컴퓨팅을 사용할 수 있습니다. 자세한 내용은 컨피덴셜 VM 개요를 참조하세요.