integrations.microsoft_sentinel_auditlogs — version 1.0

Source: presets/integrations/microsoft-sentinel-auditlogs.satz

Purpose

The organisation's audit logs, on their way to Microsoft Sentinel.

NEEDS presets/integrations/microsoft-sentinel.satz: the connector authenticates through the federation that file creates and reads as the account it creates. Used without it, the compile stops with unknown param 'sentinel_project_id'.

FOUR RESOURCES, AND EACH ONE IS LOAD-BEARING: an organisation sink that exports the four audit log streams with include_children, so every project is covered and a project created tomorrow is covered too; the topic it writes to; the subscription Sentinel pulls from; and two grants — roles/pubsub.publisher for the sink's own writer identity, without which the sink exists and delivers nothing, and roles/pubsub.subscriber for the Sentinel account on that one subscription.

TIGHTER THAN UPSTREAM ON PURPOSE. Microsoft's published configuration grants a project-level custom role carrying pubsub.subscriptions.consume and .get, which reaches every subscription in the project, including ones this estate did not make. The predefined roles/pubsub.subscriber on this subscription alone is the same access where it is needed and none where it is not.

THE FILTER IS OR-ONLY. Cloud Logging charges a sink nothing for what it exports, but an AND, a NOT or a != in an organisation sink's filter narrows it per project in ways that are hard to read back; the audit streams are named as four alternatives, exactly as the archive sink names them. Data access logs are in the list and are the loud half of the volume — Sentinel's own ingestion is charged by the gigabyte, so an estate that does not want them drops that one log_id.

ONE SOURCE, NOT ALL OF THEM. Microsoft publishes a configuration per log source — VPC flow, firewall, DNS, GKE, Cloud SQL, Compute, IAM, Resource Manager and the rest — each its own topic, subscription and sink. This is the audit-log one, which every customer starts with. Another source is this file with its own names and filter; copy it rather than widening this sink, because a sink is replaced when its filter changes and the replacement drops what was in flight.

NO CLAIM. Exporting audit logs to a SIEM does not satisfy a retention control: monitoring/organization-audit-logsink.satz is what claims those, and this sink is a copy leaving the organisation, not the archive.

Use it

params {
  // the pack's own defaults — copy only the lines you change
  sentinel_auditlogs_topic = "sentinel-topic"
  sentinel_auditlogs_subscription = "sentinel-subscription-auditlogs"
  sentinel_auditlogs_sink_name = "audit-logs-organization-sentinel-sink"
  sentinel_auditlogs_filter = "log_id("cloudaudit.googleapis.com/activity") OR log_id("cloudaudit.googleapis.com/data_access") OR log_id("cloudaudit.googleapis.com/system_event") OR log_id("cloudaudit.googleapis.com/policy")"
  sentinel_auditlogs_retention = "604800s"
  sentinel_auditlogs_ack_deadline_seconds = 60
}

use "presets/integrations/microsoft-sentinel-auditlogs.satz"

Needs from outside the pack:

• customer_organization_id — declared by estate_core; use one of them alongside, or declare it in the estate.
• sentinel_project_id — declared by integrations.microsoft_sentinel; use one of them alongside, or declare it in the estate.

Params

Questions

What to ask before this pack is configured, and what changing the answer costs.

sentinel_auditlogs_filter — Data Access logs are most of the volume, and Sentinel is charged by the gigabyte ingested: leaving them in buys full visibility of who read what, taking them out cuts the bill and the answer to that question with it. The organisation's own archive keeps whatever this sink drops. Widening it later replaces the sink, and what was in flight at that moment is not re-sent.

Contributes

Claims

None — this pack proves no control by itself.

History

The whole library's history: the changelog in presets/CHANGELOG.md.

Notes

No notes yet.