رفائيل أنجيل، المؤسس المشارك والمدير التقني لشركة Akeyless – سلسلة المقابلات

رفائيل أنجيل، المؤسس المشارك والمدير التقني لشركة Akeyless، هو قائد في مجال الأمن السيبراني وهندسة البرمجيات مع خبرة عميقة في أمن السحابة والتشفير والتحقق من هوية الآلة والبنية التحتية للشركات. منذ تأسيسه لشركة Akeyless في عام 2018، ساعد في بناء الشركة حول إدارة الأسرار الحديثة وأمان الهوية للبيئات الأصلية السحابية. قبل شركة Akeyless، عمل كمهندس برمجيات كبير في الأمن في شركة Intuit (INTU ) ، حيث بنى أنظمة لإدارة مفتاح التشفير العام والتحقق من هوية الآلة، واكتسب خبرة عملية عبر منصات AWS و Go و Python و Java و PHP و Bash و Linux و Git و Jenkins. في وقت سابق من مسيرته المهنية، شغل أنجيل مناصب هندسة برمجيات في شركة 3D Systems (DDD ) و Cimatron، حيث طور تطبيقات CAD/CAM و Windows باستخدام لغات C/C++ و C# و WPF و MFC و أنماط تصميم الكائنات.

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

أنت المؤسس المشارك لشركة Akeyless في عام 2018 بعد بناء أنظمة إدارة مفتاح التشفير والتحقق من هوية الآلة في شركة Intuit. ما هو الفجوة في أمن السحابة وإدارة الهوية التي أقنعتك بأنها وقت لبدء شركة Akeyless، وكيف تطور الرؤية الأصلية مع ظهور وكلاء الذكاء الاصطناعي كفئة جديدة من الهويات الرقمية؟

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

الضبط كان الثقة. هذا هو أكثر المواد الحساسة التي تملكها الشركة، ولا توجد منظمة جادة ستمنح طرفًا ثالثًا khảية الوصول إليها. لذلك كان المتطلب متعارض تقريبًا: تقديمها كخدمة سحابية من أجل التوسع والبساطة، ومع ذلك جعلها من الناحية المعمارية من المستحيل للبائع رؤية بيانات العميل أبدًا. هذا التوتر هو ما أدى إلى ولادة التشفير الموزع على شظايا (DFC). DFC يسمح لنا بتشغيل طائرة تحكم سحابية完全ة بينما يحتفظ العميل بشظية لا نملكها أبدًا، لذلك نحن عاجزون رياضيًا عن الوصول إلى مفاتيحهم. هذا أصبح الأساس لنظام السحابة بالإضافة إلى نموذج بدون معرفة الذي بنيت عليه شركة Akeyless.

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

يُعتبر أنك مهندس معماري وراء تقنية التشفير بدون ثقة المملوكة لشركة Akeyless. ما هي أكبر التحديات الفنية في بناء نموذج أمان يمكن أن يلغي افتراضات الثقة بينما يبقى عمليًا للشركات الكبيرة؟

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

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

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

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

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

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

جادلت شركة Akeyless بأن وكلاء الذكاء الاصطناعي يتطلبون نموذج هوية أساسيًا مختلفًا عن البشر أو التحميلات التقليدية للماكينة. ما الذي يجعل وكلاء الذكاء الاصطناعي صعبًا بشكل فريد لتأمينهم مقارنةً بطرق IAM و PAM الحالية؟

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

هويات الوكيل لا يمكن تعدادها. الحالة المحددة التي تريد حكمها عادةً لا توجد بعد، وعندما توجد، تكون قد انتهت بالفعل. يمكن لوكيل أن يظهر على Lambda ويعمل لمدة 800 ملي ثانية ويتلاشى قبل أن يلاحظه أي مسح، أو يؤسس سلاسل من وكلاء فرعية عبر VMs و-containers وserverless يكتمل في ثوان. تسجيل هذه في دليل هو معاملة الأشباح كمواطنين: بالوقت الذي يلتزم به الدخول، الكيان الذي وصفته قد انتهى.

المؤشر الصحيح هو هوية الوكالة التي يصدرها وقت التشغيل بالفعل، دور التنفيذ في AWS، رمز توكن حساب الخدمة في Kubernetes، OIDC federation، ومعايير مثل SPIFFE/SPIRE التي أثبتت بالفعل أنها قادرة على الإنتاج. هذه الهوية موجودة بالفعل، ويشهد لها المنصة التي يعمل عليها الوكيل، وتختفي عندما يختفي الوكيل. بسبب انتهاء صلاحية الهويات، الكيانات الثابتة الوحيدة للكتابة بين السياسات هي أساليب التحقق والأنظمة المستهدفة، وليس الهويات المسمى والنطاقات.

وهنا تكمن النقطة التي تفشل فيها طرق IAM و PAM الحالية بشكل حاسم: RBAC و ABAC الثابت لا يمكن أن يحتوي على ممثل غير محدد. يمكن لوكيل مع رمز مقترن ومحدد بشكل مثالي وتنفيذ TTL مثالي أن يتم حقنه بالprompt، أو يخطر استفسار تدميري، أو يتحرك من مهمة قراءة إلى مهمة كتابة في نفس الجلسة، دون أي انتهاك واضح للسياسة في层 التحقق. RBAC و ABAC تقييم في التحقق، وليس بعد ذلك، لأن ما يحدث بعد ذلك يُحدد بواسطة LLM ينظر إلى نافذة سياق لا يستطيع مؤلف السياسة رؤيتها.

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

هناك مناقشة متزايدة حول “هياكل بدون أسرار” لأنظمة الذكاء الاصطناعي. كيف تعرف التوثيق بدون أسرار، ولماذا تعتقد أن الاعتمادات الثابتة ومفاتيح API أصبحت غير مستدامة في عصر الوكلاء المستقلين؟

التوثيق بدون أسرار يعني أن الوكيل لا يحمل أبدًا اعتمادًا. بدلاً من منح الوكيل مفتاح يجب عليه تخزينه وتقديمه، يُوثق الوكيل من خلال هويته الأصلية للوظيفة، ويُحقن اعتماد قصير الأمد وjust-in-time في جلسة وسيطة في لحظة التنفيذ، ثم يُدمر عند انتهاء الجلسة. الوكيل لا يراه.

الاعتمادات الثابتة ومفاتيح API أصبحت غير مستدامة لسبب بسيط: سر الوكيل الذي يحتفظ به هو سر يمكن للمهاجم سرقته. في عالم حيث الممثل الذي يحمل الاعتماد يمكن حقنه بالprompt أو يخطر، يصبح المفتاح الطويل الأمد كتلة يمكن حصادها داخل ممثل غير محدد. إزالة الاعتماد من الوكيل وسيط الوكيل لا يملك شيئًا ليكشفه. هذا هو كل نقطة ما نسميه SecretlessAI.

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

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

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

نحن نشهد تحولًا من تأمين الهويات البشرية إلى تأمين الهويات الآلية والوكالة. كيف ترى تغيير توازن الأولويات الأمنية مع بدء الشركات في إدارة ملايين الهويات غير البشرية عبر بنيتها التحتية؟

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

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

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

قبل أن يعمل أي وكيل بشكل مستقل في الإنتاج، سأريد بعض الأشياء. أولاً، لا صلاحيات قائمة على الوكيل، مع وصول قصير الأمد وjust-in-time يتم حقنه في كل جلسة. ثانيًا، لا مسار شبكة مباشر، بحيث كل إجراء الوكيل يتم توجيهه من خلال نقطة خنق إلزامية بدلاً من الوصول مباشرة إلى قواعد البيانات وواجهات برمجة التطبيقات. ثالثًا، حوكمة سياسة متألمة التي تقيم الغرض من الطلب مقابل ما أُنشئ له، قبل أن يتم صك أي اعتماد. رابعًا، فحص الجلسة واستجابة التماسك بحيث يتم حذف البيانات الحساسة مثل PII و PHI قبل دخولها إلى نافذة سياق الوكيل. وخامسًا، سجل مراجعة واحد لا يتغير يربط بين Prompt البشري والنية المصنفة ونتيجة السياسة والجلسة والإجراء النهائي.

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

ت tập trung على سلامة النموذج، ولكن أقل اهتمام يُمنح لأمان الهوية والتحقق والتحكم في الوصول. لماذا تعتقد أن هذه المجالات ستصبح بعض التحديات الأمنية الأكثر أهمية في عصر الذكاء الاصطناعي؟

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

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

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

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

طبقة هوية الوكيل التي أتوقعها سترسخ الهوية إلى وظيفة وقت التشغيل التي يصدرها،.cloud IAM، tokens حساب الخدمة في Kubernetes، OIDC federation، ومعايير مثل SPIFFE/SPIRE التي أثبتت بالفعل أنها قادرة على الإنتاج. التحقق سيكون معبرًا عن العلاقات بين أساليب التحقق والأنظمة المستهدفة، وليس بين الهويات المسمى والنطاقات. وسيكون مركز الجاذبية هو طائرة حوكمة وقت التشغيل، بوابة توجيه كل إجراء، تصنيف النية، حقن اعتمادات زمنية، ومasking استجابات حساسة، وإنتاج سلسلة مراجعة كاملة. الهوية لا تزال مهمة، لكنها تقع في مكانها خلف الحوكمة chứ không في أمامها. هذه هي الطبقة الحكومية في وقت التشغيل، التي تقع على نفس المنصة التي تحكم بالفعل الوصول البشري والآلي، والتي أعتقد أن كل شركة تعمل بالوكلاء في الإنتاج ستحتاج إليها.

شكرًا على المقابلة الرائعة، القراء الذين يرغبون في معرفة المزيد يجب أن يزوروا Akeyless.