من لا يزال يملك صلاحية الوصول إلى موقع شركتك؟ دليل عملي للمراجعة

ابدأ بالملكية قبل تغيير كلمات المرور

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

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

ارسم خريطة للحسابات التي يعتمد عليها الموقع

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

سجّل حساب مسجّل النطاق وحساب مزود DNS كبندين منفصلين، حتى لو كانت الشركة نفسها توفر الخدمتين. وأدرج الخدمات المرتبطة بالنماذج أو الحجز؛ فقد تُدار صلاحياتها خارج لوحة تحكم الموقع.

اربط كل صلاحية بمهمة حالية

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

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

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

المراجع: Cloudflare: الأعضاء والصلاحيات · Cloudflare: السياسات والصلاحيات الفعلية

احمِ وسائل استرداد الحسابات

توصي CISA بالمصادقة متعددة العوامل، بدءًا بالحسابات الحساسة والإدارية، وتفضّل الوسائل المقاومة للتصيد. ابدأ بحسابات النطاق والسحابة والبريد ومستودع الكود، واستخدم أقوى خيار مناسب يدعمه كل مزود.

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

المراجع: CISA: تفعيل المصادقة متعددة العوامل

أزل الصلاحيات القديمة ضمن عملية تسليم واضحة

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

1. اطلب اعتماد مالك العمل للحسابات والصلاحيات المحددة التي ستتغير.
2. تحقق من قدرة المسؤول البديل على تسجيل الدخول وتنفيذ المهام المطلوبة.
3. انقل الأصول اللازمة، ووثّق أي عمليات آلية تعتمد على الحساب المغادر.
4. أزل العضويات المعتمدة، وراجع الجلسات والرموز والمفاتيح والتطبيقات المتصلة عبر أدوات المزود. غيّر بيانات الدخول المشتركة التي كان يعرفها الطرف المغادر، مع فحص الخدمات التي تعتمد عليها.
5. تحقق من الصلاحيات المتبقية، ثم اختبر النشر والاستفسارات والإصدارات وتنبيهات الأمان بحسب الأنظمة المستخدمة.
6. سجّل تاريخ التنفيذ واسم المعتمِد والتغييرات المكتملة والبنود التي ما زالت تحتاج إلى معالجة.

احتفظ بالأدلة وحدد المراجعة التالية

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

اختم المراجعة بتحديد مسؤول وموعد لكل بند لم يُحسم. كررها عند تغيير الموظفين أو الموردين، وحدد لها دورة تناسب عملك. يمنحك السجل المكتمل صورة أوضح عن التحكم في الموقع، لكنه لا يثبت أن الموقع بأكمله آمن.

المراجع: GitHub: مراجعة سجل الأمان