Azure Pipelines에 대한 기타 보안 고려 사항

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Azure Pipelines 보안과 관련하여 공유 인프라, 리포지토리, 프로젝트 등의 보호와 같은 몇 가지 다른 고려 사항을 염두에 두어야 합니다.

공유 인프라 보호

Azure Pipelines의 보호된 리소스는 실제 인프라의 추상화입니다. 기본 인프라를 보호하려면 다음 권장 사항을 따릅니다.

Microsoft 호스팅 풀 사용

Microsoft 호스팅 풀은 파이프라인의 각 실행마다 격리 및 깨끗한 가상 머신을 제공합니다. 가능하면 자체 호스팅 풀 대신 Microsoft 호스팅 풀을 사용합니다.

각 프로젝트에 대한 개별 에이전트

에이전트는 단일 풀에만 연결할 수 있습니다. 풀을 여러 프로젝트와 연결하여 여러 프로젝트에서 에이전트를 공유할 수 있습니다. 실제로 여러 프로젝트가 동일한 에이전트를 연속적으로 활용할 수 있습니다. 비용 효율적이지만 이 방법은 횡적 이동 위험을 초래할 수 있습니다.

횡적 이동을 완화하고 프로젝트 간의 교차 오염을 방지하려면 각각 특정 프로젝트에 전용으로 별도의 에이전트 풀을 유지 관리합니다.

권한이 낮은 계정을 사용하여 에이전트 실행

유혹을 받을 수 있지만 Azure DevOps 리소스에 직접 액세스할 수 있는 ID로 에이전트를 실행하는 것은 위험할 수 있습니다. 이 설정은 Microsoft Entra ID를 사용하는 조직에서 널리 사용되지만 위험을 초래합니다. Microsoft Entra ID로 지원되는 ID로 에이전트를 실행하는 경우 작업의 액세스 토큰에 의존하지 않고 Azure DevOps API에 직접 액세스할 수 있습니다. 보안을 강화하려면 네트워크 서비스와 같은 권한이 없는 로컬 계정을 사용하여 에이전트를 실행하는 것이 좋습니다.

Important

Azure DevOps에는 오해의 소지가 있는 Project Collection Service Accounts라는 그룹이 있습니다. 상속을 통해 프로젝트 컬렉션 서비스 계정의 멤버도 프로젝트 컬렉션 관리자의 구성원으로 간주됩니다. 일부 고객은 Microsoft Entra ID로 지원되는 ID를 사용하여 빌드 에이전트를 실행하며 이러한 ID는 Project Collection Service 계정의 일부일 수 있습니다. 그러나 악의적 사용자가 이러한 빌드 에이전트 중 하나에서 파이프라인을 실행하는 경우 잠재적으로 전체 Azure DevOps 조직을 제어할 수 있습니다.

자체 호스팅 에이전트가 높은 권한의 계정으로 작동하는 경우가 있습니다. 이러한 에이전트는 종종 이러한 권한 있는 계정을 활용하여 비밀 또는 프로덕션 환경에 액세스합니다. 그러나 악의적 사용자가 이러한 빌드 에이전트 중 하나에서 손상된 파이프라인을 실행하면 해당 비밀에 액세스할 수 있습니다. 그런 다음 악의적 사용자는 이러한 계정을 통해 액세스할 수 있는 다른 시스템을 통해 횡적으로 이동할 수 있습니다.

시스템 보안을 강화하려면 자체 호스팅 에이전트를 실행하기 위해 가장 낮은 권한의 계정을 사용하는 것이 좋습니다. 예를 들어 컴퓨터 계정 또는 관리 서비스 ID를 사용하는 것이 좋습니다. 또한 비밀 및 환경에 대한 액세스를 관리하는 Azure Pipelines를 맡깁니다.

서비스 연결 범위 최소화

서비스 연결에 필요한 리소스에만 액세스할 수 있는지 확인합니다. 가능할 때마다 Azure 서비스 연결에 대한 서비스 주체 대신 워크로드 ID 페더레이션을 사용하는 것이 좋습니다. 워크로드 ID 페더레이션은 업계 표준 기술인 OIDC(Open ID Connect)를 사용하여 비밀에 의존하지 않고 Azure와 Azure DevOps 간의 인증을 용이하게 합니다.

Azure 서비스 연결의 범위가 필요한 리소스에만 액세스하도록 범위가 지정되었는지 확인합니다. 사용자에게 전체 Azure 구독에 대한 광범위한 기여자 권한을 부여하지 않습니다.

새 Azure Resource Manager 서비스 연결을 만들 때는 항상 특정 리소스 그룹을 선택합니다. 리소스 그룹에 빌드에 필요한 VM 또는 리소스만 포함되어 있는지 확인합니다. 마찬가지로 GitHub 앱을 구성할 때 Azure Pipelines를 사용하여 빌드하려는 리포지토리에만 액세스 권한을 부여합니다.

프로젝트 보호

개별 리소스 외에도 Azure DevOps에서 리소스 그룹을 고려하는 것이 중요합니다. 리소스는 팀 프로젝트별로 구성되며 프로젝트 설정 및 포함을 기반으로 파이프라인이 액세스할 수 있는 항목을 이해하는 것이 중요합니다.

파이프라인의 각 작업은 열려 있는 리소스를 읽을 수 있는 권한이 있는 액세스 토큰을 받습니다. 경우에 따라 파이프라인이 이러한 리소스를 업데이트할 수도 있습니다. 즉, 사용자 계정에 특정 리소스에 대한 직접 액세스 권한이 없을 수도 있지만 파이프라인에서 실행되는 스크립트 및 태스크는 계속 액세스할 수 있습니다. 또한 Azure DevOps의 보안 모델을 사용하면 조직 내의 다른 프로젝트에서 이러한 리소스에 액세스할 수 있습니다. 특정 리소스에 대한 파이프라인 액세스를 제한하기로 결정한 경우 이 결정은 프로젝트 내의 모든 파이프라인에 적용됩니다. 특정 파이프라인은 열려 있는 리소스에 대한 액세스 권한을 선택적으로 부여할 수 없습니다.

개별 프로젝트

오픈 리소스의 특성을 고려할 때 각 제품 및 팀을 별도의 프로젝트에서 관리하는 것이 좋습니다. 이렇게 하면 한 제품의 파이프라인이 실수로 다른 제품의 열린 리소스에 액세스하여 횡적 노출을 최소화할 수 있습니다. 그러나 여러 팀 또는 제품이 프로젝트를 공유하는 경우 리소스의 세분화된 격리가 어려워집니다.

Azure DevOps 조직이 2019년 8월 이전에 만들어진 경우 실행은 여전히 모든 조직의 프로젝트에서 열린 리소스에 액세스할 수 있습니다. 조직 관리자는 파이프라인에 대한 프로젝트 격리를 가능하게 하는 Azure Pipelines의 중요한 보안 설정을 검토해야 합니다.

조직 설정 파이프라인>설정>에서 또는 직접 https://dev.azure.com/Organization_Name/_settings/pipelinessettings다음 설정을 찾을 수 있습니다.

리포지토리 보호

버전 제어 리포지토리에서 소스 코드, 파이프라인의 YAML 파일 및 필요한 스크립트 및 도구를 저장할 수 있습니다. 코드 및 파이프라인을 안전하게 변경하려면 권한 및 분기 정책을 적용하는 것이 중요합니다. 또한 리포지토리에 파이프라인 권한 및 검사를 추가하는 것이 좋습니다.

또한 리포지토리에 대한 기본 액세스 제어 설정을 검토합니다.

Git의 디자인은 분기 수준 보호에 제한이 있음을 의미합니다. 리포지토리에 푸시 액세스 사용자는 일반적으로 새 분기를 만들 수 있습니다. GitHub 오픈 소스 프로젝트를 사용하는 경우 GitHub 계정이 있는 모든 사용자가 리포지토리를 포크하고 기여를 제안할 수 있습니다. 파이프라인은 특정 분기가 아닌 리포지토리와 연결되므로 코드 및 YAML 파일을 신뢰할 수 없는 것으로 취급해야 합니다.

포크

GitHub의 공용 리포지토리를 사용하는 경우 포크 빌드에 대한 접근 방식을 신중하게 고려해야 합니다. 조직 외부에서 발생하는 포크는 특정 위험을 초래합니다. 신뢰할 수 없는 기여 코드로부터 제품을 보호하려면 다음 권장 사항을 고려합니다.

참고 항목

이러한 권장 사항은 주로 GitHub에서 공용 리포지토리를 빌드하는 데 적용됩니다.

포크 빌드에 비밀을 제공하지 않음

기본적으로 파이프라인은 포크를 빌드하도록 구성되지만 비밀 및 보호된 리소스는 해당 파이프라인의 작업에 자동으로 노출되지 않습니다. 보안을 유지하기 위해 이 보호를 사용하지 않도록 설정하지 않는 것이 중요합니다.

참고 항목

포크 빌드를 사용하여 비밀에 액세스하도록 설정하면 Azure Pipelines는 기본적으로 사용되는 액세스 토큰을 제한합니다. 이 토큰은 일반 액세스 토큰에 비해 열린 리소스에 대한 액세스가 제한됩니다. 포크 빌드에 일반 빌드와 동일한 권한을 부여하려면 포크 만들기 빌드에 일반 빌드 설정과 동일한 사용 권한이 있도록 설정합니다.

포크 빌드 수동 트리거 고려

자동 포크 빌드를 해제하고 대신 끌어오기 요청 주석을 사용하여 이러한 기여를 수동으로 빌드할 수 있습니다. 이 설정을 사용하면 빌드를 트리거하기 전에 코드를 검토할 수 있습니다.

포크 빌드에 Microsoft 호스팅 에이전트 사용

자체 호스팅 에이전트의 포크에서 빌드를 실행하지 않습니다. 이렇게 하면 외부 조직이 회사 네트워크 내의 컴퓨터에서 외부 코드를 실행할 수 있습니다. 가능하면 Microsoft 호스팅 에이전트를 사용합니다. 자체 호스팅 에이전트의 경우 네트워크 격리를 구현하고 에이전트가 작업 간에 상태를 유지하지 않도록 합니다.

코드 변경 내용 검토

분기된 풀 요청에 대해 파이프라인을 실행하기 전에 제안된 변경 사항을 주의 깊게 검토하고 원활하게 실행할 수 있는지 확인하세요.

실행하는 YAML 파이프라인의 버전은 끌어오기 요청의 버전입니다. 따라서 명령줄 스크립트 또는 단위 테스트와 같이 파이프라인이 실행되면 실행되는 코드 및 YAML 코드의 변경 내용에 특히 주의해야 합니다.

GitHub 토큰 범위 제한

GitHub 포크 풀 요청을 빌드할 때 Azure Pipelines는 파이프라인이 GitHub 리포지토리 콘텐츠를 변경할 수 없도록 합니다. 이 제한은 Azure Pipelines GitHub 앱을 사용하여 GitHub와 통합하는 경우에만 적용됩니다. 다른 형태의 GitHub 통합(예: OAuth 앱)을 사용하는 경우 제한이 적용되지 않습니다.

사용자 분기

올바른 권한이 있는 조직 사용자는 새 코드 또는 업데이트된 코드를 포함하는 새 분기를 만들 수 있습니다. 이 코드는 보호된 분기 동일한 파이프라인을 통해 실행할 수 있습니다. 새 분기의 YAML 파일이 변경되면 업데이트된 YAML이 파이프라인을 실행하는 데 사용됩니다. 이 디자인은 뛰어난 유연성과 셀프 서비스를 허용하지만 모든 변경 내용이 안전하지는 않습니다(악의적으로 수행되었는지 여부).

파이프라인이 소스 코드를 사용하거나 Azure Repos에 정의된 경우 Azure Repos 권한 모델을 완전히 이해해야 합니다. 특히 리포지토리 수준에서 분기 만들기 권한이 있는 사용자는 참가 권한이 없는 경우에도 리포지토리에 코드를 도입할 수 있습니다.

기타 보안 고려 사항

파이프라인을 보호하는 경우 고려해야 할 몇 가지 다른 사항이 있습니다.

PATH에 의존

에이전트의 PATH 설정에 의존하는 것은 위험합니다. 이전 스크립트 또는 도구에 의해 변경되었을 수 있으므로 이 기능이 어디에 있다고 생각하는지는 가리키지 않을 수 있습니다. 보안에 중요한 스크립트 및 이진 파일의 경우 항상 프로그램의 정규화된 경로를 사용합니다.

비밀 기록

Azure Pipelines는 가능한 한 로그에서 비밀을 스크럽하려고 시도합니다. 이 필터링은 최선의 방법으로 수행되며 기밀이 유출될 수 있는 모든 방법을 포착할 수는 없습니다. 콘솔에 비밀을 에코하거나, 명령줄 매개 변수에 사용하거나, 파일에 로깅하지 마세요.

컨테이너 잠금

컨테이너에는 호스트 에이전트와 통신하는 데 필요한 작업, 작업 영역 및 외부 구성 요소에 몇 가지 시스템 제공 볼륨 탑재 매핑이 있습니다. 이러한 볼륨을 모두 읽기 전용으로 표시할 수 있습니다.

resources:
  containers:
  - container: example
    image: ubuntu:22.04
    mountReadOnly:
      externals: true
      tasks: true
      tools: true
      work: false  # the default; shown here for completeness

일반적으로 대부분의 사용자는 처음 세 개의 디렉터리를 읽기 전용으로 설정하고 읽기/쓰기로 유지해야 work 합니다. 특정 작업 또는 단계에서 디렉터리에 쓰지 work 않는 경우 읽기 전용으로도 자유롭게 만들 수 work 있습니다. 그러나 파이프라인 작업에 자체 수정이 포함된 경우 읽기/쓰기로 유지해야 tasks 할 수 있습니다.

사용 가능한 작업 제어

Marketplace에서 작업을 설치하고 실행하는 기능을 사용하지 않도록 설정하면 파이프라인에서 실행되는 코드를 보다 세게 제어할 수 있습니다. 또한 모든 기본 제공 작업을 사용하지 않도록 설정할 수도 있습니다(에이전트에 대한 특수 작업인 체크 아웃 제외). 대부분의 경우 기본 제공 작업을 사용하지 않도록 설정하지 않는 것이 좋습니다.

직접 설치한 tfx 작업은 항상 사용할 수 있습니다. 이러한 두 기능을 모두 사용하도록 설정하면 해당 작업만 사용할 수 있습니다.

감사 서비스 사용

많은 파이프라인 이벤트가 감사 서비스에 기록됩니다. 감사 로그를 주기적으로 검토하여 악의적인 변경 내용이 누락되지 않았는지 확인합니다. https://dev.azure.com/ORG-NAME/_settings/audit을(를) 방문하여 시작합니다.

다음 단계

보안 개요 검토