Encrypted and Aggregating Content Stores

[jamen]

I'm working on a project investigating the use of encryption at rest on a content store.  Further to this we have some requirements that align to the feature of the Aggregating Content Store implementation.  With the latter we have an additional requirement of NOT having content stores configured in an XML file, rather it would be desirable if an system administrator could somehow configure additional stores in some sort of configuration management service (e.g zookeeper or properties file decoupled from the war file).

Can someone assist with answering the following questions:-

1. How does one go about practically encrypting an existing content store AFTER the encryption module is installed?
2. What happens at a node level and with the content properties with the process of encrypting legacy content (as I understand only NEW content is encrypted after the module is applied)?
3. Does the aggregating content store implementation support aggregated encrypted content stores?

The background is that some organisations consume storage solutions that are capped at a certain size and when that ceiling is reached we would need to procure new storage and declare it on the deployment instance.  We would NOT want to do another software release for this.  Further to this encryption at rest is a baseline requirement for our project.

[afaust]

The feature of simple configuration without XML is something that I have implemented for my simple-contentstores addon. That one also has an encrypting content store without requiring the use of Alfresco Enterprise.

As to your questions:

1. You must write a background process that transparently copies content files from the old content store to the new encrypted content store while keeping the content URLs intact / unaltered. The encrypting content store must be prioritised for retrieval in an aggregating store layer, so that if a content has already been encrypted it is preferrably retrieved from the encrypting content store instead of the old legacy store.
2. If the encryption of old content is done as I mentioned above then nothing changes on a node level. You are only processing files without affecting any data in the database as long as the content URL remains unchanged / valid.
3. All content stores support aggregation via the facading AggregatingContentStore. With the encrypting content store in Alfresco Enterprise though you will have to significantly alter the default configuration to rewire the components in such a fashion.

[jamen]

Thanks Axel Faust‌

This might be something product management might be interested in (Richard Esplin).  Particularly on the following:-

1. There should be an easy administrator friendly way to have legacy content stores transition to an encrypted state.  This may leverage points taken in Q&A from 1 and 2 above.
2. Improvement is needed to standardise configuration in such a way to streamline content stores to be aggregatable without rewiring and re-implementation
3. Content stores ideally should be addable through an administration tool or configuration management service.  Given some current project requirements to evaluate zookeeper, we may do an implementation based on this whereby micro-service components look for configuration (including potentially content store configuration) based on the order of:-
   • configuration management (zookeeper)
   • external property file
   • container property file
   • war file property file

[resplin · Accepted solution]

I apologize for taking so long to respond to this question. It took a couple of conversations with engineering before I felt like I understood the situation. Thank you Axel Faust‌ for your interesting response.

The Encrypted Content Store is a wrapper around the File Content Store, and is not intended to be used along with any other content stores such as the Aggregating Content Store or the Content Store Selector. Attempting to do so is likely to expose encrypted content in the clear, such as in the version history or when the content is deleted.

0. We have an additional requirement of NOT having content stores configured in an XML file, rather it would be desirable if an system administrator could somehow configure additional stores in some sort of configuration management service (e.g zookeeper or properties file decoupled from the war file).

It is currently required to configure the content store in an XML file, but this XML file can live outside the WAR file.

1. How does one go about practically encrypting an existing content store AFTER the encryption module is installed?

The intention is that the Encrypted Content Store be setup in a new deployment of Alfresco Content Services, and then content be migrated into that instance. Other approaches are likely to only encrypt the new content and leave the version history unencrypted.

2. What happens at a node level and with the content properties with the process of encrypting legacy content (as I understand only NEW content is encrypted after the module is applied)?

New content added to the repository will be encrypted, but the version history will not be encrypted. When content is deleted, it is likely to be moved to an unencrypted content store until the trash is emptied and will continue to be available until the orphaned content is cleaned.

3. Does the aggregating content store implementation support aggregated encrypted content stores?

It does not. The aggregating content store assumes a default content store that will be used to store new content, and if that content is not found it will examine the other content stores for it. This often results in the version history being spread across content stores, which complicates key management.

We intend to enhance our Encrypted Content Store implementation to meet these types of use cases, probably by providing a set of administration tools for managing content within a store and moving it between stores. But this work is unlikely to be scheduled in the next few quarters as we are working on our platform tooling for the next major release.

[jamen]

Just on the following

The Encrypted Content Store is a wrapper around the File Content Store, and is not intended to be used along with any other content stores such as the Aggregating Content Store or the Content Store Selector. Attempting to do so is likely to expose encrypted content in the clear, such as in the version history or when the content is deleted.

This is interesting,Axel Faust‌ indicated that the Aggregating Content Store is a facade.  Wouldn't facading an aggregation of individually encrypted stores (assuming ALL stores are encrypted) still be secure or are you saying that there is the high likelihood of leakage from the aggregator?  I note here that one would have to transition to a fully encrypted state for content at rest (so there would need to be a transition).

Otherwise, if one is in an environment where storage was managed in discrete blocks of 1TB how would Alfresco recommend one would address this.  Our current approach would be to have a master storage device that might symlink to the secondary logical locations corresponding to other devices.  e.g. Primary NFS linking out to secondary NFS devices.

[afaust]

Richard Esplin‌ is referring to how the Encrypted Content Store implementation by Alfresco is setup and supported out-of-the-box by Alfresco. On the technical implementation side of things, there is a bit more flexibility, but as Richard has indicated Alfresco did not intend the store to be used in conjunction with others.

With the AggregatingContentStore as a facade, the encrypted store would still be secure by itself. But there also is a CachingContentStore (in previous versions also a ReplicatingContentStore), which could be configured to copy content from a backing store into another, and by doing so would potentially store a decrypted version of the content in an insecure location.

But to be honest, even when the Encrypted Content Store is used, there are various constellations where an unencrypted version of the content is (temporarly) stored on disk. E.g. when Alfresco needs to transform a content to a different mimetype (i.e. create a thumbnail), the file will be stored without encryption in the server's location for temporary files. Since Alfresco does not perform pro-active cleanup of temporary files, it could sit there for between 1 or 2 hours, when the async cleanup process will remove it at the latest.

[raviranjan003]

I am using your simple content store add-on. I download the code from GitHub and build then install amp file. After setting it's not encrypted the content store. 

I am also setup the alfresco-global.properties file as per given in documentation.

[EddieMay]

Hi @raviranjan003 ,

I'd recommend creating a new post rather than adding your questions to one that has already been accepted as a solution - other people looking to help often skip over questions with accepted solutions.

[resplin]

Wouldn't facading an aggregation of individually encrypted stores (assuming ALL stores are encrypted) still be secure or are you saying that there is the high likelihood of leakage from the aggregator?

The short answer is that we haven't tested this use case. My understanding is that the system doesn't know how to handle the separate keys for the separate encrypted content stores that are aggregated.

Otherwise, if one is in an environment where storage was managed in discrete blocks of 1TB how would Alfresco recommend one would address this.  Our current approach would be to have a master storage device that might symlink to the secondary logical locations corresponding to other devices.  e.g. Primary NFS linking out to secondary NFS devices.

Our recommendation is that administrators use a storage solution that allows flexibility in a way that is transparent to the Alfresco Content Repository. The content repository encrypts each item individually, and then stores a key and a path in the database. As long as that reference doesn't change, the underlying storage device doesn't matter. Your example of indirection through a master storage device seems like it meets this requirement, as would most NAS solutions.