ארכיטקטורת אפס אמון
אפס אמון הוא מודל האבטחה שמניח שאף חלק מהרשת אינו אמין ושכל בקשת גישה חייבת להיות מאומתת ומאושרת ללא קשר למקום ממנו היא הגיעה. הוא החליף את הרעיון הישן של היקף חיצוני קשיח עם פנים רך, לאחר שעשור של התקפות הוכיח שההיקף מעולם לא היה קשה כמו שפורסם.
גוף המאמר המלא מסופק באנגלית להלן.
Zero Trust Architecture (ZTA) הוא מודל אבטחה הדורש אימות מפורש עבור כל ניסיון גישה לכל משאב, ללא אמון מרומז המוענק על סמך מיקום הרשת. "לעולם אל תסמוך, תמיד תאמת" - המשפט התעייף אבל העיקרון מתקיים. המודל הגיע ממחקר Forrester של ג'ון קינדרוואג משנת 2010 וכעת הוא מקודד ב-NIST SP 800-207.
מה שהחליף את מה
הדגם המסורתי - "טירה וחפיר" - הניח:
- Tאיומים מגיעים מבחוץ; ברגע שאתה בפנים, אתה מהימן
- חומות אש ו-VPN מגדירים את ההיקף
- הרשת היא גבול האבטחה
זה עבד עד שזה לא עבד. אישורים שנפגעו, התקפות שרשרת האספקה, מקורבים זדוניים ועבודה מרחוק - כולם עקפו את ההיקף. ההפרות הידועות לשמצה של שנות ה-2010 - Target, OPM, Anthem, Sony, Equifax - כולן כללו תוקף שנכנס לתוך ההיקף ואז נע בחופשיות. ההיקף היה נקודת הכישלון היחידה.
Zero Trust אומר: נניח שהתוקף כבר בפנים. אימות ואשר כל בקשה כאילו הגיעה מרשת עוינת. ההגנה אינה תלויה בהיקפי.
עקרונות הליבה
NIST שבעת העקרונות של:
- כל מקורות הנתונים ושירותי המחשוב הם משאבים. אין סטטוס מיוחד למערכות תקשורת "פנימיות" עבור "0XX8 פנימיות". מאובטח ללא קשר למיקום הרשת. הצפנה במעבר תמיד; אל תסמוך רק בגלל שהתעבורה נמצאת בתוך חומת האש.
- הגישה למשאבים בודדים ניתנת על בסיס הפעלה. אימות לכל משאב, לכל בקשה, לא פעם אחת לכל כניסה לרשת.
- Access נקבעת לפי מדיניות התקן + פוסט דינמי, +X ההקשר לא רק "נמצא ברשת המשנה 10.0.x.x."
- הארגון מפקח ומודד את תקינותם של כל הנכסים בבעלות והמשויכים. בדיקת בריאות רציפה של מכשירים.
- כל המשאבים הם אימות דינמי והרשאה XPLZ אכיפה דינמית והרשאה XPLZ. יופסק כאשר היציבה משתנה.
- הארגון אוסף מידע רב ככל האפשר על מצב הנכסים, תשתית הרשת והתקשורת. Telemetry מזינה את החלטת הסיכון.
איך זה באמת נראה בפועל
AXXPLZ אמון פריסה מודרנית בדרך כלל5 משלבת:- Identity provider (Okta, Microsoft Entra, Google Workspace) - מקור יחיד של אמת עבור מי שאתה.
- ניהול מכשירים (Jamf, Intune הם מכשירי Chrome בריאים ו-Chrome Enterprises) תואם.
- Access proxy (Cloudflare Access, Zscaler, Tailscale, BeyondCorp) — יושב מול כל אפליקציה פנימית ואוכף מדיניות על כל בקשה. רשת.
- Policy engine — מעריך כל בקשה מול כללים המשלבים זהות, מכשיר והקשר.
למשתמשים, התוצאה אינה נראית: פתח את Outlook, לחץ על Salesforce, ערוך דף Confluence שמאפשר גישה ל-Proxy ומנתב את ה-proxy ואז כל מכשיר מנתב את הגישה או ה-proxy. המשתמש לא רואה את מנוע המדיניות; הם רואים SSO והאפליקציות פשוט עובדות.
BeyondCorp: הדגם
יוזמת BeyondCorp של Google (החלה פנימית ב-2009, פורסמה 2014–2017) הייתה הפריסה הראשונה בקנה מידה גדול של Zero Trust. גוגל הסירה את ה-VPN הארגוני והפכה כל אפליקציה פנימית לנגישה ישירות דרך האינטרנט הציבורי - שמור על ידי פרוקסי מודע לזהות שבדק משתמש, מכשיר והקשר לכל בקשה. המודל הוכיח כי Zero Trust יכול לעבוד בקנה מידה, וגוגל ייצרה אותו כ-Identity-Aware Proxy ב-GCP.
BeyondCorp הצלחתה של התעשייה. רוב הארגונים הגדולים לפחות התחילו במסע של Zero Trust, גם אם ההגירה איטית מכיוון שכל כך הרבה דברים מדור קודם נבנו סביב המודל ההיקפי הישן.
Zero Trust ו-VPNs
Zero Trust נחשבים לפעמים כ"מוות ה-VPN". נכון חלקית. VPNs ארגוניים מסורתיים מעניקים גישה לרשת, ולאחר מכן המשתמש יכול להגיע לכל דבר שהוא מורשה אליו. Zero Trust מעניק גישה ליישומים ספציפיים, לא לרשת - מפחית משמעותית את רדיוס הפיצוץ ממשתמש שנפגע.
חלופות מודרניות כוללות Tailscale (שהוא VPN, אבל עם ACLs לכל אפליקציה וגישה מודעת לזהות - למעשה קנה מידה קטן של Zero Trust), Cloudflare Access ומוצרי ZTNA (Zero Trust Network Access) שונים.
Where Zero Trust קשה
חלקים:
- Legacy applications. אפליקציות שצפויות להיות ברשת מהימנה לרוב אין להן אימות מתאים. יש להתאים אותם בדיעבד או להעביר אותם לשרת proxy.
- Service-to-service auth. מיקרו-שירותים המדברים זה עם זה הם משטח התקפה עיקרי, ו-mTLS פלוס רשת שירות מודע לזהות מורכבת מבחינה תפעולית.
- Policy per-text per-texter. הרבה כללים. פריסות בוגרות משתמשות בהפשטות (קבוצות, תפקידים, תכונות) אבל העומס הקוגניטיבי הוא אמיתי.
- עלות הגירה. החלפת בקרות מבוססות היקפי בבקרות Zero Trust היא מסע רב-שנתי עבור כל ארגון גדול. רובם נמצאים באמצע הדרך.
Zero Trust for individuals
העקרונות מצטמצמים. כאדם פרטי:
- השתמש באימות חזק בכל מקום - סיסמאות + 2FA, או מפתחות
- אל תסמוך על הרשת הביתית שלך - הצפין הכל במעבר
- הפעל חשבונות עם הרשאות מינימליות במכשירים שלך (לא ניהול כברירת מחדל) מכיוון שנקודות קצה שנפרצו הן ההפרה הנפוצה ביותר של Zero Trust
- Tתייחס להפעלות דפדפן כבלתי מהימנות כברירת מחדל - בארגז חול, עם סינון תוכן
לא תפרוס ארכיטקטורת Zero Trust בבית, אבל הלך הרוח - נניח שכל שכבה בודדת יכולה להיכשל ישירות
.שאלות נפוצות
- האם אפס אמון הוא מוצר או פילוסופיה?
- שְׁנֵיהֶם. הפילוסופיה מוגדרת היטב (NIST 800-207). המוצרים שמיישמים אותו יוצרים מחסנית: ספק זהות, ניהול מכשירים, פרוקסי גישה, מנוע מדיניות, טלמטריה. ספקים מוכרים חלקים; "אפס אמון" היא הארכיטקטורה שאתה מרכיב מהם.
- האם Zero Trust מבטל את הצורך בחומות אש?
- לא לגמרי. חומות אש עדיין שימושיות עבור סינון רשת גס וחוסן DDoS. אבל הם כבר לא שכבת בקרת הגישה העיקרית; פרוקסי הגישה הוא. לרוב הפריסות של Zero Trust עדיין יש חומות אש; תפקידם עבר מ"ההגנה" ל"הגנה".
- האם עסק קטן יכול לאמץ את Zero Trust?
- כן, בקלות רבה יותר מאי פעם. ל-Cloudflare Access יש שכבה חינמית; ל-Tailscale יש תוכנית חינם נדיבה; Google Workspace ו-Microsoft 365 מאגדות יכולות Zero Trust למנויים עסקיים. המחסום כבר אינו עלות; זה השינוי התפעולי של ניהול מדיניות של כל אפליקציה.
- האם Zero Trust הוא רק SASE / SSE / ZTNA / SDP / [ראשי התיבות הבאות]?
- אלו קטגוריות קשורות. SASE (Secure Access Service Edge) היא פלטפורמת הרשת + האבטחה המסופקת בענן. SSE (Security Service Edge) היא תת-קבוצת האבטחה בלבד. ZTNA (Zero Trust Network Access) הוא החלק הספציפי של גישה לאפליקציה. SDP (Software-Defined Perimeter) הוא מונח ישן יותר לאותו רעיון. אפס אמון היא הפילוסופיה; אלו מוצרים שמיישמים את זה.
- כמה זמן נמשכת הגירה של Zero Trust?
- למפעל: 2-5 שנים. העבודה היא לא הטכנולוגיה - היא מזהה כל אפליקציה, כל זרימת שירות לשירות, כל מנגנון אימות מדור קודם, והעברה של כל אחד מהם למודל החדש. חברות שאומרות שהן "אפס אמון" מתכוונות בדרך כלל שיש להן פרוקסי מודע לזהות עבור רוב האפליקציות ועדיין עובדות דרך הזנב הארוך.