الإخفاء ليس هو نفسه التأمين

قام مسؤول تنفيذي غير مهندس مؤخرًا ببناء تطبيق SaaS للشركات (B2B) في يومين فقط. لقد استخدم الذكاء الاصطناعي لكتابة كل شيء. المنتج يعمل، والعملاء يستخدمونه، والميزات تُطلق بسرعة.

ثم توليتُ مسؤولية البنية التحتية. مهمتي هي العثور على المخاطر في الكود الذي يعمل بالفعل في بيئة الإنتاج (production).

وجدتُ ثغرة أمنية هائلة. كان مفتاح الـ API مكتوبًا بشكل ثابت (hardcoded) مباشرة في الكود المصدري.

أخبرتُ المسؤول التنفيذي أن هذا أمر خطير، فقام بإصلاحه على الفور.

اختفى المفتاح من الكود، لكنه أصبح الآن في ملف الـ README كخطوة للإعداد. انتقل السر من الكود إلى التوثيق. كان لا يزال داخل المستودع (repository)، بل أصبح من الأسهل العثور عليه الآن.

شرحتُ المشكلة مرة أخرى. هذه المرة، قاموا بنقل المفتاح إلى قاعدة البيانات.

بدا ذلك وكأنه تقدم؛ فقد خرج المفتاح من المستودع. ولكن عندما فحصتُ قاعدة البيانات، وجدتُ المفتاح هناك كنص مجرد (plaintext). لم يكن هناك أي تشفير، وأي شخص لديه صلاحية الوصول إلى قاعدة البيانات يمكنه قراءته.

انتقل المفتاح ثلاث مرات:

تغير الموقع، لكن الأمن لم يتحسن. كانوا يخفون السر، ولم يقوموا بتعميته (concealing).

الإخفاء (Hiding) يعني وضع شيء ما بعيدًا عن الأنظار. أما التعمية (Concealing) فتعني جعله عديم الفائدة للمهاجم.

في البرمجيات، يجب عليك اتباع هذه القواعد:

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

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

لا يتحول الذكاء إلى أمان إلا عندما تعرف ما الذي يجب حمايته.

إذا كنت تعتقد أنك أصلحت ثغرة أمنية لمجرد أنك نقلتها، فتوقف. واسأل نفسك:

السر ينتمي إلى المكان الصحيح، وليس مجرد مكان غير مرئي.

Source: https://dev.to/jun_uen0/playing-hide-and-seek-with-an-api-key-our-cfos-claude-code-kept-hiding-job

Optional learning community: https://t.me/GyaanSetuAi