MDM: إدارة أجهزة الموظفين وتأمينها بأدوات مفتوحة

بريد الشركة يصل اليوم إلى حاسوب كل موظف وهاتفه، وملفاتها تنزل إلى مجلدات المزامنة على هذه الأجهزة، وجلسات الدخول إلى أنظمتها محفوظة في متصفحاتها، وبالتالي فإن كل جهاز من هذه الأجهزة أصبح نسخة صغيرة من بيانات الشركة تسير في الشارع وتسافر وتنسى في سيارات الأجرة. وقد تحدثنا في إدارة الهوية والوصول IAM والوصول المميز PAM عن السؤال «من يملك الوصول إلى ماذا؟»، أما هذا المقال فيكمل النصف الآخر من الصورة وهو «من أي جهاز؟ وفي أي حالة هذا الجهاز؟»، لأن الحساب الصحيح على جهاز مسروق دون تشفير أو جهاز لم يحدث منذ أشهر هو باب مفتوح مهما كانت كلمة المرور قوية.

وسوف نناقش في هذا المقال ما يلي:

• المشكلة التي تحلها إدارة الأجهزة، ولماذا لا يكفي أن تطلب من الموظفين الالتزام.
• المصطلحات MDM وEMM وUEM وRMM، والفرق بين جهاز الشركة وجهاز الموظف الشخصي، وما تراه الشركة في كل حالة.
• كيف تعمل الإدارة من الداخل على Apple وAndroid وWindows وLinux، ومن أين تأتي التبعية لكل مزود.
• ما الذي تستطيع أن تفرضه وتراه، وكيف تدخل حالة الجهاز في قرار تسجيل الدخول.
• الأدوات مفتوحة المصدر والمستضافة ذاتياً ورخصها، ثم تجربة عملية مع osquery وFleet.
• خطة تطبيق لمؤسسة صغيرة، والأخطاء الشائعة، وقائمة تحقق.

ما المشكلة؟ أجهزة تحمل بيانات الشركة ولا يديرها أحد

لنفرض أن لديك شركة فيها ثلاثون موظفاً، ولكل موظف حاسوب محمول وهاتف، وأن البريد والملفات والأنظمة الداخلية كلها تعمل على سيرفراتك أو في خدمات سحابية تدخل إليها بحساب الشركة، فأمامك خمس حالات سوف تقابلها عاجلاً أم آجلاً، وكلها لا علاقة لها بقوة السيرفر أو جودة جدار الحماية:

• حاسوب ضائع دون تشفير القرص Disk Encryption: من يجد الحاسوب يستطيع أن يخرج القرص ويقرأه من جهاز آخر دون أن يعرف كلمة مرور Windows أو macOS، والسبب أن كلمة مرور الدخول تحمي شاشة الدخول فقط ولا تحمي الملفات المحفوظة على القرص.
• موظف غادر ومعه هاتفه الشخصي: حسابه في البريد قد يكون تعطل، ولكن الرسائل والمرفقات التي نزلت إلى هاتفه ما زالت عليه، وإذا تأخر تعطيل الحساب فإن المزامنة تستمر أياماً.
• أجهزة متأخرة في التحديثات Updates: جهاز في المكتب لم يحدث نظامه منذ أشهر، لأن صاحبه يضغط «لاحقاً» كل مرة، وبالتالي فإن كل ثغرة أغلقها المصنع في هذه الأشهر ما زالت مفتوحة عندك.
• صلاحيات مدير محلي Local Admin للجميع: كل مستخدم يستطيع أن يثبت أي برنامج ويعطل أي إعداد، بما في ذلك برنامج الحماية نفسه، وأي برنامج ضار يعمل بصلاحياته يأخذ الصلاحيات نفسها.
• لا يوجد سجل للأجهزة Inventory: لا أحد يعرف كم جهازاً يدخل إلى بريد الشركة، ولا أي أنظمة عليها، ولا أي جهاز يعود لمن، فإذا سألك المدير عن عدد الأجهزة التي تحتاج تحديثاً عاجلاً لثغرة ظهرت اليوم فلن تجد جواباً.

والصورة التالية تجمع هذه الحالات حول بيانات الشركة:

لماذا لا يكفي أن تطلب من الموظفين الالتزام؟

أول ما يفعله أغلبنا هو رسالة إلى الجميع: «فعلوا التشفير، وحدثوا أجهزتكم، ولا تثبتوا برامج غير معروفة»، ثم ملف Excel يكتب فيه كل موظف نوع جهازه. وهذا الحل يفشل لأسباب لا علاقة لها بنية الموظفين:

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

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

ما هي إدارة الأجهزة؟ MDM وEMM وUEM وRMM

إدارة الأجهزة المحمولة Mobile Device Management، واختصاراً MDM، هي نظام يتكون من سيرفر تديره الشركة، وطرف على كل جهاز مسجل فيه، بحيث يرسل السيرفر إلى الجهاز الإعدادات Configurations والأوامر Commands، ويرسل الجهاز إلى السيرفر معلومات عنه وعن حالته. وتقريب الفكرة مثل عقد السكن في مجمع سكني: عندما تسجل جهازك في الإدارة فأنت توقع على عقد يعطي إدارة المجمع حق تركيب أقفال موحدة وإجراء الصيانة وتغيير الأقفال إذا ضاع المفتاح، ويحدد العقد نفسه ما لا يحق لها، مثل الدخول إلى غرفتك الخاصة.

وستقابل أربعة أسماء متقاربة في عروض الشركات، وهي في الواقع طبقات تراكمت مع الوقت:

والفرق المهم عملياً بين MDM وRMM ليس في الاسم، وإنما في الطريقة: MDM يستخدم الإطار الذي بناه المصنع في النظام نفسه، فيستطيع أن يفرض ما لا يستطيعه برنامج عادي، مثل منع المستخدم من حذف الإدارة أو قفل الجهاز من المصنع، أما RMM فهو برنامج Agent تثبته على الجهاز ويعمل بصلاحيات عالية، فيستطيع أن يفعل الكثير على الحاسوب، ولكنه لا يملك شيئاً على iPhone مثلاً.

جهاز الشركة أم جهاز الموظف؟

السؤال الأول قبل أي أداة هو من يملك الجهاز، لأن الجواب يحدد ما يحق للشركة أن تفعله. فالجهاز المملوك للشركة Corporate-Owned تديره الشركة كاملاً، فترى كل التطبيقات المثبتة عليه، وتفرض التشفير والتحديثات، وتمسحه كاملاً إذا ضاع. أما الجهاز الشخصي الذي يستخدمه الموظف في العمل، أي «أحضر جهازك» Bring Your Own Device واختصاراً BYOD، فالحل التقني فيه أن يقسم الجهاز إلى قسمين: قسم العمل Work Profile في Android، والتسجيل بحساب المستخدم User Enrollment في Apple، فتدير الشركة قسم العمل فقط وتمسحه وحده عند الحاجة، وهو ما يسمى المسح الانتقائي Selective Wipe. وتقول وثائق Google في صفحة ما تراه الشركة على جهازك إن التطبيقات والبيانات في القسم الشخصي لا تراها الشركة، وإن كانت ترى معلومات الجهاز مثل الطراز والرقم التسلسلي ورقم الهاتف. أما Apple فجدول طرق التسجيل وأثرها على الخصوصية يبين أن الشركة في User Enrollment لا تستطيع أن تعرف حتى الرقم التسلسلي أو قائمة كل التطبيقات، ولا تستطيع أن تمسح الجهاز كاملاً، ولا ترى الموقع أو الرسائل أو سجل التصفح في أي طريقة من طرق التسجيل.

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

كيف تعمل إدارة الأجهزة من الداخل؟

قد يبدو من الوهلة الأولى أن السيرفر يتصل بالجهاز ويرسل إليه الأمر، ولكن هذا مستحيل عملياً، فالهاتف يتنقل بين شبكة البيت وشبكة الجوال وشبكة المقهى، ويعمل خلف NAT لا يقبل اتصالات من الخارج، والحاسوب ينام ويستيقظ. لذلك فإن كل الأنظمة تتفق على فكرة واحدة: السيرفر لا يرسل الأمر، وإنما يرسل تنبيهاً فارغاً عبر خدمة التنبيهات الفورية Push Notification Service التي يديرها مصنع النظام، والجهاز المتصل دائماً بهذه الخدمة يستيقظ ويتصل بنفسه بسيرفر الإدارة ويسأل: «هل لديك أوامر لي؟». والصورة التالية تبين ذلك:

لاحظ في الخطوة الرابعة أن الجهاز يثبت هويته بشهادة Certificate حصل عليها عند التسجيل، وأن الاتصال مشفر بين الجهاز وسيرفرك مباشرة، وبالتالي فإن خدمة المصنع لا ترى الأوامر ولا النتائج. ولكن يجدر الانتباه إلى أن هذه الخدمة تبقى تبعية لا تستطيع أن تلغيها حتى لو استضفت سيرفر الإدارة بنفسك، فإذا لم يصل الجهاز إلى خدمة التنبيهات فلن يعرف أن لديك أمراً له حتى يتصل بنفسه في موعده الدوري. وسوف نمر الآن على كل نظام، وفكرة التنبيهات تفصيل شرحه يأتي في مقال مستقل عن الإشعارات الفورية APNs وFCM بإذن الله.

Apple: بروتوكول MDM وAPNs وDDM

بنت Apple إطار الإدارة في أنظمتها منذ سنوات، وتقول في مقدمة إدارة الأجهزة إن خدمة الإدارة ترسل إلى الجهاز الإعدادات والملفات Profiles والأوامر، سواء كان الجهاز ملك المستخدم أو ملك المؤسسة. وتتم العملية كما يلي:

• ملف التسجيل Enrollment Profile: ملف بامتداد .mobileconfig يثبته المستخدم أو يصل تلقائياً، وبعده يحصل الجهاز على شهادة هوية عبر بروتوكول ACME أو SCEP، ولا يوجد على الجهاز إلا ملف تسجيل واحد في الوقت نفسه، وإذا حذفه المستخدم حذفت معه كل الإعدادات والتطبيقات التي جاءت عن طريقه.
• خدمة APNs: تقول Apple في صفحة إعداد الأجهزة للعمل مع APNs إن خدمة الإدارة تحتاج شهادة APNs لتتحدث مع الأجهزة، وإن هذه الشهادة تجدد سنوياً من بوابة شهادات Apple Push بحساب Apple، وإن الجهاز يحتاج المنفذ 5223 إلى شبكة Apple. وهذه هي التبعية الصريحة: لا يوجد سيرفر MDM لأجهزة Apple يعمل دون شهادة من Apple، وإذا انتهت الشهادة توقفت كل أجهزتك عن استقبال الأوامر، لذلك اكتب في تقويمك موعد تجديدها، واحفظ اسم الحساب الذي أنشأتها به لأن التجديد يتم بالحساب نفسه.
• التسجيل التلقائي Automated Device Enrollment: الأجهزة التي تشتريها الشركة من Apple أو من موزع معتمد تضاف إلى Apple Business Manager، الذي أصبح اسمه في الوثائق الحديثة Apple Business، ويربطها بسيرفرك، فيسجل الجهاز نفسه عند أول تشغيل، ويصبح تحت الإشراف Supervised، ولا يستطيع المستخدم حذف الإدارة. والتفاصيل في صفحة Automated Device Enrollment.
• الإدارة التصريحية Declarative Device Management: واختصاراً DDM، وهي بحسب وثائق Apple تحديث للبروتوكول، فبدلاً من أن يرسل السيرفر أمراً ثم ينتظر النتيجة، يرسل الحالة المطلوبة، ويعمل الجهاز وحده على الوصول إليها والبقاء عليها، ويبلغ السيرفر بنفسه عندما تتغير حالته، حتى دون اتصال بالإنترنت أحياناً. وهي اليوم الطريقة التي تفرض بها Apple التحديثات على الأجهزة.

Android: Android Enterprise وتطبيق الإدارة

في Android لا يأتي إطار الإدارة من بروتوكول مفتوح، وإنما من برنامج Google المسمى Android Enterprise، ويعمل كما يلي:

• تطبيق التحكم في سياسات الجهاز Device Policy Controller: واختصاراً DPC، وهو تطبيق على الجهاز يطبق السياسات، وتقول وثائق Android إنه الجسر بين لوحة الإدارة والجهاز، وإنه هو الذي ينشئ قسم العمل ويديره. والتطبيق الرسمي من Google هو Android Device Policy، وتديره أدوات الإدارة عبر Android Management API. ولاحظ أن الصفحة نفسها تقول إن Google لم تعد تقبل تسجيل تطبيقات DPC خاصة جديدة لواجهة Google Play EMM القديمة.
• أنماط الإدارة: قسم العمل Work Profile على الجهاز الشخصي أو على جهاز الشركة، والجهاز المدار بالكامل Fully Managed لأجهزة الشركة، والجهاز المخصص Dedicated لجهاز يعمل بتطبيق واحد مثل نقطة البيع.
• التسجيل دون لمس Zero-touch Enrollment: وهو المقابل للتسجيل التلقائي في Apple، فالجهاز الذي تشتريه الشركة من موزع شريك يسجل نفسه عند أول تشغيل، وتشترط صفحة Zero-touch أن يعمل الجهاز بـ Android 9 أو أحدث، وأن تكون خدمات Google Play مفعلة.
• دور Google: التنبيهات تمر عبر Firebase Cloud Messaging، واختصاراً FCM، كما في صفحة متطلبات الشبكة، والتطبيقات تصل عبر Managed Google Play، وبالتالي فإن الإدارة الكاملة لـ Android تعني حساب مؤسسة عند Google. والاستثناء هو أدوات مثل Headwind MDM التي بنت نظام تنبيهات خاصاً بها، وسوف نذكرها في الأدوات.

Windows: عميل MDM المدمج وAutopilot وGroup Policy

تقول Microsoft في نظرة عامة على MDM في Windows إن في Windows عميل إدارة مدمجاً يستطيع أن يتحدث مع أي سيرفر MDM يطبق البروتوكول، وليس مع Intune وحده، والبروتوكول هو OMA-DM، أي معيار إدارة الأجهزة من Open Mobile Alliance، حيث يفتح العميل جلسة HTTPS مع السيرفر ويتبادلان رسائل بصيغة SyncML كما في صفحة دعم OMA DM. وكل إعداد في النظام له مسار في شجرة يسمى مزود خدمة الإعدادات Configuration Service Provider، واختصاراً CSP، فهناك مثلاً BitLocker CSP لتشفير القرص وUpdate CSP للتحديثات. وتوقظ Microsoft الجهاز عبر خدمة Windows Notification Services، واختصاراً WNS، كما في صفحة التنبيهات في إدارة Windows.

ويجدر الإشارة هنا إلى ملاحظة في صفحة BitLocker CSP نفسها: إدارة إعدادات BitLocker عبر CSP، غير تفعيله وتعطيله، تحتاج ترخيص Windows Enterprise E3 أو E5 أو ما يعادله أياً كانت أداة الإدارة. أما Windows Autopilot فهو المقابل للتسجيل التلقائي، ويقوم على Microsoft Entra ID، وتقول صفحة متطلباته إنه يعتمد على مزايا في Windows وMicrosoft Entra ID وخدمة MDM مثل Intune، أي أنه تبعية لخدمات Microsoft السحابية. والطريقة الأقدم هي Group Policy مع Active Directory، وهي ما زالت تعمل في الشبكات الداخلية، ولكنها تحتاج أن يرى الجهاز سيرفر الدليل Domain Controller، وهذا لا يحدث مع موظف يعمل من البيت دون VPN.

Linux: لا يوجد معيار MDM

لا يوجد في Linux إطار إدارة يبنيه المصنع ولا خدمة تنبيهات مركزية، لذلك تبني إدارة حواسيب Linux من ثلاث قطع: أداة لإدارة الإعدادات Configuration Management مثل Ansible تطبق الإعدادات وتعيد تطبيقها، وأداة رؤية مثل osquery تجيب عن أسئلتك عن حالة الجهاز، وبرنامج Agent يتصل بسيرفر مركزي، مثل fleetd من Fleet أو Agent من MeshCentral. والتشفير هنا هو LUKS، ويجب أن يختاره المستخدم عند تثبيت النظام، لأن تشفير قرص نظام يعمل بعد التثبيت ليس عملية تفرضها عن بعد بسهولة كما في FileVault وBitLocker. وأما تحديثات السيرفرات فقد شرحنا التحديثات الأمنية التلقائية في قسم unattended-upgrades من دليل تأمين السيرفر، والفكرة نفسها تصلح لحواسيب Ubuntu.

ماذا تستطيع أن تفرض وأن ترى؟

بعد التسجيل تحصل أداة الإدارة على قائمة طويلة من الصلاحيات، وأهمها لمؤسسة صغيرة ما يلي:

• سجل الأجهزة Inventory: العتاد Hardware والرقم التسلسلي ونسخة النظام وكل البرامج المثبتة ونسخها، وبالتالي تستطيع أن تجيب في دقيقة عن سؤال «أي أجهزة عليها نسخة Chrome المصابة بالثغرة؟».
• سياسات التحديث Update Policies: موعد نهائي لتثبيت التحديث، وبعده يثبت تلقائياً، بدلاً من «لاحقاً» إلى الأبد.
• تشفير القرص مع حفظ مفتاح الاستعادة Recovery Key Escrow: FileVault في macOS، وBitLocker في Windows، وLUKS في Linux، والجزء الأهم هو أن يحفظ مفتاح الاستعادة في سيرفر الإدارة، كما تشرح Apple في إدارة FileVault، والسبب أن الجهاز المشفر الذي نسي صاحبه كلمة المرور يصبح دون المفتاح قطعة حديد، ومعه بياناته.
• قفل الشاشة وكلمة المرور: طول الرمز، ومدة القفل التلقائي، وعدد المحاولات قبل المسح على الهواتف.
• جدار الحماية Firewall: تفعيله ومنع المستخدم من إيقافه.
• إزالة صلاحيات المدير المحلي: المستخدم يعمل بحساب عادي، والتثبيت يتم من متجر داخلي.
• توزيع التطبيقات App Deployment وقوائم السماح Allowlists: تثبيت تطبيقات العمل تلقائياً، ومنع ما ليس في القائمة على الأجهزة المملوكة للشركة.
• ملفات Wi-Fi وVPN والشهادات: تصل الأجهزة إلى شبكة المكتب وإلى VPN بإعدادات جاهزة، ويحذف كل ذلك تلقائياً عند إلغاء التسجيل.
• القفل والمسح عن بعد Remote Lock and Wipe: للجهاز كاملاً إذا كان ملك الشركة، ولقسم العمل وحده إذا كان شخصياً، وتشرح Apple في مسح الأجهزة أن المسح الكامل غير ممكن للأجهزة المسجلة بـ User Enrollment.
• فحوص الالتزام Compliance: قواعد تعطي كل جهاز حكماً «ملتزم» أو «غير ملتزم»، وهو ما سوف نستخدمه في القسم التالي.
• سجل التدقيق Audit Log: من أرسل أمر المسح، ومتى، ولأي جهاز.

حالة الجهاز في قرار الدخول

هنا تلتقي إدارة الأجهزة مع إدارة الهوية، فقد شرحنا في قسم Zero Trust أن كل طلب يجب أن يثبت هويته، وأن الثقة لا تأتي من مكان الجهاز في الشبكة. وحالة الجهاز Device Posture هي المعلومة التي تكمل هذه الفكرة: مزود الهوية لا يسأل عن كلمة المرور أو Passkey فقط، وإنما يسأل أداة الإدارة أيضاً: هل هذا الجهاز مسجل؟ وهل قرصه مشفر؟ وهل نظامه محدث؟ فإذا كان الجواب لا رفض الدخول وأخبر المستخدم بما يصلحه، كما في الصورة التالية:

وقد يتساءل البعض: هل تحتاج هذا من اليوم الأول؟ والإجابة على ذلك أن هذه الخطوة هي الأخيرة في الخطة، لأنها تحتاج أن تكون كل الأجهزة مسجلة أولاً، وإلا فإنك سوف تمنع نصف الموظفين من العمل في يوم التفعيل. ولاحظ أنها في أغلب الأدوات من مزايا الخطط المدفوعة، فهي في Fleet مثلاً ضمن Premium باسم Conditional Access، ويعمل التكامل غالباً مع مزود الهوية عبر OAuth وOpenID Connect.

الأدوات مفتوحة المصدر والمستضافة ذاتياً

سوق إدارة الأجهزة تسيطر عليه منتجات مغلقة مثل Microsoft Intune وJamf وKandji، وأغلبها خدمات سحابية بسعر لكل جهاز، ولكن هناك أدوات مفتوحة المصدر تستضيفها على سيرفرك، ولكل منها حدود يجب أن تعرفها قبل أن تختار، ومنها حدود الرخصة نفسها، لأن عدداً منها يتبع نموذج النواة المفتوحة Open Core الذي شرحناه في حرة أم مفتوحة أم مجانية. والصورة التالية تبين أين تقع كل أداة:

• Fleet: منصة إدارة لـ macOS وWindows وLinux وiOS وAndroid مبنية على osquery. الرخصة MIT لكل ما هو خارج المجلد ee/، وما في ee/ برخصة تجارية، وبحسب صفحة الخطط فإن الخطة المجانية تشمل MDM لكل الأنظمة وسجل الأجهزة والسياسات Policies وتشغيل السكربتات والإعدادات وDDM وقسم العمل في Android، أما فرض تشفير القرص وفرض التحديثات والقفل والمسح عن بعد وتوزيع التطبيقات والتسجيل التلقائي وConditional Access فهي في Premium. نقاط القوة: أداة واحدة لكل الأنظمة، وواجهة واضحة، وإدارة كاملة بالـ GitOps والـ API. نقاط الضعف: أهم أوامر الأمان مدفوعة، وتحتاج MySQL وRedis، وإدارة Apple فيها تحتاج شهادة APNs كأي أداة أخرى.
• osquery: برنامج من Meta في الأصل، يحول نظام التشغيل إلى قاعدة بيانات تسألها بلغة SQL، ويعمل على macOS وWindows وLinux، ورخصته مزدوجة Apache-2.0 أو GPL-2.0 تختار منهما. نقاط القوة: رؤية عميقة لكل حاسوب بلغة واحدة. نقاط الضعف: يرى ولا يفرض، فهو لا يشفر قرصاً ولا يثبت تحديثاً، ويحتاج سيرفراً مثل Fleet ليعمل على عدد من الأجهزة.
• NanoMDM: سيرفر MDM لأجهزة Apple برخصة MIT، صغير ويعمل عبر API، وهو مع NanoDEP وNanoCMD من الفريق نفسه، ويجمعها مشروع NanoHUB. أما MicroMDM الأقدم فقد أعلن فريقه في يونيو 2025 أنه في وضع الصيانة وأن إصلاحات الأمان تتوقف بنهاية 2025، لذلك لا تبدأ به. نقاط القوة: مفتوح بالكامل ويطبق البروتوكول كما هو. نقاط الضعف: لا توجد واجهة رسومية، ويحتاج سيرفر SCEP وTLS منفصلين، وهو أداة لمن يبني نظامه فوقها وليس لفريق دعم صغير.
• Headwind MDM: لأجهزة Android، ونسخة المجتمع برخصة Apache-2.0، وتسجل الأجهزة بمسح رمز QR، وتوزع التطبيقات، وقد بنت نظام تنبيهات خاصاً عبر MQTT فتعمل في شبكة داخلية دون FCM. نقاط القوة: مستقلة عن Google وتناسب أجهزة الكشك والمستودعات. نقاط الضعف: نموذج نواة مفتوحة، فالقيود على المستخدم ووضع الكشك Kiosk والقفل والمسح عن بعد في النسخة التجارية بحسب موقع المشروع.
• MeshCentral: سيرفر إدارة عن بعد برخصة Apache-2.0 لحواسيب Windows وLinux وmacOS، فيه سطح المكتب البعيد وسطر الأوامر ومتصفح الملفات من المتصفح. نقاط القوة: مفتوح بالكامل وسهل التشغيل. نقاط الضعف: أداة دعم وتحكم وليست MDM، فلا تفرض سياسات ولا تشفيراً.
• Tactical RMM: أداة RMM لحواسيب Windows أساساً، فيها التحديثات والسكربتات والمراقبة، وتعتمد على MeshCentral للتحكم عن بعد. ولكن رخصتها تقول صراحة إنها ليست رخصة مفتوحة المصدر، فهي تسمح باستخدامها داخل مؤسستك ولعملائك، وتمنع تقديمها خدمة تجارية دون إذن، كما أن الـ Agent الموقع رقمياً وAgent لـ Linux وmacOS متاحان للرعاة Sponsors بحسب وثائقها. نقاط القوة: أداة دعم فني متكاملة لـ Windows. نقاط الضعف: مصدر متاح Source-available وليست مفتوحة، ومزايا أساسية خلف الرعاية.
• Wazuh: منصة مراقبة أمنية برخصة GPL-2.0، والـ Agent فيها يجمع السجلات ويكشف التغييرات والثغرات على الحواسيب والسيرفرات. وهي ليست أداة إدارة، وإنما الطبقة التي تخبرك أن شيئاً غريباً يحدث على جهاز مدار، وسوف نشرحها في مرحلة الأمن السيبراني من خارطة الطريق.
• Ansible: لإدارة إعدادات حواسيب Linux وسيرفراتها بملفات YAML عبر SSH دون Agent، وهي الطريقة العملية لفرض إعدادات موحدة على عدد من حواسيب المطورين.

وإذا سألتنا عن نقطة بداية لمؤسسة صغيرة فالجواب هو Fleet، لأنه يعطيك من اليوم الأول سجل الأجهزة والسياسات لكل الأنظمة دون أن تدفع، ثم تقرر بعد ذلك هل تحتاج أوامر الأمان في Premium أو تطبقها بطرق أخرى، ولذلك اخترناه في التجربة العملية.

تجربة عملية: osquery ثم Fleet

سوف نبني في هذه التجربة حاسوباً تجريبياً داخل Container يعمل بـ Ubuntu 24.04 وعليه osquery 5.23.1، ثم نسأله أسئلة حقيقية، ثم نشغل Fleet ونسجل هذا الحاسوب فيه ونرسل إليه استعلاماً مباشراً Live Query وسياسة. ولاحظ أن Container ليس حاسوباً حقيقياً، فبعض الإجابات مثل التشفير سوف تصف جهاز Docker نفسه، وسوف نشير إلى ذلك في موضعه. ولن نسجل أجهزة Apple أو Android في هذه التجربة، لأن ذلك يحتاج شهادة APNs من Apple وحساباً عند Google وأجهزة حقيقية.

الخطوة 1: حاسوب تجريبي عليه osquery

الملف التالي يبني الحاسوب التجريبي، ويضيف إليه مستخدمين: sara في مجموعة sudo، وomar مستخدماً عادياً، ومعهما خدمتا SSH وNginx حتى نجد منافذ نسأل عنها:

FROM ubuntu:24.04
ADD https://github.com/osquery/osquery/releases/download/5.23.1/osquery_5.23.1-1.linux_amd64.deb /tmp/osquery.deb
RUN apt-get update && apt-get install -y /tmp/osquery.deb openssh-server sudo nginx-light && rm -rf /var/lib/apt/lists/* /tmp/osquery.deb \
 && useradd -m -s /bin/bash -G sudo sara && useradd -m -s /bin/bash omar

وبعد تشغيل ال Container والخدمتين نسأله أول سؤال، وهو نسخة النظام:

docker exec lab-mdm-laptop osqueryi "SELECT name, version, platform FROM os_version;"

والمخرج سوف يكون كما يلي:

+--------+----------------------------+----------+
| name   | version                    | platform |
+--------+----------------------------+----------+
| Ubuntu | 24.04.5 LTS (Noble Numbat) | ubuntu   |
+--------+----------------------------+----------+

ثم البرامج المثبتة، وهي الإجابة التي تحتاجها يوم تظهر ثغرة في مكتبة مثل OpenSSL:

docker exec lab-mdm-laptop osqueryi "SELECT count(*) AS packages FROM deb_packages;"
docker exec lab-mdm-laptop osqueryi "SELECT name, version FROM deb_packages WHERE name IN ('openssl','openssh-server','sudo','nginx-light');"

+----------+
| packages |
+----------+
| 201      |
+----------+
+----------------+---------------------------+
| name           | version                   |
+----------------+---------------------------+
| nginx-light    | 1.24.0-2ubuntu7.18        |
| openssh-server | 1:9.6p1-3ubuntu13.19      |
| openssl        | 3.0.13-0ubuntu3.16        |
| sudo           | 1.9.15p5-3ubuntu5.24.04.3 |
+----------------+---------------------------+

ثم المنافذ المفتوحة Listening Ports، مع اسم البرنامج الذي يفتح كل منفذ:

docker exec lab-mdm-laptop osqueryi "SELECT DISTINCT p.name, l.port, l.address FROM listening_ports l JOIN processes p USING (pid) WHERE l.port != 0 AND l.family = 2;"

+-------+------+---------+
| name  | port | address |
+-------+------+---------+
| nginx | 80   | 0.0.0.0 |
| sshd  | 22   | 0.0.0.0 |
+-------+------+---------+

ثم السؤال الأهم في إدارة الصلاحيات، وهو من يملك sudo على هذا الجهاز:

docker exec lab-mdm-laptop osqueryi "SELECT u.username, u.uid, u.shell FROM users u JOIN user_groups ug USING (uid) JOIN groups g ON g.gid = ug.gid WHERE g.groupname = 'sudo';"

+----------+------+-----------+
| username | uid  | shell     |
+----------+------+-----------+
| ubuntu   | 1000 | /bin/bash |
| sara     | 1001 | /bin/bash |
+----------+------+-----------+

في الأوامر أعلاه لاحظ التالي:

• كل سؤال هو جدول Table له أعمدة، مثل os_version وdeb_packages وlistening_ports، وقائمة الجداول لكل نظام في وثائق osquery، فعلى Windows مثلاً تجد جدول programs بدلاً من deb_packages.
• الربط JOIN بين الجداول هو ما يعطي osquery قوته، فقد ربطنا المنافذ بالعمليات لنعرف من يفتح كل منفذ، والمستخدمين بالمجموعات لنعرف من يملك sudo.
• المستخدم ubuntu يأتي مع ال Docker Image الرسمية لـ Ubuntu 24.04، ولم نضفه نحن، وهذا مثال على ما يكشفه سجل الأجهزة: حسابات لم تكن تعرف أنها موجودة.

ماذا يحدث عندما تسأل عن جدول لا يوجد على هذا النظام؟

لنسأل الحاسوب نفسه عن حالة BitLocker:

docker exec lab-mdm-laptop osqueryi "SELECT * FROM bitlocker_info;"

Error: no such table: bitlocker_info

والسبب أن هذا الجدول موجود في osquery على Windows فقط، فلكل نظام جداوله، وعلى Linux نسأل الجدول disk_encryption الذي يقرأ حالة LUKS:

docker exec lab-mdm-laptop osqueryi "SELECT name, encrypted FROM disk_encryption WHERE name LIKE '/dev/sd%';"

+----------+-----------+
| name     | encrypted |
+----------+-----------+
| /dev/sda | 0         |
| /dev/sdb | 0         |
| /dev/sdc | 0         |
| /dev/sdd | 0         |
+----------+-----------+

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

الخطوة 2: تشغيل Fleet

نشغل Fleet مع MySQL وRedis بالملف التالي، وهو مبني على دليل Fleet الرسمي لـ Docker Compose مع تثبيت نسخ ال Images، والحاسوب التجريبي من الخطوة السابقة جزء منه:

name: arabroot-lab-mdm
services:
  mysql:
    image: mysql:8.4.8
    container_name: lab-mdm-mysql
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: fleet
      MYSQL_USER: fleet
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    volumes: [mysql:/var/lib/mysql]
    healthcheck:
      test: ["CMD-SHELL", "mysqladmin ping -h 127.0.0.1 -ufleet -p$$MYSQL_PASSWORD --silent"]
      interval: 10s
      retries: 12
      start_period: 600s
  redis:
    image: redis:7.4.7
    container_name: lab-mdm-redis
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      retries: 12
      start_period: 600s
  fleet:
    image: fleetdm/fleet:v4.92.3
    container_name: lab-mdm-fleet
    depends_on:
      mysql: { condition: service_healthy }
      redis: { condition: service_healthy }
    command: sh -c "fleet prepare db --no-prompt && fleet serve"
    environment:
      FLEET_MYSQL_ADDRESS: mysql:3306
      FLEET_MYSQL_DATABASE: fleet
      FLEET_MYSQL_USERNAME: fleet
      FLEET_MYSQL_PASSWORD: ${MYSQL_PASSWORD}
      FLEET_REDIS_ADDRESS: redis:6379
      FLEET_SERVER_ADDRESS: 0.0.0.0:1337
      FLEET_SERVER_TLS: "true"
      FLEET_SERVER_CERT: /certs/fleet.crt
      FLEET_SERVER_KEY: /certs/fleet.key
      FLEET_SERVER_PRIVATE_KEY: ${FLEET_SERVER_PRIVATE_KEY}
    volumes: ["./certs:/certs:ro"]
    ports: ["127.0.0.1:18561:1337"]
  laptop:
    build: ./agent
    image: arabroot-lab-mdm-agent:local
    container_name: lab-mdm-laptop
    hostname: lab-mdm-laptop
    command: sleep infinity
    volumes: ["./certs/fleet.crt:/etc/osquery/fleet.crt:ro"]
volumes:
  mysql:

ونولد قبل التشغيل الأسرار وشهادة TLS باسم fleet، وهو الاسم الذي سوف يستخدمه الحاسوب للوصول إلى السيرفر داخل شبكة Docker:

mkdir -p certs agent
openssl req -x509 -nodes -days 30 -newkey rsa:2048 -keyout certs/fleet.key -out certs/fleet.crt -subj "/CN=fleet" -addext "subjectAltName=DNS:fleet,DNS:localhost"
cat > .env <<EOF
MYSQL_ROOT_PASSWORD=$(openssl rand -hex 16)
MYSQL_PASSWORD=$(openssl rand -hex 16)
FLEET_SERVER_PRIVATE_KEY=$(openssl rand -base64 32)
EOF
docker compose up -d --build

في الإعداد أعلاه لاحظ التالي:

• الأمر fleet prepare db ينشئ جداول قاعدة البيانات ويرحلها Migration عند كل تحديث، ويستغرق في التشغيل الأول عدة دقائق، فلا تقم بإيقاف ال Container في أثنائه. وإذا انقطع فسوف يفشل التشغيل التالي برسالة Duplicate column name، لأن الترحيل توقف في منتصف خطوة، والحل في التجربة أن تحذف ال Volume الخاص بـ MySQL وتبدأ من جديد، أما في الإنتاج Production فاستعد النسخة الاحتياطية التي أخذتها قبل التحديث.
• تشترط وثائق Fleet MySQL 8.0.44 أو أحدث، وتذكر أن MySQL 9.6.0 غير متوافق، لذلك ثبتنا النسخة 8.4.8 التي يختبرونها.
• الشهادة هنا موقعة ذاتياً للتجربة فقط، وفي الإنتاج تضع Fleet خلف Reverse Proxy بشهادة حقيقية، والأجهزة تحتاج أن تصل إلى السيرفر من الإنترنت، لأن الحاسوب في بيت الموظف لا يرى شبكتك الداخلية.
• نشرنا المنفذ على 127.0.0.1 فقط، فالواجهة لا تظهر لأحد خارج الجهاز الذي يشغل التجربة.

بعد أن يصبح السيرفر جاهزاً نفتح https://127.0.0.1:18561 في المتصفح، ويطلب Fleet ثلاث خطوات: حساب المدير الأول، واسم المؤسسة، وعنوان السيرفر الذي تتصل به الأجهزة، وقد وضعنا فيه https://fleet:1337.

الخطوة 3: تسجيل الحاسوب في Fleet

يتعرف Fleet على الأجهزة عبر سر التسجيل Enroll Secret، وتجده في الواجهة من زر Add hosts، أو عبر الـ API بعد تسجيل الدخول:

TOKEN=$(curl -sk https://127.0.0.1:18561/api/v1/fleet/login -H 'content-type: application/json' \
  -d '{"email":"[email protected]","password":"<admin password>"}' | jq -r .token)
curl -sk https://127.0.0.1:18561/api/v1/fleet/spec/enroll_secret -H "Authorization: Bearer $TOKEN"

{
  "spec": {
    "secrets": [
      {
        "secret": "rnc8NqJkp2C9p/fpV+o4Ra6h00PfaNO/",
        "created_at": "2026-10-05T23:35:06Z"
      }
    ]
  }
}

وفي الإنتاج تستخدم برنامج fleetd الذي يبنيه Fleet لكل نظام، ويثبت osquery ويحدثه ويحمل السر والشهادة، كما في صفحة تسجيل الأجهزة. أما في التجربة فنشغل osquery نفسه بالإعدادات التي يحتاجها للاتصال بـ Fleet عبر TLS:

docker exec lab-mdm-laptop sh -c 'echo "rnc8NqJkp2C9p/fpV+o4Ra6h00PfaNO/" > /etc/osquery/enroll_secret && chmod 600 /etc/osquery/enroll_secret && cat > /etc/osquery/osquery.flags <<EOF
--enroll_secret_path=/etc/osquery/enroll_secret
--tls_server_certs=/etc/osquery/fleet.crt
--tls_hostname=fleet:1337
--host_identifier=uuid
--enroll_tls_endpoint=/api/osquery/enroll
--config_plugin=tls
--config_tls_endpoint=/api/osquery/config
--config_refresh=10
--disable_distributed=false
--distributed_plugin=tls
--distributed_interval=10
--distributed_tls_max_attempts=3
--distributed_tls_read_endpoint=/api/osquery/distributed/read
--distributed_tls_write_endpoint=/api/osquery/distributed/write
--logger_plugin=tls
--logger_tls_endpoint=/api/osquery/log
--logger_tls_period=10
EOF
(osqueryd --flagfile=/etc/osquery/osquery.flags --verbose > /var/log/osqueryd.out 2>&1 &) ; sleep 8; grep -i -E "enroll|error|fail" /var/log/osqueryd.out | head -8'

I1005 23:35:43.031663    66 database.cpp:655] Failed to obtain database version. Assume version '0' and migrate.
I1005 23:35:43.032223    66 tls_enroll.cpp:81] TLSEnrollPlugin requesting a node enroll key from: https://fleet:1337/api/osquery/enroll
I1005 23:35:43.037572    66 tls.cpp:276] TLS/HTTPS POST request to URI: https://fleet:1337/api/osquery/enroll

لاحظ أن السطر الأول ليس خطأ، فهو osquery ينشئ قاعدة بياناته المحلية أول مرة، والمهم هو السطران التاليان: طلب التسجيل وصل إلى /api/osquery/enroll عبر HTTPS. وبعد بضع ثوان ظهر الحاسوب في صفحة Hosts:

وصفحة الجهاز تجمع ما يجمعه osquery تلقائياً، ولاحظ أن خانة Disk encryption تقول Unknown، وهذا متوقع داخل Container كما رأينا في الخطوة الأولى:

الخطوة 4: استعلام مباشر وسياسة

الآن نسأل الحاسوب من سيرفر Fleet، وليس من داخله، عن مستخدمي sudo، عبر نقطة Run live report on host في الـ API:

curl -sk -X POST https://127.0.0.1:18561/api/v1/fleet/hosts/1/query -H "Authorization: Bearer $TOKEN" -H 'content-type: application/json' \
  -d '{"query":"SELECT u.username, g.groupname FROM users u JOIN user_groups ug USING (uid) JOIN groups g ON g.gid = ug.gid WHERE g.groupname = '"'"'sudo'"'"';"}'

{
  "host_id": 1,
  "rows": [
    {
      "groupname": "sudo",
      "username": "ubuntu"
    },
    {
      "groupname": "sudo",
      "username": "sara"
    }
  ],
  "query": "SELECT u.username, g.groupname FROM users u JOIN user_groups ug USING (uid) JOIN groups g ON g.gid = ug.gid WHERE g.groupname = 'sudo';",
  "status": "online"
}

والاستعلام المباشر يجيب عن سؤال اليوم، أما السياسة Policy فهي سؤال يتكرر على كل جهاز ويعطي نتيجة نجاح Pass أو فشل Fail، وهي من الخطة المجانية في Fleet. والقاعدة في كتابتها أن الاستعلام يعيد صفاً إذا كان الجهاز سليماً، ولا يعيد شيئاً إذا كان مخالفاً. أضفنا سياستين: الأولى أن المستخدم ubuntu وحده في مجموعة sudo، والثانية أن نسخة osquery هي 5.23 أو أحدث:

curl -sk -X POST https://127.0.0.1:18561/api/v1/fleet/global/policies -H "Authorization: Bearer $TOKEN" -H 'content-type: application/json' \
  -d '{"name":"No extra admins (only ubuntu in sudo)","query":"SELECT 1 WHERE NOT EXISTS (SELECT 1 FROM users u JOIN user_groups ug USING (uid) JOIN groups g ON g.gid = ug.gid WHERE g.groupname = '"'"'sudo'"'"' AND u.username != '"'"'ubuntu'"'"');","platform":"linux","description":"Only the IT account may use sudo.","resolution":"Remove other users from the sudo group."}'
curl -sk -X POST https://127.0.0.1:18561/api/v1/fleet/global/policies -H "Authorization: Bearer $TOKEN" -H 'content-type: application/json' \
  -d '{"name":"osquery is up to date (5.23 or later)","query":"SELECT 1 FROM osquery_info WHERE version >= '"'"'5.23'"'"';","platform":"linux","description":"Agent version check.","resolution":"Update osquery."}'

وبعد أن طلبنا من الجهاز تحديث بياناته بزر Refetch، ظهرت النتيجة في تبويب Policies، والسياسة الأولى فشلت لأن sara في مجموعة sudo:

والآن نصلح المخالفة على الجهاز:

docker exec lab-mdm-laptop gpasswd -d sara sudo

Removing user sara from group sudo

وعند التحديث التالي للجهاز أصبحت السياسة الأولى Pass دون أن نلمس Fleet، وهذه هي الفكرة كلها: السياسة تبقى مكتوبة في السيرفر، والجهاز يقيم نفسه بها كل مرة، فإذا أضاف أحد مستخدماً إلى sudo بعد شهر فسوف تفشل السياسة من جديد وتراها في القائمة. ولاحظ أن Fleet في الخطة المجانية يكشف المخالفة ويستطيع أن يشغل سكربتاً يصلحها، أما الإصلاح التلقائي Remediation فهو من مزايا Premium.

إزالة التجربة

نحذف ال Containers وال Volume الخاص بقاعدة البيانات وال Image التي بنيناها، بأسمائها فقط:

docker compose down -v
docker image rm arabroot-lab-mdm-agent:local fleetdm/fleet:v4.92.3 mysql:8.4.8 redis:7.4.7

خطة لمؤسسة صغيرة: من أين تبدأ؟

أكثر مشاريع إدارة الأجهزة فشلاً هي التي تبدأ بأقوى القيود في يوم واحد، فتمنع الموظفين من العمل ثم تتراجع، لذلك نقترح هذا الترتيب، وكل خطوة تبني على التي قبلها:

1. سجل الأجهزة أولاً: ثبت أداة الإدارة أو الـ Agent على كل جهاز تملكه الشركة دون أي قيد، وسجل لكل جهاز صاحبه، والسبب أنك لا تستطيع أن تحمي ما لا تعرف بوجوده، والمرحلة الأولى لن تزعج أحداً لأنها تقرأ فقط.
2. التشفير والتحديثات: فعل FileVault وBitLocker مع حفظ مفاتيح الاستعادة في سيرفر الإدارة، وتأكد من وصول مفتاح كل جهاز قبل أن تنتقل، ثم ضع سياسة تحديث بموعد نهائي معقول، أسبوعاً مثلاً.
3. السياسات: قفل الشاشة، وجدار الحماية، ثم إزالة صلاحيات المدير المحلي مع طريقة لتثبيت البرامج المطلوبة، لأن إزالة الصلاحيات دون بديل تعني أن فريق الدعم سوف يتلقى عشرين طلباً في اليوم الأول.
4. الأجهزة الشخصية: قرر هل تسمح بها، وبأي طريقة، واكتب سياسة الاستخدام وإشعار الخصوصية قبل أن تسجل أي جهاز شخصي، كما في دليل الأجهزة الشخصية في العمل BYOD.
5. ربط حالة الجهاز بالدخول: بعد أن تصبح كل الأجهزة مسجلة وملتزمة، اجعل مزود الهوية يرفض الأجهزة غير الملتزمة، وابدأ بوضع المراقبة الذي يسجل ولا يمنع لأسبوعين قبل أن تفعل المنع.

الأخطاء الشائعة

• مسح البيانات الشخصية: المسح الكامل لهاتف شخصي بدلاً من قسم العمل يحذف صور الموظف ورسائله، وهذا خطأ لا يصلحه اعتذار، لذلك لا تقم بتسجيل الأجهزة الشخصية بطريقة تسمح بالمسح الكامل أصلاً.
• التشفير دون حفظ مفاتيح الاستعادة: أول موظف ينسى كلمة مروره بعد التشفير يفقد كل ما على جهازه، فتأكد من وصول المفتاح إلى السيرفر لكل جهاز قبل أن تعتبر التشفير مكتملاً.
• تسجيل المديرين في النهاية: أجهزة مديري الأنظمة والمحاسبة والإدارة العليا هي التي تحمل أهم البيانات وأوسع الصلاحيات، وغالباً تستثنى «حتى لا نزعجهم»، والصحيح أن تبدأ بأجهزة فريق تقنية المعلومات نفسه ثم الإدارة، فإذا نجح الأمر معهم نجح مع الجميع.
• تجاهل حواسيب Linux: حواسيب المطورين تحمل مفاتيح SSH وصلاحيات الوصول إلى السيرفرات، وغياب MDM لها لا يعني أن تتركها، فـ osquery مع Fleet وAnsible تغطي أغلب ما تحتاجه.
• نسيان تجديد شهادة APNs: إذا انتهت الشهادة توقفت كل أجهزة Apple عن الاستجابة للأوامر، وإذا أنشأت شهادة جديدة بحساب آخر بدلاً من تجديد القديمة فقد تحتاج إلى إعادة تسجيل الأجهزة.
• لوحة الإدارة دون حماية كافية: من يدخل لوحة الإدارة يستطيع أن يمسح كل الأجهزة أو يشغل سكربتاً عليها، لذلك عاملها كحساب مميز كما شرحنا في IAM وPAM.

قائمة التحقق

• هل لديك سجل بكل جهاز يدخل إلى بيانات الشركة، وصاحبه، ونظامه؟
• هل كل حاسوب للشركة مشفر، ومفتاح استعادته محفوظ في سيرفر الإدارة؟
• هل التحديثات تثبت بموعد نهائي، وهل تعرف الأجهزة المتأخرة اليوم؟
• هل أزلت صلاحيات المدير المحلي، ومعها طريقة واضحة لتثبيت البرامج؟
• هل قفل الشاشة وجدار الحماية مفروضان ولا يستطيع المستخدم إيقافهما؟
• هل تستطيع أن تقفل جهازاً ضائعاً أو تمسحه خلال دقائق، وهل جربت ذلك على جهاز تجريبي؟
• هل الأجهزة الشخصية مسجلة بقسم عمل منفصل، ومعها سياسة مكتوبة وإشعار خصوصية؟
• هل حذف الجهاز ومسح قسم العمل خطوة ثابتة في إجراءات خروج الموظف؟
• هل شهادة APNs وموعد تجديدها وحسابها مكتوبة في مكان يعرفه أكثر من شخص؟
• هل لوحة الإدارة خلف SSO مع MFA، وعدد مديريها قليل، وسجلها يراجع؟
• هل حواسيب Linux داخلة في السجل والسياسات مثل غيرها؟

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• كل جهاز يدخل إلى بريد الشركة وملفاتها هو جزء من حدودها الأمنية، والطلب من الموظفين لا يعطيك رؤية ولا قدرة على التصرف.
• MDM يستخدم إطار الإدارة الذي بناه المصنع في النظام، وRMM برنامج يثبت على الحاسوب، وUEM اسم لمنصة تجمع كل الأنظمة.
• السيرفر لا يرسل الأوامر مباشرة، وإنما يوقظ الجهاز عبر APNs أو FCM أو WNS، والجهاز يتصل بالسيرفر بشهادته ويستلم الأمر، وهذه الخدمات تبعية لا تلغيها الاستضافة الذاتية.
• جهاز الشركة يدار كاملاً، والجهاز الشخصي يدار قسم العمل فيه فقط، ولا ترى الشركة الصور والرسائل والتصفح في أي حالة.
• Fleet هو أقرب أداة مفتوحة لكل الأنظمة، ولكن فرض التشفير والتحديثات والقفل والمسح فيه من Premium، وNanoMDM لـ Apple وHeadwind لـ Android مفتوحان مع حدود، وTactical RMM ليست مفتوحة المصدر.
• ابدأ بالسجل، ثم التشفير مع مفاتيح الاستعادة والتحديثات، ثم السياسات، ثم الأجهزة الشخصية، ثم اربط حالة الجهاز بالدخول.

دليلإدارة الهوية والوصول IAM والوصول المميز PAMمن يملك صلاحية root على سيرفراتك ومنذ متى، وكيف تضبط حسابات المديرين بصلاحيات مؤقتة وجلسات مسجلة.دليلBYOD: كيف تحمي بيانات الشركة على أجهزة الموظفين الشخصيةكيف تختار طريقة وصول الموظفين من أجهزتهم الشخصية، وتعرف ما يحق للشركة أن تراه، وتكتب سياسة واضحة لذلك.دليلالدخول دون كلمة مرور: شرح Passkeys وWebAuthnلماذا لا تحميك رموز SMS وTOTP من التصيد الحديث، وكيف تحل Passkeys المشكلة بمفتاح خاص لا يغادر جهازك.دليلما هو VPN؟ الشبكة الخاصة الافتراضية من المشكلة إلى الأنواعلماذا تحتاج شبكة خاصة افتراضية VPN، وكيف تغلف حزمك وتشفرها داخل نفق، وأي نوع منها يناسب فريقك.دليلشرح OAuth وOpenID Connect للمبتدئينلماذا لا يجب أن يعرف أي تطبيق كلمة مرورك، وكيف يحل OAuth ذلك بتوكنات محدودة، وكيف يضيف OpenID Connect الدخول الموحد.دليلتأمين سيرفر VPS على Ubuntu من أول دخولقبل أن تثبت أي تطبيق على سيرفرك الجديد، هذه الخطوات تغلق أبرز الثغرات وأولها الدخول بمفتاح SSH بدل كلمة المرور.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، وتنفيذ تجربة osquery 5.23.1 على Ubuntu 24.04 وتسجيله في Fleet v4.92.3 مع MySQL 8.4.8 وRedis 7.4.7.