Claude Platform Docs
관리Security posture

Security posture 이벤트를 SIEM으로 전송하기

Compliance API Activity Feed에서 Security posture 활동을 요청하고, 그중 하나를 필드별로 읽은 다음, 늦게 도착하는 활동까지 포착하는 예약 조회로 SIEM을 최신 상태로 유지합니다.

이 페이지에서는 Compliance Access Key를 준비하는 단계부터 Security posture 활동이 “security information and event management”(보안 정보 및 이벤트 관리), 즉 SIEM 시스템에 이벤트로 정해진 일정에 따라 도착하는 단계까지 안내합니다. 개요에서 어떤 조직에 이러한 활동이 있는지 설명합니다. 해당 조직을 포함하고 read:compliance_activities 또는 read:org_audit 범위를 가진 Compliance Access Key가 필요합니다.

활동 요청하기

이러한 활동만 읽으려면 activity_types[]로 피드를 필터링하세요. 이 요청에서 created_at.gte는 읽을 가장 이른 created_at을 설정하고, order=asc는 가장 오래된 활동부터 반환합니다.

cURL
curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  -H "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  -H "anthropic-version: 2026-10-21" \
  --data-urlencode "activity_types[]=org_security_control_attestation_updated" \
  --data-urlencode "created_at.gte=2026-10-20T00:00:00Z" \
  --data-urlencode "order=asc" \
  --data-urlencode "limit=5000"

API 참조API 참조 링크가 포함된 미리보기 사용 가능 — 카드에 포커스가 들어올 때까지 Tab을 누르고, 돌아가려면 Escape를 누르세요.에서 각 매개변수를 설명합니다.

활동 하나 읽기

응답의 data 배열에 있는 각 요소는 다음과 같은 활동입니다.

{
  "id": "activity_01Hq7ZtYc4Vb2NmKx8RsPd3W",
  "type": "org_security_control_attestation_updated",
  "created_at": "2026-10-20T15:04:00.220114Z",
  "organization_id": "org_01JuY4bkwkH1x4PodBJaWmh2",
  "organization_uuid": "91012d09-e48b-438e-a489-1bebfd8fa6f9",
  "actor": {
    "type": "user_actor",
    "email_address": "jane.doe@example.com",
    "user_id": "user_01WxYzAbCdEfGhJkMnPqRsTu",
    "ip_address": "192.0.2.34",
    "user_agent": "Mozilla/5.0..."
  },
  "control": "directory_sync_enabled",
  "action": "attested",
  "status": "accepted_risk"
}
  • control은 하나의 권장 설정 또는 관행인 보안 통제를 지정합니다.
  • action은 해당 통제에 대해 한 사람이 기록한 진술인 통제의 진술(attestation)에 어떤 일이 일어났는지 나타냅니다. 여기서 attested는 진술이 없던 통제에 대해 진술이 기록되었음을 의미합니다.
  • status는 진술의 값입니다. 여기서는 위험 수용(accepted_risk)입니다. 즉, 해당 통제가 적용되어 있지 않으며 조직이 그 위험을 수용합니다.
  • 여기서 actor는 진술한 사람을 사용자 ID와 이메일 주소로 식별합니다.
  • 여기서 created_at은 그 사람이 진술한 시점입니다.

Security posture 이벤트 참조에 더 많은 필드와 값이 나열되어 있습니다.

응답이 비어 있는 경우

빈 data 배열도 유효합니다. 피드에는 해당 조직에 대해 이러한 활동을 기록하기 시작한 이후에 이루어진 변경 사항만 포함됩니다. 진술이 생성되거나 변경될 때까지는 피드가 비어 있습니다.

조직에 이러한 활동이 있는지 확인하세요. 그런 다음 누군가에게 통제에 대해 진술하도록 하세요. 잠시 후 요청을 다시 보내세요.

일정에 따라 실행하기

이러한 활동 중 어느 활동이든 Activity Feed의 일반적인 1분 인덱싱 지연보다 늦게, 이미 과거인 created_at을 가진 채 조회 가능해질 수 있습니다. 따라서 커서나 계속 앞으로 이동하는 created_at.gte를 사용해 앞으로만 진행하는 통합은 이러한 활동을 절대 확인하지 못합니다. 매 실행마다 4시간의 고정된 조회 기간을 다시 읽고, 이미 저장한 활동은 제외하세요.

query = activity_types[]=org_security_control_attestation_updated
      & created_at.gte={now - 4 hours}
      & order=asc
      & limit=5000
cursor = null
loop:
  if cursor is null:
    page = GET /v1/compliance/activities?{query}
  else:
    page = GET /v1/compliance/activities?{query}&after_id={cursor}
  for activity in page.data:
    if activity.id is not in stored_ids:
      store(activity)
      add activity.id to stored_ids
  if not page.has_more: break
  cursor = page.last_id
  • 자주 실행: 경보에 필요한 만큼 자주, 예를 들어 5분마다 루프를 실행하세요.
  • 실행 전체에서 동일한 쿼리 유지: 각 실행을 시작할 때 created_at.gte를 UTC 기준으로 URL 인코딩하여 계산하세요. 모든 페이지에서 동일한 필터와 order를 보내세요. order=asc를 사용하면 last_id를 after_id로 전달할 때 더 나중의 활동으로 구성된 다음 페이지가 반환됩니다. after_id와 last_id는 결과 페이지네이션에서 설명합니다.
  • id 기준으로 중복 제거: 연속된 실행이 서로 겹치므로 이 단계는 필수입니다.
  • 실패한 실행 처리: Compliance API 오류 처리에 따른 재시도 후에도 요청이 실패하면 해당 실행을 종료하세요. 다음 실행에서 전체 기간을 다시 읽습니다. 실행이 4시간보다 오래 실패하거나 중지되면 다음 일일 재조회에서 누락된 활동을 읽습니다.

하루에 한 번 15일 재조회하기

하루에 한 번, 4시간 대신 15일의 조회 기간으로 동일한 루프를 실행하세요. 이 일일 재조회는 created_at으로부터 최대 14일 후에 조회 가능해지는 활동도 읽습니다.

  • 완료된 각 일일 재조회의 시작 시각을 기록하세요.
  • 저장된 id는 가장 최근에 기록된 시작 시각보다 16일보다 더 이전에 저장한 경우에만 삭제하세요.
  • 기록된 시작 시각이 없다면 created_at.gte를 필요한 만큼 이전으로 설정하세요. 피드는 활동을 6년 동안 보관합니다.
  • 가장 최근에 기록된 시작 시각으로부터 하루보다 더 많은 시간이 지났다면, 다음 일일 재조회를 created_at.gte를 그 시작 시각의 15일 전으로 설정하여 실행하세요.

이미 전체 피드를 수집하고 있는 경우

이러한 활동을 제외하는 activity_types[] 필터 없이 Activity Feed 전체를 읽는 통합은 이미 이러한 활동을 수신하고 있습니다. 다음 두 가지를 확인하세요.

작동 확인하기

누군가 통제에 대해 진술한 후, 루프가 새 활동을 저장할 때까지 루프를 실행하세요. 그런 다음 다시 한 번 실행하세요. 이때는 그 활동을 또다시 저장하지 않습니다.

다음 단계

활동의 created_at이 아니라 활동을 저장한 시각을 기준으로 경보를 발생시키려면 Security posture 변경 사항 감지하기를 참조하세요. “Open Cybersecurity Schema Framework”(개방형 사이버 보안 스키마 프레임워크), 즉 OCSF에 대해서는 Security posture 이벤트를 OCSF에 매핑하기를 참조하세요. 현재 결과에 대해서는 Security posture 결과 참조를 참조하세요.

이 페이지가 도움이 되었나요?