تطلق Turnkey خدمة Managed Secrets لإتاحة بيانات الاعتماد لوكلاء الذكاء الاصطناعي

أطلقت Turnkey خدمة Managed Secrets، موسعةً بذلك بنيتها التحتية للمحافظ القائمة على البيئات المعزولة لتشمل مفاتيح واجهات برمجة التطبيقات وكلمات المرور وبيانات الدفع ومواد استعادة الحساب التي تحتاج إليها التطبيقات ووكلاء الذكاء الاصطناعي للعمل. ويُخرج إعلان 29 أكتوبر الشركة من نطاق إدارة المفاتيح الخاصة إلى معالجة مشكلة أوسع: تمكين البرمجيات من التصرف دون توزيع بيانات اعتماد قابلة لإعادة الاستخدام في مختلف أجزاء بنيتها التحتية.

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

نقل الوصول إلى بيانات الاعتماد إلى داخل حدود البيئة المعزولة

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

تُجري Managed Secrets عمليات التحقق من الصلاحيات داخل البيئات المعزولة الآمنة التابعة لـTurnkey. ويشفّر العميل السر قبل استيراده، ثم تعيد البيئة المعزولة تشفيره لتخزينه. وعند وصول طلب، تقيّم البيئة المعزولة السياسات والموافقات ذات الصلة قبل تشفير النتيجة بالمفتاح الخاص بالمستلم المقصود. ويمكن أن تكون الخدمة الطالبة والخدمة المستلمة خدمتين مختلفتين.

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

التشفير وراء الاستيراد والتصدير

يشرح توثيق قناة الاتصال الآمنة لدى Turnkey بروتوكولًا يستند إلى التشفير الهجين بالمفتاح العام، أو HPKE. ويجمع البروتوكول بين اتفاق المفاتيح باستخدام المفتاح العام والتشفير الموثَّق، ما يتيح نقل المواد الحساسة عبر الأنظمة الوسيطة في صورة نص مشفّر. ويتحقق العميل، عند الاستيراد، من مواد المفاتيح الموقّعة من البيئة المعزولة، بينما تُشفَّر البيانات عند التصدير باستخدام مفتاح عام مُدرج في الطلب الموقّع.

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

تحدد صفحة منتج Managed Secrets تشفيرًا لكل سر باستخدام AES-256-GCM أثناء التخزين. وتدعم واجهة برمجة التطبيقات بيانات الاعتماد الفردية والطلبات التي تشمل عدة أسرار. وتفشل عمليات التصدير المجمعة بالكامل إذا لم يكن أحد الأسرار المطلوبة حاصلًا على التفويض، ما يمنع الإفراج عن حزمة لم تحظَ جميع عناصرها بالموافقة.

لماذا تظل هوية المستلم مهمة

تصف عبارة «يمكن للوكلاء استخدام بيانات الاعتماد دون الاطلاع عليها» نمطًا للتكامل، لا ضمانًا بأن كل عملية مستلمة ستظل عاجزة عن قراءة النص الصريح. ويوضح توثيق المطورين لدى Turnkey صراحةً أن النص الصريح قد يوجد داخل البيئة المعزولة وعلى جهاز العميل الذي يستورد السر أو يصدّره.

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

وثمة حد فاصل آخر: يمكن للسياسات فحص سياق الطلب، مثل نطاق صفحة إتمام الشراء الذي يذكره الطلب، لكن Turnkey لا تتحقق بصورة مستقلة من صحة هذا الادعاء. فالإقرار الموقّع يثبت هوية من قدّمه، لا صحته. ولا تزال التطبيقات بحاجة إلى عمليات تحقق موثوقة تربط ذلك الإقرار بالعملية الفعلية.

موافقات تتطور مع سير العمل

يمكن للفرق إتاحة الاسترداد المباشر، أو اشتراط موافقة شخص على الطلب، أو اشتراط توافق عدة أدوار للوكلاء. ويمكن تغيير السياسات دون إعادة استيراد السر الأساسي، ما يسمح ببدء سير العمل تحت إشراف وثيق ثم أتمتة طلبات مختارة لاحقًا.

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

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

من البنية التحتية للمحافظ إلى الأتمتة المالية

تستخدم بنية Turnkey الأمنية الحالية AWS Nitro Enclaves، وتجمع بين العزل على مستوى الأجهزة وعمليات البناء القابلة لإعادة الإنتاج والتصديق عن بُعد. تتيح قابلية إعادة الإنتاج مقارنة عمليات بناء البرمجيات، بينما يقدم التصديق دليلًا على الشيفرة التي يجري تشغيلها داخل البيئة المعزولة. وتوسّع Managed Secrets هذه الأسس لتشمل بيانات الاعتماد، لا مفاتيح توقيع معاملات البلوك تشين فحسب.

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

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