https://thedotnetblog.com/ar/tags/managed-identity/Articles, tutorials and insights from the .NET community.Hugoar@thedotnetblog (The .NET Blog)@thedotnetblogThu, 16 Jul 2026 00:00:00 +0000https://thedotnetblog.com/ar/news/emiliano-montesdeoca/cosmosdb-role-assignment-without-secrets/Thu, 16 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/ar/news/emiliano-montesdeoca/cosmosdb-role-assignment-without-secrets/إذا كان تطبيق Cosmos DB الخاص بك لا يزال يعتمد على المفاتيح، فأنت متأخر بالفعل في الأمان التشغيلي.<p>المصدر الأصلي: <a href="https://devblogs.microsoft.com/cosmosdb/which-azure-cosmos-db-role-does-my-app-need/">Which Azure Cosmos DB Role Does My App Need?</a></p> <p>أهم فكرة في هذا الدليل لـ Cosmos DB ليست أمرًا أو معرف دور أو خدعة CLI. إنها معمارية: توقف عن معاملة بيانات الاعتماد كتكوين للتطبيق وابدأ في معاملة الهوية كحالة وقت تشغيل.</p> <p>الكثير من الفرق لا تزال تشحن بسلاسل الاتصال لأنها تشعر بالسرعة. إنها ليست سريعة. إنها مخاطرة مؤجلة. كل مفتاح في ملف تكوين يصبح حادثة تنتظر commit متسرعًا أو متغير خط أنابيب منسوخًا أو سجلًا مسربًا. الهوية المدارة بالإضافة إلى RBAC لمستوى البيانات تزيل تلك الفئة من الفشل بالكامل تقريبًا.</p> <p>التحدي العملي هو الارتباك بين تفويض مستوى التحكم ومستوى البيانات. هذا هو المكان الذي تخسر فيه العديد من الفرق القوية أيامًا. أدوار Azure RBAC على الموارد لا تمنح تلقائيًا الوصول إلى المستندات، وأدوار مستوى بيانات Cosmos لا تمنح إدارة الحساب. إذا كان فريقك لا يوثق هذا الفصل صراحة في دفاتر التعليمات، فستستمر في الحصول على عمليات نشر هشة وأخطاء 403 يصعب تصحيحها.</p> <p>توصيتي الشخصية لفرق الإنتاج بسيطة:</p> <ul> <li>ابدأ بـ Data Reader لمسارات القراءة و Data Contributor فقط حيث تكون الكتابة مطلوبة حقًا.</li> <li>وسع النطاق فقط عندما يكون لديك حد تطبيق واحد لكل حساب.</li> <li>إذا شاركت حسابًا عبر الخدمات، ضيق النطاق مبكرًا إلى حدود قاعدة البيانات أو الحاوية بدلاً من انتظار ضغط التدقيق.</li> </ul> <p>هذا هو أحد تلك القرارات التي تتراكم. عندما تربط تطبيق .NET الخاص بك بـ DefaultAzureCredential وتكوين بنقطة نهاية فقط، كل بيئة تصبح أنظف: المحلية و CI والتجريبية والإنتاج. كما أنك تجعل الاستجابة للحوادث أسرع لأنه يمكنك الاستدلال على الأذونات من خلال تعيينات الأدوار بدلاً من مطاردة المفاتيح الغامضة.</p> <p>المقال يشير أيضًا إلى شيء يجب على الفرق الناضجة تبنيه: الأذونات كتصميم تكراري، وليس إعدادًا لمرة واحدة. يمكنك البدء واسعًا بما يكفي للتوصيل، ثم التضييق باستخدام التليمترية ومراجعات الوصول. أقل امتياز ليس غاية فلسفية؛ إنه عادة توصيل.</p> <p>إذا كنت ستتبنى شيئًا واحدًا فقط من هذا المقال، اجعله هذا: أزل الأسرار أولاً، حسّن الأدوار ثانيًا. الفرق التي تعكس هذا الترتيب عادة ما تتعطل في الاجتماعات. الفرق التي تزيل الأسرار أولاً عادة ما تشحن ثم تصلب.</p> <p>في 2026، الوصول إلى البيانات بدون أسرار ليس نمطًا متقدمًا. إنه الحد الأدنى المسؤول لأنظمة .NET الجادة على Azure.</p>