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에서 선별한 컨테이너 최적화 OS 이미지를 사용하세요. Google은 이러한 이미지를 정기적으로 패치하고 업데이트합니다.
GKE를 사용하는 경우 Google에서 최신 패치로 클러스터 노드를 업데이트하도록 노드 자동 업그레이드를 사용 설정하는 것이 좋습니다. Google은 자동으로 업데이트되고 패치되는 GKE 제어 영역을 관리합니다. 컨테이너의 공격 노출 영역을 더 줄이려면 distroless 이미지를 사용하면 됩니다. Distrosless 이미지는 보안이 중요한 애플리케이션, 마이크로서비스, 이미지 크기와 공격 노출 영역을 최소화하는 것이 중요한 상황에 적합합니다.
민감한 워크로드의 경우 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 네트워크 내의 모든 VM 간 트래픽과 피어링된 VPC 네트워크 간의 모든 VM 간 트래픽이 암호화됩니다. Cloud Interconnect 연결을 통한 트래픽 암호화에 MACsec를 사용할 수 있습니다. IPsec은 Cloud VPN 연결을 통한 트래픽에 암호화를 제공합니다. Apigee의 TLS 및 mTLS 구성, 컨테이너화된 애플리케이션의 Cloud Service Mesh와 같은 보안 기능을 사용하여 클라우드에서 애플리케이션 간 트래픽을 보호할 수 있습니다.
기본적으로 Google Cloud 는 저장 데이터와 네트워크를 통한 전송 중 데이터를 암호화합니다. 하지만 데이터는 메모리에서 사용되는 동안 기본적으로 암호화되지 않습니다. 조직에서 기밀 데이터를 처리하는 경우 애플리케이션 또는 시스템 메모리에 있는 데이터의 기밀성 및 무결성을 약화시키는 위협을 완화해야 합니다. 이러한 위협을 완화하려면 컴퓨팅 워크로드에 신뢰할 수 있는 실행 환경을 제공하는 컨피덴셜 컴퓨팅을 사용하면 됩니다. 자세한 내용은 컨피덴셜 VM 개요를 참고하세요.