시프트 레프트 보안 구현

Last reviewed 2025-02-05 UTC

Google Cloud Well-Architected Framework의 보안 부문 원칙은 소프트웨어 개발 수명 주기 초기에 구현하여 보안 상황을 개선할 수 있는 실용적인 제어 기능을 식별하는 데 도움이 됩니다. 예방적 보안 가드레일과 배포 후 보안 제어를 구현하는 데 도움이 되는 권장사항을 제공합니다.

원칙 개요

시프트-레프트 보안이란 소프트웨어 개발 수명 주기 초기에 보안 관행을 채택하는 것을 의미합니다. 이 원칙의 목표는 다음과 같습니다.

  • 시스템 변경사항이 적용되기 전에 보안 결함을 방지합니다. 예방적 보안 가드레일을 구현하고 CI/CD 파이프라인에서 코드형 인프라 (IaC), 코드형 정책, 보안 검사와 같은 관행을 채택합니다. Google Cloud에서 조직 정책 서비스, 보안 강화된 GKE 클러스터와 같은 다른 플랫폼별 기능을 사용할 수도 있습니다.
  • 시스템 변경사항이 커밋된 후 보안 버그를 조기에, 빠르게, 안정적으로 감지하고 수정합니다. 코드 검토, 배포 후 취약점 스캔, 보안 테스트와 같은 관행을 채택합니다.

보안 내재화 설계와 시프트 레프트 보안 원칙은 관련이 있지만 범위가 다릅니다. 보안 내재화 원칙을 사용하면 전체 시스템을 재구성해야 하는 근본적인 설계 결함을 방지할 수 있습니다. 예를 들어 위협 모델링 연습에서 현재 설계에는 승인 정책이 포함되어 있지 않으며 승인 정책이 없으면 모든 사용자가 동일한 수준의 액세스 권한을 갖게 된다는 것을 알 수 있습니다. 왼쪽으로 이동하는 보안은 변경사항이 적용되기 전에 구현 결함 (버그 및 구성 오류)을 방지하고 배포 후 빠르고 안정적인 수정을 가능하게 합니다.

권장사항

클라우드 워크로드에 쉬프트 레프트 보안 원칙을 구현하려면 다음 섹션의 권장사항을 고려하세요.

예방적 보안 제어 도입

이 권장사항은 다음 중점사항과 관련이 있습니다.

  • ID 및 액세스 관리
  • 클라우드 거버넌스, 위험, 규정 준수

예방적 보안 제어는 클라우드에서 강력한 보안 상태를 유지하는 데 중요합니다. 이러한 제어 기능을 사용하면 위험을 사전에 완화할 수 있습니다. 구성 오류와 리소스에 대한 무단 액세스를 방지하고, 개발자가 효율적으로 작업할 수 있도록 지원하며, 업계 표준 및 내부 정책을 준수할 수 있도록 할 수 있습니다.

예방적 보안 제어는 코드형 인프라 (IaC)를 사용하여 구현하면 더 효과적입니다. IaC를 사용하면 변경사항이 배포되기 전에 예방적 보안 제어에 인프라 코드에 대한 맞춤설정된 검사를 더 많이 포함할 수 있습니다. 예방적 보안 제어는 자동화와 결합하면 CI/CD 파이프라인의 자동 검사의 일부로 실행할 수 있습니다.

다음 제품과 기능은 환경에 예방 조치를 구현하는 데 도움이 될 수 있습니다. Google Cloud

IAM을 사용하면 권한을 기반으로 특정 리소스에 조치를 취할 수 있는 사용자를 승인할 수 있습니다. 자세한 내용은 IAM으로 조직 리소스 액세스 제어를 참고하세요.

조직 정책 서비스를 사용하면 리소스에 제한을 설정하여 구성 방법을 지정할 수 있습니다. 예를 들어 조직 정책을 사용하여 다음을 수행할 수 있습니다.

조직 정책을 사용하는 것 외에도 다음 방법을 사용하여 리소스에 대한 액세스를 제한할 수 있습니다.

  • IAM을 사용한 태그: 각 리소스에 대한 액세스 권한을 정의하는 대신 태그를 리소스 집합에 할당한 후 태그 자체에 대한 액세스 정의를 설정합니다.
  • IAM 조건: 리소스에 대한 조건부 속성 기반 액세스 제어를 정의합니다.
  • 심층 방어: VPC 서비스 제어를 사용하여 리소스에 대한 액세스를 추가로 제한합니다.

리소스 관리에 대한 자세한 내용은 Google Cloud 시작 영역의 리소스 계층 구조 결정을 참고하세요.

클라우드 리소스의 프로비저닝 및 관리 자동화

이 권장사항은 다음 중점사항과 관련이 있습니다.

  • 애플리케이션 보안
  • 클라우드 거버넌스, 위험, 규정 준수

명령형 스크립팅이 아닌 선언적 IaC도 채택하면 클라우드 리소스 및 워크로드의 프로비저닝 및 관리를 자동화하는 것이 더 효과적입니다. IaC는 자체적으로 보안 도구나 관행은 아니지만 플랫폼의 보안을 개선하는 데 도움이 됩니다. IaC를 채택하면 반복 가능한 인프라를 만들고 운영팀에 정상으로 알려진 상태를 제공할 수 있습니다. IaC는 롤백, 변경사항 감사, 문제 해결의 효율성도 개선합니다.

IaC를 CI/CD 파이프라인 및 자동화와 결합하면 OPA와 같은 도구를 사용하여 코드형 정책과 같은 관행을 채택할 수도 있습니다. 시간 경과에 따른 인프라 변경사항을 감사하고 변경사항이 배포되기 전에 인프라 코드에 대한 자동 검사를 실행할 수 있습니다.

인프라 배포를 자동화하려면 Config Controller, Terraform, Jenkins, Cloud Build와 같은 도구를 사용하면 됩니다. IaC 및 자동화를 사용하여 안전한 애플리케이션 환경을 구축할 수 있도록Google Cloud 는 엔터프라이즈 기반 청사진을 제공합니다. 이 청사진은 Google의 권장사항 및 구성을 모두 따르는 Google의 독자적인 설계입니다. 이 청사진에서는 Terraform 및 Cloud Build를 사용하여 Google Cloud 토폴로지를 구성하고 배포하는 단계별 안내를 제공합니다.

엔터프라이즈 기반 청사진의 스크립트를 수정하여 Google 권장사항을 따르고 자체 보안 요구사항을 충족하는 환경을 구성할 수 있습니다. 추가 청사진을 사용하여 청사진을 구축하거나 자체 자동화를 설계할 수 있습니다.Google Cloud 아키텍처 센터는 엔터프라이즈 기반 청사진 위에 구현할 수 있는 다른 청사진을 제공합니다. 다음은 이러한 블루프린트의 몇 가지 예입니다.

보안 애플리케이션 출시 자동화

이 권장사항은 애플리케이션 보안이라는 중점사항과 관련이 있습니다.

자동화된 도구가 없으면 일관된 보안 요구사항을 충족하기 위해 복잡한 애플리케이션 환경을 배포, 업데이트, 패치하기가 어려울 수 있습니다. 소프트웨어 개발 수명 주기 (SDLC)에 맞게 자동화된 CI/CD 파이프라인을 빌드하는 것이 좋습니다. 자동화된 CI/CD 파이프라인을 사용하면 수동 오류를 제거하고 표준화된 개발 피드백 루프를 제공하며 효율적인 제품 반복을 지원할 수 있습니다. 지속적 배포는 DORA 프레임워크에서 권장하는 권장사항 중 하나입니다.

CI/CD 파이프라인을 사용하여 애플리케이션 출시를 자동화하면 보안 버그를 조기에 신속하고 안정적으로 감지하고 수정하는 능력을 개선할 수 있습니다. 예를 들어 아티팩트가 생성될 때 보안 취약점을 자동으로 스캔하고, 보안 검토 범위를 좁히고, 알려진 안전한 버전으로 롤백할 수 있습니다. 확인된 아티팩트만 배포되도록 다양한 환경 (예: 개발, 테스트 또는 프로덕션 환경)에 대한 정책을 정의할 수도 있습니다.

애플리케이션 출시를 자동화하고 CI/CD 파이프라인에 보안 검사를 삽입할 수 있도록 Google Cloud 는 Cloud Build, Cloud Deploy, Web Security Scanner, Binary Authorization 등의 여러 도구를 제공합니다.

SDLC에서 여러 보안 요구사항을 확인하는 프로세스를 수립하려면 Google에서 정의한 SLSA (소프트웨어 아티팩트에 대한 공급망 등급) 프레임워크를 사용하세요. SLSA는 소스 코드, 빌드 프로세스, 코드 출처에 대한 보안 검사를 요구합니다. 이러한 요구사항의 대부분은 자동화된 CI/CD 파이프라인에 포함할 수 있습니다. Google에서 이러한 관행을 내부적으로 적용하는 방식을 알아보려면 Google Cloud의 변화에 대한 접근 방식을 참고하세요.

승인된 프로세스에 따라 애플리케이션을 배포합니다.

이 권장사항은 애플리케이션 보안이라는 중점사항과 관련이 있습니다.

공격자가 CI/CD 파이프라인을 손상시킬 경우 전체 애플리케이션 스택이 영향을 받을 수 있습니다. 파이프라인을 보호하려면 코드를 프로덕션에 배포하기 전에 설정된 승인 프로세스를 적용해야 합니다.

Google Kubernetes Engine (GKE), GKE Enterprise 또는 Cloud Run을 사용하는 경우 Binary Authorization을 사용하여 승인 프로세스를 설정할 수 있습니다. Binary Authorization은 구성 가능한 서명을 컨테이너 이미지에 연결합니다. 이러한 서명 (증명이라고도 함)은 이미지를 검증하는 데 도움이 됩니다. 배포 시 Binary Authorization은 이러한 증명을 사용하여 프로세스가 완료되었는지 확인합니다. 예를 들어 Binary Authorization을 사용하여 다음을 수행할 수 있습니다.

  • 특정 빌드 시스템 또는 CI 파이프라인이 컨테이너 이미지를 만들었는지 확인합니다.
  • 컨테이너 이미지가 취약점 서명 정책을 준수하는지 확인합니다.
  • 컨테이너 이미지가 QA로의 개발과 같은 다음 배포 환경으로 승격하기 위한 기준을 통과하는지 확인합니다.

Binary Authorization을 사용하면 신뢰할 수 있는 코드만 타겟 플랫폼에서 실행되도록 시행할 수 있습니다.

애플리케이션 배포 전 알려진 취약점 스캔

이 권장사항은 애플리케이션 보안이라는 중점사항과 관련이 있습니다.

애플리케이션 아티팩트가 프로덕션에 배포되기 전에 애플리케이션 아티팩트에 대한 취약점 스캔을 지속적으로 수행할 수 있는 자동화된 도구를 사용하는 것이 좋습니다.

컨테이너화된 애플리케이션의 경우 Artifact Analysis를 사용하여 컨테이너 이미지의 취약점 스캔을 자동으로 실행합니다. Artifact Analysis는 새 이미지가 Artifact Registry에 업로드될 때 이를 스캔합니다. 스캔은 컨테이너의 시스템 패키지에 대한 정보를 추출합니다. 초기 스캔 후 Artifact Analysis는 Artifact Registry에서 스캔한 이미지의 메타데이터를 지속적으로 모니터링하여 새로운 취약점이 있는지 확인합니다. Artifact Analysis는 취약점 소스에서 새로운 업데이트된 취약점 정보를 수신하면 다음을 수행합니다.

  • 스캔한 이미지의 메타데이터를 업데이트하여 최신 상태로 유지합니다.
  • 새 메모에 대한 새 취약점 어커런스를 만듭니다.
  • 더 이상 유효하지 않은 취약점 어커런스를 삭제합니다.

애플리케이션 코드에 알려진 취약점이 있는지 모니터링합니다.

이 권장사항은 애플리케이션 보안이라는 중점사항과 관련이 있습니다.

자동화 도구를 사용하여 애플리케이션 코드를 지속적으로 모니터링하여 OWASP 상위 10개와 같은 알려진 취약점이 있는지 확인합니다. Google Cloud OWASP 상위 10개 완화 기술을 지원하는 제품 및 기능에 대한 자세한 내용은 Google Cloud의 OWASP 상위 10개 완화 옵션을 참고하세요.

Web Security Scanner를 사용하여 App Engine, Compute Engine, GKE 웹 애플리케이션의 보안 취약점을 파악할 수 있습니다. 스캐너는 애플리케이션을 크롤링하여 시작 URL 범위 내에 있는 모든 링크를 확인하고 최대한 많은 사용자 입력과 이벤트 핸들러 실행을 시도합니다. 교차 사이트 스크립팅, 코드 삽입, 혼합 콘텐츠, 오래되거나 안전하지 않은 라이브러리 등의 일반적인 취약점을 자동으로 스캔하고 감지할 수 있습니다. Web Security Scanner는 거짓양성으로 사용자의 주의가 분산되지 않도록 하면서 이러한 유형의 취약점을 조기에 식별할 수 있습니다.

또한 GKE Enterprise를 사용하여 Kubernetes 클러스터의 Fleet를 관리하는 경우 보안 상황 대시보드에는 Fleet의 보안 상황을 개선하는 데 도움이 되는 구체적이고 실행 가능한 권장사항이 표시됩니다.

이전
제로 트러스트 구현
다음
선제적 사이버 방어 구현