البنية الأمنية

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

الدخول إلى النظام

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

يمكن أن يتولى النظام التحقق من الهوية بنفسه، أو أن يفوّضه إلى الدليل الموجود لديك عبر LDAP، فيستخدم الموظفون بيانات دخولهم المؤسسية وتبقى إجراءات التعيين وإنهاء الخدمة في مكان واحد. وحين يحتفظ النظام بكلمة المرور، تكون السياسة قابلة للضبط: الحد الأدنى للطول، وعدد الأحرف الأبجدية والرقمية والخاصة، والجمع بين الحالتين الكبيرة والصغيرة، وقاعدة تمنع «التغيير» الذي يعيد كلمة المرور الحالية نفسها. والمستخدم الذي يغيّر كلمة مروره بنفسه من المتصفح يجب أن يكتب الحالية أولاً، فلا تصلح جلسة تُركت مفتوحة على مكتب خالٍ للاستيلاء على الحساب.

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

وهناك ثلاثة ضوابط إضافية تحصّن تسجيل الدخول نفسه:

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

وعلى مستوى الخادم يمكن كذلك تقييد الدخول بحسب بادئة عنوان IP، أو منعه لمعرّفات دخول محددة بالاسم — وهو مفيد لعزل حساب مؤقتًا أو لحصر الوصول في شبكات معروفة.

وكل هذه الإعدادات مجتمعة في تبويب الأمان ضمن الإعدادات العامة؛ راجع إعدادات الأمان وتسجيل الدخول.

إلى ماذا يصل المستخدم

الصلاحيات مبنية على طبقات، وتُفحص هذه الطبقات بترتيب ثابت، وعلى المستخدم أن يجتازها جميعًا:

   1.  Authentication          can this person log in at all?
              │
   2.  Menus                   which menu items are even visible?
              │
   3.  Type permissions        for this kind of record — view? edit?
              │                delete? print?
   4.  Record visibility       which of those records specifically —
              │                by branch, by dimension, by "created by
              │                me", by extra filter
   5.  Field / page / list     inside a record they may open, which
              │                fields are hidden or locked, which tabs
              │                and list views are allowed
   6.  Actions & capabilities  may they trigger this particular button?

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

المنع هو الأصل

إذا لم يوجد سطر صلاحية مطابق لا على المستخدم ولا على ملف الصلاحيات، فالإجابة هي المنع. الوصول يُمنح عن قصد ولا يُورَّث بالمصادفة. والاستثناء الوحيد هو خيار الصلاحية الكاملة (Full Authority) الذي يمنح كل شيء — فعامِل ملفات الصلاحيات التي تحمله معاملة الحسابات المميزة، وأبقِ قائمة حامليها قصيرة. وهذا الخيار مخفي عن شاشة ملف الصلاحيات عن قصد حتى لا يمنحه أحد بتأشير الخانة الخطأ؛ ويحمله ملف الصلاحيات المدمج default، وتجد في حقول مخفية عن قصد كيف تُظهره بـ«تعديل شاشة».

وتستحق رؤية السجلات على مستوى السجل الواحد ذكرًا خاصًا لأنها ما يفتش عنه المدققون عادةً. فإلى جانب سؤال «هل يرى هذا المستخدم فواتير المبيعات؟» يقيّد النظام أي فواتير مبيعات تحديدًا: بحسب المحددات المرتبطة بالسجل (الفرع والإدارة ومركز التكلفة وما شابهها)، وبحسب ما إذا كان المستخدم هو من أنشأ السجل، وبحسب فلاتر إضافية حرة تُكتب داخل ملف الصلاحيات. ويُطبَّق ذلك عند قراءة البيانات لا بإخفاء صفوف في الواجهة. التفاصيل في أمان مستوى السجل، والنموذج الكامل في نظرة عامة على نظام الأمان.

وحين يغيب مدير ما، يمكن تفويض صلاحياته لمدة محددة بدلًا من مشاركتها بتسليم كلمة المرور — راجع تفويض الصلاحيات.

إثبات ما حدث

يحمل كل سجل من أنشأه ومن عدّله آخر مرة مع أوقات ذلك، ويُحفظ هذا كجزء من السجل نفسه. وفوق هذا الأساس يمكن تفعيل التدقيق على مستوى الحقل لحقول محددة بالاسم — حد ائتمان، سعر بيع، نسبة خصم، شرط سداد — فتُكتب عندئذ كل تغييرات تلك الحقول في سجل تفصيلي يبيّن القيمة السابقة والقيمة الجديدة ومن غيّرها ومتى، ويمكن الوصول إليه من السجل ذاته. واختيار حقول بعينها بدلًا من الحقول كلها أمر مقصود: فسجل التدقيق الذي لا يستطيع أحد قراءته ليس دليلًا.

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

ولأن آثار الأعمال تُعالَج كطلبات في الخلفية، يوجد كذلك سجل دائم لما فعله النظام نفسه بكل مستند، ولكل ما فشل منه — ظاهر للمسؤولين لا مدفون في ملف سجل.

حماية البيانات

أثناء النقل. ينبغي نشر نما عبر HTTPS. ويستطيع المثبِّت استخراج شهادة Let's Encrypt وتركيبها، والتجديد تلقائي. وأي تركيبة يمكن الوصول إليها من خارج شبكة المكتب ينبغي أن تعتبر هذا إلزاميًا لا اختياريًا، بل إن التركيبات الداخلية أيضًا تستفيد منه.

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

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

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

أين تقع المسؤولية

يستحق تقسيم المسؤولية تصريحًا واضحًا، لأنه مصدر معظم سوء الفهم في المراجعات الأمنية.

ما توفره نماسوفت	ما تملكه أنت
آليات التحقق من الهوية والصلاحيات والتدقيق الموصوفة أعلاه	من يحمل أي ملف صلاحيات، وكم عدد من يحملون الصلاحية الكاملة
إمكانية فرض التحقق بخطوتين وتطبيق سياسة كلمات المرور	قرار تفعيلها ومدى التشدد في ضبطها
مثبِّت يستخرج شهادة TLS ويجددها	نطاقك وقواعد جدار الحماية والشبكة الافتراضية الخاصة
مهام نسخ احتياطي مهيأة وقت التركيب	التحقق من تنفيذها، واختبار الاستعادة، وتأمين النسخة الخارجية
إصدارات دورية تتضمن الإصلاحات الأمنية	تطبيقها، وإبقاء Windows و Java و SQL Server محدَّثة

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