신뢰할 수 있는 Git 저장소 정책

Markdown으로 보기

Git 저장소 접근 제어는 Windows 엔드포인트에 신뢰할 수 있는 저장소 범위를 설정하고 식별 가능한 표준 Git 저장소 접근을 기록합니다. 엔드포인트가 신뢰할 수 없는 저장소를 식별하면 관련 Git 프로세스의 종료를 시도합니다. 규칙 일치, 프로세스 종료 여부 및 저장소 작업 완료 여부는 서로 다른 결과이므로 각각 확인해야 합니다.

이 기능은 모든 Git 클라이언트, 명령 또는 전송 방식을 대상으로 한다고 보장하지 않습니다. 저장소 권한, 네트워크 및 다른 데이터 보안 통제를 대신할 수도 없습니다.

구성 전 준비

  • 데이터 유출 방지 정책 관리 권한이 있는 계정으로 정책을 설정합니다. 관련 기록을 조회하려면 해당 조회 권한이 필요하며, 그 권한이 있는 담당자가 확인할 수 있습니다. 시범 Windows 엔드포인트의 연결과 라이선스 및 관리자 가시 범위를 확인합니다.
  • 업무에 필요한 저장소의 주소, 프로토콜과 포트를 정리하고 단일 저장소 허용과 전체 네임스페이스 허용을 구분합니다. 저장소 주소에 비밀번호나 접근 토큰 등의 자격 증명을 포함하지 마십시오. 계정 권한은 Git 서비스에서 계속 관리합니다.
  • 승인된 신뢰 및 비신뢰 테스트 대상을 준비하고 테스트 계정과 비민감 콘텐츠를 사용합니다. 정책으로 개발 또는 빌드가 중단될 수 있으므로 복구 가능한 소수의 엔드포인트에서 먼저 시험하고 복구 방안을 준비합니다.

신뢰할 수 있는 저장소 구성

  1. DLP의 애플리케이션 화면에서 Git Repository Access Control을 열고 신뢰 저장소 정책을 선택합니다. 영문 화면에서 이 탭은 Trusted Repository Policies입니다.
  2. 정책을 생성하거나 편집하고 이름을 입력합니다. 적용 시간과 엔드포인트, 그룹 또는 태그를 확인하고 먼저 시범 범위를 선택합니다.
  3. 신뢰 저장소에 저장소를 추가합니다. 각 규칙에서 정확한 저장소 또는 저장소 네임스페이스를 선택하고 해당 주소를 입력합니다. 정책 하나에 유효한 규칙이 1개 이상 500개 이하 필요하며 중복 규칙은 추가하지 않습니다. 영문 화면에서 Trusted Repositories의 Add Repository를 선택하고 규칙 유형 Exact Repository 또는 Repository Namespace를 선택합니다.
  4. 프로토콜, 호스트, 포트와 경로를 확인합니다. HTTP, HTTPS, SSH, Git 프로토콜 주소 또는 일반적인 SSH 축약 주소를 입력할 수 있습니다. 서로 다른 프로토콜은 자동으로 동일하게 취급되지 않으며 기본 포트가 아닌 경우에도 일치 결과에 영향을 줍니다.
  5. 전체 정책을 저장하고 시범 엔드포인트의 수신을 기다립니다. 신뢰 대상과 비신뢰 대상을 각각 시험하고 접근 기록에서 일치 및 실행 결과를 확인합니다. 검증 후 조직의 변경 절차에 따라 범위를 확대합니다.

다음 주소는 예시일 뿐 기본 신뢰 범위가 아닙니다.

규칙 예시 적용 범위
정확한 저장소 https://git.example.com/team/project.git 해당 저장소에 일치하며 팀의 다른 저장소까지 자동으로 포함하지 않습니다.
저장소 네임스페이스 https://git.example.com/team 해당 경로와 하위 경로에 일치하며 이름 접두사만 비슷한 다른 경로 계층에는 일치하지 않습니다.

예를 들어 HTTPS 규칙이 같은 호스트의 SSH 주소까지 포함한다고 가정하지 마십시오. 두 방식이 모두 필요하면 각각 구성하고 시험합니다. 네임스페이스는 일반적으로 단일 저장소보다 범위가 넓으므로 저장하기 전에 조직의 요구와 일치하는지 확인합니다.

주소 일치 주의 사항: 프로토콜, 호스트와 포트가 같을 때 저장소 경로 끝의 .git은 일치 비교에서 무시됩니다. 호스트 이름은 대소문자를 구분하지 않지만 저장소 경로는 구분합니다. 예를 들어 team/project.git과 team/project는 같은 저장소 경로로 일치하지만 team/Project와 team/project가 같다고 가정하지 마십시오. 실제 서비스 주소로 각각 시험합니다.

제한 및 문제 해결

  • 적용 범위: 식별 가능한 표준 Git 네트워크 작업에는 clone, fetch, pull 및 push가 포함됩니다. 다른 명령, 옵션, 클라이언트 및 Git LFS 시나리오는 각각 시범 검증해야 합니다. 기록이 없다고 접근이 없었던 것은 아닙니다.

  • 대상을 식별할 수 없는 경우: 일부 대상을 분석할 수 없으면 비신뢰 저장소로 차단하지 않습니다. 다른 보안 조치와 함께 사용하고 모든 외부 전송을 보장한다고 생각하지 마십시오.

  • 비신뢰 접근이 차단되지 않은 경우: 실제 대상이 식별되었는지와 일치 및 프로세스 실행 결과를 확인합니다. 종료가 실패하거나 프로세스가 이미 종료되었을 수 있습니다. 종료에 성공했더라도 그 전에 네트워크 통신이나 데이터 전송이 없었다고 단정할 수 없습니다.

  • 신뢰 저장소에 영향이 있는 경우: 정책 배포 상태와 실제 주소의 프로토콜, 포트 및 경로를 확인합니다. 저장소 주소 재작성과 네임스페이스 범위도 확인합니다. 조정 후 허용 및 제한 시나리오를 각각 다시 시험합니다.

  • 기록을 찾지 못하는 경우: 엔드포인트와 정책 상태, 라이선스, 계정 조회 범위, 시간 및 필터를 확인하고 보고를 기다린 뒤 다시 조회합니다. 정상적인 개발 업무가 영향을 받으면 조직 절차에 따라 먼저 복구하고 정책 범위를 확인합니다.

  • Git 저장소 접근 기록

수정일

문서 검색