리포지토리 및 파이프라인 보호
자동화를 사용하여 인프라를 배포하면 파이프라인과 리포지토리가 강력하고 중요해집니다. 이제는 변경 내용이 제어된 환경에 적용되는 유일한 방법을 나타내기 때문입니다.
Azure DevOps 조직, GitHub 리포지토리 및 파이프라인의 많은 부분은 보호가 필요합니다. 다음 표에서는 보호해야 할 가장 중요한 요소 중 일부와 함께 이러한 요소를 적절하게 보호하지 않을 경우 발생할 수 있는 취약성의 예시를 제공합니다.
| 보호할 요소 | 취약성 예시 |
|---|---|
| 액세스 권한이 있는 사용자와 수행할 수 있는 작업을 포함한 Azure DevOps 조직 또는 GitHub 리포지토리. | 앙심을 품은 전직 직원이 코드 리포지토리를 삭제합니다. |
| 리포지토리의 중요한 분기 및 해당 분기의 코드를 변경하기 위해 수행해야 하는 작업. | 누군가가 실수로 안전하지 않은 Bicep 코드를 리포지토리의 기본 분기에 커밋합니다. |
| 인프라 정의, 테스트 및 애플리케이션 코드를 포함한 리포지토리 내의 코드. | 누군가가 작성한 코드를 테스트하는 것을 잊어버렸는데 프로덕션에 릴리스될 때 제대로 작동하지 않습니다. |
| 파이프라인 정의. | 누군가가 실수로 파이프라인의 로그에 데이터베이스 연결 문자열을 쓰는 파이프라인 단계를 추가합니다. |
| 파이프라인을 실행하는 에이전트 또는 실행기. | 초안 끌어오기 요청에 대해 실행되는 파이프라인은 에이전트에 보안 취약성을 설치하며, 이는 나중에 프로덕션 배포에 사용됩니다. |
| 파이프라인 내에서 실행될 수 있는 타사 작업 또는 구성 요소. | 타사 파이프라인 작업이 서비스 주체의 자격 증명을 악성 웹 사이트로 보냅니다. |
| 파이프라인에서 Azure 액세스에 사용하는 서비스 주체. | 비프로덕션 서비스 주체가 실수로 프로덕션 환경을 변경합니다. |
| 파이프라인이 외부 시스템에 액세스하는 데 사용하는 비밀. | 팀원이 프로토타입에 대한 새 파이프라인 정의 파일을 작성하고 실수로 내 프로덕션 환경에 연결합니다. |
이제 Azure DevOps 및 GitHub 모두에서 코드 리포지토리 및 배포 파이프라인을 중심으로 거버넌스 및 제어를 적용하는 데 사용할 수 있는 몇 가지 방법에 대해 알아보겠습니다.
사용자 및 권한 관리
Azure DevOps 조직 또는 GitHub 리포지토리에 대한 액세스 권한을 부여하는 방법을 고려합니다. 액세스 권한이 있는 사용자와 수행할 수 있는 작업을 생각해봅니다.
조직의 Microsoft Entra 인스턴스를 파이프라인의 ID 공급자로 사용하는 것이 좋습니다. 그러면 누군가가 조직에 가입하거나 조직을 떠날 때마다 파이프라인에 대한 액세스 권한이 자동으로 부여되거나 취소되도록 할 수 있습니다. Microsoft Entra ID를 사용하면 조건부 액세스 및 다단계 인증과 같은 보호 기능을 쉽게 구현할 수도 있습니다.
참고 항목
GitHub와 Microsoft Entra 통합을 사용하려면 조직에 GitHub Enterprise 라이선스가 필요합니다.
팀(GitHub) 또는 그룹(Azure DevOps)을 만들어서 권한을 함께 부여할 수 있는 사용자 집합을 나타낼 수도 있습니다. 이렇게 하면 권한을 개별적으로 할당할 필요가 없습니다. 사용자 권한을 팀이나 그룹에 추가하고 제거하여 쉽게 변경할 수 있습니다.
팁
Azure DevOps에서는 Azure에서 사용하는 모델과 다른 최소 권한 모델을 사용합니다. Azure DevOps에서 거부 권한은 허용 권한을 재정의합니다. 따라서 권한 집합이 다른 여러 그룹에 할당된 경우 모든 그룹에서 허용하는 작업만 수행할 수 있습니다.
특히 그룹에 사용 권한이 할당되는 방식을 이해해야 합니다.
중요한 코드 분기 보호
파이프라인 및 자동화는 기본과 같은 특정 코드 분기를 식별하는 데 기반해야 합니다. 이러한 지정된 분기의 코드는 일반적으로 신뢰할 수 있으며 프로덕션 환경에 배포할 수 있습니다. 컨트롤을 적용하여 중요한 분기에 있는 코드가 확인되고 검토되도록 할 수 있습니다.
분기 보호 규칙(GitHub) 또는 분기 정책(Azure Repos)을 사용하여 중요한 코드 분기에 대한 직접 커밋을 방지하는 것이 좋습니다. 그러면 팀이 변경 내용을 병합하기 위해 끌어오기 요청을 사용하도록 요구할 수 있습니다. 자동화된 검사 및 수동 검토 프로세스를 적용하여 변경 내용이 병합되기 전에 유효한지 확인할 수 있습니다.
코드 테스트 및 검토
인프라 정의를 포함하여 모든 코드를 검토하고 테스트하는 것에 대한 기대치를 팀이 이해해야 합니다.
파이프라인 정의는 YAML 파일이므로 코드의 한 형태입니다. 파이프라인 정의에 대한 변경 내용을 검토하고 평가해야 합니다. 그렇지 않으면 누군가가 실수로 또는 악의적으로 서비스 주체의 자격 증명을 유출하거나 Azure 자산에 위험한 변경을 하는 파이프라인 단계를 만들 수 있습니다.
파이프라인 정의 파일에 대한 변경 내용을 철저히 검토해야 합니다. 팀의 모든 사용자는 파이프라인이 높은 권한을 가지며 특별한 주의가 필요하다는 것을 이해해야 합니다.
파이프라인 에이전트 및 실행기 보호
파이프라인은 에이전트(Azure Pipelines) 또는 실행기(GitHub Actions)에서 실행됩니다. 에이전트와 실행기를 가상 머신으로 생각할 수 있습니다. 파이프라인 정의는 제공한 태스크 및 스크립트를 실행하여 해당 가상 머신을 컨트롤합니다.
Azure Pipelines 및 GitHub Actions는 모두 호스트된 에이전트와 실행기를 제공하며, Microsoft 또는 GitHub에서 구성하고 유지 관리합니다. 플랫폼 소유자는 권장 보안 사례를 준수하도록 컴퓨터를 구성합니다. 플랫폼 소유자의 책임에는 운영 체제 취약성 패치가 포함됩니다.
그 대신 에이전트 및 실행기를 위해 사용자 고유의 물리적 또는 가상 머신을 사용하도록 선택할 수 있습니다. 이 유형의 머신을 자체 호스팅 에이전트 및 실행기라고 합니다. 자체 호스팅 에이전트 및 실행기를 사용하는 경우 머신이 올바르게 구성되고 위협으로부터 보호되는지 확인해야 합니다.
Microsoft 호스팅 에이전트 및 GitHub 호스팅 실행기는 임시입니다. 파이프라인의 실행이 종료되면 에이전트 또는 실행기에서 파일 또는 구성 변경 내용이 모두 제거됩니다. 에이전트 또는 실행기를 자체 호스팅하는 경우 프로덕션 및 비프로덕션 환경을 비롯한 여러 개별 파이프라인 또는 환경에 동일한 머신이 사용될 가능성이 큽니다. 누군가가 에이전트의 운영 체제에서 중요한 파일을 수정하고 끌어오기 요청에서 파이프라인을 실행하는 파이프라인 정의를 만든다고 가정해보겠습니다. 다음 번에 프로덕션 환경에 대해 배포가 실행될 때 에이전트를 다시 사용하게 될 수 있습니다. 그러면 이제 손상된 파일이 프로덕션 환경에 미치는 영향을 예측할 방법이 없습니다.
이러한 이유로 가능한 한 Microsoft 호스팅 에이전트 및 GitHub 호스팅 실행기를 사용하는 것이 좋습니다. 자체 호스팅 실행기를 사용해야 하는 경우 구성 및 사용과 관련된 위험을 신중하게 평가합니다.
파이프라인 내에서 실행되는 타사 구성 요소 평가
커뮤니티에서 제공하는 GitHub Actions 또는 Azure DevOps 확장을 사용하는 경우 누가 빌드했고 무엇을 하는 이들인지를 파악합니다. 타사 파이프라인 구성 요소가 서비스 주체의 자격 증명에 액세스해서 Azure의 전체 환경에 액세스하게 될지도 모릅니다.
Azure DevOps에서 조직 관리자는 일반적으로 확장을 사용하기 전에 모든 확장을 승인합니다. 조직의 관리자라면 사용하는 각 구성 요소에 관련된 보안 위험을 고려해야 합니다. 신뢰할 수 있고 안전한지 확인할 책임이 있습니다.
타사 작업 또는 태스크를 사용할 때마다 버전을 지정합니다. 검토했던 정확한 버전을 지정하는 것이 좋습니다. 파이프라인에서 이후 버전을 자동으로 사용하도록 허용하면 검토하지 않은 위험이 발생할 수 있습니다.
파이프라인의 서비스 주체 보호
파이프라인은 서비스 주체를 사용하여 Azure 및 기타 서비스에 액세스합니다. 서비스 주체를 보호하고 자격 증명을 부적절하게 사용할 수 없도록 하는 것이 중요합니다. 다중 보호 계층을 적용하는 것을 고려합니다.
먼저 서비스 주체에 대한 자격 증명을 보호하는 것이 좋습니다.
- 가능하면 항상 관리형 ID 또는 워크로드 ID를 사용하여 자격 증명을 완전히 저장하지 않도록 합니다. 모든 파이프라인에서 관리 ID 또는 워크로드 ID를 사용할 수는 없지만 가능하다면 사용하는 것이 좋습니다.
- 서비스 주체의 자격 증명을 정기적으로 변경하거나 회전하는 방법을 계획합니다. 예를 들어 조직에는 90일 또는 120일마다 자격 증명을 회전하는 정책이 있을 수 있습니다. 순환을 책임지는 담당자와 자격 증명이 사용되는 모든 위치를 업데이트하는 방법을 고려합니다.
- 비밀, 키 및 인증서를 관리하여 조직의 다른 부분에 노출되지 않도록 하는 비밀 보유자를 지정하는 것이 좋습니다.
다음으로 서비스 주체에 부여하는 사용 권한을 생각해 봅니다.
- 파이프라인의 서비스 주체에 Microsoft Entra 조건부 액세스 정책을 적용합니다. 이러한 정책은 위험한 로그인 및 동작을 식별하는 데 도움이 됩니다. 예를 들어 파이프라인 서비스 주체가 항상 하나의 지리적 지역에서 로그인하는 경우, 조건부 액세스는 자격 증명이 손상되었음을 나타낼 수 있는 예기치 않은 위치에서의 로그인을 감지하고 방지할 수 있습니다.
- 각 서비스 주체에 부여하는 권한을 신중하게 고려합니다. 예를 들어 공유 리소스의 구성을 읽는 데 사용하는 서비스 주체가 있다고 가정합니다. 서비스 주체가 더 많은 권한이 필요한 작업을 수행할 필요가 없으므로 해당 서비스 주체에 대한 읽기 권한자 액세스 권한만 부여할 수 있는지를 고려합니다.
- 서비스 주체에 할당하는 각 권한에 대해 최소 범위를 사용합니다. 예를 들어 서비스 주체가 단일 리소스 그룹에만 배포해야 하는 경우라면 역할 할당 범위를 전체 구독이 아닌 해당 리소스 그룹으로 지정합니다.
- 각 환경에 대해 별도의 서비스 주체를 사용합니다. 이렇게 하면 보안 주체의 자격 증명이 손상되거나 누군가가 한 환경에 액세스하는 경우에도 다른 환경에는 액세스할 수 없습니다.
서비스 연결 및 비밀 보호
서비스 연결(Azure Pipelines) 또는 비밀(GitHub)에는 파이프라인이 Azure 환경에 액세스하는 데 사용하는 서비스 주체에 대한 자격 증명이 포함됩니다. 서비스 연결 및 비밀을 보호하고 어떤 파이프라인이 각 서비스 연결 및 비밀을 사용할지를 컨트롤하는 것이 중요합니다. 그렇지 않으면 실수로 비프로덕션 환경을 사용하여 프로덕션 리소스에 액세스할 수 있는 서비스 주체를 사용하게 될 수도 있습니다.
Azure DevOps에서 서비스 연결을 만들 때 새 파이프라인 또는 환경에서 이를 사용하기 전에 승인을 요구하도록 구성할 수 있습니다.
또한 Azure DevOps에서는 ‘검사’를 특정 서비스 연결과 연결할 수 있습니다. 검사는 추가 보호 계층을 추가합니다. 예를 들어 프로덕션 서비스 연결에 대한 검사를 구성하여 리포지토리의 기본 분기의 코드에서만 사용되는지 확인할 수 있습니다. 이 검사를 통해 권한 없는 코드가 프로덕션 환경에 배포되지 않도록 방지할 수 있습니다.
GitHub에서 환경별 비밀을 구성하여 GitHub Actions 워크플로가 해당 환경에서 작업할 때 비밀 값만 제공되도록 할 수 있습니다. 환경별 비밀 및 승인과 같은 환경 컨트롤을 사용하면 비프로덕션 배포를 사용하여 프로덕션 환경에 배포하는 위험을 줄일 수 있습니다. 또한 워크로드 ID를 사용하여 GitHub Actions 워크플로에서 자격 증명을 사용하지 않도록 하고 자격 증명이 노출될 가능성을 제거할 수도 있습니다.
GitHub 보안 기능 사용
GitHub가 제공하는 보안 기능을 평가하고 사용해야 합니다. 이러한 기능으로는 다음이 포함됩니다.
- Dependabot은 소스 코드의 종속성에서 알려진 취약성을 검사합니다.
- 비밀 검사는 키 또는 자격 증명처럼 보이는 리포지토리의 텍스트를 식별합니다. 리포지토리에 비밀을 저장하는 것은 좋지 않습니다. 리포지토리에 비밀이 있다는 경고를 받은 경우 비밀이 손상될 경우의 가치를 고려하여 취소하거나 변경해야 합니다.
- 감사는 GitHub 구성을 변경한 사용자를 파악합니다.
- 보안 개요는 조직의 리포지토리에 모든 보안 경고를 통합합니다.
Azure DevOps 감사 로그 사용
Azure DevOps는 파이프라인, 분기 정책, 리포지토리 및 기타 리소스를 변경한 사용자를 파악하는 데 도움이 되는 감사 로그를 제공합니다. 감사를 사용하도록 설정하고 감사 로그를 정기적으로 검토하는 것이 좋습니다.
리포지토리 및 파이프라인 보호
리포지토리 및 파이프라인에 적용할 수 있는 중요한 컨트롤에 대해 설명했습니다. 이제 이 단원의 앞부분에서 나열한 각 중요한 요소를 보호하는 데 사용할 수 있는 컨트롤을 살펴보겠습니다.
| 보호할 요소 | 적용할 컨트롤 |
|---|---|
| 액세스 권한이 있는 사용자와 수행할 수 있는 작업을 포함한 Azure DevOps 조직 또는 GitHub 리포지토리. |
|
| 리포지토리의 중요한 분기 및 해당 분기의 코드를 변경하기 위해 수행해야 하는 작업. | 분기 보호 규칙 또는 분기 정책을 적용합니다. |
| 인프라 정의, 테스트 및 애플리케이션 코드를 포함한 리포지토리 내의 코드. |
|
| 파이프라인 정의. | 코드 검토 요구 사항을 적용합니다. |
| 파이프라인을 실행하는 에이전트 또는 실행기. |
|
| 파이프라인 내에서 실행될 수 있는 타사 작업 또는 구성 요소. | 모든 타사 확장 및 작업과 관련된 보안 위험을 검토합니다. |
| 파이프라인에서 Azure 액세스에 사용하는 서비스 주체. |
|
| 파이프라인이 외부 시스템에 액세스하는 데 사용하는 비밀. |
|