Inshipia Security Gateway

The Inshipia Security Gateway (ISG) brokers privileged access to production systems — command lines over SSH, and web consoles over Web Access. Administrators do not reach a target host or a console directly; they go through the gateway, which authenticates them, checks what they do against policy, and records the result.

What the gateway puts between an administrator and a production system, on both paths:

• Multi-factor authentication — an emailed one-time code, or RFC 6238 TOTP; single sign-on through the organisation's OIDC or SAML identity provider is available for the login itself, with the directory still deciding who exists and what they may do.
• Four-eyes approval — access that requires a second person waits until an authorised approver decides; nobody can approve their own request. A self-service window on a stated reason is the alternative where four eyes are too slow.
• Locks — a user or an application is stopped at once, on every broker, and their running sessions are closed.
• No credentials in the administrator's hands — the gateway brokers the access, so nobody holds a standing key on a target host or a console's shared password.
• A tamper-evident audit log — append-only JSONL, one line per event, reviewable in the web UI and parseable by a SIEM.

And per path:

• SSH: command-level policy. Each command is evaluated before it reaches the target host; a denied command is blocked on the gateway, not on the server. Access is by a short-lived certificate the gateway signs for the session, and every session is recorded.
• Web Access: request-level policy. Each request to a console is judged by method and path before it reaches the console, a sensitive one can ask for a fresh second factor, and every request is a line of the session's transcript. The console learns the user's identity from a signed assertion, or ISG signs in with a shared account the browser never sees.
• RDP: session-level policy. On RDP the verdict is at the session level: who, where, when, with which approval. Every session is recorded, can be watched live and can be terminated; the clipboard (each direction), printer and audio are off unless the policy opens them per application and role, every transfer audited without its content; the drive and the microphone are not available. A command-level, pre-execution verdict on RDP does not exist on the market, and ISG does not promise one. See remote desktop (RDP).

What you will find here

The Platform section is where to start — what both paths share:

• Getting started — from an empty host to a running gateway with a first identity: prerequisites, install, first start, first identity, and how to verify each of them.
• Fleet deployment — the schedule for installing and operating a fleet with the shipped Ansible automation: which playbook runs when and on which hosts, what every run needs on its command line, what site.yml does in order, teardown, and the operations runbooks.
• Architecture — what the parts are and how they fit: the components, the ports and local sockets, the certificate lifetimes, where state lives, and what the gateway refuses to start without.
• Identities, groups and locks — who the gateway thinks you are: where identities and groups come from, which group opens which door, what the web UI shows to whom, and how a user or an application is locked.
• Operator's interface reference — every port, socket and file the gateway opens or dials, one subsystem per section: where the value is set, what it occupies, and the command that measures it.
• Useful commands — the checks run most often, as ready-to-paste one-liners with this installation's names left as placeholders.
• Upgrading the bundled components — the third-party components the gateway ships with: how each one is pinned to an image digest, the read-only report that says what is actually running, and what a restart costs for each of them.

The SSH access section is the command-line path:

• First SSH session — one target host prepared, a first connect, and the session in the record.
• SSH policy and approval — the shape of a command rule and what it is matched against, what the policy cannot read, what is inside each certificate the gateway signs, and the gates a connect passes.
• Target host preparation — what a production server needs before it can be brokered: the two sshd directives, the accounts, the one port, and the command that decides whether the host is ready.

The Web Access section is the web-console path:

• How Web Access works — the path of a request: the listener, the sign-in hand-off, what the broker does with every request, and how a session ends.
• Configuring applications — apps.yaml and its Ansible switch, the listener and its certificate, the three ways an application learns who the user is, form sign-in recipes, and applications added on the web UI.
• Web Access policy — who reaches an application, approval and self-service windows, request rules, a fresh second factor, allow-list mode, and what is recorded.
• Isolated browser — an application that runs in a remote browser on an RBI host: what the user sees, the watermark, a second factor in the view, the screen recording and its playback, the live view.
• Remote desktop (RDP) — a Windows server's desktop through the same isolated path: the rdp:// upstream, the stored account, the pinned certificate, the channels, the recording and the read-only live view.
• Preparing a web console — what a console needs before ISG can broker it: the network, the identity mode, the shared account in OpenBao, writing a form recipe, and behaviours seen on real consoles.

The Reference section is the complete surface of the product:

• Command reference — every isg command, its help text and its flags.
• Configuration reference — every configuration file and every key in it.
• Audit event catalog — every event name the gateway writes.
• Audit log schema — the contract a SIEM parses against: file location and permissions, the JSON shape of an entry, the versioning rule and the rotation behaviour an ingesting agent must tolerate.

The Support section is for the moment something has already gone wrong:

• Troubleshooting — the messages the gateway prints for the platform and for SSH, quoted verbatim and grouped by when you see them, each with its cause and what to do about it.
• Troubleshooting Web Access — the pages a browser gets from ISG and the isg system check rows of Web Access, the same way.

How current it is

Every page under Reference except the audit log schema is generated from the source tree — the command tree, the configuration key registry, the audit event list and the string catalogs — and continuous integration fails the build if a generated page and the code it describes disagree. What these pages state is therefore true of the build they were generated from, not of some earlier one.