ExtraView is a secure application and has been developed to adhere to the strictest standards. Additional security is important and should be deployed by ensuring the environment within which ExtraView resides is secure, using firewalls and encryption of the network traffic with SSL, etc.
It is possible to protect sensitive data within the database using a further level of encryption. This protects against your database from unauthorized access, and unauthorized users using SQL commands to extract data. This encryption is provided for fields with a display type of text, and is applied on a field-by-field basis. This can be used, for example, to provide added protection for fields such as social security numbers and bank account numbers.
The precise name of the method used to encrypt this data is termed AES/ECB/PKCS5Padding (128-bit). This is widely recignized as a state-of-the-art algorithm that provides a very high level of protection.
AES = Advanced Encryption Standard
ECB = Electronic CodeBook blocking of data
PKCS5Padding = the type of padding to encrypted value. This causes the same text to produce different encrypted values from one encryption to the next
Authorized users will still see data that is encrypted within the database in the normal way. It is assumed that users will be educated on the sensitivity and privacy of data, and that the screens and reports they view may contain proprietary data that should not be stored with unauthorized personnel.
To provide the security, secret keys (or passwords) are stored in what is termed a keystore, within ExtraView. You may use a single key for all the fields you protect, or use different keys for different fields. The keystore may also be used to store certificates, for example certificates that grant access to SAML authentication servers.
These keys must be stored safely by the administrator, and there is no way to ever retrieve a lost key. This is critical to understand and neither the ExtraView application nor ExtraView Corporation personnel can ever retrieve a lost key. It cannot be stressed too much how important it is to have a process to record the keys used, and to keep them safe.
Further, here are items that should be considered before implementing encrypted fields:
The above limitations may be relaxed within future versions of the product.
There are 3 possibilities of how the secret keys may be used to unlock the data, dependent upon your requirements:
Configuration.properties
file which is read by ExtraView upon startup of the application. This is more convenient than entering the passwords manually, but not quite as secure. Of course, the filesystem with the Configuration.properties
(and other) files should be protectedConfiguration.properties
file using the technique described in the ENCRYPT_PROPERTIES section of the Installation & Configuration Guide.Unused keys may be deleted from the database, and the keys within the keystore may be updated by the administrator after providing the current key.
SAML authentication schemes typically require a certificate in a specific format known as PEM (Privacy Enhanced Mail). The name is somewhat of a misnomer as the certificates for SAML have no connection with email. The format is a Base 64 encoded striing of characters which should be pasted into the Enter certificate PEM field. If there is no entry in this field, the new entry you create for the certificate is added as a secret key only and is not used for SAML authentication.
The entry in the keystore should look like this:
The action to save a certificate in this field builds the appropriate credentials for the SAML certificate.