Claude Enterprise 감사 로그 사용법: 프로젝트 공개 범위 변경을 조사하는 법

TL;DR

핵심 3줄 요약

이 글에서 다룰 내용

어떤 문제가 생겼을 때 쓰는가

언제 이 절차가 맞는가

이 절차가 맞는 경우

• 프로젝트가 Public과 Private 사이에서 바뀐 시점을 확인해야 할 때
• 승인되지 않은 조직 전체 공개가 의심될 때
• 설정을 되돌리기 전에 변경 주체와 승인 기록을 대조해야 할 때
• 보안 검토표에 로그 행과 복구 결과를 연결해야 할 때

다른 절차가 필요한 경우

프로젝트 내용이나 채팅 입력·출력을 확인하려는 경우에는 이 감사 로그 export만으로 해결할 수 없습니다. 공식 문서에 따르면 감사 로그에는 채팅·프로젝트의 제목과 내용이 없고 고유 식별자만 포함됩니다. Primary Owner의 별도 data export와 감사 로그 export는 서로 다른 범위입니다.

Enterprise에서 customer-managed encryption keys를 사용하면 Export logs 버튼으로 내보낼 수 없습니다. 이 경우 Compliance API를 포함한 현재 조직의 승인된 조사 경로를 관리자와 확인합니다.

감사 로그에서 확인할 수 있는 것

Organization Owner와 Primary Owner는 Organization settings > Data and Privacy 에서 Export logs 를 눌러 지난 180일 감사 로그를 요청할 수 있습니다. 요청한 Owner에게 이메일 다운로드 링크가 오며 링크는 24시간 동안 유효합니다. 로그 집계 때문에 메일 수신까지 시간이 걸릴 수 있습니다.

조사에 주로 쓰는 열은 다음과 같습니다.

• created_at : 로그가 기록된 시각
• actor_info : 작업을 수행한 주체 정보
• event : 사건 유형
• event_info : 사건에 딸린 변경 정보
• entity_info : 영향을 받은 대상 정보
• ip_address : 제공 가능한 경우의 IP 주소
• device_id : 제공 가능한 경우의 기기 식별자
• user_agent : 작업에 사용된 프로그램 정보
• client_platform : iOS나 Android 같은 모바일 플랫폼 정보

모든 행에 IP 주소나 기기 정보가 들어온다고 가정하면 안 됩니다. 공식 스키마도 일부 열을 제공 가능한 경우의 값으로 설명합니다. 값이 비어 있으면 추정하지 말고 확인 필요 로 남깁니다.

따라 하는 7단계

1단계. 사건 범위와 승인자를 고정합니다

조사 문장에 대상 프로젝트, 의심 시각, 현재 공개 범위, 승인자를 적습니다. 예를 들면 “프로젝트 P가 8월 11일 14:00 KST 전후에 Private에서 Public으로 바뀌었는지 확인한다”입니다.

조사 기준 시간대를 KST 또는 UTC 하나로 정하고 끝까지 유지합니다. 관리자 화면, 이메일, 변경 요청서의 시간대가 다르면 타임라인이 뒤집힐 수 있습니다.

2단계. 현재 공개 범위를 읽기 전용으로 확인합니다

프로젝트 작성자 또는 승인된 관리자가 대상 프로젝트의 Share 화면을 엽니다. General access 가 Everyone at [your organization] 인지 Only people invited 인지 기록합니다. 이 단계에서는 공개 범위를 바꾸지 않습니다.

Public 프로젝트는 조직 구성원이 Team 탭에서 찾고 사용할 수 있습니다. 하지만 프로젝트 안의 채팅은 사용자가 따로 공유하지 않는 한 다른 구성원에게 자동 공개되지 않습니다. 프로젝트 공개 범위와 채팅 공유 링크를 같은 것으로 처리하지 않습니다.

3단계. 지난 180일 감사 로그를 요청합니다

Organization Owner 또는 Primary Owner 계정으로 Organization settings > Data and Privacy 를 엽니다. Export logs 를 눌러 로그를 요청합니다. 요청 시각과 요청자를 내부 조사 기록에 남깁니다.

이메일로 온 다운로드 링크는 24시간만 유효합니다. 원본 파일을 승인된 조사 위치에 보존하고 해석·정렬용 사본을 따로 만듭니다. 원본 행을 직접 수정하지 않습니다.

4단계. 사건 후보 행을 좁힙니다

사본에서 event 가 project_visibility_changed 인 행을 찾습니다. created_at , actor_info , entity_info , event_info.updated_privacy 를 추출합니다. 대상 프로젝트 식별자와 의심 시간 범위가 맞는 행만 검토표에 넣습니다.

프로젝트 이름이 로그에 반드시 나타난다고 가정하지 않습니다. 공식 문서상 감사 로그에는 프로젝트 제목과 내용이 없고 고유 식별자만 포함됩니다. 현재 프로젝트와 로그의 식별자를 조직의 승인된 방법으로 연결하지 못하면 확인 필요 로 보류합니다.

5단계. 로그 행과 사람 승인 기록을 대조합니다

실행자, 변경 시각, 변경 결과, 승인자, 승인 범위, 승인 시각을 한 행에 놓습니다. updated_privacy 가 바뀌었다는 기록만으로 정상 변경이나 침해를 단정하지 않습니다.

승인 문서가 없거나 실행자가 예상 담당자와 다르면 후속 조사가 필요합니다. IP 주소, 기기 식별자, user agent가 비어 있어도 행을 삭제하지 않습니다. 누락 상태 자체를 보존합니다.

6단계. 복구안을 승인받아 공개 범위를 바꿉니다

조사 결과 승인되지 않은 Public 전환으로 판단됐고 복구 승인을 받았다면 프로젝트 작성자가 Share > General access 에서 Only people invited 를 선택합니다. 반대로 승인된 조직 공개를 복구해야 한다면 Everyone at [your organization] 을 선택합니다.

복구 전에 초대된 Viewer와 Editor, 그룹, 별도 채팅 공유 링크를 함께 확인합니다. 프로젝트를 Private으로 바꾸는 작업이 별도 채팅 링크 회수나 다른 접근 경로까지 자동으로 해결한다고 추정하지 않습니다.

7단계. 차단과 정상 협업을 함께 검증합니다

복구 뒤 승인되지 않은 일반 구성원은 프로젝트를 찾거나 열 수 없어야 합니다. 승인된 초대 사용자는 의도한 Can view 또는 Can edit 권한으로 계속 접근할 수 있어야 합니다. 공개 범위만 보지 말고 양쪽 결과를 기록합니다.

마지막으로 새 감사 로그 export 또는 승인된 Compliance API 조회에서 복구 사건을 확인할 수 있는지 조직 절차에 따라 검토합니다. 이번 작업의 완료물은 원본 로그 위치, 조사 행, 승인 증빙, 복구 전후 접근 결과를 연결한 내부 검토표입니다.

그대로 복사해 쓸 프롬프트

실전 활용 팁

주의할 점

자주 묻는 질문

출처

마무리

Claude Enterprise 감사 로그 조사의 첫 단계는 설정을 바로 되돌리는 일이 아닙니다. 원본을 보존하고 project_visibility_changed 행을 승인 기록과 연결해야 합니다. 그 다음 사람 승인을 받아 공개 범위를 복구하고, 승인되지 않은 접근이 막혔는지와 정상 협업이 유지되는지를 함께 확인합니다.