search

Particular / NServiceBus

Build, version, and monitor better microservices with the most powerful service platform for .NET
https://particular.net/nservicebus/
Other
2.07k stars 650 forks source link

Add Support for Property Encryption in Saga Storage #3519

Open fafachd opened 8 years ago

fafachd commented 8 years ago

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: https://github.com/Particular/NServiceBus/issues/3490#issuecomment-188178269

timbussmann commented 8 years ago

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 commented 8 years ago

We use the registry. Good point though.

andreasohlund commented 8 years ago

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

MarcinHoppe commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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 https://github.com/Particular/NServiceBus/issues/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:

This lets us give developers read-only access to:

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

danielmarbach commented 8 years ago

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