Reach each private database on its own, without a VPN.

A database client reaches a private database over a direct connection: through the broker and the connector beside the database, with no VPN. Each database is registered as its own application. Pramaan admits the connection; it does not sign anyone in to the database. This path runs only when you switch it on.

The path a connection takes

Illustrative
Your client
Local port
The database

A client that speaks its own protocol, such as one for SSH, RDP and Postgres, connects to a local port on the person's computer. The Pramaan desktop app carries each connection to the broker. The broker hands it to the database's connector, which dials out to the broker and opens no inbound port.

One application at a time

Illustrative
You
One database
Others closed

Each forward names the application it is for, so each database is reached, and refused, on its own. Each connection is checked on its own: the access token, the person's groups and your access rules. Each private application is denied unless an access rule allows it; on this path, an application with no group assigned, a verdict that asks for inspection and a verdict that asks for step-up are also refused.

Deactivate a person, or disable, re-scope or remove the database's application, and the live connections it covers are cancelled, not merely refused next time.

The token on this path is unbound

Illustrative
A token
No device named

This path refuses a device-bound token outright, because the connection cannot carry a proof: a token that works there is unbound. On this path device posture is unknown, so a rule that requires a trusted or limited device tier never matches there; if no other rule allows the connection, the default deny refuses it.

Refused attempts are recorded

Illustrative
An attempt
Refused
Recorded

On this path, a connection the access checks refuse is written as an audit event once the person's token has been read; a refusal before that, or a connection that fails after it was allowed, is only logged. Each audit event is added to the transparency log. Such a refusal does not count toward the person's sign-in lockout.

For your engineers

Technical detail: the forwarder, the ports and the tunnel scope

Illustrative
Forwarder
Ingress
Tunnel

A direct connection goes through the broker's raw-TCP ingress, and the forwarder is the desktop app's command line. The transparency log follows RFC 6962; each audit event is a leaf.

The recipe from our documentation, for an SSH server registered as the raw-TCP application ssh-vm: point the forwarder at the ingress, sign in, and forward a local port. A database registered as a raw-TCP application is forwarded the same way, by its own name, and its client then connects to the local port.

export PRAMAAN_TCP_TUNNEL_ADDR=id.example.com:9446   # the raw-TCP ingress
pramaanctl login
pramaanctl forward ssh-vm 2222                        # opens 127.0.0.1:2222

In our reference deployment the broker publishes :9445 and :9446 directly; the second is the raw-TCP ingress, each behind source-address connection limits that our host applies. The desktop client's UDP tunnel is also published, behind a token and an address check instead. On your own host, those limits are yours to set up.

A scope just for the tunnel

Illustrative
A token
Tunnel scope

Switch on the tunnel-scope setting and the raw-TCP listener refuses an access token that was not granted the pramaan.tunnel scope.

Questions

Which database clients work this way?

Clients that speak their own protocol, such as those for SSH, RDP and Postgres. This path carries TCP only. UDP (voice, video) comes from the always-on desktop client alone, unicast only, off by default.

Does Pramaan sign people in to the database?

No. Pramaan admits the connection to the application; the database's own login is unchanged.

Can people forward a database from their phones?

No. Forwarding runs in the Pramaan desktop app only: the Android app lists direct-connection apps and does not forward them.

Why is the token used on this path not device-bound?

This path refuses a device-bound token outright, because the connection cannot carry a proof: a token that works there is unbound.

Are refused connections recorded?

Partly: a connection the access checks refuse is written as an audit event once the person's token has been read; a refusal before that, or a connection that fails after it was allowed, is only logged.

Talk to us, or try it first

  1. Book a walkthrough

    Against your own apps, not slides.

  2. Run the lab

    It uses a demonstration account; none of your data is involved.

  3. See pricing

    Published floors, named-user bands and what every tier includes.