Microsoft Azure

ماذا يحمل Microsoft Azure، ولماذا يهمّ ذلك هنا

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

ويعني أيضاً أن مسألة الهوية محسومة سلفاً. وحيث تحكم خدمة الهوية من هو من، يستطيع المساعد أن يرثها بدل أن يحتفظ بفكرة ثانية عمّن يرى ماذا — وهي الترتيبة التي تتقادم بسوء في كل مكان تُستخدم فيه.

والأسئلة هي أسئلة أي سحابة: هل هو سليم، وهل نجح، وكم يكلّف، وفي أي بيئة. والقيمة أنها تُسأل دون بوابة.

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

النطاق والتحكم عبر أدوار Azure

الأدوار المسندة للقراءة فقط. لا يستطيع Reader ولا Cost Management Reader إنشاء الموارد أو تعديلها أو حذفها، ولا يستطيع Storage Blob Data Reader كتابة الملفات أو حذفها. وأي قدرة على الكتابة ستكون قراراً منفصلاً مقصوداً، بدور مستقل.

والرؤية تُرسم على مستويين: الأدوار المسندة إلى كيان الخدمة تحدد الإطار الخارجي، وضمنه تحدد هوية السائل في Entra ID ومجموعاته ما يُقال له.

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

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

وللتدقيق تفصيل يستحق الانتباه: سجل النشاط (Activity Log) في Azure يسجّل التغييرات على الموارد لا القراءات، فلن يُظهر الكثير عن ربط للقراءة فقط. أما سجلات تسجيل الدخول الخاصة بكيان الخدمة في Entra ID فتُظهر متى تحقق من هويته، وسجلات موارد التخزين — إن فعّلتموها — تسجّل قراءة الملفات.

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

ما الذي يحلّ محلّه ربط Azure

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

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

والقراءة المحدودة النطاق تقع بين الاثنين: يُجاب السؤال، ولا يتّسع الوصول، ويُظهر سجل التدقيق بالضبط ما قُرئ ومن قرأه.

كيف تستفيدون فعلاً من ربط Azure

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

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

وقرّروا مبكراً هل تأتي إجابات السلامة من التنبيهات أم من المقاييس الخام. التنبيهات المعرّفة في Azure Monitor تختصر ما يعدّه فريقكم مشكلة، والإجابة منها تُبقي تعريف المساعد لـ«غير سليم» مطابقاً لتعريف المهندس المناوب. أما قراءة المقاييس مباشرة فتعني أن يطبّق المساعد حدوداً لم يتفق عليها أحد.

البيانات الشخصية والمستأجر والمناطق في Azure

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

وموقع البيانات في Azure تحدده المنطقة التي اخترتموها لكل مورد، وكثير من المؤسسات تفرض ذلك بقواعد المواقع المسموح بها في Azure Policy. الربط يقرأ الموارد حيث هي، ولا يغيّر منطقتها ولا ينسخها إلى اشتراك آخر. ضعوا قائمة الاشتراكات والمناطق المشمولة بجانب إسنادات الأدوار، ليرى المراجع الأمرين في مكان واحد.

ولأن كيان الخدمة يعيش في المستأجر لديكم، فالأدلة التي يحتاجها المراجع — إسنادات أدواره، وعمليات دخوله، وسجلات التخزين — محفوظة في Entra ID وAzure Monitor لديكم، لا في تقرير يصدر عنا.

كيف تُعالَج أسئلة Azure في أماكن أخرى

طريق Microsoft نفسها هو Copilot المدمج في بوابة Azure، الذي يجيب عن أسئلة الموارد والتكلفة لمن سجّل الدخول أصلاً، ضمن صلاحياته في RBAC. ويستطيع Azure Monitor أيضاً إرسال التنبيهات عبر مجموعات الإجراءات (action groups) إلى البريد أو الرسائل النصية أو webhook، وهكذا توصلها فرق كثيرة إلى قنوات Microsoft Teams. والخياران يناسبان من يعمل داخل البوابة أصلاً.

والمؤسسات التي تبني طبقتها الحوارية على منظومة Microsoft تستخدم غالباً Copilot Studio أو Azure AI Bot Service. وهذا طريق ممكن، ويحمل ما يحمله أي بناء داخلي من التزامات: جهة تصمم الصلاحيات، وتعالج العربية، وتتولى الصيانة.

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

والإخفاق الذي يتكرر هو اتساع النطاق بدافع السهولة: دور يُسند على مستوى الاشتراك أو مجموعة الإدارة (management group) لأنه أسرع من اختيار مجموعات الموارد. عندها يرث كل ما تحت ذلك النطاق الإسناد نفسه، بما في ذلك اشتراكات تُنشأ لاحقاً.