소스 보호

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

이 문서에서는 소프트웨어 소스 코드 관리를 위한 권장사항을 설명합니다.

소프트웨어팀이 소스를 관리하기 위한 기본 단계는 버전 제어 시스템(VCS)을 채택하는 것입니다. 버전 제어 시스템은 변경 내역 및 감사 기능을 제공합니다. GitHub와 같은 호스팅된 버전 제어 시스템은 가용성, 안정성, 보안 제어, 통합 코드 검토 도구, 다른 클라우드 서비스와의 통합과 같은 추가적인 이점을 제공합니다.

현재 대부분의 팀이 버전 제어를 사용하고 있지만 버전 제어 시스템과 CI/CD 파이프라인의 다른 부분과의 통합을 구성하는 방법은 다양합니다.

이 문서에서는 버전 제어 시스템 구성을 위한 소프트웨어 공급망 보안 고려사항을 살펴봅니다. 소프트웨어 공급망을 보호하기 위한 프레임워크인 Supply chain Levels for Software Artifacts의 권장사항을 설명합니다. 프레임워크에는 소스 요구사항을 포함하여 변경사항을 점진적으로 구현하는 데 도움이 되는 여러 수준의 요구사항이 포함됩니다.

변경 내역 및 변경할 수 없는 버전이 포함된 버전 제어 시스템은 SLSA 레벨 2 요구사항입니다. 소프트웨어 공급망의 시작 기준으로 SLSA 레벨 2를 준수하는 것이 좋습니다.

SLSA 레벨 3에서 소스 및 빌드 플랫폼은 확인된 소스 기록 및 소스 보관 정책을 비롯한 더 강력한 보안 요구사항을 준수합니다. SLSA 레벨 4는 소스 요구 사항에 2인 검토를 추가합니다.

애플리케이션 소스 외에도 버전 제어 사용

버전 제어에 애플리케이션 소스를 저장하는 것은 이전 기록 검토 및 감사가 필요할 때 널리 사용되는 방식입니다. 그러나 구성, 정책, 데이터 등 버전 제어의 이점을 누리는 다른 유형의 소스도 있습니다. 여기에는 다음 파일이 포함됩니다.

  • 컴퓨팅 인프라의 가용성 및 보안에 영향을 주는 파일
  • 완료 시 공동작업이 필요한 파일
  • 반복 가능한 승인 프로세스가 필요한 파일
  • 변경 내역이 필요한 파일

다음은 몇 가지 예시입니다.

  • 코드형 인프라: 확장 가능하고 안전한 방식으로 인프라를 관리하려는 조직은 코드형 인프라를 주요 방법론으로 사용합니다. 예를 들어 Artifact Registry 저장소를 만드는 버전 제어에 Terraform 모듈을 저장할 수 있습니다.
  • 구성 관리: 구성 관리는 코드형 인프라와 비슷하지만 Ansible, Puppet, Chef와 같은 도구를 사용하여 애플리케이션 구성을 관리하는 데 중점을 둡니다. 버전 제어 시스템에 애플리케이션 구성 파일을 저장하고 관리합니다.
  • 데이터베이스 구성 및 마이그레이션 스크립트: 제품 데이터베이스와 분석 또는 로깅 데이터베이스 모두에 대한 구성 및 스크립트를 저장합니다.
  • Jupyter 노트북: GitHub에 저장된 노트북으로 작업할 수 있는 다양한 방법은 [extension for JupyterLab][jlab], Colaboratory, 및 [Vertex AI Workbench][vertex]가 포함됩니다.
  • 보안 정책: 자동화된 정책 시행을 위한 정책 파일을 저장합니다. 예를 들어 GKE에서 배포 동작을 허용하거나 거부하는 게이트키퍼 정책 또는 정책을 위반하는 인프라를 Terraform이 프로비저닝하는 것을 방지하는 Sentinel 정책을 저장할 수 있습니다.

버전 제어는 소프트웨어 배포 및 조직 성과 향상을 가져오는 DORA DevOps 연구에서 확인된 기술 기능 중 하나입니다. 스크립트, 소스 코드, 구성 파일을 버전 제어에 저장하면 환경을 재현 및 복구하고, 변경사항을 추적 및 감사하고, 결함에 신속하게 대응할 수 있습니다.

저장소 구성

저장소는 코드 및 관련 역할, 권한, 통합, 승인을 정리하기 위한 기본 논리 단위입니다.

저장소 구성에서 발생할 수 있는 문제는 다음과 같습니다.

  • 저장소 구성은 표준화되지 않으므로 특히 조직에 수백 또는 수천 개의 저장소가 있는 일반적인 시나리오에서 저장소 보안이 애플리케이션에 적절한지 확인하기가 어렵습니다.
  • 저장소를 만든 사람은 다른 검토자와 병합하는 기능을 포함하여 완전한 관리 권한이 있는 소유자가 됩니다.
  • 저장소를 코드 분석, 빌드 서버, Issue Tracker, 알림 서비스, CI/CD 인프라의 다른 부분과 통합하는 것은 상당히 많은 작업입니다. 저장소를 만들고 설정하는 표준 방법을 사용하면 반복적인 작업이 줄어들고 권장사항이 지원됩니다.

이러한 문제를 해결하기 위한 권장사항은 다음과 같습니다.

  • 반복 가능하고 보안에 민감한 자동화 프로세스를 사용하여 저장소를 설정합니다. 예를 들어 저장소가 있는 애플리케이션의 보안 요구사항을 포함하는 Terraform 모듈을 설정할 수 있습니다. 보안 수준이 높은 애플리케이션은 보안 수준이 낮은 앱보다 많은 병합 승인자가 필요합니다.
  • 저장소 관리자가 각 저장소를 처음부터 구성하는 대신 새 저장소 설정을 유도하는 저장소 구성 템플릿 집합 중에서 선택할 수 있는 방법을 만듭니다. 이러한 템플릿은 애플리케이션의 다양한 보안 수준을 반영하고, 각 보안 수준에 필요한 사용자 ID와 동기화되어야 합니다. 사실상 일반적으로 조직 내 애플리케이션 및 인프라와 이를 담당하는 사용자를 반영하는 계층적 ID 및 액세스 제어(IAM) 시스템을 사용하는 것을 의미합니다.
  • 저장소 사용자를 위한 다중 인증(MFA)을 통해 중앙 집중식 ID 관리가 필요합니다.
    • 중앙 집중식 ID 관리를 사용하면 사용자가 조직을 떠나거나 새 팀으로 이동할 때 소스 관리에 대한 최소한의 권한을 유지할 수 있습니다.
    • 다중 인증(MFA)을 사용하면 소스에 대한 피싱 및 기타 유형의 공격 위험을 크게 줄일 수 있습니다. 2단계 인증은 코드 승인자에 대한 SLSA 레벨 4 요구사항 중 하나입니다.
  • 저장소 소유자를 신뢰할 수 있는 소수의 직원으로 제한합니다. 이 경우 버전 제어를 ID 관리 시스템과 통합하고 정책 설정 기능을 조직의 상위 직책으로 이동해야 할 수 있습니다. 가능한 경우 저장소 소유자가 두 번째 검토자 없이 병합을 수행할 수 있는 기능을 삭제하세요.

코드 검토

코드 검토는 조직이 소프트웨어의 품질 및 보안을 유지하는 주된 방법입니다. 코드 검토는 다음과 같은 다양한 장애 모드를 해결하려고 합니다.

  • 소프트웨어 결함 또는 유연하지 않은 디자인을 사용한 코드 도입
  • 잘못 정의된 API
  • 개발자가 작성한 안전하지 않은 코드로 인한 보안 문제 발생
  • 안전하지 않거나 안전하지 않을 수 있는 타사 라이브러리를 추가함으로써 보안 문제 발생

위험을 완화하는 몇 가지 방법은 다음과 같습니다.

  • 소프트웨어 수명 주기 전반에 걸쳐 지속적 테스트를 구현합니다. 소스를 버전 제어 시스템에 커밋할 때 트리거되는 자동 테스트는 개발자가 테스트에서 발견한 문제에 대한 의견을 빠르게 얻을 수 있는 방법입니다.
  • 검토자의 수와 ID를 애플리케이션의 보안 수준에 맞게 설정합니다. 예를 들어 사용량이 적은 인트라넷 앱은 비즈니스에 중요한 공개 애플리케이션보다 보안 요구사항이 낮습니다.
  • 커밋의 변경에 필요한 기술 전문 지식과 신뢰 수준을 기준으로 검토자를 할당합니다. 검토자는 검토 중인 언어, 코드가 상호작용하는 시스템, 이 애플리케이션 클래스의 보안 위험을 잘 알고 있어야 합니다. 기술 전문 지식 요구사항에는 많은 차원이 있습니다. 예를 들면 다음과 같습니다.
    • 코드를 읽을 수 있나요?
    • 안전한가요?
    • 적합한 타사 라이브러리를 사용하고 있나요?
    • 타사 라이브러리를 안전하게 보호하는 프로세스가 있나요?
    • 코드를 구성할 수 있나요?
    • API 설계가 권장사항을 따르고 있나요?
  • 검토는 관례적인 단계가 아니라 권장사항과 관련된 지속적인 대화입니다. 신기술 개발자를 위한 교육 프로그램과 함께 기술 스택의 각 부분에 대한 체크리스트, 스타일 가이드, 설계 표준을 만듭니다. VS Code 및 IntelliJ와 같은 일부 IDE는 프로그래매틱 또는 스타일 오류를 자동으로 플래그할 수 있는 린터를 제공합니다. 린터는 개발자가 보다 일관된 코드를 만들 수 있도록 지원하고 코드 검토자가 자동 검사로 식별하기 어려운 문제에 집중할 수 있게 해줍니다.

    보안 소프트웨어 개발Open Source Security Foundation(OpenSSF)에서 만든 무료 온라인 과정입니다. 이 문서는 소프트웨어 공급망 보안과 관련하여 기본 소프트웨어 개발 관행을 설명합니다.

  • 각 개발자가 준비되는 즉시 기능 브랜치 pull 요청으로 코드 검토를 수행합니다. 새 출시 버전이 테스트되기 직전까지 보안 확인 및 코드 검토를 수행하기 위해 기다리지 마세요.

  • 타사 라이브러리 스캔을 포함한 취약점 스캔을 pull 요청 및 IDE에 통합하면 가능한 한 빨리 문제를 식별할 수 있습니다. Google Cloud의 On-Demand Scanning API를 사용하면 컨테이너에서 로컬로 취약점을 스캔할 수 있습니다.

  • 개발자가 애플리케이션을 손상시킬 변경사항을 식별하고 해결할 수 있도록 병합 전에 자동화된 테스트를 통합합니다. 지속적 테스트 자세히 알아보기

병합 승인

지속적으로 통합되는 CI/CD 파이프라인에서 코드를 production 분기에 병합하면 자동 빌드 및 출시를 포함한 다운스트림 변경이 발생할 수 있습니다. 따라서 병합할 수 있는 사용자를 정하는 것은 소프트웨어 배포 보안에서 중요한 부분입니다. 고려 사항은 다음과 같습니다.

  • production 분기에서 보호된 분기 소유자를 설정합니다. 병합이 허용되는 사용자의 수와 ID는 애플리케이션의 보안 요구사항에 적합해야 합니다. SLSA 레벨 4에는 엄격하게 인증된 승인자 두 명이 필요하지만 승인자 수는 저장소의 콘텐츠에 적합해야 합니다.
  • 대부분의 버전 제어 시스템에서는 병합을 자체적으로 수행할 수 있으므로 저장소 소유자의 ID를 엄격하게 제어합니다.
  • 멀티 저장소 및 멀티 아티팩트 출시를 위한 배포 및 병합 승인 프로세스를 분리합니다.

개발 보호 도구

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

  • Cloud Workstations(미리보기)

    Cloud Workstations는 Google Cloud의 완전 관리형 개발 환경을 제공합니다. IT 및 보안 관리자는 개발 환경을 쉽게 프로비저닝, 확장, 관리, 보호할 수 있으며 개발자는 일관된 구성 및 맞춤설정 도구를 사용하여 개발 환경에 액세스할 수 있습니다.

    Cloud Workstations는 애플리케이션 개발 환경의 보안 상태를 강화하여 개발 초기부터 보안 문제 해결을 지원합니다. VPC 서비스 제어, 비공개 인그레스 또는 이그레스, 강제 이미지 업데이트, Identity and Access Management 액세스 정책과 같은 보안 기능이 있습니다. 자세한 내용은 Cloud Workstations 문서를 참조하세요.

  • Cloud Code source protect(미리보기)

    Cloud Code는 Google Cloud로 애플리케이션을 생성, 배포, 통합하기 위한 IDE 지원을 제공합니다. 개발자는 샘플 템플릿에서 새 애플리케이션을 만들고 맞춤설정할 수 있으며 완성된 애플리케이션을 실행할 수 있습니다. Cloud Code source protect는 개발자가 IDE에서 작업할 때 취약한 종속 항목 및 라이선스 보고와 같은 실시간 보안 피드백을 제공합니다. 개발자가 소프트웨어 개발 프로세스를 시작할 때 코드를 수정할 수 있는 빠르고 실행 가능한 피드백을 제공합니다.

    기능 제공 여부: Cloud Code source protect 기능은 공개적으로 액세스할 수 없습니다. 이 기능에 액세스하려면 액세스 요청 페이지를 참조하세요.

다음 단계