Begin forwarded message:
> From: Daniel Beatty <danielbea...@mac.com> > Date: August 27, 2010 4:10:34 AM EDT > To: David BON <bo...@mac.com> > Cc: Daniel Beatty <danielbea...@mac.com> > Subject: Re: Cloud Computing and PCI Compliance > > > > Greetings David, > I would have to agree with you. The combination of PayPal and SAML2 (such as > Shibboleth) would allow such a thing to be true. The Shibboleth > implementation would allow the site to remove all but the references to the > IdP and since PayPal also abides by this also, then the references by the > Cloud hosted web app would be small. I would think the last hitch on this > would be backups of the web app's database would the last piece of that PCI > compliance jigsaw puzzle. But, that is just me rambling with logic. > > Later, > Dan > > On Aug 23, 2010, at 8:54 AM, David BON wrote: > >> If you use Paypal services for example (or another Internet Payment >> Gateway), I suppose that they are already Level 1 compliant, no ? In that >> case, you don't need to maintain any cardholder information in your own >> system and could be then easily PCI compliant even using the cloud computing? >> >> Did I miss something? >> >> Regards. >> >> David B. >> >> Le 23 août 10 à 12:43, Kieran Kelleher a écrit : >> >>> My colleague at work who looks after PCI compliance sent me this >>> interesting info, which clarifies a lot. >>> >>> • PCI Compliance Level 1 - Merchants processing over 6 million Visa >>> transactions annually (all channels) or Global merchants identified as >>> Level 1 by any Visa region >>> • PCI Compliance Level 2 - Merchants processing 1 million to 6 million >>> Visa transactions annually (all channels) >>> • PCI Compliance Level 3 - Merchants processing 20,000 to 1 million >>> Visa e-commerce transactions annually >>> • PCI Compliance Level 4 - Merchants processing less than 20,000 Visa >>> e-commerce transactions annually and all other merchants processing up to 1 >>> million Visa transactions annually >>> >>> >>> As he said, and based on our average transaction of about $100, "If we get >>> to a level one, we will have enough money to have an OC3 pipe, all the >>> equipment we need and a full IT department!" .... :-) >>> >>> Based on some other internet "research", a possible approach to deal with >>> this scenario might be building a hybrid cloud architecture having most of >>> the deployment in the could while having a separate secure webservices >>> application hosted physically and securely inhouse for storing the >>> encrypted cc records and processing the credit card transactions >>> themselves. The remote apps would merely send a request to that internal >>> webservices app where the request might have the CCInfo PK and an >>> transaction amount/id for processing, the cloud app would ping cc >>> webservices app every few seconds for transaction status and finally get >>> the result. Such an approach would compartmentalize PCI in a manageable way >>> it would seem. Of course credit cards would still be submitted through >>> forms in the cloud app, but never stored there, from there it would be >>> encryption of the cc info and transmission back to the internal webservices >>> app for permanent storage and or requests to perform cc transactions. >>> >>> Any opinions on that? >>> >>> >>> -Kieran >>> >>> >>> >>> >>> On Aug 22, 2010, at 5:43 PM, Simon wrote: >>> >>>> To be compliant you would need to do your card processing elsewhere that >>>> can provide such a guarantee. >>>> >>>> no, that's not necessarily the case. it depends on what level of pci >>>> compliance you require. checkout the official amazon response on the >>>> following thread. they confirm you can build up to level 2 compliance on >>>> amazon web services. >>>> >>>> http://developer.amazonwebservices.com/connect/message.jspa?messageID=139547 >>>> >>>> level 1 is the only one that can't be achieved because of the on-site >>>> visit requirement. but IIRC that's only necessary if you are processing >>>> over 6 million cards per annum. >>>> >>>> simon >>>> >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>> Help/Unsubscribe/Update your Subscription: >>>> http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%40mac.com >>>> >>>> This email sent to kieran_li...@mac.com >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/bon_d%40mac.com >>> >>> This email sent to bo...@mac.com >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/danielbeatty%40mac.com >> >> This email sent to danielbea...@mac.com > > Dan Beatty, M.S. CS (B.S. EECS) > Ph.D. Student > Texas Tech University > dan.bea...@mac.com > http://web.me.com/danielbeatty/My_Home_Page/Welcome.html > (806)438-6620 > > > > > > > > >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
