감사 로그의 수집, 전송과 보존
Foundry 감사 로그는 누가 어떤 작업을 언제 어떤 리소스에 수행했는지 조사하는 기록입니다. 사용자, 세션과 서비스 계정의 활동을 분석해 사고 대응, 접근 검토와 책임 확인에 사용할 수 있습니다. 로그에는 이름, 이메일이나 검색어 등 민감한 정보가 포함될 수 있으므로 목적에 필요한 담당자만 접근하도록 관리합니다.
전용 보안 정보 및 이벤트 관리(SIEM) 시스템이 있다면 그곳에서 수집하고 분석하는 방식을 권장합니다. 전용 시스템이 없거나 가벼운 분석이 필요하면 Foundry 데이터셋으로 내보내 플랫폼 안에서 분석할 수 있습니다.
audit.3와 과거 audit.2
새 수집 및 분석에는 audit.3를 사용합니다. 일반적인 전달 지연은 약 15분 수준이며 직접 API 수집, 일관된 범주와 구조화된 필드, 제품 및 연관 엔터티 정보가 제공됩니다.
audit.2는 과거 기간의 분석과 이전 작업을 위해 남아 있는 형식입니다. 로그를 압축하고 환경별 아카이브 저장소로 옮기는 데 약 24시간 또는 그 이상이 걸릴 수 있습니다. 직접 SIEM 수집 API가 없으므로 Foundry 데이터셋으로 내보낸 뒤 분석하거나 외부로 전달해야 합니다. 범주는 선택적이며 제품마다 필드 구조가 달라질 수 있습니다.
새 이벤트의 audit.2 기록은 종료 예정이며, 과거 이벤트가 audit.3로 소급 변환되지는 않습니다. 스키마와 전환 절차를 구분해 적용합니다.
SIEM으로 직접 수집
audit.3는 List Log Files로 날짜 범위의 파일 목록을 받고 Get Log File Content로 파일 내용을 가져올 수 있습니다. 먼저 Foundry에 감사 로그 데이터셋을 만들 필요가 없습니다. SIEM의 기존 수집 및 알림 체계에 연결하면 중간 데이터셋의 추가 저장 및 연산을 줄일 수 있습니다.
페이지 토큰과 반복 조회
- 첫 요청에
startDate를 지정하고 필요하면endDate도 지정합니다. - 응답의
nextPageToken을 저장합니다. - 이후 요청에는 저장한 토큰을 전달해 이어서 새 파일을 조회합니다.
data가 비어 있거나 생략되어도nextPageToken은 계속 반환됩니다. 현재 새 파일이 없다는 뜻이므로 토큰을 저장하고 다음 주기에 다시 사용합니다.
종료 날짜를 생략하면 최신 파일을 계속 조회하는 수집에 사용할 수 있습니다. 페이지 진행 토큰을 따라가며 수집하되, 로그 자체의 중복은 스키마의 logEntryId로 구분합니다. 파일 목록 진행과 로그 행의 중복 가능성을 같은 보장으로 해석하지 않습니다.
인증과 조직 권한
요청에는 Authorization: Bearer <access_token>을 사용합니다. 권장 구성은 Developer Console의 외부 애플리케이션에 감사 로그 읽기 접근을 설정하고 Client credentials grant로 api:audit-read scope의 토큰을 발급받는 방식입니다.
Scope와 앱 설정만으로 조직 권한을 얻지는 않습니다. Control Panel에서 로그를 조회할 조직의 Organization permissions를 열고, 토큰의 사용자에게 Create datasets with audit logs for the organization 작업 권한 묶음이 있는 기존 역할 또는 사용자 정의 역할을 부여해야 합니다. 서비스 계정을 사용한다면 앱이 생성한 서비스 사용자에게 부여합니다. 조직이 하나인 플랫폼 인스턴스에도 이 조건이 적용됩니다.
Developer Console을 사용할 수 없다면 일반 OAuth Client credentials 구성을 사용할 수 있습니다. 개인 관리자 토큰은 개인 계정에 대한 운영 의존성, 과도한 권한, 교체의 어려움과 자동화 주체가 불명확한 감사 기록 때문에 운영 SIEM 수집에 권장하지 않습니다. OAuth 토큰 규약을 참조합니다.
Foundry 데이터셋으로 내보내기
Control Panel에서 조직별로 audit.2 또는 audit.3 내보내기 데이터셋을 만들 수 있습니다. Pipeline Builder는 빠른 초기 분석에, Code Repositories는 대규모 장기 분석에 사용할 수 있습니다. Contour로 분석할 때에는 데이터가 매우 클 수 있으므로 먼저 필터링합니다.
최종 목적지가 외부 SIEM이면 audit.3 직접 API 수집을 우선 고려합니다. Foundry 데이터셋을 외부로 전달해야 하는 경우에는 Data Connection의 내보내기를 사용할 수 있습니다.
권한과 생성 절차
Audit.3 내보내기에는 대상 조직의 audit-export:orchestrate-v3 작업 권한이 필요합니다. Control Panel의 Organization permissions에서 Organization administrator 역할로 부여할 수 있습니다.
- Control Panel을 열고 상단에서 대상 조직을 선택합니다.
- 왼쪽 Search에서
Audit logs를 찾아 엽니다. Create export dataset을 선택합니다.- 새 형식은
audit.3, 이전 기간의 이력 분석은audit.2를 선택합니다. - 데이터셋의 저장 위치와 이름을 지정합니다.
- 민감한 사용 정보에 필요한 보안 표지를 적용하고 업무상 필요한 관리자만 읽도록 구성합니다. 기본적으로 선택한 조직이 데이터셋에 적용됩니다.
- 필요하면 시작 날짜 필터로 그 날짜 이후 이벤트만 포함합니다.
- 필요하면 데이터셋별 보존 기간을 지정합니다. 최댓값은 730일입니다.
- 보안 영향과 구성을 확인한 뒤 동의 항목을 작성하고
Create export를 선택합니다.
보존 기간의 기준
보존 기간은 이벤트 시각이 아니라 로그가 내보내기 데이터셋에 추가된 트랜잭션 시각을 기준으로 합니다. 삭제 대상으로 표시된 트랜잭션은 실제 삭제까지 최대 7일이 더 걸릴 수 있습니다.
가상의 첫 예에서 시작 날짜가 2025-01-01, 보존 기간이 90일이면 처음에는 그 날짜 이후 로그를 한꺼번에 가져옵니다. 데이터셋을 만든 지 90일이 지나면 초기에 적재한 과거 로그의 트랜잭션도 보존 기간을 넘으므로 데이터셋 크기가 크게 줄 수 있습니다. 이후에는 최근 90일 안에 추가한 트랜잭션을 유지합니다.
두 번째 예에서 시작 날짜가 생성 시점 기준 30일 전이고 보존 기간이 90일이면 처음에는 과거 30일 로그가 들어옵니다. 새 로그가 쌓이며 트랜잭션 기준 90일의 이동 구간을 유지합니다. 늦게 적재한 과거 이벤트는 이벤트 시각만으로 즉시 삭제되지 않습니다.
갱신과 일시정지
새 로그는 주기적으로 append됩니다. Audit.3의 한 번 추가는 최대 100 GiB 및 10,000개 파일, audit.2는 최대 10 GiB입니다. 큰 추가량은 주로 초기 적재에 필요하며 실행 시간은 새 로그 양에 비례합니다.
대규모 환경의 audit.2 초기 빌드에는 수 시간 이상 빈 append 트랜잭션이 생길 수 있습니다. 전체 이력을 처리하는 과정의 동작이며 새 audit.3 내보내기에는 같은 초기 지연이 없습니다. 빌드 일정은 audit-export 서비스가 관리하며 사용자 화면에 표시하지 않습니다.
Audit.3 데이터셋의 date는 Hive 파티션 열입니다. 쿼리에서는 datetime이 아닌 날짜형처럼 나타나며, 먼저 date를 제한하면 파티션을 줄여 분석 속도를 높일 수 있습니다. 정확한 시간 경계는 이어서 time으로 제한합니다.
내보내기를 중단하려면 해당 조직의 Audit logs 페이지에서 데이터셋 작업 메뉴의 Pause export를 선택합니다. 같은 메뉴의 Resume export로 다시 시작할 수 있습니다.
조직별 로그 귀속
환경의 로그는 단일 아카이브에 기록한 뒤 전달 과정에서 사용자 식별자를 조직에 연결합니다. 특정 조직의 내보내기에는 그 조직에 귀속된 로그만 포함합니다.
사람이 아닌 서비스 사용자만 수행한 작업은 보통 조직 소속이 없어 특정 조직에 귀속되지 않습니다. 예외적으로 Client credentials grant의 외부 앱 서비스 사용자가 등록 조직에서만 사용되는 경우에는 그 조직에 귀속된 감사 로그를 생성합니다. 단순히 서비스 사용자의 organization 필드가 비어 있다는 사실만으로 이 예외를 무시하지 않습니다.
보안 탐지와 조사 운영은 감사 로그 모니터링, 요청 및 결과 필드의 의미는 감사 범주를 참조합니다.