This document provides information about data security risk mitigation solutions provided to DSP users via:
WebApps use role-based security, in which organizational roles define which WebApps and which pages in the WebApp each user can access.
WebApp Groups, such as read only, power user, subscriber or administrator, limit what users assigned to those groups can do within the application A user must belong to the User WebApp group for that WebApp to display on the Navigation pane. Refer to WebApp Groups in the online help for a list of groups and what each group allows the user to do.
An Administrator can also use keys to limit user access across multiple work areas such as data sources a.h report repositories. Refer to Assign Keys to Security Role in the online help for more information.
Refer to the Set Security section of the online help for more information.
Fields encrypted through the application layer are also encrypted at the data layer, preventing visibility of sensitive data by those with access to the database. Encryption limits visibility of data at the application layer even if a user has role access to an application and data sources and reports.
NOTE: User access to the database is controlled by standard operating procedures of the client organization.
Data Source connection parameters are encrypted on screen. An Administrator configures which fields (connection string, user id, and password) are encrypted from viewing.
Sensitive Data fields may be encrypted from the application layer to the database layer at the database, table, and field level.
Column-level encryption is used to protect sensitive information that is stored in the underlying database. Without this feature, such information is stored in plain text and is readable by any user with access to the underlying database and potentially by unauthorized users if login security is breached.
This section outlines how to implement column level encryption in the DSP (version 6.0 and higher) using column-level encryption and decryption.
The following terms are used throughout this document:
- FIPS 197 Compliance – Federal Information Processing Standard 197 is a US Government standard that provides best practices for implementing crypto algorithms, handling key material and data buffers, and working with the operating system.
- Decrypt/Pass – When reading data from an encrypted column, the decrypt mechanism is designed to look at the data, find the magic marker and attempt to decrypt the data. If the magic marker does not exist, there is no attempt to decrypt the data and the data is preserved as is.
Become familiar with the following technical notes before implementing column-level encryption:
- All encryption and decryption is performed at the application level.
- Triple DES or AES-256 is used.
- All methods are called through system level FIPS 197 compliant libraries.
- Encryption Keys are stored in the database. Each instance of DSP can have one or more encryption keys that can be used to encrypt one or more columns.
- Proprietary keys are protected by a Site Master Password (which is system-generated if one is not specified) that must be identical across all servers for a specific instance. The Site Master Password is stored in config.xml. The system-generated Site Master Password is based on the server name and the database; therefore, all host files or DNS aliases must be in place and identical across all machines that have DSP server software running. In general, this is just the web server. For example:
<add key="EncryptionAlgorithm" value="AES256" />
<add key="EncryptionKey" value="e02337ddc69f762d2881602d4b4bcbf9cbd144a2" />
- Users only need rights to view the page in order to view the encrypted data.
NOTE: The data is still encrypted at rest and the user is authorized to see the data.
- Encryption is available to developers through the plugin API with encrypt and decrypt/pass. To use the API, the KeyID must be known (located in the Key table, GUID).
Even with Column-Level Encryption, accidental disclosure to non-authorized users is possible. If a user has access to any page and an encryption string is pasted in, plain text displays after transition to view mode. This risk can be minimized by implementing Page security and by securing the encryption keys.
The following are limitations to the column-level encryption feature:
- Encrypted columns must be nullable and be configured with data type nvarchar. The size of the column must be between 128 and 256.
- WebApps with encrypted data must be decrypted before a CTS package is built. Move the package, then re-encrypt.
- Data entered directly into the database outside of the DSP-specific mechanism will be seen as plain text because this is application-level encryption and decryption.
- Database-level mechanisms cannot be used to read or write encrypted data. These operations must be performed by plugins or through the DSP front end.
- Joins, search or indexing are not supported on encrypted columns.
To encrypt columns:
Grant permissions to the Power User and Power Designer WebApp groups for the System Administration WebApp. Refer to Assign Users to WebApp Groups for more information.
Each instance of DSP is delivered with a System Administration Passwords key. Additional encryption keys can be created.
Encryption keys are stored encrypted in the database. The key to decrypt the encryption key is stored in the file system on the web server.
To create an encryption key:
- Log in to the DSP.
- Select Admin > Configuration >Encryption > Encryption Keys in the Navigation
- Click Add on Page Toolbar.
- Enter an encryption key name in Display Name field.
- Click Save.
To encrypt a column:
- Select Admin > Data Sources in the Navigation pane.
- Locate the Data Source Name.
- Click the Encryption icon; all enabled column encryptions display.
- Click Add on the Page Toolbar.
- Select a table from TABLE NAME list box.
- Select a column from COLUMN NAME list box.
- Select an encryption key from KEY ID list box.
- Click Save.
- Click Enable.
NOTE: To decrypt a column, click Disable.
The DSP has built-in activity logging for every application, every page, every field, and every event for every user, stored in a log file on the application server. The application administrator may configure this to reduce tracking of some pages, some fields, and some events. Refer to Log Events and Access to Personal Data in the online help for more information.
The DSP assists clients with regulatory or corporate compliance by:
- Restricting access to personal data (any data that can be used to identify a person), handled through DSP security and through purging data after a retention date has passed. Purging data is configured in Common and Collect.
- Tracking and logging user access to this data throughout the product, which is configured in System Administration.
Settings must be configured before compliance can begin.
- An Administrator must enable the logging feature in System Administration. By default, the DSP tracks access to all pages; however, an Administrator can control which pages are tracked. Refer to Log Access to Personal Data in online help for more information.
- At the client site, an Administrator must also set up auditing for these specific tables in the DataSource named “DataGarage”.
When a Data Controller updates any retention expiration date, an e-signature is required and captured in the audit records.
- At the client site, an Administrator should also set up auditing for any tables that contain regulated data. Refer to Enable Auditing for Tables with Personal Information in help for more information.
- A Collect Administrator must configure data protection for the Target, Target Source and Table on the Data Protection tab in Collect. The following settings can be configured:
- Data Controller — The user responsible for the processing of personal data in the target. Any user or group who is assigned the Data Controller role must have a user account in the DSP. Data Controller must have access to the target based on their assigned security role and security key.
- Data Classification — The nature of the data in the target, identifying whether a target contains personal data and so must be purged.
- Retention Expiration Date — The date when the data in the target, target sources, and tables will be automatically purged when a Service page runs.