Azure Fundamentals · درس

الهوية المدارة للمصادقة دون كلمات مرور

عيّن هوية مدارة مخصصة للنظام إلى جهاز ظاهري أو App Service، وامنحها صلاحيات RBAC للوصول إلى Key Vault وBlob Storage، وأزل الأسرار من تعليمات التطبيق البرمجية

الهوية المدارة للمصادقة دون كلمات مرور درس مجاني في Azure Fundamentals على CoddyKit. هذا هو الدرس 1 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Azure Fundamentals، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Azure Fundamentals 4 دروس في المجموع.

مشكلة بيانات الاعتماد المخزنة

تقليديًا، تتصل التطبيقات بخدمات Azure مثل Storage أو Key Vault باستخدام سلاسل الاتصال أو مفاتيح API المخزنة في ملفات الإعداد أو متغيرات البيئة. وقد تُدرج بيانات الاعتماد هذه عن طريق الخطأ في نظام التحكم في المصدر، أو تنكشف في السجلات، أو تُسرق في حالة اختراق. تلغي Managed Identity حاجة التطبيقات إلى تخزين بيانات الاعتماد تمامًا؛ إذ تصدر Azure نفسها رمزًا مميزًا وتجدده نيابةً عن المورد، ولا يحتاج التطبيق سوى إلى طلب الرمز المميز الحالي من Azure أثناء التشغيل.

ما المقصود بالهوية المُدارة؟

إن Managed Identity عبارة عن service principal تتم إدارته تلقائيًا في Microsoft Entra ID ويرتبط بمورد Azure، مثل VM أو App Service أو Function App. تنشئ منصة Azure بيانات اعتماد الهوية وتحافظ عليها، مع تدويرها بانتظام، لذلك لا تتعامل التعليمات البرمجية الخاصة بك مطلقًا مع كلمة مرور أو سر. وتستدعي التطبيقات التي تعمل على المورد نقطة النهاية Azure Instance Metadata Service (IMDS) على العنوان http://169.254.169.254 للحصول على رمز OAuth قصير الأجل، ثم تقدمه إلى خدمات Azure.

# Get a token from IMDS (runs inside an Azure VM or App Service)
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://storage.azure.com/' \
  -H 'Metadata: true'

المعيّنة للنظام مقابل المعيّنة للمستخدم

هناك نوعان من الهوية المُدارة: ترتبط المعيّنة للنظام بمورد Azure واحد؛ إذ تُنشأ عند تمكينها على المورد وتُحذف تلقائيًا عند حذف المورد. أما المعيّنة للمستخدم فهي هوية مستقلة في Entra ID تنشئها بشكل منفصل، ثم تربطها بمورد Azure واحد أو أكثر. وتفيد الهويات المعيّنة للمستخدم عندما تحتاج خدمات متعددة، مثل عدة Function Apps، إلى مشاركة الهوية نفسها وأذونات RBAC، مما يلغي تكرار تعيينات الأدوار.

# Enable system-assigned managed identity on an App Service
az webapp identity assign \
  --resource-group myRG \
  --name myWebApp

# Create and assign a user-assigned identity
az identity create --name mySharedIdentity --resource-group myRG
az webapp identity assign \
  --resource-group myRG \
  --name myWebApp \
  --identities mySharedIdentity

منح أذونات RBAC

بعد تمكين هوية مُدارة، يجب منحها أذونات RBAC على مورد Azure المستهدف. فعلى سبيل المثال، للسماح لـ App Service بقراءة الكائنات الثنائية كبيرة الحجم، عيّن دور Storage Blob Data Reader إلى الهوية المُدارة الخاصة بـ App Service على حساب التخزين. وتتبع تعيينات RBAC مبدأ أقل قدر من الامتيازات؛ لذا امنح الحد الأدنى فقط من الأذونات المطلوبة. لا تعيّن دور Owner أو Contributor إلى هوية مُدارة إلا عند الضرورة القصوى.

# Get the managed identity object ID
PRINCIPAL_ID=$(az webapp identity show \
  --resource-group myRG --name myWebApp \
  --query principalId --output tsv)

# Assign Storage Blob Data Reader role
az role assignment create \
  --assignee $PRINCIPAL_ID \
  --role 'Storage Blob Data Reader' \
  --scope '/subscriptions/<sub>/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/mystorageacct'

استخدام DefaultAzureCredential في التعليمات البرمجية

توفر Azure SDK فئة DefaultAzureCredential التي تجرب تلقائيًا عدة أساليب للمصادقة بالترتيب: متغيرات البيئة، وهوية حمل العمل، والهوية المُدارة، وAzure CLI، وVisual Studio، وغيرها. وعند تشغيل التطبيق على Azure، مثل App Service أو VM أو Function App، تستخدم DefaultAzureCredential الهوية المُدارة تلقائيًا من دون أي تغييرات في التعليمات البرمجية. أما محليًا، فيسجل المطورون الدخول من خلال جلسة Azure CLI الخاصة بهم. وتعمل فئة بيانات الاعتماد الواحدة هذه في جميع البيئات من دون منطق شرطي.

# Python example using DefaultAzureCredential
from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

credential = DefaultAzureCredential()
client = BlobServiceClient(
  account_url='https://mystorageacct.blob.core.windows.net',
  credential=credential
)
blobs = client.get_container_client('mycontainer').list_blobs()
for blob in blobs:
    print(blob.name)

الهوية المُدارة مع Azure Key Vault

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

# Python: Read a Key Vault secret using managed identity
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient

credential = DefaultAzureCredential()
client = SecretClient(
  vault_url='https://mykeyvault.vault.azure.net/',
  credential=credential
)
secret = client.get_secret('DatabasePassword')
print('Secret value retrieved successfully')

الهوية المُدارة للوصول إلى Azure SQL

تدعم Azure SQL Database مصادقة Entra ID، ما يعني أن الهوية المُدارة يمكنها المصادقة على SQL من دون اسم مستخدم وكلمة مرور. لتمكين ذلك: عيّن مسؤول Entra ID على خادم SQL، ثم نفّذ عبارة CREATE USER في قاعدة البيانات المستهدفة باسم العرض الخاص بالهوية المُدارة، وامنحها دور قاعدة البيانات المناسب. ويتصل التطبيق باستخدام DefaultAzureCredential من Azure SDK ورمز وصول مخصص للنطاق https://database.windows.net/، وبذلك تتم المصادقة بالكامل من دون كلمة مرور.

-- In Azure SQL: create a user for the managed identity
CREATE USER [myWebApp] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [myWebApp];
ALTER ROLE db_datawriter ADD MEMBER [myWebApp];

الهوية المُدارة لأحمال عمل AKS

في Azure Kubernetes Service، يمكن لكل pod الحصول على رموز الهوية المُدارة باستخدام Workload Identity، وهي الخلف لـ AAD Pod Identity. تنشئ هوية مُدارة معيّنة للمستخدم، وتربطها بمُصدر OIDC الخاص بـ AKS، وتضيف تعليقًا إلى حساب خدمة Kubernetes، ثم تحقن وحدة تحكم Azure Workload Identity متغيرات البيئة اللازمة حتى يتمكن DefaultAzureCredential الخاص بـ pod من الحصول على رمز. ويمد هذا النمط المصادقة من دون كلمات مرور إلى الخدمات المصغرة التي تعمل في حاويات، من دون تخزين الأسرار في كائنات Kubernetes Secrets.

# Create federated identity credential for AKS workload identity
az identity federated-credential create \
  --name myFederatedCredential \
  --identity-name mySharedIdentity \
  --resource-group myRG \
  --issuer $(az aks show --resource-group myRG --name myAKS --query 'oidcIssuerProfile.issuerUrl' -o tsv) \
  --subject 'system:serviceaccount:default:myapp-sa' \
  --audiences 'api://AzureADTokenExchange'

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

على الرغم من أن بيانات اعتماد الهوية المُدارة غير مرئية للمطورين، تُسجَّل جميع أحداث إصدار الرموز المميزة والوصول إلى الموارد. تسجل سجلات تسجيل الدخول في Entra ID كل طلب رمز مميز صادر عن هوية مُدارة، بما في ذلك المورد الذي يتم الوصول إليه، والوقت، وما إذا كان الطلب قد نجح. كما تسجل سجلات نشاط Azure Storage وسجلات تدقيق Key Vault العمليات المحددة التي نُفذت باستخدام الرمز المميز. وتُعد هذه السجلات ضرورية لعمليات التدقيق الأمني والتحقيق في الحوادث التي تشمل الهويات المُدارة.

# Query Entra ID sign-in logs for a managed identity
az monitor activity-log list \
  --resource-group myRG \
  --caller myWebApp \
  --start-time 2024-06-01 \
  --output table

الترحيل من سلاسل الاتصال

إذا كان تطبيقك يستخدم حاليًا سلاسل الاتصال أو مفاتيح API، فانتقل إلى الهوية المُدارة في ثلاث خطوات: الخطوة 1 — مكّن هوية مُدارة على مورد الحوسبة. الخطوة 2 — عيّن أدوار RBAC المناسبة للهوية على كل خدمة مستهدفة. الخطوة 3 — حدّث التعليمات البرمجية للتطبيق لاستخدام DefaultAzureCredential بدلًا من سلسلة الاتصال. أزل سلسلة الاتصال من إعدادات App Service ومن Key Vault بعد التحقق من نجاح الترحيل. ويمكن عادةً إكمال هذا الترحيل مع إجراء تغييرات طفيفة على التعليمات البرمجية في تطبيقات Azure SDK الحديثة.

ملخص فوائد الأمان

توفر Managed Identity أربع فوائد أمنية رئيسية مقارنة بالمصادقة القائمة على بيانات الاعتماد: عدم تخزين بيانات الاعتماد — فلا يوجد ما يمكن سرقته أو إدراجه عن طريق الخطأ. التدوير التلقائي — تدوّر Azure الشهادات الأساسية من دون توقف. أذونات محددة النطاق — لا تُمنح الهويات إلا أدوار RBAC التي تحتاج إليها، وفق مبدأ أقل قدر من الامتيازات. سجل تدقيق كامل — تُسجَّل جميع محاولات الوصول في Entra ID وسجلات تدقيق الخدمة التي تم الوصول إليها. وبالنسبة إلى أي تكامل جديد مع خدمات Azure، ينبغي أن تكون الهوية المُدارة نهج المصادقة الافتراضي.

تحقّق سريع

اختبروا مدى فهمكم لمفاهيم Microsoft Azure Fundamentals (AZ-900) الواردة في هذا الدرس.

مراجعة الدرس

تعلّمتم في هذا الدرس أن الهوية المُدارة تلغي الحاجة إلى بيانات الاعتماد المخزّنة من خلال منح موارد Azure هوية Entra ID تتم إدارتها تلقائيًا، وأن DefaultAzureCredential في Azure SDK يستخدم الهوية المُدارة بشفافية في Azure وبيانات اعتماد المطوّر محليًا، وأن تعيينات أدوار RBAC على الخدمات المستهدفة تتحكم في الموارد التي يمكن للهوية الوصول إليها. بعد ذلك، سنستكشف Azure Service Bus للمراسلة غير المترابطة بين مكوّنات التطبيق.

الأسئلة الشائعة

هل درس «الهوية المدارة للمصادقة دون كلمات مرور» مجاني؟

نعم — نص درس «الهوية المدارة للمصادقة دون كلمات مرور» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Azure Fundamentals، انتقل إلى CoddyKit PRO. تتضمن دورة Azure Fundamentals 4 دروس في المجموع.

ماذا ستتعلم في «الهوية المدارة للمصادقة دون كلمات مرور»؟

عيّن هوية مدارة مخصصة للنظام إلى جهاز ظاهري أو App Service، وامنحها صلاحيات RBAC للوصول إلى Key Vault وBlob Storage، وأزل الأسرار من تعليمات التطبيق البرمجية تتمرن على Azure Fundamentals مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ Azure Fundamentals؟

لا تُشترط خبرة سابقة. Azure Fundamentals على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 1 من أصل 4.

كم من الوقت يستغرق درس «الهوية المدارة للمصادقة دون كلمات مرور»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس Azure Fundamentals هذا؟

نعم. كل درس في Azure Fundamentals يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

← العودة إلى Azure Fundamentals