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
Network data encryption
Use network encryption to encrypt data transmitted between server and client, and between server and other server.
Background Knowledge on Keystores
This topic offers some generic insights into keystores and how they are used for secure communications with the TLS (Transport Layer Security) protocol. While the first part provides the theoretical background, the second part shows examples for applying this in practice using OpenSSL.
Concepts of Keys, Certificates and Keystores for TLS
This section explains keystores for TLS/SSL (Transport Layer Security / Secure Socket Layer) connections between database clients and servers.
Certificate authorities

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.
      - Communication support modules for data transmission encryption
        You can use the communication support modules (CSMs) to encrypt data transmissions, including distributed queries, over the network.
      - Enterprise replication and high availability network data encryption
        You can configure network data encryption for Enterprise Replication and high availability clusters by using configuration parameters.
      - Background Knowledge on Keystores
        This topic offers some generic insights into keystores and how they are used for secure communications with the TLS (Transport Layer Security) protocol. While the first part provides the theoretical background, the second part shows examples for applying this in practice using OpenSSL.
        Concepts of Keys, Certificates and Keystores for TLS
        This section explains keystores for TLS/SSL (Transport Layer Security / Secure Socket Layer) connections between database clients and servers.
        A high level view of TLS/SSL
        TLS handshake, certificates and public-private key pairs
        Relationship between certificates and keys
        Keystores
        Keystore content
        Certificate authorities
        Using only self-signed certificates
        Setting up a home-grown certificate authority (CA)
        Examples for creating keystores using OpenSSL
        Examples for creating keystores using IBM® GSKit
    - 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.
    - 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

Certificate authorities

As explained before, a certificate authority (CA) is "an entity that is trusted by all communication partners". For TLS communication, this means that the CA is trusted to issue a user certificate only after having checked that the requester for the certificate really is who he says.

For TLS communication, CA is trusted to issue a user certificate only after having checked that the requester for the certificate really is who he says. The extent of this checking is of various degrees. Basic checking usually means verifying that the requester is the owner of the stated e-mail address and internet domain. More elaborate verification may include a proper postal address, entry in a trade register, and even more background checks. The more checking is performed, the trustworthier are the CA and the certificates it issues. These factors also have an effect on the price to be paid for the certificate. This applies mostly to public CAs.

Returning to the basic principle of "an entity that is trusted by all communication partners", a company or organization also can setup its own CA for all internal database communication. As long as all database servers and database clients reside e.g. within the same intranet, all in-house communication partners can agree upon and trust a "home-grown" CA that issues user certificates for the database servers and distributes its own CA certificates to the database clients. As a concept, this may even be acceptable for certain B2B communications, where a database client may be outside of the intranet. Still, the client may trust the CA certificate received from the company for access to a database service of this same company.

With that, the use of CAs can be divided into three basic categories:

Using a public CA (and paying for the certificates issued).
Setting up a home-grown CA (for a limited number of well known and trusting communication partners).
Not using a CA at all (but only using self-signed certificates).