حافة Google، شرح كامل
هذا الشهر انتقل الباب الرئيسي للأسطول. كل طلب إلى كل تطبيق نستضيفه يدخل الآن عبر حافة عالمية واحدة — حافة Google — قبل أن يلمس خادم التطبيق. تدوينتان سابقتان ذكرتا أجزاءً من هذا (أساس WAF لدينا، واختيار المناطق)؛ وهذه هي الصورة الكاملة لما يعبره الطلب في طريقه إلى الداخل.
باب واحد للأسطول كله
كل نطاق نخدمه يشير إلى عناوين مخصصة على موزّع الحمل العالمي لدى Google: يتصل الزائر بأقرب نقطة حضور لـGoogle ثم يسافر عبر شبكة Google نفسها. الشهادات تصدرها Google وتجدّدها، وأمن النقل الصارم (HSTS) مفعّل، والحافة كلها إعدادات مصرَّح بها — مُراجَعة ومُدارة بالإصدارات وقابلة لإعادة البناء، مثل كل شيء آخر على المنصة.
أرخص هجوم يمكن النجاة منه هو الهجوم الذي لا يصلك أبدًا.
يُفحص قبل أن يصل
أمام كل تطبيق يقف الدرع نفسه. حظر بمعدل الطلبات يحمي كل تسجيل دخول — خمس محاولات في دقيقة تكلف العنوان عشر دقائق من الإيقاف — وحارس الاستعلامات يُسقط الطلبات التي تحمل أنماط حقن واضحة قبل أن تبلغ التطبيق. مجموعات قواعد OWASP المُعدة مسبقًا من Google تقيّم كل طلب بالتوازي، أما «ويبهوك» المدفوعات فمستثناة عمدًا من مطابقة الأنماط: إذ تتحقق بتوقيع المزوِّد — لأن قاعدة لا تفرّق بين دفعة حقيقية وهجوم هي قاعدة تكسر إيراداتك.
أسماء موقَّعة وأبواب محروسة
العناوين نفسها صارت جزءًا من المحيط: نطاقاتنا الخمسة عشر تعيش على Google Cloud DNS وكل منطقة موقَّعة بـDNSSEC — فيستطيع المحلِّل التحقق من أنه يخاطب المنطقة الأصلية لا منتحلًا. أسطح التشغيل الخاصة بنا — لوحات الأسطول، وحتى SSH إلى الأجهزة — لا تنفتح إلا لهوية Google موثَّقة، لا لكلمة مرور على الإنترنت المفتوح أبدًا. وما يبقى مجهول الهوية هو بالضبط ما صرّحنا بأنه كذلك: نقاط الفحص الصحي و«ويبهوك» المدفوعات، مدونة في سجل الأسطول، لا غير.
