Home
Security
You can secure your Informix® database server and the data that is stored in your Informix databases. You can encrypt data, secure connections, control user privileges and access, and audit data security.
Security in HCL Informix®
The Informix® Security Guide documents methods for keeping your data secure by preventing unauthorized viewing and altering of data or database objects, including how to use the secure-auditing facility of the database server.
Securing data
Connection security
You can administer the security of the connections to the database server by using authentication and authorization processes.
Internal users (UNIX™, Linux™)
The DBSA can grant database access to users that do not authenticate on the OS of the host computer by mapping PAM-authenticated users to OS-level entities or by configuring the server to perform internal authentication.
Specifying surrogates for mapped users (UNIX™, Linux™)
Specify operating system (OS) user names, user IDs, group names, and group IDs in the allowed.surrogates file to control which OS users and groups can act as surrogates for mapped users.

Security
You can secure your Informix® database server and the data that is stored in your Informix databases. You can encrypt data, secure connections, control user privileges and access, and audit data security.
- Security in HCL Informix®
  The Informix® Security Guide documents methods for keeping your data secure by preventing unauthorized viewing and altering of data or database objects, including how to use the secure-auditing facility of the database server.
  - Securing data
    - HCL Informix® directory security
      utilities and product directories are secure by default.
    - Network data encryption
      Use network encryption to encrypt data transmitted between server and client, and between server and other server.
    - Column-level encryption
      You can use column-level encryption to store sensitive data in an encrypted format. After encrypting sensitive data, such as credit card numbers, only users who can provide a secret password can decrypt the data.
    - Connection security
      You can administer the security of the connections to the database server by using authentication and authorization processes.
      - Authentication mechanisms
        You can configure the Informix® server authentication mechanisms to meet varying requirements, such as different security methods required for local and remote connections, database access by users without operating system accounts on the servers host computer, and non-root installation.
      - Internal users (UNIX™, Linux™)
        The DBSA can grant database access to users that do not authenticate on the OS of the host computer by mapping PAM-authenticated users to OS-level entities or by configuring the server to perform internal authentication.
        Mapped users (UNIX™, Linux™)
        The DBSA can configure the server to allow database access by external users. External users attempting to connect through Kerberos single sign-on (SSO), a Pluggable Authentication Module (PAM), or internal authentication can be mapped to an OS-level profile for processing connection requests.
        Mapped user surrogates in the allowed.surrogates file (UNIX™, Linux™)
        The OS Administrator can use the /etc/informix/allowed.surrogates file to control which OS users and groups can act as surrogates for mapped users.
        Specifying surrogates for mapped users (UNIX™, Linux™)
        Specify operating system (OS) user names, user IDs, group names, and group IDs in the allowed.surrogates file to control which OS users and groups can act as surrogates for mapped users.
        Internally authenticated users (UNIX™, Linux™)
        The DBSA can configure the server to authenticate users by checking their credentials with a hashed password that is stored inside the database server.
        Location and file names for mapped users' generated files (UNIX™, Linux™)
        The generated files for some mapped users are created in a different default location, and are named differently.
        Connections to a non-root installation (UNIX™, Linux™)
        A non-root installation of a database server runs without user root or user informix privileges. Installation and user administration of a non-root server can be easier, but this type of installation does not support all product features.
        Creating database server users (UNIX™, Linux™)
        If you have DBSA privileges, you can create internally authenticated users or you can create users who do not have accounts on the host system. To create these types of users, you must map each user to the appropriate user and group privileges, regardless of whether these users have operating system accounts on the database server host computer.
        Maintaining database server users (UNIX™, Linux™)
        You can modify, drop, or rename a database server user account that was created with the CREATE USER statement.
        User mapping tables (UNIX™, Linux™)
        The user mapping tables in the SYSUSER database are system tables that map users to OS-level properties that enable Informix® access and control level of discretionary access privileges.
      - Guest account (Windows™)
        Disable the Windows™ Guest account to prevent anonymous logins.
      - Trusted-context objects and trusted connections
        You can use trusted-context objects and trusted connections to increase system performance and security within a three-tier application model.
      - Pluggable authentication modules (UNIX™ or Linux™)
        A Pluggable Authentication Module (PAM) is a well-defined framework for supporting different authentication modules that were originally developed by Sun Microsystems. PAM is supported in both 32- and 64-bit modes on Solaris, Linux™, HP-UX and AIX®.
      - LDAP authentication support on Windows™
      - Authentication module deployment
      - Simple password encryption
        The simple password communication support module (SPWDCSM) provides password encryption.
      - Single sign-on
        Single sign-on is an authentication feature that bypasses the requirement to provide user name and password after a user logs into the client computer's operating system.
      - Securing local connections to a host
        The database server administrator (DBSA) can use the SECURITY_LOCALCONNECTION configuration parameter to set up security checking for local connections with the same host.
      - Limiting denial-of-service flood attacks
        Informix® has multiple listener threads (listen_authenticate) to limit denial-of-service (DOS) attacks.
    - Discretionary access control
      Discretionary access control verifies whether the user who is attempting to perform an operation has been granted the required privileges to perform that operation.
    - Label-Based Access Control
      You can use label-based access control (LBAC), an implementation of multi-level security (MLS), to control who has read access and who has write access to individual rows and columns of data.
  - Auditing data security

Specifying surrogates for mapped users (UNIX™, Linux™)

Specify operating system (OS) user names, user IDs, group names, and group IDs in the allowed.surrogates file to control which OS users and groups can act as surrogates for mapped users.

Procedure

Create a file named allowed.surrogates in the /etc/informix directory.
The allowed.surrogates file must be owned by root instead of informix. The file must not have execute permissions and only the file owner can have write permission.
In the allowed.surrogates file, enter the OS user names, user IDs, OS group names, group IDs, ranges of user IDs, and ranges of group IDs that you want to allow as surrogates.
1. Enter comma-separated OS user names, user IDs, and ranges of user IDs after entering the user: label.
```
users:user1,user2,105,104,300,400..500
```
2. Enter comma-separated OS group names, group IDs, and ranges of group IDs after entering the group: label.
```
groups:ifx_dbsa,group1,group2,root,1,10..20
```
The group and user labels are case-insensitive, and can be pluralized. Entries are separated by commas. Ranges of user IDs and group IDs are inclusive, with the upper and lower ranges separated by two periods. You must specify both an upper and lower limit for ranges. Comment lines begin with # and are ignored. Blank lines are also ignored.
If the allowed.surrogates file is formatted incorrectly, then user mapping is disabled and an error is logged in the online log file. If a user name or group name cannot be identified, the name is logged in the online log file and otherwise ignored, and the cache is cleared.

Example

The following example of an allowed.surrogates file entry specifies user user1, user 40, users 45-50, and group 10 as acceptable surrogates.


#Surrogate IDs
USERS:user1,40,45..50
GROUP:10