보안 배포 파이프라인 설계

배포 파이프라인은 코드 또는 사전 빌드된 아티팩트를 가져와 테스트 환경이나 프로덕션 환경에 배포하는 자동화된 프로세스입니다. 배포 파이프라인은 일반적으로 애플리케이션, 구성 또는 클라우드 인프라(코드형 인프라)를 배포하는 데 사용되며 클라우드 배포의 전반적인 보안 상황에서 중요한 역할을 할 수 있습니다.

이 가이드는 DevOps 및 보안 엔지니어를 대상으로 하며 기밀성, 무결성, 가용성 요구사항에 따라 보안 배포 파이프라인 설계에 대한 권장사항을 설명합니다.

아키텍처

다음 다이어그램에서는 배포 파이프라인의 데이터 흐름을 보여줍니다. 아티팩트를 리소스로 변환하는 방법을 보여줍니다.

배포 파이프라인은 더 큰 지속적 통합/지속적 배포(CI/CD) 워크플로의 일부인 경우가 많으며 일반적으로 다음 모델 중 하나를 통해 구현됩니다.

• 푸시 모델: 이 모델에서는 Jenkins 또는GitLab과 같은 중앙 CI/CD 시스템을 사용하여 배포 파이프라인을 구현합니다. 이 CI/CD 시스템은 Google Cloud, 온프레미스 또는 다른 클라우드 환경에서 실행될 수 있습니다. 배포 파이프라인 여러 개를 관리하는 데 같은 CI/CD 시스템이 사용되는 경우가 많습니다.

  푸시 모델은 잠재적으로 다수의 리소스나 애플리케이션을 관리하는 데 사용되는 몇 가지 CI/CD 시스템이 포함된 중앙 집중식 아키텍처로 이어집니다. 예를 들어 단일 Jenkins 또는 GitLab 인스턴스를 사용하여 모든 프로젝트와 애플리케이션을 포함한 전체 프로덕션 환경을 관리할 수 있습니다.

• 가져오기 모델: 이 모델에서는 리소스와 함께 배포되는 에이전트(예: 동일한 Kubernetes 클러스터)가 배포 프로세스를 구현합니다. 에이전트는 중앙 위치에서 아티팩트나 소스 코드를 가져와 로컬로 배포합니다. 각 에이전트는 리소스 1~2개를 관리합니다.

  가져오기 모델은 잠재적으로 단일 목적의 에이전트를 다수 사용하는 보다 분산화된 아키텍처로 이어집니다.

배포 파이프라인을 일관적으로 사용하면 수동 배포와 비교 시 다음과 같은 이점이 있습니다.

• 수동 작업이 필요하지 않으므로 효율성이 향상됩니다.
• 프로세스가 완전히 자동화되고 반복 가능하므로 신뢰성이 향상됩니다.
• 코드 변경이나 입력 아티팩트에 대한 모든 배포를 추적할 수 있으므로 추적 가능성이 향상됩니다.

수행하려면 배포 파이프라인에서 관리하는 리소스에 대한 액세스 권한이 필요합니다.

• Terraform과 같은 도구를 사용하여 인프라를 배포하는 파이프라인에서 VM 인스턴스, 서브넷 또는 Cloud Storage 버킷과 같은 리소스를 생성, 수정 또는 삭제해야 할 수도 있습니다.
• 애플리케이션을 배포하는 파이프라인에서 새 컨테이너 이미지를 Artifact Registry에 업로드하고 새 애플리케이션 버전을 App Engine, Cloud Run 또는 Google Kubernetes Engine(GKE)에 배포해야 할 수도 있습니다.
• 설정을 관리하거나 구성 파일을 배포하는 파이프라인에서 VM 인스턴스 메타데이터, Kubernetes 구성을 수정하거나 Cloud Storage의 데이터를 수정해야 할 수도 있습니다.

배포 파이프라인이 제대로 보호되지 않으면 Google Cloud 리소스에 대한 액세스가 보안 상황에서 취약점이 될 수 있습니다. 보안이 약화되면 다음과 같은 여러 종류의 공격이 발생할 수 있습니다.

• 파이프라인 악성 공격: 악의적인 행위자가 리소스를 직접 공격하는 대신 배포 파이프라인, 구성 또는 기본 인프라를 손상시키려고 시도할 수 있습니다. 악의적인 행위자는 다음 다이어그램과 같이 Google Cloud에 대한 파이프라인의 액세스 권한을 활용하여 파이프라인이 Cloud 리소스에서 악의적인 작업을 수행하게 할 수 있습니다.

  

• 공급망 공격: 악의적인 행위자는 다음 다이어그램과 같이 배포 파이프라인을 공격하는 대신 소스 코드, 라이브러리 또는 컨테이너 이미지를 포함한 파이프라인 입력을 손상시키거나 교체하려고 시도할 수 있습니다.

  

배포 파이프라인이 적절하게 보호되었는지 여부를 확인하기 위해서는 Google Cloud 리소스의 허용 정책과 거부 정책을 따로 확인하는 것만으로는 부족합니다. 대신 직접 또는 간접적으로 리소스에 대한 액세스 권한을 부여하는 시스템의 전체 그래프를 고려해야 합니다. 이 그래프에는 다음 정보가 포함됩니다.

• 배포 파이프라인, 기본 CI/CD 시스템, 기본 인프라
• 소스 코드 저장소, 기본 서버, 기본 인프라
• 입력 아티팩트, 스토리지 위치, 기본 인프라
• 입력 아티팩트를 생성하는 시스템 및 기본 인프라

복잡한 입력 그래프를 사용하면 리소스에 대한 사용자 액세스와 시스템 약점을 파악하기가 어렵습니다.

다음 섹션에서는 그래프 크기를 관리하고 측면 이동 및 공급망 공격의 위험을 줄이는 데 도움이 되는 방식으로 배포 파이프라인을 설계할 수 있는 권장사항을 설명합니다.

보안 목표 평가

Google Cloud의 리소스는 민감한 정도에 따라 달라질 수 있습니다. 일부 리소스는 비즈니스에 중요하거나 기밀이므로 매우 민감할 수 있습니다. 다른 리소스는 임시 리소스이거나 테스트 용도로만 사용되므로 덜 민감할 수 있습니다.

보안 배포 파이프라인을 설계하려면 먼저 파이프라인에서 액세스해야 하는 리소스와 이러한 리소스의 민감도를 이해해야 합니다. 리소스가 민감할수록 파이프라인 보안에 더 집중해야 합니다.

배포 파이프라인에서 액세스하는 리소스는 다음과 같습니다.

• 애플리케이션(예: Cloud Run 또는 App Engine)
• 클라우드 리소스(예: VM 인스턴스 또는 Cloud Storage 버킷)
• 데이터(예: Cloud Storage 객체, BigQuery 레코드 또는 파일)

이러한 리소스 중 일부에는 다른 리소스에 대한 종속 항목이 있을 수 있습니다. 예를 들면 다음과 같습니다.

• 애플리케이션에서 데이터, 클라우드 리소스, 기타 애플리케이션에 액세스할 수 있습니다.

• VM 인스턴스 또는 Cloud Storage 버킷과 같은 클라우드 리소스에 애플리케이션이나 데이터가 포함될 수 있습니다.

  

앞선 다이어그램과 같이 종속 항목은 리소스 민감도에 영향을 미칩니다. 예를 들어 매우 민감한 정보에 액세스하는 애플리케이션을 사용하는 경우 일반적으로 해당 애플리케이션을 매우 민감한 정보로 취급해야 합니다. 마찬가지로, Cloud Storage 버킷과 같은 클라우드 리소스에 민감한 정보가 포함되어 있으면 일반적으로 버킷을 민감한 정보로 취급해야 합니다.

이러한 종속 항목으로 인해 먼저 데이터 민감도를 평가하는 것이 가장 좋습니다. 데이터를 평가한 후에는 종속 항목 체인을 검사하고 Cloud 리소스와 애플리케이션의 민감도를 평가할 수 있습니다.

데이터 민감도 분류

배포 파이프라인의 데이터 민감도를 이해하려면 다음 세 가지 목표를 고려하세요.

• 기밀성: 무단 액세스로부터 데이터를 보호해야 합니다.
• 무결성: 승인되지 않은 수정이나 삭제로부터 데이터를 보호해야 합니다.
• 가용성: 승인된 사람과 시스템이 배포 파이프라인의 데이터에 액세스할 수 있는지 확인해야 합니다.

이러한 각 목표에서 파이프라인이 침해되면 어떤 일이 발생할지 질문해 봅니다.

• 기밀성: 악의적인 행위자에게 데이터가 공개되거나 유출된 경우 피해 정도가 얼마나 되나요?
• 무결성: 악의적인 행위자가 데이터를 수정하거나 삭제하면 피해 정도가 얼마나 되나요?
• 가용성: 악의적인 행위자가 데이터 액세스를 중단하면 피해 정도가 얼마나 되나요?

여러 리소스에서 결과를 비교하려면 보안 카테고리를 도입하는 것이 좋습니다. 보안 분류 표준(FIPS-199)에서는 다음 4가지 카테고리를 사용할 것을 권장합니다.

• 높음: 심각하거나 치명적일 수 있는 손상
• 보통: 심각할 수 있는 손상
• 낮음: 제한될 수 있는 손상
• 해당 사항 없음: 표준이 적용되지 않음

환경과 컨텍스트에 따라 다른 카테고리 집합이 더 적합할 수 있습니다.

파이프라인 데이터의 기밀성과 무결성은 앞서 언급한 보안 카테고리 기준의 범위를 기반으로 합니다. 다음 하위 섹션에는 기밀성 및 무결성 측정이 서로 다른 리소스의 예시가 포함되어 있습니다.

기밀성은 낮은 수준이지만 무결성이 낮은, 보통, 높은 수준의 리소스

다음 리소스 예시 모두 기밀성이 낮은 수준입니다.

• 낮은 무결성: 테스트 데이터
• 보통 무결성: 공개 웹 서버 콘텐츠, 조직의 정책 제약조건
• 높은 무결성: 컨테이너 이미지, 디스크 이미지, 애플리케이션 구성, 액세스 정책(허용 및 거부 목록), 선취권, 액세스 수준 데이터

기밀성은 보통 수준이지만 무결성이 낮은, 보통, 높은 수준의 리소스

다음 리소스 예시 모두 기밀성이 보통 수준입니다.

• 낮은 무결성: 내부 웹 서버 콘텐츠
• 보통 무결성: 감사 로그
• 높은 무결성: 애플리케이션 구성 파일

기밀성은 높은 수준이지만 무결성이 낮은, 보통, 높은 수준의 리소스

다음 리소스 예시 모두 기밀성이 높은 수준입니다.

• 낮은 무결성: 사용 데이터 및 개인 식별 정보
• 보통 무결성: 보안 비밀
• 높은 무결성: 재무 데이터, KMS 키

액세스하는 데이터를 기반으로 애플리케이션 분류

애플리케이션에서 민감한 정보에 액세스하면 애플리케이션과 이 애플리케이션을 관리하는 배포 파이프라인도 민감한 정보가 될 수 있습니다. 해당 민감도를 검증하려면 애플리케이션과 파이프라인에서 액세스해야 하는 데이터를 확인합니다.

애플리케이션에서 액세스하는 모든 데이터를 식별 및 분류하면 보안 배포 파이프라인을 설계하기 전에 다음 카테고리를 사용하여 처음에 애플리케이션을 분류할 수 있습니다.

• 기밀성: 액세스한 모든 데이터의 가장 높은 카테고리
• 무결성: 액세스한 모든 데이터의 가장 높은 카테고리
• 가용성: 액세스한 모든 데이터의 가장 높은 카테고리

이 초기 평가는 안내를 제공하지만 다음과 같은 추가적으로 고려할 요소가 있을 수 있습니다.

• 두 데이터 세트의 기밀성 수준이 각각 낮을 수 있습니다. 하지만 조합하면 새로운 유용한 정보를 얻을 수 있습니다. 애플리케이션에서 두 데이터 세트 모두에 액세스할 수 있으면 보통 또는 높은 기밀성으로 분류해야 할 수도 있습니다.
• 애플리케이션이 무결성이 높은 데이터에 액세스할 수 있는 경우 일반적으로 애플리케이션을 높은 무결성으로 분류해야 합니다. 하지만 해당 액세스가 읽기 전용인 경우 높은 무결성 분류가 너무 엄격할 수 있습니다.

애플리케이션을 분류하는 공식 방식에 대한 자세한 내용은 정보 유형 및 정보 시스템을 보안 카테고리로 매핑하는 가이드(NIST SP 800-60 Vol. 2 Rev1)를 참조하세요.

호스팅하는 데이터와 애플리케이션을 기반으로 클라우드 리소스 분류

Google Cloud에 배포하는 모든 데이터나 애플리케이션은 Google Cloud 리소스에서 호스팅됩니다.

• 애플리케이션은 App Engine 서비스, VM 인스턴스 또는 GKE 클러스터에서 호스팅될 수 있습니다.
• 데이터는 영구 디스크, Cloud Storage 버킷 또는 BigQuery 데이터 세트에서 호스팅될 수 있습니다.

클라우드 리소스에서 민감한 정보나 애플리케이션을 호스팅하면 리소스 및 리소스를 관리하는 배포 파이프라인도 민감한 정보가 될 수 있습니다. 예를 들어 Cloud Run 서비스와 배포 파이프라인이 호스팅하는 애플리케이션과 마찬가지로 민감한 정보가 될 수 있다는 점을 고려해야 합니다.

데이터와 애플리케이션을 분류한 후에 애플리케이션의 초기 보안 카테고리를 만듭니다. 이렇게 하려면 다음 카테고리에서 수준을 결정합니다.

• 기밀성: 호스팅된 모든 데이터나 애플리케이션의 가장 높은 카테고리
• 무결성: 호스팅된 모든 데이터나 애플리케이션의 가장 높은 카테고리
• 가용성: 호스팅된 모든 데이터나 애플리케이션의 가장 높은 카테고리

초기 평가를 수행할 때는 엄격하지 않도록 합니다. 예를 들면 다음과 같습니다.

• 높은 수준의 기밀 데이터가 암호화되는 경우 암호화 키를 높은 기밀 수준으로 취급합니다. 그러나 데이터가 포함된 리소스에는 더 낮은 보안 카테고리를 사용할 수 있습니다.
• 데이터의 중복 복사본을 저장하거나 여러 리소스에 걸쳐 동일한 애플리케이션의 중복 인스턴스를 실행하는 경우 리소스 카테고리를 호스팅하는 데이터나 애플리케이션의 카테고리보다 낮게 만들 수 있습니다.

배포 파이프라인 사용 제한

배포 파이프라인에서 민감한 Google Cloud 리소스에 액세스해야 하는 경우 보안 상황을 고려해야 합니다. 리소스가 민감할수록 파이프라인을 더욱 보호해야 합니다. 하지만 다음과 같은 실용적인 제한사항이 발생할 수 있습니다.

• 기존 인프라나 기존 CI/CD 시스템을 사용할 때 해당 인프라에서 현실적으로 달성할 수 있는 보안 수준을 제한할 수 있습니다. 예를 들어 CI/CD 시스템이 제한된 보안 제어 집합만 지원하거나 일부 프로덕션 환경보다 안전하지 않다고 간주되는 인프라에서 실행 중일 수 있습니다.
• 배포 파이프라인을 실행하기 위해 새 인프라와 시스템을 설정할 때 가장 엄격한 보안 요구사항을 충족하는 방식으로 모든 구성요소를 보호하는 것이 경제적이지 않을 수 있습니다.

이러한 제한사항을 해결하기 위해 배포 파이프라인과 특정 CI/CD 시스템을 사용해야 하는 시나리오와 사용하지 않아야 하는 시나리오에 대한 제약조건을 설정하는 것이 유용할 수 있습니다. 예를 들어 가장 민감한 배포는 배포 파이프라인 외부에서 더 효율적으로 처리되는 경우가 많습니다. 권한이 있는 세션 관리 시스템이나 권한 있는 액세스 관리 시스템 또는 도구 프록시와 같은 다른 것을 사용하여 이러한 배포를 수동으로 수행할 수 있습니다.

제약조건을 설정하려면 리소스 카테고리를 기준으로 적용할 액세스 제어를 정의합니다. 다음 표에 제시된 안내를 고려하세요.

리소스 카테고리	액세스 제어
낮음	승인 필요 없음
보통	팀장이 승인해야 함
높음	여러 팀장이 승인하고 작업을 기록해야 함

다음 질문과 기타 질문을 통해 이러한 요구사항을 소스 코드 관리(SCM) 및 CI/CD 시스템의 기능과 비교합니다.

• SCM 또는 CI/CD 시스템에서 필요한 액세스 제어와 승인 메커니즘을 지원하나요?
• 악의적인 행위자가 기본 인프라를 공격하면 제어가 전환되지 않도록 보호되나요?
• 제어를 정의하는 구성이 적절하게 보호되나요?

SCM 또는 CI/CD 시스템에 적용되는 기능과 제한사항에 따라 배포 파이프라인의 데이터 및 애플리케이션 제약조건을 정의할 수 있습니다. 다음 표에 제시된 안내를 고려하세요.

리소스 카테고리	제약조건
낮음	배포 파이프라인을 사용할 수 있고 개발자는 배포를 자체 승인할 수 있습니다.
보통	배포 파이프라인을 사용할 수 있지만 팀장이 모든 커밋과 배포를 승인해야 합니다.
높음	배포 파이프라인을 사용하지 마세요. 대신 관리자가 권한이 있는 액세스 관리 시스템과 세션 레코드를 사용해야 합니다.

리소스 가용성 유지

배포 파이프라인을 사용하여 리소스를 관리하는 것은 해당 리소스의 가용성에 영향을 미치고 새로운 위험을 초래할 수 있습니다.

• 서비스 중단 원인: 배포 파이프라인에서 잘못된 코드나 구성 파일을 푸시하여 이전에 작동 중인 시스템을 손상시키거나 데이터를 사용할 수 없게 될 수 있습니다.
• 서비스 중단 연장: 서비스 중단을 해결하려면 배포 파이프라인을 다시 실행해야 할 수 있습니다. 배포 파이프라인이 손상되거나 다른 이유로 사용할 수 없는 경우 서비스 중단이 연장될 수 있습니다.

서비스 중단을 야기하거나 연장하는 파이프라인은 서비스 거부 위험을 야기합니다. 악의적인 행위자가 배포 파이프라인을 사용하여 의도적으로 서비스를 중단시킬 수 있습니다.

비상 액세스 절차 만들기

배포 파이프라인이 애플리케이션 또는 리소스를 배포하거나 구성할 수 있는 유일한 방법인 경우 파이프라인 가용성이 중요해질 수 있습니다. 배포 파이프라인이 업무에 중요한 애플리케이션을 관리하는 유일한 방법인 극단적인 경우에는 배포 파이프라인을 업무상 중요하게 고려해야 할 수도 있습니다.

배포 파이프라인이 여러 시스템과 도구에서 생성되는 경우가 많으므로 높은 수준의 가용성을 유지하는 것이 어렵거나 경제적이지 않을 수 있습니다.

비상 액세스 절차를 만들어 배포 파이프라인이 가용성에 미치는 영향을 줄일 수 있습니다. 예를 들어 배포 파이프라인이 작동하지 않을 때 사용할 수 있는 대체 액세스 경로를 만듭니다.

비상 액세스 절차를 만들려면 일반적으로 대부분의 다음 프로세스가 필요합니다.

• 관련 Google Cloud 리소스에 대한 액세스 권한이 있는 사용자 계정 중 하나 이상을 유지합니다.
• 비상 액세스 사용자 계정의 사용자 인증 정보를 안전한 위치에 저장하거나 권한이 있는 액세스 관리 시스템을 사용하여 액세스를 차단합니다.
• 승인된 직원이 사용자 인증 정보에 액세스할 수 있는 절차를 설정합니다.
• 비상 액세스 사용자 계정 사용을 감사하고 검토합니다.

입력 아티팩트가 가용성 요구사항을 충족하는지 확인

일반적으로 배포 파이프라인은 배포를 수행하기 전에 중앙 소스 코드 저장소에서 소스 코드를 다운로드해야 합니다. 소스 코드 저장소를 사용할 수 없으면 배포 파이프라인 실행이 실패할 수 있습니다.

많은 배포 파이프라인에서도 서드 파티 아티팩트에 의존합니다. 이러한 아티팩트에는 npm, Maven Central 또는 NuGet Gallery와 같은 소스의 라이브러리와 컨테이너 기본 이미지, .deb 및 .rpm 패키지가 포함될 수 있습니다. 서드 파티 소스 중 하나를 사용할 수 없으면 배포 파이프라인 실행이 실패할 수 있습니다.

특정 수준의 가용성을 유지하려면 배포 파이프라인의 입력 아티팩트 모두 동일하거나 더 높은 가용성 요구사항을 충족하는지 확인해야 합니다. 다음 목록을 사용하면 입력 아티팩트의 가용성을 확인할 수 있습니다.

• 입력 아티팩트, 특히 서드 파티 소스의 소스 수 제한
• 소스 시스템을 사용할 수 없는 경우 배포 파이프라인에서 사용할 수 있는 입력 아티팩트의 캐시 유지

배포 파이프라인 및 프로덕션 시스템과 같은 인프라 처리

배포 파이프라인은 개발, 스테이징, 프로덕션 환경 간 연결 조직 역할을 하는 경우가 많습니다. 환경에 따라 여러 단계를 구현할 수 있습니다.

• 첫 번째 단계에서는 배포 파이프라인이 개발 환경을 업데이트합니다.
• 다음 단계에서는 배포 파이프라인이 스테이징 환경을 업데이트합니다.
• 마지막 단계에서는 배포 파이프라인이 프로덕션 환경을 업데이트합니다.

여러 환경에서 배포 파이프라인을 사용할 때는 파이프라인이 각 환경의 가용성 요구사항을 충족하는지 확인합니다. 일반적으로 프로덕션 환경의 가용성 요구 사항이 가장 높으므로 배포 파이프라인과 기본 인프라를 프로덕션 시스템처럼 취급해야 합니다. 즉, 프로덕션 시스템과 동일한 방식으로 배포 파이프라인을 실행하는 인프라에 동일한 액세스 제어, 보안, 품질 표준을 적용합니다.

배포 파이프라인 범위 제한

배포 파이프라인에서 액세스할 수 있는 리소스가 많을수록 보안 침해 시 더욱 심각한 손상이 발생할 수 있습니다. 최악의 경우 여러 프로젝트나 전체 조직에 액세스할 수 있는 손상된 배포 파이프라인에 의해 Google Cloud에 있는 모든 데이터와 애플리케이션이 심각하게 손상될 수 있습니다.

이러한 최악의 시나리오를 방지하려면 배포 파이프라인 범위를 제한합니다. Google Cloud에서 상대적으로 적은 수의 리소스에만 액세스해야 하는 각 배포 파이프라인의 범위를 정의합니다.

• 프로젝트 수준에서 액세스 권한을 부여하는 대신 배포 파이프라인에 개별 리소스에 대한 액세스 권한만 부여합니다.
• 여러 Google Cloud 프로젝트에서 리소스에 대한 액세스 권한을 부여하지 마세요.
• 여러 프로젝트나 환경에 액세스해야 하는 경우에는 배포 파이프라인을 여러 단계로 분할합니다. 그런 다음 단계를 개별적으로 보호합니다.

기밀성 유지

배포 파이프라인은 관리하는 데이터의 기밀성을 유지해야 합니다. 기밀성과 관련된 주요 위험 중 하나는 데이터 무단 반출입니다.

악의적인 행위자는 여러 가지 방법으로 배포 파이프라인을 사용하여 Google Cloud 리소스의 데이터를 유출하려고 합니다. 이러한 방법은 다음과 같습니다.

• 직접: 악의적인 행위자가 Google Cloud 리소스에서 데이터를 추출한 후 다른 곳으로 복사하도록 배포 파이프라인이나 구성을 수정할 수 있습니다.
• 간접: 악의적인 행위자가 배포 파이프라인을 사용하여 손상된 코드를 배포한 후 Google Cloud 환경에서 데이터를 도용할 수 있습니다.

기밀 리소스에 대한 액세스를 최소화하여 기밀성 위험을 줄일 수 있습니다. 하지만 기밀 리소스에 대한 모든 액세스 권한을 삭제하는 것이 실용적이지 않을 수 있습니다. 따라서 관리하는 리소스의 기밀성 요구사항이 충족되도록 배포 파이프라인을 설계해야 합니다. 이러한 요구 사항을 확인하려면 다음 방법을 사용하면 됩니다.

1. 배포 파이프라인에서 액세스해야 하는 데이터, 애플리케이션, 리소스를 결정하고 분류합니다.
2. 기밀성 카테고리가 가장 높은 리소스를 찾아 배포 파이프라인의 초기 카테고리로 사용합니다.

애플리케이션 및 클라우드 리소스의 분류 프로세스와 마찬가지로 이러한 초기 평가가 항상 적합한 것은 아닙니다. 예를 들어 배포 파이프라인을 사용하여 높은 수준의 기밀 정보가 포함되는 리소스를 만들 수 있습니다. 이러한 리소스를 만들 수 있지만 읽을 수 없도록 배포 파이프라인을 제한하는 경우에는 낮은 기밀성 카테고리만으로 충분할 수 있습니다.

기밀성을 유지하기 위해 Bell–LaPadula 모델에서는 배포 파이프라인에서 다음을 수행하면 안 된다고 제안합니다.

• 기밀성이 높은 입력 아티팩트 사용
• 기밀성이 낮은 리소스에 데이터 쓰기

앞선 다이어그램에서는 Bell-LaPadula 모델에 따라 데이터 기밀성을 보장하는 데 도움이 되도록 파이프라인에서 데이터가 흐르는 방식을 보여줍니다.

배포 파이프라인에서 필요 없는 데이터를 읽도록 허용하지 않음

배포 파이프라인은 종종 데이터에 액세스할 필요가 없지만 여전히 액세스할 수 있습니다. 이러한 과도한 액세스 권한 부여는 다음과 같은 이유로 발생할 수 있습니다.

• 잘못된 액세스 권한 부여 예를 들어 배포 파이프라인에는 프로젝트 수준에서 Cloud Storage에 대한 액세스 권한이 부여될 수 있습니다. 따라서 배포 파이프라인은 프로젝트의 모든 Cloud Storage 버킷에 액세스할 수 있지만 단일 버킷에 대한 액세스만으로 충분할 수 있습니다.
• 과도한 권한이 있는 역할 사용 예를 들어 배포 파이프라인에 Cloud Storage에 대한 전체 액세스 권한을 제공하는 역할이 부여될 수 있습니다. 하지만 새 버킷을 만들 수 있는 권한만으로 충분합니다.

파이프라인에서 액세스할 수 있는 데이터가 많을수록 다른 사람이나 무언가가 데이터를 도용할 수 있는 위험이 커집니다. 이 위험을 최소화하려면 배포 파이프라인에 필요하지 않은 데이터에 대한 액세스 권한을 부여하지 마세요. 배포 파이프라인의 유일한 목적은 구성 또는 소프트웨어 배포를 관리하는 것이므로 여러 배포 파이프라인에서 데이터에 액세스할 필요가 전혀 없습니다.

배포 파이프라인에서 필요 없는 위치에 쓰도록 허용하지 않음

데이터를 삭제하려면 악의적인 행위자에게 환경에 액세스하고 데이터를 환경 외부로 전송하는 방법이 필요합니다. 배포 파이프라인에서 데이터를 전송할 수 있는 스토리지와 네트워크 위치가 많을수록 악의적인 행위자가 이러한 위치 중 하나를 유출에 사용할 가능성이 높아집니다.

파이프라인에서 데이터를 전송할 수 있는 네트워크와 스토리지 위치 수를 제한하면 위험을 줄일 수 있습니다.

• 리소스에 기밀 데이터가 포함되어 있지 않아도 파이프라인에 필요하지 않은 리소스에 대한 쓰기 액세스를 취소합니다.
• 인터넷 액세스를 차단하거나 연결을 허용 목록에 포함된 네트워크 위치 집합으로 제한합니다.

아웃바운드 액세스를 제한하는 것은 보통 기밀 또는 높은 기밀로 분류된 파이프라인에 특히 중요합니다. 이러한 파이프라인에서 기밀 데이터나 암호화 키 자료에 액세스할 수 있기 때문입니다.

손상된 배포에서 데이터가 도용되지 않도록 VPC 서비스 제어 사용

악의적인 행위자는 배포 파이프라인에서 데이터 무단 반출을 수행할 수 있게 하는 대신 배포 파이프라인을 사용하여 손상된 코드를 배포하려고 시도할 수 있습니다. 그러면 손상된 코드가 Google Cloud 환경 내에서 데이터를 도용할 수 있습니다.

VPC 서비스 제어를 사용하면 데이터 도용 위협의 위험을 줄일 수 있습니다. VPC 서비스 제어를 사용하면 특정 Google Cloud 프로젝트 내에서 액세스할 수 있는 리소스와 API의 집합을 제한할 수 있습니다.

무결성 유지

Google Cloud 환경을 보호하려면 무결성을 보호해야 합니다. 여기에는 다음과 같은 정보가 포함됩니다.

• 데이터나 구성의 승인되지 않은 수정 또는 삭제 방지
• 신뢰할 수 없는 코드나 구성 배포 방지
• 모든 변경사항이 명확하게 감사 추적되도록 보장

배포 파이프라인을 사용하면 다음을 수행하여 환경 무결성을 유지할 수 있습니다.

• 승인 프로세스 구현(예: 코드 검토 형식)
• 모든 구성 또는 코드 변경사항에 일관된 프로세스 적용
• 배포 전에 자동 테스트 또는 빠른 점검 실행

이러한 조치가 효과적이게 하려면 악의적인 행위자가 이러한 조치를 약화하거나 회피할 수 없게 해야 합니다. 이러한 활동을 방지하려면 다음 항목의 무결성을 보호해야 합니다.

• 배포 파이프라인 및 구성
• 기본 인프라
• 배포 파이프라인에서 사용하는 모든 입력

배포 파이프라인이 취약해지지 않게 하려면 배포 파이프라인의 무결성 표준이 관리하는 리소스의 무결성 요구사항과 일치하거나 초과되는지 확인해야 합니다. 이러한 요구 사항을 확인하려면 다음 방법을 사용하면 됩니다.

1. 배포 파이프라인에서 액세스해야 하는 데이터, 애플리케이션, 리소스를 결정하고 분류합니다.
2. 무결성 카테고리가 가장 높은 리소스를 찾아 배포 파이프라인의 카테고리로 사용합니다.

배포 파이프라인의 무결성이 유지되도록 Biba 모델에서는 다음을 제안합니다.

• 배포 파이프라인에서 무결성이 낮은 입력 아티팩트를 사용하지 않아야 합니다.
• 배포 파이프라인에서 무결성이 더 높은 리소스에 데이터를 쓰면 안 됩니다.

앞선 다이어그램에서는 Biba 모델에 따라 데이터 무결성을 보장하는 데 도움이 되도록 파이프라인에서 데이터가 흐르는 방식을 보여줍니다.

입력 아티팩트의 신뢰성 확인

많은 배포 파이프라인에서 서드 파티 소스의 아티팩트를 사용합니다. 이러한 아티팩트는 다음과 같습니다.

• Docker 기본 이미지
• .rpm 또는 .deb 패키지
• Maven, .npm 또는 NuGet 라이브러리

악의적인 행위자가 다음과 같은 방법으로 보안 손상된 서드 파티 아티팩트 버전을 사용하도록 배포 파이프라인을 수정하려고 시도할 수 있습니다.

• 아티팩트를 저장하는 저장소 손상
• 다른 소스 저장소를 사용하도록 배포 파이프라인 구성 수정
• 유사한 이름 또는 오타가 포함된 이름으로 악성 패키지 업로드

여러 패키지 관리자를 사용하면 코드 서명 지원을 통해 패키지 신뢰성을 확인할 수 있습니다. 예를 들어 PGP를 사용하여 RPM 및 Maven 패키지에 서명할 수 있습니다. Authenticode를 사용하여 NuGet 패키지에 서명할 수 있습니다.

코드 서명을 사용하면 다음을 통해 손상된 서드 파티 패키지로 인한 손실 위험을 줄일 수 있습니다.

• 모든 서드 파티 아티팩트가 서명되도록 요구
• 선별된 신뢰할 수 있는 게시자 인증서 또는 공개 키 목록 유지
• 배포 파이프라인에서 신뢰할 수 있는 게시자 목록에 대해 서드 파티 아티팩트 서명을 확인하도록 허용

또는 아티팩트의 해시를 확인할 수 있습니다. 코드 서명을 지원하지 않고 가끔 변하는 아티팩트에 이 방식을 사용할 수 있습니다.

기본 인프라가 무결성 요구를 충족하는지 확인

악의적인 사용자는 배포 파이프라인 자체를 손상시키는 대신 다음과 같은 인프라를 손상시키려고 시도할 수 있습니다.

• 배포 파이프라인을 실행하는 CI/CD 소프트웨어
• 파이프라인에서 사용하는 도구(예: Terraform, kubectl 또는 Docker)
• 운영체제 및 모든 구성요소

배포 파이프라인의 기반이 되는 인프라는 복잡한 경우가 많으며 다양한 공급업체나 소스의 구성요소를 포함할 수 있으므로 이러한 유형의 보안 침해를 감지하기 어려울 수 있습니다.

다음과 같은 방법으로 손상된 인프라 위험을 줄일 수 있습니다.

• 인프라와 모든 구성요소를 배포 파이프라인 및 관리하는 Google Cloud 리소스와 동일한 무결성 표준으로 유지
• 도구가 신뢰할 수 있는 소스에서 제공되었는지 확인 및 신뢰성 확인
• 정기적으로 인프라를 처음부터 다시 빌드
• 보안 VM에서 배포 파이프라인 실행

파이프라인에 무결성 제어 적용

악의적인 행위자는 위협이지만 Google Cloud 환경 무결성을 손상시킬 수 있는 소프트웨어 또는 구성 변경사항의 유일한 소스는 아닙니다. 이러한 변경사항은 개발자에 의한 것일 수도 있고 간단히 무지로 인한 사고이거나 오타 및 기타 실수로 인한 결과일 수 있습니다.

추가 무결성 제어를 적용하도록 배포 파이프라인을 구성하면 실수에 의한 위험한 변경사항 적용 위험을 줄일 수 있습니다. 이러한 제어에는 다음이 포함됩니다.

• 코드 및 구성에 대한 정적 분석 수행
• 모든 변경사항이 규칙 집합 집합을 통과하도록 요구(policy as code)
• 동시에 수행할 수 있는 변경사항 수 제한

다음 단계

• 배포 파이프라인에서 서비스 계정을 사용에 대한 권장사항을 알아보세요.
• 서비스 계정 보안을 위한 권장사항을 검토하세요.
• 위협 조사 및 대응에 대해 자세히 알아보세요.
• 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.