감사 로그로 보안 활동 조사하기

감사 로그 분석은 사용자나 서비스가 어떤 리소스에 언제 어떤 작업을 했는지 연결해 사고와 목적 외 사용을 조사하는 과정입니다. 이름, 이메일과 사용 내용 등이 포함될 수 있으므로 로그 자체도 민감 데이터로 취급하고 필요한 담당자에게만 접근을 부여합니다.

전용 SIEM이 있으면 audit.3 파일을 API로 직접 수집하는 경로를 우선 고려합니다. 별도 보안 분석 도구가 없으면 조직별 Foundry 내보내기 데이터셋을 사용할 수 있습니다. Audit.2는 과거 기간 분석에 사용하며, 새 분석은 audit.3의 범주와 필드로 구성합니다. 전송과 권한을 먼저 설정합니다.

로그 무결성과 보존

로그 생성부터 저장까지의 기반 구조는 추가 기록만 가능한 방식으로 설계되어 있으며 아카이브 저장소 접근도 엄격하게 제한됩니다. 법적 사유로 로그에 유입된 정보를 제거해야 하는 경우에는 Palantir Support와 해당 데이터 및 처리 계획을 확인합니다. 일반적인 분석 데이터셋 편집을 원본 감사 아카이브 수정으로 해석하지 않습니다.

주요 탐지 목적

보안 사고 조사에서는 다음과 같은 행동을 함께 봅니다.

• 평소와 다른 로그인 시각과 위치, 물리적으로 불가능한 이동처럼 계정 탈취가 의심되는 패턴
• 대량 데이터 조회 후 내보내기, 특히 평상시 업무 시간 밖의 반출
• 예상하지 못한 권한 변경이나 평소 범위를 넘는 리소스 접근
• 예상하지 못한 출처나 의심스러운 패턴의 코드 실행

규정 및 책임 검토에서는 승인한 범위와 목적의 접근인지, 허가받은 사용자가 접근 목적을 벗어났는지, 법적 보존 또는 조사에 필요한 사용자 및 데이터 활동을 확보할 수 있는지 확인합니다.

사용자 데이터 접근 조사 예

다음은 가상의 이상 접근 알림을 조사하는 절차입니다.

1. 조사할 time 구간과 사용자를 정하고 categories에 dataLoad가 있는 로그를 찾습니다.
2. 해당 범주의 요청 및 결과 필드에서 실제 접근한 데이터셋을 확인합니다. 필드 위치는 범주별 규약을 사용합니다.
3. 같은 활동에서 dataExport가 있는지 찾아 내보내기 기록을 확인합니다.
4. users와 entities를 사용해 관련 사용자와 리소스를 연결하고 시간 순으로 정리합니다.
5. 사용자의 업무 맥락을 확인해 정당한 활동인지 판단합니다.

DataLoad와 dataExport는 다른 사건입니다. 로그의 부재만으로 모든 반출이 없었다고 단정하지 말고 수집 범위와 다운로드 통제의 한계도 고려합니다.

교육 자격과 개인정보 반출 검토 예

가상의 의료 데이터 관리팀이 교육을 이수한 사용자만 환자 데이터의 내보내기를 수행했는지 확인한다고 가정합니다. 시간 범위를 좁히고 dataExport 범주 중 환자 데이터 리소스를 대상으로 한 이벤트를 선택합니다. uid를 내부 교육 자격 기록과 대조하고, 관련 내보내기에 지속적인 알림을 구성하며 접근 및 내보내기 활동을 주기적으로 보고합니다.

Uid는 가장 하류 호출자입니다. 서비스가 사용자를 대신한 사건에서는 users 및 onBehalfOf 같은 실행 맥락도 확인해 책임 주체를 구분합니다. 로그 자체가 교육 자격이나 사용 목적의 적정성을 판단하지는 않습니다.

범주별 탐지 예

예를 들어 인증 확인 실패를 사용자별로 묶어 일정 시간 안에 5회를 초과한 경우 조사 대상으로 삼을 수 있습니다. 이 수치는 가상의 탐지 임계값이며 조직의 정상 활동에 맞게 정해야 합니다. 인증 성공 여부는 authenticationCheckResult 등의 해당 범주 필드와 로그 result를 함께 해석합니다.

민감 리소스의 권한 변경은 managementPermissions 범주를 고르고 resourcesWithPermissionsChanges를 관리 대상 목록과 대조합니다. 모든 리소스 식별자가 최상위 resource_id라는 단일 열에 있다고 가정하지 않습니다.

시간과 범주를 먼저 필터링

대규모 감사 데이터는 집계나 시각화 전에 시간 구간과 범주를 좁혀야 합니다. Foundry audit.3 내보내기에는 date 파티션이 있으므로 date를 먼저 제한한 뒤 time의 정확한 범위를 적용하면 효율적입니다.

다음은 가상의 하루 동안 내보내기 기록을 추출하는 완전한 변환 예입니다. 예제 입력에서는 date가 이벤트의 UTC 날짜와 일치한다고 가정합니다. 실제 데이터셋에서는 조사할 이벤트를 포함하는 파티션 범위를 확인한 뒤 날짜와 경로를 바꿉니다. 정확한 시간 조건에는 끝 시각을 제외한 반열린 구간을 사용합니다.

from transforms.api import Input, Output, transform
from pyspark.sql import functions as F


@transform(
    audit_logs=Input("/Security/Audit/audit3_export"),
    output=Output("/Security/Audit/export_investigation"),
)
def collect_export_investigation(audit_logs, output):
    source = audit_logs.dataframe()
    selected = source.filter(F.col("date") == F.lit("2026-10-01").cast("date"))
    event_time = F.to_timestamp(F.col("time"))
    selected = selected.filter(
        (event_time >= F.to_timestamp(F.lit("2026-10-01T00:00:00Z")))
        & (event_time < F.to_timestamp(F.lit("2026-10-02T00:00:00Z")))
    )
    selected = selected.filter(F.array_contains(F.col("categories"), "dataExport"))
    output.write_dataframe(selected.dropDuplicates(["logEntryId"]))

이 예제는 같은 로그 행의 수집 중복을 logEntryId로 제거합니다. 같은 eventId의 여러 행은 스트리밍 응답의 시작과 종료처럼 별도 기록일 수 있으므로 eventId만으로 삭제하지 않습니다. 직접 API로 받은 원시 로그를 분석한다면 date 파티션 열이 없는 구조도 고려해 수집 시 날짜 범위를 제한합니다.

탐지 운영 기준

자동 알림 전에 사용자 또는 그룹의 평소 로그인 시간과 위치, 데이터 접근 대상 및 빈도와 양, 내보내기 목적과 시각, 권한 변경 절차를 파악합니다. 정상 활동의 기준이 있어야 이상 징후의 의미와 오탐을 판단할 수 있습니다.

중요한 실패나 민감 데이터 반출에는 신속한 알림을, 사용량 증가와 권한 변화 추세에는 주기적인 분석을 구성할 수 있습니다. 알림을 조사하고 대응할 담당 절차를 정하고 정기 감사로 탐지 범위와 효과를 확인합니다. 자주 필터링하는 필드는 SIEM이나 분석 환경에 맞게 색인 또는 사전 구성을 적용합니다.

Palantir CIRT(Computer Incident Response Team)는 호스팅된 고객 플랫폼의 보안 위협을 감시하며 의심 활동을 발견하면 고객에게 연락해 확인합니다. 고객은 자기 조직의 정상 업무와 정책을 알고 있으므로 별도의 감사 모니터링을 운영해야 합니다. 플랫폼 수준 탐지만으로 조직의 모든 목적 외 사용을 판단할 수는 없습니다.

처음 구성할 때에는 전달 경로와 권한을 정하고, 중요한 범주부터 조회를 만든 뒤 과거 활동으로 기준을 세웁니다. 이후 우선순위가 높은 알림을 적용하고 운영 결과에 따라 임계값과 범위를 조정합니다. 지원이 필요하면 Palantir Support에 문의합니다.