Share via

보안 모범 사례

  • 아티클

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

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

필수는 아니지만 Azure DevOps를 사용하는 동안 모범 사례를 통합하면 환경을 개선하고 보안을 강화할 수 있습니다. Azure DevOps 환경을 안전하게 유지하는 것을 목표로 하는 다음 모범 사례를 컴파일했습니다.

Azure DevOps 환경 보호

사용자 제거

  • 조직에서 MSA 계정을 사용하는 경우 액세스를 방지할 다른 방법이 없으므로 조직에서 직접 비활성 사용자를 제거합니다. 이렇게 하면 제거된 사용자 계정에 할당된 작업 항목에 대한 쿼리를 만들 수 없습니다. 자세한 내용은 Azure DevOps에서 사용자 삭제를 참조 하세요.
  • 조직이 Microsoft Entra ID에 연결된 경우 Microsoft Entra 사용자 계정을 사용하지 않도록 설정하거나 삭제하고 Azure DevOps 사용자 계정을 활성 상태로 둘 수 있습니다. 이러한 방식으로 Azure DevOps 사용자 ID를 사용하여 작업 항목 기록을 계속 쿼리할 수 있습니다.
  • 사용자 PAT를 해지합니다.
  • 개별 사용자 계정에 부여되었을 수 있는 특별한 권한을 취소합니다.
  • 제거하려는 사용자의 작업을 현재 팀 구성원에게 다시 할당합니다.

Microsoft Entra ID 사용

Id에 대한 단일 평면을 갖도록 Azure DevOps를 Microsoft Entra ID와 통합합니다. 일관성 및 단일 신뢰할 수 있는 원본은 명확성을 높이고 사용자 오류 및 구성 복잡성으로 인한 보안 위험을 줄입니다. 거버넌스를 종료하는 핵심은 여러 역할 할당을 갖는 것입니다(역할 정의가 다르고 동일한 Microsoft Entra 그룹에 대한 리소스 범위가 서로 다름). Microsoft Entra ID가 없으면 조직 액세스를 제어할 책임이 있습니다.

또한 Microsoft Entra ID를 사용하면 다단계 인증 또는 기타 조건부 액세스 정책과 같은 다른 보안 기능에 액세스할 수 있습니다.

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

감사 이벤트 검토

Microsoft Entra 지원 조직이 있으면 보안 정책에서 감사를 켤 수 있습니다. 감사 이벤트를 주기적으로 검토하여 관리자 및 다른 사용자의 예기치 않은 사용 패턴을 모니터링하고 대응합니다.

네트워크 보호

이렇게 하는 몇 가지 방법은 다음과 같습니다.

  • 특정 IP를 제한하도록 허용 목록을 설정합니다.
  • 항상 암호화를 사용합니다.
  • 인증서의 유효성을 검사합니다.
  • WAF(웹 애플리케이션 방화벽)를 구현하여 Azure DevOps와 악의적인 웹 기반 트래픽을 필터링, 모니터링 및 차단할 수 있습니다.
  • 자세한 내용은 애플리케이션 관리 모범 사례에 대한 이 지침을 참조하세요.

범위가 지정된 권한

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

프로젝트 수준 권한

  • 중요한 정보를 유출하고 안전하지 않은 코드를 프로덕션에 배포할 위험을 줄이기 위해 프로젝트 및 리포지토리에 대한 액세스를 제한합니다.
  • 기본 제공 보안 그룹 또는 사용자 지정 보안 그룹을 사용하여 사용 권한을 관리합니다. 자세한 내용은 작업을 선택할 수 있는 권한 부여 또는 제한을 참조 하세요.
  • 조직의 정책 설정에서 "공개 프로젝트 허용"을 사용하지 않도록 설정하여 모든 조직 사용자가 공용 프로젝트를 만들지 못하도록 합니다. Azure DevOps Services를 사용하면 프로젝트의 가시성을 퍼블릭에서 프라이빗으로, 그 반대로 변경할 수 있습니다. 사용자가 조직에 로그인하지 않은 경우 공용 프로젝트에 대한 읽기 전용 액세스 권한이 있습니다. 사용자가 로그인한 경우 프라이빗 프로젝트에 대한 액세스 권한을 부여하고 허용된 변경 내용을 적용할 수 있습니다.
  • 사용자가 새 프로젝트를 만들도록 허용하지 않습니다.

외부 게스트 액세스

  • "할 일기본 초대를 보낼 수 있도록 허용" 정책을 사용하지 않도록 설정하여 외부 게스트 액세스를 완전히 차단합니다. 비즈니스가 필요하지 않은 경우 그렇게 하는 것이 좋습니다.
  • 허용되더라도 개인 및 비즈니스 계정에 다른 메일 또는 UPN(사용자 계정 이름)을 사용합니다. 이 작업을 수행하면 이메일/UPN이 동일한 경우 비즈니스와 개인 계정 간에 명확하게 구분할 수 없습니다.
  • 모든 외부 게스트 사용자를 단일 Microsoft Entra 그룹에 배치하고 해당 그룹의 권한을 적절하게 관리합니다. 이러한 방식으로 쉽게 관리하고 감사할 수 있습니다.
    • 그룹 규칙이 해당 사용자에게 적용되도록 직접 할당을 제거합니다. 자세한 내용은 액세스 수준을 할당하는 그룹 규칙 추가를 참조 하세요.
    • 사용자 페이지의 그룹 규칙 탭에서 정기적으로 규칙을 다시 평가합니다. Microsoft Entra ID의 그룹 멤버 자격 변경이 조직에 영향을 줄 수 있는지 여부를 명확히 합니다. Microsoft Entra ID는 동적 그룹 멤버 자격을 업데이트하는 데 최대 24시간이 걸릴 수 있습니다. 24시간마다 그룹 규칙이 변경될 때마다 규칙이 시스템에서 자동으로 다시 평가됩니다.
  • 자세한 내용은 Microsoft Entra ID의 B2B 게스트를 참조하세요.

보안 그룹 관리

보안 및 사용자 그룹

보안 그룹 및 사용자 그룹에 권한을 할당하기 위한 다음 권장 사항을 참조하세요.

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

자세한 내용은 유효한 사용자 그룹을 참조 하세요.

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

Project Collection 관리istrator 및 Project 관리istrator 액세스 권한이 있는 경우 조직 또는 프로젝트의 구성을 변경할 수 있습니다. 이러한 기본 제공 관리자 그룹에 대한 액세스를 보호하려면 Microsoft Entra PIM(Privileged Identity Management) 그룹을 사용하여 Just-In-Time 액세스가 필요합니다.

액세스 구성

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

참고 항목

PIM 그룹을 사용하여 상승된 액세스 권한이 있는 사용자도 조직에 대한 표준 액세스 권한이 있는지 확인하여 페이지를 보고 권한을 새로 고칠 수 있습니다.

액세스 사용

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

참고 항목

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

서비스 계정 범위 지정

  • 서비스 계정에 대화형 로그인 권한이 없는지 확인 합니다 .
  • 서비스 계정 권한을 필요한 최소 권한으로 제한합니다.
  • 서비스 계정에 대해 기본 계정을 사용하는 경우 보고서 판독기 계정에 다른 ID를 사용합니다. 자세한 내용은 서비스 계정 및 종속성을 참조 하세요.
  • 작업 그룹에 구성 요소를 설치하는 경우 사용자 계정에 로컬 계정을 사용합니다. 자세한 내용은 서비스 계정 요구 사항을 참조 하세요.
  • 가능하면 서비스 연결을 사용합니다. 서비스 연결은 비밀 변수를 빌드에 직접 전달할 필요 없이 다양한 서비스에 연결하는 보안 메커니즘을 제공합니다. - 이러한 연결을 사용해야 하는 특정 위치로 제한하고 더 이상 사용하지 않습니다.
  • 서비스 계정 활동을 모니터링하고 감사 스트리밍을 만듭니 다. 감사를 사용하면 의심스러운 로그인 및 활동을 감지하고 대응할 수 있습니다.
  • 자세한 내용은 일반 서비스 연결 유형을 참조 하세요.

서비스 연결 범위 지정

  • Azure Resource Manager 및 기타 서비스 연결의 범위를 액세스가 필요한 리소스 및 그룹에만 적용합니다. 서비스 연결에는 전체 Azure 구독에 대한 광범위한 기여자 권한이 없어야 합니다.
  • ARM(Azure Resource Manager) 서비스 연결에 워크로드 ID 페더레이션을 사용합니다. 워크로드 ID 페더레이션을 사용하면 Azure Pipelines에서 Azure에 대한 비밀 없는 서비스 연결을 만들 수 있습니다.
  • 사용자에게 Azure 구독에 대한 일반 또는 광범위한 기여자 권한을 부여하지 마세요.
  • 사용 권한의 범위를 지정하는 방법은 없으므로 Azure 클래식 서비스 연결을 사용하지 마세요.
  • 리소스 그룹에 빌드에 액세스해야 하는 VM(Virtual Machines) 또는 리소스만 포함되어 있는지 확인합니다.
  • 용도별 팀 서비스 계정을 사용하여 서비스 연결을 인증합니다.
  • 자세한 내용은 일반 서비스 연결 유형을 참조 하세요.

올바른 인증 방법 선택

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

서비스 주체 고려

Microsoft Entra 토큰을 사용하여 Azure DevOps 리소스에 액세스할 수 있는 서비스 주체 및 관리 ID와 같은 대안을 살펴봅니다. 이러한 토큰은 PAT에 비해 유출될 때 위험이 적으며 손쉬운 자격 증명 관리와 같은 이점을 포함합니다.

PAT를 아파르게 사용

가능하면 애플리케이션 코드로 키를 안전하게 관리하는 것이 어려우며 GitHub와 같은 공용 코드 리포지토리에 중요한 액세스 키를 실수로 게시하는 등의 실수가 발생할 수 있으므로 암호화 키 대신 인증에 항상 ID 서비스를 사용하는 것이 좋습니다. 그러나 개인용 액세스 토큰(PAT)을 사용해야 하는 경우 다음 지침을 고려합니다.

  • PAT는 항상 특정 역할로 범위가 지정되어야 합니다.

  • PAT는 여러 조직에 대한 전역 액세스를 제공해서는 안 됩니다.

  • PAT는 빌드 또는 릴리스에 대한 쓰기 또는 관리 권한을 부여해서는 안 됩니다.

  • PAT는 만료 날짜가 있어야 하며 암호만큼 중요하므로 비밀로 유지되어야 합니다.

  • 코드를 간소화하려는 경우에도 PAT는 애플리케이션 코드에서 하드 코딩되어서는 안 됩니다.

  • 관리주체는 다음을 사용하여 모든 PAT를 정기적으로 감사해야 합니다.REST API 및 위의 조건을 충족하지 않는 모든 API를 취소합니다.

  • PAT를 비밀로 유지합니다. 토큰은 암호만큼 중요합니다.

  • 토큰을 안전한 장소에 저장합니다.

  • 애플리케이션에서 하드 코드 토큰을 사용하지 마세요. 오랜 시간 동안 토큰을 가져오고 애플리케이션에 저장하기 위해 코드를 간소화할 수 있지만 그렇게 하지 마세요.

  • 토큰에 만료 날짜를 지정합니다.

  • 자세한 내용은 다음 문서를 검사.

Azure Artifacts 보호

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

Azure Boards 보호

Azure Pipelines 보호

  • 확장 템플릿을 사용합니다.
  • 파이프라인에 대한 사용 권한 수준을 설정하는 방법에 대한 자세한 내용은 파이프라인 사용 권한 설정을 참조 하세요.
  • Azure Pipelines 보안 모범 사례에 대한 자세한 내용은 Azure Pipelines 보안을 참조 하세요.

정책

  • 원래 요청자 외부에 하나 이상의 검토자가 필요합니다. 승인자는 변경 내용의 공동 소유자를 공유하며 잠재적 영향에 대해 동등하게 책임을 져야 합니다.
  • 통과하려면 CI 빌드 필요. 이 요구 사항은 바이러스 및 자격 증명 검사와 같은 코드 린팅, 단위 테스트 및 보안 검사 통해 기준 코드 품질을 설정하는 데 유용합니다.
  • 원래 끌어오기 요청자가 변경을 승인할 수 없는지 확인합니다.
  • 일부 검토자가 기다리거나 거부하도록 투표하는 경우에도 PR(끌어오기 요청)의 완료를 허용하지 않습니다.
  • 최근 변경 내용이 푸시되면 코드 검토자 투표를 다시 설정합니다.
  • 특정 생산 분기 실행하여 릴리스 파이프라인을 잠급니다.
  • 조직의 파이프라인 설정에서 "변수에 대해 큐 시간에 settable 적용"을 사용하도록 설정합니다.
  • 편집기에서 설정된 변수에 대해 "사용자가 이 파이프라인을 실행할 때 이 값을 재정의하도록 허용"을 허용하지 마세요.

에이전트

  • 가능한 가장 적은 수의 계정에 권한을 부여합니다.
  • 에이전트를 사용할 수 있는 가장 제한적인 방화벽이 있습니다.
  • 빌드 플릿이 악의적인 행위자가 악용할 수 있는 취약한 코드를 실행하지 않도록 풀을 정기적으로 업데이트합니다.
  • 프로덕션에 배송되거나 배포되는 빌드 아티팩트를 위해 별도의 에이전트 풀을 사용합니다.
  • 민감하지 않은 풀에서 "중요한" 풀을 분할하고 해당 풀에 잠긴 빌드 정의에서만 자격 증명을 사용하도록 허용합니다.

정의

  • YAML(Yet Another Markup Language)을 사용하여 파이프라인 정의를 관리합니다. YAML은 변경에 대한 추적 가능성을 제공하고 승인 지침을 따를 수 있으므로 파이프라인 정의를 관리하는 데 선호되는 방법입니다.
  • 파이프라인 정의 보호 최소 계정 수에 대한 액세스 편집

입력

  • 빌드 스크립트에 변수에 대한 온전성 검사 포함합니다. 정신 검사 설정 가능한 변수를 통해 명령 삽입 공격을 완화할 수 있습니다.
  • 가능한 한 적은 수의 빌드 변수를 "릴리스 시 설정 가능"으로 설정합니다.

작업

  • 원격으로 가져온 리소스는 피하지만 필요한 경우 버전 관리 및 해시 검사 사용합니다.
  • 비밀을 기록하지 마세요.
  • 파이프라인 변수에 비밀을 저장하지 말고 Azure Key Vault를 사용합니다. 정기적으로 빌드 파이프라인을 검사하여 비밀이 빌드 파이프라인 변수에 저장되지 않는지 확인합니다.
  • 사용자가 보안에 중요한 파이프라인에서 임의의 분기 또는 태그에 대해 빌드를 실행하도록 허용하지 마세요.
  • 상속된 사용 권한이 광범위하고 사용 권한에 대한 요구 사항을 정확하게 반영하지 않으므로 파이프라인에서 상속을 사용하지 않도록 설정합니다.
  • 모든 경우에 작업 권한 부여 범위를 제한합니다.

리포지토리 및 분기

  • "최소 검토자 수 필요" 정책을 설정하여 승인자가 모든 끌어오기 요청을 검토하도록 합니다.
  • 프로젝트 전체 대신 각 리포지토리 또는 분기와 관련된 보안 정책을 구성합니다. 보안 정책은 위험을 줄이고, 변경 관리 표준을 적용하며, 팀의 코드 품질을 향상시킵니다.
  • 프로덕션 비밀을 별도의 Key Vault에 저장하고 비프로덕션 빌드를 별도로 유지하기 위해 필요한 경우에만 액세스 권한을 부여합니다.
  • 자격 증명 사용을 포함하여 테스트 환경을 프로덕션 환경과 혼합하지 마세요.
  • 포크를 사용하지 않도록 설정합니다. 포크가 많을수록 각 포크의 보안을 추적하기가 더 어려워집니다. 또한 사용자는 리포지토리의 복사본을 자신의 개인 계정에 쉽게 포크할 수 있습니다.
  • 포크 빌드에 대한 비밀을 제공하지 마세요.
  • 포크 빌드를 수동으로 트리거하는 것이 좋습니다.
  • 포크 빌드에 Microsoft 호스팅 에이전트를 사용합니다.
  • Git의 경우 프로젝트의 git 리포지토리에서 프로덕션 빌드 정의를 검사 자격 증명을 검색할 수 있습니다.
  • 분기의 컨텍스트 production 에서 실행되는 파이프라인만 사용할 수 prod-connection있도록 분기 컨트롤 검사 구성합니다.
  • 자세한 내용은 기타 보안 고려 사항을 참조 하세요.

Azure Repos 보호

Azure Test Plans 보호

GitHub 통합 보안

  • PAT(개인 액세스 토큰) 기반 인증을 사용하지 않도록 설정하면 OAuth 흐름이 GitHub 서비스 연결과 함께 사용됩니다.
  • GitHub 서비스 연결을 리포지토리의 관리자 또는 소유자인 ID로 인증하지 마세요.
  • 전체 범위 GitHub PAT(개인용 액세스 토큰)를 사용하여 GitHub 서비스 연결을 인증하지 마세요.
  • Azure DevOps와의 서비스 연결로 개인 GitHub 계정을 사용하지 마세요.