보안 감사

감사 로그는 감사자가 Foundry 사용자가 수행한 액션을 이해하는 주요 방법입니다.

Foundry의 감사 로그에는 다음을 추론할 수 있는 충분한 정보가 포함되어 있습니다:

• 누가 액션을 수행했는지
• 무엇이 액션이었는지
• 언제 액션이 발생했는지
• 어디서 액션이 발생했는지

일부 경우, 감사 로그에는 이름 및 이메일 주소와 같은 개인 식별 정보(PII)를 포함한 사용자에 대한 컨텍스트 정보가 포함될 수 있습니다. 따라서 감사 로그 내용은 민감한 것으로 간주되어야 하며 필요한 보안 자격을 갖춘 사람만이 볼 수 있어야 합니다.

감사 로그는 일반적으로 고객이 소유한 보안 모니터링을 위한 목적별 시스템("보안 정보 및 이벤트 관리" 또는 SIEM 솔루션)으로 소비됩니다.

이 가이드는 두 섹션에서 감사 로그를 추출하고 사용하는 과정을 설명합니다:

• 감사 전달: 하위 SIEM 또는 사용자가 감사 로그를 소비하는 방법.
• 감사 스키마: Foundry 감사 로그의 내용.

감사 전달

감사 로그는 고객의 보안 인프라 및 SIEM 요구 사항에 따라 여러 메커니즘을 통해 하위 소비를 위해 전달됩니다. Foundry 서비스에서 생성된 감사 로그 배치는 컴파일, 압축되어 24시간 이내에 로그 버킷(종종 S3, 환경에 따라 다름)으로 이동됩니다. 여기에서 Foundry는 Audit Export To Foundry를 통해 고객에게 로그를 직접 전달할 수 있습니다.

Foundry로의 감사 내보내기

감사 로그는 조직별로 직접 Foundry 데이터셋으로 내보낼 수 있습니다. 구성 설정의 일부로, 조직 관리자는 Foundry 파일 시스템 내에서 이 감사 로그 데이터셋이 생성될 위치를 선택합니다.

로그 데이터가 데이터셋에 도착하면, 고객은 Foundry의 Data Connection 애플리케이션을 통해 외부 SIEM으로 감사 데이터를 내보낼 수 있습니다.

내보내기 권한

감사 로그를 내보내려면 사용자는 대상 그룹에 대해 audit-export:orchestrate-v2 작업이 필요합니다. 이는 Organization permissions 탭의 Control Panel에서 Organization administrator 역할을 통해 부여할 수 있습니다. 자세한 내용은 Organization Permissions를 참조하세요.

내보내기 설정

Foundry로의 감사 내보내기를 설정하려면:

1. Foundry Control Panel로 이동합니다.
2. 왼쪽 사이드바에서 드롭다운 메뉴를 통해 관련 그룹을 선택합니다.
3. 왼쪽 사이드바에서 Organization Settings 아래의 Audit Logs를 선택합니다.
4. 감사 로그 데이터셋을 생성하려면 Create dataset을 선택합니다. 이 데이터셋의 위치를 Foundry에서 선택합니다. 기본적으로 감사 로그 데이터셋은 위에서 선택한 그룹으로 표시됩니다. Organization Markings를 참조하세요.
5. 선택적으로, 주어진 날짜 이후에 발생한 이벤트로 이 데이터셋을 제한하기 위해 시작 날짜 필터를 구성합니다.
6. 선택적으로, 이 내보내기 데이터셋에서 로그가 유지되는 시간을 제한하기 위해 보존 정책을 구성합니다. 보존 정책은 로그가 내보내기 데이터셋에 추가된 트랜잭션 타임스탬프를 기준으로 하며, 로그 항목 자체의 타임스탬프가 아닙니다. relevant transactions을 삭제하는 데는 삭제로 표시된 후 최대 7일이 걸릴 수 있습니다. 다음은 실제로 작동하는 방식에 대한 두 가지 예입니다:
   • 예시 1:
     • 시작 날짜: 1년 전
     • 보존 정책: 90일
     • 이 경우, 내보내기 데이터셋은 처음에는 지난 1년간의 로그를 포함합니다. 데이터셋 생성 후 90일이 지나면 보존 정책이 적용되어 마지막 90일 동안 추가된 로그만 유지되며, 처음에 데이터셋에 있던 전체 1년은 유지되지 않습니다. 실제로는 90일 후에 오래된 로그가 제거되면서 데이터셋의 크기가 크게 감소합니다.
   • 예시 2:
     • 시작 날짜: 30일 전
     • 보존 정책: 90일
     • 이 시나리오에서는 내보내기 데이터셋이 지난 30일간의 로그로 시작합니다. 새로운 로그가 추가됨에 따라 데이터셋은 최근 90일간의 데이터를 보유하는 롤링 윈도우로 성장합니다. 90일보다 오래된 트랜잭션에 추가된 로그는 보존 정책에 따라 제거됩니다.

더 큰 스택의 경우, 첫 몇 시간 동안의 빌드는 빈 추가 트랜잭션을 생성할 수 있습니다. 이는 파이프라인이 감사 로그의 백로그를 처리하면서 예상되는 동작입니다.

내보내기 비활성화

내보내기를 비활성화하려면 감사 로그 데이터셋을 휴지통이나 다른 프로젝트로 이동하세요.

감사 로그 업데이트

빌드 시, 감사 로그 데이터셋은 새로운 로그가 제공될 때 추가할 특정 조건 집합을 따릅니다(변경 가능):

• 감사 로그가 로그 버킷에 제공되면, 일반적으로 24시간 이내에, 가져오기가 매 2시간마다 실행되어 해당 로그를 내보내기 데이터셋 상류의 숨겨진 중간 데이터셋에 배치합니다.
• 새로운 로그는 매 10분마다 중간 데이터셋에서 내보내기 데이터셋으로 추가됩니다. 각 추가는 최대 10GB의 로그 데이터를 가져옵니다. 감사 로그 데이터셋이 처음 생성될 때 10GB의 로그 데이터를 추가하는 경우가 일반적입니다.
• 새로운 로그 데이터가 없으면, 내보내기 데이터셋의 일정이 1시간 동안 일시 중지된 후 다시 시작됩니다.
• 대부분의 경우, 감사 로그 데이터셋이 완전히 최신 상태가 되면 작업은 매 시간마다 계속 실행됩니다. 일반적으로 세 작업 중 하나는 감사 로그 데이터셋에 새 데이터를 추가하며, 나머지는 추가 콘텐츠 없이 중단됩니다.
• 각 감사 로그 추가의 실행 시간은 감사 로그 데이터셋에 추가되는 새로운 로그의 양에 직접 비례합니다.
• 내보내기 데이터셋의 빌드를 제어하는 일정은 audit-export에 의해 제어되며 사용자에게는 보이지 않습니다.

감사 로그 데이터셋 분석

감사 로그 데이터셋은 매우 많은 양의 데이터를 포함할 수 있으므로, 집계나 시각화를 수행하기 전에 time 열을 사용하여 이 데이터셋을 필터링할 것을 권장합니다. 필터링을 위해, 감사 데이터셋은 Contour에서 필터링하지 않고는 효과적으로 분석하기에 너무 클 수 있으므로 Pipeline Builder나 Transforms를 사용하는 것이 좋습니다.

감사 스키마

Palantir 제품이 생성하는 모든 로그는 구조화된 로그입니다. 이는 특정 스키마를 따르며, 하위 시스템에서 신뢰할 수 있음을 의미합니다.

Palantir 감사 로그는 현재 audit.2 스키마로 제공되며, 일반적으로 "Audit V2"라고도 합니다. 업데이트된 스키마인 audit.3 또는 "Audit V3"는 개발 중이지만 아직 일반적으로 사용 가능하지 않습니다.

audit.2 및 audit.3 스키마 모두에서 감사 로그는 이를 생성하는 서비스에 따라 다를 수 있습니다. 이는 각 서비스가 다른 도메인에 대해 논리적으로 설명하고 있어 설명해야 할 우려 사항이 다르기 때문입니다. 이 차이는 아래에서 설명할 audit.2에서 더 두드러집니다.

서비스별 정보는 주로 request_params 및 result_params 필드 내에 캡처됩니다. 이러한 필드의 내용은 로깅하는 서비스와 로깅되는 이벤트에 따라 모양이 변경됩니다.

감사 카테고리

감사 로그는 플랫폼에서 사용자가 수행한 모든 액션의 정제된 기록으로 생각할 수 있습니다. 이는 지나치게 상세한 로그가 더 많은 정보를 포함할 수 있지만 이해하기 어려울 수 있는 경우의 절충안입니다.

Palantir 로그에는 서비스별 지식이 거의 없이 로그를 이해하기 쉽게 하기 위한 감사 카테고리라는 개념이 포함되어 있습니다.

감사 카테고리를 사용하면 감사 로그는 감사 가능한 이벤트의 합집합으로 설명됩니다. 감사 카테고리는 data 대 metaData 대 logic과 같은 핵심 개념 집합을 기반으로 하며, 이러한 개념에 대한 액션을 설명하는 카테고리로 나뉩니다. 예를 들어, dataLoad는 시스템에서 데이터를 로드하는 것을, metaDataCreate는 데이터를 설명하는 새로운 메타데이터를 생성하는 것을, logicDelete는 시스템 내에서 두 데이터 조각 간의 변환을 설명하는 로직을 삭제하는 것을 의미합니다.

감사 카테고리는 audit.2 로그 내의 느슨한 형식에서 audit.3 로그 내의 더 엄격하고 풍부한 형식으로 버전 변경을 겪었습니다. 자세한 내용은 아래를 참조하세요.

사용 가능한 audit.2 및 audit.3 카테고리의 자세한 목록은 Audit log categories를 참조하세요.

감사 로그 귀속

감사 로그는 환경별로 단일 로그 아카이브에 작성됩니다. 감사 로그가 전달 파이프라인을 통해 처리될 때, 사용자 ID 필드(uid 및 아래 스키마의 otherUids)가 추출되고 사용자는 해당 그룹에 매핑됩니다.

주어진 오케스트레이션에 대해 조정된 감사 내보내기는 해당 그룹에 귀속된 감사 로그로 제한됩니다. 서비스(비인간) 사용자가 단독으로 수행한 액션은 일반적으로 그룹에 귀속되지 않습니다. 이러한 사용자는 그룹 구성원이 아니기 때문입니다. 단, 등록 그룹에 의해 사용되는 Client Credentials Grants를 사용하는 타사 애플리케이션의 서비스 사용자는 해당 그룹에 귀속된 감사 로그를 생성합니다.

Audit.2 로그

audit.2 로그는 요청 및 응답 파라미터의 모양에 대한 서비스 간 보장이 없습니다. 따라서 감사 로그에 대한 논리는 일반적으로 서비스별로 수행되어야 합니다.

audit.2 로그는 검색을 좁히는 데 유용한 감사 카테고리를 포함할 수 있습니다. 그러나 이 카테고리는 감사 로그의 나머지 내용을 추가로 설명하지 않으며, audit.2 로그는 감사 카테고리를 포함할 보장이 없습니다. 카테고리가 있는 경우, request_params 내의 _category 또는 _categories 필드에 포함됩니다.

audit.2 로그 내보내기 데이터셋의 스키마는 아래에 제공됩니다.

Audit.3 로그

audit.3 로그는 로그 내용에 대한 이해를 위해 특정 서비스를 이해할 필요성을 줄이기 위해 감사 카테고리의 엄격한 사용을 설정합니다. audit.3 로그는 다음 보장을 염두에 두고 생성됩니다:

1. 모든 감사 카테고리는 적용되는 값/항목을 명시적으로 정의합니다 - 예를 들어, dataLoad는 로드된 리소스를 정확히 설명합니다.
2. 모든 로그는 감사 카테고리의 합집합으로 엄격하게 생성됩니다. 이는 로그가 자유 형식 데이터를 포함하지 않음을 의미합니다.
3. 감사 로그 내의 중요한 정보는 audit.3 스키마의 최상위 수준으로 승격됩니다. 예를 들어, 모든 명명된 리소스는 최상위 수준뿐만 아니라 요청 및 응답 파라미터 내에도 존재합니다.

이러한 보장은 특정 로그에 대해 (1) 어떤 감사 가능한 이벤트가 그것을 생성했는지와 (2) 정확히 어떤 필드를 포함하는지를 알 수 있음을 의미합니다. 이러한 보장은 서비스에 구애받지 않습니다.

audit.3 스키마는 아래에 제공됩니다. 이 정보는 포괄적이지 않으며 변경될 수 있습니다: