This section describes means or actions that that can or should be taken to secure (“harden”) the database.

This document covers the following:

• Using the Linux Group Concept

• Securing Administration of Adabas Role-Based Security

• Preventing Loss of Administration Privileges

• Securing PUBLIC Access Privileges

• Securing Configuration Files

• Securing the Audit Trail Log File

---

Using the Linux Group Concept

If the Adabas users belong to different Linux groups, you can restrict the Adabas access to databases assigned to this group.

Example:

Assume you have two Linux groups called Production and Test. There are users belonging to the group Production, who should have access only to the production databases, and there are users belonging to the group Test, who should have access only to the test databases. Assume you have the following users for starting the database:

• dbaprod belongs to the group Production and should start the production databases

• dbatest belongs to the group Test and should start the test databases

The following is necessary to restrict the Adabas access to users of the group to which the databases belong:

• You must use two different NET_WORK_IDs, even if you are not using Net-Work. Because Adabas does not know if a Net-Work server will be started later, Adabas creates a shared memory section common with Net-Work, a GDT (global database table). The permission for GDT access is restricted to the group to which the Adabas nucleus belongs. Therefore, starting a nucleus fails if the same GDT is accessed as used by another nucleus belonging to a different group.

  You can use different GDTs if you start the nucleus with a different NET_WORK_ID because a separate GDT is created for each NET_WORK_ID. NET_WORK_ID is an environment variable, which must be set when the Adabas nucleus is started - two NET_WORK_IDs are considered to be equal if the first character is equal. If the environment variable NET_WORK_ID is not set, an empty NET_WORK_ID is used.

  In this example, you could start the production databases after setting NET_WORK_ID to P, and the test databases after setting NET_WORK_ID to T.

• The nucleus must be started with the parameter ADABAS_ACCESS=GROUP. Assume that you start in this example the Production databases with ADABAS_ACCESS=GROUP, but the Test databases with ADABAS=ACCESS=ALL (or without the parameter ADABAS_ACCESS). Then only the Production users can access the production databases, but all users can access the test databases.

Securing Administration of Adabas Role-Based Security

This section describes how to secure access to the ADARBA utility, which provides the functionality to administer the security definitions.

By default, all users with the PUBLIC role have access to and can execute the ADARBA utility.

The example below shows how access to ADARBA can be restricted by:

• Creating a security administrator role;

• Granting the role permission to execute the utility;

• Creating a user credential that is to be assigned the security administrator role;

• Granting the user security administrator role; and

• Revoking the permission to execute the utility from the role PUBLIC.

> adarba 
> adarba: dbid=nnn
 
> adarba: create,role= security_administrator
> adarba: grant,operation=ada.uti.rba,to,role= security_administrator

> adarba: create,user=dbasec_userid
> adarba: grant,role= security_administrator,to,user=dbasec_userid

> adarba: revoke,operation=ada.uti.rba,from,role=PUBLIC

In this example, the following security definitions are created or modified:

• Created:

  • Role: security_administrator

  • User Credentials: dbasec_userid

  • Permission to Operation: ada.uti.rba

• Modified:

  • Role: PUBLIC

  • Permission to Operation: ada.uti.rba

Notes:

1. The role name and the user credentials are site-specific.
2. The credentials used for authorization must also be defined for authentication.

Preventing Loss of Administration Privileges

Lock Out Scenario

A 'lock out' scenario is possible. You must take appropriate action to prevent the 'loss of administration permissions'.

There is no recovery from a loss of administration privilege or a lock out scenario. This is a scenario in which no individual has access to the administration utilities, and the administration privilege for the security definitions has been lost.

The situation can be avoided by ensuring access to the following administration utilities.

• ADABCK

• ADADBM

• ADARBA

Recommended procedures to prevent a lock out scenario are to:

• Create more than one administration role;

• Assign access privileges to these administration roles;

• Assign the administration roles to more than one user credential.

In order to prevent an accidental loss of privileges, it is important to understand the processing logic behind the DROP function in ADARBA.

Drop Role Function

The DROP ROLE function in ADARBA deletes the following security definitions:

• All references to the ROLE definition are deleted:

  • The permissions granted to the ROLE are revoked;

  • The ROLE assignments to all USERS are revoked.

• The ROLE definition is deleted.

The function performs a cascading delete without issuing a warning message.

A loss of privileges scenario can occur if the administrator role is dropped, and no other role has access to the administration utilities.

Securing PUBLIC Access Privileges

You should review and restrict access privileges assigned to the role PUBLIC. This includes the roles assigned to the PUBLIC user, and the privileges assigned to the PUBLIC role.

PUBLIC access is provided when the RBAC system file has not been loaded, even though security is enabled.

You should take the following actions to secure access privileges assigned to PUBLIC:

• Ensure that the RBAC system file is loaded;

• Review the roles that are assigned to the PUBLIC user;

• Review the privileges that are granted to the PUBLIC role.

Securing Configuration Files

This section describes how to secure the configuration files used to configure authorization for Adabas utilities.

File	Description
adaauth.ini	Configuration of Authorization for Adabas Utilities
adaaudit.ini	Configuration of Audit Trail

To secure the configuration files, please ensure the following:

• READ-ACCESS
  All users, which execute an Adabas utility, must be able to read these files.

• WRITE-ACCESS
  Only the administrator of a file should have write access to the file.

The location of the configuration files is platform-dependent and is described in the section Configuration of Authorization for Adabas Utilities of the Extended Operation documentation.

Securing the Audit Trail Log File

This section describes how to secure the audit trail log file used by the Authorization for Adabas utilities.

File	Description
adaaudit.log	Audit Trail log file for Authorization for Utilities

To secure the audit trail log file, please ensure the following:

• READ/WRITE-ACCESS
  All users, which execute an Adabas utility, must be able to write to the audit trail log file.

The location of the audit trail log file is set via the LOG_FILE option in the adaaudit.ini configuration file and is described in the section Configuration of Authorization for Adabas Utilities of the Extended Operation documentation.