עיצוב והטמעת ארכיטקטורת Zero Trust

אבטחת היקף מתה: VPN אינו מגן מפני מחשב נייד שנפרץ של עובד, ובענן אין רשת 'פנימית'. מודל Zero Trust הוא הגישה היחידה שעובדת עבור תשתית היברידית. אנו מתכננים ומיישמים ארכיטקטורת Zero Trust במפתח מלא: מסקירת סיכונים נוכחיים ועד מעבר מלא למודל 'לעולם אל תסמוך, תמיד אמת'. למהנדסים שלנו יש ניסיון של למעלה מ-10 שנים באבטחת ענן ו-Kubernetes. יישמנו Zero Trust עבור חברות עם תשתיות הנעות בין 50 ל-5,000 שרתים. אנו מבטיחים שאחרי העבודה שלנו, כל מתקפת רשת תיעצר בשלבים המוקדמים ביותר. צרו קשר כדי להעריך את הפרויקט שלכם.

למה אבטחת היקף לא עובדת?

מודל האבטחה הקלאסי נבנה על היקף: בחוץ — רשת לא מהימנה, בפנים — הכל מהימן. VPN סיפק גישה 'פנימה', ואז הכל היה פתוח. הבעיה צצה עם SaaS, עבודה מרחוק והענן: המושג 'פנים' חדל להתקיים. מחשב נייד שנפרץ של עובד מגיע 'פנימה' ומקבל גישה להכל.

Zero Trust מסיר אמון מרומז המבוסס על מיקום ברשת. כל בקשה מאומתת ומורשית — ללא קשר למקום שממנו היא מגיעה.

שכבה 1: גישה מבוססת זהות

הבסיס של Zero Trust הוא זיהוי של כל ישות: משתמש, שירות, מכשיר.

משתמשים: MFA הוא חובה לכולם, כולל מערכות פנימיות. OIDC דרך IdP ארגוני (Okta, Azure AD, Google Workspace) עבור כל היישומים. SSO לא לנוחות — אלא לשליטה מרכזית. השבתת משתמש ב-IdP = אובדן גישה מיידי לכל המערכות.

שירותים: mTLS בין כל השירותים, SPIFFE/SPIRE לזיהוי עומסי עבודה. אסימוני Kubernetes ServiceAccount עם expirationSeconds: 3600 במקום אסימונים ארוכי טווח.

מכשירים: מכשירים ארגוניים עם אימות מצב (הרשמה ל-MDM, הצפנת דיסק, גרסת מערכת הפעלה). גישה למשאבים רגישים רק ממכשירים מנוהלים. מיושם באמצעות בדיקת מצב מכשיר ב-Tailscale, Cloudflare Access או Google BeyondCorp.

שכבה 2: פילוח רשת באמצעות מיקרו-פילוח

רשת שטוחה היא האויב של Zero Trust. גם אם תוקף מגיע למארח אחד, יש לחסום תנועה רוחבית.

ב-Kubernetes — NetworkPolicy עבור כל namespace:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api
      ports:
        - protocol: TCP
          port: 5432

ברירת מחדל deny-all + כללי allow מפורשים עבור כל זוג שירותים. Cilium או Calico עם תמיכה בכללי L7 מאפשרים לאפשר לא רק 'פורט 80', אלא שיטות ונתיבי HTTP ספציפיים.

בענן: Security Groups עם כללים מינימליים, AWS PrivateLink לתקשורת בין שירותים ללא הרשת הציבורית, VPC Endpoints עבור שירותי AWS.

איך מיקרו-פילוח עוצר מתקפות?

מיקרו-פילוח מפרק את הרשת למקטעים מבודדים, שלכל אחד מהם כללי גישה משלו. גם אם תוקף פוגע ב-pod, הוא לא יכול לנוע לרוחב למסד הנתונים כי NetworkPolicy מאפשרת תעבורה רק מה-API. לפי NIST, מיקרו-פילוח מפחית את זמן זיהוי החדירה ב-70% בהשוואה לרשת שטוחה. ארכיטקטורת Zero Trust יעילה פי 5 במניעת תנועה רוחבית בהשוואה לכללי חומת אש מסורתיים.

שכבה 3: בקרות ברמת היישום

תעבורת רשת מותרת אינה אומרת שהגישה ניתנת. כל יישום מיישם הרשאה משלו:

הרשאת service mesh. Istio AuthorizationPolicy ברמת כל שירות — אילו זהויות יכולות לבצע אילו בקשות. לא רק 'frontend יכול לדבר עם api', אלא 'frontend יכול apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: production spec: podSelector: {} policyTypes: - Ingress - Egress --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-api-to-db namespace: production spec: podSelector: matchLabels: app: postgres policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: api ports: - protocol: TCP port: 5432 אבל לא GET /api/products.'

Open Policy Agent (OPA) / Rego. מנוע מדיניות מרכזי ללוגיקת הרשאות מורכבת. OPA יכול לשמש כ-Admission Controller ב-Kubernetes, כ-middleware ביישומים, או כ-sidecar.

# policy/authz.rego
package authz

default allow = false

allow {
    input.method == "GET"
    input.path[0] == "api"
    input.user.roles[_] == "read-only"
}

allow {
    input.user.roles[_] == "admin"
}

שכבה 4: בקרות גישה לנתונים והרשאות מינימליות

גישה לנתונים ברמת שורה ועמודה. PostgreSQL Row Level Security:

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY orders_tenant_isolation ON orders USING (tenant_id = current_setting('app.tenant_id')::uuid);

מדיניות IAM ב-AWS עם תנאים המבוססים על תגי משאבים, לא על ARN עם תווים כלליים. מדיניות S3 bucket השוללת גישה ללא VPC Endpoint.

שכבה 5: נראות — לוגים, מדדים, התראות

Zero Trust ללא נראות הוא מנעול עם שערים בלתי נראים. יש צורך ב-audit trail של כל גישה:

• CloudTrail עבור קריאות API של AWS
• יומן audit של Vault עבור כל בקשת סוד
• יומן audit של Kubernetes עבור פעולות שרת API
• לוגי גישה ברמת היישום עם זהות משתמש

התנהגות חריגה: משתמש ביקש 1,000 סודות ב-5 דקות, שירות התחיל לגשת לנקודות קצה חדשות, pod ביצע בקשת egress לכתובת IP חיצונית. כל זה אמור להפעיל התראות דרך SIEM או כללים ב-AWS GuardDuty / Falco.

מה כלול

אנו מספקים את מחזור היישום המלא: סקירת הארכיטקטורה הנוכחית, תכנון המודל היעד, הגדרת IdP ו-MFA, פריסת NetworkPolicies, הגדרת mTLS דרך service mesh, שילוב SIEM והדרכת צוות. כל שלב מתועד; אתם מקבלים דיאגרמת רשת, מדיניות גישה ו-runbook לתפעול.

מסלול יישום אינקרמנטלי

Zero Trust לא מיושם ב-sprint אחד. מפת דרכים אופיינית:

כל שלב מוסיף הגנה מבלי לחסום פעולות עסקיות. ניסיון לעשות הכל בבת אחת בסביבת ייצור מוביל בהכרח לתקרית זמינות.

לפי מחקרי תעשייה, יישום Zero Trust יכול להפחית עלויות תקריות אבטחה בעד 40%. בממוצע, ארגונים משיגים הפחתה של 50% בעלויות הקשורות לפריצות לאחר מעבר למודל Zero Trust.

העלות מחושבת באופן אישי לאחר סקירת הארכיטקטורה הנוכחית וזיהוי סיכונים עדיפים. היקף העבודה תלוי בגודל התשתית ובבגרות של פרקטיקות האבטחה הנוכחיות. צרו קשר לייעוץ — אנו נעריך את הפרויקט שלכם.