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.
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.

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

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.

If a mapped user is created with a non-OS surrogate UID and a home directory is not specified for this user, the working directory of the user is set to $INFORMIXDIR/users/server_servernumber/uid_UID. Generated files, such as explain output files and debug files are stored in the user's working directory.

Generated files are renamed to have a username_ prefix, where username is the name of mapped user. For example on server number 2, the sqexplain.out file for mapped user fred, who has a UID of 3000, would be $INFORMIXDIR/users/server_2/uid_3000/fred_sqexplain.out

If the length of the directory exceeds 256 bytes, the database server generates a warning, and files are generated in $INFORMIXDIR, instead.

If a CREATE USER or ALTER USER statement was used to specify the mapped user's home directory, then remote clients' files are generated in user's home directory and local clients' files are generated in the user's current working directory. File names changed to have a username_ prefix, where username is the name of the mapped user. Distinguishing the files of a specific mapped user is important, because multiple users can be mapped to the same surrogate UID.

If there are characters in a mapped user's name that interfere with file creation, characters are changed to '_'. For example, the generated files of mapped user foo/bar are renamed with the prefix foo_bar_.