UPDATE: As Spencer noted in the comment below, you can now configure ELB to generate PCI-compliant SSL proxying.
PCI Compliance, despite it's very important goals of safeguarding customer data, unfortunately right now exists primarily as a way for the processing companies to cover their butts. This weakness comes due to the fact that the bulk of the requirements can be fulfilled for small merchants by filling out the appropriate Self-Assessment Questionnaire (SAQ).
This is a little bit like asking high-school students to grade themselves on a test without giving them the answer key. There's the obvious problem of the students lying, but there's a further problem of them not knowing what the correct answer is. The terminology on the SAQ is not necessarily transparent.
To add insult to injury, most acquiring banks (the people who should receive the SAQ) aren't asking for it, simply because the number of vendors in the country processing payments far outstrips the capability of the card companies to check-up on them. Again, at the lowest levels PCI Compliance seems to exist primarily as a way to card companies to have their rumps properly protected in the event of a data breech. They get to levy fines and say "But they told use they were compliant," without springing for (the admittedly large cost of) an actual verification process.
There is, however, one part of level 4 compliance that has some value - and that's the need to pass a quarterly security scan from a Approved PCI compliance Scanning Vendor. This scan, even while it's not perfect at least provides a minimum baseline of safeguards a company needs to fulfill before it can reach compliance. Make sure you've applied the latest security patches and aren't running ancient software. That sort of thing.
Amazon recently reached level 1 compliance as a service vendor, meaning it's possible to run any size cardholder data environment on Amazon's cloud without being in violation. Unfortunately most Rails hosting companies, even those built on Amazon's AWS (like Engineyard
) don't seem to offer compliance or offer it at a significant premium.
What this means is that if you want to be compliant on the AWS cloud you either need to not take in any credit card information anywhere in your site (offsite pages, such as those provided by Braintree or Chargify are a great option) or you need to deploy your infrastructure directly onto EC2 yourself.
The good news is that the baseline infrastructure needed to pass the Automated security scan, provided you App doesn't have any holes is pretty straightforward. There were only two notable things we had to do to pass the ASV:
1. Deploy the (as of this writing) latest version of Ubuntu
- 10.10 Maverick. We deploy from the excellent alestic images
. You need Apache version 2.2.16 or later to be compliant. 2.2.17 is preferred as 2.2.16 will still show up with a couple of notices (primarily related to expat vulnerabilities) but those won't affect your compliance. You could also probably find a backport of apache2 to the 10.04 LTS or compile your own. I don't know have any details on other distributions.
2A. Set up your SSL certificate directly on your instances Apache. You'll also need to disable weak ciphers and turn off SSLv2 by adding the following to your host configuration:
SSLProtocol all -SSLv2
As nice as Elastic Load Balancers support for SSL is - it unfortunately (as of right now) can't be configured in this way. Support in the API may show up at some point, see this topic on aws forums
for more details. If your using ELB, you'll have to forward port 443 to your instances via TCP - which means you can't use any of the session stickiness options normally offers for HTTP connections.
A blog article on Zen One
has some more details on the SSL issue as well as ways to test your configuration.
2B. (Or a Better solution) Ask amazon to configure a ELB with weak ciphers turned off. An Amazon rep we contacted has stated that they can modify anexisting load balancer to make it compliant - the advantage of this is that using Option 2A provides some problems with tracking the IP Addresses of incoming requests - something that is very important for fraud monitoring. We had to sign up for a support contract to open up a ticket to make this happen. This option also makes it possible to turn on session stickiness if that's something your app needs.
Next you need to actually run the scan - we used HackerGuardian
from Comodo which gives you the first scans free. It's $250/year after that for 4 quarterly scans. They also have a SAQ Wizard to help you go through the steps necessary for compliance. The SAQ is a timesink and pain in the butt but it's not unmanageable.
And with that, you'll be good to go. You'll just need to find some people who actually want to pay you (but that's the easy part, right?)