إدارة الهوية والوصول

مكتمل

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

تعتبر إدارة الهوية والوصول (IAM) حد الأمان في السحابة العامة. أساس أي بنية سحابة عامة وآمنة ومتوافقة تمامًا. تقدم Azure مجموعة شاملة من الخدمات والأدوات وهندسة المراجع لمساعدة المؤسسات على بناء بيئات عالية الأمان والكفاءة التشغيلية كما هو مُوضح هنا.

تتناول هذه الوحدة اعتبارات التصميم والتوصيات المتعلقة بـ IAM في بيئة المؤسسة.

التخطيط لإدارة الهوية والوصول

تتبع المؤسسات عادة نهجًا أقل حظًا في الوصول التشغيلي. ينبغي مراعاة هذا الطراز من خلال دليل Azure النشط الخاص بالوصول المستند إلى دور (RBAC) وتعريفات الدور المخصصة في دليل Azure النشط (Azure AD). من الضروري التخطيط لكيفية التحكم في الوصول إلى الموارد في Azure. ينبغي أن يلبي أي تصميم لـ IAM وRBAC المتطلبات التنظيمية والأمنية والتشغيلية قبل قبوله.

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

⁩مخطط يوضح الهوية وإدارة الوصول.⁧

عند التخطيط للوصول المُستند إلى الدور، استخدم تعريفات دور RBAC المُخصصة داخل مستأجر Azure AD ثم ضع في الاعتبار الأدوار الرئيسية التالية:

  • ⁩مالك النظام الأساسي Azure⁧⁩: يُستخدم لإدارة مجموعة الإدارة، وكذلك إدارة دورة حياة الاشتراك.

    {
      "Name": "Azure platform owner",
      "Id": "88888888-8888-8888-8888-888888888888",
      "IsCustom": true,
      "Description": "Used for management group and subscription lifecycle management.",
      "Actions": [
        "*"
      ],
      "NotActions": [],
      "DataActions": [],
      "NotDataActions": [],
      "AssignableScopes": [
        "/"
      ]
    }
    
  • ⁩إدارة الشبكة (NetOps)⁧⁩: تُستخدم لإدارة الاتصال العالمي على مستوى النظام الأساسي للشبكات الظاهرية، ومستودعات بيانات المُستخدم، ومجموعات أمان الشبكة، والأجهزة الظاهرية للشبكة، والشبكات الخاصة الظاهرية، وAzure ExpressRoute، وغيرها.

    {
      "Name": "NetOps",
      "Id": "88888888-8888-8888-8888-888888888888",
      "IsCustom": true,
      "Description": "Used for platform-wide global connectivity management of network resources.",
      "Actions": [
        "*/read",
        "Microsoft.Authorization/*/write",
        "Microsoft.Network/vpnGateways/*",
        "Microsoft.Network/expressRouteCircuits/*",
        "Microsoft.Network/routeTables/write",
        "Microsoft.Network/vpnSites/*"
      ],
      "NotActions": [],
      "DataActions": [],
      "NotDataActions": [],
      "AssignableScopes": [
        "/"
      ]
    }
    
  • ⁩عمليات الأمان (SecOps)⁧⁩: تمثل دور مسؤول أمان مع عرض أفقي عبر Azure بأكملها.

    {
      "Name": "SecOps",
      "Id": "88888888-8888-8888-8888-888888888888",
      "IsCustom": true,
      "Description": "Used for platform-wide visibility of security resources.",
      "Actions": [
        "*/read",
        "*/register/action",
        "Microsoft.KeyVault/locations/deletedVaults/purge/action",
        "Microsoft.Insights/alertRules/*",
        "Microsoft.Authorization/policyDefinitions/*",
        "Microsoft.Authorization/policyAssignments/*",
        "Microsoft.Authorization/policySetDefinitions/*",
        "Microsoft.PolicyInsights/*",
        "Microsoft.Security/*"
      ],
      "NotActions": [],
      "DataActions": [],
      "NotDataActions": [],
      "AssignableScopes": [
        "/"
      ]
    }
    
  • ⁩مالك الاشتراك⁧⁩: هو دور مُفوض لمالك الاشتراك مأخوذ من دور مالك الاشتراك.

    {
      "Name": "Subscription owner",
      "Id": "88888888-8888-8888-8888-888888888888",
      "IsCustom": true,
      "Description": "A delegated role for subscription owner derived from subscription owner role.",
      "Actions": [
        "*"
      ],
      "NotActions": [
        "Microsoft.Authorization/*/write",
        "Microsoft.Network/vpnGateways/*",
        "Microsoft.Network/expressRouteCircuits/*",
        "Microsoft.Network/routeTables/write",
        "Microsoft.Network/vpnSites/*"
      ],
      "DataActions": [],
      "NotDataActions": [],
      "AssignableScopes": [
        "/"
      ]
    }
    
  • ⁩مالكو التطبيقات (DevOps/AppOps):⁧⁩دور المساهم الممنوح لفريق التطبيق/العمليات.

    {
      "Name": "Application owners",
      "Id": "88888888-8888-8888-8888-888888888888",
      "IsCustom": true,
      "Description": "Contributor role granted for application/operations team.",
      "Actions": [
        "*"
      ],
      "NotActions": [
        "Microsoft.Network/publicIPAddresses/write",
        "Microsoft.Network/virtualNetworks/write",
        "Microsoft.KeyVault/locations/deletedVaults/purge/action"
      ],
      "DataActions": [],
      "NotDataActions": [],
      "AssignableScopes": [
        "/subscriptions/{applicationSubscriptionId1}",
        "/subscriptions/{applicationSubscriptionId2}",
        "/providers/Microsoft.Management/managementGroups/{applicationGroupId1}"
      ]
    }
    

ضع التوصيات والاعتبارات المتعلقة بإدارة الهوية والوصول

توجد حدود متعلقة بعدد الأدوار المخصصة وتعيينات الأدوار التي ينبغي مراعاتها عند وضع إطار عمل حول IAM والحوكمة. لمزيد من المعلومات، راجع حدود خدمة AZURE RBAC.

  • يوجد حد أقصى لـعدد 2000 تعيين دور RBAC مُخصص لكل اشتراك.
  • يوجد حد أقصى لـعدد 500 تعيين دور RBAC مُخصص لكل مجموعة إدارة.

عليك مراعاة الاختلافات بين ملكية المورد المركزية مقابل ملكية المورد الخارجي:

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

نوصي باستخدام Azure AD RBAC لإدارة الوصول إلى الموارد على مستوى البيانات، حيثما كان ذلك ممكنًا. من أمثلة ذلك Azure Key Vault أو حساب تخزين أو قاعدة بيانات SQL.

وزّع سياسات الوصول الشرطية لـAzure AD لأي مستخدم له حقوق في بيئات Azure. يوفر ذلك آلية أخرى للمساعدة في حماية بيئة Azure التي يتم التحكم فيها من خلال الوصول غير المُصرح به. افرض المُصادقة متعددة العوامل لأي مستخدم له حقوق إلى البيئات Azure. يعد فرض المُصادقة متعددة العوامل شرطًا لكثير من أطر الامتثال. حيث يقلل إلى حد كبير من خطر سرقة بيانات الاعتماد والوصول غير المُصرح به.

استخدم Azure AD Privileged Identity Management (PIM) لإنشاء الوصول غير الدائم والأقل امتيازًا. حدد أدوار المؤسسة إلى الحد الأدنى من الوصول المطلوب. يمكن لـ Azure AD PIM توسيع الأدوات والعمليات الموجودة أو استخدام أدوات Azure الأصلية كما هو مُوضح أو تنفيذ كليهما حسب الحاجة. استخدم المراجعات الوصول إلى Azure AD PIM للتحقق من صحة استحقاقات الموارد بشكل دوري. تُعد استعراضات الوصول جزءًا من العديد من أطر الامتثال. توجد منظمات عديدة لديها بالفعل عملية قائمة لتلبية هذا المطلب. استخدام مجموعات Azure AD فقط لموارد مستوى التحكم Azure في Azure AD PIM عند منح الوصول إلى الموارد. أضف مجموعات محلية إلى مجموعة Azure AD فقط إذا كان نظام إدارة مجموعة في مكانه بالفعل.

قم بدمج سجلات Azure AD مع جهاز Azure Monitor للنظام الأساسي. يسمح Azure Monitor بمصدر وحيد للحقيقة حول بيانات السجل ومراقبة البيانات في Azure، ما يمنح المؤسسات خيارات سحابة أصلية لتلبية المتطلبات المتعلقة بمجموعة السجلات والاحتفاظ به.

في حالة وجود أي متطلبات سيطرة للبيانات، فيمكن نشر نُهج المستخدم المخصص لتنفيذه.

استخدم Azure Security Center للوصول في الوقت المناسب لكل البنية الأساسية كموارد خدمة (IaaS) لتمكين حماية مستوى الشبكة لوصول المستخدم غير النهائي إلى الأجهزة الظاهرية IaaS.

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

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

لا تضف المستخدمين مباشرةً إلى نطاقات موارد Azure. يؤدي الافتقار إلى الإدارة المركزية إلى زيادة كبيرة في الإدارة اللازمة لمنع الوصول غير المُصرح به إلى البيانات المُقيدة.

خطط من أجل المصادقة داخل منطقة الهبوط

يكون قرار التصميم المهم الذي ينبغي للمؤسسة أن تتخذه عند اعتماد Azure متعلقًا بما إذا كان من الضروري توسيع نطاق الهوية المحلية الموجود في Azure أم إنشاء علامة جديدة. ينبغي تقييم متطلبات المُصادقة داخل منطقة الهبوط بدقة ودمجها في خطط لتوزيع خدمات مجال Active Directory (AD DS) في Windows Server أو Azure AD DS أو كليهما. سوف تستخدم معظم بيئات Azure على الأقل Azure AD من أجل مصادقة بنية Azure ومصادقة المضيف المحلي AD DS، وإدارة نهج المجموعة.

ضع التوصيات والاعتبارات الخاصة بالمُصادقة داخل منطقة الهبوط

عليك مراعاة المسؤوليات المركزية والمُفوضة لإدارة الموارد الموزعة داخل منطقة الهبوط. عليك أيضًا مراعاة التطبيقات التي تعتمد على خدمات المجال واستخدام البروتوكولات القديمة، والتي تستخدم Azure AD DS.

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

إذا كان لدى إحدى المؤسسات تصورًا بضرورة الوصول إلى تطبيق يستخدم مُصادقة Windows المتكاملة عن بُعد من خلال Azure AD، ففكّر في استخدام Azure AD Application Proxy.

تذكّر أنه يوجد فرق بين إعلان Azure وAzure AD DS وDS AD الذي يعمل على Windows Server. قم بتقييم احتياجات تطبيقك، وفهم وتوثيق موفر المُصادقة الذي سيستخدمه كل واحد. خطط لجميع التطبيقات وفقًا لذلك. قم بتقييم توافق أحمال العمل لـ AD DS على Windows Server وAzure AD DS. تأكد من سماح تصميم الشبكة للموارد التي تتطلب AD DS على Windows Server من أجل المصادقة المحلية والإدارة للوصول إلى وحدات التحكم بالمجال المناسبة. أمّا AD DS على Windows Server، فعليك مراعاة بيئات الخدمات المشتركة التي توفر مصادقة محلية وإدارة المضيف في سياق شبكة أكبر على مستوى المؤسسة.

وزّع Azure AD DS داخل المنطقة الأساسية لأن هذه الخدمة يمكن توقعها في اشتراك واحد فقط.

استخدم الهويات المُدارة بدلاً من أساسيات الخدمة للمُصادقة على خدمات Azure. يقلل هذا النهج من التعرض لسرقة بيانات الاعتماد.

اختبر معلوماتك

1.

كيف ينبغي أن تحدث مُصادقة موارد إلى مورد؟

2.

من الممارسات المُثلى لمالكي الاشتراكات أن يكون لديهم أذونات الكتابة لـ Microsoft.Authorization وأيضًا الحصول على أذونات دور المساهم.