ننقل متجرنا الإلكتروني إلى السحابة، ما هي الثغرات الأمنية السحابية الأكثر شيوعاً عملياً؟

أخطر خطأ تقني هو ترك خدمة البيانات الوصفية (Metadata Service) للخادم الافتراضي على الإصدار القديم. فلو كان لديك إضافة بها ثغرة SSRF، يستطيع المهاجم إرسال طلب لهذا العنوان المحلي وسرقة بيانات الاعتماد المؤقتة الممنوحة للخادم فوراً. اجعل استخدام الإصدار الثاني من خدمة البيانات الوصفية إلزامياً وضيّق صلاحيات الأدوار (Roles).

أثناء نقل متجر تجزئة بحجم مشابه، نسينا منفذ قاعدة بيانات بيئة الاختبار مفتوحاً لمدة يومين. وخلال 48 ساعة فقط تلقينا محاولات هجوم القوة العمياء (Brute-force) التلقائية من 14 ألف عنوان IP مختلف. إذا كانت ميزانيتك 1200 يورو، فخصص 150 يورو منها على الأقل لأدوات السجلات المركزية والتنبيهات اللحظية.

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

تأكد تماماً من إنجاز هذه الفحوصات الثلاثة قبل يوم الإطلاق: 1) تفعيل خيار 'حظر الوصول العام' على جميع مساحات التخزين. 2) وضع خوادمك في شبكة فرعية خاصة (Private Subnet) وجعل اتصالها بالعالم الخارجي مقتصراً على موازن الأحمال (Load Balancer). 3) فرض المصادقة متعددة العوامل عبر الأجهزة أو التطبيقات لجميع الموظفين بلا استثناء لتسجيل الدخول إلى لوحة الإدارة.

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

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

عند نقل بنية الدفع التحتية، هل تحتفظون ببيانات البطاقات مباشرة على خوادمكم أم تعتمدون على آلية الرموز الآمنة (Tokens) التي توفرها بوابة الدفع؟ إذا كانت بيانات البطاقات تمر عبر الخادم، فيجب أن تكون معايير الأمان والتدقيق لديكم في السحابة أكثر صرامة بكثير.

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

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

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

هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.

شكراً لكتابة هذا، فهو صحيح تماماً. محاولة فعل هذا بمفردك هي أغلى الطرق.

بالتوفيق.

يجب إجراء تمييز هنا. كل من يستعجل في أمثلة على أمان السحابة يتعثر في نفس النقطة.

أتمنى أن يفيدك هذا.

أنا أيضًا أوافق على هذا الرأي. نسخة احتياطية غير مختبرة ليست نسخة احتياطية.

فعل الجميع لشيء ما لا يعني أنه صحيح. بالتوفيق.

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

هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.

أنا مشروع صغير، دعوني أشرح من منظوري. فعل الجميع لشيء ما لا يعني أنه صحيح.

لو كنت مكانك، لسلك هذا المسار.

أنت محق.

الطريق الذي يبدو رخيصاً غالباً ما يكلف غالياً لاحقاً. القرار المتسرع يصبح قراراً يُصحح بعد ستة أشهر.

هذا كل شيء، أرجو المعذرة إذا أطالت.

تم الحفظ. القرار المتسرع يصبح قراراً يُصحح بعد ستة أشهر.

بالتوفيق.

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

هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.