☄️ 🛰️ 🧑🏿‍🤝‍🧑🏽 انشقاق العيوب ليس مجرد عشوائية 🤚 🍏 🖊️

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

يبدو أن مجرد تغيير كل شيء إلى بعض التجزئة غير المتكافئة يكفي وكل شيء سيكون على ما يرام.

لذلك ، لن يحدث ذلك.

والحقيقة هي أن قاعدة بيانات البنك هي مجموعة من الجداول المترابطة. في مكان ما يتم توصيلهم بالاسم ورقم حساب العميل. في مكان ما من خلال معرفها الفريد. في مكان ما (هنا يبدأ الألم) من خلال إجراء مخزن يحسب معرف التمرير بناءً على هذا والجدول المجاور. إلخ.

الوضع المعتاد هو أن مطور الإصدار الأول من النظام قد مات بالفعل أو غادر قبل عشر سنوات ، وأنظمة النواة التي تعمل في برنامج Hypervisor القديم داخل برنامج Hypervisor الجديد (لضمان التوافق) لا تزال في المنتج.

أي ، قبل إخفاء هوية كل هذا ، تحتاج أولاً إلى فهم قاعدة البيانات.

من يفعل نزع الطابع الشخصي ولماذا؟

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

أي نزع شخصية هو طبقة باهظة الثمن وغير مكلفة بين الأنظمة الإنتاجية واختبار التطوير.

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

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

كيف يتم استبدال البيانات؟

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

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

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

لذا ، لنفترض ، بعد كل هذا ، أننا نرى جدولًا به حقل "الاسم". قام المعالج بالفعل بوضع علامة عليه لنا كاسم ، ولا يمكننا سوى تأكيد واختيار نوع نزع الشخصية. يوفر Wizard استبدالًا عشوائيًا للأسماء السلافية (هناك قواعد لمناطق مختلفة). نحن نتفق ونحصل على بدائل مثل Ivan Ivanov Petrenko - Joseph Albertovich Chingachguk. إذا كان هذا مهمًا ، يتم الاحتفاظ بالجنس ، إذا لم يكن كذلك ، يتم استبدال البدائل عبر قاعدة بيانات الأسماء.

أمثلة على البدائل:

. ->
->
->
->
-> -

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

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

ما الذي يحدث في الداخل؟

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

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

بعد انتهاء العملية ، تبقى جداول التحويل في قاعدة البيانات المحمية لخادم إلغاء تخصيص الشخصية. يتم قطع القاعدة (مبتورة) وتمريرها للاختبار بدون جداول تحويل ، وبالتالي ، بالنسبة للاختبار ، يصبح نزع الطابع الشخصي لا رجعة فيه.

يتم تمرير قاعدة البيانات المجهولة بالكامل إلى المختبرين لاختبار الإجهاد.

هذا يعني أنه أثناء العمل مع قاعدة البيانات ، "يتضخم" جدول التحويل (يعتمد المبلغ المحدد على اختيار البدائل ونوعها) ، لكن قاعدة العمل تبقى بالحجم الأصلي.

كيف تبدو العملية في واجهة المشغل؟

نظرة عامة على IDE باستخدام أحد البائعين كمثال:

المصحح:

بدء التحول من IDE:

تكوين تعبير للبحث عن البيانات الحساسة في ملف التعريف:

صفحة تحتوي على مجموعة من القواعد للملف الشخصي:

نتيجة ملف التعريف ، صفحة الويب مع بحث البيانات:

هل جميع البيانات الموجودة في قاعدة البيانات مقنعة؟

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

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

استراتيجيات المثال:

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

هل من الممكن تغيير البيانات باستخدام DBMS نفسه؟

نعم. عند نزع الطابع الشخصي عن البيانات ، هناك طريقتان رئيسيتان - تغيير البيانات في قاعدة البيانات باستخدام قاعدة البيانات نفسها أو تنظيم عملية ETL وتغيير البيانات باستخدام برنامج تابع لجهة خارجية.

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

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

تظهر الممارسة أنه إذا كان لدى العميل مجموعة من العديد من الأنظمة التي تتطلب مزيدًا من التكامل ، عندها يمكن تنفيذ النهج الثاني فقط للتكلفة النهائية في المال ، وكذلك لأوقات التطوير المقبولة.

أي أنه يمكننا القيام بأي شيء نريده ، لكن نهج ETL أثبت جيدًا في القطاع المصرفي.

ولماذا لا تفسد البيانات ببساطة يدويًا؟

يمكن القيام بذلك مرة واحدة. سيجلس شخص ما لمدة ثلاثة أيام ، وينزع شخصية مجموعة من البيانات ويعد قاعدة بيانات من 500-1000 سجل. تكمن الصعوبة في أن العملية يجب أن تتكرر بانتظام (مع كل تغيير في بنية قاعدة البيانات وظهور الحقول والجداول الجديدة) وبكميات كبيرة (لأنواع مختلفة من الاختبارات). هناك طلب شائع يتمثل في إلغاء تخصيص أول 10-50 جيجا بايت من قاعدة البيانات بحيث يقع هذا المبلغ على كل جدول بالتساوي.

ماذا تفعل إذا تم تخزين عمليات مسح المستندات في قاعدة البيانات؟

إذا كان من الممكن اختزال مستند إلى XML وإعادة تحويله (على سبيل المثال ، مستندات المكتب) ، يمكنك أيضًا إلغاء تخصيصها. ولكن في بعض الأحيان هناك ثنائيات مثل مسح جوازات السفر في PDF / JPG / TIFF / BMP. في هذه الحالة ، تتمثل الممارسة المقبولة عمومًا في توفير مستندات مماثلة مع نص برمجي تابع لجهة خارجية واستبدال المستندات الحقيقية بعينات من قاعدة المستندات التي تم إنشاؤها عشوائيًا. أصعب شيء هو مع الصور ، ولكن هناك خدمات مثل هذه تحل المشكلة بنفس الطريقة تقريبًا.

من المناسب لماذا؟

عند التحديث بعد تغيير البرنامج أو "اللحاق" ، تكون العمليات أبسط.

ولكن ماذا لو حدث خطأ ما في الاختبارات؟

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

كيف تشاهد العرض؟

أسهل طريقة هي مراسلتي عبر البريد الإلكتروني على PSemenov@technoserv.com.

انشقاق العيوب ليس مجرد عشوائية