Setting Up Privileged Session Audit (Session Recording)

Privileged Session Audit: Where Control Is Lost

Direct access to servers and databases is the most loosely controlled area of infrastructure.

An administrator or contractor connects via SSH, works under their own account or through a shared privileged account, and all that remains of the session is the fact of login in the system log.

What exactly was performed — which tables were read, which data was exported, which configurations were changed — cannot be reconstructed from the logs. While everything runs normally, this goes unnoticed; the cost becomes apparent at the moment of incident investigation.

A typical picture: a database maintenance contractor logs into a production server as root, exports a dump of a client table "for debugging," and leaves.

A few weeks later a leak surfaces, the security team pulls the logs — and there is only the line "session opened for user root." Who, when, and what exactly was done cannot be reconstructed: the command history is either disabled, or edited by the administrator themselves, or lost when the connection drops.

Privileged session audit closes precisely this gap — it records not the fact of login, but the full content of the session.

Without recording administrator sessions, control over privileged user access remains declarative: rights are granted, but what is done under them is unknown.

Incident investigation turns into guesswork, and there is no evidence base for an internal investigation or a conversation with a contractor.

Below we break down how this is closed technically: where to place the interception, what to write to storage, and how to preserve a record that cannot be cleaned up after the fact.

What Changes After Implementing Session Recording

Before implementing session recording, investigating an incident in a production environment comes down to the lack of primary data: the logs show that the configuration changed, but not which administrator did it or as part of which task.

An engineer spends hours cross-referencing timestamps, tickets in the tracker, and chat conversations, and some episodes still remain without a definitive conclusion.

Once privileged session recording is enabled, the investigation relies on a reproducible chronicle: commands, context, and the sequence of actions are tied to a specific account.

The first measurable effect is incident investigation time. When there is a session recording with precise timestamps, finding the cause comes down to replaying the relevant interval rather than reconstructing it from indirect evidence.

In practice, this reduces investigation from hours to tens of minutes, and for typical cases to just a few minutes, because there is no need to pull up the change history and interview participants.

The second effect is the share of actions with confirmed authorship. Each privileged operation is matched to a person and a time, rather than to a shared service account.

This closes the gap that made it impossible to prove who made a change during an investigation, and it eliminates disputed situations during shift handovers.

The third effect is transparency of admin operations and reduced risk of sabotage. When it is known that actions are recorded, out-of-process changes that bypass procedures become visible rather than going unnoticed.

An entire class of failures related to uncontrolled changes to access rights, configurations, and traffic routes disappears.

Worth noting separately is readiness for audits: session recording provides an export that can be presented to an auditor or the security team without manually assembling evidence.

Regulatory and internal requirements are met through a standard mechanism rather than through one-off efforts by the team.

Recording methods: gateway, host agent, protocol proxy

Privileged session auditing can be built in three ways, and the choice between them determines what actually ends up in the recording.

An access gateway is placed in front of the target perimeter and passes traffic through itself — recording happens at the entry point, before the command reaches the server.

An agent on the server captures activity from inside the host, including local connections that bypass the network. A protocol proxy parses a specific management protocol and writes commands in an already structured form.

In practice, these options are combined.

The gateway covers the main access flow and provides a single point of control, the agent adds completeness on critical hosts, and the protocol proxy deepens detail where it matters to see the commands themselves, not just the fact of a connection.

The limitations of each method are important to know in advance — otherwise the recording will have a blind spot exactly in the area that interests the security service.

Separately, it is worth considering that session recording is also a load on the infrastructure: the volume of stored data grows along with the number of privileged connections.

Therefore, the choice of session recording method is tied to the retention policy and to restricting access to the recordings themselves — otherwise auditing turns into a source of new risks.

How we implement: from inventory to handover

Implementation of privileged session auditing begins not with installing a recording tool, but with answering the question: who goes where with elevated privileges.

Until there is a complete picture, any recording configuration creates blind spots — the most interesting sessions remain out of control.

Inventory and connection scheme

We collect all privileged accounts: local administrators, service and system accounts, domain groups, access to hypervisors, DBMS, and network equipment. Separately, we record where the login comes from — engineers' workstations, jump hosts, automation tools.

The output is a registry of accounts with owners and criticality, which also becomes the basis for recording rules.

Next, we design the connection scheme: where the interceptor is installed, how traffic goes through the intermediate node, what happens when the recording node is unavailable.

Here we also decide whether we record only commands or the full terminal video stream, and how this correlates with the load on the target systems.

Configuration and verification

Configuration proceeds by groups: for each category of accounts — its own recording profile, its own retention periods, and its own rules for masking sensitive data in command output.

In parallel, we configure the export of events to external storage so that the log cannot be modified with the same account that writes it.

Verification is a separate stage with a set of scenarios: login by key and by password, operation through an intermediate node, connection loss in the middle of a session, an attempt to disable the recording agent, recovery after a restart of the target node.

We confirm each scenario not with "it works," but with a specific artifact — a recording that can be found by session identifier.

Handover to operations

We hand over not only the configured system, but also the regulations: who has access to the recordings, how a request for viewing is processed, what to do in the event of an incident.

We train the on-duty shift and the security service to search for a session by user, time, and host.

After handover, a support period remains — we refine the rules based on the real flow of events, when it becomes clear which sessions are being recorded unnecessarily and which should be added.

Access policies and separation of administrator roles

Administrator rights are described not by "access to the server" but by a matrix: role → set of actions → scope → condition.

As long as the matrix lives in the tech lead's head, any new engineer gets access "like everyone else," and six months later no one can say who went to prod and why.

We move it into the configuration of access systems and bring it in line with the principle of least privilege: a role grants exactly the amount needed for the task, and no more.

A separate axis is the rights to view recordings. Whoever replays a session sees everything the administrator did, including the contents of configs and tokens in the command line.

Therefore access to replay is granted by a separate role that does not coincide with the executor's role: the engineer works, the security service watches, the department head sees only metadata — who, when, on which node, how long the session lasted.

The action log is immutable: records are stored in a storage with editing and deletion prohibited, and the retention period is set by policy.

What we configure in the rights:

• Administrator roles: on-call, senior engineer, auditor, security service — with different sets of actions.
• Scope: prod, staging, a separate environment, or a specific group of nodes.
• Entry conditions: mandatory second factor, working window, trusted network segment, confirmation by a second engineer for critical operations.
• Separation of rights: the executor cannot delete or edit their own session record.
• Rights to view recordings: a separate role with restrictions by environment and by data type.
• Retention periods and archiving rules: how long a record lives in hot storage, what goes to the archive.
• Review procedure: who confirms and how often that the granted rights are still needed.
• Action log for the rights themselves: granting, elevation, revocation — everything is recorded with the author of the change.

Such a matrix removes the main risk of privileged access — not "they'll break in from outside," but "an insider will do something extra and no one will notice." When rights are laid out by role and session recordings are protected from editing, incident investigation takes minutes: we pull up the log, look at the session, and see the command and the context.

Case study: how we closed uncontrolled contractor access

What it was like before

The client is a manufacturing company with a distributed infrastructure. Contractors providing database and network equipment support logged into servers using shared accounts: one account per team, the password was sent via messenger and was not changed for months.

For half of these accounts, the owner could not be identified — the person had left, but the access remained active. An inventory audit before the start revealed 68 accounts with privileges, of which 41 had no assigned responsible person.

Incident investigation took up to three days: logs were collected manually from each node, correlated by time, and there was no answer to the question "who exactly executed the command" — all actions were performed under a single login.

At the same time, some contractors worked from their own laptops, bypassing the corporate perimeter.

What was changed

We deployed Teleport as a single entry point for privileged access. Each contractor received a personal account with a short-lived certificate — instead of a static password.

Access is granted to a specific node and role, the session lifetime is limited, and extension requires justification in a request.

Sessions are recorded at the protocol level: commands, terminal output, time, and connection context are saved. The recording is tied to an individual, not to a shared login, and is stored in a secure vault with an immutable retention period.

At the same time, we established an ownership registry: each account got a responsible person and a review date, and inactive ones are blocked automatically by a lifecycle rule.

What the result was

Investigation is no longer a probe: an engineer opens the session recording, filters by account and interval, and sees the exact sequence of commands. Revoking access upon contract termination is a single operation in the registry instead of going through dozens of nodes.

How session recording differs from command logging

Command logging captures text: who, when, and which line they entered into the console. This is enough to see the intent, but not enough to see the result.

The psql command looks the same in the log whether an administrator dumped a single table or opened an interactive session and worked inside it for hours — all subsequent actions won't make it into the log, because they happen inside an already running process, not in the shell.

Session recording works at a different level: the entire terminal input-output stream is written, including interactive shells, work inside editors, database responses, and utility output.

The result is not a set of scattered lines, but a replayable snapshot of the work: it can be played back at the same speed as the original, or skimmed through, showing pauses, cancelled commands, and clipboard pastes.

It is the replay of actions that answers the question "what actually happened," rather than "what was typed."

The difference between the approaches shows up in two scenarios. The first is incident investigation: the command log shows that an administrator connected to the server, and then silence; the session recording shows what they did inside.

The second is reviewing a disputed operation: the log shows a single deletion command, while the recording shows that there were three checks and a rollback before it, and that the deletion was a deliberate step, not a mistake.

A complete picture is achieved through a combination: the log provides fast event search and is convenient for automated rules and alerts, while the session recording provides context and the evidence base.

Command logging is cheaper to store and easier to parse with machine tools, while session recording is heavier in volume, but it is precisely what closes the blind spots of interactive work.

In practice, they are not set against each other but configured together: the log as an index, the recording as the primary source.

What the customer receives upon completion of implementation

Implementation ends not with the launch of recording, but with the handover of a complete set of materials by which the system operates without us.

Below is what exactly remains with your team: an audit of privileged sessions without these artifacts turns into a set of scripts that no one dares to modify.

• Collection configurations. Rule files: which accounts and groups are recorded, the depth of recording commands and output, retention period, rotation. Everything is in a version control system — changes go through review rather than being edited by hand in production.
• Connection schematics. How target servers and network equipment send the stream to the recording node, where the points of failure are, what happens when the channel breaks: buffering on the source side and backfill after connectivity is restored.
• Access policies for recordings. Who can view, who can export, who cannot delete. Separation of roles: the recording node administrator does not have the right to erase archives, access to viewing is by request and with logging of the viewing itself.
• Investigation procedure. A step-by-step order for an incident: how to find a session by time, account, and host, how to export a fragment, how to prepare an excerpt for the security service or a review with a contractor.
• Support instructions. What to do when storage is full, the recording node is unavailable, time is out of sync on the source — with criteria for when to escalate.
• Documentation and handover. Stand diagram, access matrix, change log, and a short session with your team: we walk through the investigation of a real incident from start to export.

Separately, we fix the verification: a test privileged session that we find together in the archive and export. If the recording is not found or the fragment is unreadable — the implementation is not closed. Describe your task, and we will come back with an estimate and a plan.

Let's discuss your task and come back with an estimate

To come back with an implementation plan and a timeline estimate, rather than generalities, we need to understand your current infrastructure and recording requirements.

Tell us how many privileged accounts you have and through which access points they operate: SSH to a fleet of servers, RDP to Windows hosts, database management panels, cloud administrator web consoles.

Separately, clarify whether you already have centralized event collection and where logs are written — this determines whether we integrate into the existing perimeter or deploy collection from scratch.

The key question is what exactly should be captured in the recording and how long it is retained.

For some, the fact of a connection and a set of executed commands is enough; for others, a full screen video recording tied to a timeline is needed; and for others still, a prohibition on copying files via the clipboard is also required.

This directly determines the architecture: where the access broker sits, how session storage is structured, and how viewing rights for recordings are delineated between the security team, audit, and the administrators themselves.

Equally important is how you envision rollback and compatibility.

If the recording sits between the engineer and the server, any configuration error will block access to production — so we design a backup entry path bypassing the broker in advance and test it on a staging environment.

Tell us whether there are regulator or internal policy requirements for the storage format and retention period, and which systems should receive exports: SIEM, support service, archive.

Describe the task in free form — host fleet, access protocols, recording and storage requirements, timeline constraints. We will come back with a phased implementation plan, a component placement diagram, and a timeline estimate for your perimeter.