مخطط انسيابي لطلب الوصول إلى البيانات: من الطلب إلى الإلغاء
مخطط انسيابي لعملية طلب الوصول إلى البيانات: ذكر الغرض، وقراءة تصنيف مجموعة البيانات، وقرار مالك البيانات، وفحوصات البيانات الشخصية، ثم منح وصول محدّد المدة يُعاد اعتماده أو يُلغى.
ما هي مخطط انسيابي لطلب الوصول إلى البيانات: من الطلب إلى الإلغاء؟
تُعامَل طلبات البيانات عادةً كما لو كانت طلبات برمجيات. تصل تذكرة تطلب الوصول إلى مستودع البيانات، فيمنحها من يملك بيانات الاعتماد، وينتهي الأمر بشخص كان يحتاج جدولاً واحداً للإجابة عن سؤال واحد وهو قادر على قراءة كل مخطط في العنقود، بما فيها ما يحمل الرواتب أو معرّفات المرضى أو أرقام البطاقات. وثلاث عادات تسبّب معظم الضرر. تُختار جهة الاعتماد بحسب من يستطيع تقنياً منح الوصول لا بحسب من يُساءل عن البيانات. ويسمّي الطلب نظاماً بدل أن يذكر غرضاً، فلا يبقى شيء يُختبر عليه مبدأ أقل صلاحية. ولا يحمل المنح تاريخ انتهاء، فيعمّر بعد انتهاء المشروع، ثم بعد الانتقال إلى فريق آخر، وأحياناً بعد انتهاء الخدمة. والوصول إلى البيانات هو النوع الوحيد من الوصول الذي يتوفر فيه دائماً تقريباً جواب أصغر (عمود مُقنَّع، أو مرشّح على مستوى الصفوف، أو جدول مُجمَّع مسبقاً)، ولا يعرضه أحد، لأن عرضه يستغرق وقتاً أطول من منح الجدول الخام. والنتيجة بيئة بيانات لا يستطيع أحد أن يقول فيها من يقرأ ماذا، دون أن يكون أي طلب منفرد فيها غير معقول.
هذا المخطط يخصّ مجموعات البيانات لا الحسابات. فإن كان موظف على رأس عمله يحتاج تطبيقاً إضافياً والسؤال هو من يعتمده ومن يزوّده به، فتلك هي عملية طلب صلاحيات الوصول العامة على /ar/templates/عملية-طلب-صلاحيات-الوصول، والنسخة التي يقودها حدث التحاق أو انتقال في نظام الموارد البشرية على /ar/templates/عملية-طلب-صلاحيات-الموظفين. أما إنشاء الهوية نفسها وتعديلها وتعطيلها (الحساب ومجموعة الدليل والرخصة) فيخصّ عملية تزويد المستخدمين بالصلاحيات على /ar/templates/عملية-تزويد-المستخدمين-بالصلاحيات؛ وكل ما هنا يفترض أن مقدّم الطلب يملك حساباً عاملاً أصلاً، ولا يسأل إلا عمّا يجوز لذلك الحساب قراءته. وهو ليس طلباً من خارج المؤسسة أيضاً: فطلب فرد نسخةً من بياناته الشخصية يستدعي التزاماً نظامياً له ساعته الخاصة وفحوصات هويته وأسباب رفضه، وذلك مرسوم على /ar/templates/عملية-طلبات-أصحاب-البيانات-الشخصية. وإن كانت البيانات قد بلغت أصلاً مكاناً لم يكن ينبغي أن تبلغه، فهذا هو المخطط الخطأ تماماً: الاحتواء واختبار الخطر على الأفراد وقرار الإخطار خلال 72 ساعة كلها على /ar/templates/الاستجابة-لخرق-البيانات-الشخصية. ويبقى هنا نطاق ضيّق محدّد: شخص من داخل المؤسسة، ومجموعة بيانات مُسمّاة، وغرض مذكور، ومالك يقرّر.
والقرارات التي تتركها معظم إجراءات الوصول إلى البيانات المكتوبة للعادة مرسومة هنا صراحةً. «مفهرسة ولها مالك مُسمّى؟» تسبق أي تقييم، لأن مجموعة بيانات بلا مالك لا يستطيع أحد اعتمادها، والموقف الصادق في معظم المؤسسات أن أول طلب على جدول ما هو ما يدفع أخيراً إلى تصنيفه؛ ولذلك يعود فرع «لا» عبر الفهرسة بدل التصعيد إلى من تصادف أنه بنى خط البيانات. و«أي مستوى وصول يحتاجه الغرض؟» تفرّع ثلاثي لا سؤال بنعم أو لا، فيوجد المسار المُقنَّع أو المُجمَّع على المخطط ويلزم استبعاده صراحةً بدل ألّا يُذكر أصلاً. والعملية لا تنتهي عند المنح: «هل أُعيد اعتماده قبل تاريخ الانتهاء؟» تجعل الانتهاء هو الأصل والتجديد هو الاستثناء، وهو عكس ما يجري عليه العمل فعلاً، بينما تعطي «هل تغيّر الدور أو الغرض؟» المالكَ سبباً ثانياً للإلغاء لا ينتظر موعد مراجعة. والمسار الطارئ مرسوم للسبب نفسه: فمهندس أمام حادثة إنتاج سيبلغ البيانات بطريقة أو بأخرى، ولذلك تضع «هل مُنح اعتماد لاحق؟» المصادقةَ والإلغاء خلف الوصول الطارئ بدل التظاهر بأنه لا يحدث.
ما الذي يغطيه هذا المخطط
في هذا القالب
- خمسة مسارات: مقدّم الطلب، وأمين البيانات، ومالك البيانات، ومكتب الخصوصية، وفريق منصة البيانات، موزّعة على خمس مراحل: الطلب، والتصنيف، وتقييم المالك، والتزويد، والمراجعة والإلغاء
- طلب ملزَم بذكر سبب: «رفع طلب يذكر الغرض» هو المدخل الاعتيادي الوحيد، بينما يرسل تفرّع «وصول طارئ لحادثة؟» حالات حوادث الإنتاج مباشرةً إلى «منح وصول طارئ مُسجَّل» بدل تركها تقع خارج المخطط. ثم يواجه ذلك المنح «هل مُنح اعتماد لاحق؟»، وينتهي عند «إلغاء الوصول الطارئ والتصعيد» إن لم يصادق عليه أحد
- قرار «مفهرسة ولها مالك مُسمّى؟» في مسار أمين البيانات، وفرع «لا» فيه يمرّ عبر «تصنيفها وتسمية مالك للبيانات» ثم يعود إلى البحث في الكتالوج، فلا تُعتمد مجموعة بيانات بلا مالك افتراضاً
- مالك البيانات هو من يحمل القرار لا تقنية المعلومات: «تقييم الغرض وأقل صلاحية»، ثم «هل يبرّر الغرض هذا الوصول؟» التي ينتهي فرع «لا» فيها عند «رفض الطلب مع توثيق الأسباب»، ثم «هل يشمل النطاق بيانات شخصية؟» التي توجّه المسار إلى مسار مكتب الخصوصية
- فرع بيانات شخصية له أنياب حقيقية: «توثيق الأساس القانوني وتقليل الحقول»، ثم قرار ثلاثي «هل تُجيز مراجعة الخصوصية الاستخدام؟» يُجيز الطلب، أو يرفضه إلى نقطة الرفض نفسها، أو يمرّره عبر «إتمام تقييم الأثر ووضع الشروط» ثم يعيده لجواب ثانٍ بعد أن تُعرف المخاطرة المتبقية
- قرار ثلاثي «أي مستوى وصول يحتاجه الغرض؟»: مُقنَّع أو مُجمَّع، أو بيانات مقيَّدة خام (وتضيف «توقيع اتفاقية استخدام البيانات»)، أو بيانات داخلية خام، تلتقي كلها عند «منح الوصول بتاريخ انتهاء» وتسجيل الاستعلامات والقيد في سجل الوصول. ثم تعيد «هل تغيّر الدور أو الغرض؟» و«هل أُعيد اعتماده قبل تاريخ الانتهاء؟» المسارَ إلى منح جديد أو تخرجان به إلى «إلغاء الوصول وتحديث السجل»
متى تستخدم هذا القالب
- تكتب قسم الوصول في سياسة حوكمة البيانات أو إدارتها لمستودع بيانات أو بحيرة بيانات أو طبقة تقارير، وتحتاج صفحة واحدة تبيّن أن مالك البيانات هو من يقرّر لا الفريق الذي يملك بيانات الاعتماد
- يحمل محلّلوك صلاحيات مُنحت لمشاريع انتهت قبل سنتين، وتريد بناء تاريخ الانتهاء وإعادة الاعتماد داخل العملية بدل إدارتهما كحملة تنظيف سنوية لا يطيقها أحد
- تُعدّ مسار الطلبات في كتالوج بيانات أو في أداة لحوكمة الوصول، وتريد الاتفاق على مسار الاعتماد وعتبات التصنيف قبل ترميزها
- للمهندسين مسار وصول طارئ إلى بيانات الإنتاج لا يراجعه أحد بعد ذلك، وتحتاج أن تكون خطوتا المصادقة والإلغاء مرسومتين حيث يراهما مالكو البيانات ومناوبة الطوارئ معاً
- يختلف فريق الخصوصية وفريق منصة البيانات باستمرار حول من يقرّر في البيانات الشخصية، وتريد وضع الأساس القانوني والتقليل وتقييم الأثر داخل المسار لا مُلحقةً بنهايته
كيف تعمل
أعد تسمية المسارات لتطابق مؤسستك
استبدل مقدّم الطلب وأمين البيانات ومالك البيانات ومكتب الخصوصية وفريق منصة البيانات بالأدوار الموجودة لديك فعلاً. وأبقِ مالك البيانات منفصلاً عن فريق المنصة حتى لو قام بالدورين اليوم شخص واحد، لأن دمجهما هو ما ينتج عمليةً يكون فيها المانح هو المعتمِد نفسه. وإن لم يكن لديك مكتب خصوصية فسمِّ من يحمل هذه المسؤولية بدل حذف المسار، وإن كانت أمانة البيانات غير رسمية فضع قائد المجال هناك واذكر ذلك كتابةً.
اكتب مخطط التصنيف داخل المخطط الانسيابي
«قراءة التصنيف وقواعد التعامل» تبقى بلا أثر ما لم تكن المستويات موجودة. سمِّها: عام، وداخلي، وسرّي، ومقيَّد، أو أياً كان ما يستخدمه مخططك، وسجّل بجانب كل مستوى ما يبيحه: الاستعلام في المكان فقط، أو السماح بالاستخراج، أو إلزام التقنيع، أو اشتراط اتفاقية موقّعة. ثم حدّد أي مستوى يُفعّل فرع اتفاقية الاستخدام، وأي مستوى لا يجوز أن يغادر بيئة التحليل أبداً. فبلا ذلك الجدول، يُناقش كل طلب من المبادئ الأولى وتتباين الأجوبة باختلاف المعتمِد.
اجعل بيان الغرض يؤدي عملاً حقيقياً
حدّد الحد الأدنى الذي يجب أن يذكره الطلب: السؤال الذي يُراد الإجابة عنه، والجداول والأعمدة اللازمة، وسجلات مَن تقع في النطاق، والمدة المطلوبة للوصول، والمكان الذي سيُحفظ فيه أي استخراج. وعبارة «للتحليل» ينبغي أن تُردّ لا أن تُعتمد. وهذا أرخص ضابط في الصفحة، لأن غرضاً مكتوباً كما ينبغي يجعل تقدير أقل صلاحية وقرار التقنيع وتاريخ الانتهاء شبه آلية، بينما الغرض الغامض يجعل الثلاثة اعتباطية.
اضبط مُدد انتهاء افتراضية بحسب التصنيف
ألحِق بـ«منح الوصول بتاريخ انتهاء» مدةً افتراضية لكل مستوى: نافذة الحادثة للوصول الطارئ، وتسعين يوماً للبيانات المقيَّدة، وستة أشهر أو اثني عشر شهراً للبيانات الداخلية، وتاريخ انتهاء المشروع حيث يوجد مشروع. ودع مقدّمي الطلبات يطلبون مدداً أقصر، واجعل أي مدة تتجاوز الافتراضية قراراً صريحاً من المالك. فتاريخ الانتهاء هو الضابط الذي ينجو من إعادة الهيكلة ومن تبديل الأدوات ومن نسيان الجميع أن العملية كانت موجودة.
اتفق على المسار الطارئ قبل أن تحتاجه
قرّر من يجوز له استدعاء الوصول الطارئ، وما الذي يمنحه، ومن أي حساب يعمل، وكيف تُسجَّل الجلسة، ومن يُنبَّه لحظة المنح. ثم حدّد مهلة المصادقة (عدداً صغيراً من أيام العمل)، والأهم أن تقرّر ما يحدث حين لا يصادق أحد. فالإلغاء التلقائي عند انقضاء المهلة هو النسخة الوحيدة التي تصمد، لأن قائمة اعتمادات لاحقة بلا أثر مترتب على تجاهلها تتحول إلى تراكم دائم خلال ربع سنة.
استعرضه خطوة بخطوة ثم انشر إصداراً
خذ المخطط النهائي إلى مالك بيانات، ومحلّل يطلب الوصول كثيراً، ومهندس المنصة الذي ينفّذ المنح، ومن يتولى الخصوصية، واختبره على ثلاثة طلبات حقيقية من الربع الماضي، منها واحد رُفض وواحد مرّ عبر المسار الطارئ. وصحّح المخطط ليطابق ما حدث فعلاً لا ما تقوله السياسة. ثم انشر تلك المراجعة، واحتفظ بالإصدارات السابقة، واربطها من سياسة حوكمة البيانات ليعرف القارئ أي نسخة ينظر إليها.
الأسئلة الشائعة
ما خطوات عملية طلب الوصول إلى البيانات؟
ارفع طلباً يذكر الغرض لا النظام؛ وابحث عن مجموعة البيانات في الكتالوج واقرأ تصنيفها وقواعد التعامل معها؛ وتأكد أن لها مالكاً مُسمّى، وصنّفها أولاً إن لم يكن لها؛ ودع ذلك المالك يقيّم الغرض في مواجهة مبدأ أقل صلاحية ويقرّر؛ وحيث تدخل بيانات شخصية في النطاق، وثّق الأساس القانوني وقلّل الحقول ومرّر الطلب عبر مراجعة خصوصية أو تقييم أثر؛ واعرض عرضاً مُقنَّعاً أو مُجمَّعاً قبل الوصول الخام؛ وأضف اتفاقية استخدام موقّعة للبيانات المقيَّدة؛ وامنح الوصول بتاريخ انتهاء؛ وفعّل تسجيل الاستعلامات؛ وقيّد الصلاحية في سجل الوصول؛ ثم إما أن تعيد اعتمادها قبل انتهائها أو تلغيها، فوراً إن تغيّر دور الشخص أو تغيّر الغرض. والخطوات الأكثر غياباً في الواقع هي البديل المُقنَّع، وتاريخ الانتهاء، ومُحفِّز الإلغاء عند تغيّر الدور.
من ينبغي أن يعتمد الوصول إلى مجموعة بيانات: تقنية المعلومات أم مالك البيانات؟
مالك البيانات، أي الشخص المُساءل في مجال العمل الذي تصفه البيانات، لا الفريق الذي يشغّل المنصة التي تستقر عليها. فالحكم المطلوب هو هل يبرّر هذا الغرض هذه البيانات، ولا يستطيع إصداره إلا من يفهم ما تعنيه السجلات. أما فريق المنصة فينفّذ المنح ويضبط تاريخ الانتهاء ويشغّل التسجيل؛ ولا ينبغي أن يقرّر فوق ذلك من يستحق قراءة سجلات الرواتب أو المرضى أو العملاء. ويستحق اعتماد المدير المباشر أن يُضاف كبوابة أولى، لأنه يؤكد أن الطلب جزء من عمل الشخص، لكنه لا يحلّ محل قرار المالك. وحيث لا يكون لمجموعة البيانات مالك فعلياً، فتلك ملاحظة بحد ذاتها، ولهذا يضع هذا المخطط «مفهرسة ولها مالك مُسمّى؟» قبل التقييم لا بعده.
كم ينبغي أن يدوم الوصول إلى البيانات قبل انتهائه؟
بقدر ما يقتضيه الغرض المذكور ولا أكثر، مع مدة افتراضية يحدّدها التصنيف لا تفاوض على كل طلب. ومن الأنماط العملية: مدة الحادثة للوصول الطارئ، ونحو تسعين يوماً للبيانات المقيَّدة أو الشخصية، وستة إلى اثني عشر شهراً للبيانات الداخلية الاعتيادية، وتاريخ انتهاء المشروع حين يكون الطلب مرتبطاً بمشروع. والآلية أهم من الأرقام: فتاريخ الانتهاء يجعل الإزالة هي الأصل والتجديد هو الفعل المقصود، فيضمر الوصول من تلقاء نفسه حين تُهمل العملية، بينما الوصول بلا تاريخ انتهاء يتراكم. وحين تطلب من مالك أن يعيد الاعتماد، أرسل عدّادات الاستعلامات مع الطلب: فالصلاحية التي لم يستخدمها أحد منذ ستة أشهر تُزال بلا جدال، أما قائمة أسماء بلا بيانات استخدام فتُعتمد جملةً واحدة في الغالب.
متى يحتاج طلب الوصول إلى البيانات تقييم أثر لحماية البيانات (DPIA)؟
بموجب اللائحة العامة لحماية البيانات في الاتحاد الأوروبي والمملكة المتحدة، يلزم تقييم أثر حماية البيانات حين يُرجَّح أن تؤدي المعالجة إلى خطر مرتفع على الأفراد، ويُتوقع بوجه خاص في المعالجة واسعة النطاق للفئات الخاصة من البيانات، وفي المراقبة المنهجية، وفي القرارات الآلية ذات الأثر القانوني أو المماثل له. وتنشر السلطات الرقابية قوائمها الخاصة بالعمليات التي تستوجبه دائماً، كما تتضمن قوانين حماية البيانات الوطنية في أسواق أخرى اشتراطاً مماثلاً بصياغات مختلفة، فارجع إلى نص القانون الساري عليك قبل تثبيت العتبة. أما في طلب تحليلات داخلي فالمُحفِّزات الصادقة عادةً هي حجم الفئة المعنية، وهل البيانات من الفئات الخاصة أو متعلقة بأحكام جنائية، وهل يتوقع الأفراد هذا الاستخدام بشكل معقول، وهل يغذّي المُخرج قراراً يخصّهم. وأمران يفيدان عملياً: افحص كل طلب يمسّ بيانات شخصية بدل انتظار من يثير قلقاً، وعامل النتيجة كشروط على المنح: الأعمدة المُقنَّعة، ومدة الاحتفاظ، وحظر إعادة تحديد الهوية، لا كوثيقة تُحفظ وتُنسى.
بم يختلف هذا عن عملية طلب صلاحيات الوصول العامة؟
عملية طلب صلاحيات الوصول العامة على /ar/templates/عملية-طلب-صلاحيات-الوصول تغطي الأنظمة والتطبيقات: يحتاج أحدهم دوراً في نظام عمل، فيعتمده مديره المباشر ومالك النظام، ويُجرى فحص فصل المهام، ثم تزوّده تقنية المعلومات. أما هذه الصفحة فتغطي مجموعات البيانات، وثلاثة أمور تتغيّر تبعاً لذلك. المعتمِد هو مالك البيانات لا مالك النظام، لأن السؤال يدور حول معنى السجلات لا حول وظيفة تطبيق. وتقع خطوة تصنيف في المنتصف، لأن الجواب يتوقف على ما في الجدول. ويوجد بديل مُقنَّع أو مُجمَّع لا نظير له في الوصول إلى التطبيقات: فأنت لا تستطيع منح أحد ستين في المئة من وحدة مالية، لكنك تستطيع منحه عرضاً نُزعت منه المعرّفات. فإن كنت تصمّم نموذج مكتب خدمات للوصول إلى التطبيقات فابدأ بالعملية العامة، وإن كنت تحكم من يستطيع الاستعلام عن مستودع البيانات فابدأ من هنا.