PolariStar — İstar Bilişim Türkçe Request a demo

← All modules

Secure access

Password Vault

Secrets are stored under AES-256-GCM; viewing and copying take a separate permission and leave a trace.

The vault is a separate security area for device and account credentials. Secrets are never stored as plain text: each record is encrypted with AES-256-GCM under its own nonce. The SNMP and SSH credentials used for scanning do not live here but in the inventory connection profiles — human access and automation identity are deliberately kept apart. The vault is not the product catalogue, not a customer product and not the knowledge base: a secret belongs in the vault, not in an article.

From the PolariStar panel, with demo data.

No plain text

Secrets are encrypted with AES-256-GCM under a separate nonce per record. Direct database access does not reveal a password. The master key is held neither in the database nor in source, but loaded from a container secret or KMS.

The list never returns a password

The list API does not put the secret in its response. The default view is masked, with browser autocomplete and sensitive logging turned off. Retrieving a password is a separate request behind a separate permission.

Permission-based access, not role-based

Seeing the vault in the menu, opening a record’s password and managing it are distinct rights. Access hangs on two separately granted permissions rather than on a role name: one to view, one to manage. Viewing and copying ask you to authenticate again — an open session is not enough on its own.

Every access leaves a trace

Viewing, copying, editing, exporting and failed attempts all write an audit record. Who opened which record, and when, is kept. Access can be accounted for afterwards.

Scope is enforced in the API layer

Every record belongs to a scope: the customer in MSP mode, the whole company in organisation mode. Scope is enforced in the API and query layer, not just by a filter in the interface. Calling the API directly will not reach another customer’s record either. Picking a scope uses the same two-step narrowing as inventory.

Automation credentials live elsewhere

The SNMP community strings and SSH credentials used for device scanning sit in the inventory connection profiles, in their own encrypted columns. The vault is for access a person makes by hand: web and admin interfaces, SSH, RDP, iLO/iDRAC, hypervisors, VPN, switches and firewalls. Keeping the two apart stops one permission from quietly opening the other.

Linked to a device or cloud account

A vault record can be attached to an inventory device, a location and an access type. While you work on a device you reach its access record without hunting for it somewhere else. The link is optional, so a cloud account with no device behind it can live in the vault too.

Secrets stay out of documents

The product rule is explicit: passwords, SNMP communities, private keys and customer secrets are not logged and not written into documents. A knowledge base article points at the vault record instead of embedding the password. Plain-text CSV export is off by default, and no real password is sent to any AI service.

Role boundaries — who sees whatA four-row matrix. The technical role sees tickets, inventory, monitoring and the password vault, but not sale price or margin. The sales role sees the catalog, quotes and sales reports, but not technical solution detail unless granted explicitly. An administrator sees both sides. The customer portal sees only its own data. The boundary is enforced in the API and query layer, not in the interface.Who sees what — and where the boundary is enforcedROLESEESDOES NOT SEETechnicalSupport teamTickets, inventory, monitoring,the password vault, support reportsSale price, cost, margin,sales reportsSalesCommercial teamCatalog, quotes, customerproducts, sales reportsTechnical solution detail,unless granted explicitlyAdministratorPlatform ownerBoth support and sales reports,plus portal licensesA limited admin cannot issueplatform licensesCustomer portalEnd userTheir own requests, their owndevices, published solutionsAny other customer's data,cost, margin, commissionThe boundary is not only in the interface; it is enforced in the API and query layer.Menus narrow by role, but the restriction passes through the query gate (canAccessClient, getPortalUser).

The path of one access record

  1. 1The record is createdAn authorised user picks the customer, the location and the access type: web, SSH, RDP, iLO/iDRAC, hypervisor, VPN or switch and firewall. Address or hostname, port and username go in.
  2. 2The password is written encryptedThe password or secret note is encrypted server-side with AES-256-GCM. What reaches the database is ciphertext; no column holds the plain value.
  3. 3It is attached to a deviceIf you want, the record is linked to a device in inventory. That keeps the tickets, configuration backups and access record of one device on the same chain.
  4. 4The list arrives maskedThe vault list shows the record, not the password. The response carries no secret and the value stays masked on screen.
  5. 5The password is requestedOpening or copying the password takes a separate permission and triggers re-authentication. Without it the record is visible but the secret stays closed.
  6. 6A trace remainsThe request is written to the audit log: who, which record, when. Failed attempts are recorded too, so an unauthorised try does not pass unnoticed.

Frequently asked

Can you read our passwords?

We cannot. Secrets sit encrypted under AES-256-GCM, and the master key is loaded from a container secret or KMS rather than from the database or the source. Someone holding a database backup still cannot read a password.

Do the SNMP communities we gave for scanning end up in the vault?

No. Scanning credentials stay in the inventory connection profiles, in their own encrypted columns. The split is deliberate: access a person makes by hand and the identity automation uses are not tied to the same permission.

Can a customer see the vault from their portal?

No. The customer portal is a narrow surface: their own requests, their own devices and published solutions. The vault is not among those views, and the scope limit is enforced in the API and query layer rather than in the menu.

In organisation mode there are no customers, so what is the scope?

In organisation mode the vault works as a single company-wide vault, with no per-customer stack. Opening a record’s password remains a separate permission; reaching the menu does not grant it.

Is the vault finished today?

The encryption model, the scope rules and the separation of permissions are written down as binding and enforced. The module is not opened in any customer installation until encryption and scope isolation have been verified independently — that rule is written into the product’s own development documents. A pre-pilot verification list is kept for this module.

Who it helps

IT managers who want device and account credentials in one encrypted, scoped place. Teams that have to account for who used an access, and when.

Related modules

Inventory Knowledge Base Settings and Permissions

See it on your own operation

Let us open a workspace for you and try it with your own customers and devices. We will guide you through setup and data migration.

Request a demo Documentation