로그 내보내기와 플랫폼 내 접근 설정
Foundry의 애플리케이션 로그는 함수 실행, 변환과 파이프라인 실행, 빌드와 배포, 시스템 오류 및 경고를 기록합니다. Code Repositories에서 사용자가 추가한 로그도 포함됩니다.
| 관리 대상 | 목적 |
|---|---|
| 로그 내보내기 | 조직의 로그를 Foundry 스트리밍 데이터셋으로 전달하여 분석하거나 외부 모니터링 시스템에 연결 |
| 플랫폼 내 로그 접근 | Workflow Lineage에서 Ontology와 AIP 실행의 추적 기록 및 서비스 로그를 읽을 수 있는 범위 설정 |
내보낸 데이터셋의 접근 권한과 플랫폼 내 실행 로그의 조회 권한은 별도로 설정합니다.
로그 내보내기는 베타 기능입니다. 인스턴스에 제공되지 않을 수 있고 개발 중 동작이 바뀔 수 있습니다. 가용성은 Palantir 지원팀에 확인합니다.
관리 화면 열기
- Control Panel을 엽니다.
- 위쪽 배너에서 해당 조직을 선택합니다.
- Organization → Log observability settings로 이동합니다. Control Panel 첫 화면에서 같은 이름을 검색할 수도 있습니다.
로그 내보내기의 권한과 목적
내보내기 구성을 관리하려면 조직 관리자(Organization administrator) 역할이 필요합니다. 구성은 조직 단위로 관리합니다.
내보내기를 만들기 전에 다음을 정해야 합니다.
- 모니터링 목적과 수집할 프로젝트 범위
- 사용자 식별자가 실제로 필요한지 여부
- 보존 기간
- 결과 데이터셋에 접근할 사용자와 필요한 보안 표지
운영이나 보안 분석을 위한 로그에도 사용자 활동과 민감한 애플리케이션 데이터가 들어갈 수 있습니다. 데이터셋에 표지를 적용하여 접근을 제한하고, 목적에 필요한 범위만 수집합니다.
내보내기 대상과 조직 표지 조건
내보내기는 실행 시작 리소스(Source executor)를 기준으로 구성합니다. 선택한 프로젝트에 있는 함수, 액션, 자동화 등의 실행 시작 리소스가 범위에 포함되는지와 다음 조건을 확인합니다.
- 내보내기 데이터셋에는 조직 표지가 하나 이상 있어야 합니다.
- 내보내기 데이터셋의 모든 조직 표지는 실행 시작 리소스에도 있어야 합니다. 데이터셋은 생성 위치의 조직 표지를 상속하므로 위치 선택에 주의합니다.
- 액션은 프로젝트 기반 권한을 사용해야 합니다. 기존 온톨로지 권한으로 관리되는 액션은 먼저 프로젝트 기반 권한으로 이전해야 내보내기에 포함할 수 있습니다.
가상의 실행 시작 리소스에 조직 A, B가 지정되어 있다고 가정하면:
| 내보내기 데이터셋의 조직 표지 | 내보내기 가능 여부 |
|---|---|
A | 가능 |
A, B | 가능 |
A, C | 불가. 실행 시작 리소스에 C가 없음 |
| 없음 | 불가. 조직 표지가 최소 하나 필요 |
구성 수와 프로젝트 범위 제한
| 항목 | 한도 |
|---|---|
| 조직당 내보내기 구성 | 최대 50개 |
| 프로젝트 하나가 포함될 수 있는 내보내기 구성 | 최대 3개 |
| 프로젝트를 직접 선택하는 구성 하나의 프로젝트 수 | 최대 100개 |
조직의 모든 프로젝트를 대상으로 한 구성도 프로젝트별 3개 한도에 포함됩니다. 가능하면 특정 프로젝트를 선택하는 편이 결과 데이터셋의 접근 범위를 관리하기 쉽습니다.
내보내기 만들기
1. 구성 시작
Create log export를 선택합니다.
2. 프로젝트 선택
로그를 내보낼 프로젝트를 고릅니다. 공간(Space)으로 목록을 제한하거나 프로젝트 이름을 검색할 수 있습니다. 이미 다른 구성에 포함된 프로젝트에는 내보내기 구성 수가 표시됩니다.
3. 데이터셋 이름과 위치 지정
로그를 받을 스트리밍 데이터셋의 이름과 위치를 지정합니다. Foundry 파일시스템의 지원 위치를 사용해야 하며, 사용자가 만든 일반 폴더를 내보내기 위치로 사용할 수는 없습니다. 생성 위치에서 상속할 조직 표지도 확인합니다.
4. 스키마와 사용자 ID 처리 선택
다음 중 로그 형식을 선택합니다.
| 형식 | 페이로드 |
|---|---|
| Palantir 내부 형식 | 직렬화한 JSON 문자열 |
| OpenTelemetry(OTel) 프로토콜 형식 | 프로토콜 버퍼 바이너리. 이후 OTel 수집기로 전달하는 데 사용 가능 |
같은 단계의 Unredact user IDs로 사용자 ID의 가림 처리를 제어합니다. 기본값은 사용자 ID를 가리는 것입니다. 로그 본문에는 다른 민감한 정보가 남을 수 있으므로 데이터셋의 접근 권한도 설정해야 합니다.
5. 보안 표지 적용
Apply markings에서 결과 스트리밍 데이터셋에 붙일 보안 표지를 선택합니다. 이 단계는 선택 사항이지만 민감한 로그의 접근 통제를 위해 권장됩니다. 선택한 표지는 내보내기 구성이 생성된 뒤 데이터셋에 적용됩니다. 이후 데이터셋에 직접 표지를 추가할 수도 있습니다.
6. 검토와 생성
선택한 프로젝트, 저장 위치, 스키마, 표지와 접근 요건을 확인하고 Create configuration을 선택합니다. 생성한 구성과 적용한 표지는 목록에 표시됩니다.
로그는 구성을 생성한 시점부터 지속적으로 데이터셋에 기록됩니다. 처음 구성할 때 데이터가 들어오기까지 최대 5분이 걸릴 수 있습니다. 과거 로그 전체의 소급 복사는 지원하지 않습니다.
내보내기 중단
구성 목록 오른쪽의 휴지통 아이콘으로 내보내기 구성을 삭제하면 새 로그 전달이 멈춥니다. 이미 생성된 데이터셋은 계속 존재합니다.
대상 스트리밍 데이터셋을 휴지통으로 보내거나 영구 삭제해도 로그 내보내기는 멈춥니다. 이 동작은 아래의 플랫폼 내 로그 이력 삭제와 다른 작업입니다.
로그 분석과 보장 범위
내보낸 로그는 양이 많을 수 있으므로 시간 범위 등으로 먼저 필터링합니다. Transforms나 Pipeline Builder로 분석하거나 다른 모니터링 시스템에 전달할 수 있습니다.
로그에는 실행 상세, 오류, 성능 관련 구조화 필드가 들어가며, 구체적인 구조는 로그를 생성한 애플리케이션이나 서비스에 따라 달라집니다. 로그를 만든 리소스의 RID로 해당 리소스를 추적할 수 있습니다. 조직별 내보내기는 그 조직의 맥락에서 발생한 로그로 제한됩니다.
이 로그는 감사 로그(Audit logs)가 아니며, 100% 신뢰성 있는 전달을 보장하지 않습니다. Foundry가 생성하는 로그 내용은 사전 통지 없이 변경될 수 있습니다.
플랫폼 내 로그 접근
플랫폼 내 접근 제어는 활성화된 프로젝트에서 호출하는 함수, 액션, 자동화와 언어 모델의 실행 로그에 적용합니다. 기본적으로 조직의 모든 프로젝트에서 로그 접근이 비활성화되어 있습니다.
원래 리소스나 실행 중 접근한 데이터의 보안 표지는 로그에 자동 전파되지 않습니다. 프롬프트와 응답, 객체 속성값과 사용자 입력이 로그에 들어갈 수 있으므로, 접근을 활성화할 때 워크플로가 접할 수 있는 가장 민감한 데이터에 맞게 표지를 직접 지정합니다.
공유 실행 로그를 보려면 다음을 모두 충족해야 합니다.
- 실행 시작 리소스의 프로젝트 또는 리소스 수준 재정의에서 로그 읽기가 활성화됨
- 적용된 모든 로그 보안 표지에 접근할 수 있음
- 실행 시작 리소스에
foundry-telemetry-service:view-execution-history작업 권한이 있음. 기본Editor역할이 부여하며 사용자 지정 역할로도 부여 가능
리소스가 이동했다면 로그 귀속 프로젝트의 조건도 확인해야 합니다. 역할과 예외의 전체 기준은 로그 권한에 설명되어 있습니다.
일반적인 플랫폼 내 공유 로그 조회는 30일 보존 범위를 사용합니다. 일반 인스턴스에서는 필요한 작업 권한을 가진 사용자가 공유 설정과 관계없이 본인의 최근 24시간 실행 로그를 볼 수 있지만, 보안 분류 기반 접근 제어(CBAC) 인스턴스에는 이 예외가 없습니다.
Control Panel에서 프로젝트 접근 설정
조직 전체의 프로젝트 설정을 보려면 기본적으로 Organization administrator 역할이 필요합니다. 프로젝트의 설정을 바꾸려면 그 프로젝트의 Edit 권한과 Information security officer 또는 Enrollment administrator 역할도 필요합니다.
- Log access 탭을 엽니다. 현재 로그 읽기가 활성화된 프로젝트가 표시됩니다.
- Add project를 선택합니다.
- 프로젝트를 고른 뒤 로그 읽기를 활성화하고 필요한 표지를 적용합니다.
- 적용한 프로젝트가 활성화 목록에 나타나는지 확인합니다.
- 해당 프로젝트에 있는 실행 시작 리소스에 적용된 정책을 확인합니다.
Workflow Lineage에서 정책 검토와 변경
리소스의 Log access overview를 열고 Log access policy → Edit를 선택합니다. 프로젝트 수준 설정을 사용하려면 Configure in Control Panel로 이동합니다.
| 항목 | 의미와 상태 |
|---|---|
| Current project | 현재 리소스가 있는 프로젝트. Enabled 또는 Not configured |
| Attributed project | 로그 귀속 프로젝트. 현재 프로젝트와 다를 때 표시. Enabled 또는 Not configured |
| Resource override | 리소스 수준 재정의. 활성 재정의가 있거나 프로젝트에서 접근이 비활성화되면 표시. Enabled, Disabled, Not configured |
로그 귀속 프로젝트 갱신
로그 귀속 프로젝트(Attributed project)의 기본값은 리소스가 처음 로그를 남길 때 위치했던 프로젝트입니다. 그 뒤 이동하면 현재 프로젝트와 로그 귀속 프로젝트가 달라지고 두 프로젝트의 조건이 적용됩니다.
관리자는 이전 프로젝트의 상태 태그에 마우스를 올리고 Clear and inherit를 선택하여 귀속을 현재 프로젝트로 재지정할 수 있습니다.
기존 온톨로지 권한 액션의 재정의
기존 온톨로지 권한을 사용하는 액션은 프로젝트 기반 권한으로 이전해야 프로젝트 단위로 관리할 수 있습니다. 이전하기 전에는 다음 중 하나를 선택합니다.
- 권장 방식: 액션을 프로젝트 기반 권한으로 이전
- 임시 운영 방식: 리소스 수준 재정의로 로그 접근을 활성화
기존 권한의 액션에는 프로젝트 대신 Ontology 리소스 식별자가 표시됩니다. 이를 일반 프로젝트처럼 활성화하거나 Foundry 파일시스템에서 접근할 수는 없습니다. 프로젝트로 이전한 뒤에는 관리자가 기존 Ontology 식별자의 귀속을 해제하여 갱신합니다.
재정의를 활성화할 때는 사용자가 로그를 읽기 위해 가져야 할 Required markings를 지정합니다. 이 표지는 기존 리소스 및 프로젝트의 로그 설정에 있는 표지에 추가됩니다. 실행이 읽은 객체나 데이터의 표지는 자동으로 전파되지 않습니다.
비활성화된 리소스 재정의 방식은 더 이상 사용하지 않습니다. 표에 Disabled 재정의가 있으면 제거하고 프로젝트 정책을 사용해야 합니다. 제거하기 전에는 Next로 진행할 수 없습니다.
변경 확인
정책을 구성하고 Next를 선택하면 보안상 영향을 확인하는 단계가 나옵니다.
- 재정의를 활성화할 때는 민감한 객체 데이터가 기록될 수 있고 올바른 표지를 적용했음을 확인합니다.
- 재정의를 해제할 때는 리소스가 프로젝트 수준의 로그 공개 범위로 돌아감을 확인합니다.
확인란을 선택한 뒤 Apply Changes로 저장합니다.
로그 이력 영구 삭제
Information security officer 또는 Enrollment administrator는 Workflow Lineage의 Run history나 Log search에서 Edit permissions → Delete log history → Delete logs로 삭제할 수 있습니다.
대상 리소스에서 시작된 실행의 모든 로그를 영구 삭제하며, 되돌릴 수 없습니다. 목록에 적용한 필터는 삭제 범위를 제한하지 않습니다. 삭제 대상과 영향을 확인한 뒤 진행해야 합니다.