Table of Contents

Search

  1. Preface
  2. Introduction
  3. Accessing Data Archive
  4. Working with Data Archive
  5. Scheduling Jobs
  6. Viewing the Dashboard
  7. Creating Data Archive Projects
  8. Salesforce Archiving
  9. SAP Application Retirement
  10. Creating Retirement Archive Projects
  11. Integrated Validation for Archive and Retirement Projects
  12. Retention Management
  13. External Attachments
  14. Data Archive Restore
  15. Data Discovery Portal
  16. Data Visualization
  17. Data Privacy
  18. Oracle E-Business Suite Retirement Reports
  19. JD Edwards Enterprise Retirement Reports
  20. Oracle PeopleSoft Applications Retirement Reports
  21. Language Settings
  22. Appendix A: Data Vault Datatype Conversion
  23. Appendix B: Special Characters in Data Vault
  24. Appendix C: SAP Application Retirement Supported HR Clusters
  25. Appendix D: Glossary

Encrypt Data in Data Vault Job

Encrypt Data in Data Vault Job

The encrypt data in Data Vault job gives you the option to encrypt data that has already been archived or retired to the Data Vault. You can also use the job to rotate encryption keys on a regular basis, as required by company security policy.
Typically when you archive or retire data to the Data Vault, you enable data encryption when you create the archive or retirement project. If you archive or retire to the Data Vault without enabling data encryption, you can use the encrypt data in Data Vault job to encrypt the data at a later time. You can also use the job to rotate encryption keys for data that has already been encrypted, either during the initial project run or with this standalone job.

Access Roles

To be able to view and schedule the encrypt data in Data Vault job, a user must have both the encryption user role as well as a role that allows a user to schedule jobs, such as the scheduler role. The encryption user role is assigned to the Administrator role by default. For more information on system-defined roles, see the chapter "Security" in the
Data Archive Administrator Guide
.

Conf.properties File

The following table describes the properties that you can configure in
conf.properties
:
Property
Description
informia.encryptionkey.command
Command to generate the encryption key if you use a third-party utility. Provide the command to run the third-party key generator.
informia.encryption.RegistrationThreadCount
Defines the number of registration threads used to encrypt the Data Vault data. Default value is 5.
informia.encryption.WorkerThreadCount
Defines the number of worker threads used to encrypt the Data Vault data. Default value is 10.
informia.encryption.SCTRegistrationType
Defines whether the SQL or admin registers the encrypted .SCT files in Data Vault. Valid property values are SQL and admin. Default is SQL.
informia.encryption.AdminTimeout
Defines the admin timeout in seconds.
informia.encryption.DeleteOldDataFiles
Specifies whether or not to delete the original unencrypted data files during the encryption job. Valid property values are Y and N. Default value is N.
If you set this property to N, the encrypt job unregisters but does not delete the original unencrypted .SCT files. The job also creates new, encrypted data files and registers those files. Because the original files are still present in their physical location, the total size of the .SCT files will double.
If you set this property to Y, the job deletes the original files during the encryption job.
There is no automated process to validate the encrypted data against the original data. You must manually validate the encrypted data against the original data. After you validate the data, refer to the steps in the "Restoring and Deleting Old .SCT files" section below for cleanup instructions.
Informatica recommends setting this property to N, so that you can manually validate the encrypted data.
Default is N.
informia.encryption.IDVDeBugMode
Specifies whether or not Data Vault runs the encryption job in debug mode. Valid property values are Y and N.
Default value is N.
Debug mode provides more troubleshooting information if the encryption job fails.
For more information on the
conf.properties
file, see the
Data Archive Administrator Guide
.

Job Properties

Archive Store
The Data Vault target connection that contains the data that you want to encrypt. The job encrypts all of the tables in the archive folder that is defined in the target connection that you select. To encrypt the data on all available Data Vault connections, you can also choose "All Connections."
Encryption Key
Type of encryption key used to encrypt the data. You can choose either the random key generator provided by Informatica, or a third-party key generator. When you choose the third-party key generator, you must configure the property "
informia.encryptionkey.command
" in the
conf.properties
file. For more information on random and third-party encryption keys, see the chapters "Creating Retirement Archive Projects" and "Creating Data Archive Projects" in the
Data Archive User Guide
.
Rotate Keys
Select Yes or No. When you select yes, the job generates a new key used to encrypt the data. The data is encrypted with the new key.

Parallel Jobs

The encrypt data in Data Vault job is a single-thread job. You cannot run two encrypt jobs in parallel on the same Data Vault connection, nor can you run a job to encrypt all available connections and then start a second job on any connection. You can run two encrypt jobs in parallel provided they are running on different Data Vault connections. This design preserves the consistency of Data Vault metadata. When the encrypt data in Data Vault job runs, it unregisters the original unencrypted .SCT files in the Data Vault and registers the new encrypted files with the suffix "_ENC" appended to the file name. If you run the job to rotate encryption keys, the original encrypted .SCT files are unregistered.
If you try to run an encrypt job on a connection while a different encrypt job is running on the same connection, the job fails with an error that another encryption job is running. You must wait for the first encryption job to finish before starting another encryption job on the same connection.
In rare circumstances you may have the same Data Vault archive folder available on two different Data Vault connections. Because the underlying Data Vault database is the same, you cannot run parallel encryption jobs on this archive folder even though it exists on different connections.
In addition to parallel encryption jobs, you cannot simultaneously run any job that updates Data Vault metadata while an encryption job is running on the same connection. If you try to run any job that updates Data Vault metadata while an encryption job is running on the same connection, or all connections, the second job fails with an error. You can run a job that updates Data Vault metadata in parallel with an encryption job only if the encryption job is running on a different connection and archive folder than the second job.
The following list contains the specific jobs that you cannot run while an encryption job runs on the same target connection:
  • Archive crawler
  • Move external attachments
  • Update retention policy
  • Delete expired records
  • Purge expired records
  • Add tagging
  • Update tagging
  • Remove tagging
  • Apply legal hold
  • Remove legal hold
  • Load external attachments
  • Restore external attachments from archive folder
  • Audit log archive loader
  • Archive structured digital records
  • Restore file archive
  • Move external attachments
  • Create materialized views
  • Refresh materialized views
  • Release of information index record

Logs and Reports

The encryption job creates logs that are stored in the
<ILM_HOME>/logs/
directory. The logs contain information about the archive folder and individual tables that were encrypted during the job, such as the time that the job took to encrypt each table.
The encryption job creates logs inside of the
<ILM_HOME>/logs/
folder with the following directory structure:
<ILM_HOME>/logs/encryption_logs/<Job ID>/<Repository ID>/<Logs_entry_ID>
. The <Logs_entry_ID> directories contain a log for each table in the archive folder that was encrypted during the job. To find the table associated with a particular entry ID, you can query the ILM repository table "
xa_encryption_job_status
." The table contains the column ENTRY_ID for each table in the encryption job. The table also has a STATUS column to indicate the encryption status of a particular table. The STATUS column contains either C for complete, P for pending, or E for error.
An encryption job status report is also available in the Data Archive user interface, on the
Monitor Jobs
page. Expand the encryption job and then the job details to display the link that launches the PDF status report. The report is dynamic, so you can launch the report and track the progress of the job as it runs.

Restore Process

The job generates restore scripts every time you run it. The scripts are stored in the following location:
<ILM_HOME>/webapp/file_archive/restore/
. The job creates one folder for each table, with the folder structure
JOBID/repid/tableid
.
If necessary, you can restore the previous .SCT files after the encryption job is complete. To restore the previous .SCT files, run the following commands from the Plugin folder:
source the fasplugin.sh go to <ILM_HOME>/webapp/file_archive . ./fasplugin.sh <ILM_HOME>/webapp/file_archive go to <ILM_HOME>/webapp/file_archive ssaencrypt -G -F <ILM_HOME>/webapp/file_archive/restore/JOBID/repid/tableid/<Restore_YYYY_MM_DD_hh_mm_ss.adm> -P <PORT> -Q <AdminPort> -H <IDV Hostname> -u <IDV user/password>
The command will unregister the new encrypted .SCT files, register the old .SCT files, and delete the new encrypted .SCT files.
When the .SCT files are located on external storage, the files will not be deleted if they are under retention.

Deletion of Old .SCT Files

After you validate the data, if you want to delete the old .SCT files, run the following commands:
source the fasplugin.sh go to <ILM_HOME>/webapp/file_archive . ./fasplugin.sh <ILM_HOME>/webapp/file_archive ssaencrypt -O -F <ILM_HOME>/webapp/file_archive/restore/JOBID/repid/tableid/<Restore_YYYY_MM_DD_hh_mm_ss.adm> -P <PORT> -Q <AdminPort> -H <IDV Hostname> -u <IDV user/password>
The command deletes the old .SCT files.
When the .SCT files are located on external storage, the files will not be deleted if they are under retention.

0 COMMENTS

We’d like to hear from you!