זהויות לא-אנושיות: משטח התקיפה השקט
אתם מכירים את מספר העובדים שלכם. סביר להניח שאינכם מכירים את מספר הזהויות הלא-אנושיות שלכם.
רוב החברות מתמקדות בהגנה על אנשים. אתם משתמשים ב-SSO וב-MFA כדי לאבטח משתמשים אנושיים. זה עובד. קשה יותר לפרוץ לחשבונות אנושיים כיום.
בעוד שאתם מגנים על בני אדם, הזהויות המכניות גדלות. Service principals, workload identities ותפקידי AI עולים כעת על מספר בני האדם פי 10 עד 50.
הזהויות הללו אינן מופיעות במערכות HR. הן אינן מופיעות בתרשימי ארגון. ובכל זאת, לעיתים קרובות הן מחזיקות ברמת הגישה הגבוהה ביותר בענן שלכם.
אזורים בסיכון גבוה כוללים: • אפליקציות OAuth עם גישה רחבה ל-Slack או Salesforce. • Service principals ו-managed identities. • זהויות של CI/CD pipeline. • תפקידי AI service.
תוקפים מחפשים את הנתיב הקל. מכיוון שחשבונות אנושיים מאובטחים, הם מכוונים למכונות. מכונות סובלות משלוש בעיות עיקריות: • Privilege Creep: הרשאות נשארות פעילות זמן רב לאחר שהן נדרשות. • חוסר נראות (Visibility): אין לכם רשימה של תפקידי שירות פעילים או הרשאות OAuth. • Credentials בעלי חיי חיים ארוכים: מפתחות סטטיים יוצרים "דלתות אחוריות" קבועות.
עליכם להתייחס לזהויות מכניות כעדיפות עליונה.
פעלו לפי הצעדים הבאים כדי לאבטח אותן: • השתמשו ב-Workload Identity Federation. החליפו מפתחות סטטיים בטוקנים (tokens) בעלי חיי חיים קצרים באמצעות OIDC. • נתחו ונטרו באופן קבוע. השתמשו בכלים כמו AWS IAM Access Analyzer כדי למצוא התנהגות חריגה. • אוטומציה של עקרון ה-least privilege. הסירו הרשאות שאינן בשימוש באופן אוטומטי. • ניהול (Govern) של זהויות AI. בצעו מיפוי (Inventory) של כל תפקיד AI service כבר מההתחלה.
האבטחה עברה מרשתות לנקודות קצה (endpoints) ולאנשים. השלב הבא הוא זהויות לא-אנושיות.
בעידן של סוכני AI, תוקפים לא צריכים לפרוץ לעובד. הם רק צריכים טוקן אחד.
הזהות היא הפרימטר (perimeter) החדש שלכם. לעיתים קרובות, הזהות הזו אינה אנושית.
מקור: https://dev.to/alifunk/non-human-identities-the-silent-attack-surface-no-one-is-monitoring-45ie
קהילת למידה אופציונלית: https://t.me/GyaanSetuAi