| |
|
|
BoKS Access Control for Servers — How It Works
Administrators, or DBAs, who need to login to the operating system of your company's servers, are controlled by FoxT Clients installed on the user's workstation and all servers. Servers are placed into security domains called Host Groups, and access policies connect users to these groups.
The FoxT Client takes over all authentication and access requests, and diverts them to the BoKS policy server infrastructure. The granular access policy, which has been implemented in the central BoKS database, controls WHO can connect to WHICH server WHEN and HOW.
Here's an example: Based on the user's role, and the administration group the server resides in, user MCALL is required to login to the application server using a secure communications method using Secure SHell (SSH). A positive control decision is made BEFORE the connection request is made to the server, and a network session is connected to the server. This denies hacking and spoofing attack possibilities. The server access is logged centrally in the BoKS Manager log services.
BoKS also controls privileged accounts. Using BoKS, separate access policies are applied if the user wishes to become a privileged account, such as a DBA management account. Here, the central access control policy on the BoKS Manager denies the ability to login directly as the anonymous DBA user. The assumption of this "delegated account" is also tracked in central logs. After correctly assuming using the DBA identity, the administrator can then login to the database server on another part of the network. Again a security policy check is made by the BoKS Manager BEFORE the network session is established.
The BoKS identity of the user is sustained throughout the security domain, and if allowed by policy, the user is Single Signed On (SSO) to each machine.
|
|
|
