데이터 보호 개요
Azure DevOps Services
Azure DevOps Services는 계획부터 배포까지 개발 프로젝트를 위한 클라우드 호스팅 애플리케이션입니다. 온-프레미스 기능을 기반으로 더 많은 클라우드 서비스를 통해 소스 코드, 작업 항목, 빌드 및 테스트를 관리합니다. Azure DevOps는 PaaS(Platform as a Service) 인프라와 Azure SQL을 포함한 많은 Azure 서비스를 사용하여 개발 프로젝트에 안정적이고 전역적으로 사용 가능한 서비스를 제공합니다.
이 문서에서는 프로젝트를 안전하고, 사용 가능하고, 안전하게, 비공개로 유지하기 위해 Microsoft에서 수행하는 단계를 설명합니다. 프로젝트를 안전하고 안전하게 유지하는 데 중요한 역할을 설명합니다.
이 문서는 매일 프로젝트 자산을 관리하는 조직 관리자 및 IT 전문가를 위한 것입니다. Azure DevOps에 이미 익숙하고 Microsoft가 Azure DevOps에 저장된 자산을 보호하는 방법에 대해 자세히 알고 싶은 개인에게 가장 유용합니다.
당사의 약정
Microsoft는 예외 없이 프로젝트가 안전하고 안전하게 유지되도록 지원합니다. Azure DevOps에 프로젝트를 저장하는 경우 여러 계층의 보안 및 거버넌스 기술, 운영 관행 및 규정 준수 정책의 이점을 누릴 수 있습니다. 미사용 및 전송 중 데이터 개인 정보 보호 및 무결성을 적용합니다.
직면하는 위협은 데이터 가용성, 서비스 가용성, 서비스 보안 및 데이터 개인 정보 보호의 네 가지 기본 범주에 있습니다. 이 문서에서는 각 범주 내의 특정 위협을 살펴보고 Azure DevOps가 이를 해결하기 위해 수행하는 작업을 설명합니다. 이 문서에서는 데이터가 저장되는 방법과 Azure DevOps가 데이터에 대한 액세스를 관리하는 방법을 설명하는 것으로 시작합니다.
데이터 보호를 위해서는 무단 공개 및 변조로부터 자산을 보호하기 위해 수행해야 하는 단계를 알고 있는 관리자와 사용자의 적극적인 참여가 필요합니다. 사용자 액세스 지점에 권한을 부여할 때 명시적이어야 하므로 적절한 사용자만 Azure DevOps 내의 데이터에 액세스합니다.
사용 위치 또는 사용 방법에 관계없이 모든 데이터가 잠재적으로 위험에 처할 수 있다고 생각해야 합니다. 이 문은 클라우드에 저장된 데이터와 프라이빗 데이터 센터에 저장된 데이터에 모두 해당합니다. 데이터, 민감도 및 위험, 손상될 경우 발생할 수 있는 손상을 분류하는 것이 중요합니다. 또한 정보 보안을 관리하기 위한 전체 정책에 상대적으로 데이터를 분류합니다.
Azure를 기반으로 빌드됨
Azure 데이터 센터에서 Azure DevOps를 전적으로 호스트합니다. Azure DevOps는 컴퓨팅, 스토리지, 네트워킹, Azure SQL, ID 및 액세스 관리 및 Azure Service Bus를 비롯한 많은 핵심 Azure 서비스를 사용합니다.
Azure DevOps는 Azure Storage를 서비스 메타데이터 및 고객 데이터의 기본 리포지토리로 사용합니다. 데이터 형식과 스토리지 및 검색 요구 사항에 따라 Azure DevOps는 Azure Blob Storage 및 Azure SQL Database 스토리지를 사용합니다.
데이터 보호에 대한 Azure DevOps Services 접근 방식을 이해하는 데 도움이 되도록 스토리지 서비스에 대한 몇 가지 배경은 다음과 같습니다.
Azure Blob Storage 는 구조화되지 않은 데이터의 큰 청크를 저장합니다. 모든 프로젝트는 이 서비스를 사용합니다. 데이터에는 작업 항목에 대한 첨부 파일 및 원본 파일의 내용과 같이 잠재적으로 중요한 프라이빗 정보가 포함됩니다. 대부분의 프로젝트에서 대부분의 스토리지는 이러한 유형의 구조화되지 않은 Blob Storage입니다.
Azure SQL Database 는 프로젝트 메타데이터, 버전이 지정된 소스 제어 기록 및 작업 항목의 세부 정보를 포함하여 조직의 구조적 및 트랜잭션 측면을 저장합니다. 데이터베이스 스토리지를 사용하면 프로젝트의 중요한 요소에 빠르게 액세스할 수 있습니다. 파일 및 첨부 파일을 조회하기 위해 Blob Storage에 인덱스를 제공합니다.
관리자는 사용자 ID 또는 그룹에 대한 권한을 부여하거나 제한하여 리소스에 대한 액세스를 관리할 수 있습니다. Azure DevOps는 Microsoft Entra ID 및 Microsoft 계정을 통해 사용자 ID 의 페더레이션 인증을 사용합니다.
인증하는 동안 사용자는 자격 증명을 제공하는 인증 공급자로 라우팅됩니다. 인증 공급자가 사용자의 자격 증명을 확인한 후 Azure DevOps는 사용자에게 인증 쿠키를 발급합니다. 이 쿠키를 사용하면 사용자가 Azure DevOps에 대해 인증된 상태를 유지할 수 있습니다.
이러한 방식으로 사용자의 자격 증명 정보는 Azure DevOps와 직접 공유되지 않습니다. 사용자가 액세스하려고 하는 각 Azure DevOps 리소스에 대해 사용 권한의 유효성 검사는 사용자의 명시적 권한 및 사용자가 그룹 멤버 자격을 통해 상속한 사용 권한을 기반으로 합니다.
관리자는 액세스 제어를 사용하여 조직, 프로젝트 컬렉션, 팀 프로젝트 및 팀 범위 데이터 및 기능에 대한 액세스를 보호할 수 있습니다. 관리자는 버전 제어를 위한 폴더 및 작업 항목의 영역 경로와 같은 특정 자산에 대한 액세스 제어를 사용할 수도 있습니다.
데이터 가용성
Azure DevOps는 하드웨어 오류, 서비스 중단 또는 지역 재해가 발생할 경우 데이터 가용성을 보장하기 위해 많은 Azure Storage 기능을 사용합니다. 또한 Azure DevOps 팀은 실수로 또는 악의적인 삭제로부터 데이터를 보호하는 절차를 따릅니다.
데이터 중복성
하드웨어 또는 서비스 오류 시 데이터를 보호하기 위해 Azure Storage는 동일한 지리적 위치에 있는 두 지역 간에 고객 데이터를 지역 복제합니다. 예를 들어 Azure Storage는 북유럽과 서유럽 간 또는 남북 미국 간에 데이터를 지리적으로 복제할 수 있습니다.
Azure Blob Storage의 경우 고객 데이터는 단일 지역 내에서 세 번 복제됩니다. 고객 데이터는 동일한 지리적 위치에 있는 두 번째 지역에 비동기적으로 복제됩니다. 따라서 Azure는 항상 6개의 데이터 복사본에 해당하는 복사본을 유지 관리합니다.
복사본이 여러 개 있으면 주요 중단 또는 재해가 발생한 경우 별도의 지역으로 장애 조치(failover)하는 동시에 지역 내의 하드웨어 오류에 대한 로컬 중복성을 가질 수 있습니다. Azure SQL Database 스토리지의 경우 지역 재해가 발생한 경우 매일 백업이 오프사이트에서 유지 관리됩니다.
데이터 중복 및 장애 조치(failover)와 관련하여 다음을 수행합니다.
- Microsoft가 주 지역과 보조 지역 간에 데이터를 복제하는 경우 몇 분 단위로 측정되는 고유 델타가 있습니다.
- 보조 지역으로의 장애 조치(failover)는 특정 배율 단위의 모든 고객에게 영향을 미치기 때문에 Microsoft가 중앙에서 결정해야 하는 결정입니다. 극단적인 경우를 제외하고 Microsoft는 고객 데이터가 손실되지 않도록 장애 조치(failover)를 방지하도록 선택합니다.
- Azure DevOps는 가동 시간 99.9%의 SLA(서비스 수준 계약)를 제공합니다. Azure DevOps는 특정 달에 해당 SLA를 놓친 경우 월별 요금의 일부를 환불합니다.
- 브라질에는 지역이 하나뿐이므로 재해 복구를 위해 브라질의 고객 데이터가 미국 중남부 지역으로 복제됩니다.
실수 발생
우발적인 데이터 손실로부터 보호하기 위해 Microsoft는 Azure Blob Storage에 저장된 Blob과 Azure SQL Database 내의 데이터베이스 모두에 대해 지정 시간 백업을 사용합니다. 각 스토리지 계정은 모든 Blob의 별도 복사본을 유지 관리하며 변경 내용은 기존 데이터에 추가됩니다. 이러한 백업은 변경할 수 없으므로 백업 절차 중에 기존 스토리지를 다시 작성할 필요가 없습니다.
Azure SQL Database에는 Azure DevOps에서 활용하는 표준 백업 기능이 포함되어 있습니다. 데이터는 28일 동안 보존되며, 이러한 백업은 지역 가동 중단 시 복구를 용이하게 하기 위해 쌍을 이루는 지역에 복제됩니다.
삭제 후 28일 이내에 삭제된 조직 또는 프로젝트를 복구할 수 있습니다. 그러나 이 기간이 경과하면 이러한 엔터티가 영구적으로 삭제되고 복원할 수 없습니다. 이러한 백업은 재해 복구를 위한 중요한 구성 요소로 사용되지만, 고객은 데이터를 포괄적으로 보호하기 위해 적절한 데이터 관리 및 백업 전략을 실행해야 합니다.
Important
- 여기서 실수로 삭제 되는 것은 서비스에 대한 인시던트 결과로 발생하는 시나리오를 나타냅니다. 고객의 실수로 자산을 삭제하는 것은 포함되지 않습니다(예: 리포지토리, 작업 항목, 첨부 파일 또는 아티팩트).
- 고객이 실수로 삭제하는 자산 복원은 지원되지 않습니다. 이러한 백업은 비즈니스 연속성을 위한 것이며 중단 또는 재해 시나리오로부터의 복구를 지원하기 위한 것입니다.
- 드물게 백 엔드 재시도 및 여러 원본에서 데이터를 삭제해야 하므로 삭제 프로세스가 최대 70일이 걸릴 수 있습니다.
연습이 중요합니다.
데이터의 여러 백업을 사용하는 것이 좋지만 실제로는 복원을 예측할 수 없습니다. 사람들은 "백업은 실패하지 않습니다. 복원이 수행됩니다." 이 진술은 기술적으로 올바르지 않지만 감정은 옳습니다.
Microsoft는 정기적으로 백업에서 데이터 세트를 복원하는 방법을 연습합니다. Azure에서 지역 중복 스토리지를 정기적으로 테스트합니다. 재해 및 데이터 손상 시나리오에는 여러 가지 조합이 있습니다. 이러한 시나리오에 대한 새 테스트를 정기적으로 계획하고 실행합니다.
서비스 가용성
Azure DevOps는 조직 및 관련 자산에 액세스할 수 있도록 DDoS(분산 서비스 거부) 보호 및 라이브 사이트 응답을 제공합니다.
DDoS 보호
경우에 따라 악의적인 DDoS 공격이 서비스 가용성에 영향을 줄 수 있습니다. Azure에는 서비스에 대한 공격을 방지하는 데 도움이 되는 DDoS 방어 시스템이 있습니다. SYN 쿠키, 속도 제한 및 연결 제한과 같은 표준 검색 및 완화 기술을 사용합니다. 이 시스템은 외부뿐만 아니라 Azure 내에서의 공격을 견딜 수 있도록 설계되었습니다.
Azure 방어 시스템에 침투할 수 있는 애플리케이션별 공격의 경우 Azure DevOps는 애플리케이션 수준 및 조직 수준 할당량 및 제한을 설정합니다. 이 방법은 리소스를 공격하거나 실수로 오용하는 동안 주요 서비스 리소스를 과도하게 사용하는 것을 방지하는 데 도움이 됩니다.
라이브 사이트 응답
드문 경우지만 서비스 가용성 문제에 대한 라이브 사이트 응답이 필요할 수 있습니다. 문제를 신속하게 식별하고 필요한 개발 팀 리소스를 참여시키기 위해 지속적으로 사용할 수 있는 운영 팀이 있습니다.
그런 다음 개발 팀 리소스가 문제를 해결합니다. 또한 서비스에 영향을 주는 문제를 감지한 후 몇 분 내에 서비스 상태 페이지를 업데이트하는 것을 목표로 합니다. 개발 팀 리소스는 문제를 해결한 후 근본 원인을 식별하고 향후 유사한 문제를 방지하기 위해 필요한 변경 내용을 추적합니다.
라이브 사이트 관리를 위한 Azure DevOps 프로세스는 사용자의 환경 및 서비스 상태에 초점을 맞춥니다. 이러한 프로세스는 문제를 감지, 대응 및 완화하는 시간을 최소화합니다. 모든 엔지니어링 분야는 관련되고 책임이 있으므로 지속적인 개선은 직접적인 경험에서 진화합니다. 모니터링, 진단, 복원력 및 품질 보증 프로세스는 시간이 지남에 따라 개선됩니다.
Azure DevOps의 라이브 사이트 관리에는 원격 분석, 인시던트 관리 및 라이브 사이트 검토의 세 가지 고유한 트랙이 있습니다. 이러한 트랙이 수반하는 것은 다음과 같습니다.
운영 팀은 개별 조직에 대한 가용성 메트릭도 모니터링합니다. 이러한 메트릭은 일부 고객에게만 영향을 줄 수 있는 특정 조건에 대한 인사이트를 제공합니다. 이 데이터를 조사하면 고객 관련 문제를 해결하기 위한 목표 개선이 발생할 수 있습니다. 경우에 따라 Microsoft는 사용자에게 직접 연락하여 사용자의 경험을 이해하고 서비스를 개선하기 위해 사용자와 협력할 수도 있습니다.
Microsoft는 SLA를 게시하고 매달 이 계약을 충족할 수 있도록 재무 보증을 제공합니다. 자세한 내용은 Azure DevOps용 SLA를 참조 하세요.
파트너 팀 또는 종속성에 Azure DevOps에 영향을 주는 인시던트가 있는 경우가 있습니다. 모든 파트너 팀은 이러한 서비스 중단에서 식별, 해결 및 학습하는 유사한 접근 방식을 따릅니다.
서비스 보안
서비스 보안에는 적절한 디자인 및 코딩 기술에서 작동 요인에 이르기까지 지속적인 경계가 필요합니다. Microsoft는 보안 허점 방지 및 위반 탐지에 적극적으로 투자하고 있습니다. 위반이 있는 경우 Microsoft는 보안 대응 계획을 사용하여 데이터 유출, 손실 또는 손상을 최소화합니다. 자세한 내용은 보안, 인증 및 권한 부여 정보를 참조 하세요.
디자인별 보안
Azure DevOps는 보안을 위해 설계되었습니다. Azure DevOps는 개발 프로세스의 핵심에서 Microsoft 보안 개발 수명 주기를 사용합니다. Microsoft Operational Security Assurance 프로그램은 Azure DevOps의 클라우드 운영 절차를 안내합니다.
Azure DevOps 팀에는 모든 엔지니어 및 운영 담당자에 대한 연간 교육 요구 사항이 있습니다. 이 팀은 Microsoft 엔지니어가 주최하는 비공식 모임도 후원합니다. 팀은 모임에서 나타나는 문제를 해결한 후 다른 팀과 배운 교훈을 공유합니다.
다음 방법론에서는 학습 요구 사항을 지정합니다.
- 서비스 디자인 중 위협 모델링
- 디자인 및 코드에 대한 모범 사례 다음
- 표준 도구 및 테스트를 사용하여 보안 확인
- 운영 및 고객 데이터에 대한 액세스 제한
- 엄격한 승인 프로세스를 통해 새로운 기능의 출시를 안내합니다.
클라우드 서비스는 호스트 플랫폼만큼만 안전합니다. Azure DevOps는 대부분의 인프라에 PaaS를 사용합니다. PaaS는 알려진 보안 취약성에 대한 정기적인 업데이트를 자동으로 제공합니다.
Azure에서 호스트되는 가상 머신은 호스트된 빌드 서비스와 같은 IaaS(Infrastructure as a Service)를 사용합니다. 이러한 이미지는 Windows 업데이트 사용할 수 있는 최신 보안 패치를 포함하도록 정기적인 업데이트를 받습니다. 배포, 모니터링 및 보고에 사용되는 컴퓨터를 포함하여 온-프레미스 컴퓨터에 동일한 업데이트 엄격이 적용됩니다.
Azure DevOps 팀은 Azure DevOps의 보안 중심 침투 테스트를 정기적으로 수행합니다. 침투 테스트는 악의적인 공격자가 사용하는 것과 동일한 기술 및 메커니즘을 사용하여 Azure DevOps의 라이브 프로덕션 서비스 및 인프라를 활용하려고 합니다. 목표는 제어된 프로세스에서 실제 취약성, 구성, 오류 또는 기타 보안 격차를 식별하는 것입니다.
팀은 이러한 테스트의 결과를 검토하여 다른 개선 영역을 식별하고 예방 시스템 및 교육의 품질을 향상합니다. Microsoft 서비스 신뢰 포털에서 최근 Azure DevOps 침투 테스트의 결과를 검토할 수 있습니다.
자격 증명 보안
Microsoft는 예외 없이 프로젝트가 안전하고 안전하게 유지되도록 하기 위해 최선을 다하고 있습니다. Azure DevOps에서 프로젝트는 여러 계층의 보안 및 거버넌스 기술, 운영 관행 및 규정 준수 정책의 이점을 누릴 수 있습니다. 미사용 및 전송 중 데이터 개인 정보 보호 및 무결성을 적용합니다. 또한 Azure DevOps에서 저장하는 자격 증명 또는 비밀과 관련하여 다음 방법을 준수합니다. 올바른 인증 메커니즘을 선택하는 방법에 대한 자세한 내용은 인증 지침을 참조하세요.
Important
Azure DevOps는 대체 자격 증명 인증을 지원하지 않습니다. 대체 자격 증명을 계속 사용하는 경우 보다 안전한 인증 방법으로 전환하는 것이 좋습니다.
개인용 액세스 토큰(PAT)
- PAT의 해시를 저장합니다.
- 원시 PAT는 서버 쪽에서 메모리 내를 생성합니다. 32바이트는 RNGCryptoServiceProvider를 통해 임의로 생성되고 호출자와 base-32로 인코딩된 문자열로 공유됩니다. 이 값은 저장되지 않습니다.
- PAT 해시는 키 자격 증명 모음에 저장된 64바이트 대칭 서명 키를 사용하여 서버 쪽에서 원시 PAT의 HMACSHA256Hash로 메모리 내를 생성합니다.
- 해시는 데이터베이스에 저장됩니다.
SSH(보안 셸) 키
- 바깥쪽 조직 ID 및 SSH 공개 키의 해시를 저장합니다.
- 원시 공개 키는 SSL을 통해 호출자가 직접 제공합니다.
- SSH 해시는 키 자격 증명 모음에 저장된 64바이트 대칭 서명 키를 사용하여 서버 쪽에서 조직 ID 및 원시 공개 키의 HMACSHA256Hash로 메모리 내를 생성합니다.
- 해시는 데이터베이스에 저장됩니다.
OAuth 자격 증명(JWT)
- OAuth 자격 증명은 완전히 자체 설명하는 JWT(JSON 웹 토큰)로 발급되며 서비스에 저장되지 않습니다.
- 서비스에 발급되고 제공된 JWT의 클레임은 키 자격 증명 모음에 저장된 인증서를 사용하여 유효성을 검사합니다.
보안 결함 보고
침투 테스트에 Azure DevOps 서비스와 관련된 잠재적인 보안 결함이 있다고 생각되면 24시간 이내에 Microsoft에 보고합니다. 자세한 내용은 컴퓨터 보안 취약성을 보고하는 Microsoft 웹 페이지를 참조하세요.
Important
침투 테스트 활동에 대해 Microsoft에 알릴 필요는 없지만 Microsoft 침투 테스트 참여 규칙을 준수해야 합니다.
장려금 프로그램
Azure DevOps는 Microsoft 버그 장려금 프로그램에 참여합니다. 이 프로그램은 문제를 보고하는 보안 연구원에게 보상을 제공하며, 더 많은 사람들이 Azure DevOps를 안전하게 유지할 수 있도록 장려합니다. 자세한 내용은 Microsoft Azure DevOps 장려금 프로그램을 참조 하세요.
액세스 제한
Microsoft는 프로덕션 환경 및 고객 데이터에 액세스할 수 있는 사용자를 엄격하게 제어합니다. 필요한 최소 권한 수준으로, 그리고 사용자의 근거를 검증한 후에만 액세스 권한을 부여합니다. 팀 구성원이 긴급한 문제를 해결하거나 구성 변경을 배포하기 위해 액세스해야 하는 경우 프로덕션 서비스에 대한 Just-In-Time 액세스를 신청해야 합니다. 상황이 해결되는 즉시 액세스가 취소됩니다.
별도의 시스템에서 액세스 요청 및 승인을 추적하고 모니터링합니다. 시스템에 대한 모든 액세스는 이러한 승인과 상관 관계가 있습니다. 승인되지 않은 액세스가 감지되면 운영 팀에 조사하도록 경고합니다.
모든 원격 시스템 액세스에 2단계 인증을 사용합니다. 개발자 또는 운영 직원 중 한 명의 사용자 이름과 암호를 도난당한 경우 데이터는 보호된 상태로 유지됩니다. 서비스에 대한 원격 액세스를 허용하기 전에 스마트 카드 또는 사전 승인된 번호에 대한 전화 통화를 통해 더 많은 인증 검사가 수행되어야 합니다.
서비스를 관리하고 유지 관리하기 위해 Microsoft는 RDP 암호, SSL 인증서 및 암호화 키와 같은 비밀을 사용합니다. 이러한 비밀은 모두 Azure Portal을 통해 안전하게 관리, 저장 및 전송됩니다. 이러한 비밀에 액세스하려면 안전하게 기록되고 기록되는 특정 권한이 필요합니다. 모든 비밀은 정기적인 주기로 회전되며, 보안 이벤트가 있는 경우 요청 시 순환할 수 있습니다.
Azure DevOps 운영 팀은 강화된 관리자 워크스테이션을 사용하여 서비스를 관리합니다. 이러한 컴퓨터는 최소한의 애플리케이션을 실행하고 논리적으로 분할된 환경에서 작동합니다.
작업 팀 구성원은 워크스테이션에 액세스하려면 2단계 인증을 통해 특정 자격 증명을 제공해야 합니다. 모든 액세스는 모니터링되고 안전하게 기록됩니다. 외부 변조로부터 서비스를 격리하기 위해 Outlook 및 Office와 같은 애플리케이션은 종종 스피어 피싱 및 기타 유형의 공격의 대상이기 때문에 허용하지 않습니다.
침입 보호 및 응답
Microsoft는 사용자와 Azure DevOps 간에 전송하는 동안 데이터를 가로채거나 수정하지 않도록 HTTPS 및 SSL을 통해 데이터를 암호화합니다. Azure DevOps에서 사용자 대신 저장하는 데이터는 다음과 같이 암호화됩니다.
Azure SQL 데이터베이스에 저장된 데이터는 투명한 데이터 암호화를 통해 암호화됩니다. 이 기능은 데이터베이스, 연결된 백업 및 미사용 트랜잭션 로그 파일의 실시간 암호화를 수행하여 악의적인 활동으로부터 보호하는 데 도움이 됩니다.
Azure Blob Storage 연결은 전송 중인 데이터를 보호하기 위해 암호화됩니다. Azure Blob Storage에 저장된 미사용 데이터의 경우 Azure DevOps는 서비스 쪽 암호화를 사용합니다.
Azure DevOps 팀은 Azure 인프라를 사용하여 서비스의 주요 측면을 기록하고 모니터링합니다. 로깅 및 모니터링은 서비스 내의 활동이 합법적인지 확인하는 데 도움이 되며 위반 또는 시도된 위반을 감지하는 데 도움이 됩니다.
모든 배포 및 관리자 활동은 프로덕션 스토리지에 대한 운영자 액세스와 마찬가지로 안전하게 기록됩니다. 로그 정보는 자동으로 분석되고 잠재적으로 악의적이거나 권한이 없는 모든 동작은 실시간 경고를 발생합니다.
Azure DevOps 팀에서 가능한 침입 또는 우선 순위가 높은 보안 취약성을 식별하면 명확한 응답 계획이 있습니다. 이 계획은 책임 있는 당사자, 고객 데이터를 보호하기 위한 필수 단계 및 Microsoft의 보안 전문가와 협력하는 방법에 대한 지침을 간략하게 설명합니다. 팀은 또한 데이터가 공개되거나 손상된 경우 조직 소유자 알리므로 상황을 해결하기 위한 적절한 조치를 취할 수 있습니다.
새로운 위협에 대처하기 위해 Azure DevOps는 위반 가정 전략을 사용합니다. Microsoft 내의 고도로 전문화된 보안 전문가 팀은 정교한 악의적 사용자의 역할을 가정합니다. 이 팀은 보안 위반 탐지 및 대응을 테스트하여 실제 공격의 준비 상태와 영향을 정확하게 측정합니다. 이 전략은 서비스의 위협 탐지, 대응 및 방어를 강화합니다. 또한 팀은 전체 보안 프로그램의 유효성을 검사하고 개선할 수 있습니다.
랜섬웨어 공격 보호
Azure DevOps는 Azure 컨트롤을 사용하여 랜섬웨어 공격을 방지, 감지 및 대응합니다. Azure가 랜섬웨어 공격으로부터 고객을 보호하는 방법에 대한 자세한 내용은 Azure의 랜섬웨어 보호를 참조하세요.
데이터 개인 정보
데이터를 적절하게 그리고 합법적인 용도로 처리하고 있다는 확신이 있어야 합니다. 이러한 보증의 일부에는 사용량을 신중하게 제한하는 작업이 포함됩니다.
일반 데이터 보호 규정
GDPR(일반 데이터 보호 규정)은 1995년 유럽 연합(EU) 데이터 보호 지침 95/46/EC가 도입된 이래 유럽에서 가장 큰 데이터 보호법 변경 사항입니다. GDPR에 대한 자세한 내용은 Microsoft 보안 센터의 개요 페이지를 참조하세요.
데이터 보존 및 주권
Azure DevOps는 미국, 캐나다, 유럽, 영국, 인도, 오스트레일리아, 아시아 태평양 및 브라질 등 전 세계 8개 지리적 위치에서 사용할 수 있습니다. 기본적으로 조직은 가장 가까운 위치에 할당됩니다. 그러나 조직을 만들 때 다른 위치를 선택할 수 있습니다. 나중에 마음이 바뀌면 Microsoft 지원의 도움을 받아 조직을 다른 위치로 마이그레이션할 수 있습니다.
Azure DevOps는 선택한 위치 외부로 고객 데이터를 이동하거나 복제하지 않습니다. 대신 데이터는 동일한 위치 내의 두 번째 지역에 지리적으로 복제됩니다. 유일한 예외는 재해 복구를 위해 데이터를 미국 중남부 지역에 복제하는 브라질입니다.
참고 항목
Microsoft에서 제공하는 macOS 에이전트에서 실행되는 빌드 및 릴리스의 경우 데이터는 미국 GitHub 데이터 센터로 전송됩니다.
자세한 내용은 Azure DevOps의 데이터 위치를 참조 하세요.
법 집행 기관 액세스
경우에 따라 법 집행 엔터티와 같은 제3자가 Microsoft에 접근하여 Azure DevOps에 저장된 고객 데이터에 액세스할 수 있습니다. 확인을 위해 요청을 조직 소유자 리디렉션하려고 합니다. 법원 명령으로 Microsoft가 고객 데이터를 제3자에게 공개하도록 강요하는 경우 Microsoft는 법적으로 금지되지 않는 한 조직 소유자 미리 알리기 위해 합리적인 노력을 기울입니다.
일부 고객은 법 집행 활동에 대한 특정 법적 관할권을 보장하기 위해 특정 지리적 위치에 데이터 스토리지를 요구합니다. 소스 코드, 작업 항목, 테스트 결과, 지역 중복 미러 및 오프사이트 백업과 같은 모든 고객 데이터는 앞에서 언급한 위치 중 하나 내에서 유지 관리됩니다.
Microsoft 액세스
때때로 Microsoft 직원은 Azure DevOps에 저장된 고객 데이터에 대한 액세스 권한을 얻어야 합니다. 예방 조치로 고객 데이터에 대한 액세스 권한이 있거나 있을 수 있는 모든 직원은 이전 고용 및 형사 유죄 판결을 포함하는 신원 조회를 통과해야 합니다. 라이브 사이트 인시던트 또는 기타 승인된 유지 관리 작업이 기록되고 모니터링되는 경우에만 프로덕션 시스템에 대한 액세스를 허용합니다.
시스템 내의 모든 데이터가 동일한 방식으로 처리되는 것은 아니므로 데이터를 다음 형식으로 분류합니다.
- 고객 데이터: Azure DevOps에 업로드하는 항목입니다.
- 조직 데이터: 조직에 등록하거나 관리할 때 제출하는 정보입니다.
- Microsoft 데이터: 서비스 작업을 통해 필요하거나 수집되는 정보입니다.
분류에 따라 사용 시나리오, 지리적 위치 요구 사항, 액세스 제한 및 보존 요구 사항을 제어합니다.
Microsoft 홍보용
Microsoft는 때때로 고객에게 연락하여 유용할 수 있는 더 많은 기능과 서비스에 대해 알리려고 합니다. 모든 고객이 이러한 제품에 대해 연락하기를 원하지 않으므로 마케팅 전자 메일 통신을 옵트인하고 옵트아웃할 수 있습니다.
Microsoft는 고객 데이터를 사용하여 특정 사용자 또는 조직의 특정 제품을 대상으로 지정하지 않습니다. 대신 조직 수준에서 조직 데이터 및 집계 사용 통계를 사용하여 특정 제품을 받아야 하는 그룹을 결정합니다.
신뢰도 구축
Microsoft가 Azure DevOps를 대신하여 수행하는 다른 노력에 확신을 가질 수 있습니다. 이러한 노력에는 Microsoft의 내부 채택 정책, 서비스 상태에 대한 투명성 수준, 정보 보안 관리를 위한 시스템 인증을 받기 위한 진행 상황 등이 포함됩니다.
내부 채택
Microsoft 팀은 내부적으로 Azure DevOps를 채택하고 있습니다. Azure DevOps 팀은 2014년에 조직으로 전환하여 광범위하게 사용합니다. 다른 팀에 대한 채택 계획을 사용하도록 설정하는 지침을 수립했습니다.
대규모 팀은 기존 DevOps 시스템에 대한 투자로 인해 소규모 팀보다 점진적으로 이동합니다. 빠르게 이동하는 팀의 경우 프로젝트 분류 접근 방식을 설정했습니다. 프로젝트 특성에 따라 위험 허용 범위를 평가하여 프로젝트가 Azure DevOps에 적합한지 확인합니다. 대규모 팀의 경우 채택은 일반적으로 더 많은 계획과 함께 단계적으로 수행됩니다.
내부 프로젝트에 대한 더 많은 요구 사항에는 적절한 사용자 ID 수명 주기 및 암호 복잡성을 보장하기 위해 조직을 Microsoft Entra ID와 연결시키는 것이 포함됩니다. 더 중요한 프로젝트에는 2단계 인증도 필요합니다.
규정 준수 인증
데이터 보안을 위한 절차의 타사 평가를 이해하는 데 관심이 있을 수 있습니다. Azure DevOps는 다음 인증을 달성했습니다.
- ISO 27001:2013
- ISO 27018:2019
- ISO 26262:2023
- HIPAA(Health Insurance Portability and Accountability Act)
- BAA(Business Associate Agreement)
- EU 모델 조항
- SOC(시스템 및 조직 컨트롤) 1 유형 2
- SOC 2 형식 2
- 독일 C5
- 호주 IRAP
- ENS-스페인
Azure DevOps에 대한 SOC 감사는 데이터 보안, 가용성, 처리 무결성 및 기밀성에 대한 제어를 다룹니다. Azure DevOps에 대한 SOC 보고서는 Microsoft 서비스 신뢰 포털을 통해 사용할 수 있습니다.
CAIQ(컨센서스 평가 이니셔티브 설문지)는 조직이 클라우드 서비스 공급자의 보안 사례 및 기능을 평가하고 평가하는 데 도움이 됩니다. 보안 및 투명성에 대한 우리의 약속에 따라 최근에 Azure DevOps에 대한 CAIQ 평가를 완료했습니다. Microsoft 서비스 신뢰 포털에서 전체 보고서를 검토하도록 초대합니다.
수행할 수 있는 단계
적절한 데이터 보호에는 사용자, 관리자 및 사용자의 적극적인 참여가 필요합니다. Azure DevOps에 저장된 프로젝트 데이터는 사용자 액세스 지점만큼만 안전합니다. 해당 조직의 권한 엄격 및 세분성 수준을 프로젝트의 민감도 수준과 일치합니다.
데이터 분류
첫 번째 단계는 데이터를 분류하는 것입니다. 민감도 및 위험 수평선에 따라 데이터를 분류하고 손상될 경우 발생할 수 있는 손상을 분류합니다. 많은 엔터프라이즈에는 프로젝트가 Azure DevOps로 이동할 때 재사용할 수 있는 기존 분류 방법이 있습니다. 자세한 내용은 Microsoft Trustworthy Computing에서 클라우드 준비 상태를 위한 데이터 분류를 다운로드할 수 있습니다.
Microsoft Entra ID 채택
Microsoft Entra ID를 사용하여 Azure DevOps에 대한 조직의 액세스를 관리합니다. Microsoft Entra ID는 사용자의 자격 증명 보안을 개선하는 또 다른 방법을 제공합니다.
Microsoft Entra ID를 사용하면 IT 부서에서 사용자가 조직을 떠날 때 사용자 액세스 정책, 암호 복잡성, 암호 새로 고침 및 만료를 관리할 수 있습니다. Active Directory 페더레이션을 통해 Microsoft Entra ID를 조직의 중앙 디렉터리에 직접 연결할 수 있으므로 엔터프라이즈에 대한 이러한 세부 정보를 관리할 수 있는 위치는 하나뿐입니다.
다음 표에서는 Azure DevOps 액세스를 기준으로 Microsoft 계정 및 Microsoft Entra 특성을 비교합니다.
| 속성 | Microsoft 계정 | Microsoft Entra ID |
|---|---|---|
| ID 작성자 | 사용자 | 조직 |
| 모든 작업 자산에 대한 단일 사용자 이름 및 암호 | 예 | 예 |
| 암호 수명 및 복잡성 제어 | 사용자 | 조직 |
| Azure DevOps 멤버 자격 제한 | 모든 Microsoft 계정 | 조직의 디렉터리 |
| 추적 가능한 ID | 예 | 예 |
| 조직 및 IP 소유권 | 불분명 | 조직 |
| 2단계 인증 등록 | 사용자 | 조직 |
| 디바이스 기반의 조건부 액세스 | 아니요 | 조직 |
조직에 대해 이 지원을 구성하는 방법에 대해 자세히 알아봅니다.
2단계 인증 요구
로그인하려면 둘 이상의 요소를 요구하여 조직에 대한 액세스를 제한할 수 있습니다. Microsoft Entra ID를 사용하여 여러 요소를 요구할 수 있습니다. 예를 들어 모든 인증 요청에 대해 사용자 이름 및 암호 외에도 전화 인증을 요구할 수 있습니다.
BitLocker 사용
중요한 프로젝트의 경우 Windows 랩톱 또는 데스크톱 컴퓨터에서 BitLocker를 사용할 수 있습니다. BitLocker는 Windows 및 데이터가 상주하는 전체 드라이브를 암호화합니다. BitLocker를 사용하도록 설정하면 해당 드라이브에 저장한 모든 파일이 자동으로 암호화됩니다. 컴퓨터가 잘못된 손에 넘어지면 BitLocker는 프로젝트의 로컬 데이터 복사본에 대한 무단 액세스를 방지합니다.
대체 인증 자격 증명 사용 제한
Git 관련 도구의 기본 인증 메커니즘은 대체 인증(기본 인증이라고도 함)입니다. 이 메커니즘을 사용하면 사용자가 Git 명령줄 작업 중에 사용할 대체 사용자 이름 및 암호를 설정할 수 있습니다. 사용자는 이 사용자 이름/암호 조합을 사용하여 해당 사용자에게 권한이 있는 다른 데이터에 액세스할 수 있습니다. 기본적으로 대체 인증 자격 증명은 기본 페더레이션 인증보다 안전하지 않습니다.
보안 강화를 위해 계속 선택할 수 있습니다. 모든 통신은 HTTPS를 통해 전송되며 암호 복잡성 요구 사항이 있습니다. 조직은 프로젝트의 보안 요구 사항을 충족하기 위해 더 많은 정책이 필요한지 계속 평가해야 합니다.
조직의 보안 요구 사항을 충족하지 않는 경우 대체 인증 자격 증명을 사용하지 않도록 설정할 수 있습니다. 자세한 내용은 조직의 애플리케이션 연결 및 보안 정책 변경을 참조하세요.
조직에 대한 보안 액세스
관리자는 Microsoft Entra ID를 사용하여 Azure DevOps와 같은 Azure 리소스 및 애플리케이션에 대한 액세스를 제어할 수 있습니다. 조건부 액세스 제어가 적용된 상태에서 Microsoft Entra ID는 사용자가 애플리케이션에 액세스하도록 설정한 특정 조건을 확인합니다. 사용자가 액세스 요구 사항을 충족하면 사용자가 인증되고 애플리케이션에 액세스할 수 있습니다.
Azure DevOps는 사용자 지정 Azure DevOps 인증 메커니즘에 특정 유형의 조건부 액세스 정책(예: IP 펜싱)을 적용하도록 지원합니다. 이러한 메커니즘에는 개인 액세스 토큰, 대체 인증, OAuth 및 SSH(Secure Shell) 키가 포함됩니다. 사용자가 타사 클라이언트를 통해 Azure DevOps에 액세스하는 경우 IPv4 기반 정책만 적용됩니다.