audit.2 분석을 audit.3로 전환하기
Audit.3는 직접 API 수집과 범주별 필드 규약을 제공하는 새 로그 형식입니다. 기존 분석의 단순한 열 이름 변경으로 전환을 끝낼 수는 없습니다. 상세 구조와 이벤트 이름이 달라질 수 있으므로 실제로 필요한 행동과 리소스를 기준으로 분석을 이전합니다.
필드와 이벤트의 차이
request_params와 result_params는 각각 requestFields와 resultFields가 되지만 내부 구조는 달라질 수 있습니다. 과거 요청 필드의 정보가 새 결과 필드에 있거나 그 반대일 수 있으므로 양쪽을 확인합니다.
새 name은 일반적으로 제품명과 엔드포인트명을 대문자 snake case로 조합합니다. 과거 이벤트 이름과 완전한 일대일 대응이 있는 것은 아닙니다. 가능하면 최상위 categories, product, service, entities와 users를 사용합니다. Users에는 관련 사용자 ID가 있지만 프로필과 그룹은 현재 채우지 않으므로 필요한 경우 따로 보강합니다.
과거 이력과 전환 기간
Audit.3는 활성화된 뒤의 이벤트만 기록합니다. 그 전의 이력은 audit.2로 남으며 소급 변환하지 않습니다.
2025년 11월 24~25일의 인프라 갱신 중 일부 플랫폼 인스턴스에는 약 3시간의 audit.3 가용성 공백이 있었을 수 있습니다. 해당 시기를 조사할 때에는 audit.2를 보완 자료로 사용하고, 2025년 12월 4일 이후의 분석에는 audit.3로 전환하는 것이 권장됩니다.
두 형식을 함께 기록한 전환 기간에는 양쪽 분석을 비교할 수 있습니다. 같은 사건을 양쪽에서 읽는 구간의 중복과 형식별 측정 차이를 고려해야 합니다.
외부 SIEM의 전환
list-log-files와get-log-file-content를 통한 audit.3 직접 수집을 구성합니다.- 새 스키마에 맞게 파싱 규칙을 바꿉니다.
- 가능한 탐지 규칙을 서비스별 이벤트 이름 대신 범주 기반으로 바꿉니다.
- 검토 기간 동안 기존 audit.2 수집과 함께 운용합니다.
- 필요한 탐지와 알림이 기대한 이벤트를 포착하는지 확인합니다.
- 충분한 범위를 확인한 뒤 audit.2 Foundry 내보내기와 SIEM 수집을 중단합니다.
직접 수집은 일반적인 약 15분 수준의 전달 지연을 사용하며 Foundry 데이터셋을 경유하는 단계가 없습니다. 설정 권한과 토큰 진행 방식은 감사 로그 수집을 참조합니다.
Foundry 분석의 전환
Control Panel에서 새 audit.3 내보내기 데이터셋을 만들고 검토 중에는 기존 audit.2 데이터셋도 유지합니다. Global Branch를 사용하면 여러 코드 저장소의 Pull request를 한 전환 작업으로 묶을 수 있습니다. Data Lineage에서 audit.2의 하류 분석을 찾아 유지할 분석과 제거할 의존 관계를 결정합니다.
예를 들어 과거에 EXPORT_DATASET, DOWNLOAD_FILE, CREATE_EXTERNAL_CONNECTION 같은 이벤트 이름을 나열해 찾았다면 새 분석은 dataExport 범주를 사용합니다. 다음은 가상의 입력 및 출력 경로를 사용하는 완전한 Python 변환입니다. 실제 감사 로그 데이터셋과 저장 위치로 바꿉니다.
from transforms.api import Input, Output, transform
from pyspark.sql import functions as F
@transform(
audit_logs=Input("/Security/Audit/audit3_export"),
exports=Output("/Security/Audit/data_exports"),
)
def collect_data_exports(audit_logs, exports):
source = audit_logs.dataframe()
filtered = source.filter(F.array_contains(F.col("categories"), "dataExport"))
exports.write_dataframe(filtered)
Categories는 집합 또는 배열 형태이므로 문자열의 부분 포함 검사 대신 배열 원소 포함 검사를 사용합니다. 대규모 조사에서는 모니터링 예제처럼 date와 time 범위를 먼저 좁힙니다.
전환 검토와 완료
같은 기간에 양쪽 분석을 실행해 기대한 사건이 포착되는지 비교합니다. 범주 필터가 이전 이벤트 이름 목록과 같거나 더 적절한 범위를 포착하는지, SIEM 알림이 동작하는지 확인합니다.
검토가 끝나면 모든 하류 소비자를 audit.3 API나 데이터셋으로 바꾸고 Control Panel에서 audit.2 내보내기를 Pause export로 중단합니다. 외부 SIEM의 audit.2 수집도 중단합니다. 새 audit.2 로그의 수집을 중단한 뒤에도 기존 audit.2 기록은 과거 기간의 조사에 필요할 수 있습니다.
이전 중의 문제 해결
대응하는 이벤트 이름이 없음
엔드포인트가 대체되었거나 의미가 낮은 이벤트를 새 형식으로 옮기지 않은 경우가 있습니다. 먼저 현재 audit.2에서 그 이벤트가 실제로 계속 생성되는지 확인합니다. 생성된다면 audit.2의 trace_id 값을 audit.3의 traceId와 연결해 관련 이벤트를 찾습니다. 대응을 찾지 못하면 Palantir Support에 문의합니다.
중첩 필드 파싱
기존 request_params나 result_params의 상세 내용을 풀어 쓰던 분석은 새 구조에 맞게 다시 작성해야 합니다. 범주별 필드에서 필요한 값의 위치를 확인하고 가능하면 entities와 users 같은 최상위 필드를 사용합니다. 선택적 값이나 예상과 다른 구조를 처리하되 누락을 정상적인 성공으로 숨기지 않습니다.
전환 날짜를 가로지르는 분석
SIEM에서는 전환 중 함께 수집한 과거 데이터를 보존 정책에 맞게 유지합니다. Foundry에서는 두 데이터셋의 필요한 필드를 공통 구조로 정규화한 뷰를 만들고 type에 따라 파싱을 구분할 수 있습니다. 스키마가 다른 원시 행을 그대로 합치는 것만으로 의미가 정렬되지는 않습니다. 구조와 이벤트 범위 차이 때문에 모든 지표가 완전히 이어지지 않을 수 있습니다.