Google Cloud Well-Architected Framework의 보안 부문에서 이 원칙을 따르면 클라우드 애플리케이션, 서비스, 플랫폼의 설계에 강력한 보안 기능, 제어, 관행을 통합하기 위한 권장사항을 확인할 수 있습니다. 아이디어 구상부터 운영까지 설계 프로세스의 모든 단계에 보안을 통합하면 보안이 더욱 효과적입니다.
원칙 개요
설계에 의한 보안에 대한 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에서 선별한 컨테이너 최적화 OS 이미지를 사용하세요. Google은 이러한 이미지를 정기적으로 패치하고 업데이트합니다.
GKE를 사용하는 경우 Google에서 최신 패치로 클러스터 노드를 업데이트하도록 노드 자동 업그레이드를 사용 설정하는 것이 좋습니다. Google은 자동으로 업데이트되고 패치되는 GKE 컨트롤 플레인을 관리합니다. 컨테이너의 공격 표면을 더욱 줄이려면 distroless 이미지를 사용하면 됩니다. Distroless 이미지는 보안에 민감한 애플리케이션, 마이크로서비스, 이미지 크기와 공격 표면을 최소화하는 것이 중요한 상황에 적합합니다.
민감한 워크로드의 경우 VM 부팅 주기 동안 악성 코드가 로드되지 않도록 하는 보안 VM을 사용하세요. 보안 VM 인스턴스는 부팅 보안을 제공하고 무결성을 모니터링하며 vTPM (Virtual Trusted Platform Module)을 사용합니다.
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 는 봉투 암호화 및 암호화 키 관리를 위한 옵션을 제공합니다. 스토리지, 컴퓨팅 또는 빅데이터 워크로드 등 어떤 용도의 키를 선택하든 키 생성, 보관, 순환을 위한 요구사항에 가장 적합한 솔루션을 찾아야 합니다. 예를 들어 Cloud Key Management Service (Cloud KMS)에서 고객 관리 암호화 키 (CMEK)를 만들 수 있습니다. CMEK는 암호화 키를 정기적으로 순환해야 하는 등의 규제 또는 규정 준수 요구사항을 충족하기 위해 소프트웨어 기반이거나 HSM으로 보호될 수 있습니다. Cloud KMS Autokey를 사용하면 CMEK의 프로비저닝 및 할당을 자동화할 수 있습니다. 또한 Cloud 외부 키 관리자 (Cloud EKM)를 사용하여 서드 파티 키 관리 시스템에서 가져온 자체 키를 사용할 수 있습니다.
전송 중인 데이터를 암호화하는 것이 좋습니다. 데이터가 Google이나 Google의 대리인이 통제하지 않는 물리적 경계 외부로 이동할 때 Google은 하나 이상의 네트워크 계층에서 전송 중인 데이터를 암호화하고 인증합니다. VPC 네트워크 내 및 피어링된 VPC 네트워크 간의 모든 VM 간 트래픽이 암호화됩니다. Cloud Interconnect 연결을 통한 트래픽 암호화에 MACsec를 사용할 수 있습니다. IPsec은 Cloud VPN 연결을 통한 트래픽에 암호화를 제공합니다. 컨테이너화된 애플리케이션의 경우 Apigee의 TLS 및 mTLS 구성 및 Cloud Service Mesh와 같은 보안 기능을 사용하여 클라우드에서 애플리케이션 간 트래픽을 보호할 수 있습니다.
기본적으로 Google Cloud 는 네트워크에서 저장 데이터와 전송 중 데이터를 암호화합니다. 하지만 메모리에서 사용되는 데이터는 기본적으로 암호화되지 않습니다. 조직에서 기밀 데이터를 처리하는 경우 애플리케이션 또는 시스템 메모리에 있는 데이터의 기밀성 및 무결성을 약화시키는 위협을 완화해야 합니다. 이러한 위협을 완화하려면 컴퓨팅 워크로드에 신뢰할 수 있는 실행 환경을 제공하는 컨피덴셜 컴퓨팅을 사용하면 됩니다. 자세한 내용은 컨피덴셜 VM 개요를 참고하세요.