<<팔란티어의 차세대 감사 로깅 시스템 : 규모있게 신뢰를 구축하는 방법>>
팔란티어의 차세대 감사 로깅 시스템에 대한 팔란티어 블로그 글을 살펴보았다.
매일, 고객 조직들은 가장 민감한 데이터와 핵심 운영을 Palantir 플랫폼에 맡기고 있으며, 국가 안보 임무를 조율하는 정부 기관, 환자 정보를 보호하는 의료기관, 사기 적발을 수행하는 금융기관까지 이들은 중요한 의사결정을 내리기 위해 Palantir에 의존하고 있다.
이 신뢰는 쉽게 주어지지 않으며, 그냥 유지되는 것도 아니다. 투명성과 책임성, 그리고 팔란티어가 창업 초기부터 지켜온 원칙, 즉 “플랫폼에서 이루어지는 모든 사용자의 행동은 감시 가능해야 한다(Auditable)”는 기반 위에 세워지고 있다.
팔란티어는 프라이버시와 보안은 자사의 후순위 고려사항이 아니라고 강조했는데,
세계 최초의 Privacy and Civil Liberties(PCL) 엔지니어링 팀이 존재하며, “프라이버시 보호 기술은 핵심 기능이어야 한다”는 철학을 바탕으로 움직여 왔다고 설명했다. 이를 가능하게 만드는 가장 중요한 요소 중 하나가 바로 감사 로그(audit logs)라고 함.
감사 로그는 누가, 언제, 어디서, 무엇을 했는지에 대한 불변(immutable) 기록이며,
보안팀은 이를 통해 사건 대응을 수행하고, 준법감시 조직은 규제 준수를 증명하며, 조직은 복잡한 협업 환경에서 요구되는 책임성을 갖출 수 있다.
.
.
.
<“감시자를 감시하라” : 감사 가능성(Auditability)을 핵심 가치로>
누가 감시자를 감시하는가?
팔란티어에게 이 문장은 단순한 수사가 아니라 설계 요구사항이며,
Foundry, AIP, 그리고 도메인 특화 제품들은 민감한 데이터를 다루고 복잡한 분석을 수행하는 강력한 기능을 제공하고 있기에, 강력한 기능에는 큰 책임이 따르고, 책임에는 반드시 책임 추적성(Accountability)이 필요하다는 설명.
이 책임을 운영적으로 구현하는 도구가 바로 감사 로깅 시스템이라고 한다.
"감사 로깅은 단지 규정 준수를 위한 것이 아닙니다.
그것은 신뢰의 기반입니다."
.
.
.
<대규모 감사 로깅의 어려움>
팔란티어의 플랫폼에서는 매일 수백 테라바이트의 감사 로그가 생성되는데,
문제는 단순한 데이터량이 아니며, 이 로그는 다음을 포함한다.
데이터 접근 요청
분석 쿼리
권한 변경
데이터 내보내기(Export)
온톨로지 기반 동작
그리고 여러 조직이 공유 인프라에서 협업할 수 있는 환경에서 실행.
팔란티어는 Audit.2 세대의 한계는 다음과 같았다고 지적하는데,
Batch Pipeline 기반 접근 속도 한계
제품별 사건(Event) 정의의 비일관성
실제 분석을 수행하기 위해서는 플랫폼 내부 구조에 대한 깊은 이해가 필요했다고 강조했다.
.
.
.
<새로운 기반 : Audit.3 실시간 스트리밍 파이프라인>
Audit.3는 두 가지 핵심 혁신을 담고 있는데,
1) 완전히 재설계된 스트리밍 파이프라인
로그를 쓰는 순간 구조화된 메타데이터 포함
컨테이너별 telemetry agent가 실시간 수집
중간 데이터 저장 제거
수 분 내 로그 접근 가능 (준실시간)
즉, 감사 로그는 “사후 분석(rear-view mirror)” 대상이 아닌
실시간 운영 도구가 된다.
.
.
2) 범주(Category) 기반 표준화된 Audit Schema
Audit.2는 제품별 이벤트명(E.g., READ_DATASET, FETCH_DATA, EXPORT_REPORT)이 달라서 분석이 매우 어려웠는데..
Audit.3에서는 모든 동작이 “카테고리”로 정의된다.
예:
dataExport
dataLoad
authentication
permissionChange
이것이 의미하는 바는?
→ 향후 신규 기능이 추가돼도 분석할 쿼리를 다시 쓸 필요가 없다.
→ SIEM 및 컴플라이언스 규칙이 미래 호환성 확보.
개발자에게는 Build 단계에서 스키마 준수가 강제된다고 함.
.
.
.
<Audit.3가 제공하는 핵심 필드 예시>
categories — 이벤트의 분류(핵심)
entities — 접근 대상 리소스(무엇을?)
users — 참여 사용자(누가?)
origins — 요청의 근원(사용자인가? 자동화인가?)
result — SUCCESS / ERROR / UNAUTHORIZED 등
product — 어떤 Palantir 제품에서 발생했는가
.
.
.
<“이전 vs 이후” 사례 비교>
Audit.2 세계 :
각 제품이 다른 이벤트 이름 사용
Export 유형마다 다른 필드 구조
쿼리 작성자가 내부 구조를 모두 이해해야 함
.
.
Audit.3 세계:
한 줄이면 끝 :
categories contains "dataLoad"
categories contains "dataExport"
"Audit.3는 분석을 개념적 사고로 전환시키며,
더 이상 세부 구현을 기억할 필요가 없습니다."
.
.
.
<SIEM 통합을 위한 공개 API>
조직의 보안 팀과 SOC 환경을 고려하여
list-log-files
get-log-file-content
API 두 개로 직접 감사 로그 수집 가능
→ Foundry를 통하지 않아도 된다
→ SIEM으로 바로 연동 가능
.
.
.
<Audit.2 → Audit.3 마이그레이션>
두 시스템 병행 운영(안정적 전환)
문서 제공
스키마 레퍼런스 제공
API 가이드 제공
미래 확장 가능 구조
.
.
.
<감사 로깅은 “배관 공정(plumbing)”이 아니다>
Audit Logging은 조직의 가치 체계(Value System)를 반영하는 기술이고,
Palantir의 철학은,
프라이버시는 보호되고, 운영은 성공해야 한다.이 둘은 상충 관계가 아니라 상호 강화 관계다.
"Audit.3는 단순한 기술 진화가 아니라,
투명성과 책임성을 실시간 보장하기 위한 기반입니다."
.
.
.
<결론>
Audit.3는 Palantir의 핵심 원칙을 강화할 수 있으며,
모든 행동은 보이는(visible)
모든 행동은 시간적으로 가까운(real-time)
모든 행동은 감사 가능(auditable)
이는 “규모에서의 책임(responsibility at scale)”을 실천하는 기술이라고 강조했다.
#팔란티어 $PLTR
(출처 : 팔란티어 블로그)