تحوّل هندسة الأمان متطلبات حمل العمل إلى “عنصر تحكم” (control) يمكن اختباره ومراقبته وإزالته بأمان. في Azure، يمتد هذا العمل ليشمل مستأجر Microsoft Entra، وAzure Resource Manager ضمن اشتراك معين، ومستوى البيانات (data plane) لكل خدمة؛ لذا قد يحمي إعدادٌ يبدو صحيحاً نطاقاً خاطئاً.
سنستخدم حمل عمل تطويري محدد النطاق داخل مجموعة الموارد الوهمية rg-orders-dev. والهدف من ذلك هو توضيح القرارات والأدلة والحدود التي يجب على مهندس أمان السحابة تحديدها قبل اعتماد إعداد معين كإجراء حماية.
ابدأ بمتطلب مرتبط بأصل (asset) وتهديد معين. على سبيل المثال، يجب أن تقوم واجهة برمجة تطبيقات (API) لمعالجة الطلبات باسترداد سر (secret) دون كشفه عبر شبكة الإنترنت العامة. يُعرف عنصر التحكم بأنه الآلية المكوّنة لتلبية هذا المتطلب، بينما يُعد الدليل (evidence) سجلاً قابلاً للملاحظة يدعم ادعاءً محدداً حول تكوين عنصر التحكم أو نشاطه.
يتميز سير العمل لدينا بالاتساق؛ إذ نحدد الأصل، وحدود البيانات، والهوية، والتهديد؛ ونختار أصغر عنصر تحكم مناسب؛ ونحدد الفشل المتوقع في حال رفض الوصول أو اتخاذ حركة المرور مساراً غير مقصود؛ ثم نتحقق من النتيجة المرجوة باستخدام أدلة التكوين وأدلة وقت التشغيل. وتعمل عملية التنظيف على إزالة الأذونات المؤقتة، أو أسرار الاختبار، أو إعدادات التشخيص عند عدم الحاجة إليها، مما يمنع تحول بقايا الاختبار إلى نقاط انكشاف أمني دائمة.
تجيب أدلة التكوين وأدلة وقت التشغيل على أسئلة مختلفة. فتعيين الأدوار أو تكوين نقطة نهاية خاصة (private endpoint) يوضح الحالة المقصودة لمستوى التحكم (control plane). أما حدث التدقيق في Key Vault، أو سجل تشخيص التخزين، أو فشل التطبيق، فيوضح محاولة مرصودة على مستوى البيانات (data plane) ضمن الإطار الزمني المسجل لها. ولا يكفي أي منهما بمفرده لإثبات أن كل مسار آمن أو أن الحادثة الأمنية ليس لها سبب آخر.
تحدد التوصيات الفجوات في الوضع الأمني، ولكن يجب أن يأتي الإنفاذ الفعلي من سياسة “الرفض” (deny policy) أو من عنصر التحكم نفسه.
تتولى Microsoft تأمين البنية التحتية المادية الأساسية لـ Azure، بينما يظل العميل مسؤولاً عن بيانات حمل العمل، وسلوك التطبيق، والهويات، وخيارات الوصول. لا يعني حد المسؤولية المشتركة هذا أن الخدمة المُدارة بواسطة المنصة لا تتطلب أي عمل أمني من جانب العميل؛ بل يعني أنه يجب علينا تحديد الطرف المسؤول عن كل طبقة قبل اختيار الأدلة أو إجراءات المعالجة.
يقوم دليل Microsoft Entra بمصادقة المستخدمين والتطبيقات والهويات المُدارة. ويُعد Azure Resource Manager (المعروف اختصاراً بـ ARM) مستوى التحكم في Azure لإنشاء الموارد وتكوينها ضمن اشتراك أو مجموعة موارد. وتعمل تعيينات أدوار Azure RBAC (التحكم في الوصول المستند إلى الأدوار) ضمن هذه النطاقات على تخويل إجراءات مستوى التحكم، مثل تغيير تكوين الشبكة لحساب التخزين.
يُقصد بـ مستوى البيانات (data plane) للخدمة تلك الواجهة الخاصة بالخدمة التي تقوم بقراءة البيانات المحمية أو كتابتها أو استخدامها. وتتم عمليات استرداد الأسرار من Key Vault والوصول إلى بيانات Blob عبر مستويات البيانات الخاصة بكل منها، حيث يتم تطبيق قواعد التخويل وضوابط الشبكة الخاصة بمستوى البيانات بشكل مستقل عن تخويل ARM. وبالتالي، فإن المستخدم الذي يمتلك دور “مساهم” (Contributor) ويستطيع تكوين المخزن (vault) ليس مخولاً بالضرورة لقراءة الأسرار الموجودة فيه.
تتمثل القاعدة القابلة لإعادة الاستخدام في تحديد الكيان (principal)، والإجراء، والنطاق، والمستوى (plane) قبل الحكم على ما إذا كان ينبغي للوصول أن ينجح.
يتمثل حمل العمل الافتراضي لدينا في app-orders-api، وهو تطبيق ضمن خدمة Azure App Service موجود في مجموعة الموارد rg-orders-dev، وذلك ضمن اشتراك افتراضي يحمل المعرف <subscription-id>. يعمل التطبيق في منطقة Azure مختارة ويستخدم الشبكة الافتراضية vnet-orders-dev للتكامل مع الشبكة الافتراضية الصادرة. يحتاج التطبيق إلى بيانات الطلبات الموجودة في stordersdev وسر مخزن في kv-orders-dev، بينما تُعد law-sec-01 مساحة عمل Log Analytics المستخدمة من قبل Microsoft Sentinel.
تُعد الشبكة الافتراضية بمثابة الحد الشبكي للتطبيق، وليست بالضرورة الموقع الذي توجد فيه كافة موارد خدمات Azure. تظل كل من stordersdev وkv-orders-dev خدمات تابعة لمنصة Azure وتقع خارج نطاق الشبكة الافتراضية vnet-orders-dev؛ وتعمل نقاط النهاية الخاصة (Private Endpoints) على وضع واجهات شبكة خاصة لتلك الخدمات داخل الشبكة الافتراضية. يجب أن تقوم إعدادات نظام أسماء النطاقات (DNS) الخاص وإعدادات الشبكة للخدمة بتوجيه الطلبات الصادرة من واجهة برمجة التطبيقات (API) إلى عناوين نقاط النهاية تلك بدلاً من توجيهها إلى نقطة نهاية عامة.
ستحتاج الهوية المُدارة للتطبيق لاحقاً إلى أذونات منفصلة خاصة بمستوى البيانات (data-plane) لتنفيذ الإجراءات المطلوبة في كل من Key Vault وStorage. يعمل Sentinel على المورد law-sec-01؛ حيث تحدد الموصلات (connectors) وإعدادات التشخيص السجلات التي سيتم استقبالها وتحليلها. ولا يمكن لمساحة العمل دعم عمليات التحقيق إلا فيما يتعلق بالبيانات التي تم تجميعها فعلياً داخلها.
تتبّع حدود عبء العمل (workload boundary) بدءاً من واجهة برمجة التطبيقات (API) ووصولاً إلى نقاط النهاية الخاصة بها ومساحة عمل المراقبة.