AEM JCR Data Encryption

Never read anything about encrypting JCR data. Seems like Overkill as the Server is protected by authentication and permissions.

Hi Joerg,

Thanks for responding.

Here is my use case:

User enters name, email id, phone number and address in AEM for subscribing to the newsletter, by using AEM Forms or otherwise.

This info needs to be stored in JCR repository (CRX) and that info needs to be used for sending newsletter, sms alerts , etc by the same AEM.

I agree that it is mot a good practice to store PII in AEM.

But, let us say that client has mandated this and asked us to take precautionary security measures accordingly.

If we are using forms, on Form Submit, we could get control, encrypt it and store in AEM.

If not using AEM Forms, we do not get control, as the data is stored by AEM inside JCR directly, with the.OOB functionality.

In such a case, how could we encrypt data?

The only solution I am aware is to write an Event Handler on that JCR Node, to know when the value is stored/updated, encrypt using any outside tool and store the encrypted value.

Similarly, whenever the data is retrieved, that event needs to be handled by decrypting and returning.

Kindly suggest.

Thanks,

Rama.

Do you really want to store subscription information in AEM? I would rather let AEM be the frontend and store the data in a more appropriate platform (Adobe Campaign for example).

If we leave the PII question aside and reformulate the question into "How can I store data encrypted in JCR", I see one reliable option: Do it yourself. Let only your code deal with the encrypted data and encrypt it when writing and decrypt it when reading.

Jörg

Here is information about encrypting/decrypting values stored in AEM's JCR in case others might find it useful...

https://www.albinsblog.com/2014/12/encryptingdecrypting-data-in-adobe-cq5.html#.W0YxyhJKiOE

Experiencing Adobe Experience Manager - Day CQ: AEM 6 SP1 - Servlet for Encryption Decryption

Thanks for posting

Hi,

This is a very interesting topic and quite relevant to something we are currently looking at with AEM forms and Adobe Sign. Using the OOTB functionality data and pre-signed PDFs are stored 'somewhere' in the JCR unencrypted. Also any saved data is stored in a similar manner When the signed PDF is polled it could be possible to move these items somewhere else and delete. However this still gives a large window where data at rest is unencrypted and potentially accessible to anyone with access to that part of the repository.

We would likely use a Processing server away from the Publish environment.

We are looking at a number of uses for AEM forms within the banking industry and clearly protection of PII is a major requirement.

Given AEM forms has been used in banking and tax collection solutions is there are an agreed pattern for protection of PII?

I hope noone is storing PII-relevant data inside the JCR repository. It does not have any builtin encryption, because it's not designed to serve as storage for such data.

That means that any architecture which requires you to save such data inside the JCR is flawed (at least from my personal point of view).In your case you can probably use the processing capabilities of AEM forms, but fetch and store any PII data from some other system. That happens in the cases I know. The PDF form itself is not sensitive and is often stored inside the repo. But when the user-data is prefilled into this form and when the form is submitted, it's not.

Jörg,

disclaimer: I am not a form specialist, just have some colleagues who are :-)

Exactly. We are not storing anything or using Forms at the moment for this reason.

Reality is that majority of forms that require some sort of signatory  would contain some PII so the current OOTB solution seems a bit lacking.

Current thought is that we would have to build a PII compliant standalone backend service to process the data, prepare the PDF, submit to Adobe Sign, poll for a signed PDFs and onward process. Pretty much everything that the Forms mechanism does.

When implementing forms solutions we use the JCR purely as an intermediary location for data we need to move around or reverse replicate. If you are collecting PII inside your forms, you need to take a direct to DB approach. Specifically the SubmitDataService. You can implement custom code to ensure your data is sent to an encrypted data source. This also makes reporting and extraction easier for the enterprise.

Adobe Experience Manager Help | Custom storage for drafts and submissions component