Enforce strict control and accountability

SA provides strong security and accountability, as described in the following sections.

• Stronger controls and accountability
• Read-only, digitally signed audit trails
• Signed SHA checksums for packages in the software repository
• Role-based authorization
• Audit logging of user activities

Stronger controls and accountability

SA improves security throughout a data center using strong controls and accountability. Using SA, security architects or IT management can control who can perform a particular task on a server. Task control is fine-grained; for example, an administrator can grant comprehensive read-only access with change privileges restricted to patch installation and a specific list of SA Global Shell commands.

SA automatically creates a tamper-proof audit trail that captures details such as which SA user performed a particular management task on a server at a given time. SA’s granular role-based access control system is designed around the interaction between users, groups of servers, management tasks, and the SA data model that describes the environment. One immediate security benefit of this powerful access control model is that fewer people need administrator accounts on servers. Instead, they can be given SA user accounts to perform only the management tasks they must perform, a security best practice.

Everyone who logs into SA must have a unique SA user name and password. Administrators can create user names within SA or import them from an external LDAP system. For example, if a company has an existing Microsoft Active Directory implementation, they can synchronize with the directory server to reuse the user accounts that already exist.

When creating user accounts, SA users are assigned to SA groups. Groups are a convenient way of describing what servers users can operate on and what management tasks they can perform on those servers.

Several predefined groups are provided by default in SA. The permissions for these groups can be customized as necessary, and you can create new groups with customized permission levels to satisfy the requirements of any organization. The permissions that you specify for a user group determine what the group's member can do with SA. Action permissions specify what actions users can perform; resource permissions specify which objects (typically servers) users can perform these actions on. The SA graphical user interface, called the SA Client, as well as the Global Shell interface, are both bound by these task rules, so that users will be able to see and perform only the tasks they are authorized by security administrators to perform.

Security administrators can also control the policy-based software installation environment, which automates the process of installing software and configuring applications on a server. Designated users can model an organization’s application software structure in a folder hierarchy, and set up fine-grained permissions for creation, viewing, modification, and execution. This model provides a clear delineation of specialization, where subject matter experts can implement and adjust policies, and system administrators can manage the servers in their environment by applying software policies to servers.

See User and user group setup and security user groups and permissions.

Read-only, digitally signed audit trails

In addition to careful controls of which actions SA users can perform on managed servers, SA automatically maintains a detailed audit trail of events performed by SA users. The audit trail logs details such as the user, the event, the servers acted on, the time the task was performed, the total elapsed time, and any error conditions associated with the task.

The audit trail itself is stored as read-only, digitally signed data in an Oracle database to prevent users from tampering with the data. This audit trail data helps organizations establish strict accountability in their environment—an increasingly urgent topic in the age of Sarbanes-Oxley Act, the Gramm-Leach-Bliley Act (GLB Act), and the Health Information Portability and Accountability Act (HIPAA). Users can select how long the audit trail is stored (the default period is six months), and they can easily create a data warehouse that stores the audit trail (and other SA data) for longer periods of time.

The Audit Trail is housed in the AUDIT_DATA tablespace, and contains the following tables:

AUDIT_OBJTYPE_ATTR

AUDIT_OBJECT_TYPES

AUDIT_OBJECT_COLLECTORS

AUDIT_OBJECT_ATTR

AUDIT_FEATURES

AUDIT_EVENT_OBJECTS

AUDIT_EVENT_DETAIL_VALUES

AUDIT_EVENT_DETAILS

AUDIT_EVENTS

AUDIT_DATA_TYPES

AUDIT_DATA_OBJECTS

AUDIT_DATAOBJ_VALUES

AUDIT_CONFIG_PARAMS

AUDIT_COMPONENTS

AUDIT_ACTIONS

Signed SHA checksums for packages in the software repository

When SA users upload software to the Software Repository, SA automatically computes an RSA-with-SHA1 signature for the package. To generate the signature, SA uses a combination of the SHA1 checksum calculation, the software package contents, and an internal private RSA key that is known only to the Software Repository. The private key is not modifiable. This prevents users from tampering with the software in the Software Repository. The package and its corresponding digital signature are stored locally at the Software Repository. When SA installs software on a managed server, it validates the RSA key and the SHA1 signature of the software before permitting the download. This helps ensure that the software installed by SA is exactly the same software uploaded into the Software Repository.

Role-based authorization

• SA enforces a very granular system of role-based access controls. Security administrators can set up authorization on the following parameters:
• A facility: A facility is a collection of servers that are managed by a single SA core. A facility can be all or part of a data center, server room, or computer lab. A facility is the highest level of abstraction in the granular role-based permissioning model.
• A group of servers (by customer): Servers are grouped by customers, which can represent any arbitrary group of servers in a single data center. The group might represent a paying customer, a cost center, or servers running a particular business application such as Siebel or the Expense Report application. The software packages managed by SA each belong to a particular customer, although they may also belong to a special account called Customer Independent, which means the software is available to provision on any customer's server (for example, patches belong to the customer account Customer Independent). This allows security administrators to control the exact set of software packages that may be applied on a particular group of servers.
• A dynamic group of servers (rules-based): Security administrators can also create server groups based on dynamic rules evaluation (from simple to complex) and grant permissions to all servers belonging to the group. For example, a security administrator can group managed servers that are running the Linux operating system and reside in a particular IP address space, and then assign which SA user groups are authorized to perform management tasks on this server group.
• Software policy modeling and distribution: Software policy modeling provides a powerful mechanism to model software using a folder model. Folders provide the ability to define security permissions to control access to their contents across user groups. You can set folder permissions to determine which user groups can view, use, and modify items within a folder.

Audit logging of user activities

SA stores audit trails centrally in the Model Repository, where each entry is digitally signed. SA is designed from the ground up with strong cryptographic controls that prevent any undetectable modification to audit logs. Because audit logs are stored centrally, they cannot be deleted from managed servers. In fact, the entire security design of SA is defensive, based on the assumption that an individual managed server being compromised must not endanger the security of the whole system.