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 UNIX Group Concept

• Securing Configuration Files

• Securing the Audit Trail Log File

---

Using the UNIX Group Concept

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

Example:

Assume you have two UNIX 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 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
adarbac.ini	Role-Based Access Control Definitions

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.