This section describes means or actions that that can or should be taken to secure (“harden”) the database.
This document covers the following:
If the Adabas users belong to different Linux groups, you can restrict the Adabas access to databases assigned to this group.
Note:
This feature is only available for Linux, not for Windows platforms.
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.
Note:
If you are using Net-Work, it is also necessary to start
different Net-Work servers for different groups. You must take care to ensure
that it is not possible for users to access databases via Net-Work for which
they have no permissions.
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:
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.
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.
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.
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.