问题
I have seen related questions here, but they don't seem to be answering exactly what I need.
We use Powershell scripts to deploy our applications and the info like passwords in configuration files for most of the environments ( UATs etc. ) are in plain text. It is not a big issue, but when it comes to PREPROD and PROD, it is a big issue. So we had some markers in the config like "{{prompt-password}}" which will give a login dialog (Get-Credential) and the person doing the deployment can enter the credential and the deployment continues.
But this doesn't really help for automated deployment ( meaning one-click deploy through tools like TeamCity )
Should I go for Asymmetric encryption ( http://msdn.microsoft.com/en-us/library/as0w18af.aspx ) where the password is encrypted using a public key, entered in the config, and private key is stored (as described here http://msdn.microsoft.com/en-us/library/tswxhw92.aspx ) in the "agent" ( as in a VM from where TeamCity will trigger the deployment and which has restricted access ) running the automated deployment and it can decrypt the password? Not really strong on Cryptography and stuff, but does this sound like the way to go? Any other suggestions? How do people handle such automated deployment?
Update:
Ok, I have gone ahead and implemented it. I have written a Console Application in C# which uses the Crypography libraries. The app generates the keys:
RSACryptoServiceProvider rsa = GetRsa(containerName);
File.WriteAllText("keys.kez",rsa.ToXmlString(true));
I also get out the public key:
File.WriteAllText("public.pke", rsa.ToXmlString(false));
Give the public key to anyone who has to encrypt the password and ask them to enter the password in the config. Put the keys.kez file in any agent that has to run the deployment.
回答1:
Asymmetric encryption is definitely the winner here from a security and simplicity standpoint. I have deployed production SaaS apps in this manner very successfully.
There are a few tricks. One, as you mentioned, make sure the public/private key pair is installed on the host, not stored in config files or in the code. Two, assume the management and key generation tools provided by MS are weak to terrible and plan accordingly (we created a simple keygen exe for Operations to run during deploy.)
回答2:
Not really an answer, but a suggestion or an other question.
Why don't tou store the password in a crypted string in a config file
$credential.Password | ConvertFrom-SecureString | Set-Content c:\temp\password.txt
As far as I understand the documentation a process running with the same credential can get it back
$password = Get-Content c:\temp\password.txt | ConvertTo-SecureString
$credential = New-Object System.Management.Automation.PsCredential `
"username",$password
You can replace $credential.Password by read-host -assecurestring
回答3:
As you said in your question, your password are kept in PROD in config file in plain text. No amount of encryption can help with that. Also, this is kind of a vicious cycle - how are you going to protect encryption key?
The key think here is to look at what is practical, and what kind of business workflows your organization follows when it comes to deployments.
Let me explain this on an example. Let's assume that the deployment to PROD is executed by an infrastructure team. This team has access to the password that is required in your configs. They will never disclose this password to you (deployment developer) for security reasons. You want to avoid them entering the password during each installation. To think of it this is the best you can do. They will have to enter the password at least once.
Cryptography solution won't really work here because your deployment package will need a way to decrypt the password anyway and if it can do it without user input, so can you (the developer), and this is not acceptable.
Since the password is store in PROD config files in plain text anyway, make the deployment package prompt for the password only if it's not know. Once a infrastructure team member supplies the password, save it in a file locally. Better yet, save it in machine-wide key container. You do not need a password for this. Next installation around the key will already be known, and your installation won't need to prompt for a key again. Of course you need to provide a way to change the stored key too if needed.
The tokenizing approach, that you described, works. I've been doing this for quite some time quite successfully. (I.e. passed external security reviews) Since you do have a plain text password in PROD, PROD must be considered secure (safe) environment. And since it safe, there is nothing wrong about caching (storing a copy of) this secure password within it.
回答4:
Whether you use asymetric or symetric encryption you'll need to keep the deciphering key in your code so you are shifting the security risk from your configuration file to your executable (agent). It is much better in terms of obfuscation but the executable could conceivably be reverse engineered by someone sufficiently determined to extract the deciphering key.
回答5:
How about creating a scheduled job to run the deployment scripts? Set the task to be run with specific an user account and grant the account relevant permissions.
回答6:
An interesting question, I work with multiple environments as well and have the challenge of different settings for different environments. We don't really put passwords in the config though (a compromised machine or a mistake by an engineer etc...). If we do it's for pretty insecure stuff, as such we keep them plain text.
With that in mind could the build machine just not have a list of password for each environment?
If you don't want to you keep them plain text you may be able to do something with PowerShell - I'm sure Jaykul did a post on this way back when but my (quick) googling only returned something from Halr (both are PowerShell MVPs so it should be interesting) .
http://halr9000.com/article/531
来源：https://stackoverflow.com/questions/6133988/handling-passwords-in-production-config-for-automated-deployment