Features and Benefits
Advanced authentication and authorization
Take the Next Step
4-eyes authorization
To avoid accidental misconfiguration and other human errors, SCB supports the 4-eyes authorization principle. This is achieved by requiring an authorizer to allow the administrators to access the server. The authorizer also has the possibility to monitor the work of the administrator real-time, just like they were watching the same screen.
The 4-eyes principle can be used for the auditors as well: SCB can use multiple keys to encrypt the audit trails. In this case, multiple decryption keys are needed to replay the audit trails, so a single auditor on his own cannot access every information about your systems.
Gateway authentication
SCB can require the users to perform gateway authentication, meaning that the user must authenticate on SCB as well. This additional authentication can be performed on the SCB web interface, so it provides a protocol-independent, outband authentication method. That way the connections can be authenticated to the central authentication database (for example LDAP or RADIUS), even if the protocol itself does not support authentication databases. Also, connections using general usernames (for example root, Administrator, and so on) can be connected to real user accounts.
Usermapping
For SSH and RDP connections, usermapping policies can be defined. A usermapping policy describes who can use a specific username to access the remote server: only members of the specified local or LDAP usergroups (for example administrators) can use the specified username (for example root) on the server.
Detailed access control – who, when, how, from where can access which server
SCB allows you to define connections: access to a server is possible only from the listed client IP addresses. This can be narrowed by limiting various parameters of the connection, for example, the time when the server can be accessed, the usernames and the authentication method used in SSH, or the type of channels permitted in SSH or RDP connections. Controlling the authentication means that SCB can enforce the use of strong authentication methods (public key), and also verify the public key of the users. Also, SCB can authenticate the users to an external user directory. This authentication is completely independent from the authentication that the user performs on the remote server.
The following parameters can be controlled:
- The IP address of the client machines allowed to access the server.
- The group of administrators permitted to access the server (based on username black- and whitelists or LDAP groups) when using SSH or RDP6 with Network Layer Authentication.
- In addition to the authentication performed on the remote server, it is also possible to require an additional, outband authentication on the SCB web interface. Authorization can be based on this outband authentication as well.
- The authentication method (for example, password, public-key, certificate) required to access the server using SSH.
- The time period when the server can be accessed (for example, only during working hours).
- The type of the SSH or RDP channel permitted to the server (for example, SSH terminal or port forward, RDP file sharing, and so on).
Password management
Credential Stores offer a way to store user credentials (for example, passwords, private keys, certificates) and use them to login to the target server, without the user having access to the credentials. That way, the users only have to authenticate on SCB with their usual password (that can be stored locally on SCB or in your central LDAP database). If the user is allowed to access the target server, SCB automatically logs in using the data from the Credential Store.
In addition to storing credentials locally, SCB integrates smoothly to Enterprise Random Password Manager (ERPM), Lieberman Software's privileged identity management solution. That way, the passwords of the target servers can be managed centrally using the ERPM, while SCB ensures that the protected servers can be accessed only via SCB — since the users do not know the passwords required for direct access.
