ملاحظات المنتج
أين تُحفظ البيانات الشخصية؟
بدأ هذا التصميم من موقف مزعج يتكرر أثناء التشغيل: التحقيق في فشل تسجيل الدخول ورؤية معلومات لم تكن بحاجة إلى الاطلاع عليها.
حين يكشف التحقيق معلومات لا تحتاج إليها
عند تشغيل منصة للهوية، يتكرر طلب مثل: «أحد المستخدمين لا يستطيع تسجيل الدخول». ولتشخيص المشكلة، تدخل إلى بيئة العميل وتبحث عن الحساب.
ما تحتاج إلى معرفته محدد: هل الحساب مقفل؟ متى فشلت المحاولة الأخيرة وفي أي خطوة؟ ما مسار تسجيل الدخول المستخدم؟ وهل ما زال مفتاح المرور مسجلاً وصالحاً؟
لا يتطلب أي من ذلك معرفة هوية الشخص. ومع ذلك، يظهر الاسم والبريد الإلكتروني ورقم الهاتف والحسابات المرتبطة فور فتح الحساب. كنت تبحث عن حالة تقنية، فوجدت معلومات عن الشخص أيضاً.
«يرجى عدم النظر» ليست وسيلة حماية
إذا كانت المعلومة معروضة بالفعل.
لم يخالف أحد الإجراءات. طلب العميل التحقيق، واتبع الموظف الخطوات الصحيحة، ومع ذلك ظهرت البيانات. بنية النظام هي التي وضعتها أمامه.
الاعتماد على التعليمات والتدريب وحدهما يجعل الحماية رهينة ذاكرة الموظف وانتباهه. فصل البيانات الشخصية في Authrim بدأ بمحاولة حل هذه المشكلة في بنية النظام نفسها.
قاعدتان منذ بداية التصميم
تُحفظ المعلومات التي تحدد الشخص مباشرة في قاعدة بيانات منفصلة فعلياً. الفصل موجود منذ طبقة الوصول إلى البيانات، وليس إضافة لاحقة.
بهذا الفصل يمكن حل المشكلة الأولى. حالة القفل ومحاولات الدخول الفاشلة ومعلومات الأجهزة متاحة في جانب Core DB. يمكن منح صلاحيات التحقيق دون إتاحة جانب PII DB، فلا يحتاج الموظف إلى تجنب النظر عمداً.
وتساعد البنية نفسها في الإجابة عن أسئلة التدقيق: أين تُحفظ الأسماء وعناوين البريد؟ وما نطاق الحذف؟ حل المشكلة التشغيلية جعل التصميم أسهل في الشرح أيضاً.
ليست PII DB المكان الوحيد الذي يحتوي على بيانات شخصية
هذه نقطة أساسية: الفصل ليس حداً قانونياً بين البيانات الشخصية وغير الشخصية.
تحتوي Core DB أيضاً على عناوين IP ومعلومات الأجهزة وتاريخ الجلسات وأحداث المصادقة والبيانات الوصفية لبيانات الاعتماد ومعرّفات المستخدمين الداخلية المستقرة. وقد تُعد هذه بيانات شخصية بحسب السياق. فالجمع بينها وبين معلومات أخرى قد يحدد شخصاً.
يفصل Authrim بين البيانات التي تحدد الشخص مباشرة وبيانات الهوية اللازمة للتشغيل. الهدف هو إجراء التحقيق باستخدام الثانية دون الوصول إلى الأولى، وليس إعفاء الثانية من الحماية.
لذلك لا يصح القول إن البيانات الشخصية لا توجد إلا في PII DB. الأدق أن الأسماء والبريد الإلكتروني وغيرها من المعرّفات المباشرة معزولة فيها، بحيث يمكن منح وصول للتحقيق دون فتح ذلك التخزين.
الحذف هو الخطوة الأولى فقط
تنفيذ طلب حذف حساب أمر مباشر. الأصعب هو تلبية الطلبين اللذين قد يأتيان بعده.
الأول هو إثبات الحذف: متى جرى، ومن نفذه، ولماذا. والثاني هو منع إعادة التسجيل خلال فترة محددة.
كلا الطلبين يحتاج إلى التعرف على شخص حُذفت بياناته. لكن إبقاء المعلومات التي تحدده مباشرة يتعارض مع غرض الحذف.
هذا هو مبدأ التنفيذ: الاحتفاظ بالبصمة اللازمة لمنع التكرار فقط، وحذفها بعد انتهاء المدة، مع تسجيل وقت الحذف ومن نفذه وسببه.
متى يصح القول إن القيمة غير قابلة للاسترجاع؟
توضيح تقني: عناوين البريد الإلكتروني منخفضة الإنتروبيا. إذا استُخدمت تجزئة عادية فقط، فقد يكشف هجوم بالقاموس العنوان الأصلي. عدم الاسترجاع ليس ضماناً بلا شروط.
يستخدم Authrim فهرساً معمى بـHMAC-SHA256 ومفتاح سري، مع رقم جيل للمفتاح يسمح بتدويره. دون المفتاح، لا يمكن اختبار العناوين المحتملة بإعادة حساب بصماتها.
إذن عزل المفتاح شرط لهذه الحماية. تخزينه مع البصمات يُفقد هذا الضمان.
إتاحة ما يحتاج إليه التحقيق فقط
لنعد إلى بلاغ تعذر تسجيل الدخول. يحتاج المحقق إلى تحديد موضع توقف المصادقة، ولا يحتاج عادة إلى فتح الاسم أو رقم الهاتف.
يفصل Authrim معلومات التعريف المباشر كي تُمنح صلاحيات التشخيص دون الوصول إلى مخزنها. وإذا احتاج التحقيق فعلاً إلى بيانات شخصية، يتولاها شخص يملك الصلاحيات الإضافية المناسبة.
يحمي التشفير والتحكم في الوصول البيانات، وتسجل سجلات التدقيق استخدامها. وإلى جانب ذلك، ينبغي أن يتمكن الموظف من إنهاء التحقيق المعتاد دون فتح بيانات شخصية لا يحتاج إليها. يجعل فصل التخزين هذه الحالة نقطة انطلاق العمل اليومي.
التنفيذ: فصل التخزين وحدود الوصول مطبّق.
التحقق: تغطيه الاختبارات الآلية في المستودع.
النضج التشغيلي: أعمال التعزيز مستمرة. Authrim ما زال في مرحلة ما قبل 1.0.
يسهّل هذا التصميم إجراءات الحذف، لكنه لا يشكل بحد ذاته ضماناً للامتثال القانوني. يتوقف ذلك أيضاً على إجراءات المؤسسة وعقودها.