Security and architecture
With an access management tool, the architecture is the product. So we describe what sits where, and who sees what.
Where the password lives
Either in your existing Pleasant Password Server, from which the broker requests it with a read-only service account, or in VisionDesk's own database, encrypted with AES-256-GCM. The key lives on the broker machine, not in the database.
Who sees the password
Nobody. The secret travels from the broker through the client into the RDP engine and never appears in the interface. For a manual sign-in the system types it into the input field rather than using the clipboard, because tools that watch clipboard history would read it from there.
The client never talks to the vault
The client never receives a vault token. Every secret request goes through the broker, where it is logged, so no end user needs any permission in the password manager.
Sign-in
Windows authentication with Active Directory and Kerberos. There is no separate VisionDesk password that could leak.
Network
The broker runs in your own network, over HTTPS. There is no outbound connection to any cloud service, no telemetry, and it works in a closed network.
Who asks for a secret, and why
Every secret request must state which user is asking, for which target, and why. The parameter has no default value, so the compiler enforces it at every call site.
The TOTP seed never reaches the connector
The seed of a tunnel profile's one-time code is filtered out before the secret is even resolved, so it never gets to the connector.
Envelope encryption, rotation without downtime
Locally stored secrets are protected by a data key, which is sealed by a key above it. Rotation needs no downtime, and the procedure is written up in a separate runbook.
The audit log cannot be rewritten unnoticed
An append-only trigger and an HMAC-signed seal chain protect the log table. The seal key is not in the database, so whoever obtains only the database cannot forge a valid seal.
Measured binary hardening
Address space layout randomisation, data execution prevention and control flow guard are enabled on each of the three shipped executables. The raw output and the measurement script are in the documentation.
Measured transport encryption
TLS 1.3, the server certificate fingerprint matches the configured pin, and both ends of the chain refuse an unencrypted connection.
Rate limiting per user
The whole API is rate limited in four bands, by user rather than by IP address. So one colleague's broken script does not throttle a whole team working behind the same terminal server.
A stored secret can be deleted for good
Deletion overwrites the stored value with random bytes, removes the row and leaves an audit trace. We state the limit too: it is not disk-level erasure, and the transaction log and backups may keep the old bytes.
An upgrade never overwrites a running client
A new release gets a new version folder, and only the pointer file is swapped. Before installation the signature check hard-fails if the package is not valid.
The risk we name openly
The broker machine is a central element: with the built-in store, losing the encryption key makes locally stored secrets permanently unrecoverable. We go through backing up the key explicitly during onboarding.