This page (revision-10) was last changed on 26-Nov-2021 10:22 by kparrott

This page was created on 26-Nov-2021 10:22 by rforbes

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
10 26-Nov-2021 10:22 4 KB kparrott to previous
9 26-Nov-2021 10:22 4 KB jaiken to previous | to last
8 26-Nov-2021 10:22 3 KB jaiken to previous | to last
7 26-Nov-2021 10:22 3 KB jaiken to previous | to last
6 26-Nov-2021 10:22 3 KB rforbes to previous | to last
5 26-Nov-2021 10:22 3 KB rforbes to previous | to last
4 26-Nov-2021 10:22 3 KB rforbes to previous | to last
3 26-Nov-2021 10:22 439 bytes rforbes to previous | to last
2 26-Nov-2021 10:22 399 bytes rforbes to previous | to last
1 26-Nov-2021 10:22 366 bytes rforbes to last

Page References

Incoming links Outgoing links
ENCRYPTION
ENCRYPTION

Version management

Difference between version and

At line 1 changed one line
The following pages describe the various aspects of encryption of data at rest in the database:
Encryption means that the data is scrambled when you look at it but it can be "unscrambled". There are two points of scrambling:
* During transmission across the network (especially the Internet)
* Within the data itself, when it is "at rest"
At line 3 changed one line
* [ENCRYPTION CONCEPTS]
!Encrypted Transmission
We can encrypt the data transmission using the HTTP Secure Socket Layer (HTTPS) protocol from the application server to the client. Follow the directions in Configuring SSL for your application server. In addition, as part of the Oracle Advanced Security Option, Network Encryption is also available with the ''Enterprise Edition'' of the application server software.
!Encrypting Data at Rest
Encrypting sensitive data in the database when it is not being used (known as data at rest) prevents it from being viewed or otherwise used by an unauthorized user who has gained access to the database files. Having the data encrypted does bring a performance consideration. The more data that the system has to encrypt and decrypt en route to/from the database, the more of an impact it will have on your performance.
Data is encrypted using a ''key'' and when examined without the key, is scrambled. The key is required to decrypt it to make it readable. The key is stored outside the database so that if the database files are compromised, the data is still encrypted. The key becomes part of the backup strategy, but (for a best practice of security) must be backed up on a separate medium than the data base.
Oracle offers a mechanism known as Transparent Data Encryption (TDE) as part of the Advanced Security Option in the ''Enterprise Edition'' of the database server software. TDE allows you to encrypt any number of fields without modification of the application. It is not recommended that columns on transaction-oriented mass updatable tables be encrypted. Columns that are part of an index (like PERSON_CODE) cannot be encrypted.
The application also supports encryption of select often-secured fields. The columns that are available for encryption are: BIRTH_DATE, GOVERNMENT_CODE, DRIVERS_LICENSE, and BANK_ACCOUNT, in all the places within the system that they reside.
!Encryptable Columns
When a column is encrypted, that actual column will then be blanked out to NULL, and the encrypted value is stored on a RAW type of field on the same record. This ensures that the data cannot be read in clear text. The columns that may be encrypted (you control this with the [IMCE] screen) are:
||Table || Column || Encrypted Column
|P2K_HR_CONTACTS |BIRTH_DATE |RAW_BIRTH_DATE
|P2K_HR_CONTACTS |GOVERNMENT_CODE |RAW_GOVERNMENT_CODE
|P2K_HR_IDENTITIES |BIRTH_DATE |RAW_BIRTH_DATE
|P2K_HR_IDENTITIES |DRIVERS_LICENSE |RAW_DRIVERS_LICENSE
|P2K_HR_IDENTITIES |GOVERNMENT_CODE |RAW_GOVERNMENT_CODE
|P2K_PR_DEPOSITS |BANK_ACCOUNT |RAW_BANK_ACCOUNT
|P2K_PR_PAYMENT_RULE_DETAILS|BANK_ACCOUNT |RAW_BANK_ACCOUNT
|P2K_RE_CANDIDATES |BIRTH_DATE |RAW_BIRTH_DATE
|P2K_RE_CANDIDATES |DRIVERS_LICENSE |RAW_DRIVERS_LICENSE
|P2K_RE_CANDIDATES |GOVERNMENT_CODE |RAW_GOVERNMENT_CODE
|P2K_WS_SERVICE_DEFINITIONS |WS_PASSWORD |RAW_WS_PASSWORD
|P2K_WS_SERVICE_DEFINITIONS |WALLET_PASSWORD |RAW_WALLET_PASSWORD
|P2K_WS_SERVICE_DEFINITIONS |TOKEN_PASSWORD |RAW_TOKEN_PASSWORD
The views provided with the application handle the decryption of data, so if you are creating reports using external tools with these views, there is nothing more to be done. If you are accessing the fields above directly, then you will need to modify your reports to handle the decryption of the data. A database function, [P2K_PMSEC.CHECKANDDECRYPT] (and for date columns [P2K_PMSEC.CHECKANDDECRYPTDATE|P2K_PMSEC.CHECKANDDECRYPT]) is provided to help your external reports with the decryption of the data.
!Oracle Reports limitation
Note that any Oracle Report that reports on or utilizes a field that has been encrypted will now show that field to be blank. Processes (such as UEEF) that are trying to run backend code utilizing encryption will error out.
At line 6 removed one line
* [P2K_PMSEC] - reporting on encrypted data
At line 8 removed one line
* [PROCESSING ENCRYPTED DATA]
At line 10 changed 5 lines
[CLEANUP]
Do we include this still?
* [TRANSPARENT_DATA_ENCRYPTION] - An alternate method using Oracle Transparent Data Encryption
----
![Notes|Edit:Internal.ENCRYPTION]
[{InsertPage page='Internal.ENCRYPTION' default='Click to create a new notes page'}]
This page (revision-10) was last changed on 26-Nov-2021 10:22 by kparrottTop