Adabas provides the following facilities to prevent unauthorized access and updates to Adabas database files:
Security system user IDs are the sign-on user IDs provided by security software such as RACF, ACF2, or Top Secret. Adabas support for security system user IDs allows you to track user activity in Adabas databases. Support for security system user IDs is provided in z/OS and z/VSE environments only.
Security system user IDs are supported in Adabas system fields. command logs, some operator commands, operator command output displays, PRILOG displays, Adabas utilities, and Adabas session statistics. A SECUID ADARUN parameter is provided to allow you to specify the requirement level of security system user IDs for a database. This section describes security system user ID support in Adabas in more detail.
In CICS environments only, if you want your security system user IDs to be stored in Adabas user queue elements (making them available for display and review as well as preventing response code 200, ADARSP200, subcode 21 when ADARUN SECUID=REQUIRE is in effect for Adabas), you must code the SAF parameter as YES. This is only required in CICS environments; in other environments, the security system user IDs are automatically stored.
For more information, read Step 6. Prepare the CICS Link Globals Table -- CICSGBL and SAF: Adabas Security Interface Flag.
Use the SECUID ADARUN parameter to specify the requirement level of security system user IDs for a database. You can indicate how Adabas handles calls from users without a security system user ID or with a security system user ID that changed during the Adabas session. For complete information about the SECUID ADARUN parameter, read SECUID Parameter: Security System User ID Requirement Level.
The SECUID operator command can be used to alter the setting of the ADARUN SECUID parameter while the nucleus is active. This operator command is valid for use both on the console and in the ADADBS OPERCOM utility function. For more information about the SECUID operator command, read SECUID Command; for more information about use of the SECUID operator command in the ADADBS OPERCOM utility function, read about the SECUID operator command.
You can use the STOPSU operator command to stop and delete a user with a specified security user ID. Any open transactions of the stopped user are backed out. No response code is issued; the next time the stopped user issues a command, a new user queue element (UQE) is created. For more information about the STOPSU operator command, read STOPSU Command; for more information about use of the STOPSU operator command in the ADADBS OPERCOM utility function, read about the STOPSU operator command.
You can use the STOPSUR operator command to stop a user with a specified security user ID, but the stopped user is not immediately deleted. Any open transactions of the stopped user are backed out. The stopped user is only deleted after he or she has issued a subsequent command and response code 22 (ADARSP22), subcode 54 has been issued in response to that command. This response code-subcode combination is used to notify users that their Adabas activity has been halted and their user session resources have been freed. Only after the response code-subcode combination has been issued is the user queue element (UQE) of the stopped user deleted. For more information about the STOPSUR operator command, read STOPSUR Command; for more information about use of the STOPSUR operator command in the ADADBS OPERCOM utility function, read about the STOPSUR operator command.
Security system user IDs (SSIDs) can be stored in system fields in an Adabas file. The value "SECUID" can be used in field definitions that include the SY field option. This SY=SECUID value indicates that the system field contains an SSID. For complete information read System Fields and SY: System Field.
The SECUID field is included in Adabas command logs (CLOGs) and protection logs (PLOGs).
Output reports from various operator commands (such as the DPARM, DCQ, DFILES, DUQ, or DHQA operator commands) include the current SECUID setting of the user's actual security system user ID.
The PRILOG print program displays the SECUID when CLOGLAYOUT=8 is used. All of the reports produced by the PRILOG print program include this field.
The following Adabas utilities support security system user IDs:
The security system user ID will appear in the extract file and the primary output file produced by the ADACDC utility. If the security system user ID is not known, blanks are stored in the extract file. For more information, read ADACDC Utility: Changed-Data Capture.
The ADASEL utility supports security system user IDs in three places in the SELECT parameter of the ADASEL utility:
The SECUID parameter can be used to specify a security system user ID or range of security system user IDs in the value-criterion of the WITH clause or the IF statement.
The SECUID [HEX] parameter can be used in the DISPLAY instruction to indicate that the security system user ID of the user who added, updated, or deleted the record should be displayed.
The security system user ID appears in the output log data set if the EXPANDED keyword is specified in the output instruction of the ADASEL utility. If the security system user ID is not known, "UNKNOWN" displays.
For more information, read ADASEL Utility: Select Protection Data.
The ADAWRK utility includes a SECUID parameter that you can use to specify up to 24 security system user IDs (SECUIDs) in character format. Each SECUID must be one to eight bytes long. When SECUIDs are specified, only Work part 1 autorestart area records for those SECUIDs are processed by the ADAWRK utility and printed on its reports. For more information, read ADAWRK Utility: Work Area Recovery Reports.
The high usage session statistics produced for a nucleus session include the user's security system user ID, if it is known. For more information, read High Usage Session Statistics.
Data encryption is an integral feature of Adabas and requires no options or extra modules. Data may be enciphered before being placed in the database.
The user must provide the cipher key at the time records are stored. This key is not stored and must be available to request or decipher the data. This minimizes the chances of data being compromised by unauthorized access to the system.
To retain maximum control over cipher codes, an Adabas user exit program can be created to insert the currently valid cipher code into user applications; this removes the need to make the codes known to users, and protects the file from corruption that can occur by adding data that is encrypted with the wrong cipher code.
Also available as an integral feature of Adabas that requires no options or special modules is the multiclient file.
A single Adabas physical file defined as multiclient can store records for multiple users or groups of users. The multiclient feature divides the physical file into multiple logical files by attaching an internal owner ID to each record.
The owner ID is assigned to a user ID. A user ID can have only one owner ID, but an owner ID can belong to more than one user. Each user can access only the subset of records that is associated with the user's owner ID.
Note:
For any installed external security package such as RACF or
CA-Top Secret, a user is still identified by either Natural ETID or LOGON
ID.
All database requests to multiclient files are handled by the Adabas nucleus.
Access/update control is available only with Adabas Security and the related security utility ADASCR that defines and controls Adabas Security functions.
Adabas Security provides two levels of protection: access/update and value.
Note:
Adabas Security documentation is available upon request. For
complete information about Adabas Security, contact your Software AG
representative.
Access-/update-level protection applies a basic level of security on a file-by-file basis. Access/update protection can be defined for some files and not for others. It restricts use of a file or field within the file to those having an appropriate access/update profile definition and a password specified by the user of the file.
Access/update permission values ranging from 0 to 14 are defined for each user and attached to that user's password, and each protected file (and selected field or fields, if desired) has equivalent access/update threshold protection values of the same range. Only a user whose permission value equals or is greater than the protection level of the specified file (and, when applicable, field) is permitted to perform that operation type (access or update) on the file or field. An access/update permission level of 0 only allows access/update of unprotected files or fields with protection level 0 or no defined protection password.
Value-level protection applies restrictions on the type and range of values that can be accessed or updated in specific fields. The restrictions are applied according to user password (files with fields using value-level protection must be password-protected). They can be for specific values or for value ranges, and can be either accept or reject criteria.
The System Authorization Facility (SAF) is used by z/OS and compatible sites to provide rigorous control of the resources available to a user or group of users. Compatible security packages such as IBM's RACF and Computer Associates' ACF2 or Top Secret allow the system administrator
to maintain user identification credentials such as user ID and password; and
to establish profiles determining the data sets, storage volumes, transactions, and reports available to a user.
Generally, a security package allows the system administrator to authorize a user's access to system resources. The security package then monitors all users and their resource usage to ensure that no unauthorized access or change occurs. Attempts by unauthorized users to use either the system or specific system resources are recorded and reported.
A user profile, which can be for a single user or a group of users, defines which system hardware and software resources a user is allowed to use. A resource profile defines access/update privileges for one or more devices, volumes, and/or programs (resources that must be used together to perform certain functions can be defined together in the same profile).
When a user logs on to the system, the security package uses the user's logon ID to identify that user's profile. Each time the user attempts to perform a task or access information, the security package uses information in its resource profiles to allow or deny access. Using the profile concept, the security package expands the single point of authorization-the logon ID-to provide extensive control over all system resources.
The resulting security repository and the infrastructure to administer it represent a significant investment. At the same time, the volume of critical information held by a business is constantly growing, as is the number of users referencing the data. The challenge of controlling these ever-increasing accesses requires a solution that is flexible, easy to implement and, above all, one that safeguards the company's investment.
Adabas SAF Security enhances the scope of SAF-based security packages by integrating Adabas resources into the central security repository. Adabas SAF Security enables:
a single control and audit system for all resources;
industry-standard protection of Adabas data; and
maximized return on investment in the security repository.
Adabas SAF Security operation can be tailored on a nucleus-by-nucleus basis, allowing great flexibility in its implementation. It comprises:
a server operating in each secured Adabas address space;
an online administration and monitoring system, an application written in Natural and accessed from either the demo or full version of Adabas Online System (AOS); and
a plug-in routine PINSAF that interfaces with the Adabas error handling facility. It is activated automatically at initialization to aid problem diagnosis.
Adabas SAF Security allows you to protect the following Adabas resources:
| Resource | Protection |
|---|---|
| Adabas Nucleus |
|
| Adabas Utilities |
|
| Adabas Files |
|
| Production Environment Data | Controls the users allowed to operate in a production or test environment. Such cross-level checking could be used, for example, to prevent damage by an application program inadvertently cataloged against the wrong database ID. |
| Transaction Data | Controls the users allowed to store or retrieve ET data. |
| File Passwords and Cipher Codes | Dynamically applies passwords and codes held in the security repository or supplied by a user exit. This eliminates the need for the application to manage security data and removes the requirement to transmit sensitive information from the client to the database. |
| Administration Services |
Controls the users allowed to perform online administration of the Adabas environment. The following administration services can be protected in this way:
|
Refer to the Adabas SAF Security documentation for more information regarding the protection of the above resources.
In the following figure, all traffic between clients and the Adabas nucleus is controlled by the Adabas router (ADASVC). The Adabas router extracts the user’s logon ID from the user’s ACEE (a system representation of the user’s identification) and makes it available for Adabas SAF Security (ADASAF) to perform security checks using the installed external security package.
The central security logon ID is used to log on to the system. Through the operating system or TP monitor, the installed external security package package performs authentication of the logon ID. For calls from a remote workstation or non-IBM platform, a remote logon procedure is used to give the logon ID to ADASAF.
Full, flexible control is maintained with a one user : one definition approach while previous investments in host-based security systems and infrastructures are enhanced, not discarded.
The demo version of Adabas Online System (AOS) distributed with Adabas includes a security facility for restricting access to the Adabas online facilities. AOS Security requires Natural Security as a prerequisite. See the Adabas Security documentation for more information.
The Natural Security system provides extensive security for Adabas/Natural users. It is required for AOS Security and recommended for other features of Adabas. See the Natural Security documentation for more information.
Adabas SAF Security or ADASAF is one of several Software AG security products that enhance the effectiveness of the SAF central security repository:
| Product | Protects |
|---|---|
| Adabas SAF Security | Adabas |
| Entire Net-Work SAF Security | Entire Net-Work version 5.6 and above |
| EntireX Security | EntireX, Entire Broker, Broker Services |
| Natural SAF Security | Natural |
The Entire Net-Work SAF Security (NETSAF) is a separate, optional product for z/OS environments running Entire Net-Work version 5.6 or above. It allows Entire Net-Work clients to access SAF-secured data sources (targets); for example, Adabas, EntireX Communicator, and Entire System Server.
NETSAF can be activated on a link-by-link basis. If only one node of several communicates externally, security can be activated for that node alone and only for external links.
To secure Entire Net-Work, it is necessary to define resource profiles in the SAF repository. Resource profiles are defined for each host target. Adabas resource profiles can be defined at the file level. The command type determines the access level required for successful authorization: valid access levels are READ, UPDATE, and CONTROL. CONTROL applies to AOS commands, for example.
Point-of-access verification of incoming requests is made against the SAF-based central security repository: all access from mainframe clients can be verified against the same security profile.
Security checks are based on a trusted user ID, which must exist in the central security repository. In some cases, the user ID is authenticated in the caller's home environment or is fixed by, for example, the Entire Net-Work configuration. A user ID can be lost if calls are routed through an intermediate gateway node.