عندما تم إطلاق AWS لأول مرة قبل عقدين من الزمن، كانت الطريقة الوحيدة لمصادقة التطبيقات هي من خلال مفاتيح الوصول طويلة الأمد. على مر السنين، أنشأت AWS خيارات متنوعة لبيانات الاعتماد قصيرة المدى والتي تمثل تحسينًا كبيرًا للأمان لأنها تقلل من احتمالية العثور عليها من قبل مهاجم خلال فترة حياتها. قامت AWS مؤخرًا بتلخيص العديد من هذه الخيارات في ملف مشاركة مدونة ولقد ناقشت هذه الأشكال المختلفة من المصادقة بنفسي بريد. لذلك كان من المفاجئ أن نرى أن AWS قد أنشأت شكلاً جديدًا من المفاتيح طويلة المدى: مفاتيح واجهة برمجة التطبيقات Bedrock. ستنظر هذه المدونة بشكل أكثر تعمقًا في هذا النوع الجديد من مفاتيح واجهة برمجة التطبيقات طويلة المدى بالإضافة إلى نوع جديد من مفاتيح واجهة برمجة التطبيقات قصيرة المدى التي تم إنشاؤها لـ Bedrock.
في وحدة تحكم الويب AWS، يبدو الاختيار بين مفاتيح Bedrock API قصيرة وطويلة المدى متشابهًا جدًا، ولكنها تستخدم آليات مختلفة جدًا خلف الكواليس.
يؤدي إنشاء مفتاح Bedrock API طويل المدى إلى إنشاء مستخدم IAM جديد عند القيام بذلك من خلال وحدة تحكم الويب. يمكنك أيضًا إنشاء أحد هذه المفاتيح يدويًا عن طريق ربطه بمستخدم IAM موجود. على الرغم من أن الاستخدام المستمر لمستخدمي IAM لهذه الميزة في البداية لا يبدو مثاليًا، فهذا يعني أن AWS ربطت ميزة خطيرة جديدة بميزة خطرة قديمة. ونتيجة لذلك، بالنسبة للشركات التي قامت بالفعل بحظر مستخدمي IAM عبر SCP، فقد قامت بالفعل بحظر هذه الميزة الجديدة. تم عرض SCP لمنع إنشاء مستخدمي IAM في إحدى منشورات مدونتنا السابقة: تعيين الإعدادات الافتراضية الآمنة على AWS وتجنب التكوينات الخاطئة.
سيتم إنشاء مستخدم IAM الجديد باسم مثل “BedrockAPIKey-abcd” حيث تكون الأحرف الأربعة الأخيرة عشوائية. ثم يكون لدى هذا المستخدم سياسة IAM أمازون بيدروك ليميتيد أكسس تضاف إليه تلقائيا. على الرغم من تسمية هذه السياسة بكلمة “محدودة”، إلا أنها لا تزال تتمتع بأكثر من نصف امتيازات خدمة Bedrock، بما في ذلك القدرة على إنشاء حواجز الحماية وحذفها. بالنسبة لمعظم حالات الاستخدام، يجب استخدام بيانات الاعتماد هذه فقط لاستدعاء النماذج وربما بعض امتيازات العرض فقط، لذلك ستكون هذه المفاتيح ذات امتيازات زائدة لمعظم حالات الاستخدام عند إنشائها من خلال وحدة تحكم الويب.
بدلاً من استخدام مفتاح وصول مستخدم IAM، يتم إنشاء مفاتيح Bedrock API باستخدام IAM API إنشاءServiceSpecificCredential، وهي واجهة برمجة تطبيقات قديمة من عام 2016 كانت تستخدم سابقًا فقط لـ CodeCommit وAmazon Keyspaces (لـ Apache Cassandra). تمت إضافة وظيفة جديدة إلى واجهة برمجة التطبيقات (API) لهذه المفاتيح الجديدة بحيث يمكن تحديد وقت انتهاء الصلاحية عليها، أو عدم انتهاء صلاحيتها أبدًا. يعجبني أن AWS قدمت طريقة للحصول على وقت انتهاء الصلاحية، ولكن لا توجد طريقة لفرض وقت انتهاء الصلاحية على هذه الاستخدامات شروط سياسة إدارة الهوية وإمكانية الوصول (IAM).. تحرير 2025.09.04: توفر AWS الآن الشروط iam:ServiceSpecificCredentialAgeDays وiam:ServiceSpecificCredentialServiceName.
تبدو مفاتيح واجهة برمجة التطبيقات الجديدة هذه كما يلي: ABSKQmVkcm9ja0FQSUtleS… وهي مكونة من 132 حرفًا، مع البادئة ABSK، ثم سلسلة مشفرة باستخدام base64. عند فك التشفير، ستبدو هذه السلسلة بالشكل “BedrockAPIKey-abcd+1-at-123456789012:FS0k7F…” لذا فإن المثال المذكور سابقًا “ABSKQmVkcm9ja0FQSUtleS“فك التشفير إلى”BedrockAPIKey” البادئة وبالتالي يمكن استخدامها للمسح السري للعثور عليها مع الحد الأدنى من النتائج الإيجابية الخاطئة. بالطبع تنطبق التحذيرات المعتادة على أن هذا غير موثق بواسطة AWS وبالتالي عرضة للتغيير. بالإضافة إلى ذلك، كما ذكرنا، يمكن ربط مفاتيح Bedrock API هذه بمستخدمي IAM الحاليين الذين لديهم أسماء مستخدمين مختلفة، لذا لاكتشاف هذه الأسماء على نطاق واسع، يجب عليك للأسف استخدام فقط “ABSK” بادئة.
تحتوي السلسلة التي تم فك تشفيرها على اسم مستخدم IAM المرتبط، سواء كان هذا هو مفتاح واجهة برمجة التطبيقات الأساسي أو الثانوي، ومعرف الحساب. يمكن أن يكون لديك مفتاحي Bedrock API لكل مستخدم IAM، على غرار مفاتيح الوصول، وسيتم الإشارة إلى المفتاح الثاني بـ “+1” في فك التشفير هذا. بعد النقطتين، توجد سلسلة أخرى مشفرة باستخدام Base64، ولكنها تُفك تشفير 44 بايت من البيانات الثنائية العشوائية على ما يبدو.
لاستخدام مفاتيح واجهة برمجة التطبيقات هذه، ما عليك سوى إضافة رأس HTTP الذي يحتوي عليها، كما هو موضح في طلب تجعيد سطر واحد في مستندات AWS هنا. وهذا يختلف عن معظم عمليات المصادقة إلى AWS التي تستخدم خوارزمية تسمى sigv4 يتضمن التجزئة ونتيجة لذلك لا يتم إرسال المفتاح السري أبدًا. باستخدام مفتاح Bedrock API هذا، يتم نسخه مباشرة إلى طلب HTTPS. يتم تقديم الطلب عبر TLS، ولكن من المفاجئ أن تستخدم AWS رمزًا مميزًا لحامل بدلاً من آلية التجزئة المعتادة الخاصة بها.
تظهر مفاتيح واجهة برمجة التطبيقات (API) طويلة المدى هذه بالفعل في مستودعات GitHub العامة. لاحظنا لأول مرة تسرب المفاتيح هناك في غضون أسبوعين من الإطلاق.
أوصينا AWS بدمج هذه المفاتيح في Github Secret Scanning برنامج الشريك وهو ما تستخدمه AWS لتحديد مفاتيح وصول مستخدم IAM التي يتم نشرها في مستودعات GitHub العامة. اعتبارًا من الأول من أغسطس، تم تحديد هذه المفاتيح الآن كجزء من ذلك، بحيث أنه عندما يتم الالتزام بمفتاح Bedrock API طويل المدى بمستودع GitHub العام، ستطبق AWS سياسة العزل الخاصة بها على مستخدم IAM، وتخطر العميل عبر حالة الدعم، بالإضافة إلى بريد إلكتروني إلى حساب البريد الإلكتروني الجذر. تشارك هذه الاتصالات معلومات حول بيانات الاعتماد المكشوفة، بما في ذلك الريبو والالتزام والملف، بالإضافة إلى اسم مستخدم IAM.
قام Wiz أيضًا بدمج اكتشاف هذه المفاتيح في الماسح الضوئي السري الخاص بنا.
يتم استخدام مفاتيح Bedrock API قصيرة المدى بنفس طريقة استخدام المفاتيح طويلة المدى (مثل الرموز المميزة لحاملها في طلبات HTTPS)، ولكن يتم إنشاؤها من خلال آلية منفصلة تمامًا. يبلغ طول هذه المفاتيح قصيرة المدى أكثر من 1000 حرف وتبدو وكأنها “bedrock-api-key-YmVkcm9jay…“
بينما يتم إنشاء بيانات الاعتماد طويلة المدى عبر استدعاء واجهة برمجة التطبيقات (API). iam:CreateServiceSpecificCredential، لا تحتوي بيانات الاعتماد قصيرة المدى على استدعاء API لإنشائها. بدلاً من ذلك، أصدرت AWS ملفًا مكتبة جديدة لإنشائها. أنت تستطيع انظر في الكود كل ما يفعله هذا هو إنشاء عنوان URL موقّع مسبقًا، وترميزه بواسطة Base64، ووضع بادئة له بهذه السلسلة “bedrock-api-key-“. نظرًا لأن هذا يؤدي إلى إنشاء عنوان URL موقّع مسبقًا، لا يوجد حدث CloudTrail لإنشاء هذه المفاتيح قصيرة المدى لأن كل ذلك يحدث من جانب العميل. لذلك، لن يتم تسجيلها في CloudTrail إلا عند استخدامها. واجهة برمجة التطبيقات التي يتم توقيعها هي واجهة برمجة تطبيقات جديدة غير موثقة bedrock:CallWithBearerToken.
يمكن اكتشاف إنشاء مفاتيح Bedrock طويلة المدى من خلال البحث عن الأحداث منها iam:CreateServiceSpecificCredential مع requestParameters.service=="bedrock.amazonaws.com". لا يتم تسجيل إنشاء مفاتيح Bedrock قصيرة المدى في CloudTrail لأنه يتم من جانب العميل من خلال إنشاء عنوان URL موقّع مسبقًا.
يمكن تحديد استخدام مفاتيح Bedrock طويلة المدى أو قصيرة المدى من خلال تضمينها "additionalEventData": { "callWithBearerToken": true } في هذا الحدث. يعتمد تحديد ما إذا كان ذلك بسبب مفتاح أساسي طويل أو قصير المدى على نوع المبدأ: يستخدم مستخدمو IAM مفاتيح طويلة المدى، وتستخدم أدوار IAM مفاتيح قصيرة المدى.
أنشأت AWS هذا ميزة جديدة “لتبسيط تجربة البدء وتسريع تطوير الذكاء الاصطناعي التوليدي”. إنه يقلل من بعض التعقيدات في آليات المصادقة الأخرى، ولكنه بخلاف ذلك كان بمثابة إضافة غير متوقعة، نظرًا لأن بيانات الاعتماد طويلة الأمد تمثل مصدرًا دائمًا للحوادث الأمنية لعملاء AWS. يعتمد كل من أنواع بيانات الاعتماد الجديدة هذه على بعض إمكانيات AWS الموجودة مسبقًا، لذلك يتم بناؤها في بعض النواحي على أساس أمني موجود ومختبر جيدًا، ولكنها أضافت أيضًا مفهوم الرمز المميز الأبسط لحامله إلى AWS. لا يمكن استخدام مفاتيح واجهة برمجة التطبيقات الجديدة هذه إلا مع Bedrock، لذا فهي محدودة في كيفية إساءة استخدامها، ولكن Bedrock هي إحدى الخدمات التي تقدمها AWS سياسة الحجر الصحي يحاول التقييد بسبب إساءة استخدام تلك الخدمة في الماضي من قبل المهاجمين.
بعد أخذ كل الأمور بعين الاعتبار، ما زلنا نوصي بتنفيذ SCP لمنع مستخدمي IAM (وبالتالي مفاتيح Bedrock API طويلة المدى)، بالإضافة إلى رفض الامتياز bedrock:CallWithBearerToken (كما هو موضح هنا) مما سيمنع استخدام مفاتيح Bedrock طويلة أو قصيرة المدى. لا يزال من الممكن تحقيق استخدام Bedrock من خلال آليات المصادقة الأخرى الموجودة مسبقًا.
بيان من AWS
—
يمكن أن تؤكد AWS أن عملية فحص الأسرار قد تم تحديثها بالفعل لتشمل مفاتيح Amazon Bedrock API، ولا يلزم اتخاذ أي إجراء من جانب العملاء. حدثت المشكلة المحددة في منشور المدونة قبل توسيع عملية المسح لدينا. قامت AWS أيضًا بالتحقيق في مفاتيح Bedrock API التي تم تخصيصها مسبقًا لـ GitHub وعزلتها حيثما وجدت.
إذا اكتشفنا أنه ربما تم الوصول إلى أحد الحسابات بشكل غير مناسب، فسوف تقوم AWS بإخطار العميل والعمل معه لتأمين حسابه. يمكنك العثور على معلومات حول التعامل مع مفاتيح Amazon Bedrock المخترقة في دليل Amazon Bedrock API وبدائل مفاتيح الوصول طويلة المدى في دليل مستخدم IAM.
نشكر WIZ على إشراك AWS Security ونتطلع إلى التعاون في التقارير المستقبلية.
—
