Auditing
A fundamental challenge of securing access to sensitive computing resources is creating a system of record around users' access and actions over remote sessions. Organizations are typically motivated to invest in recording capabilities to address at least one of the following:
Compliance management: Organizations need to prove compliance of their infrastructure's security posture to internal or external auditors. Records of remote access are often required.
Various laws and regulations have record keeping requirements. These laws and regulations specify what activities need to be recorded and how long the records must be kept. One of the reasons an organization records access to a system is to comply with the record keeping requirements of a law or regulation.
Threat management: Organizations must monitor, investigate, and react to security incidents and malicious activity. Further, security teams seek to prevent incidents and proactively identify potential threats in real time.
In the course of their investigations, security teams may need to identify suspicious activity conducted by a specific principal or against a specific target. Administrators may require a breakdown of session information by user or a time-based view of past activities, for example.
Session recording
Boundary provides auditing capabilities via session recording. In Boundary, a session represents a set of connections between a user and a host from a target. The session begins when an authorized user requests access to a target, and it ends when that access is terminated. All sessions have a fixed time limit, and all connections are proxied through a worker.
Sessions are recorded by workers. Workers are the proxy between an end user and a target. No session data is routed through a controller during the recording stage. The worker stores the session recording on local disk during the recording phase, and then moves the recording to the external object store when the session is terminated. Session recordings are stored in the BSR (Boundary Session Recording) format. Any credentials needed to access the external object store are passed from the controller to the recording worker when the session is established.
In a multi-hop session, the worker that is configured to access the external object store is the worker that records the session. If no worker can access the storage backend, the session is canceled and an error is returned.
You view session recordings with a session player that runs in a web browser. The session player is an aggregation of web components that work together to present the different parts of a session recording as a logical whole. A controller retrieves the contents of a recording from a worker with access to the external object store. The controller decodes the contents of the recording into a format that is usable by the player. The player then retrieves the data from the controller.
Session recording audit events
Boundary emits audit events for actions performed by users. Here are some of the possible event field types that are emitted:
timestamp- The timestamp of the eventauth- Authentication information about the user who performed the action.response.details.item.connection_recordings.id- Session recording ID.channel_recordings.id- Session recording channel ID.start_time.seconds- Start time of session recording.end_time.seconds- End time of session recording.bytes_up- Upload bytes during session.bytes_down- Download bytes during session.channel_recordings.duration.seconds- Length of time a session took, recorded in seconds.
request_info.client_ip- The client IP address used by the user.response.details.item.create_time_values.target.name- The name of the targets.target.id- The ID of the target accessed during the recording.target.type- The type of protocol used.target.scope.name- Name of the scope the target accessed belongs to.target.scope.parent_scope_id- Parent ID of the scope the target accessed belongs to.
response.details.item.Attrs.SshTargetAttributes.storage_bucket_id.value- Storage bucket ID attached to a target that is used for storing session recordings.enable_session_recording.value- Determines if session recording is enabled on a target.
Storage buckets
A resource known as a storage bucket is used to store the recorded sessions. The storage bucket represents a bucket in an external object store. At this time, the only supported storage for storage buckets is AWS S3. In AWS S3, a storage bucket contains the bucket name, region, and optional prefix, as well as any credentials needed to access the bucket, such as the secret key.
Before you can use a storage bucket to record sessions, you must configure a worker with local storage to act as a cache. The entire recording is written to the local storage cache before it is uploaded. Once the session is complete, the files are automatically synced with the external storage bucket and deleted from the worker's local storage.
A storage bucket exists in either the Global scope or an Org scope. A storage bucket that is associated with the Global scope can be associated with any target. However, a storage bucket in an Org scope can only be associated with targets in a project from the same Org scope. Any storage buckets associated with an Org scope are deleted when the Org itself is deleted.
Deleting a storage bucket in Boundary does not delete the bucket in the external object store, nor does it delete the recorded sessions in the bucket. The storage bucket's lifecycle does not affect the lifecycle of the bucket in the external object store. Any session recording metadata that is attached to the storage bucket is deleted when the storage bucket is deleted.
BSR directory structure
The BSR (Boundary Session Recording) defines a hierarchical directory structure of files and a binary file format. It contains all the data transmitted between a user and a target during a single session.
Boundary creates the top-level directory of the BSR as <sessionID>.bsr. This top level directory contains session summary information and subdirectories for connections.
A BSR connections directory contains a summary of connections, as well as inbound and outbound requests. If you use a multiplexed protocol, there are subdirectories for the channels.
BSR Session folder
session-recording.meta file example:
session-meta.json file example:
session-recording.json file example:
SHA256SUM and SHA256SUM.sig files are used for cryptographically verifying the contents of this directory.
For more information on *.sign, bsrKey.pub, wrappedBsrKey, and wrappedPrivKey files, refer to Validating the integrity of session recordings.
BSR Connection folder
connection-recording.meta file example:
connection-recording-summary.json file example:
*.data files are binary files containing all data transmitted during a session.
SHA256SUM and SHA256SUM.sig files are used for cryptographically verifying the contents of this directory.
BSR Channel folder
channel-recording.meta file example:
channel-recording-summary.json file example:
*.data files are binary files containing all data transmitted during a session.
SHA256SUM and SHA256SUM.sig files are used for cryptographically verifying the contents of this directory.
For more information, refer to the overview of configuring session recording.