זהות היא הפרימטר החדש: Zero-Trust פרקטי לחברות בסדר גודל בינוני

"Zero-Trust" הוא הביטוי הכי משווק בתעשיית הסייבר. הוא גם הרעיון התפעולי הכי מועיל שהציגו בעשור האחרון, אם מצליחים להתעלם מהשיווק ולהתמקד במה שהוא באמת דורש. הקאץ' זה שעומק היישום שרוב הספקים מרמזים עליו (continuous device posture, microsegmentation בכל מקום, workload identity חתום ומוסמך) הוא באמת מעבר לתקציב הריאלי של רוב החברות בסדר גודל בינוני, ולנסות לקפוץ ישר לדיאגרמה הארכיטקטונית שעל המצגת של הספק מייצר תוכנית יקרה שאף פעם לא מתממשת בפועל.

זו גרסת Zero-Trust שאנחנו מריצים עם לקוחות mid-market. היא עולה בערך רבע מהמספר שמופיע בשקף הראשון של רוב מצגות הספקים, לוקחת בערך 18 חודשים לנחות, ובאופן מוכח מורידה סיכון תנועה לטראלית בכל מדידה שיש לנו. היא גם נוקטת עמדה ברורה לגבי אילו חלקים בארכיטקטורת ה-Zero-Trust הקנונית אפשר לדחות.

מה Zero-Trust באמת אומר בעברית פשוטה

Zero-Trust הוא טענה אחת: כל החלטת גישה מתקבלת מחדש, מול תמונה עכשווית של מי שואל ומה מותר לו, ללא הנחה ש"להיות בתוך הרשת" מקנה איזושהי הרשאה. זהו.

כל השאר, mTLS בין כל workload, ZTNA לפני כל אפליקציה פנימית, signed device posture attestations, attribute-based access control עם policy-as-code, אלה דפוסי יישום של הטענה. הם לא הטענה. אפשר ליישם את העיקרון של Zero-Trust באופן סביר בלי כל אלה, ואפשר לפרוס את כולם ועדיין לא לעבוד לפי העיקרון.

הסיבה שזה חשוב: חברות בסדר גודל בינוני קונות באופן עקבי את דפוסי היישום ומדלגות על לוגיקת ההחלטה שמתחתיהם. התוצאה היא תוכנית זהויות עם SSO, conditional access, MFA, ZTNA, וכלי CIEM, אבל שעדיין לא יכולה לענות על השאלה "אם הלפטופ של קבלן נפרץ עכשיו, לאילו נתוני פרודקשן הוא יכול להגיע בעשר הדקות הבאות?" היישום קיים. לוגיקת ההחלטה לגישה לא.

ארבעת המהלכים שסוגרים את רוב משטח התקיפה האמיתי

מהניסיון שלנו בערך ב-40 תוכניות זהויות בארגונים בינוניים, ארבע החלטות הנדסיות מהוות בערך 80% מההורדה האמיתית של סיכון תנועה לטראלית. ה-20% שנותרו הם באמת יקרים, וכדאי לחשוב עליהם בזהירות.

1. להפוך את ה-IdP לנתיב היחיד לכל דבר

המהלך עם הערך הגבוה ביותר הוא להבטיח שכל משאב משמעותי (פרודקשן בענן, מאגרי קוד, CI/CD, אפליקציות פנימיות, בסיסי נתונים, כלי תפעול, Kubernetes, SaaS של ספקים) דורש אימות דרך ספק הזהויות המרכזי שלכם. כל נתיב אחר, חשבונות מקומיים, service accounts משותפים, credentials שספק הנפיק, federated identity מרכישות ישנות, חייב להיות מסולק או מנותב דרך ה-IdP.

זה קשה מסיבה אחת: תמיד יש חריגים. SaaS legacy שלא תומך ב-SAML. מנועי בסיס נתונים עם מנגנון אימות משלהם. קונסולות של ספקים שרכש מחלקת רכש בלי שאבטחה הייתה מעורבת. החריגים הם המקום שבו הסיכון יושב. תעשו מצאי שלהם, תעדפו לפי blast radius, ותסגרו אותם על לוח זמנים מדוד. הסבב הראשון בדרך כלל מוצא 30 עד 80 משטחי אימות לא מנוהלים בחברה בינונית טיפוסית.

2. Conditional access שבאמת מבטא את מודל הסיכון שלכם

רוב מדיניות ה-conditional access שאנחנו רואים היא בוטה: "דרוש MFA לכל המשתמשים, חסום התחברות מחוץ למדינות מוכרות." זה בסדר אבל לא מבדיל בין אנליסט משאבי אנוש שבודק תלושי שכר לבין מהנדס DevOps שמקבל הרשאת פרודקשן. הגרנולריות הנכונה היא פר-אפליקציה, לפעמים פר-פעולה.

נקודת התחלה סבירה היא שלוש מחלקות מדיניות:

• עבודה רגילה: SSO, MFA, אימות מודרני דרוש. סשן דפדפן יכול להישאר ליום עבודה.
• מערכות רגישות (פרודקשן בענן admin, מערכות פיננסיות, source code עם secrets, customer רובד הנתונים): SSO, MFA מבוסס hardware, אימות מכשיר מנוהל, אימות טרי כל 4–8 שעות, עם חסימה או דרישת אימות מוגבר במקרי impossible-travel.
• פעולות בעלות אמון מירבי (פריסת פרודקשן, שינויי IAM policy, key rotations, ייצוא נתונים מעל סף): אימות מוגבר מפורש בפעולה, נדרשת הצדקה, מתועד ב-זרם ביקורת בלתי-נמחק.

המודל התלת-שכבתי הזה ניתן לאכיפה עם מה שרוב ה-IdP-ים הארגוניים שולחים היום (Entra ID, Okta, Ping). הוא לא דורש כלים נוספים. מה שהוא דורש זה את המשמעת לבצע מיפוי בפועל של כל מערכת לאחת משלוש השכבות, וזו העבודה האמיתית.

3. גרף הרשאות בקצב שבועי

אל תשאלו "האם למשתמשים יש least privilege?" השאלה הזו אף פעם לא נסגרת. תשאלו במקום: "לכל יחס הרשאה בסביבה שלנו, האם אנחנו יודעים שהוא קיים, והאם הוא מוצדק?" הדרך לתפעל את זה היא לחשב את גרף ההרשאות (כל ישות → כל משאב שהוא יכול להגיע אליו) בקצב שבועי ולעקוב אחרי הגודל והצורה שלו לאורך זמן.

תוכנית בריאה רואה את הגרף הזה מתכווץ. תוכנית לא בריאה רואה אותו גדל ככל שצוותי הנדסה מוסיפים תחולה כדי לגרום למערכות לעבוד. שוק ה-CIEM קיים כדי לעשות את זה לענן. ל-SaaS ולאפליקציות פנימיות בדרך כלל אפשר לבנות גרסה 90% נכונה מ-ייצוא דרך API יחד עם שכבת נירמול. הפואנטה היא לא מושלמות. הפואנטה היא לייצר metric שחושף האם התוכנית מרוויחה או מאבדת קרקע.

4. Audit ברמת הפעולה, לא ברמת ה-session

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

ביקורת ברמת פעולה צריך לכסות לפחות: רובד בקרה של ענן (CloudTrail / Activity Log / Audit Logs), identity admin (הקצאות תפקיד, עריכות policy, שינויים ב-privileged groups), פריסת פרודקשן, גישה ל-secrets, וייצוא נתוני לקוחות. אלה המקומות שבהם פעולות תוקף נראות אם מסתכלים. רוב ההוצאה כאן היא עלות הזרמה ל-SIEM. העבודה ההנדסית היא בעיקר הפעלת לוגים שכבר קיימים.

ה-20% שבאמת יקרים

אם תעשו את הארבעה למעלה, סגרתם בערך 80% ממשטח התקיפה של תנועה לטראלית בחברה בינונית. ה-20% שנשארו הם איפה ששיווק הספקים גר, והם באמת יקרים:

• Continuous device posture ו-attestation. זהות מכשיר עם hardware root שמוכיחה שהמכונה הדורשת לא נטתה ממצב known-good, מוערכת בכל גישה, היא Zero-Trust אמיתי בשכבת הרשת. היא גם הסעיף הגדול ביותר בפריסה בסגנון גוגל. חברות בינוניות בדרך כלל לא צריכות את זה, ואלה שכן (תעשיות מוסדרות עם מטרות בעלות ערך גבוה) צריכות לתכנן תוכנית רב-שנתית במקום לקנות את זה כפתרון מוכן.
• Workload identity בגרנולריות מלאה. mTLS בין כל microservice עם certificates קצרי-חיים מתחלפים זה הנדסה מצוינת. זה גם יקר ולרוב החברות, ערך נמוך יותר מתיקון משטח הזהויות האנושיות קודם. Service mesh נקנה לעיתים קרובות לפני שעושים את הארבעה למעלה, והמורכבות שנוצרת בעצם מקשה על תגובה לאירוע.
• Microsegmentation לרוחב הרשת. אכיפת רשת של מדיניות זהות-מודעת היא בקרה אמיתית, אבל אם כבר הפכתם את הזהות לפרימטר (מהלך 1), הרשת יכולה להיות יותר שטוחה והחזרים על הבקרה יותר קטנים.

תוכנית זהויות פרגמטית בארגון בינוני דוחה את שלושת אלה ב-18–24 חודשים הראשונים ובוחנת מחדש כשהגרף וה-audit הבסיסיים בריאים. לקנות אותם מוקדם זה לא שגוי, פשוט הסדר הלא נכון.

איפה אנחנו נכנסים

תחום ניהול זהויות וגישה של פליקן-טק בונה את תוכנית ארבעת המהלכים שלמעלה עם כלים שלקוחות כבר מחזיקים (Entra ID / Okta / Ping ל-IdP, AWS / Azure / GCP CIEM לגרפי הרשאות ענן, ה-SIEM הקיים ל-ביקורת ברמת פעולה). אנחנו עובדים יחד עם צוות אבטחת הענן שלנו כשגרף ההרשאות חוצה גבולות ענן ו-on-prem, ועם המומחים שלנו ל-SIEM/SOAR כדי לוודא ש-ביקורת ברמת פעולה הופך לזיהוי, לא לאחסון ב-data lake.

אם לתוכנית הזהויות שלכם יש את כל דפוסי היישום של Zero-Trust אבל לא יכולה לענות על שאלת הלפטופ של הקבלן למעלה, זה הפרויקט שצריך להתחיל איתו.