Sonador Access Log: Observable Accountability for Medical Data
An audit begins with questions that sound almost too simple. Who retrieved this resource? What decision was made when they asked? Was access permitted? And if it was denied, what happened next? A platform that cannot answer them is not necessarily insecure, but it cannot demonstrate that it is secure, and in healthcare the demonstration is part of the obligation. Trust, in a regulated environment, is something you verify after the fact.
The regulatory language is explicit. HIPAA's Security Rule (45 CFR 164.312(b), the audit-controls standard) calls for mechanisms that record and examine activity in information systems that contain or use electronic protected health information. And as the ACL article in this series observed, the requirement is not an American peculiarity: GDPR, Australia's Privacy Principles, and Ontario's health-privacy legislation converge on the same expectation, making audit capability the common denominator of health-data regulation across jurisdictions.
Sonador 0.4.1 ships its answer: an opt-in Access Log that records access, identity, policy, and credential events as FHIR R4B AuditEvents and publishes them, over secure Kafka, to whatever analysis and retention tools the organization already operates. It is disabled by default. Turning it on is a deliberate deployment decision, and this article covers what you get when you make it.
This piece is part of Sonador's ongoing security series, and it completes an arc: identity established who a user is, authorization decided what they may do, and this article is about the record of how the platform behaves (what data is accessed and what decisions were made in compliance to the policies which are intended to protect patient privacy).
Access Logs Have a Day Job
It would be a mistake to file the Access Log under compliance and stop there. The questions that open this article are framed as an auditor's, and an auditor may ask them once a year. An operations team asks them on an ordinary Tuesday: when a clinician swears they never opened a study or when a pipeline halts and nobody knows whose credential expired. A record built to satisfy the annual examination turns out to be the working instrument of everyone defending the system the other 364 days.
And most of what it illuminates is innocent, and that is the point. The value of a consistent record is not that every entry is an alarm; it is that ordinary explanations become fast to confirm, allowing for genuine exceptions to stand out.
Signals Worth a Closer Look
A request is denied. Usually that is the system working (a resident clicked a study outside their group). But a pattern of denials against one patient's record, from one account, at odd hours, is a probe, and the difference between the two is visible only in a record that includes denials at all. Repeated failed sign-ins tell a similar story: one is a mistyped password; forty across ten accounts may be an attack in progress. An ACL grant nobody remembers making (a policy change that widened access to a group of studies) deserves a name, a timestamp, and a before-and-after. And an API credential created outside any planned integration is either an engineer moving fast or an attacker setting up long-term access. The people operating the platform need to be able to determine what is happening, and quickly.
The investigative rhythm is identical in every case: pull the events for the account or the resource, read them in order, and let the record settle the question. Without a log, each of these moments becomes a meeting: recollections, guesses, and a decision asserted on confidence rather than evidence.
Most irregularities have ordinary explanations; consistent records help teams resolve them quickly and recognize the activity that warrants follow-up. An access log is not primarily an alarm system, it is the shared memory that lets a team close questions with confidence. It clears normal activity as much as it catches abnormal activity and clearing people is the more common job.
Anatomy of an Access Event
Every record the Access Log produces answers the same five questions.
- WHEN: the event is recorded as it happened, with the timestamp of the decision itself
- WHO: the agent; the person or service that acted, the application responsible for the request, and the network address it arrived from.
- ACTION: what they did; read, create, or modify
- WHAT: the entity; a typed identifier for the study or object involved.
- OUTCOME: whether the operation was permitted or denied. Denials get equal treatment: a refused request produces just as complete a record as a granted one.
Sonador publishes its access as FHIR R4B Audit Events, the audit vocabulary of the FHIR standard. FHIR is the data standard that most modern health systems already speak, and the choice is practical. Tools that understand healthcare data (SIEMs, the security platforms that collect and correlate event logs; clinical data platforms; compliance tooling) already know how to filter, retain, and correlate AuditEvent fields. Adopting the standard means an organization's existing tools can read Sonador's evidence on day one, without a translation layer for a Sonador-only format, and that the records stay readable years from now to tools that have never heard of Sonador.
A shared vocabulary also pays off at correlation time. In a SIEM, a Sonador denial can sit on the same timeline as a VPN login and a workstation alert, joined by the account and network address the Audit Event already carries. The audit trail stops being an island: the imaging platform's evidence sits alongside everything else the security team collects, and analysts work with the queries and dashboards they already know rather than learning a one-platform format first.
What the Log Covers
Sonador records four classes of events (matching the decisions this series has traced through the platform): access, identity, policy, and credentials. Applications which are integrated with Sonador via Data Services will also log access events.
Tracking and Exporting Access Events
Within Sonador, access requests arrive by two roads. Inside the imaging server, the Orthanc Advanced Authorization Plugin intercepts every attempt to read or change a DICOM resource (patient, study, or series) and asks whether the caller is allowed. Outside it, Data Services carry the same question on behalf of connected applications (pipelines, notebooks, and dashboards).
Neither system answers on its own. Both forward authentication/authorization requests to the Sonador Web Application, where the Resource Access Control Engine evaluates it against the user's identity, group membership, and the policies attached to the resource. The engine returns a decision (permitted or denied) and that decision is the event. As each one is made, the web application exports it as an access record: who asked, through what system, for what resource, with what result.
Kafka's role here is worth pinning down, because the delivery guarantees that follow all trace back to how it works. Producers (Sonador, in this architecture) publish events to a named topic. The topic's partitions store those events durably and in order, an append-only ledger. Consumers read at their own pace, each keeping its own place in the stream, so a real-time alerting pipeline and a nightly archival job can share one topic without coordinating. And because events persist, the log is replayable: a consumer added next quarter can process history it was never running for. That last property is what makes Kafka a natural audit transport — the record does not depend on any single consumer having been awake.
In practice, most organizations attach two kinds of consumers. The first is analytical: a SIEM or log platform that correlates events, drives dashboards, and raises alerts when a pattern crosses a threshold. The second is archival: durable, inexpensive storage where events accumulate for the retention window the organization's policies require, ready for periodic access review. Both read the same topic without getting in each other's way, and a consumer added later can replay what it missed. Sonador takes no dependency on either: the platform's job ends when a well-formed event crosses the boundary.
Because audit events describe access to patient data, the transport itself is treated as a security boundary. The 0.4.1 release brings TLS encryption and SASL authentication for the Kafka connection, with credentials supplied through files on disk rather than passwords pasted into configuration. Settings are validated at startup, so a misconfigured deployment fails loudly rather than silently shipping events insecurely; secrets are redacted from logs and error output; and delivery retries are handled safely. Existing deployments are untouched by all of this: a configuration without the security block keeps running PLAINTEXT exactly as before.
Held to Its Own Standard: Privacy and Safety by Design
An access log sits on delicate ground: built carelessly, a security control becomes a privacy risk and an availability risk of its own. A log that copies patient data multiplies the surface an attacker can reach; a log that sits in the request path turns its own failures into clinical failures. The Access Log is designed against both, by two rules.
The first rule is minimum necessary: a record carries what an investigation needs to identify the actor, the resource, and the decision, and deliberately nothing more. Access logs can carry sensitive information of their own, so what stays out of the record matters as much as what goes in. Recording parameter names but not their contents preserves the shape of a request without its substance: an investigator can see that a worklist was searched by StudyDate without learning the date that was typed. Deployment hostnames are omitted so the log cannot double as a map of the network. And tokens and credentials are never written, so a leaked archive of audit events cannot become a credential spill.
The second rule is that patient data stays available. Access logging runs outside the clinical request path and works on a best-effort basis: it tries, within limits, and never holds up patient care to keep trying. Event publication makes a bounded attempt against Kafka (one producer per worker process, flushed at shutdown), and if Kafka is slow or unavailable, Sonador notes the miss and moves on with the clinical work. Repeat requests may be answered from the short-lived authorization decision cache, and, as noted above, cached decisions retain their audit context. The failure behavior was chosen deliberately: a logging problem stays a logging problem.
Enabling the Audit Log
Step 1: Enable the log
The Access Log is opt-in; nothing is recorded until a deployment turns it on in the Sonador/Orthanc configuration. The Audit Log is enabled by setting the AUDIT_LOGGING_ENABLED block of the Kafka section in the site configuration.
# Audit logging is enabled by setting the AUDIT_LOGGING_ENABLED # value within the configuration to "True" and by # configuring the connection. [Kafka] AUDIT_LOGGING_ENABLED = 'true' [[Audit]] AUDIT_TOPIC = 'sonador-audit-event' AUDIT_SOURCE_SITE = 'sonador' # Required options in the connection are the server # (bootstrap.servers) and client ID (client.id). # The Audit topic is given by the AUDIT_TOPIC # parameter in the Audit section. [[Connection]] bootstrap.servers = 'kafka:9092' client.id = 'sonador-web' message.timeout.ms = '300000'
Step 2: Add the Kafka connection settings block
Before events leave the host, give the transport its TLS and SASL configuration, with credentials read from files rather than embedded in configuration. The settings are validated at startup: a bad path or an inconsistent mechanism stops the deployment instead of degrading it silently. [[Connection]] block accepts any librdkafka client property (unchanged). There are no Sonador specific aliases. Refer to "Audit Logging"in the Sonador Documentation for additional detail.
[Kafka] # ... # Kafka Connection options are passed as librdkfakfa # client properties unchanged. There are no specific # Sonador aliases. [[Connection]] bootstrap.servers = 'kafka.example.com:9093' security.protocol = 'sasl_ssl' sasl.mechanisms = 'SCRAM-SHA-512' sasl.username = 'sonador' sasl.password = '...' ssl.ca.location = '/etc/sonador/tls/ca.pem' # ...
Step 3: Consume the stream
Any Kafka client can read the topic (access-log-events in the release notes, though names may be deployment-configurable). A minimal Python consumer follows; kcat works equally well for spot checks. Each message is one FHIR R4B AuditEvent.
import json from kafka import KafkaConsumer # Verify topic name and client settings for your deployment. consumer = KafkaConsumer( "access-log-events", bootstrap_servers="broker.internal:9093", security_protocol="SASL_SSL", sasl_mechanism="SCRAM-SHA-512", sasl_plain_username=open("/run/secrets/kafka-username").read().strip(), sasl_plain_password=open("/run/secrets/kafka-password").read().strip(), ssl_cafile="/etc/sonador/tls/ca.pem", value_deserializer=lambda v: json.loads(v), ) for message in consumer: print(json.dumps(message.value, indent=2))
Step 4: Route the stream to its home
Point a SIEM consumer at the topic for correlation and alerting, an archival consumer at the same topic for durable retention, or both. Retention policy (how long, on what storage, reviewed by whom) belongs to the organization, in the systems it already trusts for exactly this job. A worthwhile acceptance test: perform one deliberate denial and one failed sign-in, then confirm both appear in the SIEM with the outcome and agent fields you expect. When that round trip works, the pipeline is real: request to evidence, with the organization's own tools holding the evidence.
Best Practices
The Sonador Access Log is opt-in and disabled by default. It is designed to help implement and support audit controls; but will by itself not establish compliance. Compliance is a property of an organization's whole program. Retention windows, review cadence, alert thresholds, and the response when a signal warrants follow-up are organizational responsibilities and live within a Healthcare organization's tools.
Practically: decide before enabling the log which consumers will read it and who reviews what they find; treat the four event classes as a checklist for coverage conversations with your compliance team; and exercise the pipeline including a deliberate denial and a failed sign-in.
IMPORTANT: Enable TLS/SASL transport security before shipping events off-host in production. Audit events describe access to patient data; the channel that carries them deserves the same protection as the medical imaging deployment.
Conclusion
The Access Log gives Sonador operators something the platform could not offer before: a durable record of how imaging data is actually used. Sign-ins, access requests and their outcomes, policy changes, and credential activity are captured as FHIR R4B AuditEvents (connected applications included) and delivered over Kafka to whatever analysis and retention tools the organization already runs. Because the events use a standard vocabulary and an open transport, there is no proprietary log store to operate and no new console to learn; the record lands where an organization already does its security work.
The log is opt-in, and what it carries is deliberately bounded: enough to reconstruct who did what, with what result (never search contents, credentials, or the imaging data itself). For an organization that enables it, the practical change is simple. Questions about access to patient data stop being questions about what the platform might have done and become questions a record can answer.
Documentation
- HHS HIPAA Security Rule — Audit Controls: 45 CFR 164.312(b). Access records required by HIPAA.
- HL7 FHIR R4B AuditEvent
- Sonador 0.4.1 Release Announcement
- Managing Users and Access in Sonador
- Resource Access Control (ACL) in Sonador
- Orthanc Advanced Authorization Plugin
- Sonador Platform Documentation: developer resources, including deployment and configuration guides
Comments
Loading
No results found