보안 모범 사례

아티클
08/14/2024

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

특히 Azure DevOps Services와 같은 클라우드 기반 솔루션에서 정보 및 데이터를 처리하는 경우 보안이 최우선 순위여야 합니다. Microsoft는 기본 클라우드 인프라의 보안을 보장하지만 Azure DevOps 내에서 보안을 구성하는 것은 사용자의 책임입니다.

필수는 아니지만 모범 사례를 통합하면 환경을 크게 향상시키고 보안을 강화할 수 있습니다. 다음 권장 사항은 보안 Azure DevOps 환경을 유지 관리하는 데 도움이 되도록 설계되었습니다.

Azure DevOps 환경 보호

사용자를 제거하고, 감사 이벤트를 검토하고, Microsoft Entra ID와 통합하기 위해 다음 모범 사례를 사용합니다.

사용자 제거

MSA(Microsoft 계정)에서 비활성 사용자 제거: MSA를 사용하는 경우 조직 에서 비활성 사용자를 직접 제거합니다. 제거된 MSA 계정에 할당된 작업 항목에 대한 쿼리는 만들 수 없습니다.
Microsoft Entra 사용자 계정 사용 안 함 또는 삭제: Microsoft Entra ID에 연결된 경우 Azure DevOps 사용자 계정을 활성 상태로 유지하면서 Microsoft Entra 사용자 계정을 사용하지 않도록 설정하거나 삭제합니다. 이 작업을 사용하면 Azure DevOps 사용자 ID를 사용하여 작업 항목 기록을 계속 쿼리할 수 있습니다.
사용자 PAT 해지: 이러한 중요한 인증 토큰의 보안 관리를 보장하기 위해 기존 사용자 PAT를 정기적으로 검토하고 해지합니다.
개별 사용자에게 부여된 특별 사용 권한 취소: 최소 권한의 원칙에 부합하도록 개별 사용자에게 부여된 특수 권한을 감사하고 해지합니다.
제거된 사용자의 작업 다시 할당: 사용자를 제거하기 전에 작업 항목을 현재 팀 구성원에게 다시 할당하여 부하를 효과적으로 분산합니다.

Microsoft Entra ID 사용

통합 ID 시스템 설정: Microsoft Entra ID에 Azure DevOps를 연결하여 ID에 대한 단일 평면을 만듭니다. 이러한 일관성은 혼동을 줄이고 수동 구성 오류로 인한 보안 위험을 최소화합니다.
세분화된 거버넌스 구현: Microsoft Entra ID를 사용하여 다양한 리소스 범위의 특정 그룹에 다양한 역할 및 권한을 할당합니다. 이 작업은 제어된 액세스를 보장하고 보안 모범 사례에 부합합니다.
보안 기능 향상: 다음과 같은 Microsoft Entra ID를 사용하여 다른 보안 기능을 사용하도록 설정합니다.
- MFA(다단계 인증): 사용자 인증을 위해 암호 및 전화 확인과 같은 여러 요소가 필요합니다. 조건부 액세스 정책: 위치, 디바이스 또는 위험 수준과 같은 조건에 따라 액세스 규칙을 정의합니다.

자세한 내용은 다음 문서를 참조하세요.

감사 이벤트 검토

조직이 Microsoft Entra에 연결된 상태에서 다음 작업을 수행하여 보안을 강화하고 사용 패턴을 모니터링합니다.

감사 사용: 사용자 작업, 권한 및 변경 내용과 관련된 이벤트를 추적하고 봅니다.
감사 이벤트를 정기적으로 검토합니다. 특히 관리자 및 다른 사용자가 예기치 않은 사용 패턴을 찾습니다.

네트워크 보호

다음 함수는 Azure DevOps로 작업할 때 네트워크의 보안을 강화하는 효과적인 방법입니다.

IP 허용 목록 설정: 특정 IP 주소에 대한 액세스를 제한하여 신뢰할 수 있는 원본의 트래픽만 허용하여 공격 노출 영역을 줄입니다.
암호화 사용: 전송 중 및 미사용 데이터를 항상 암호화합니다. HTTPS와 같은 프로토콜을 사용하여 통신 채널을 보호합니다.
인증서 유효성 검사: 연결을 설정할 때 신뢰할 수 있는 기관에서 인증서가 유효하고 발급되었는지 확인합니다.
WAF(웹 애플리케이션 방화벽) 구현: 일반적인 공격에 대한 추가 보호 계층을 위해 WAF를 사용하여 악성 웹 기반 트래픽을 필터링, 모니터링 및 차단합니다.

자세한 내용은 애플리케이션 관리 모범 사례를 참조 하세요.

범위 권한

시스템은 개별, 컬렉션, 프로젝트 및 개체와 같은 다양한 수준에서 사용 권한을 처리하고 기본적으로 하나 이상의 기본 제공 그룹에 할당합니다. 보안을 강화하려면 다음 작업을 수행합니다.

최소 권한 액세스 제공: 사용자 및 서비스에 비즈니스 기능을 수행하는 데 필요한 최소 액세스 권한을 부여합니다.
상속 사용 안 함: 가능하면 상속을 사용하지 않도록 설정합니다. 상속은 기본적으로 허용 특성으로 인해 실수로 예기치 않은 사용자에게 액세스 또는 권한을 부여할 수 있습니다. 자세한 내용은 사용 권한 상속에 대한 섹션을 참조하세요.

사용 권한에 대한 자세한 내용은 다음 문서를 참조하세요.

프로젝트 수준 권한

프로젝트 및 리포지토리에 대한 액세스 제한: 프로젝트 및 리포지토리에 대한 액세스를 제한하여 중요한 정보를 유출하고 안전하지 않은 코드를 배포할 위험을 줄입니다. 기본 제공 또는 사용자 지정 보안 그룹 관리 권한을 사용합니다.
"공용 프로젝트 허용"을 사용하지 않도록 설정: 조직의 정책 설정에서 공용 프로젝트를 만드는 옵션을 사용하지 않도록 설정합니다. 필요에 따라 프로젝트 가시성을 공용에서 프라이빗으로 전환합니다. 로그인하지 않은 사용자는 공용 프로젝트에 대한 읽기 전용 액세스 권한을 가지지만 로그인한 사용자는 프라이빗 프로젝트에 대한 액세스 권한을 부여하고 허용된 변경을 수행할 수 있습니다.
프로젝트 만들기 제한: 사용자가 환경에 대한 제어를 유지하기 위해 새 프로젝트를 만들지 못하도록 합니다.

외부 게스트 액세스

외부 게스트 액세스 차단: 비즈니스가 필요하지 않은 경우 외부 게스트 액세스를 방지하기 위해 "모든 도메인에 초대를 보낼 수 있도록 허용" 정책을 사용하지 않도록 설정합니다.
고유한 전자 메일 또는 UPN 사용: 개인 및 비즈니스 계정에 대해 다른 전자 메일 주소 또는 UPN(사용자 계정 이름)을 사용하여 개인 계정과 회사 관련 계정 간의 모호성을 제거합니다.
외부 게스트 사용자 그룹: 모든 외부 게스트 사용자를 단일 Microsoft Entra 그룹에 배치하고 이 그룹에 대한 권한을 적절하게 관리합니다. 이러한 사용자에게 그룹 규칙이 적용되도록 직접 할당을 제거합니다.
규칙 정기적으로 다시 평가: 사용자 페이지의 그룹 규칙 탭에서 규칙을 정기적으로 검토합니다. 조직에 영향을 줄 수 있는 Microsoft Entra ID의 그룹 멤버 자격 변경을 고려합니다. Microsoft Entra ID는 동적 그룹 멤버 자격을 업데이트하는 데 최대 24시간이 걸릴 수 있으며, 규칙은 그룹 규칙이 변경될 때마다 24시간마다 자동으로 다시 평가됩니다.

자세한 내용은 Microsoft Entra ID의 B2B 게스트를 참조하세요.

보안 그룹 관리

보안 및 사용자 그룹

다음 표에서는 보안 그룹 및 사용자 그룹에 권한을 할당하기 위한 권장 사항을 보여 줍니다.

하다	안 함
많은 사용자를 관리할 때 Microsoft Entra ID, Active Directory 또는 Windows 보안 그룹을 사용합니다.	*프로젝트 유효한 사용자 그룹에 대한* 기본 사용 권한을 변경하지 마세요.** 이 그룹은 프로젝트 정보에 액세스하고 볼 수 있습니다. 자세한 내용은 유효한 사용자 그룹을 참조 하세요.
팀을 추가할 때 영역 경로, 반복 경로 및 쿼리를 만들고 수정해야 하는 팀 구성원에게 할당할 권한을 고려합니다.	다른 권한 수준을 포함하는 여러 보안 그룹에 사용자를 추가하지 마세요. 경우에 따라 거부 권한 수준이 허용 권한 수준을 재정의할 수 있습니다. 예를 들어 Azure DevOps 프로젝트에 개발자와 테스터라는 두 개의 보안 그룹이 있다고 상상해 보세요. 개발자 그룹에는 허용으로 설정된 작업 항목을 편집할 수 있는 권한이 있습니다. 그러나 몇 가지 주요 개인을 제외한 다른 사람이 특정 중요한 작업 항목을 편집하지 않도록 합니다. 이렇게 하려면 중요한 항목 편집기라는 새 보안 그룹을 만들고 작업 항목을 편집할 수 있는 권한을 이 그룹에 대해 거부로 설정합니다. 사용자가 개발자 그룹과 중요한 항목 편집기 그룹의 구성원인 경우 중요한 항목 편집기 그룹의 거부 권한이 개발자 그룹의 허용 권한보다 우선합니다. 따라서 개발자 그룹에 허용 권한이 있더라도 이 사용자는 중요한 작업 항목을 편집할 수 없습니다. 이 동작은 거부 권한이 엄격하게 적용되어 Azure DevOps 환경 내에서 중요한 작업에 대한 높은 수준의 보안 및 제어를 제공합니다.
많은 팀을 추가할 때 프로젝트 관리자가 사용할 수 있는 사용 권한의 하위 집합을 할당하는 팀 관리자 사용자 지정 그룹을 만드는 것이 좋습니다.	*프로젝트 유효한 사용자 그룹에 대한 기본 할당을* 변경하지 마세요.** 프로젝트 유효한 사용자 그룹 중 하나에 대해 보기 인스턴스 수준 정보를 제거하거나 거부로 설정하는 경우 그룹의 사용자는 사용 권한을 설정한 프로젝트, 컬렉션 또는 배포에 액세스할 수 없습니다.
프로젝트에 대한 작업 항목 쿼리를 만들고 공유하는 기능이 필요한 사용자 또는 그룹에 작업 항목 쿼리 폴더 참가 권한을 부여하는 것이 좋습니다.	*서비스 계정에만 할당으로 기록된 권한을 사용자 계정에* 할당하지 마세요.**
그룹을 가능한 한 작게 유지합니다. 액세스를 제한해야 하며 그룹을 자주 감사해야 합니다.
기본 제공 역할을 활용하고 개발자의 경우 기본적으로 기여자를 지정합니다. 관리자는 상승된 권한에 대해 프로젝트 관리자 보안 그룹에 할당되어 보안 권한을 구성할 수 있습니다.

관리 그룹에 대한 Just-In-Time 액세스

프로젝트 컬렉션 관리자 및 프로젝트 관리자 액세스 권한이 있는 경우 조직 또는 프로젝트의 구성을 수정할 수 있습니다. 이러한 기본 제공 관리자 그룹에 대한 보안을 강화하려면 Microsoft Entra PIM(Privileged Identity Management) 그룹을 사용하여 Just-In-Time 액세스를 구현하는 것이 좋습니다. 이 방법을 사용하면 필요한 경우에만 상승된 권한을 부여하여 영구 액세스와 관련된 위험을 줄일 수 있습니다.

액세스 구성

Microsoft Entra ID에서 역할 할당 가능 그룹을 만듭니다.
Azure DevOps 그룹에 Microsoft Entra 그룹을 추가합니다.

참고 항목

Microsoft Entra PIM(Privileged Identity Management) 그룹을 사용하여 Just-In-Time 액세스를 구성하는 경우 상승된 액세스 권한이 있는 사용자도 조직에 대한 표준 액세스를 유지하도록 합니다. 이렇게 하면 필요한 페이지를 보고 필요에 따라 사용 권한을 새로 고칠 수 있습니다.

액세스 사용

액세스를 활성화합니다.
Azure DevOps 에서 사용 권한을 새로 고칩니다.
관리자 액세스가 필요한 작업을 수행합니다.

참고 항목

사용자는 PIM 그룹 액세스가 비활성화된 후 최대 1시간 동안 Azure DevOps에서 상승된 액세스 권한을 가집니다.

서비스 계정 범위 지정

단일 용도 서비스 계정 만들기: 각 서비스에는 위험을 최소화하기 위한 전용 계정이 있어야 합니다. 일반 사용자 계정을 서비스 계정으로 사용하지 않습니다.
명명 및 설명서 규칙을 따릅니다. 서비스 계정에 명확하고 설명이 포함된 이름을 사용하고 해당 용도 및 관련 서비스를 문서화합니다.
사용되지 않는 서비스 계정 식별 및 사용 안 함: 더 이상 사용되지 않는 계정을 정기적으로 검토하고 식별합니다. 삭제를 고려하기 전에 사용하지 않는 계정을 사용하지 않도록 설정합니다.
권한 제한: 서비스 계정 권한을 필요한 최소 권한으로 제한합니다. 서비스 계정에 대한 대화형 로그인 권한을 사용하지 마세요.
보고서 읽기 프로그램에 별도의 ID 사용: 서비스 계정에 도메인 계정을 사용하는 경우 보고서 판독기 에서 다른 ID를 사용하여 사용 권한을 격리하고 불필요한 액세스를 방지합니다.
작업 그룹 설치에 로컬 계정 사용: 작업 그룹에 구성 요소를 설치할 때 사용자 계정에 로컬 계정을 사용합니다. 이 시나리오에서는 도메인 계정을 사용하지 않습니다.
서비스 연결 활용: 가능한 경우 서비스 연결을 사용하여 빌드에 직접 비밀 변수를 전달하지 않고 서비스에 안전하게 연결합니다. 특정 사용 사례에 대한 연결을 제한합니다.
서비스 계정 활동 모니터링: 감사를 구현하고 감사 스트림을 만들어 서비스 계정 활동을 모니터링합니다.

자세한 내용은 일반 서비스 연결 유형을 참조 하세요.

서비스 연결 범위 지정

서비스 연결 범위: Azure Resource Manager 서비스 연결 범위를 특정 리소스 및 그룹에 지정하여 액세스를 제한합니다. 전체 Azure 구독에서 광범위한 기여자 권한을 부여하지 않습니다.
워크로드 ID 페더레이션 사용: 비밀 없이 OIDC(OpenID Connect)를 사용하여 Azure 리소스로 인증합니다. Azure 구독에 대한 소유자 역할, Azure Stack 또는 Azure 미국 정부 환경에 연결되지 않는 경우 워크로드 ID 페더레이션을 자동으로 또는 수동으로 만들고 사용하는 Marketplace 확장 작업을 지원합니다.
리소스 그룹 범위: 리소스 그룹에 빌드 프로세스에 필요한 VM(Virtual Machines) 또는 리소스만 포함되어 있는지 확인합니다.
클래식 서비스 연결 방지: 범위 지정 옵션이 부족한 클래식 서비스 대신 최신 Azure Resource Manager 서비스 연결을 선택합니다.
용도별 팀 서비스 계정 사용: 용도별 팀 서비스 계정을 사용하여 서비스 연결을 인증하여 보안 및 제어를 유지합니다.

자세한 내용은 일반 서비스 연결 유형을 참조 하세요.

적합한 인증 방법 선택

다음 원본에서 인증 방법을 선택합니다.

서비스 주체 및 관리 ID 고려
개인용 액세스 토큰(PAT)을 아끼고 사용

서비스 주체 고려

서비스 주체 및 관리 ID와 같은 대안을 살펴봅니다.

서비스 주체 사용: Microsoft Entra 애플리케이션 내의 보안 개체를 나타냅니다. 애플리케이션이 지정된 테넌트에서 수행할 수 있는 작업을 정의합니다. Azure Portal에서 애플리케이션 등록 중에 설정합니다. Azure DevOps를 포함하여 Azure 리소스에 액세스하도록 구성합니다. 특정 액세스 및 제어가 필요한 앱에 유용합니다.
관리 ID 사용: 애플리케이션의 서비스 주체와 유사합니다. Azure 리소스에 대한 ID를 제공합니다. Microsoft Entra 인증을 지원하는 서비스에서 자격 증명을 공유하도록 허용합니다. Azure는 자격 증명 관리 및 회전을 자동으로 처리합니다. 원활한 로그인 세부 정보 관리에 적합합니다.

PAT를 아파르게 사용

특정 역할에 대한 PAT 범위: 특정 작업에 필요한 권한만 PAT에 할당합니다. 실수로 인한 오용의 위험을 최소화하기 위해 여러 조직 또는 리포지토리에 대한 전역 액세스 권한을 부여하지 않습니다.
빌드 및 릴리스에 대한 쓰기 또는 관리 권한을 사용하지 마세요. PAT에는 빌드, 릴리스 또는 기타 중요한 리소스에 대한 쓰기 또는 관리 권한이 없어야 합니다. 이러한 권한을 제한하면 파이프라인 또는 배포에 영향을 줄 수 있는 의도하지 않은 작업을 방지할 수 있습니다.
만료 날짜를 설정하고 PAT를 비밀로 유지합니다 . 항상 PAT의 만료 날짜를 설정합니다. 필요에 따라 정기적으로 검토하고 갱신합니다. PAT를 암호로 중요하게 처리하여 기밀로 유지하고 애플리케이션 코드에서 공개 공유 또는 하드코딩을 방지합니다.
애플리케이션 코드 에서 PAT를 하드 코딩하지 마세요. 코드에 직접 PAT를 포함하는 대신 보안 구성 파일 또는 환경 변수를 사용하여 PAT를 동적으로 저장하고 검색합니다. 동적.
사용하지 않는 PAT를 정기적으로 감사 및 해지: 관리자는 REST API를 사용하여 모든 PAT를 주기적으로 검토해야 합니다. 더 이상 필요하지 않거나 권장 조건을 충족하지 않는 모든 PAT를 취소합니다.

자세한 내용은 관리자 및 PAT 사용에 대한 정책을 사용하여 PAT 관리를 참조하세요.

Azure Artifacts 보호

피드, 프로젝트 및 프로젝트 컬렉션 관리자 간의 차이점을 이해해야 합니다. 자세한 내용은 Azure Artifacts 설정 구성을 참조 하세요.
피드 권한을 설정합니다.

Azure Boards 보호

프로세스를 사용자 지정하기 전에 Azure Boards 를 구성하고 사용자 지정합니다.
작업 추적 및 계획 권한 설정
Azure Boards에 대한 기본 권한 및 액세스 권한 알아보기
쿼리 권한 설정

Azure Pipelines 보호

정책

외부 검토자 필요: 철저한 검토 프로세스를 위해 원래 요청자 외부에 하나 이상의 검토자가 있는지 확인합니다. 승인자는 잠재적인 영향에 대한 변경 내용 및 책임에 대한 공동 소유권을 공유합니다.
전달하려면 CI 빌드 필요: PR을 병합하기 전에 CI(연속 통합) 빌드를 통과하도록 요구하여 코드 품질에 대한 기준을 설정합니다. CI 검사에는 코드 린팅, 단위 테스트 및 보안 검사가 포함됩니다.
자체 승인 허용 안 함: 원래 PR 요청자가 자신의 변경 내용을 승인하지 못하도록 방지하여 편견 없는 검토 프로세스를 보장하고 이해 상충을 방지합니다.
"대기" 또는 "거부" 투표 로 PR 완성 허용: 일부 검토자가 기다리거나 거부하도록 투표하는 경우에도 PR 완료를 방지하여 병합하기 전에 모든 피드백을 처리하도록 장려합니다.
변경 내용에 대한 검토자 투표 다시 설정: 최근 변경 내용이 PR에 푸시될 때 검토자 투표를 다시 설정하여 검토자가 업데이트된 코드를 다시 평가하도록 합니다.
릴리스 파이프라인 잠금: 릴리스 파이프라인을 특정 분기(일반적으로 프로덕션 또는 주)로 제한하여 다른 분기에서 실수로 배포하지 않도록 합니다.
큐 시간에 설정 가능한 변수 적용: 파이프라인 변수에 대해 "큐 시간에 settable 적용" 옵션을 사용하도록 설정하여 사용자가 파이프라인 실행 중에 변수 값을 재정의하지 못하도록 합니다.
편집 기에서 변수 재정의 허용: 파이프라인 편집기에서 설정된 변수의 경우 일관성을 유지하고 의도하지 않은 변경을 방지하기 위해 사용자 재정의를 허용하지 않습니다.

에이전트

권한 부여: 공격 노출 영역을 줄이기 위해 필요한 가장 작은 계정 집합으로 권한을 제한합니다.
에이전트에 대한 제한적인 방화벽 구성: 에이전트가 작동하도록 허용하면서 방화벽을 최대한 제한적으로 설정하여 보안 및 유용성의 균형을 유지합니다.
정기적으로 에이전트 풀 업데이트: 에이전트를 정기적으로 업데이트하여 에이전트를 최신 상태로 유지하여 취약한 코드가 실행되지 않도록 하여 악용 위험을 줄입니다.
프로덕션 아티팩트용으로 별도의 에이전트 풀을 사용합니다. 고유 에이전트 풀을 사용하여 프로덕션 아티팩트를 격리하여 실수로 배포하지 않도록 방지합니다생산 분기.
중요한 풀 세그먼트: 중요한 워크로드와 민감하지 않은 워크로드에 대해 별도의 풀을 만듭니다. 적절한 풀과 연결된 빌드 정의에서만 자격 증명을 허용합니다.

정의

파이프라인 정의에 YAML 사용: 더 나은 추적 기능과 승인 지침 및 버전 제어 방법을 준수하기 위해 YAML(Yet Another Markup Language)을 사용하여 파이프라인을 정의합니다.
파이프라인 정의에 대한 편집 액세스 제한: 파이프라인 정의 편집에 대한 액세스를 필요한 최소 계정으로 제한하여 우발적이거나 무단 변경의 위험을 줄입니다.

입력

빌드 스크립트에 변수에 대한 검사 포함: 설정 가능한 변수를 통해 잠재적인 명령 삽입 공격을 완화하기 위해 빌드 스크립트 내에서 검사를 구현합니다. 입력 값의 유효성을 검사하고 의도하지 않거나 악의적인 명령을 방지합니다.
"릴리스 시 설정 가능" 빌드 변수 제한: 릴리스 시간에 설정할 수 있는 빌드 변수 수를 최소화하여 공격 표면을 줄이고 구성 관리를 간소화합니다.

작업

원격으로 가져온 리소스를 방지합니다. 가능하면 빌드 프로세스 중에 외부 URL에서 리소스를 가져오지 마세요. 원격 리소스가 필요한 경우 버전 관리 및 해시 검사를 사용하여 무결성을 보장합니다.
비밀 로깅 방지: 의도하지 않은 노출 및 보안 손상을 방지하기 위해 빌드 로그에 비밀 또는 자격 증명과 같은 중요한 정보를 기록하지 마세요.
비밀에 Azure Key Vault 사용: 파이프라인 변수에 직접 비밀을 저장하는 대신 Azure Key Vault를 사용하여 비밀을 안전하게 관리하고 검색합니다.
임의의 분기 또는 태그에 대해 빌드 실행 제한: 보안에 중요한 파이프라인의 경우 사용자가 분기 또는 태그에 대해 빌드를 실행하지 못하도록 제한합니다. 실수로 실행되거나 권한이 없는 실행을 방지하기 위해 권한이 부여된 특정 분기 또는 태그를 정의합니다.
파이프라인 권한에 대한 상속 사용 안 함: 상속된 사용 권한은 지나치게 광범위할 수 있으며 요구 사항을 정확하게 반영하지 못할 수 있습니다. 상속을 사용하지 않도록 설정하고 보안 요구 사항에 맞게 명시적으로 권한을 설정합니다.
작업 권한 부여 범위 제한: 항상 작업 권한 부여 범위를 필요한 최소로 제한합니다. 각 작업에서 수행하는 특정 작업에 따라 사용 권한을 미세 조정합니다.

리포지토리 및 분기

최소 검토자 수 필요: 모든 끌어오기 요청이 적어도 두 명의 승인자로부터 검토를 받도록 정책을 사용하도록 설정하여 철저한 코드 검토 및 책임을 홍보합니다.
리포지토리별 보안 정책 구성: 위험을 줄이고, 변경 관리 표준을 적용하고, 코드 품질을 향상시키기 위해 프로젝트 차원의 정책 대신 각 리포지토리 또는 분기에 보안 정책을 조정합니다.
별도의 키 자격 증명 모음에서 프로덕션 비밀 격리: 프로덕션 비밀을 Azure Key Vault에 별도로 저장하고 비프로덕션 빌드에서 분리를 유지하기 위해 알아야 할 기준으로 액세스를 제한합니다.
프로덕션에서 테스트 환경 분리: 비프로덕션 컨텍스트에서 자격 증명 및 비밀이 사용되지 않도록 테스트 환경을 프로덕션 환경과 혼합하지 마세요.
포크 사용 안 함: 포크를 사용하지 않도록 설정하면 포크의 확산을 방지하여 보안을 관리할 수 있으므로 모든 복사본에서 보안을 더 쉽게 추적할 수 있습니다.
포크 빌드에 비밀을 제공하지 않음: 포크된 빌드와 비밀을 공유하여 비밀을 기밀로 유지하고 포크에 노출되지 않도록 합니다.
포크 빌드를 수동으로 트리거하는 것이 좋습니다. 자동 트리거가 보안 검사에 대한 더 나은 제어를 제공하는 대신 포크에 대한 빌드를 수동으로 트리거합니다.
포크 빌드에 Microsoft 호스팅 에이전트 사용: 유지 관리되고 안전한 포크된 빌드에 Microsoft 호스팅 에이전트를 사용합니다.
Git 리포지토리에서 프로덕션 빌드 정의 검사: 정기적으로 프로젝트의 Git 리포지토리에 저장된 프로덕션 빌드 정의를 확인하여 자격 증명 또는 중요한 정보를 확인합니다.
프로덕션 컨텍스트에 대한 분기 제어 검사 구성: 생산 분기 컨텍스트에서 실행되는 파이프라인에 대한 중요한 연결(예: prod-connection)의 사용을 제한하여 적절한 권한 부여를 보장하고 우발적인 오용을 방지하도록 분기 제어 검사를 설정합니다.

자세한 내용은 기타 보안 고려 사항을 참조 하세요.

Azure Repos 보호

Azure Test Plans 보호

GitHub 통합 보안

PAT 대신 OAuth 흐름 사용: GitHub 서비스 연결에 PAT 기반 인증을 사용하지 않도록 설정하고 더 나은 보안 및 통합을 위해 OAuth 흐름을 선택합니다.
관리자 또는 소유자 ID 방지: 리포지토리의 관리자 또는 소유자인 ID를 사용하여 GitHub 서비스 연결을 인증하지 마세요. 사용 권한을 필요한 수준으로 제한합니다.
전체 범위 GitHub PAT 방지: 전체 범위 GitHub PAT를 사용하여 서비스 연결을 인증하지 않습니다. 필요한 최소 권한으로 토큰을 사용합니다.
개인 GitHub 계정을 서비스 연결로 사용하지 마세요. Azure DevOps에서 개인 GitHub 계정을 서비스 연결로 사용하지 마세요. 대신 전용 서비스 계정을 만들거나 조직 수준 계정을 사용합니다.

다음을 통해 공유