[Seaside] Anyone familiar wityh PCIDSS?

[Paul DeBruicker]

I don't know.  It would be good to know. Hopefully there's a way to 
learn without going through an audit first.

Here are some ideas about ways to store it that may get around the issue:

1.  Use a MySQL (or whatever) database on another machine to store the 
credit card info.

2.  Use Braintree's Vault product 
(https://www.braintreepayments.com/tour/vault) which just stores the 
info safely in a payment processor agnostic way.

3.  Use Stripe (http://www.stripe.com) if you don't have a merchant 
account or don't need one yet.   I've made a Pharo/Gemstone package 
here: http://www.squeaksource.com/Stripe.html I think they charge 2.9% + 
$0.30 per transaction

4.  Maybe putting your externally facing webserver (e.g. apache) on 
another machine and referring to your Pharo/Gemstone installations as 
the app server/ database server is enough for separation of concerns.





On 07/25/2012 10:15 AM, James Foster wrote:
> The Payment Card Industry Data Security Standard (https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf) specifies in section 2.2.1: "Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)"
>
> My interpretation is that this does not specify the application server, so it can be co-located with the database server. I just talked to someone who thinks that it is fine to put the application server with the web server but not with the database server. If the application server and the database server have to be on separate machines, then this would prohibit image-based persistence (whether Pharo or GemStone).
>
> Any comments?
>
> James Foster
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>