Privacy and personal data¶
This page describes, factually, which personal data Steward processes, where it lives and how it can be exported or erased. It is technical documentation for the organization that deploys Steward, not legal advice: your data protection officer or counsel decides what it means for your own obligations.
Who is responsible¶
Steward is software that you run yourself. There is one independent instance per client, on the host you choose.
- The controller of the personal data is the organization that decides why and how the instance is used: typically the client whose directory is managed. The MSP that deploys and operates the instance for that client usually acts as its processor. Who is what is a matter for your contract; Steward does not decide it.
- The author of Steward is neither. Steward sends nothing to the author or to any third party of the project: there is no telemetry, no analytics, no crash reporting, no update check and no license check. This was verified in the code: the only network connections the instance opens are the ones you configure (LDAPS to your domain controllers; the Teleport JWKS URL if you enable Teleport; the webhooks and SMTP server of the notification channels you create; the internal call to the helpdesk password service if enabled). The optional sidecars the installer adds connect only where their job requires: the ACME container to the certificate authority and to your DNS provider's API, the Cloudflare Tunnel container to Cloudflare. The web app loads no script, font or image from another site.
- Your exposure choices bring their own processors. Behind Cloudflare Tunnel and Access, or behind a reverse proxy or WAF operated by someone else, that provider terminates TLS and sees the traffic (names, attribute values, the AD password typed at sign-in); a publicly trusted certificate puts the console's host name in the public Certificate Transparency logs (use a wildcard certificate to avoid it). See Exposure and HTTPS certificate. The About dialog link to the source code is a plain link followed only if someone clicks it.
What is processed¶
| Data | Where it comes from | What is kept |
|---|---|---|
| Directory attributes of the managed accounts, groups and computers (name, mail, phone, department, group membership, account status, LAPS metadata, ...) | Read from, and written to, Active Directory by the console on behalf of an operator | Not copied into the Steward database as a rule. Search results and profiles are read live. Names and attribute values appear in the audit log only for the changes made (old and new values, as described below) |
| Console operators (name, provider, AD subject or Teleport user, roles, delegations, enabled flag) | Created when an operator is added or signs in | Operator table in the SQLite database |
| Sessions | Created at sign-in | Server-side session record (operator, creation and expiry times); the browser only holds an opaque, HttpOnly cookie |
| Audit log | Written for every action, refusal and sign-in event | Time, operator, provider, action, target objectGUID, attributes changed with old and new values, result, reason, ticket reference (at most 100 characters), verification method of a reset, hash chain. The password of a user is never logged or audited. For failed fleet-token calls the source IP address is recorded; sign-in throttling keeps IP addresses in memory only and not on disk |
| Tickets and reasons typed by operators | The helpdesk and onboarding forms | In the audit rows of the action they accompany |
| TOTP secrets of operators (authenticator app) | Enrolment on the Security page | Encrypted with AES-256-GCM under the instance master key; never returned by the API |
| Technical-account secrets (service accounts, notification webhook URLs and keys, SMTP password) | Setup and settings pages | Encrypted with the master key; write-only in the API |
| Notification payloads | Events you subscribe a channel to | Sent to the channels you configured (webhook, Teams, Slack, e-mail): event type, operator name, target display names and summary. The secrets of the channel are not part of the payload; see Notifications for the exact payload |
| Standard output logs | The container | One JSON line per audit event and operational messages; same content as the audit log, without secrets. Retention is whatever your Docker log driver and collector apply |
Where it is stored¶
- SQLite database in the
/datavolume (steward.db): operators, roles, delegations, sessions, audit log, settings, templates, notification channels (secrets encrypted). - Master key and data-protection keys in the
/secretsvolume (mode 0700): the keys that decrypt the secrets above. Back them up separately from the database; a backup of one without the other protects the encrypted values. - Active Directory remains the system of record for all directory data. Steward does not replicate the directory.
- Backups made with
deploy/backup.shcontain the database and/secrets, and are as sensitive as both: store and retain them under your own policy.
Retention¶
- Audit log: kept forever by default. Set
Audit:RetentionDays(0 or at least 30) to purge older rows once a day; the hash chain keeps verifying from an anchor and each purge is itself audited. Forward the stdout audit stream to your SIEM if you need a longer copy, and apply the SIEM's own retention. - Sessions: expire after the idle and absolute timeouts (
Session:Idle, default 30 minutes;Session:Absolute, default 10 hours) and are dropped when the operator is disabled or deleted. - Browser: the console keeps only cosmetic preferences (language, theme, sidebar state) in the browser; the "recently viewed" list is cleared at sign-out.
- Settings, roles, templates and notification channels: kept until deleted.
Export and erasure¶
- Operators: deleting an operator (Delegations, Operators) removes their console record, sessions and TOTP secret. Audit rows are
deliberately not rewritten (the hash chain makes them tamper-evident); the
operators.deletedrow records who was removed. Rows age out withAudit:RetentionDays. - Audit log: exported from the Audit page (CSV) or through the API. Erasing individual rows is not possible without breaking the chain; use the retention limit, or retire the instance (below).
- Directory data: exported from and erased in Active Directory with your usual tools; Steward holds no separate copy to erase. A user's request about their AD data goes to the people who administer the directory.
- Whole instance: removing the
/dataand/secretsvolumes (and any backups and forwarded logs) removes everything Steward stores.
Security measures¶
In short: deny-by-default authorization with two independent decisions (console and AD), strict LDAPS validation, step-up with an
authenticator code for sensitive changes, server-side sessions with Secure, HttpOnly, SameSite=Strict cookies, encryption of
all stored secrets, a tamper-evident audit chain, a strict content security policy, and per-client isolation. Details:
Security model, Operations (audit, backup) and Notifications.