اختبار Android Enterprise: Work Profile وFully Managed، وكيف تعرف حدود الإدارة بدل اسم Corporate؟

التطبيق نفسه موجود مرتين في الهاتف: نسخة عليها علامة حقيبة، ونسخة شخصية. ترفع السياسة في منصة MDM وتختبر النسخة الشخصية، ثم تقول إن المنع ما اشتغل. أحيانًا المشكلة ليست في السياسة ولا في Android؛ أنت اختبرت نسخة داخل سياق مختلف عن الذي تديره المؤسسة.

مراجعة Android Enterprise تبدأ من نوع الإدارة والـ Profile الذي تعمل فيه، ثم التطبيق والبيانات والقناة التي تمر منها. هذا المقال يبني اختبارًا مصرحًا على جهاز معمل، ويستخدم ADB للقراءة فقط عندما يسمح تصميم المختبر، مع شرح ما تكشفه النتائج وما لا تثبته. الهدف فهم حدود العمل والشخصي، مو خطوات كسر العزل أو إزالة إدارة جهاز شركة.

ثلاثة أوضاع لازم تفرقها قبل الفحص

Work Profile على جهاز شخصي يفصل تطبيقات وبيانات العمل عن المساحة الشخصية. الجهاز المملوك للشركة مع ملف عمل له نموذج آخر يسمح بقدرات إدارة إضافية تناسب الملكية مع بقاء فصل الاستخدام الشخصي. أما Fully Managed فيخص جهاز عمل مُدار بالكامل. توثيق Google يعرض هذه الحالات بصورة مستقلة؛ كلمة Corporate في منصة واحدة لا تشرح جميع الحقوق.

وDedicated Device يمثل جهازًا مخصصًا لوظيفة مثل كشك أو جهاز مستودع ضمن إدارة كاملة وفق النشر. هذا مختلف عن هاتف موظف يستخدم للعمل والشخصي. قبل اختبار سياسة نسخ أو كاميرا أو تطبيق، سجل نمط الإدارة وإصدار Android وطراز الجهاز ونسخة وكيل الإدارة.

إذا فريقك يستخدم اختصار COPE، اقرأ ماذا يقصد اليوم. بعض نماذج Fully Managed مع Work Profile القديمة تغيرت في Android 11، والتسمية قد تبقى في حديث الفريق أو واجهة المورد. لا تنقل نتيجة جهاز قديم إلى جهاز جديد بمجرد نفس الاسم. السلوك الحقيقي ونوع التسجيل هما المرجع الذي يبنى عليه الاختبار.

Profile Owner وDevice Owner مب مستخدم root

DPC هو مكون التحكم بسياسات الجهاز. ويمكن أن تكون سلطته مرتبطة بملف عمل أو بجهاز مُدار وفق النموذج والإصدار. هذه صفات إدارة في Android، لا تعني أن التطبيق يمتلك جلسة root عامة أو يستطيع قراءة جميع ملفات كل تطبيق. راجع الوظيفة الموثقة بدل إسقاط مصطلحات Windows أو Unix عليها.

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

هذا يفيد في التقرير: إذا عدم تطبيق إعداد سببه وضع إدارة لا يدعمه، فهو اختلاف تصميم أو اختيار نمط غير مناسب، مب تجاوز مثبت. وإذا الوضع يدعمه والسياسة المقصودة لم تصل أو لم تنفذ، تحتاج فحص التعيين والحالة والتطبيق. فصل سلطة DPC عن سلطة عملية Shell يحميك من استنتاجات كبيرة من لقطة واحدة.

اقرأ المستخدمين محليًا إذا مختبرك يجيز ADB

في جهاز معمل وافق مالكه على اتصال ADB، يمكن أن تبدأ بأمر قراءة:
adb shell pm list users

المخرجات تعرض مستخدمي أو Profiles الجهاز بحسب الإصدار، وتساعدك تميز معرف ملف العمل من السياق الأساسي. لا تفترض أن الرقم 10 هو ملف العمل دائمًا، ولا تنسخ رقمًا من مثال على الإنترنت إلى جهازك. اقرأ ما ظهر وراجعه مع إعداد المختبر.

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

احتفظ فقط بالحقول اللازمة لتمييز السياقات، ونقح الأسماء ومعرفات الجهاز قبل مشاركة الدليل. لما تعرف المعرفات تستطيع ربط التطبيق والاختبار بالـ Profile الصحيح، بدل شرح نتيجة غامضة تقول «التطبيق ما أخذ الإعداد» بينما التطبيق المختبر أصلاً النسخة غير المدارة.

dumpsys يساعدك تشوف حالة الإدارة، ما يعطيك حكمًا نهائيًا

أداة dumpsys تقرأ معلومات خدمات النظام. ابدأ في المعمل بالقائمة:
adb shell dumpsys -l

إذا ظهر اسم الخدمة device_policy في إصدار جهازك، تستطيع قراءة حالتها:
adb shell dumpsys device_policy

اقرأ الأقسام التي توضح المالك والملف والقيود المرتبطة بالسؤال. صيغة العرض تختلف بين الإصدارات والموردين، فلا تكتب parser يفترض ترتيب سطور ثابتًا ثم تعتبر غياب حقل دليلًا على غياب إدارة.

قارن الحالة بما في منصة MDM: هل تتكلم عن نفس الجهاز ونفس الملف وآخر اتصال؟ إذا المنصة تقول إن سياسة عُينت لكن الجهاز لا يعرض ما تتوقعه، راجع حالة التسليم والإصدار والقدرة المدعومة. لا تحفظ dump كاملًا في مقال عام؛ قد يحمل تفاصيل إعداد أو أسماء وبيانات ما تحتاجها.

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

نفس Package Name ممكن يعني نسختين ببيانات مختلفة

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

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

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

Managed Configuration إعداد تطبيق، مب دائمًا تفويض خدمة

يمكن للمنصة تعيين إعدادات لتطبيق يدعم Managed Configurations. قد تكون رابطًا أو خيار سلوك أو قيمة مرتبطة بالمستخدم. راجع ما يستهلكه التطبيق وكيف، ومن يستطيع كتابة إعداد العنصر في منصة الإدارة. كون الإعداد «Managed» يعني مسار توزيعه، ولا يثبت أن كل قيمة داخله آمنة أو سرية.

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

وفي الاختبار الهجومي السؤال عن مدخل ثقة: إذا قدرة تعديل إعداد تصل إلى تطبيق أعلى حساسية، هل يتحقق التطبيق من القيمة والغرض والهوية؟ لا تفترض أن تغيير عنوان يعني التقاط بيانات؛ هذا يحتاج تصميم التطبيق وتحليلًا منفصلًا. تبقى مراجعة ملكية الإعداد ومسار وصوله نتيجة نافعة حتى لو لم تُجر تجربة تغيير على خدمة حقيقية.

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

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

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

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

صلاحية إدارة التطبيق تختلف عن حق بيانات المستخدم

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

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

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

العزل عند تغيير الحالة: إيقاف الملف وإنهاء الخدمة

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

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

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

حالة إيجابية وسلبية تمنع تقريرًا على نسخة غلط

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

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

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

كيف تصنف الملاحظة وتختار المعالجة؟

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

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

وفي كل حالة اكتب ما ثبت وما لم يُختبر. نجاح نقل نص اختبار عبر قناة لا يثبت استخراج ملفات تطبيق، وقراءة dumpsys عبر ADB لا تثبت حق تطبيق عادي. هذه حدود واضحة تعطي نتيجة محترفة، وتخلي القارئ يفهم ليش الأدوات مفيدة من غير أن يعتبر كل مخرج تشخيصي اختراقًا.

مراجع Android والخطوة التالية في مراجعة MDM

نماذج الإدارة من Google:
https://developers.google.com/android/work/overview
https://developers.google.com/android/work/terminology

ملفات العمل واختبار التطبيقات:
https://developer.android.com/work/managed-profiles

قراءة خدمات النظام بأداة dumpsys:
https://developer.android.com/tools/dumpsys

ولربط أهلية الجهاز بقاعدة التسجيل قبل تطبيق السياسة، هذا مقال SOTI داخل المجتمع:
https://courses.cyberpts.com/community/162/akhtbar-tsjyl-alajhzh-fy-soti-enrollment-id-ykhtar-alsyash-lkn-mn-ythbt-an-aljha

قبل أي فحص اسأل: أي Profile؟ أي نسخة تطبيق؟ أي نمط إدارة؟ ثم اختر أداة قراءة تجيب عن واحدة منها، واختبر السلوك بقيمة عامة معروفة. فهم السياق يغير معنى النتيجة بالكامل، ويختصر تجربة طويلة ممكن كانت كلها على التطبيق أو المساحة الغلط.