Chatee ahora con Soporte
Chat con el soporte

One Identity Safeguard for Privileged Sessions 7.5.1 - Administration Guide

Preface Introduction The concepts of One Identity Safeguard for Privileged Sessions (SPS)
The philosophy of One Identity Safeguard for Privileged Sessions (SPS) Policies Credential Stores Plugin framework Indexing Supported protocols and client applications Modes of operation Connecting to a server through One Identity Safeguard for Privileged Sessions (SPS) Archive and backup concepts Maximizing the scope of auditing IPv6 in One Identity Safeguard for Privileged Sessions (SPS) SSH host keys Authenticating clients using public-key authentication in SSH The gateway authentication process Four-eyes authorization Network interfaces High Availability support in One Identity Safeguard for Privileged Sessions (SPS) Versions and releases of One Identity Safeguard for Privileged Sessions (SPS) Accessing and configuring One Identity Safeguard for Privileged Sessions (SPS)
Cloud deployment considerations The Welcome Wizard and the first login Basic settings
Supported web browsers The structure of the web interface Network settings Configuring date and time System logging, SNMP and e-mail alerts Configuring system monitoring on SPS Data and configuration backups Archiving Cleaning up audit data Using plugins Forwarding data to third-party systems Starling integration
User management and access control
Login settings Managing One Identity Safeguard for Privileged Sessions (SPS) users locally Setting password policies for local users Managing local user groups Managing One Identity Safeguard for Privileged Sessions (SPS) users from an LDAP database Authenticating users to a RADIUS server Authenticating users with X.509 certificates Authenticating users with SAML2 Managing user rights and usergroups Creating rules for restricting access to search audit data Displaying the privileges of users and user groups Listing and searching configuration changes
Managing One Identity Safeguard for Privileged Sessions (SPS)
Controlling One Identity Safeguard for Privileged Sessions (SPS): reboot, shutdown Managing One Identity Safeguard for Privileged Sessions (SPS) clusters Managing a High Availability One Identity Safeguard for Privileged Sessions (SPS) cluster Upgrading One Identity Safeguard for Privileged Sessions (SPS) Managing the One Identity Safeguard for Privileged Sessions (SPS) license Accessing the One Identity Safeguard for Privileged Sessions (SPS) console Sealed mode Out-of-band management of One Identity Safeguard for Privileged Sessions (SPS) Managing the certificates used on One Identity Safeguard for Privileged Sessions (SPS)
General connection settings HTTP-specific settings ICA-specific settings MSSQL-specific settings RDP-specific settings SSH-specific settings Using Sudo with SPS Telnet-specific settings VMware Horizon View connections VNC-specific settings Indexing audit trails Using the Search interface Advanced authentication and authorization techniques Reports The One Identity Safeguard for Privileged Sessions (SPS) REST API One Identity Safeguard for Privileged Sessions (SPS) scenarios Troubleshooting One Identity Safeguard for Privileged Sessions (SPS)
Network troubleshooting Gathering data about system problems Viewing logs on One Identity Safeguard for Privileged Sessions (SPS) Changing log verbosity level of One Identity Safeguard for Privileged Sessions (SPS) Collecting logs and system information for error reporting Collecting logs and system information of the boot process for error reporting Support hotfixes Status history and statistics Troubleshooting a One Identity Safeguard for Privileged Sessions (SPS) cluster Understanding One Identity Safeguard for Privileged Sessions (SPS) RAID status Restoring One Identity Safeguard for Privileged Sessions (SPS) configuration and data VNC is not working with TLS Configuring the IPMI from the BIOS after losing IPMI password Incomplete TSA response received Using UPN usernames in audited SSH connections
Using SPS with SPP Configuring external devices Using SCP with agent-forwarding Security checklist for configuring One Identity Safeguard for Privileged Sessions (SPS) Jumplists for in-product help Configuring SPS to use an LDAP backend Glossary

Creating an archive policy using NFS

The Move data to a remote server using NFS archive method connects to a shared directory of the target server with the Network File Share protocol.

NOTE: Backup and archive policies only work with existing shares and subdirectories.

If a server has a share at, for example, archive and that directory is empty, when the user configures archive/scb1 (or similar) as a backup/archive share, it will fail.

The version of NFS used is automatically detected. All versions of NFS, up to and including NFS version 4 protocol, are supported.

  1. Navigate to Policies > Backup & Archive and click in the Archive policies section to create a new archive policy.

  2. Enter a name for the archive policy.

  3. Enter the time when the archive process should start into the Start time field in HH:MM format (for example 23:00).

    You can add the start time for additional archive processes.

    		 Caution:

    When specifying an additional start time, ensure that the previous archive process finishes before the new archive process starts.

  4. To archive the data collected on more than once a day, click . You can schedule multiple archive times.

    NOTE: In case an archive process is not finished before the next one would start, the next archive process waits for the previous process to be completed.

  1. Fill the Delete data from SPS after field. Data older than this value is archived to the external server.

    NOTE: The archived data is deleted from SPS.

  1. Select Move data to a remote server using NFS from the Before deleting data from PSM radio buttons.

    Figure 73: Policies > Backup & Archive —Configuring archiving

  2. Enter the domain name of the remote server into the Target server field.

  3. Enter the name of the NFS export into the Export field.

    SPS saves all data into this directory, automatically creating the subdirectories.

  4. The remote server must also be configured to accept connections from SPS.

    Add a line that corresponds to the settings of SPS to the /etc/exports file of the remote server. This line should contain the following parameters:

    • The path to the archive directory as set in the Export field of the SPS archive policy.

    • The IP address of the SPS interface that is used to access the remote server. For more information on the network interfaces of SPS, see Network settings.

      Use an IPv4 address.

    • The following parameters: (rw,no_root_squash,sync).

    Example: Configuring NFS on the remote server

    For example, if SPS connects the remote server from the 192.168.1.15 IP address and the data is saved into the /var/backups/SPS directory, add the following line to the /etc/exports file:

    /var/backups/SPS 192.168.1.15(rw,no_root_squash,sync)

    		 Caution:

    To enable non-root users to access the directories and subdirectories on the NFS server through SPS, assign them read permissions. Non-root users without a read permission cannot access the directories and subdirectories on the NFS server.

  5. On the remote server, execute the following command:

    exportfs -a

    Verify that the rpc portmapper and rpc.statd applications are running.

  1. SPS organizes the audit trails into directories based on the date or the protocol. The subdirectories are created directly into the archive directory. Select one of the following directory structures:

    • Protocol/Connection/Archive Date/

    • Archive Date/Connection/Protocol/

    • Connection Date/Protocol/Connection/

    • Archive Date/

    • Connection Date/

    For example, the Protocol/Connection/Archive Date template will have create subdirectories for the audited protocols (that is, ssh, rdp, telnet, vnc), for the name of the connection policy, and finally, for the date (YEAR-MONTH-DAY in YYYY-MM-DD format).

    NOTE: Connection Date refers to the time the connection started, while Archive Date to the time it was archived. The difference between the two dates depends on the retention time set for the archiving policy.

  2. When your SPS instance is a node in a cluster, select Include the Cluster Node ID in the path. This ensures that the node ID is included in the path of the relevant directory, which is required to prevent cluster nodes from archiving data to the same location. Archiving data to the same location would result in data loss. In addition, including the node ID in the directory name also enables easy identification.

    		 Caution:

    Hazard of data loss

    If you configured configuration synchronization across your cluster nodes, unchecking Include the Cluster Node ID in the path when your SPS is a node in a cluster can result in data loss.

  3. To receive e-mail notifications, select the Send notification on errors only or the Send notification on all events option. Notifications are sent to the administrator e-mail address set on the Management tab, and include the list of the files that were backed up.

    NOTE: This e-mail notification is different from the one set on the Alerting & Monitoring tab. This notification is sent to the administrator's e-mail address, while the alerts are sent to the alert e-mail address (see Configuring system monitoring on SPS).

  4. Click Commit.

  5. To assign the archive policy to the connection you want to archive, see Archiving the collected data.

Archiving the collected data

To configure data archiving, assign an archive policy to the connection.

Prerequisites

You have to configure an archive policy before starting this procedure. For details, see Archiving.

To assign an archive policy to the connection

  1. Navigate to the connection (for example, to Traffic Controls > SSH > Connections).

  2. Select the connection.

  3. Select the archive policy you want to use in the Archive policy field.

  4. Click .

  5. Optional: To start the archiving process immediately, click Archive now. This functionality works only after a corresponding policy has been configured.

Cleaning up audit data

One Identity Safeguard for Privileged Sessions (SPS) can automatically archive audit trails older than a specified retention time. However, the .zat file and the metadata of the corresponding connections are not deleted from the SPS connection database. Deleting the stored data of old connections decreases the size of the database, making searches faster, and may also be required by certain policies or regulations.

In an audit data cleanup policy, you can specify the period after which the zat file and the metadata is deleted. You can also provide a lucene-like query, with which you can specify which sessions you want to delete. For example, using the query, you can create a filter for a specific protocol.

For more information, see Configuring cleanup policies.

Configuring cleanup policies

In an audit data cleanup policy, you can specify the period after which the zat file and the metadata is deleted. You can also provide a lucene-like query, with which you can specify which sessions you want to delete. For example, using the query, you can create a filter for a specific protocol.

To add a new audit data cleanup policy

  1. Navigate to Policies > Audit Data Cleanup Policies.

  2. Select Add policy.

    Figure 74: Policies > Audit Data Cleanup Policies — Configuring an audit data cleanup policy

  3. In Policy name, specify a unique name for the audit data cleanup policy.

  4. In the Audit data older than field, enter how long (in days) SPS must keep the zat file and the metadata. For example, if you specify 365, SPS deletes the audit data of connections older than a year.

    The accepted value range is 30-100,000 days.

    NOTE: The database cleanup occurs once a day at 22:01 PM.

    NOTE: Since the database cleanup happens once a day at 22:01 PM, if you specify the same retention time for an archive policy, for example, 90 days in the Audit data retention period field, ensure that the archiving is set to start before 22:01 PM.

  5. In Audit data query, which is a lucene-like query, specify to which audit data the cleanup policy applies.

    To fill this query, specify, for example, a field and the related term. Optionally, you may add a boolean operator and specify another field and related term. For example, to specify the audit data of the SSH protocol and the ssh-connection-policy connection policy to be cleaned up, in Audit data query, type protocol:SSH AND recording.connection_policy:ssh-connection-policy

  6. To save your changes, click Add policy.

  7. Optionally, repeat the steps to create new audit data cleanup policies for other protocols and connections.

Expected outcome

Every day, SPS deletes the zat file and the metadata of connections that are older than the given cleanup time from the connection database.

Preview the effect of the cleanup policy

The preview chart of a cleanup policy predicts how the respective cleanup policy will affect your audit data.

Preview charts are available in the following places:

  • Audit Data Cleanup Policies page.

    You can preview one or more cleanup policies at the same time in one chart.

  • Add new audit data cleanup policy and the Edit cleanup policy side sheets.

    You can preview the actual policy that you are creating or editing.

  • By clicking the chart icons in the policy lists.

    You can preview the respective policy.

Reading the charts

  • The charts display data in monthly increments.

  • The vertical line or lines represent the end of the data retention period for the respective policy or policies.

  • To the right of the vertical line, you can see the sessions which are not scheduled for deletion yet.

  • To the left of the vertical line, you can see those sessions which are to be deleted by the next cleanup event.

  • Sessions matching this query (green) represents the sessions which are affected by the respective cleanup policy.

  • Sessions not included in this cleanup policy (blue) represents the sessions which are not affected by the respective cleanup policy.

Documentos relacionados

The document was helpful.

Seleccionar calificación

I easily found the information I needed.

Seleccionar calificación