Data protection and encryption¶
This page states where Logstrm encrypts data, where it does not, and which encryption responsibilities belong to the operator. Claims are limited to what the software implements.
Encryption in transit¶
Outbound to destinations¶
| Destination | Transport | Certificate validation |
|---|---|---|
| Microsoft Sentinel via Data Collection Rule | HTTPS to the Data Collection Endpoint | Go standard library trust store; no override available |
| Azure Entra token endpoints (all auth modes) | HTTPS | Go standard library trust store; no override available |
| Elasticsearch | Operator-configured http:// or https:// |
Configurable: custom CA, client certificate, or insecure_skip_verify |
The Sentinel emitter provides no option to disable certificate validation. The Elasticsearch emitter does: insecure_skip_verify and plain http:// endpoints are accepted. Treat both as prohibited in production and enforce that in configuration review.
Inbound to Logstrm¶
The Data Plane HTTP listener, the Syslog listener and the Manager API/UI do not terminate TLS in-process. The Syslog listener supports TCP and UDP only; there is no TLS Syslog server, and configuration structure must not be read as evidence that one exists.
Therefore:
- Terminate TLS at an ingress controller, load balancer or reverse proxy in front of the Manager and the HTTP listener, and restrict the backend network path.
- For Syslog, keep the listener on a trusted network segment, or place a TLS-terminating relay in front of it. Do not expose it to untrusted networks.
- Do not describe a default Logstrm deployment as end-to-end encrypted on the inbound path.
Encryption at rest¶
Logstrm performs no application-level encryption. All at-rest protection is inherited from the storage platform the operator provides.
| Data | Written by | Format | Product-level encryption |
|---|---|---|---|
| Dead-letter queue entries | Data Plane | JSON Lines files in the configured DLQ directory | None |
| JSONL archive output | Data Plane | JSON Lines file (0600 file mode) |
None |
| Configuration version history | Manager | SQLite table storing the full configuration YAML | None |
| Registered node records, including Data Plane authentication tokens | Manager | SQLite | None |
Operator responsibilities that follow:
- Place the DLQ, archive and Manager database on encrypted volumes. On Azure, that is Azure Disk or Azure Files encryption; on Kubernetes, the encryption properties of the StorageClass backing the PersistentVolumeClaim.
- Extend encryption and access control to backups and snapshots of those volumes, which contain the same plaintext.
- Restrict filesystem and volume access: DLQ files and the archive contain raw event payloads, and the Manager database contains configuration and node tokens.
- Apply retention limits so buffered payloads are not stored longer than the data-classification policy allows.
Customer-managed keys¶
Logstrm implements no key-management layer, performs no envelope encryption and stores no encryption keys. It therefore cannot independently offer CMK, key rotation or crypto-shredding for data it writes.
What is achievable today:
- Infrastructure CMK — encrypt the volumes holding the DLQ, archive and Manager database with customer-managed keys through the platform, for example Azure Disk encryption with a key in Azure Key Vault. Key lifecycle, rotation and revocation are managed in the platform, transparently to Logstrm.
- Destination-side CMK — encryption of data after delivery is a property of the destination, such as a Log Analytics workspace or an Elasticsearch cluster, and is configured there.
What is not available: per-tenant or per-field application-level encryption, customer-held keys for in-flight buffering, and cryptographic erasure of buffered data by key revocation. Revoking a volume key makes the volume unreadable but is a storage-level action, not a Logstrm feature.
Reducing sensitive data at rest¶
Where payloads must not persist in plaintext buffers, reduce what is written rather than assuming encryption that does not exist:
- Use the pipeline's masking and redaction transformations to remove sensitive fields before emitters, so DLQ entries and archives contain already-masked events.
- Drop or project unnecessary fields in the pipeline instead of forwarding whole payloads.
- Size the DLQ and its retention deliberately; it is a bounded failure buffer, not an archive.
Masking is operator-configured. It applies only to the fields the configuration targets, and it is not a substitute for storage encryption or access control.