감사(Auditing)

lakeFS Team 및 lakeFS Enterprise에서 제공되는 기능이에요. 무료 체험을 시작하거나 문의하기를 통해 연락해 보세요.

출처: 문서

본문

lakeFS 감사 로그(audit log)는 사용자 액션과 관련된 모든 정보를, 언제 누가 무엇을 했는지까지 깔끔하게 정리된 표로 확인할 수 있게 해 줘요.

여러 목적으로 활용할 수 있어요:

• 컴플라이언스 - 감사 로그로 사용자가 어떤 데이터에 접근했는지, 사용자 관리에 어떤 변경을 했는지 보여줄 수 있어요.

• 트러블슈팅 - 기반 객체 스토어에서 예상치 못한 변화가 생겼을 때(예: 큰 파일이 갑자기 수천 개의 작은 파일로 쪼개진 경우), 감사 로그로 어떤 액션이 이 변화를 일으켰는지 추적할 수 있어요.

어떤 감사 로그가 나에게 해당되나요

• lakeFS Cloud: 감사 로그는 AWS S3 Access Point를 통해 Parquet 형식으로 전달되며 Treeverse가 관리해요. 바로 아래 섹션을 참고하세요.

• lakeFS Team 및 셀프 매니지드 lakeFS Enterprise: 내장 Iceberg 시스템 테이블을 사용하거나, 감사 이벤트를 자체 로깅 파이프라인으로 수집하고 싶다면 로그 기반 방식을 사용하세요.

AWS S3에서 감사 로그 접근 설정하기

감사 로그 접근은 AWS S3 Access Point를 통해 이루어져요.

액세스 포인트와 상호작용하는 방법은 여러 가지가 있어요(AWS에서 액세스 포인트 사용하기 참고).

초기 설정 절차:

• 데이터 접근에 사용할 IAM Role ARN을 기록해 두세요. 보통 Athena 같은 도구에서 사용하는 사용자나 역할이에요.

• 고객 성공팀(customer success)에 연락해 이 ARN을 전달하세요. ARN 역할을 받으면 액세스 포인트가 생성되고 다음 정보를 응답으로 받게 돼요:

• S3 버킷 (예: arn:aws:s3:::lakefs-audit-logs-us-east-1-production)

• 액세스 포인트 S3 URI (예: s3://arn:aws:s3:us-east-1:<treeverse-id>:accesspoint/lakefs-logs-<organization>)

• 액세스 포인트 별칭(Alias). 버킷 이름이나 액세스 포인트 ARN 대신 이 별칭으로 데이터에 접근할 수 있어요. (예: lakefs-logs-<generated>-s3alias)

• 필요하다면 IAM Role 정책과 신뢰 정책(trust policy)을 업데이트하세요

2개 리전(us-east-1, us-west-2)에 lakeFS 설치 2개가 있는 경우를 위한 최소 IAM 정책 예시예요:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::lakefs-audit-logs-us-east-1-production",
                "arn:aws:s3:::lakefs-audit-logs-us-east-1-production/*",
                "arn:aws:s3:::lakefs-logs-<generated>-s3alias/*",
                "arn:aws:s3:us-east-1:<treeverse-id>:accesspoint/lakefs-logs-<organization>",
                "arn:aws:s3:us-east-1:<treeverse-id>:accesspoint/lakefs-logs-<organization>/*"
            ],
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "etl/v1/data/region=<region_a>/organization=org-<organization>/*",
                        "etl/v1/data/region=<region_b>/organization=org-<organization>/*"
                    ]
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:GetObjectVersion"
            ],
            "Resource": [
                "arn:aws:s3:::lakefs-audit-logs-us-east-1-production",
                "arn:aws:s3:::lakefs-audit-logs-us-east-1-production/etl/v1/data/region=<region_a>/organization=org-<organization>/*",
                "arn:aws:s3:::lakefs-audit-logs-us-east-1-production/etl/v1/data/region=<region_b>/organization=org-<organization>/*",
                "arn:aws:s3:::lakefs-logs-<generated>-s3alias/*",
                "arn:aws:s3:us-east-1:<treeverse-id>:accesspoint/lakefs-logs-<organization>/object/etl/v1/data/region=<region_a>/organization=org-<organization>/*",
                "arn:aws:s3:us-east-1:<treeverse-id>:accesspoint/lakefs-logs-<organization>/object/etl/v1/data/region=<region_b>/organization=org-<organization>/*"
            ]
        },
        {
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": [
                "arn:aws:kms:us-east-1:<treeverse-id>:key/<encryption-key-id>"
            ],
            "Effect": "Allow"
        }
    ]
}

계정 내 누구나 위 역할을 수임(assume)할 수 있게 해 주는 신뢰 정책 예시예요:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<YOUR_ACCOUNT_ID>:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {}
        }
    ]
}

인증은 IAM Role을 수임하는 방식으로 이루어져요:

# Assume role use AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN:
aws sts assume-role --role-arn arn:aws:iam::<your-aws-account>:role/<reader-role> --role-session-name <name>

# verify role assumed
aws sts get-caller-identity

# list objects (can be used with --recursive) with access point ARN
aws s3 ls arn:aws:s3:us-east-1:<treeverse-id>:accesspoint/lakefs-logs-<organization>/etl/v1/data/region=<region>/organization=org-<organization>/

# get object locally via s3 access point alias
aws s3api get-object --bucket lakefs-logs-<generated>-s3alias --key etl/v1/data/region=<region>/organization=org-<organization>/year=<YY>/month=<MM>/day=<DD>/hour=<HH>/<file>-snappy.parquet sample.parquet

데이터 레이아웃

Tip

IAM 정책을 만들 때는 버킷 이름이 중요하지만, 실제 데이터 접근(AWS CLI, Spark 등)에 사용되는 것은 액세스 포인트 ARN과 별칭이에요.

버킷 이름: lakefs-audit-logs-us-east-1-production

루트 프리픽스: etl/v1/data/region=<region>/organization=org-<organization-name>/

파일 경로 패턴: 모든 감사 로그 파일은 parquet 형식이고 패턴은 etl/v1/data/region=<region>/organization=org-<organization-name>/year=<YY>/month=<MM>/day=<DD>/hour=<HH>/*-snappy.parquet 이에요

경로 값

region: lakeFS 설치 리전 (예: lakeFS URL의 리전: https://..lakefscloud.io/)

organization: lakeFS URL https://<organization-name>.<region>.lakefscloud.io/ 에서 확인할 수 있어요. S3 경로의 값은 반드시 org-<organization-name> 형태로 접두사가 붙어야 해요

파티션

• year

• month

• day

• hour

예시

"Acme" 조직이 lakeFS 설치 2개를 운영하는 경우의 경로 예시예요:

# ACME in us-east-1
etl/v1/data/region=us-east-1/organization=org-acme/year=2024/month=02/day=12/hour=13/log_abc-snappy.parquet

# ACME in us-west-2
etl/v1/data/region=us-west-2/organization=org-acme/year=2024/month=02/day=12/hour=13/log_xyz-snappy.parquet

스키마

파일은 parquet 형식이라 Spark나 parquet을 읽을 수 있는 클라이언트에서 바로 접근할 수 있어요. Spark의 printSchema()로 값을 살펴볼 수 있는데, 아래는 중요 컬럼에 주석을 붙인 최신 스키마예요:

column	type	description
data_user	string	요청을 수행한 사용자의 내부 사용자 ID. 외부 IdP(예: SSO, Microsoft Entra 등)를 사용하는 경우 IdP가 표현하는 UID예요. (아래에 python으로 외부 ID 정보를 추출하는 예시가 있어요)
data_repository	string	이 요청과 관련된 리포지토리 ID. 현재는 s3_gateway 요청에만 반환돼요
data_ref	string	이 요청과 관련된 레퍼런스 ID(tag, branch, ...). 현재는 s3_gateway 요청에만 반환돼요
data_status_code	int	이 요청에 대해 반환된 HTTP 상태 코드
data_service_name	string	요청의 서비스 이름. "rest_api" 또는 "s3_gateway"예요
data_request_id	string	이 요청을 식별하는 고유 ID
data_path	string	이 요청에 사용된 HTTP 경로
data_operation_id	string	이 요청의 논리적 연산 ID. 예: list_objects, delete_repository, ...
data_method	string	요청의 HTTP 메서드
data_time	string	요청 시작 시각의 datetime, ISO 8601 형식

IdP 사용자: 감사 로그의 사용자 ID를 lakeFS 이메일로 매핑하기

각 로그의 data_user 컬럼은 해당 동작을 수행한 사용자 ID를 나타내요.

• 인증이 필요 없는 경우(예: 로그인 시도)에는 비어 있을 수 있어요.

• 사용자가 lakeFS 내부에서 생성된 API 사용자라면 그 ID가 곧 이름이기도 해요.

• data_user는 외부 IdP(예: SSO 시스템)의 ID를 담을 수 있는데, 보통 사람이 읽기 어려운 형태예요. 이 ID를 실제 사용된 lakeFS 이메일과 연결할 수 있어요. Python lakefs-sdk를 사용한 예시를 참고하세요.

import lakefs_sdk

# Configure HTTP basic authorization: basic_auth
configuration = lakefs_sdk.Configuration(
    host = "https://<org>.<region>.lakefscloud.io/api/v1",
    username = 'AKIA...',
    password = '...'
)

# Print all user email and uid in lakeFS
# the uid is equal to the user id in the audit logs.
with lakefs_sdk.ApiClient(configuration) as api_client:
    auth_api = lakefs_sdk.AuthApi(api_client)
    has_more = True
    next_offset = ''
    page_size = 100
    while has_more:
        resp = auth_api.list_users(prefix='', after=next_offset, amount=page_size)
        for u in resp.results:
            email = u.email
            uid = u.id
            print(f'Email: {email}, UID: {uid}')

        has_more = resp.pagination.has_more
        next_offset = resp.pagination.next_offset

예시: Spark를 사용하는 Glue 노트북

from awsglue.transforms import *
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job

sc = SparkContext.getOrCreate()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)

# connect to s3 access point
alias = 's3://<bucket-alias-name>'
s3_dyf = glueContext.create_dynamic_frame.from_options(
    format_options={},
    connection_type="s3",
    format="parquet",
    connection_options={
        "paths": [alias + "/etl/v1/data/region=<region>/organization=org-<org>/year=<YY>/month=<MM>/day=<DD>/hour=<HH>/"],
        "recurse": True,
    },
    transformation_ctx="sample-ctx",
)

s3_dyf.show()
s3_dyf.printSchema()

제한된 IP 대역을 위한 감사 로그 필드 마스킹(Redaction, lakeFS Cloud)

설정된 제한 IP 대역에서 온 요청에 대해서는 lakeFS가 data_repository, data_ref, data_path를 최대 max_field_length자로 줄이고 *** 접미사를 붙여요. 각 필드는 독립적으로 잘리며, 한도 이하의 값은 온전히 유지돼요. 다른 IP의 기록과 그 외 모든 필드는 변경되지 않아요.

대역 매칭은 lakeFS가 요청에 대해 식별한 클라이언트 IP를 기준으로 하며, 이는 Client IP resolution 설정에서 구성해요.

예시 (최대 필드 길이 8):

• data_repository: my-secret-repo → my-secre***

• data_ref: main → main

• data_path: /api/v1/repositories/my-secret-repo/refs/main/objects?path=secret-data.parquet → /api/v1/repositories/my-secre***/refs/main/objects?***

활성화

마스킹은 lakeFS Cloud 설치에서 Treeverse가 설정해요. [email protected] 로 연락해 아래 정보를 전달하세요:

• 제한 IP 대역: 요청을 마스킹할 CIDR 블록 또는 개별 IP.

• 최대 필드 길이: *** 붙기 전에 필드별로 유지할 문자 수. 각 마스킹 필드에 독립적으로 적용되는 단일 한도예요 (0 = 완전 마스킹).

감사 로그 Iceberg 시스템 테이블 (온프레미스)

lakeFS Enterprise는 감사 이벤트를 내장 Iceberg 테이블에 저장할 수 있고, lakeFS Iceberg REST 카탈로그를 통해 쿼리할 수 있어요. 감사 데이터를 수집·관리하기 위한 별도 외부 파이프라인이 필요 없어요.

활성화하면 lakeFS가 자동으로:

• 시스템 리포지토리(lakefssystem)와 Iceberg 테이블(system.audit_log)을 생성해요

• 모든 감사 이벤트를 캡처해요

• 이벤트를 Iceberg 감사 테이블로 플러시해요

• Iceberg 호환 쿼리 엔진(Spark, Trino, Athena 등)에서 즉시 쿼리 가능하게 만들어요

감사 로그 활성화하기

lakeFS Cloud

lakeFS Cloud 배포의 감사 로그 설정은 Treeverse가 관리해요. Iceberg 감사 로그를 활성화하려면 [email protected] 로 연락하세요.

lakeFS 설정에 다음을 추가하세요:

audit_log:
  enabled: true
  retention_days: 90        # 0 = infinite retention
  storage_namespace: s3://my-bucket/lakefssystem  # where audit data is stored
  flush:
    interval: 1m            # how often to flush buffered events
    batch_size: 100000      # flush when this many events accumulate (whichever comes first)

Note

storage_namespace는 blockstore 섹션에 설정된 것과 동일한 객체 스토어 안의 위치를 가리켜야 해요. 생략하면 lakeFS가 blockstore.default_namespace_prefix에 /lakefssystem을 붙여 자동 도출해요 (예: s3://my-bucket/lakefssystem).

접근 제어

감사 로그 접근은 일반 catalog:* 권한과 별도의 전용 audit 권한으로 관리돼요:

Action	Description	Resource ARN
audit:ReadAuditLog	감사 로그 테이블 읽기/쿼리	arn:lakefs:audit:::log
audit:WriteAuditLog	감사 로그에 쓰기(시스템 전용)	arn:lakefs:audit:::log

• 읽기 접근: AuditLogRead 정책(액션 audit:ReadAuditLog)으로 제어돼요. 새 설치에서는 이 정책이 Admins와 SuperUsers 그룹에 자동으로 붙어요. 다른 사용자나 그룹에 접근을 허용하려면 아래의 AuditLogRead 정책을 붙이면 돼요.

• 쓰기는 시스템 전용이에요. lakefssystem 리포지토리는 읽기 전용이에요. 감사 서비스 사용자(부트스트랩 시 생성)가 수집, 컴팩션, 만료를 위해 audit:* 권한을 보유해요.

• 자기 감사 제외: 재귀적 자기 감사를 막기 위해 lakefssystem 리포지토리 자체를 겨냥한 이벤트는 제외돼요.

기존 설치에서 접근 설정하기

AuditLogRead 정책이 없다면(예: 이 기능 이전에 만들어진 설치), 아래 예시로 수동 생성하고 관련 그룹에 붙이세요.

예시: AuditLogRead 정책

{
  "id": "AuditLogRead",
  "statement": [
    {
      "action": ["audit:ReadAuditLog"],
      "resource": "arn:lakefs:audit:::log",
      "effect": "allow"
    }
  ]
}

RBAC 모델에 대한 자세한 내용은 Role-Based Access Control 문서를 참고하세요.

감사 로그 쿼리하기

Iceberg 호환 쿼리 엔진을 lakeFS Iceberg REST 카탈로그에 연결하고 감사 로그 테이블을 쿼리하세요.

테이블 위치는 lakefssystem.main.system.audit_log 이며 각 부분은:

• lakefssystem — 자동 생성된 시스템 리포지토리

• main — 기본 브랜치

• system — Iceberg 네임스페이스

• audit_log — 테이블 이름

감사 로그 테이블에서 실행할 수 있는 쿼리 예시예요:

-- Recent activity by a specific user
SELECT time, user, repository, ref, operation_id, path, status_code
FROM lakefssystem.main.system.audit_log
WHERE user = 'alice'
ORDER BY time DESC
LIMIT 50;

-- Top API operations in the last 7 days
SELECT operation_id, COUNT(*) AS calls
FROM lakefssystem.main.system.audit_log
WHERE time >= CURRENT_TIMESTAMP - INTERVAL '7' DAY
GROUP BY operation_id
ORDER BY calls DESC
LIMIT 20;

-- Repository activity overview (last 24 hours)
SELECT repository, COUNT(*) AS operations
FROM lakefssystem.main.system.audit_log
WHERE time >= CURRENT_TIMESTAMP - INTERVAL '1' DAY
GROUP BY repository
ORDER BY operations DESC;

스키마

Iceberg audit_log 테이블의 스키마예요:

Column	Type	Nullable	Description
user	string	yes	인증된 사용자의 사용자명 (미인증이면 비어 있음)
repository	string	yes	리포지토리 이름 (해당 없으면 비어 있음)
ref	string	yes	브랜치, 태그 또는 커밋 레퍼런스
status_code	int32	no	HTTP 응답 상태 코드
service_name	string	no	rest_api 또는 s3_gateway
request_id	string	no	고유 요청 식별자
path	string	yes	HTTP 요청 경로
operation_id	string	no	논리적 연산 (예: ListRepositories, GetObject)
method	string	no	HTTP 메서드 (GET, POST 등)
source_ip	string	yes	클라이언트 IP 주소, Client IP resolution에 따라 식별
client	string	yes	클라이언트 식별자 (SDK 이름/버전 또는 User-Agent)
time	timestamp (UTC)	no	요청 시각
tenant	string	yes	요청이 스코프된 테넌트, 예약된 루트 테넌트는 비어 있음

테이블은 효율적인 쿼리를 위해 days(time)과 repository로 파티셔닝돼요.

여러 테넌트에 걸친 감사 기록 읽기

테넌트를 사용하는 설치는 감사 테이블을 하나만 두고(root 테넌트에 위치) 레코드마다 테넌트 이름을 기록하는 방식이에요. 리포지토리 이름은 설치 전체에서 고유하므로 repository만으로도 리포지토리를 식별할 수 있고, tenant 컬럼 덕분에 리포지토리를 전혀 지명하지 않는 요청(예: 리포지토리 목록 조회)까지 포함해 한 테넌트의 활동을 통째로 리포팅할 수 있어요.

테넌트 없는 요청의 기록은 root라고 명시하지 않고 tenant를 비워 둬요. 덕분에 이 기능을 쓰지 않는 설치에서는 컬럼 전체가 비어 있게 유지돼요. 컬럼이 생기기 전에 기록된 레코드도 빈 값으로 읽히기 때문에 둘은 구분되지 않아요.

테넌트 버킷 어드레싱을 사용하는 S3 게이트웨이 트래픽에는 한 가지 주의점이 있어요. lakeFS가 테넌트를 별도로 기록하기 시작하기 전에 기록된 레코드는 합성 버킷 이름 전체를 repository에 담았어요. 그래서 team-a--my-repo로 어드레싱된 버킷은 그 이름 그대로 나타나고, 같은 리포지토리의 이후 레코드는 my-repo와 tenant의 team-a로 분리 저장돼요. 그 업그레이드를 가로지르는 쿼리는 하나의 논리적 리포지토리에 대해 두 형태를 모두 보게 되므로 이를 처리해야 해요.

유지 관리(Maintenance)

주기적 유지 관리 작업이 작은 파일을 컴팩션하고 오래된 스냅샷을 만료시키며, 고아 파일을 정리하고 변경을 커밋해요. 두 가지 모드로 실행할 수 있어요:

• 인프로세스(기본값): lakeFS 서버에 내장된 스케줄러가 유지 관리를 자동 실행해요. audit_log.enabled가 true면 기본으로 활성화되는 가장 간단한 배포 방식이에요.

• 외부 작업: lakefs audit maintain을 여러분의 오케스트레이션 시스템(예: Kubernetes CronJob, cron, Airflow)의 예약 작업으로 실행해요. 이 모드를 쓰려면 서버 설정에서 audit_log.maintenance.enabled: false로 두어 인프로세스 스케줄러를 비활성화하세요.

Note

두 모드는 동일한 설정을 사용하고 동일한 메트릭을 내보내므로 서로 전환하기 쉬워요.

인프로세스 모드

인프로세스 스케줄러는 설정 가능한 cron 스케줄에 따라 lakeFS 서버 안에서 실행돼요. 분산 락 덕분에 멀티 레플리카 배포에서도 한 번에 한 인스턴스만 유지 관리를 수행해요.

audit_log:
  enabled: true
  maintenance:
    enabled: true              # default true, depends `audit_log.enabled` is true
    schedule: "0 * * * *"      # cron expression (default: every hour)

인프로세스 유지 관리 메트릭은 다른 lakeFS 메트릭과 함께 lakeFS 서버의 /metrics 엔드포인트로 수집돼요.

외부 작업

같은 lakeFS Enterprise 바이너리와 설정 파일로 lakefs audit maintain을 예약 작업으로 실행하세요:

lakefs audit maintain -c /etc/lakefs/config.yaml --retention-days 90

이 작업은 컴팩션, 스냅샷 만료, 고아 정리를 수행하고 변경을 커밋해요. 각 단계는 플래그로 토글할 수 있어요 (--compact, --expire-snapshots, --cleanup-orphans, --commit — 모두 기본값 true).

종료 코드:

Code	Meaning
0	모든 단계 성공 완료
1	하나 이상의 단계 실패
2	컴팩션 실패

유지 관리 상태 모니터링에는 이 종료 코드와 아래 메트릭을 활용하세요.

튜닝 플래그:

Flag	Default	Description
--retention-days	90	이보다 오래된 스냅샷 만료 (0 = 만료 없음)
--compact-min-files	3	컴팩션 트리거를 위한 최소 작은 파일 수
--compact-max-small-file-size	33554432	이보다 작은 파일(바이트)이 "작은 파일"로 간주됨 (기본 32MB)

외부 작업으로 실행할 때는 실행 후 Prometheus Pushgateway로 메트릭을 푸시할 수 있어요. 푸시 대상은 lakeFS 설정 파일의 audit_log.maintenance.metrics_push_url로 구성하고, URL이 비어 있으면 푸시하지 않아요.

Helm 차트: lakeFS Helm 차트는 auditLog.maintenance.cronJob을 true로 설정하면 Kubernetes CronJob을 배포할 수 있어요. 메인 배포와 같은 설정 파일과 라이선스 시크릿을 공유해요.

메트릭

Metric	Type	Description
audit_maintain_step_duration_seconds{step}	histogram	각 유지 관리 단계의 소요 시간
audit_maintain_step_errors_total{step}	counter	실패한 유지 관리 단계 수
audit_maintain_success_total	counter	완전히 성공한 유지 관리 실행 수
audit_compaction_chunks_total	counter	처리된 컴팩션 청크 수
audit_compaction_files_merged_total	counter	컴팩션에서 병합된 소스 파일 수
audit_compaction_bytes_merged_total	counter	컴팩션에서 병합된 바이트 수

{step} 라벨 값은 compaction, snapshot-expiration, orphan-cleanup, lakefs-commit, all-steps 이에요.

설정 세부 사항은 Enterprise Configuration Reference의 audit_log 섹션을 참고하세요.

로그 기반 감사 (온프레미스)

Iceberg 시스템 테이블을 쿼리하는 대신 이미 운영 중인 로깅/SIEM 파이프라인에 감사 이벤트를 넣고 싶다면, 로그 컬렉터로 lakeFS 컨테이너 stdout에서 감사 이벤트를 수집할 수 있어요.

수집

로그를 컨테이너 stdout(기본값)으로 보내고 로그 컬렉터로 캡처·전달하세요. log_audit이 true인 항목만 필터링하면 돼요.

대표적인 로그 컬렉터: Fluent Bit, Fluentd, Logstash.

감사 로그 항목 예시(JSON):

{
  "client": "lakefs-python-sdk/1.65.2",
  "host": "lakefs.example.com",
  "level": "info",
  "log_audit": true,
  "method": "POST",
  "msg": "HTTP call ended",
  "operation_id": "DeleteObjects",
  "path": "/api/v1/repositories/my-repo/branches/my-branch/objects/delete",
  "request_id": "1234567-5b66-7655-b4e8-2h0c271f6r90",
  "service_name": "rest_api",
  "source_ip": "80.0.0.10",
  "status_code": 200,
  "time": "2025-12-25T12:30:32Z",
  "user": "lakefs-ci-bot"
}

저장과 쿼리

수집된 감사 로그는 인프라에 따라 다양한 방식으로 저장하고 쿼리할 수 있어요. 저장소와 쿼리 엔진의 선택은 기존 인프라, 보존 요구 사항, 쿼리 패턴에 따라 달라져요.

예시: S3/Azure Blob에 저장하고 Spark로 ETL 인덱싱 후 Athena/Spark로 쿼리하거나, 실시간 분석을 위해 Elasticsearch에 저장하기.

스케일링 고려 사항

높은 규모에서는 lakeFS가 상당한 양의 감사 로그를 생성할 수 있어요. 다음을 고려하세요:

• 파티셔닝: 쿼리 성능과 스토리지 비용 관리를 위해 시간 단위(예: year/month/day/hour)로 로그를 파티셔닝하세요

• 보존 정책: 오래된 로그를 아카이브하거나 삭제할 보존 기간과 라이프사이클 규칙을 정의하세요

스키마 고려 사항

감사 로그 스키마는 안정적이고 시간이 지나며 점진적으로 확장돼요. 스키마 인식 쿼리 엔진(예: Athena, BigQuery)을 사용한다면 AWS Glue Crawler 같은 스키마 탐지 메커니즘으로 새 필드가 나타날 때 테이블 스키마를 자동 감지·갱신하는 방식을 고려하세요. 위 Schema 섹션에서 설명한 필드들(온프레미스에서는 data_ 접두사를 제거)이 모든 감사 로그 항목에 존재할 것으로 기대돼요.

더 알아보기 (Learn more)

공식 문서의 감사(Auditing) 페이지는 https://docs.lakefs.io/admin/auditing 에서 확인할 수 있어요.