امتثال PCI و Ajax

Question

لدي هذه الفكرة ، لكنني غير متأكد مما إذا كانت متوافقة مع PCI. أنا جديد على ساحة الامتثال PCI وأصبح فضوليًا لمعرفة ما إذا كان هذا السيناريو ينتهك PCI.

لذلك ، دعنا ننشئ السيناريو. الشركة A متوافقة مع PCI ولديها خدمة ويب على HTTPS تعرض أجزاء من الوظائف حول معالجة الدفع. الشركة ب ليست متوافقة ، لكن موقعها على الإنترنت آمن.

فيما يلي خطوات السيناريو.

1. يات مع موقع الويب الخاص بـ B's Webservice عبر رمز جانب الخادم. ترسل هذه الخدمة رمزًا مشفرًا.
2. B حقن هذا الرمز المميز في صفحة تحتوي على نموذج لقبول معلومات بطاقة الائتمان.
3. يدخل المستخدم معلومات بطاقة الائتمان الخاصة بهم على موقع B.
4. يتم إرسال معلومات النموذج ، جنبًا إلى جنب مع الرمز المميز ، عبر مكالمة AJAX إلى خدمة الويب الخاصة بـ A.
5. تعمل خدمة الويب الخاصة بـ A على البيانات وتجمع الحالة (معتمدة/رفضت/إلخ)

والسؤال هو ، لأن JavaScript ينتقل مباشرة من جهاز المستخدم إلى الخوادم المتوافقة مع الشركة A ، هل هو متوافق مع PCI؟ أنا مهتم جدًا بمعرفة ما يعتقده الخبراء في هذه الساحة.

Answer 1

كتيب على PCI DSS جميع ال معايير PCI

يحتوي PCI DSS (معيار بيانات بيانات صناعة بطاقة الدفع) على مفهوم "تحديد النطاق" - تحديد الأنظمة التي تأتي تحت مظلة PCI.

هل أنت تاجر أم بائع برامج؟إذا لم يتم إرسال PAN (رقم الحساب الأساسي) ، وهو رقم بطاقة الائتمان الطويلة ، إلى موقع الويب الخاص بك ، فعادةً ما لا يكون موقع الويب الخاص بك ضمن نطاق PCI. - على افتراض أنك التاجر. إذا كنت بائعًا برامج ، فمن المحتمل أن يكون برنامجك في نطاق PA-DSS (انظر أدناه).

PAN Transing الخاص بك الخادمكانت الفكرة القديمة هي أنه سيتم إرسال المقلاة إلى موقع الويب الخاص بك (من خلال تقديم نموذج المتصفح) ، ثم يدور موقع الويب الخاص بك وإرساله إلى بوابة الدفع (على سبيل المثال ، Outlize.NET). في هذا السيناريو ، لم يتم تخزين المقلاة على الخادم الخاص بك ، لكنه فعل عبور الخادم الخاص بك. كان هذا يعني أن أنظمة التاجر الخاصة بك لن تكون تحت نطاق PCI DSS لأنها لم تخزين المقلاة أبدًا. لكن تلك الأيام تنتهي بسرعة أو اختفت بالفعل. (وهو ما يعتمد على مدى عدوانية مورد حسابك/التاجر حول PCI.)

التحكم في صفحة الويب الخاصة بك نظرًا لأن صفحة الويب الخاصة بك لا تنقل أي مقلاة إلى الخادم الخاص بك ، فأنت لست في نطاق PCI. ولكن كيف تعرف أن شخصًا ما لم يغير صفحة الويب الخاصة بك لنقل المقلاة إلى الخادم الخاص بك (أو في أي مكان آخر ، باستخدام تقنيات JSONP)؟ الجواب هو أنك بحاجة إلى أن تؤكد لنفسك أنه لن يلعب أي شخص مع صفحة نماذج الدفع الخاصة بك.

كيف تؤكد لك هذا الأمر متروك لك. يمكنك استخدام تقنيات PCI أو تقنيات أخرى. هذه مسألة أمان الكمبيوتر الداخلي والتدقيق.

معيار أمان بيانات تطبيق الدفع (PA-DSS) إذا قمت ببيع SW الخاص بك للتجار ، فربما يكون ذلك ضمن نطاق معيار PA-DSS. انظر اساسي.

PCI سياسي ، وليس تقني تذكر أن PCI النطاق متروك لك. إذا كنت تاجرًا كبيرًا بما فيه الكفاية ، فستحتاج أيضًا إلى العمل مع QSA (مقيم أمن مؤهل) يقوم بمراجعة وموافق لخطة امتثال PCI و LACPING.

من الممكن بالتأكيد أن تقول QSA أنه نظرًا لأنك تتحكم في صفحة الويب الخاصة بك ، يجب أن تكون تحت PCI لأنه قد يفسد شخص ما. ولكن هذا سيكون حجة انتهازي. بعد كل شيء ، يمكنك بعد ذلك القول أن كل صفحة ويب من أي تاجر إنترنت تحتاج إلى أن تكون تحت PCI لأن أي صفحة ويب يمكن أن تفسد لمطالبة الناس بالقيام بالقيام بشيء سيء معها. من ناحية أخرى ، هذا هو بالضبط نوع الحجة التي تستخدمها VISA لزيادة نطاق PCI لصالح أصحاب الامتياز للشركات. مقالة - سلعة.

شهادة PCI ليست عذرا لاحظ أيضًا أن جمعيات البطاقات تحتفظ بالحق في طردك إذا كان لديك اقتحام-حتى لو كنت متوافقًا مع PCI. لذلك تريد أن تتأكد من أنك هدف أكثر صرامة من أي شخص آخر على كتلةك.

إضافة: المزيد عن النطاق كما يمكنك معرفة ما سبق ، فإن المشكلة الرئيسية هي أنظمة موجودة أو خارج نطاق PCI. لدى مجلس PCI الآن مجموعة مصلحة خاصة (SIG) التي تفحص هذا العدد الكامل لما هو موجود وما هو خارج نطاق PCI. وأظن أنهم سيريدون أن ينمو المظروف ، وليس يتقلص.

إضافة: إنه بينك وبين محاميك سيناريو الخاص بك هو بداية معالجة المقلاة التي تم على متصفحات عملائك. لا يصل المقلاة أبدًا إلى أنظمتك ، ولا حتى للحظة. لذا فإن تفسيري هو أنك خارج نطاق Merchant PCI DSS. لكنك الشخص الذي يوقع على بيان الامتثال PCI وهو عقد بينك وبين مستحوذك. لذلك الأمر متروك لك ومحاميك لتفسير معيار PCI DSS ، وليس أنا.

الحد الأدنى يجب ألا تقوم أبدًا بتخزين البيانات على أنظمتك. لا يجب أن تتجول في أنظمتك. تتيح بروتوكولات بوابة الدفع الجديدة من Offect.net و Braintree تقنية عدم النقل. اعتمادًا على حجم معاملات بطاقات الائتمان الخاصة بك ، يختلف امتثال PCI من قائمة مراجعة ذاتية الإدارة إلى مشروع ضخم.

لمزيد من قصص حرب PCI ، تحقق من storefrontbacktalk بلوق وهم تغطية PCI.

Answer 2

إجابة لاري ك جيدة. إنه في الغالب شيء سياسي/طبقة.

يبدو أن استخدام iframe للنشر من B إلى A هو حل مقبول ، في حين أن استخدام Ajax - مع CORS أو JSONP - هو أكثر شكلاً إلى حد ما ولكنه لا يزال ، على الأقل بالنسبة لبعض اللاعبين الكبار ، مقبولًا.

ال ملحق المعلومات: إرشادات التجارة الإلكترونية PCI DSS تتساقط طبقات V2 أن نقول أن هذا الحل (API المباشر) على ما يرام ولكنك أنت ينبغي احرص على الحصول على رمز بأمان (على الرغم من أن PCI DSS لا يصف أي شيء ملموسة تحتاج إلى القيام به) - انظر القسم 3.4.3.1 أوجه واجهات برمجة التطبيقات المدمجة الجهة الثالثة مع وظيفة مباشرة وذوي الصلة 3.4.3.4 اعتبارات أمنية لتطبيقات التجارة الإلكترونية المشتركة, الذي يقرأ:

نهج واجهة برمجة التطبيقات المباشرة: مع نهج واجهة برمجة التطبيقات المباشرة ، لا يزال التاجر مسؤولاً عن صفحة الويب التي يتم تقديمها إلى المستهلك ، ويستضيف التاجر الحقول الموجودة في صفحة الدفع التي تقبل البيانات-فقط تم نشر بيانات حامل البطاقة مباشرة من المستهلك إلى مزود الخدمة. نظرًا لاستضافة صفحات الدفع من قبل التاجر ، فإن صفحات الدفع آمنة فقط مثل موقع الويب الخاص بالتاجر ، ويمكن أن يؤدي حل وسط لنظام التاجر إلى حل وسط لبيانات بطاقة الدفع. ... على وجه التحديد ، بالنسبة لجميع السيناريوهات المذكورة أعلاه ، يجب على التاجر مراقبة أي دليل على أن الأنظمة قد تغيرت وتستجيب بسرعة لاستعادة الأنظمة إلى حالة موثوقة عند اكتشاف تغييرات غير مصرح بها. يجب أن يكون التجار الذين يتبنون هذه النماذج التي يتم الاستعانة بمصادر خارجية للإدارة المشتركة لتقليل متطلبات PCI DSS المعمول بها على دراية بالمخاطر المحتملة التي تكون متأصلة في هذه الأنواع من بنية النظام. لتقليل فرصة الهجوم في هذه السيناريوهات ، يجب على التجار تطبيق العناية الواجبة الإضافية لضمان تطوير تطبيق الويب بشكل آمن ويخضع للاختبار الشامل للاختراق.

على سبيل المثال تستخدم بوابة الدفع الشريطية مباشرة على JSONP منذ عام 2012 بدلاً من نهج iframe الذي استخدموه من قبل.

من ناحية أخرى ، يوفر WePay أيضًا واجهة برمجة تطبيقات مباشرة مع IFRAME للتخلص تمامًا من متطلبات PCI [WP] (مدعيا ذلك مع واجهة برمجة تطبيقات المباشر "" مع واجهة برمجة التطبيقات (API) المباشرة "..] لا يزال يتعين عليك أن تكون متوافقًا مع معايير أمان بيانات صناعة بطاقة الدفع (PCI-DSS) ومعايير أمان بيانات تطبيق الدفع (PA-DSS) كلما تم تطبيقه."(دون تحديد ما هو بالضبط" كلما قابلة للتطبيق "يعني).

WP] رابط WePay: https://www.wepay.com/developer/tutorial/tokenization

Answer 3

لقد مررت مؤخرًا ببعض أعمال امتثال PCI لخوادمنا ، لذلك هذا أمامي مباشرة. الجواب القصير هو لا.

يتطلب الامتثال PCI أن تلبي كل خطوة من المسار الذي تمر من خلاله المعلومات الحساسة متطلبات PCI في حد ذاته. يمكن أن يكون هناك شيء آمن ولكنه غير متوافق ، كما لاحظت فيما يتعلق بالشركة B. لأنك ذكرت بالفعل أن الشركة B ليست متوافقة غير متوافق.

ما إذا كانت خدمة امتثال PCI تربط هذه النقاط فعليًا وكيف يمكن أن تصدقها على أنها تمرير أو فشل قد تكون مسألة أخرى.

Answer 4

بغض النظر عما إذا كان "من الناحية الفنية" يفي بمعايير PCI (أو لا) ، فلن أضع ثقتي في هذه الطريقة في القيام بالأشياء.

إذا كان النموذج موجودًا على صفحة ضمن اسم المضيف لـ B ، فإن B لديه وصول كامل إلى ما هو في حقول النماذج. (خادم B قادر على إرسال javaScript الخبيث للمستخدم إذا أراد ذلك.)

تتمثل الطريقة الأكثر أمانًا في القيام بذلك (من حيث حماية أرقام بطاقات الائتمان) في وضع النموذج تمامًا ضمن اسم مضيف خدمة معالجة الدفع بدلاً من اسم مضيف غير موثوق به.

Answer 5

ها هو موقع PCI

في الأساس ، إذا تمكنت من رؤية رقم البطاقة أو أي معلومات تعريف حول البطاقة ، فستحتاج إلى الامتثال لمتطلبات PCI. لست متأكدًا من أنهم بالضرورة وثيقة قانونية "حتى الآن" ، ولكن إذا تم العثور عليك في انتهاك ، يمكن إلغاء قدرتك على المعالجة ، أو أن تكون جزءًا من عملية المعاملات. علاوة على ذلك ، يمكنك التوقيع على اتفاقية حول مسؤوليتك واخترت عملية حيث يمكن لشركات بطاقات الائتمان أن تتناسب معك. كل ذلك لامتياز قبول بطاقات الائتمان.

للمتعة هنا رابط (PDF) إلى 38 صفحة 'مرشد سريع.