Security Guide > Using Data Encryption > Data Encryption > Data at Rest Encryption
Was this helpful?
Data at Rest Encryption
What is Data at Rest Encryption?
‘Data at rest’ refers to data on physical media recorded in a persistent form in Actian Ingres database table, transaction log, journal, and checkpoint files. ‘Data at rest encryption’ ensures the data on disk or other media is protected by encryption and can only be accessed by the known encryption passphrase.
Data can be encrypted at the DBMS Server level or the application level:
• Database encryption is done at the DBMS Server level and transparent to applications. It protects all data in a database. If you want to be assured that all data at rest is encrypted, declare the database as encrypted using the “createdb -encrypt” command, where you also define an encryption passphrase. To enable access to the database, use the ENABLE PASSPHRASE statement.
• The passphrase applies to the database.
• Table column encryption also is done at the DBMS Server level and transparent to applications. It protects all values in specific database table columns. If you want to encrypt only the data in a few table columns, declare the columns as encrypted on the CREATE TABLE statement, where you also define an encryption passphrase.
• The passphrase applies to the individual table with an encrypted column.
• Functional encryption is done at the application level. It allows specific values in table columns to be encrypted. The application has full control over the encryption by applying encryption and decryption functions with a passphrase on individual data values.
• The passphrase can apply to a set of rows of a column as specified by the application.
You can combine the two levels of encryption, creating an encrypted database with createdb, and then storing application-encrypted data in that database. But you cannot combine database encryption with table column encryption.
The following table gives an overview of the major differences between these three types of encryption at rest:
 
 
Datahase Encryption
 
Table Column Encryption
Functional Encryption
Transparent to application
x
x
-
Full application control
-
-
x
Protects all data in database with single passphrase
 
x
-
-
Protects individual data values in table columns with individual passphrases
-
-
x
‍Compression of backups created with checkpoints
No compression possible
The amount of encrypted data decreases the compression rate proportionally
The amount of encrypted data decreases the compression rate proportionally
Size of encrypted data
-
-
Incorrect column sizing can cause data loss
Restrictions for indexing table columns
-
Encrypted column must be defined with NOSALT
Encrypted column cannot be in a composite index
Range and pattern queries cannot use the index
Index likely is useless if it contains encrypted values
Restrictions for table columns
-
Encrypted column cannot be a part of table key
Table key is non-functioning if it contains encrypted values
Optimizer statistics
-
Statistics data collected for encrypted columns is stored without encryption
-
Table partitioning
-
Partitioning on an encrypted column may reveal information on the values of the column
-
Security of the passphrase in SQL statements
Passphrase statements run by DBAs only
Passphrase statements run by DBAs and table owners
Every statement accessing encrypted values contains the passphrase
From the comparison it is obvious that database encryption can be used with the least restrictions for applications as well as database design and operation. It is the generally recommended method for protecting the data at rest. Table column encryption may be applicable when only a small number of table columns is to be protected. Functional encryption is the only method that offers full control by the application.
Protecting data outside of the databases
Data at rest encryption does not protect data outside of the database, which includes:
• Data passed back and forth to applications
• Transactions that implement data replication at a logical (vs. binary, journal application) level
• Files created using copydb, unloaddb and genxml utilities
• Data exported by other methods like external tables or COPY INTO EXTERNAL CSV.
Note:  If the security of data transmitted over a network is important, you can implement protection using other mechanisms such as TLS or AES. Flat files containing sensitive information that is encrypted in the database should be stored in encrypted files or on encrypted media.
Last modified date: 01/27/2026