views:

140

answers:

4

I am developing a web application that uses Amazon Web Services. I am using ASP.NET MVC. I also use several Amazon Web Serivces including S3, EC2 and SQS. I am planning to hire freelancers to help the development. Now I put the Amazon Web Service key and secret in the web.config file and it is connected to my credit card. I am using hosted SVN source control, and TeamCity for automatic build and testing.

The question is, is there a way the freelancer can checkout the code and do testing, without knowing the sensitive information like the AWS key and secret? Should I put it in a different file? Should I put it in the database and encrypt it?

+2  A: 

The problem with freelancers is that they generally have access to the keys to the kingdom. In .net you can toss all the stuff you want to keep secret into a separate assembly...but that can be reversed and opened up. You can keep the data in an encrypted format but at some point in time you have to give them access to the decryption algorithm so that they can work with the decrypted data when speaking with those services. If you have a shop with developers you can always create a wrapper that interacts between the freelancers code and your service layer thereby somewhat protecting your code and sensitive data from the un-trusted freelancers.

The easiest way for you to do this is with traditional abstraction layers. Don't give your freelancers deep access into your code base and you should be good. In your statement you said that you were using a public SVN which means you may need more than one repository.

Andrew Siemer
I think both answered my question but I can only mark one as an answer.
ycseattle
{GRIN} ...no worries!
Andrew Siemer
+4  A: 
  1. have a test account for your development and give that to your freelancers
  2. you can encrypt the sections of web.config following the steps mentioned here
  3. you can move the key into the code and compile the layer as a dll and give that to the developers
Rony
+1  A: 

Don't be sold on easily solving this problem -- you cannot hide your key from developers without going to greater lengths. If it's stored in a DLL, they can decompile the DLL with a tool like Reflector. If it's encrypted in web.config, but decrypted somewhere else where it needs to be used, they can monitor the network traffic with a proxy tool, or attach a debugger. While the methods suggested are useful for preventing casual theft of the key, such as by a typical user, somebody skilled who is determined to find it out and has access to run your code can generally find a way to get what they want.

Try to hire people you can trust. Do background checks if you must.

If you really need to hide your key, keep the code that uses it on a separate system the developers won't have access to except through a well-designed secure interface. Basically, you'll end up proxying access to AWS through another web service.

Chris W. Rea
+1  A: 

Legal protections are your friend here. Get a lawyer to draw up a contract for you, including protective clauses and penalties for violations. Also, if you need enough freelance help, it might make sense to look at a company to provide the services which could be a bit more secure than the freelance angle.

Failing that, Rony's first point is good--get a second, non production account. You honestly should have one anyhow for staging and testing as you probably don't want untested code playing with production data. The real expense with AWS is in bandwidth rather than purely in storage, so it shouldn't cost too much.

Another angle, depending on how much of the service's API you are using and your skills as a coder, would be to abstract the S3 bits behind your own storage interface. Provide the developers with a non-S3 backed implementation while keeping your s3-backed implementation in a separate repository they don't have access to, then switch to the s3-backed option when appropriate. This has long-term advantages like making it easy to switch storage providers should the need arise.

Wyatt Barnett