Add Support for Property Encryption in Saga Storage

[fafachd]

Our client's developers need read access to production saga storage for debugging purposes (RavenDB in this case case) and production control requires sensitive properties be encrypted to allow this access. Since NSB already provides property encryption over the wire, it would be really nice to be able to tell NSB to apply this (already configured) property encryption while saving saga state.

See this issue for background: #3490 (comment)

[timbussmann]

I'm wondering whether it is a good idea to use the same encryption mechanism used for transport encryption for data encryption. Since the encryption keys are configured the config file, what mechanisms do you use for hiding them from your staff @fafachd ?

[fafachd]

We use the registry. Good point though.

[andreasohlund]

I don't like sharing the keys since the lifecycle is different:

• Message encryption: Keys needs to be available for as long as "messages are expected to be stuck in the error queue", arguably this is in the "a few months" to a year timeframe
• Saga encryption: Needs to be around for the lifespan of the saga => forever

[MarcinHoppe]

@andreasohlund I think this can be solved by having a master key (or keys) defined in some key store (config, registry, Azure Key Vault) and deriving encryption / authentication keys per usage (data in transit, data at rest).

@timbussmann Providing access to key stores other than the config file is also something we should think about.

We would be in a better position to address both concerns when #3345 is done.

[timbussmann]

@fafachd so as long you're not using some sort of config file encryption mechanism (is that even possible outside of ASP.NET apps?) your devs/ops will still have access to the key, right? So in that case, encrypting properties just makes it more difficult to read sensitive data but doesn't really protect it at all. Transport message encryption imho is mainly protecting from man-in-the-middle attacks, it's not really working as a data protection mechanism. Every dev could just log all message properties in a message handler (same with saga data) and the whole encryption is utterly useless. And if you're not explicitly define all allowed assemblies, assembly scanning will make it trivial for any dev to inject malicious extensions to any endpoint.

Still I kinda like the idea of saga data encryption. @fafachd are you using data encryption somewhere else on your business data or only on saga data (and if yes, what mechanisms are you using)? But I tend to agree with @andreasohlund that this seems to be a different feature than transport level encryption. Still, a perfectly valid feature request imho.

[fafachd]

I appreciate you all taking the time to look at this! We currently use NSB transport-level property encryption and let NSB inject an IEncryptionService into our sagas to encrypt sensitive fields before saving and decrypt them before loading saga state (hense #3490). Our NSB services are not currently using any other encryption. We created a common library for all our NSB services to look in the registry for keys and we only allow prod control (not developers) access to production registries.

You could slot this feature request into a bigger-picture objective of maximizing developer visibility into production installations without compromising security. We work to:

• Avoid putting connection strings or encryption keys in config files
• Not log any sensitive information or PII
• Encrypt sensitive information in transport and in saga storage

This lets us give developers read-only access to:

• Production bin directories for our NSB services
• Production Raven instances for our NSB services
• Production log files
• Service Pulse

We would also like to give developers read access to ServiceInsight in production, hence: Particular/ServiceControl#400
http://eaiguy.net/2014/10/24/securing-servicepulse/

[danielmarbach]

@fafachd We are closing down the features for version 6. We decided to not include this in v6.