تفويض مركزي بدلاً من الإجراء اليدوي

أعلنت GitHub ميزة جديدة لمؤسسات GitHub Enterprise Cloud تتيح لمسؤولي المؤسسة أتمتة تفويض المصادقة عبر الدخول الموحد، أو SSO، للرموز الشخصية الكلاسيكية ومفاتيح SSH الموجودة مسبقاً. وتستبدل هذه الإمكانية الإجراء اليدوي الذي كان يفرض على المطورين اعتماد بيانات الاعتماد لكل منظمة على حدة.

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

إعداد مؤسسي وصلاحية مخصصة للتطبيقات

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

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

تفويض ما يصل إلى 50 منظمة في طلب واحد

تتيح الواجهة البرمجية الجديدة لتطبيق GitHub App تفويض رمز شخصي كلاسيكي أو مفتاح SSH لعدد يصل إلى 50 منظمة ضمن طلب واحد. ويمنح ذلك المؤسسات طريقة جماعية لمعالجة بيانات الاعتماد المرتبطة بعدة منظمات، بدلاً من تكرار الاستدعاء أو الإجراء نفسه لكل منظمة على حدة.

تعتمد العملية على تعريف بيانات الاعتماد باستخدام معرّف الرمز غير السري أو بصمة مفتاح SSH. ولا تُرسل أسرار الرمز أو المفتاح إلى تطبيق GitHub، وهو فصل مهم بين تحديد بيانات الاعتماد وتنفيذ التفويض. وبذلك يستطيع التطبيق الإشارة إلى العنصر المطلوب مع تجنب تمرير قيم سرية ضمن الطلب.

تحققات قبل منح التفويض

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

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

تجاوز التفويضات النشطة ودعم التدوير

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

تقترح GitHub استخدام الواجهة البرمجية عندما تدير المؤسسة تفويض SSO لحسابات الخدمة أو لبيانات اعتماد الأتمتة عبر عدد كبير من المنظمات. ويمكن لتطبيق المؤسسة استدعاء الواجهة عند تدوير رمز أو مفتاح، وكذلك عند إضافة مجموعة من المنظمات الجديدة، بدلاً من تفويض كل منظمة يدوياً. وتقول الشركة إن الميزة متاحة حالياً لحسابات GitHub Enterprise Cloud.

المصادر

• GitHub ChangelogAutomate SSO authorization for classic PATs and SSH keys