أفضل الممارسات لتخزين المعلومات المصرفية في قاعدة بيانات

Question

ملخص الإجابات:
لا تفعل ذلك. الآثار القانونية والمالية ستكون كارثية. ابحث عن حلول الطرف الثالث المنشأة أو استئجار خبير. لا تخزن أي معلومات حساسة على خادم مشترك. البحث للحصول على آلية التشفير الأنسب.

أنا أشرك موقعا على شبكة الإنترنت للعملاء الذي يحتاج إلى تخزين معلومات بنك عملائه (رقم حساب التوجيه +) في DB للإيداع المباشر. إليك بعض التفاصيل:

1) سيكون الموقع في البداية على خادم استضافة مشترك (هذا هو قلقي الأول).
2) أنا أستخدم php / mysql.
3) أخطط لاستخدام Mcrypt.
4) سيتم تحديد الموقع خارج جذر الويب.

أخبرني بأفكارك إذا سمحت. إذا كان ذلك ممكنا، يرجى تزويدني ببعض الموارد على معالجة ACH.

شكرا!

تحرير: كنت أتوقع مثل هذا الرد كما أشعر بالرعب من مشاكل الأمن هناك أيضا. لقد أعربت عن قلقي لعملي وهذا سيكون دعما جيدا.

تحرير 2: سوف المشي بعيدا عن هذا. لم يكن سعيدا بالفكرة في المقام الأول! سيحقق API الدفع الشامل في PayPal.

Answer 1

أعتقد أنه يمكنك حل هذه المشكلة دون تخزين أي معلومات مصرفية بنفسك من خلال استخدام شيء مثل PayPal's الدفع الجماهية API. وبعد بهذه الطريقة، يمكن لعملائك دفع الناس، و PayPal يخزن جميع المعلومات حتى لا تضطر إلى ذلك.

إذا كنت ترغب في القراءة حول جميع الخطوات التي تحتاجها حتى تتخذ حتى تتمتع بإمكانيات عن بعد لتأمين البيانات المالية الحساسة للعميل، Googleالامتثال PCI.'

إذا لم تكن خائفا ملاذا تخزين البيانات المالية عبر الإنترنت، فأنت ساذج فظيع.

Answer 2

1) سيكون الموقع في البداية على خادم استضافة مشترك (هذا هو قلقي الأول). --حقا سيء. عدم وجود سيطرة إدارية مطلقة على الخادم، وتكون قادرة على إبقاء أشخاص آخرين في الخارج مشكلة كبيرة حقا.

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

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

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

Answer 3

لا تفعل ذلك.

BU، إذا كان عليك، استخدم Crypto Public / الخاص Crypto. تخزين واستخدام فقط المفتاح العمومي لتشفير البيانات التي تذهب إلى قاعدة البيانات. قم بتخزين المفتاح الخاص في مكان آمن (معنى: ليس الخادم المستضاف، ولكن الجهاز المحلي "آمن" مع عناصر تحكم الوصول المناسبة). عند الضرورة، قم بتنزيل البيانات إلى الجهاز المحلي، استخدم المفتاح الخاص لفك تشفيره، وذهبت.

ولكن على محمل الجد، ابحث عن طريقة لتجنب القيام بذلك إذا كنت تستطيع.

Answer 4

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

من القلق الإضافي هو أنه ليس بيانات عميلك، إنه عملائك عميل بيانات! قد تكون قادرا على اتخاذ اتفاق مع عميلك لتعويضك، ولكن ليس عندما يشارك عملائهم. بمجرد تعرض البيانات للخطر، سيعود إليك مباشرة معك مع العملاء الذين يتنفسون عنقهم في السحب!

Answer 5

بالنسبة إلى المعلومات المصرفية، يجب أن يكون الخادم الخاص بك في سيطرته غير مشتركة.

أيضا، mcrypt ليست آمنة للغاية. أعلم أنه مبني لكنني أقترح شيئا غير قابل للقرصنة مثل RSA. إذا كان شخص ما يحصل على المعلومات، فلا ينبغي أن يكونوا قادرين على اختراقها دون مفتاح خاص.

Answer 6

وأنا أتفق مع الآخرين - هذه فكرة سيئة للغاية.

يمكن أن تكون الخوادم المخصصة لمدة تتراوح بين 79 إلى 99 دولارا أمريكيا في الشهر، إذا لم يكن هذا غير متناول الجميع، فأنا أتساءل حقا لماذا تعالج المعلومات المصرفية لتبدأ. ستكون الطريقة المفضلة هي الحصول على قاعدة البيانات منفصلة من مربع الويب في هذه الحالة أيضا. ويفضل أن يكون مع بعض جدران الحماية وحماية أخرى بينهما (أي جدران جدراني، واحد أمام خادم الويب، والآخر بين خادم الويب وقاعدة البيانات).

ولكن أي شيء سيكون أفضل من استخدام الاستضافة المشتركة. أعني، يمكنك توصيل الحق في SQL Server وشاهد جميع قواعد البيانات المتاحة - ما مدى سهولة القفز في الحق في الحد الأدنى من القرصنة؟

أيضا، من فضلك قل لي اسم الموقع لذلك أنا لا أشعل أبدا ووضع معلومات المصرفية الخاصة بي !!! :)

أيضا، تأكد من أن لديك أخطاء وتأمين أبعاد قبل المضي قدما مع استضافة مشتركة.

Answer 7

كنت مواجهة وضع مماثل مثلك، وحلها بهذه الطريقة.

1. نظرا لأنك لن تقوم بمعالجة ACH، اكتشف ما إذا كان لدى ARC معالجة API القدرة على إنشاء عميل.
2. إذا كانت الإجابة بنعم، فإن كائن العميل هذا، سيتضمن عادة رقم الحساب ورقم التوجيه، إلخ، وتخزين الرمز المميز في قاعدة البيانات الخاصة بك. (لذلك عندما يعطي المستخدم معلوماته، يمكنك تمريرها مباشرة إلى معالج ACH عبر HTTPS، وحفظ الرمز المميز).
3. كلما اضطررت إلى الخصم من حسابها، قم بتمرير هذا الرمز المميز إلى المعالج، وهذا كل شيء !!

بهذه الطريقة، لا تقم بإنقاذ أي حساب وأرقام توجيه في قاعدة البيانات الخاصة بك، وحتى إذا كان شخص ما يختار DB، فإنهم يرون فقط الرمز المميز، وهو أمر عديم الفائدة للغاية - لا يستطيعون فعل أي شيء معها، كما هو محدد المعالج ACH.

لقد فعلت مماثلة لبطاقات الائتمان باستخدام شريطية.

حظ سعيد!

Answer 8

ليس لديك خبرة في هذا المجال، ولا يمكنك حتى العثور على علب من الديدان هذه كبيرة في نادي مستودع. هذه هي الحالة التي يحتاجها عميلك إلى استئجار خبير مجال؛ إذا كنت مهتما بالقيام بهذا النوع من العمل في المستقبل، فحاول العمل عن كثب مع الخبير وامتصاص الكثير من المعرفة قدر الإمكان.

Answer 9

أعتقد أن الجميع هنا قد أعلنوا عن كرههم من الوضع بما فيه الكفاية، لذلك سوف أسقط تلميحا فقط في مشكلة أخرى عند القيام بأي نوع من التشفير (الذي نوافق عليه ضروري):

يجب تشفير البيانات في مكان ما!

إذا قمت بذلك على الخادم، فستفعل الخادم الخاضع للخطر فقط تشفيرك وتمريرها على ث / س تشفيرها.

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

في النهاية: إذا كنت تفكر حقا في القيام بذلك على خادم قد لا يكون آمنا 110٪، امش بعيدا.