أمن الشبكة في BYOC

انشر ClickHouse على بنيتك التحتية السحابية الخاصة

​

الاتصالات بين طبقة التحكم في ClickHouse وVPC الخاصة بـ BYOC لديك

تحافظ طبقة التحكم في ClickHouse Cloud على عدة أنواع من الاتصالات لتشغيل نشر BYOC الخاص بك ودعمه:

الغرض	نوع الاتصال	ملاحظات
العمليات اليومية — خادم Kubernetes API	عام مع تصفية عناوين IP (افتراضيًا) أو Tailscale	تتواصل خدمات الإدارة مع خادم EKS API عبر الشبكة العامة، مع تقييد الوصول باستخدام قوائم السماح لعناوين IP. بعد النشر الأولي، يمكنك اختياريًا التبديل إلى Tailscale للوصول الخاص.
العمليات اليومية — واجهات AWS API	ClickHouse VPC → AWS	تستدعي خدمات الإدارة واجهات AWS API (مثل EKS وEC2) من VPC الخاصة بـ ClickHouse Cloud إلى AWS. ولا يشمل ذلك VPC الخاصة بك أو Tailscale.
استكشاف الأخطاء وإصلاحها — خدمة ClickHouse	Tailscale	يصل مهندسو ClickHouse إلى خدمة ClickHouse (مثل جداول النظام) لأغراض التشخيص عبر Tailscale.
استكشاف الأخطاء وإصلاحها — خادم Kubernetes API	Tailscale	يصل مهندسو ClickHouse إلى خادم EKS API لتشخيصات المجموعة عبر Tailscale.

يوضح القسم التالي كيفية استخدام الشبكة الخاصة Tailscale في استكشاف الأخطاء وإصلاحها وللوصول الإداري الاختياري.

​

شبكة Tailscale الخاصة

يوفّر Tailscale اتصالًا عبر شبكة خاصة قائمًا على مبدأ انعدام الثقة بين خدمات الإدارة في ClickHouse Cloud ونشر BYOC لديك. وتتيح هذه القناة الآمنة لمهندسي ClickHouse تنفيذ مهام استكشاف الأخطاء وإصلاحها وعمليات الإدارة من دون الحاجة إلى الوصول عبر الإنترنت العام أو إعدادات VPN معقّدة.

​

نظرة عامة

ينشئ Tailscale نفق شبكة خاصًا ومشفّرًا بين طبقة التحكم في ClickHouse (ضمن VPC الخاصة بـ ClickHouse) وdata plane الخاص بـ BYOC لديك (ضمن VPC الخاصة بك). ويُستخدم هذا الاتصال حصريًا من أجل:

• عمليات الإدارة: خدمات الإدارة في ClickHouse التي تنسّق مع البنية التحتية لـ BYOC لديك
• وصول استكشاف الأخطاء وإصلاحها: وصول مهندسي ClickHouse إلى خوادم Kubernetes API وجداول النظام في ClickHouse لأغراض التشخيص
• الوصول إلى المقاييس: تتيح لوحات المراقبة المركزية في ClickHouse الوصول إلى المقاييس من Prometheus Stack المنشور داخل VPC الخاصة بـ BYOC لديك، مما يوفّر لمهندسي ClickHouse إمكانية الرصد داخل البيئة.

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

​

كيف يعمل Tailscale في BYOC

لكل خدمة أو نقطة نهاية يلزم الوصول إليها عبر Tailscale، ينشر ClickHouse BYOC ما يلي:

1. تسجيل عنوان Tailnet: تسجّل كل نقطة نهاية عنوان tailnet فريدًا (مثل k8s.xxxx.us-east-1.aws.byoc.clickhouse-prd.com لخادم Kubernetes API)

2. حاوية وكيل Tailscale: تعمل حاوية وكيل Tailscale في مجموعة EKS لديك، وتكون مسؤولة عن:

   • الاتصال بخادم التنسيق في Tailscale
   • تسجيل الخدمات لتصبح قابلة للاكتشاف
   • تنسيق إعداد الشبكة مع كبسولات Nginx

3. كبسولة Nginx: كبسولة Nginx تقوم بما يلي:

   • إنهاء حركة مرور TLS الواردة من Tailscale
   • توجيه حركة المرور إلى عناوين IP المناسبة داخل مجموعة EKS لديك

​

عملية الاتصال بالشبكة

تتم عملية إنشاء اتصال Tailscale عبر الخطوات التالية:

1. الاتصال الأولي:

   • يتصل وكلاء Tailscale على كلا الطرفين (بيئة مهندس ClickHouse وعنقود BYOC EKS لديك) بخادم التنسيق في Tailscale
   • يسجّل وكيل عنقود EKS خدمة Kubernetes لتصبح قابلة للاكتشاف
   • يجب على مهندسي ClickHouse التصعيد داخليًا ليتمكنوا من رؤية الخدمة

2. نمط الاتصال:

   • النمط المباشر: تحاول الوكلاء إنشاء اتصال مباشر عبر نفق لاجتياز NAT
   • نمط الترحيل: إذا فشل النمط المباشر، يعود الاتصال إلى نمط الترحيل عبر خادم Tailscale DERP ‏(بروتوكول الترحيل الموزّع المشفّر)

3. التشفير:

   • جميع الاتصالات مشفّرة من طرف إلى طرف
   • يُنشئ كل وكيل Tailscale زوج مفاتيح عام/خاص خاصًا به (على غرار PKI)
   • تظل حركة البيانات مشفّرة بغض النظر عما إذا كانت تستخدم النمط المباشر أو نمط الترحيل

​

ميزات الأمان

اتصالات صادرة فقط:

• تُنشئ وكلاء Tailscale في عنقود EKS لديك اتصالات صادرة إلى خوادم التنسيق/الترحيل الخاصة بـ Tailscale
• لا حاجة إلى أي اتصالات واردة — لا يلزم أن تسمح أي قواعد في Security Group بحركة مرور واردة إلى وكلاء Tailscale
• يقلّل ذلك من سطح الهجوم ويبسّط تهيئة أمان الشبكة

التحكم في الوصول:

• يجب على المهندسين طلب الوصول عبر سير عمل موافقة داخلي قبل أن يتمكن Tailscale من توجيههم إلى نقطة نهاية العميل
• يكون الوصول محدد المدة وتنتهي صلاحيته تلقائيًا
• تخضع جميع عمليات الوصول للتدقيق والتسجيل

للاطلاع على سياسة الوصول إلى البيانات كاملةً — وما الذي يمكن للمهندسين الاطلاع عليه، والمصادقة المستندة إلى الشهادات، والتدقيق من جهة العميل — راجع ClickHouse data access.

​

وصول خدمات الإدارة

بشكل افتراضي، تصل خدمات إدارة ClickHouse إلى عنقود Kubernetes الخاص بـ BYOC عبر عنوان IP العام لخادم واجهة برمجة تطبيقات EKS، ويكون هذا الوصول مقيّدًا بعناوين IP الخاصة بـ NAT gateway التابعة لـ ClickHouse فقط.

التكوين الاختياري لـ Private Endpoint:

• يمكنك تهيئة خادم واجهة برمجة تطبيقات EKS لاستخدام نقطة نهاية خاصة فقط
• في هذه الحالة، تصل خدمات الإدارة إلى خادم واجهة برمجة التطبيقات عبر Tailscale (بشكل مشابه لوصول المهندسين عند استكشاف الأخطاء وإصلاحها)
• يُحتفَظ بالوصول العام كآلية احتياطية لاحتياجات التحقيق الطارئة والدعم

​

تدفّق حركة مرور الشبكة

تدفّق اتصال Tailscale:

1. وكيل Tailscale في مجموعة EKS → خادم التنسيق في Tailscale (صادر)
2. وكيل Tailscale على جهاز المهندس → خادم التنسيق في Tailscale (صادر)
3. يُنشأ اتصال مباشر أو مُرحَّل بين الوكيلين
4. تتدفّق حركة المرور المشفّرة عبر النفق المُنشأ
5. ينهي كبسولة Nginx في EKS اتصال TLS ويوجّه الحركة إلى الخدمات الداخلية

عدم نقل بيانات العملاء:

• تُستخدم اتصالات Tailscale فقط للإدارة واستكشاف الأخطاء وإصلاحها
• لا تمرّ حركة مرور الاستعلامات وبيانات العملاء مطلقًا عبر Tailscale
• تظل جميع بيانات العملاء داخل VPC الخاصة بك

لمزيد من التفاصيل التقنية حول كيفية تنفيذ Tailscale في BYOC، راجع مقالة المدوّنة Building ClickHouse BYOC on AWS. ولمعرفة ما يمكن لمهندسي ClickHouse الاطلاع عليه بعد الاتصال وكيف يدقّق ClickHouse هذا الوصول، راجع ClickHouse data access.

​

حدود الشبكة

يغطي هذا القسم أنواعًا مختلفة من حركة مرور الشبكة من وإلى الـ VPC الخاصة بالعميل في BYOC:

• الوارد: حركة المرور التي تدخل إلى الـ VPC الخاصة بالعميل في BYOC.
• الصادر: حركة المرور التي تنطلق من الـ VPC الخاصة بالعميل في BYOC وتُرسَل إلى وجهة خارجية.
• عام: نقطة نهاية شبكية يمكن الوصول إليها عبر الإنترنت العام.
• خاص: نقطة نهاية شبكية لا يمكن الوصول إليها إلا عبر اتصالات خاصة، مثل VPC peering أو VPC Private Link أو Tailscale.

يتم نشر Ingress الخاص بـ Istio خلف AWS NLB لاستقبال حركة مرور عميل ClickHouse.

وارد، عام أو خاص

تتولى بوابة Ingress الخاصة بـ Istio إنهاء TLS. وتُخزَّن الشهادة، التي يوفّرها CertManager باستخدام Let’s Encrypt، كـ secret داخل عنقود EKS. وتكون حركة المرور بين Istio وClickHouse مشفّرة بواسطة AWS لأنهما موجودان داخل الـ VPC نفسها.

بشكل افتراضي، يكون Ingress متاحًا بشكل عام مع التصفية عبر IP allow list. ويمكن للعملاء تهيئة VPC peering لجعله خاصًا وتعطيل الاتصالات العامة. ونوصي بشدة بإعداد عامل تصفية IP لتقييد الوصول.

​

وصول استكشاف الأخطاء وإصلاحها

وارد، خاص

يحتاج مهندسو ClickHouse Cloud إلى وصول لأغراض استكشاف الأخطاء وإصلاحها عبر Tailscale. ويُمنحون مصادقة مستندة إلى الشهادات عند الحاجة لعمليات نشر BYOC. راجع ClickHouse data access للاطلاع على سياسة الوصول الكاملة.

​

مجمِّع بيانات الفوترة

الصادر، خاص

يجمع مجمِّع بيانات الفوترة بيانات الفوترة من ClickHouse ويرسلها إلى حاوية تخزين S3 مملوكة لـ ClickHouse Cloud.

يعمل كحاوية جانبية إلى جانب حاوية خادم ClickHouse، ويجمع دوريًا مقاييس CPU والذاكرة. وتُوجَّه الطلبات داخل نفس المنطقة عبر نقاط نهاية خدمة بوابة VPC.

​

التنبيهات

الصادر، العام

تم إعداد AlertManager لإرسال التنبيهات إلى ClickHouse Cloud عندما يكون عنقود ClickHouse الخاص بالعميل في حالة غير سليمة.

تُخزَّن المقاييس والسجلات ضمن شبكة BYOC VPC الخاصة بالعميل. وتُخزَّن السجلات حاليًا محليًا على EBS. وفي تحديث مستقبلي، ستُخزَّن في LogHouse، وهي خدمة ClickHouse ضمن شبكة BYOC VPC. أما المقاييس فتستخدم مكدس Prometheus وThanos، وتُخزَّن محليًا ضمن شبكة BYOC VPC.

​

حالة الخدمة

الصادر، Public

يرسل مُصدِّر الحالة معلومات حالة خدمة ClickHouse إلى SQS تابعة لـ ClickHouse Cloud.