١ يونيو ٢٠٢٦

لماذا تعد شبكة VPN عبئاً أمنياً: الوصول إلى الشبكة بثقة صفرية (Zero-Trust) في تطبيقات SaaS الحديثة

الوصول إلى الشبكة بثقة صفرية (Zero-Trust) في تطبيقات SaaS الحديثة: تخلصوا من شبكات VPN الخاصة بكم

نحن بحاجة إلى الحديث عن أمن المحيط (perimeter security) لديكم. إذا كنتم لا تزالون تعتمدون على شبكة افتراضية خاصة تقليدية (VPN) لتأمين الخدمات الداخلية في عام 2026، فإنكم تؤسسون لنقطة ضعف أمنية. لقد انتهى نموذج "القلعة والخندق" الكلاسيكي. بمجرد أن يخترق المهاجم الخندق، يصبح لديه حرية حركة جانبية غير مقيدة عبر كامل شبكتكم الداخلية. وهذا أمر غير مقبول في بيئات البرمجيات كخدمة (SaaS) الحديثة.

المسار الوحيد القابل للتطبيق للمضي قدماً هو الوصول إلى الشبكة بثقة صفرية (ZTNA - Zero-Trust Network Access). في نموذج الثقة الصفرية، تُعتبر الشبكة نفسها معادية. يجب التحقق من هوية كل طلب بشكل صريح، وتفويضه، والتحقق من صلاحيته بشكل مستمر، سواء كان هذا الطلب قادماً من موظف يعمل عن بُعد في مقهى أو من خدمة مصغرة (microservice) داخل عنقود Kubernetes الخاص بكم.

يستعرض هذا المقال بالتفصيل المشكلة المتعلقة بالحدود الأمنية التقليدية، والتحول المعماري المطلوب لتطبيق ZTNA، واستراتيجية تنفيذ ملموسة باستخدام وكلاء أمنيين يعتمدون على الهوية (identity-aware proxies) الحديثة.

المشكلة: أمن المحيط مجرد وهم

يعتمد أمن الشبكات التقليدي على عناوين IP والحدود الشبكية. حيث تقومون بوضع جدار حماية (firewall) على أطراف بنيتكم التحتية وبوابة VPN للوصول عن بُعد. وبمجرد أن يقوم المستخدم بمصادقة هويته عبر الـ VPN، يتم منحه عنوان IP داخلياً ويُعطى وصولاً واسعاً إلى الشبكة المحلية (LAN) للشركة.

تتضمن هذه البنية ثلاثة عيوب قاتلة:

الثقة الضمنية (Implicit Trust): يثق النظام ضمنياً بأي كيان يعمل من عنوان IP داخلي. فإذا تم اختراق جهاز المحمول الخاص بأحد المطورين، يحصل المهاجم على نفق مباشر إلى بيئة الإنتاج الخاصة بكم.
غياب الدقة والتفصيل (Lack of Granularity): تعمل شبكات VPN على الطبقة الثالثة (Layer 3) أو الرابعة (Layer 4) من نموذج OSI. وهي تمنح حق الوصول إلى قطاعات كاملة من الشبكة (subnets)، وليس إلى تطبيقات فردية. لا يمكنك بسهولة تحديد صلاحيات مثل: "يمكن لـ Alice الوصول إلى لوحة تحكم المقاييس الداخلية، ولكن ليس إلى واجهة برمجة تطبيقات الفوترة (billing API)"، دون إدارة متاهة من قوائم التحكم في الوصول للشبكة (Network ACLs) المعقدة.
تجربة مستخدم سيئة: يؤدي توجيه جميع حركات المرور (traffic) عبر بوابة VPN مركزية إلى إحداث زمن انتقال (latency) كبير واختناقات في النطاق الترددي (bandwidth).

إنكم تقومون بتأمين الشيء الخاطئ. إنكم تؤمنون الشبكة، بينما يجب عليكم تأمين التطبيق.

سبب الصعوبة: تعقيد الوصول المعتمد على الهوية

إذا كان الوصول للشبكة بثقة صفرية (Zero-Trust Network Access) متفوقاً إلى هذا الحد، فلماذا لا يقوم الجميع بتطبيقه؟ لأن الانتقال من الأمن المتمحور حول الشبكة إلى الأمن المتمحور حول الهوية أمر صعب من الناحيتين المفهومية والتشغيلية.

فهو يتطلب التخلي عن عناوين IP كوحدة للثقة واستبدالها بالهوية المشفرة والسياق الأمني.

وإليكم ما يجعل هذا الانتقال صعباً:

اتحاد الهوية (Identity Federation): يجب عليكم مركزية إدارة الهويات. يجب أن يتكامل كل تطبيق مع مزود الهوية (IdP) الخاص بكم - مثل Google Workspace، أو Okta، أو Azure AD. ويشكل تعديل الأدوات الداخلية القديمة التي لا تدعم سوى المصادقة الأساسية (Basic Auth) أو لا تدعم أي مصادقة على الإطلاق صداعاً حقيقياً.
إدارة السياسات (Policy Management): في عالم VPN، يكون الوصول ثنائياً: إما أنك متصل بالشبكة أو غير متصل. أما في عالم ZTNA، فتكون سياسات الوصول دقيقة للغاية وسياقية. يتعين عليك تحديد قواعد بناءً على دور المستخدم، وحالة الجهاز (هل هو جهاز تملكه وتديره الشركة؟ هل تشفير القرص مفعّل؟)، والوقت من اليوم، ومدى حساسية التطبيق.
الأداء وزمن الانتقال (Performance and Latency): يجب اعتراض كل طلب والتحقق من هويته وتفويضه. إذا كان الوكيل المعتمد على الهوية (identity-aware proxy) لديكم بطيئاً، فستبدو مجموعة تطبيقاتكم بالكامل ثقيلة الاستجابة.

على الرغم من هذه التحديات، فإن هذا التحول إلزامي. فاختراق المحيط الأمني مسألة وقت فقط ("متى" وليس "إذا").

البنية المعمارية: مخطط الوصول للشبكة بثقة صفرية

تستبدل بنية ZTNA القوية في بيئة SaaS بوابة الـ VPN بوكيل معتمد على الهوية (Identity-Aware Proxy - IAP). يقع هذا الوكيل مباشرة أمام تطبيقاتكم الداخلية، ويتوسط كل طلب HTTP.

المكونات الأساسية لهذه البنية هي:

مزود الهوية (Identity Provider - IdP): المصدر الموثوق لهويات المستخدمين وعضويات المجموعات (مثل Okta).
مزود ثقة الأجهزة (Device Trust Provider): نظام يقيم سلامة الأجهزة النهائية وحالتها الأمنية (مثل CrowdStrike أو Kolide).
محرك السياسات (Policy Engine): خدمة مركزية تقوم بتخزين قواعد الوصول وتقييمها.
الوكيل المعتمد على الهوية (Identity-Aware Proxy - IAP): نقطة فرض السياسات. حيث يعترض الطلبات، ويستشير محرك السياسات، ثم يقوم إما بتوجيه الطلب إلى التطبيق المستهدف (upstream) أو رفضه.

تدفق الطلبات

عندما يحاول أحد المطورين الوصول إلى خدمة داخلية (على سبيل المثال، metrics.internal.yourcompany.com)، يحدث التدفق التالي:

يقوم نظام DNS الخاص بالمستخدم بتحليل اسم المضيف (hostname) إلى عنوان IP العام للوكيل المعتمد على الهوية (IAP).
يبدأ متصفح المستخدم اتصال TLS بالوكيل.
يتحقق الوكيل من وجود ملف تعريف ارتباط جلسة (session cookie) مشفر وصالح. وفي حال عدم وجوده، يقوم بإعادة توجيه المستخدم إلى مزود الهوية (IdP) عبر بروتوكول OpenID Connect (OIDC).
يقوم المستخدم بمصادقة هويته مع مزود الهوية (IdP) (مع فرض مصادقة ثنائية مقاومة للتصيد الاحتيالي، مثل YubiKey).
يعيد مزود الهوية (IdP) توجيه المستخدم إلى الوكيل مع رمز هوية (identity token).
يمرر الوكيل هوية المستخدم وسياق جهازه وعنوان URL المطلوب إلى محرك السياسات.
يقيم محرك السياسات الطلب وفقاً للقواعد المحددة (مثل: "يسمح فقط للمهندسين الذين يستخدمون أجهزة مملوكة للشركة بالوصول إلى المقاييس").
في حال التصريح بالوصول، يقوم الوكيل بتوجيه الطلب إلى التطبيق المستهدف (upstream). وبشكل حاسم، يحقن الوكيل تأكيداً (غالباً ما يكون رمز JWT موقعاً) في ترويسات الطلب (request headers).
يقوم التطبيق المستهدف بالتحقق من صحة رمز JWT للتأكد من أن الطلب جاء بالفعل من الوكيل الموثوق به، وليس من عملية مارقة (rogue process) داخل العنقود.

توفر هذه البنية تحققاً مستمراً على مستوى الطبقة السابعة (Layer 7).

التنفيذ: بناء ZTNA باستخدام Pomerium و Kubernetes

دعونا نلقي نظرة على تطبيق عملي وملموس. سنستخدم Pomerium كوكيل معتمد على الهوية، ونقوم بنشره على عنقود Kubernetes (إصدار v1.29+). يعتبر Pomerium خياراً ممتازاً لأنه مفتوح المصدر وسريع للغاية ويتكامل بشكل أصيل مع مزودي الهوية القياسيين.

نفترض أن لديكم عنقود Kubernetes قيد التشغيل وخدمة ترغبون في إتاحتها بشكل آمن، مثل لوحة تحكم Grafana.

الخطوة 1: نشر Pomerium

أولاً، نحتاج إلى تهيئة Pomerium للاتصال بمزود الهوية (IdP) الخاص بنا. سنستخدم مخطط Helm قياسياً. إليكم مثالاً لتهيئة ملف values.yaml لـ Pomerium لربطه بـ Google Workspace.

# pomerium-values.yaml
authenticate:
  idp:
    provider: google
    clientID: "YOUR_GOOGLE_CLIENT_ID"
    clientSecret: "YOUR_GOOGLE_CLIENT_SECRET"
    serviceAccount: "base64_encoded_service_account_json"

ingress:
  enabled: true
  className: "nginx"
  hosts:
    - authenticate.internal.yourcompany.com
  tls:
    - secretName: pomerium-tls
      hosts:
        - authenticate.internal.yourcompany.com

config:
  # The shared secret for communication between Pomerium components
  sharedSecret: "generate_a_random_base64_string_here"
  cookieSecret: "generate_another_random_base64_string_here"

تطبيق مخطط helm:

helm repo add pomerium https://helm.pomerium.io
helm install pomerium pomerium/pomerium -f pomerium-values.yaml --namespace pomerium --create-namespace

الخطوة 2: تحديد سياسات الوصول

الآن نحن بحاجة إلى تأمين مثيل Grafana الخاص بنا. نقوم بذلك عن طريق تحديد مورد Ingress مع تعليقات توضيحية (annotations) محددة يفهمها Pomerium. وبدلاً من Kubernetes Ingress القياسي، سنستخدم تعريف المورد المخصص (CRD) الخاص بـ Pomerium والذي يسمى PomeriumRoute.

هنا تتجلى قوة ZTNA؛ حيث نقوم بتعريف السياسة كتعليمات برمجية (policy as code) جنباً إلى جنب مع نشر تطبيقنا.

# grafana-route.yaml
apiVersion: ingress.pomerium.io/v1
kind: PomeriumRoute
metadata:
  name: grafana-secure-route
  namespace: monitoring
spec:
  from: https://metrics.internal.yourcompany.com
  to: http://grafana.monitoring.svc.cluster.local:80
  policy:
    - allow:
        and:
          - domain:
              is: yourcompany.com
          - claim/groups:
              has: "engineering-team@yourcompany.com"

تنص هذه التهيئة على ما يلي: السماح بالوصول إلى https://metrics.internal.yourcompany.com فقط إذا قام المستخدم بمصادقة هويته باستخدام بريد إلكتروني ينتهي بـ @yourcompany.com وكان عضواً في مجموعة engineering-team.

تطبيق المسار:

kubectl apply -f grafana-route.yaml

الخطوة 3: التحقق من التطبيق المستهدف (الخطوة الحاسمة)

إذا توقفتم عند الخطوة 2، فسيكون لديكم ثغرة أمنية. ماذا يحدث لو تمكن مهاجم من اختراق كبسولة (pod) داخل عنقود Kubernetes الخاص بكم؟ يمكنه حينئذٍ تجاوز Pomerium بالكامل وإرسال الطلبات مباشرة إلى http://grafana.monitoring.svc.cluster.local:80.

لتحقيق وصول حقيقي للشبكة بثقة صفرية (Zero-Trust Network Access)، يجب على التطبيق المستهدف (Grafana) التحقق من أن كل طلب يمر عبر Pomerium.

يقوم Pomerium بحقن ترويسة X-Pomerium-Jwt-Assertion في كل طلب يمر عبره. رمز JWT هذا يكون موقعاً بواسطة المفتاح الخاص بـ Pomerium.

يجب على تطبيقكم التحقق من صحة رمز JWT هذا. إذا كنتم تبنون خدمات مصغرة مخصصة بلغة Go (على سبيل المثال باستخدام Go 1.22)، فيمكنكم تنفيذ برمجية وسيطة (middleware) لإجراء هذا التحقق.

package main

import (
	"context"
	"crypto/rsa"
	"fmt"
	"net/http"
	"strings"

	"github.com/golang-jwt/jwt/v5"
	"github.com/lestrrat-go/jwx/v2/jwk"
)

// JWKS URL for Pomerium
const pomeriumJWKSURL = "https://authenticate.internal.yourcompany.com/.well-known/pomerium/jwks.json"

func requirePomeriumAssertion(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		assertion := r.Header.Get("X-Pomerium-Jwt-Assertion")
		if assertion == "" {
			http.Error(w, "Missing Pomerium Assertion", http.StatusUnauthorized)
			return
		}

		// Fetch and cache the public keys from Pomerium
		ctx := context.Background()
		set, err := jwk.Fetch(ctx, pomeriumJWKSURL)
		if err != nil {
			http.Error(w, "Failed to fetch keys", http.StatusInternalServerError)
			return
		}

		// Parse and validate the JWT
		token, err := jwt.Parse(assertion, func(token *jwt.Token) (interface{}, error) {
			if _, ok := token.Method.(*jwt.SigningMethodES256); !ok {
				return nil, fmt.Errorf("unexpected signing method: %v", token.Header["alg"])
			}
			
			kid, ok := token.Header["kid"].(string)
			if !ok {
				return nil, fmt.Errorf("missing kid header")
			}

			key, ok := set.LookupKeyID(kid)
			if !ok {
				return nil, fmt.Errorf("key %v not found", kid)
			}

			var rawKey interface{}
			if err := key.Raw(&rawKey); err != nil {
				return nil, err
			}
			return rawKey, nil
		})

		if err != nil || !token.Valid {
			http.Error(w, "Invalid Assertion", http.StatusForbidden)
			return
		}

		// Proceed to the application
		next.ServeHTTP(w, r)
	})
}

من خلال فرض التحقق من صحة JWT على مستوى طبقة التطبيق، فإنكم تجعلون الحدود الشبكية غير ذات أهمية. حتى لو كان المهاجم على نفس الشبكة الفرعية (subnet)، فلن يتمكن من تجاوز عمليات التحقق من التفويض.

العقبات الشائعة: أسباب فشل نشر ZTNA

إن نشر وكيل معتمد على الهوية أمر مباشر. لكن نقل المؤسسة فعلياً إلى نموذج الثقة الصفرية أمر صعب. وإليكم بعض أسباب الفشل الشائعة:

1. تجاهل التطبيقات القديمة (Legacy Applications)

تتعامل تطبيقات SaaS الحديثة مع بروتوكول HTTP وتفهم بروتوكولات OAuth أو OIDC بشكل أصيل. أما الأدوات الداخلية القديمة فلا تفعل ذلك في كثير من الأحيان؛ إذ قد تعتمد على عناوين IP ثابتة ومحفورة في الكود أو على المصادقة الأساسية (basic authentication).

لا تحاولوا إعادة كتابة هذه التطبيقات على الفور. بدلاً من ذلك، استخدموا الوكيل لحقن الترويسات (headers) أو لإجراء ترجمة للمصادقة الأساسية. وإذا كان التطبيق يستخدم بروتوكولاً غير HTTP (مثل SSH أو RDP)، فأنتم بحاجة إلى وكيل يدعم إنشاء الأنفاق (tunneling) (يتعامل كل من Pomerium و Teleport مع هذا الأمر بشكل جيد).

2. النمط المضاد "كسر الزجاج للحالات الطارئة" (The "Break Glass" Antipattern)

غالباً ما تطبق الفرق سياسات ZTNA صارمة، لكنها تترك شبكة VPN خلفية تعمل "فقط في حالة" تعطل مزود الهوية (IdP). هذا الأمر يقوض الهدف بالكامل؛ فالمهاجمون سيعثرون على شبكة VPN هذه بالتأكيد.

بدلاً من تشغيل شبكة موازية غير آمنة، صمموا بنية ZTNA الخاصة بكم لتكون عالية الإتاحة (high availability). استخدموا مزودي هوية احتياطيين (redundant IdPs)، أو تأكدوا من أن وكيلكم يمكنه تخزين قرارات السياسة والمفاتيح التشفيرية مؤقتاً لتخطي فترات الانقطاع الوجيزة لمزود الهوية.

3. إرهاق التنبيهات (Alert Fatigue)

تنتج بنية الثقة الصفرية حجماً هائلاً من سجلات الأحداث (logs)؛ حيث يمثل كل طلب حدث تفويض مستقل. وإذا قمتم برمي جميع هذه السجلات في نظام SIEM دون تصفية وربط دقيقين، فسيواجه فريق الأمن لديكم إرهاقاً كبيراً بسبب التنبيهات الزائدة عن الحد.

ركزوا بدلاً من ذلك على تسجيل الطلبات المرفوضة التي تنشأ من أجهزة معروفة للشركة، أو حالات السفر المستحيل (impossible travel) ضمن سجلات الهوية الخاصة بكم.

النتيجة: تطبيق SaaS حديث ومرن

إن الانتقال إلى الوصول للشبكة بثقة صفرية (Zero-Trust Network Access) يمثل استثماراً هندسياً كبيراً؛ فهو يتطلب إعادة تدريب الفرق، وتحديث البنية التحتية، وتبني عقليات تشغيلية جديدة.

ولكن النتيجة هي مؤسسة أكثر مرونة وقوة بشكل جوهري.

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

والأهم من ذلك هو أنكم تقللون بشكل كبير من نطاق التأثير (blast radius) في حالة اختراق أي جهاز نهائي. ففي العالم المعتمد على المحيط الأمني، يعد سرقة جهاز محمول لأحد المطورين خرقاً كارثياً. أما في عالم الثقة الصفرية، فهو حادث محتوى ومسيطر عليه.

تخلصوا من خنادقكم المائية، وأمنوا تطبيقاتكم، وابدأوا في بناء بنية الثقة الصفرية اليوم.

خدمة سفن لابس

اختبار الاختراق VAPT والأمن السيبراني

نختبر الأنظمة ضد الثغرات الأمنية. شاهد خدمات الأمن السيبراني ←