ארכיטקטורת אמון אפס

תקציר

Zero Trust (בקיצור: ZT) הוא מודל אבטחה שבו היקף הרשת אינו נחשב יותר לאזור אמין. כל בקשה (user ach application, service ach service, action ach network) מאומתת באופן מפורש, מורשית ומוצפנת, תוך לקיחת בחשבון אותות קונטקסטואליים (זהות, מצב התקן, מיקום, סיכון, התנהגות). המטרה היא לצמצם את רדיוס הפיצוץ, להפחית את הסיכון לתנועה לרוחב ולפשט את הציות.

אפס יסודות אמון

1. אין אמון מפורש - אמון אינו עובר בירושה מרשת VPN/ASN.
2. הגישה היא המינימום הדרוש: המדיניות ”לספק רק את הדרוש כעת”.
3. אימות רציף: מפגשים ואסימונים נערכים מחדש באופן קבוע לסיכון והקשר.
4. הנחת פשרה: פיצול, יכולת תצפית, בלימה מהירה וסיבובי מפתח.
5. הצפנה בכל מקום: TLS 1. 2+/1. 3 ו-MTLS בתוכניות מידע, DNS מוגן, סודות ב-KMS/HSM.

נוף מטרה ותחומי שליטה

זהות: בני אדם (IDP: SSO, MFA, Passkeys/FIDO2), מכונות (SPIFF/SVID, x509/mTLS).
התקנים: ציות למדיניות (MDM/EDR, דיסק מוצפן, טלאים, בריחה מהכלא/שורש - אסור).
רשת: Microsegmentation L3/L7, ZTNA/SDP gateways, service mesh (שליח/איסטיו/לינקרד).
יישומים/APIs: mTLS, OIDC/JWT, חתימות בקשה (HMAC), מגבלות קצב, DLP/מיסוך.
נתונים: סיווג (Public/Secretial/Restricted), טוקניזציה/הצפנה ברמת השדה.
תצפיות: רישומי אימות/אישור מרכזיים, אנליטיקה התנהגותית, SLO/SLA.

ארכיטקטורת התייחסות (שבור על ידי מטוסים)

מטוס בקרה: IDP/CIAM, PDP/PEP (אופ "א/שליח), קטלוגי מדיניות, PKI/CA, אימות התקן.
Data Plane: proxy access (ZTNA), sidecar proxy (Envoy) עבור mTLS ומדיניות L7, GW service gateways/APIs.
מטוס ניהול: קטלוג שירות, CMDB, CI/CD, ניהול סודי (Vault/KMS), ביקורת מרכזית.

1. זיהוי (SSO + phishing-resistance MFA) * 2) הערכת התקנים (MDM posture) * 3) ZTNA מייסדת mTLS ליישום * 4) PDP (פוליסה) מקבל החלטה בהתבסס על תכונות (ABAC/RBAC C F F F F F F F E E E E) * 5) הערכת סיכון רציפה מחדש (זמן, גיאו, חריגות).

זהות ואישור

IDP/SSO: OIDC/SAML, ברירת מחדל MFA, רצוי FIDO2 (סיסמאות).
RBAC/ABAC: תפקידים + תכונות הקשר (מצב התקן, מחלקה, פרופיל סיכון).
גישה Just-In-Time (JIT): הרשאות זמניות עם ביטול אוטומטי; זכוכית פריצה - מוסדרת בקפדנות.
MTLS למכונות: SPIFFE/SVID או PKI פנימי עם תעודות קצרות טווח; שחרור רוטרי אוטומטי.

התקנים והקשר

יציבה: OS/EDR, כולל דיסק-הצפנה, חומת אש; לא תואם גישה מינימלית או בלוק.
הצגה: זהות התקן + שמות חתומים (MDM/Endpoint).
הגבלות רשת: חסימה של מנהרות צד שלישי, DNS תאגידי כפוי, הגנה מפני דליפות DNS/WebRTC.

networking ו ־ microsegmentation

במקום זאת, קטעים/VRF ומדיניות על L7.
Service Mesh: Sidecar proxies מספק mTLS, אישור מדיניות (OPA/Envired Filter), טלמטריה.
ZTNA/SDP: גישה ליישום מסוים, לא לרשת; kliyent↔broker↔app, מדיניות ב-PDP.
גישה מרחוק: החלפת VPN עבה עם יישום פרוקסי; מנהרות נסיגה מוגבלות לנתיבים/נמלים.

מדיניות ומנוע פתרון

PDP/PEP: Policy Decision Point (OPA/Styra, Cedar buth). + נקודת אכיפת מדיניות (שליח/איסטיו/שער).
מודל מדיניות: חוקים הצהרתיים (Rego/Cedar), תכונות סטטיות וקונטקסטואליות, הערכת סיכונים.

rego package access. http

default allow = false

allow {
input. user. role == "support"
input. request. path == "/admin/tickets"
input. device. compliant == true time. now_hh >= 8 time. now_hh <= 20
}

פתרונות עקבות: רישום ”קלט ”/” תוצאה ”/” הסבר” לביקורת.

הצפנה ברירת מחדל ואמון

TLS 1. 2+/1. 3 בכל מקום, סוויטות צופן קפדניות, HSTS, הידוק OCSP.
MTLS בפנים: servis↔servis רק על ידי תעודות משותפות; מפתחות לטווח קצר (שעות/ימים).
סודות: KMS/HSM, סודות דינמיים (Vault), TTL קצר, פחות חיסיון ליישומים.

תצפית, SLO ותגובה

• אימות והצלחת אישור (%), זמן החלטה P95 PDP, לחיצת יד p95 TLS.
• אחוז הבקשות החסומות על ידי מדיניות (חריגות/שווא).
• זמינות של מתווכי ZTNA ובקר רשת.
• פרופורציה של מכשירים וטרנדים תואמים.

• "זי-טי-אן-איי 99 זמינות. 95 %/חודש; החלטה p95 authZE second 50/emply"
• "אחוז הבקשות באם-טי-אל-אס-99. 9%».
• "לא יותר מ-0. 1% כשלים בגישה שגויה/יום"

אזעקה: התפרצויות של הכחשה, השפלה של לחיצות ידיים p95, שרשראות לא תקפות, ירידה בפרופורציה של התקנים תואמים, חריגות גאוגרפיה/ASN.

מעבר מהיקף לאמון אפס: מפת דרכים

1. מלאי: יישומים, זרימות נתונים, צרכנים, רגישות (PII/card/paypouts).
2. זהות ו-MFA: SSO ו-MFA עמיד בדיג לכולם.
3. הקשר התקני: MDM/EDR, מדיניות ציות בסיסית, בלוק לא תואם.
4. מיקרו-ביצועים של נתיבי עדיפות: תשלומים, משרד אחורי, מנהל; הזן mTLS.
5. ZTNA לגישה למשתמש: פרסום יישומים באמצעות פרוקסי, הסר את ה ־ VPN הרחב.
6. מדיניות ABAC: PDP מרוכז, חוקים הצהרתיים, ביקורת.
7. הארכת רשת השירות: S2S mTLS, מדיניות אל-7, טלמטריה.
8. אוטומציה ו-SLO: התראה, מבחני מדיניות (CI פוליטי), ימי משחק "מה אם IDP אינו זמין? ».

פרטים עבור iGaming/fintech

קטעי דומיין קשיחים: תשלומים/PII/אנטי הונאה/תוכן - היקפים נפרדים ומדיניות; גישה רק מעל ZTNA.
אינטראקציה עם PSP/בנקים: אפשר רשימה על ידי ASN/ranges, mTLS עד PSP-endpoints, ניטור טיים-טו-וולט וכישלונות AuthZ.
ספקי תוכן ושותפים: גישה זמנית ל-JIT API, אסימוני TTL קצרים, ביקורת אינטגרציה.
ציות: PCI DSS/GDPR - מזעור נתונים, DLP/פסאודונימיזציה, רישום גישה לטבלאות רגישות.

ביטחון שרשרת אספקה ו CI/CD

חתימות חפץ (SLSA/Provenance): חתימות מכל (cossign), מדיניות קבלה בשנת K8s.
SBOM ופגיעות: SBOM דור (CyclonDX), מדיניות-שער בצינור.
סודות CI: OIDC Federation to Cloud KMS; איסור על מפתחות סטטיים.
סיבובים: תדיר, אוטומטי; נאלץ לבטל על תקריות.

חרקים נפוצים ותבניות אנטי

”ZTNA = VPN חדש”: פרסום רשת במקום יישומים אינו אפס נאמנות.
אין בדיקת התקן: MFA הוא, אבל התקנים נגועים/מושרשים מקבלים גישה.
משתמש על יחיד: היעדר JIT ותפקידים נפרדים.
מדיניות בקוד השירות: ביקורת/עדכון מרכזי לא אפשרי.
MTLS חלקי: חלק משירותים ללא mTLS = = לולאת ”דולפת”.
אפס UX: מיותר בקשות MFA, אין SSO; תוצאה - התנגדות לפקודות.

מיני-מדריך לבחירת טכנולוגיות

גישה למשתמש: ZTNA/SDP ברוקר + IDP (OIDC, FIDO2 MFA).
אבטחת שירות: Service-mesh (Istio/Linkerd) + OPA/Envoy authZ.
PKI: SPIFFE/SVID או Vault PKI עם TTL קצר.
פוליטיקאים: אופ "א/רגו או סידר; חנות בגיט, תבדוק במודיע (בדיקות מדיניות).
יומנים וטלמטריה: OpenTelemetry # ניתוח ריכוזי, גילוי אנומליה.

תצורות מדגם (שברים)

שליח (הדדי-TLS בין שירותים)

yaml static_resources:
listeners:
- name: listener_https filter_chains:
- filters:
- name: envoy. filters. network. http_connection_manager typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. network. http_connection_manager. v3. HttpConnectionManager route_config: { name: local_route, virtual_hosts: [] }
transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params: { tls_minimum_protocol_version: TLSv1_2 }
tls_certificates:
- certificate_chain: { filename: /certs/tls. crt }
private_key: { filename: /certs/tls. key }
validation_context:
trusted_ca: { filename: /certs/ca. crt }
require_signed_certificate: true

אופ "א/רגו: גישה לדיווחים רק מ" פיננסים ", ממכשירים צייתנים, בשעות העבודה

rego package policy. reports

default allow = false

allow {
input. user. dept == "finance"
input. device. compliant == true input. resource == "reports/profit"
time. now_hh >= 8 time. now_hh <= 21
}

אפס רשימת יישומי אמון

1. אפשר SSO ו ־ MFA FIDO2 לכל המשתמשים.
2. הזן יציבת התקן (MDM/EDR) עם מנעול לא תואם.
3. העברה של גישה למשתמש ל-ZTNA (לכל אפליקציה), השאירו את VPN רק עבור ערוצי S2S צרים.
4. בפנים - mTLS כברירת מחדל + תעודות קצרות ימים.
5. מדיניות מרכזית (PDP/OPA), לאחסן בGit, מבחן בCI.
6. תחומים רגישים (תשלומים/פיל/משרד אחורי) ומגבילים את מזרח-מערב.
7. הגדרת טלמטריה, SLO והתראה על auth/authZ, mTLS שיתוף, אותות יציבה.
8. ניהול ”ימי משחק” (כשל IDP, דליפת מפתח, ירידה ברוקר) ותיקון SOPS/rolbacks.

שאלות נפוצות

האם קרן האפס מחליפה את וי-פי-אן לחלוטין?
לגישה למשתמש - כן, לטובת ZTNA. עבור גזעי S2S, VPN/IPsk עשוי להישאר, אך עם mTLS מעל ומדיניות קפדנית.

האם זי-טי יכול להחמיר את ה-UX?
אם בחוסר התחשבות. עם SSO + FIDO2, MFA אדפטיבית וגישה לכל אפליקציה, UX בדרך כלל משתפר.

האם זה הכרחי להציג רשת שירות?
לא תמיד. אבל עבור סביבת מיקרו-רוויס גדולה, רשת מפשטת בצורה קיצונית את mTLS/policy/telemetry.

סך הכל

קרן אפס היא לא מוצר אלא דיסציפלינה ארכיטקטונית: זהות כהיקף חדש, הקשר התקני, גישה ליישומים (ZTNA), מיקרו-ביצועים ו-MTLS בכל מקום, מדיניות ריכוזית ואמינות מדידה. אם תעקוב אחר מפת הדרכים ותבדוק, תצמצם את משטח ההתקפה, תזרז את הביקורת ותשיג ביטחון בר קיימא ללא ”ברירת מחדל”.