소스 보호

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

소프트웨어팀이 소스를 관리하기 위한 기본 단계는 버전 제어 시스템(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 연구에서 확인된 기술 기능 중 하나입니다. 버전 제어에 스크립트, 소스 코드, 구성 파일을 저장하면 환경, trace, 감사 변경사항을 재현 및 복구하고 결함에 빠르게 대응하는 데 도움이 됩니다.

저장소 구성

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

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

저장소 구성은 표준화되지 않으므로 특히 조직에 수백 또는 수천 개의 저장소가 있는 일반적인 시나리오에서 저장소 보안이 애플리케이션에 적절한지 확인하기가 어렵습니다.
저장소를 만드는 누구나 다른 검토자 없이 병합을 수행하는 기능을 포함하여 전체 관리 권한이 있는 소유자가 됩니다.
저장소를 코드 분석, 빌드 서버, 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 기능은 공개적으로 액세스할 수 없습니다. 이 기능에 액세스하려면 액세스 요청 페이지를 참조하세요.