How paranoid should I be about my Azure application binary files being stolen?

I need to migrate a huge application to Windows Azure. The applic开发者_运维百科ation depends on a third-party library that requires an activation key stored in a special binary file on the role instance filesystem.

Obviously that key has to be either included into the role package or stored somewhere where role can fetch it. The activation key will not be bound to the machine (since I have no idea where exactly a role will be run in the cloud) so anyone can use it to make a copy of that library work.

Since Azure roles run somewhere not under our control I feel somewhat paranoid about the key being stolen and made widely available.

How do I evaluate how likely it is to steal a binary file that is included into Azure role? How do I mitigate such risks?

When asking questions like this you need to differentiate your attackers:

• A2) Rogue internet hacker
• A3) A developer in your organization
• A4) A person in your organization who does deployments

Your role binaries are not accessible to A2, however they are very accessible to A3 and A4.

As mentioned in another answer, you can store your secrets in the Role Configuration File. However, these secrets are still accessible to A4 (anyone with access to the portal).

To defend against A4 you want to encrypt the secrets in the role configuration file with a key that isn't present in the role binaries or the role configuration. Then in your role binaries you decrypt the encrypted role setting, with the decryption key.

The key to use for encrypting the secrets is a certificate, which the Azure SDK will install for you. You can find a post about setting up certificates for azure here.

In summary, for secrets where you need to defend against people in your organization who do deployments/have access to your configuration files you do the following:

Have a trusted party do the following:

• Generate a Certificate/Private Key
• Encrypt secrets with the Certificate, and store the encrypted settings in your configuration files
• Upload the Certificate/Private Key to your service.

Then modify your service to:

• Have the service model install the Certificate/PrivateKey
• Have your application, load the private key for decrypting secrets
• Have your application load the encrypted settings from role configuration, and decrypt them with the private key.

As far security is concerned, unless your team is extremely capable in this area, the default always upgraded Azure OS is probably much more secure than any self-configured host. At least, this is how we (aka my company, Lokad) assess the situation two years after migrating in full to Windows Azure compared to our previous self-hosted situation.

Then, if you have credentials, such as licence keys, then the most logical place to put them is the Role configuration file - not the Role binaries. You can naturally regenerate the special file within the VM as needed, but this way, you don't internally spread your credentials all over the place as you archive your binary versions.