تتضمن اليوم كل العروض التجارية تقريبًا لأدوات التسجيل أو الأرشفة أو التدقيق عبارة «غير قابل للتغيير»: تخزين غير قابل للتغيير، وسجلات (logs) غير قابلة للتغيير، ونسخ احتياطية غير قابلة للتغيير. تنقل العبارة شعورًا بالأمان، ولهذا تتكرر كثيرًا. المشكلة أنها تصف خاصية في نظام المورّد، لا ما يحتاج المدقّق أو الجهة التنظيمية أو المحكمة إلى رؤيته: إثبات يمكن تأكيده باستقلالية.
هذا الدليل موجّه لفرق الأمن والامتثال والمشتريات التي تحتاج إلى تقييم ادعاءات سجلات التدقيق. وليس الغرض منه التقليل من شأن عدم قابلية التغيير، فهي مفيدة وضرورية في أحيان كثيرة، بل الفصل بين سؤالين يُخلط بينهما عادةً: «هل يمكن تغيير هذا السجل؟» و «هل أستطيع أن أثبت لطرف ثالث أنه لم يُغيَّر؟»
خاصيتان مختلفتان
عدم قابلية التغيير ضابط وقائي. يحاول نظام تخزين WORM (write once, read many)، أو قفل الكائنات بفترة احتفاظ، أو قاعدة بيانات append-only منع تعديل السجل أو حذفه بعد كتابته. وإذا عمل الضابط كما هو موعود، يبقى السجل.
قابلية التحقق خاصية تتعلق بالأدلة. وتعني أن أي طرف معني، بالمعلومات المناسبة، يستطيع تأكيد أن السجل اليوم مطابق تمامًا لما كان عليه في لحظة محددة، دون الاضطرار إلى الوثوق بكلام من يحتفظ به. ويقوم التحقق عادةً على بصمات رقمية تشفيرية (دوال التجزئة) وأختام زمنية ونقطة مرجعية لا تتحكم فيها وحدها الجهة التي أنتجت السجل.
الخاصيتان متكاملتان، لكن إحداهما لا تغني عن الأخرى. فقد يكون النظام غير قابل للتغيير ومع ذلك لا يتيح أي وسيلة لإثبات ذلك خارج النظام نفسه. وقد يكون السجل قابلًا للتحقق حتى لو حُفظ على وسيط عادي، شرط أن تكون بصمته الرقمية قد ثُبّتت في موضع مستقل.
عدم قابلية التغيير وعدٌ بشأن سلوك نظام. وقابلية التحقق إثبات يستطيع طرف ثالث أن يتأكد منه بنفسه.
لماذا لا يكفي «غير قابل للتغيير» في التدقيق
تبقى الثقة موضوعة في المشغّل
حين يؤكد مورّد أن السجلات غير قابلة للتغيير، يعتمد الضمان على صحة إعداد النظام، وعلى صلاحيات من يديره، وعلى غياب الأعطال. وتتضمن كثير من آليات الاحتفاظ أوضاعًا تتيح لمستخدمين ذوي امتيازات خاصة تقصير الاحتفاظ أو إزالته. وحتى في أشد الأوضاع صرامة، يظل الضمان ادعاءً بشأن نظام لا يتحكم فيه المدقّق.
عدم قابلية التغيير لا يقول شيئًا عما كُتب
السجل غير القابل للتغيير يحفظ بأمانة ما وُضع فيه. فإذا كانت البيانات قد جرى العبث بها لحظة الكتابة، أو لم يُسجَّل حدث قط، أو أخفقت عملية آلية بصمت لساعات، فإن الوسيط غير القابل للتغيير يحفظ هذا الواقع الناقص بالصرامة نفسها. والسؤال المهم ليس «هل غُيِّر لاحقًا؟» فحسب، بل أيضًا «هل هو كامل ويطابق المصدر؟».
يجب أن يبقى الإثبات بعد زوال النظام
قد تقع عمليات التدقيق والنزاعات والتفتيشات التنظيمية بعد سنوات من الوقائع. وفي ذلك الحين، قد يكون المورّد الأصلي قد استُبدل، وقد يكون النظام قد رُحِّل، وقد لا يكون من أعدّوه ما زالوا في المؤسسة. نادرًا ما يصمد ادعاء عدم قابلية التغيير أمام الترحيل. أما الإثبات القابل للتحقق فيصمد، شرط توثيق طريقة التحقق.
ثمانية أسئلة توجّهها إلى أي مورّد
تساعد الأسئلة التالية على تحويل الادعاء العام إلى تقييم محدد. ليس هناك جواب صحيح واحد لجميعها، لكن الإجابات الغامضة ينبغي أن تُعامَل على أنها علامة تحذير.
- من يستطيع التحقق، وبأي صلاحية وصول؟ هل يستطيع مدقّق خارجي تأكيد سلامة سجل دون بيانات اعتماد إدارية ودون طلب مساعدة من المورّد؟
- ما الذي يُختم بالضبط؟ الملف كاملًا، أم كل صف في جدول، أم كل حدث في السجل (log)، أم مجرد ملخص يومي؟ إن مستوى التفصيل يحدد ما يمكن إثباته.
- أين تقع النقطة المرجعية؟ إذا كانت البصمة الرقمية المرجعية محفوظة في النظام نفسه الذي توجد فيه البيانات، فمن يخترق أحدهما يستطيع اختراق الآخر.
- كيف يُعالَج الوقت؟ هل يأتي الختم الزمني من ساعة الخادم أم من مصدر مستقل وقابل للتحقق؟ وهل تستطيع إثبات أن سجلًا ما كان موجودًا قبل تاريخ معيّن؟
- كيف يُكشف الإغفال؟ هل يترك حذف سجل أو التوقف عن كتابته أي أثر؟ تتيح آليات مثل سلاسل التجزئة أو الترقيم التسلسلي كشف الفجوات.
- ماذا يحدث مع البيانات الشخصية؟ إذا لزم حذف المحتوى بموجب اللائحة العامة لحماية البيانات (GDPR)، فهل يبقى إثبات السلامة قائمًا دون كشف المحتوى الأصلي؟ إن ختم البصمات الرقمية بدلًا من البيانات يحلّ هذا التوتر.
- بأي صيغة يُصدَّر الإثبات؟ هل يمكن تسليم الدليل إلى جهة تنظيمية بصيغة موثّقة وقابلة للتحقق بأدوات شائعة، أم أنه مقروء فقط داخل المنصة؟
- كيف يتطور التشفير؟ هل توجد خطة لاستبدال الخوارزميات التي قد تُعدّ ضعيفة، دون فقدان صلاحية الإثباتات التي صدرت بالفعل؟
كيف يبدو التحقق المستقل عمليًا
المبدأ بسيط. لحظة إنشاء سجل أو توثيقه، تُحسب بصمته الرقمية بدالة تجزئة تشفيرية مثل SHA-256. وتُختم هذه البصمة، وهي قيمة قصيرة وفريدة لذلك المحتوى بالضبط، بختم زمني في سجل مستقل. ويبقى المحتوى الأصلي حيث كان دائمًا.
وفي وقت لاحق، وللتحقق، تُعاد حساب البصمة الرقمية للملف كما هو اليوم وتُقارن بالبصمة المختومة. فإذا تطابقتا، فالمحتوى لم يتغير منذ لحظة الختم. وإذا اختلفتا، ولو بمقدار بت واحد، يصبح التغيير جليًا. ولا تتطلب هذه العملية الثقة بمن يحتفظ بالملف: بل تتطلب فقط الوصول إلى الملف وإلى سجل المرجع وإلى طريقة حساب علنية.
وهذا التصميم هو ما يتيح، مثلًا، بوابة تحقق عامة يؤكد فيها أي مستلم لتقرير أصالته دون أن يكون له حساب في منصة من أصدره.
علامات تحذير في العرض
- ترد كلمة «غير قابل للتغيير» دون شرح للآلية التي تضمنها.
- لا يمكن التحقق إلا عبر واجهة المورّد، بعد تسجيل الدخول.
- ليس واضحًا ما يحدث للإثباتات إذا انتهى العقد.
- يعتمد كشف التغييرات على أن يتذكر أحدهم المقارنة يدويًا.
- لا يستطيع المورّد أن يشرح كيف سيُكشف حذف سجل ما.
لا يُعدّ أي من هذه النقاط، بمفرده، سببًا للاستبعاد. لكن كلًّا منها يمثّل جزءًا من سلسلة الثقة ما زال يعتمد على وعد لا على إثبات.
كيف تساعد ROOTKey
صُمّمت ROOTKey حول التمييز الموصوف في هذه المقالة. يحصل كل أصل على بصمة رقمية فريدة، تُختم بشكل دائم في سجل عام مستقل - سجل مؤرَّخ بختم زمني لحالته الدقيقة. ومع النشر المخصص تبقى البيانات في بنيتك التحتية؛ ولا تُسجَّل سوى البصمة الرقمية.
وانطلاقًا من هذا الختم، تقارن المراقبة المستمرة بياناتك بالسجل وتُطلق تنبيهًا عند أي تعديل. ويُختم كل إجراء بختم زمني تشفيري، مكوّنًا سلسلة عهدة جاهزة للمدقّقين وقابلة للتصدير إلى الجهات التنظيمية. ويستطيع أي مستلم تأكيد سلامة مستند صدر عبر ROOTKey في بوابة التحقق العامة، دون الاعتماد على كلام أحد.