Details
-
Type:
New Feature
-
Status:
Open
-
Priority:
Severe
-
Resolution: Unresolved
-
Affects Version/s: 4.1.2
-
Fix Version/s: Future Release
-
Component/s: API
-
Labels:
-
Customer Case:
-
QA Validation Status:Not Yet Validated
Description
Use case is for security reasons, avoid dumping the JVM memory etc.
Ideas:
- We may think of a new storage type, delete temporarily unencrypted objects after their usage, eventually involve GC.
- Or even think of a pluggable data policy on the row level. (e.g. custom plug-in checks at first time of object creation if this field (e.g. defined by the field name or other criteria defined by the custom plug-in) is defined as sensitive data and need to be encrypted).
Ideas:
- We may think of a new storage type, delete temporarily unencrypted objects after their usage, eventually involve GC.
- Or even think of a pluggable data policy on the row level. (e.g. custom plug-in checks at first time of object creation if this field (e.g. defined by the field name or other criteria defined by the custom plug-in) is defined as sensitive data and need to be encrypted).
Issue Links
| This issue relates to: | ||||
| PDI-6774 | As an ETL-Administrator, I want to set some security restrictions by a security level |
|
|
|
That's simply the end of the story. There are no work-arounds or whatever to make that any harder.
In-memory encryption is no use if the decryption algorithm is somewhere available to the VM.