זהות היא הפרימטר החדש: 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 בלי כל אלה, ואפשר לקבל את כולם ולא להיות בתאימות ל-Zero-Trust.

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

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

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

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

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

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

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

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

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

• עבודה רגילה: SSO, MFA, modern auth דרוש. browser session יכול להישאר ליום עבודה.
• מערכות רגישות (cloud production admin, מערכות פיננסיות, source code עם secrets, customer data plane): SSO, MFA מבוסס hardware, managed-device attestation, אימות טרי כל 4–8 שעות, ללא impossible-travel.
• פעולות בעלות אמון מירבי (פריסת פרודקשן, שינויי IAM policy, key rotations, data export מעל סף): step-up auth מפורש בפעולה, נדרשת הצדקה, מתועד ב-audit stream בלתי-נמחק.

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

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

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

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

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

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

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

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

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

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

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

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

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

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