향상된 보안 관리

이 업데이트를 사용하면 이제 전체 프로젝트 또는 organization 고급 보안을 사용하거나 사용하지 않도록 설정할 수 있습니다. 새로 만든 리포지토리 또는 프로젝트에 대해 고급 보안을 자동으로 사용하도록 설정할 수도 있습니다.

Azure Pipelines에서는 포크된 GitHub 리포지토리에서 빌드된 끌어오기 요청의 보안을 개선하기 위해 중앙 집중식 컨트롤을 추가했습니다.

이러한 기능에 대해 자세히 알아보려면 릴리스 정보를 확인하세요.

일반

• 고급 보안을 위한 프로젝트 및 organization 수준 사용

• 고급 보안 사용 중 예상 커밋자 수

Azure Pipelines

• 승인 및 확인 시간이 초과된 경우 스테이지 다시 시도

• 모든 환경에 대한 관리자 역할

• 포크된 GitHub 리포지토리에서 PR을 빌드하기 위한 중앙 집중식 제어

Azure Repos

• 사용자가 자신의 변경 내용을 승인할 수 없도록 하는 새로운 "분기 정책"

Azure Artifacts

• 화물 상자에 대한 Azure Artifacts 지원 소개(공개 미리 보기)

일반

고급 보안을 위한 프로젝트 및 organization 수준 사용

이제 전체 프로젝트 또는 organization 고급 보안을 사용하거나 사용하지 않도록 설정할 수 있습니다. 활성화 전에 커밋자 수를 표시하는 새로운 추가와 함께 프로젝트 또는 organization 수준에서 "모두 사용"을 선택하면 요금이 청구될 수 있는 새 활성 커밋자 수를 예상할 수 있습니다. 또한 해당 프로젝트 또는 organization 따라 새로 만든 리포지토리 또는 프로젝트에 대해 Advanced Security를 자동으로 사용하도록 선택할 수도 있습니다. 이 설정을 통해 사용하도록 설정된 모든 리포지토리에는 비밀 리포지토리 검사 및 푸시 보호가 활성화됩니다.

프로젝트 수준 사용:

조직 수준 사용:

고급 보안 사용 중 예상 커밋자 수

고급 보안 온보딩 환경의 일부로, 이제 특정 리포지토리, 프로젝트 또는 organization 대해 Advanced Security를 사용하도록 설정한 결과로 추가되었을 수 있는 활성 커밋자 수를 예측할 수 있습니다. 이 개수는 근사치이며 제공된 추정치와 사용 후 청구에 대해 보고된 값 간에 약간의 불일치가 표시될 수 있습니다. 이 예상은 API를 통해 얻을 수 있으며 이 프로세스를 설명하는 추가 설명서가 곧 제공될 예정입니다.

Azure Pipelines

승인 및 확인 시간이 초과된 경우 스테이지 다시 시도

승인 및 확인 시간이 초과되면 해당 승인이 속한 단계를 건너뜁니다. 건너뛴 스테이지에 대한 종속성이 있는 스테이지도 건너뜁습니다.

이제 승인을 받고 시간 초과를 확인하는 단계를 다시 시도할 수 있습니다. 이전에는 승인 시간이 초과된 경우에만 이 작업을 수행할 수 있었습니다.

모든 환경에 대한 관리자 역할

YAML 파이프라인의 환경은 애플리케이션을 배포하는 컴퓨팅 리소스(예: AKS 클러스터 또는 VM 집합)를 나타냅니다. 배포에 대한 보안 제어 및 추적 기능을 제공합니다.

환경 관리는 매우 어려울 수 있습니다. 이는 환경을 만들 때 환경을 만드는 사람이 자동으로 단독 관리자가 되기 때문입니다. 예를 들어 모든 환경의 승인 및 검사를 중앙 집중식으로 관리하려는 경우 모든 환경 관리자에게 특정 사용자 또는 그룹을 관리자로 추가한 다음 REST API를 사용하여 검사를 구성하도록 요청해야 했습니다. 이 방법은 지루하고 오류가 발생하기 쉬울 수 있으며 새 환경이 추가될 때 크기가 조정되지 않습니다.

이 스프린트를 통해 환경 허브 수준에서 관리자 역할을 추가했습니다. 이렇게 하면 환경이 서비스 연결 또는 에이전트 풀과 동등합니다. 사용자 또는 그룹에 관리자 역할을 할당하려면 이미 environments-hub 관리자 또는 organization 소유자여야 합니다.

이 관리자 역할이 있는 사용자는 모든 환경을 관리, 관리, 보기 및 사용할 수 있습니다. 여기에는 모든 파이프라인에 대한 환경 열기가 포함됩니다.

환경 허브 수준에서 사용자 관리자 역할을 부여하면 모든 기존 환경 및 향후 환경에 대한 관리자가 됩니다.

포크된 GitHub 리포지토리에서 PR을 빌드하기 위한 중앙 집중식 제어

GitHub에서 퍼블릭 리포지토리를 빌드하는 경우 포크 빌드에 대한 입장을 고려해야 합니다. 포크는 조직 외부에서 나오기 때문에 특히 위험합니다.

GitHub 리포지토리 및 리포지토리 보호를 빌드하는 방법에 대한 권장 사항을 검토하여 GitHub 퍼블릭 리포지토리를 빌드하는 파이프라인의 보안을 개선할 수 있습니다. 아쉽게도 수많은 파이프라인을 관리하고 모범 사례를 준수하도록 하려면 상당한 노력이 필요할 수 있습니다.

파이프라인의 보안을 강화하기 위해 파이프라인이 분기된 GitHub 리포지토리에서 PR을 빌드하는 방법을 정의하기 위한 organization 수준 제어를 추가했습니다. 새 설정의 이름은 포크된 GitHub 리포지토리에서 끌어오기 요청 빌드 제한이며 organization 및 프로젝트 수준에서 작동합니다.

organization 수준 설정은 프로젝트가 가질 수 있는 설정을 제한하고 프로젝트 수준 설정은 파이프라인이 가질 수 있는 설정을 제한합니다.

토글이 organization 수준에서 작동하는 방식을 살펴보겠습니다. 새 컨트롤은 기본적으로 꺼져 있으므로 설정이 보편적으로 적용되지 않습니다.

토글을 켜면 분기된 GitHub 리포지토리에서 PR 빌드를 사용하지 않도록 선택할 수 있습니다. 즉, 이러한 PR을 만들 때 파이프라인이 실행되지 않습니다.

포크된 리포지토리에서 끌어오기 요청을 안전하게 빌드 옵션을 선택하면 모든 파이프라인(organization 전체)은 포크된 리포지토리의 PR 빌드에 비밀을 사용할 수 없고, 이러한 빌드가 일반 빌드와 동일한 권한을 가지도록 할 수 없으며 PR 주석에 의해 트리거되어야 합니다. 프로젝트는 여전히 파이프라인이 이러한 PR을 빌드하는 것을 허용하지 않기 로 결정할 수 있습니다.

사용자 지정 옵션을 선택하면 파이프라인 설정을 제한하는 방법을 정의할 수 있습니다. 예를 들어 PR이 팀 구성원이 아닌 멤버 및 비 기여자가 속한 경우 포크된 GitHub 리포지토리에서 PR을 빌드하기 위해 모든 파이프라인에 주석이 필요한지 확인할 수 있습니다. 그러나 이러한 빌드에서 비밀을 사용할 수 있도록 허용할 수 있습니다. 프로젝트는 파이프라인이 이러한 PR을 빌드하거나 안전하게 빌드하는 것을 허용하지 않거나 organization 수준에서 지정된 설정을 더 제한적으로 사용할 수 없도록 결정할 수 있습니다.

Azure Repos

사용자가 자신의 변경 내용을 승인할 수 없도록 하는 새로운 "분기 정책"

사용자가 승인하는 변경 내용에 대한 제어를 개선하고 더 엄격한 규정/규정 준수 요구 사항과 일치하기 위해 명시적으로 허용되지 않는 한 사용자가 자신의 변경 내용을 승인하지 못하도록 하는 옵션을 제공합니다.

분기 정책을 관리할 수 있는 기능을 가진 사용자는 이제 "새 변경 내용이 푸시되는 경우"에서 새로 추가된 옵션 "모든 반복에 대해 하나 이상의 승인 필요"를 전환할 수 있습니다. 이 옵션을 선택하면 마지막 원본 분기 변경에 대해 하나 이상의 승인 투표가 필요합니다. 사용자의 승인은 해당 사용자가 푸시한 이전의 승인되지 않은 반복에 대해 계산되지 않습니다. 따라서 마지막 반복에 대한 추가 승인은 다른 사용자가 수행해야 합니다.

다음 이미지는 사용자 A가 만든 끌어오기 요청과 사용자 B, C, A 및 C가 해당 끌어오기 요청에 대해 수행한 추가 4개의 커밋(반복)을 보여 줍니다. 두 번째 반복(사용자 B가 수행한 커밋)이 완료된 후 사용자 C는 이를 승인했습니다. 이때 사용자 A의 첫 번째 커밋(끌어오기 요청이 생성되었을 때)에 대한 승인을 암시했으며 새로 도입된 정책이 성공합니다. 다섯 번째 반복(사용자 C의 마지막 커밋) 후 사용자 A가 승인을 수행했습니다. 이는 사용자 C가 수행한 이전 커밋에 대한 암시적 승인이지만 네 번째 반복에서 사용자 A가 수행한 두 번째 커밋에 대한 승인을 의미하지는 않았습니다. 새로 도입된 정책이 성공하려면 승인되지 않은 반복 4는 사용자 B, C 또는 끌어오기 요청을 변경하지 않은 다른 사용자의 승인으로 승인되어야 합니다.

Azure Artifacts

화물 상자에 대한 Azure Artifacts 지원 소개(공개 미리 보기)

이제 Azure Artifacts가 화물 상자에 대한 기본 지원을 제공한다는 것을 발표하게 되어 기쁩니다. 이 지원에는 업스트림 원본으로 사용할 수 있는 crates.io 외에도 기존 프로토콜과 관련된 기능 패리티가 포함됩니다. Rust 개발자와 팀은 이제 Azure의 강력한 인프라를 사용하고 친숙한 Azure DevOps 환경에 머물면서 화물 상자를 원활하게 소비, 게시, 관리 및 공유할 수 있습니다.

미리 보기에는 등록이 필요하지 않습니다. Azure DevOps 프로젝트로 이동하고, 아티팩트 를 선택하고, 지침에 따라 Rust 프로젝트를 Azure Artifacts 피드에 연결하여 시작할 수 있습니다.

다음 단계

Azure DevOps로 이동하여 살펴보세요.

피드백을 제공하는 방법

이러한 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 도움말 메뉴를 사용하여 문제를 보고하거나 제안을 제공합니다.

Stack Overflow에서 커뮤니티에서 조언과 질문에 답변할 수도 있습니다.

감사합니다,

실비우 앤드리카