# Git 저장소 접근 기록

Canonical: https://www.nsecsoft.com/ko/docs/ping64-data-security/dlp/git/records/

Language: ko-KR

Updated: 2026-11-15T03:47:44.024075Z

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

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

전체 설정은 [신뢰할 수 있는 Git 저장소 정책](https://www.nsecsoft.com/ko/docs/ping64-data-security/dlp/git/policy/)을 참조하십시오.

기존 기록만 조회한다면 해당 조회 권한이 있는 계정으로 아래 조회 단계에 바로 진행할 수 있습니다. 조회만을 위해 정책을 새로 만들거나 시험 이벤트를 발생시킬 필요는 없습니다. 새 기록을 검증하려면 먼저 기존 적용 정책을 확인하고 필요한 경우에만 정책 관리 권한이 있는 담당자가 수정한 후 시험합니다.

## 구성 전 준비

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

## 신뢰할 수 있는 저장소 구성

1.  **DLP**의 애플리케이션 화면에서 **Git Repository Access Control**을 열고 신뢰 저장소 정책을 선택합니다. 영문 화면에서 이 탭은 **Trusted Repository Policies**입니다.
2.  기존 정책의 활성화 상태, 적용 시간, 대상 엔드포인트 및 신뢰 저장소 규칙을 확인합니다. 저장소 범위, 프로토콜, 호스트, 포트와 경로도 점검합니다. 테스트에 적합한 기존 설정은 다시 저장하지 않고 재사용합니다. 변경이 필요한 경우에만 권한 있는 관리자가 영향을 평가하고 [신뢰 Git 저장소 정책](https://www.nsecsoft.com/ko/docs/ping64-data-security/dlp/git/policy/)에 따라 수정해 전체 정책을 저장한 뒤 시험 엔드포인트의 수신을 확인합니다.
3.  승인된 테스트 계정과 비민감 콘텐츠로 신뢰 및 비신뢰 대상을 각각 테스트합니다. 아래에서 접근 기록을 조회해 일치 결과와 실행 결과를 비교합니다. 테스트만을 위해 범위를 확대하거나 운영 업무에 영향을 주지 마십시오.

## 접근 기록 확인

1.  **Git Repository Access Control** 화면에서 접근 기록을 선택합니다. 처음 열면 오늘과 그 이전 6일이 기본 범위입니다. 다른 기간을 조사하려면 날짜를 변경합니다. 영문 화면에서 기록 탭은 **Access Records**입니다.
2.  필요에 따라 엔드포인트를 선택하고 저장소 주소 키워드를 입력하며 Git 작업, 일치 결과 및 실행 결과로 필터링합니다. 목록에서 저장소, 작업, 일치 및 실행 결과, 엔드포인트와 시간을 확인하고 필요한 경우 페이지를 이동합니다. 영문 화면의 필터 이름은 **Git Operation**, **Match Result**, **Enforcement Result**입니다.
3.  상세 정보를 열어 대상, 정책, 엔드포인트 및 시간을 대조합니다. 비신뢰 일치가 차단 성공을 의미하지 않으므로 실행 결과도 확인해야 합니다.
4.  대상이 식별되지 않으면 업무 상황과 엔드포인트 상태를 함께 조사합니다. 기록에는 민감한 업무 정보가 포함될 수 있으므로 조직 기준에 따라 접근을 제한합니다.

## 제한 및 문제 해결

-   **적용 범위:** 식별 가능한 표준 Git 네트워크 작업에는 clone, fetch, pull 및 push가 포함됩니다. 다른 명령, 옵션, 클라이언트 및 Git LFS 시나리오는 각각 시범 검증해야 합니다. 기록이 없다고 접근이 없었던 것은 아닙니다.
-   **대상을 식별할 수 없는 경우:** 일부 대상을 분석할 수 없으면 비신뢰 저장소로 차단하지 않습니다. 다른 보안 조치와 함께 사용하고 모든 외부 전송을 보장한다고 생각하지 마십시오.
-   **비신뢰 접근이 차단되지 않은 경우:** 실제 대상이 식별되었는지와 일치 및 프로세스 실행 결과를 확인합니다. 종료가 실패하거나 프로세스가 이미 종료되었을 수 있습니다. 종료에 성공했더라도 그 전에 네트워크 통신이나 데이터 전송이 없었다고 단정할 수 없습니다.
-   **신뢰 저장소에 영향이 있는 경우:** 정책 배포 상태와 실제 주소의 프로토콜, 포트 및 경로를 확인합니다. 저장소 주소 재작성과 네임스페이스 범위도 확인합니다. 조정 후 허용 및 제한 시나리오를 각각 다시 시험합니다.
-   **기록을 찾지 못하는 경우:** 엔드포인트와 정책 상태, 라이선스, 계정 조회 범위, 시간 및 필터를 확인하고 보고를 기다린 뒤 다시 조회합니다. 정상적인 개발 업무가 영향을 받으면 조직 절차에 따라 먼저 복구하고 정책 범위를 확인합니다.