빌드 보호

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

이 문서에서는 빌드 보호를 위한 권장사항을 설명합니다. 코드 빌드는 다음과 같은 다양한 유형의 작업을 나타낼 수 있습니다.

  • 코드 최적화 또는 난독화: 예를 들어 Google 오픈소스 도구인 Closure Compiler는 자바스크립트를 파싱 및 분석하고 불필요한 코드를 삭제하며 나머지 항목을 재작성 및 최소화합니다. 또한 코드에서 일반적인 자바스크립트 문제가 있는지 확인합니다.
  • 코드를 중간 코드로 컴파일: 예를 들어 자바 코드를 자바 클래스 파일(.class)로 컴파일하거나 C++ 코드를 객체 파일(.obj)로 컴파일할 수 있습니다.
  • 코드 컴파일 및 연결, 라이브러리 또는 실행 파일 만들기: 예를 들어 C++ 코드를 공유 라이브러리(.so) 또는 Windows 실행 파일(.exe)로 컴파일합니다.
  • 코드를 배포 가능하거나 배포 가능한 형식으로 패키징: 예를 들어 자바 클래스 파일에서 자바 WAR(.war) 파일 만들기, Docker 이미지 만들기, Python 빌드 배포(.whl)를 만듭니다.

사용하는 프로그래밍 언어 및 배포하는 환경에 따라 빌드에 이러한 작업의 다양한 조합이 포함될 수 있습니다. 예를 들어 빌드는 Python 코드를 빌드된 배포로 패키징하고 Artifact Registry 또는 PyPI와 같은 아티팩트 저장소에 업로드하여 Cloud Functions에서 종속 항목으로 사용할 수 있습니다. Python 코드를 컨테이너화하고 컨테이너 이미지를 Cloud Run 또는 Google Kubernetes Engine에 배포할 수도 있습니다.

이 문서의 방법은 코드를 컴파일하는 대신 런타임 환경에 패키징 또는 배포하기 위한 코드를 빌드하는 데 중점을 둡니다.

자동 빌드 사용

자동 빌드 또는 스크립트 빌드는 소스 코드 검색 단계와 코드 빌드 단계를 포함하여 빌드 스크립트 또는 빌드 구성의 모든 빌드 단계를 정의합니다. 수동 명령어가 있다면 빌드를 실행하는 명령어뿐입니다.

예를 들어 빌드 스크립트는 다음과 같습니다.

  • Cloud Build cloudbuild.yaml
  • make 도구로 실행하는 Makefile
  • .github/workflows/ 디렉터리에 저장된 YAML 형식의 GitHub 작업 워크플로 파일

자동 빌드는 빌드 단계의 일관성을 제공합니다. 그러나 일관되고 신뢰할 수 있는 환경에서 빌드를 실행하는 것도 중요합니다.

로컬 빌드는 디버깅에 유용할 수 있지만 로컬 빌드에서 소프트웨어를 출시하면 빌드 프로세스에 많은 보안 문제, 비일관성, 비효율성이 발생할 수 있습니다.

  • 로컬 빌드를 허용하면 악의적인 의도를 가진 공격자가 빌드 프로세스를 수정할 수 있는 방법이 제공됩니다.
  • 개발자 로컬 환경과 개발자 관행의 비일관성으로 인해 빌드를 재현하고 빌드 문제를 진단하기가 어렵습니다.

수동 빌드는 컴퓨팅, 저장소, 네트워크와 같은 더 많은 인프라 리소스를 활용하여 프로세스를 비효율적으로 만듭니다. SLSA 프레임워크 요구사항에서 자동 빌드는 SLSA 레벨 1의 요구사항이며 빌드에 개발자 환경 대신 빌드 서비스 사용은 SLSA 레벨 2의 요구사항입니다.

Cloud Build는 Google Cloud의 관리형 빌드 서비스입니다. 빌드 구성 파일을 사용하여 Cloud Build에 빌드 단계를 제공합니다. 종속 항목을 가져오고, 단위 테스트, 정적 분석, 통합 테스트를 실행하고, Docker, Gradle, Maven, Go, Python과 같은 빌드 도구로 아티팩트를 만들도록 빌드를 구성할 수 있습니다. Cloud Build는 Artifact RegistryGoogle Cloud Deploy와 같은 Google Cloud의 다른 CI/CD 서비스뿐만 아니라 GKECloud Run과 같은 런타임 환경과 완전히 통합됩니다. GitHub 및 Bitbucket과 같은 주요 소스 코드 관리 시스템과의 통합도 제공합니다.

빌드 출처 생성

빌드 출처는 빌드에 대한 검증 가능한 데이터 모음입니다.

출처 메타데이터에는 빌드된 이미지의 다이제스트, 입력 소스 위치, 빌드 도구 모음, 빌드 기간과 같은 세부정보가 포함됩니다.

빌드 출처를 생성하면 다음을 수행하는 데 도움이 됩니다.

  • 빌드된 아티팩트가 신뢰할 수 있는 소스 위치 및 신뢰할 수 있는 빌드 시스템에서 생성되었는지 확인합니다.
  • 신뢰할 수 없는 소스 위치 또는 빌드 시스템에서 삽입된 코드를 식별합니다.

알림 및 정책 메커니즘을 사용하여 빌드 출처 데이터를 사전에 사용할 수 있습니다. 예를 들어 확인된 소스에서 빌드된 코드 배포만 허용하는 정책을 만들 수 있습니다.

SLSA 레벨 1의 경우 빌드된 아티팩트 소비자가 빌드 출처를 사용할 수 있어야 합니다. SLSA 레벨 2의 경우 빌드 출처 데이터도 다음과 같아야 합니다.

  • 빌드 서비스에서 생성되거나 빌드 서비스에서 직접 읽을 수 있습니다.
  • 소비자가 신뢰성 및 무결성을 확인할 수 있습니다. 이 작업은 빌드 출처 데이터를 만드는 서비스에서 생성된 디지털 서명을 사용하여 수행해야 합니다.

SLSA 레벨 3의 경우에는 출처 콘텐츠에도 다음이 포함되어야 합니다.

  • 빌드 정의의 진입점입니다.
  • 사용자가 제어하는 모든 빌드 매개변수입니다.

Cloud Build는 SLSA 레벨 3 보증을 제공하는 컨테이너 이미지의 빌드 출처를 생성할 수 있습니다. 자세한 내용은 빌드 출처 보기를 참조하세요.

임시 빌드 환경 사용

임시 환경은 단일 빌드 호출을 위해 지속되는 임시 환경입니다. 빌드 후에는 환경이 완전 삭제되거나 삭제됩니다. 임시 빌드는 빌드 서비스 및 빌드 단계가 컨테이너 또는 VM과 같은 임시 환경에서 실행되도록 합니다. 기존 빌드 환경을 재사용하는 대신 빌드 서비스는 각 빌드에 새로운 환경을 프로비저닝한 다음 빌드 프로세스가 완료되면 삭제합니다.

임시 환경에는 빌드 프로세스를 방해할 수 있는 이전 빌드의 잔여 파일 또는 환경 설정이 없으므로 클린 빌드를 보장합니다. 비임시 환경은 공격자가 악성 파일과 콘텐츠를 삽입할 수 있는 기회를 제공합니다. 또한 임시 환경은 유지보수 오버헤드를 줄이고 빌드 환경의 불일치를 줄여줍니다.

Cloud Build는 모든 빌드에 대해 새로운 가상 머신 환경을 설정하고 빌드 후에 폐기합니다.

빌드 서비스에 대한 액세스 제한

빌드 서비스 및 빌드 리소스에 필요한 최소 권한을 부여하여 최소 권한의 보안 원칙을 따르세요. 또한 빌드를 대신하여 빌드를 실행하고 다른 서비스와 상호작용하려면 사람이 아닌 ID를 사용해야 합니다.

Cloud Build를 사용하는 경우:

  • 조직의 구성원에게 필요한 최소 권한을 부여합니다.
  • Cloud Build 대신 작동하는 서비스 계정의 권한을 사용 사례에 필요한 권한만 갖도록 맞춤설정합니다. 기본 Cloud Build 서비스 계정의 권한을 수정하거나 대신 커스텀 서비스 계정을 사용하는 것이 좋습니다.
  • Cloud Build 허용된 통합 조직 정책을 사용하여 빌드 트리거를 호출할 수 있는 외부 서비스를 제어합니다.
  • VPC 서비스 제어를 사용하여 서비스 경계에 Cloud Build를 배치합니다. 경계는 경계 내에 있는 Google Cloud 서비스 간의 무료 통신을 허용하지만 지정한 규칙에 따라 경계 간의 통신을 제한합니다. 또한 경계는 데이터 무단 반출 위험을 완화합니다.

    Cloud Build는 비공개 풀에서 실행되는 빌드에 대해서만 VPC 서비스 제어를 지원합니다.

사용자 인증 정보 보호

빌드에는 버전 제어, 아티팩트 저장소, 배포 환경과 같은 다른 시스템에 대한 연결이 포함되는 경우가 많습니다. 빌드에서 사용하는 사용자 인증 정보를 보호하면 소프트웨어 공급망에서 시스템에 대한 무단 액세스 및 데이터 무단 반출을 방지하는 데 도움이 됩니다.

하드 코딩된 사용자 인증 정보를 버전 제어 또는 빌드 구성에 직접 저장하지 마세요. 대신 사용자 인증 정보를 보안 키 저장소에 저장하세요.

Google Cloud에서 Secret Manager는 API 키, 비밀번호, 기타 민감한 데이터를 안전하게 저장합니다. Secret Manager에 저장된 보안 비밀을 사용하도록 Cloud Build를 구성할 수 있습니다.

종속 항목 관리

애플리케이션의 무결성은 개발하는 코드와 사용하는 종속 항목의 무결성에 의존합니다. 또한 종속 항목을 게시하는 위치, 아티팩트 저장소에 읽고 쓸 수 있는 사용자, 런타임 환경에 배포하는 신뢰할 수 있는 빌드 아티팩트 소스에 대한 정책도 고려해야 합니다.

종속 항목 관리에 대한 자세한 내용은 종속 항목 관리를 참조하세요.

Cloud Build에서는 클라우드 빌더를 사용하여 명령어를 실행합니다. 빌더는 공용 언어 및 도구가 설치된 컨테이너 이미지입니다. Docker Hub, Cloud Build에서 제공하는 빌더, 커뮤니티 기부 빌더, 사용자가 만든 커스텀 빌더와 같은 공개 레지스트리의 공개 컨테이너 이미지를 사용할 수 있습니다. Google Cloud 빌드팩을 포함한 빌더로 빌드팩을 사용할 수도 있습니다.

Cloud Build 빌드에서 사용하는 빌더를 검토하고, 누가 이를 제공하는지 파악하고, 소프트웨어 공급망에서 신뢰 여부를 결정합니다. 빌더의 코드를 보다 세부적으로 제어하려면 공개 소스의 빌더를 사용하는 대신 커스텀 빌더를 만들 수 있습니다.

빌드 변경 기회 줄이기

빌드에 영향을 줄 수 있는 다음과 같은 다양한 요소가 있습니다.

  • 동시에 실행되고 서로에게 영향을 줄 수 있는 빌드 또는 후속 빌드에 지속되고 영향을 주는 빌드
  • 빌드 진입점 및 최상위 소스 위치 이외의 사용자 매개변수를 허용하는 빌드
  • 변경 가능한 범위 또는 종속 항목이 있는 종속 항목을 지정하는 빌드(예: latest 태그가 있는 이미지 사용) 이러한 방식은 빌드가 잘못되거나 원치 않는 버전의 종속 항목을 사용할 위험이 있습니다.

다음은 이러한 위험을 완화하는 데 도움이 됩니다.

  • 각 빌드를 임시 환경에서 실행합니다.
  • 사용자가 빌드 스크립트에 정의된 변수에 영향을 줄 수 없도록 추가 매개변수를 사용하여 빌드를 실행하지 마세요.
  • 빌드 서비스 및 빌드 리소스에 대한 액세스를 제한합니다.
  • 향후 다른 버전의 아티팩트를 가리킬 수 있는 태그 같은 식별자 대신 변경할 수 없는 종속 항목을 참조합니다. 종속 항목에 대한 자세한 내용은 종속 항목 관리를 참조하세요.

컨테이너 빌드를 위한 권장사항 준수

컨테이너 빌드를 위한 권장사항을 검토하여 다음과 같이 안정적이고 공격에 덜 취약한 컨테이너 이미지를 빌드하는 방법을 알아보세요.

  • 단일 애플리케이션 패키징
  • 프로세스 처리
  • Docker 빌드 캐시 최적화
  • 불필요한 도구를 삭제하고 이미지를 최대한 작게 유지
  • 컨테이너 분석으로 취약점을 스캔합니다. Artifact Registry에 저장된 이미지를 스캔하거나 저장하기 전에 로컬에서 스캔할 수 있습니다.
  • 태그 추가 권장사항
  • 공개 이미지 사용에 대한 보안 고려사항

Software Delivery Shield

Software Delivery Shield는 완전 관리형 엔드 투 엔드 소프트웨어 공급망 보안 솔루션입니다. 이는 개발자, DevOps, 보안팀이 소프트웨어 공급망의 보안 상태를 개선하는 데 사용할 수 있는 포괄적이고 모듈화된 기능 및 도구 모음을 Google Cloud 서비스 전반에서 제공합니다. Google Cloud 콘솔의 Cloud Build UI에서 빌드된 애플리케이션의 보안 통계를 표시합니다. 여기에는 다음이 포함됩니다.

  • 소프트웨어 공급망 보안의 성숙도 수준을 식별하는 SLSA 레벨
  • 빌드 아티팩트의 취약점
  • 빌드에 대한 검증 가능한 메타데이터 모음인 빌드 출처 빌드된 이미지의 다이제스트, 입력 소스 위치, 빌드 도구 모음, 빌드 단계, 빌드 기간과 같은 세부정보가 포함됩니다.

빌드된 애플리케이션의 보안 통계를 보는 방법은 애플리케이션 빌드 및 보안 통계 보기를 참조하세요.

다음 단계