מבט על הבנת שלטון זהות לא-אנושית

האם ניתן לקיים זהות בלתי מתייחסת לזהות אחרת? איך נדע?

זה עשוי להראות קצת פילוסופי למאמר טכנולוגי בתחום האבטחה, אך זהו נקודה חשובה לשמור עליה בעת התמודדות עם נושא זהויות לא-אנושיות. שאלה טובה יותר בנוגע לאבטחה בעצם הייתה, "האם זהות צריכה לקיים אם אי אפשר להתקשר איתה?" יתכן שלא נוכל להגיע למענה על שאלה זו בראשונה, מאחר שהוכחת טבע המציאות היא מעט מחוץ לתחום המדעי של מדעי המחשב. עם זאת, הרבה אנשים עבדו קשה בבניית כלים למנהליות NHI כדי לקבוע אם זהות מכונה קיימת, מדוע היא קיימת, ולענות על השאלה האם היא צריכה לקיים.

עתיד הפיכת אבטחת הסודות לארגן דרכים מתוך הבנת מחזור החיים והתלויות האחת בשניה של הזהויות לא-אנושיות שנסמכות על סודות. אך מדוע כעת? בואו נשיב אחורה ונבחן מחדש כמה מההנחיות שלנו בנוגע ל-NHI והקיומם.

מהן זהויות לא-אנושיות?

לפני שנמשיך, בואו נגדיר NHI בהקשר של השיחה הזו.

In the simplest terms, a non-human identity, also commonly referred to as a machine identity or a workload identity, is any entity that is not human and can perform an action within your system, most commonly interacting exclusively with other non-humans.

זה עשוי להיות כמו גרסת Kubernetes שצריכה להתקשר עם מקור נתונים ולשלוח את הנתונים שעובדו למערכת דיווחים. זה עשוי להיות חיישן של אינטרנט הדברים (IoT) שמזין נתונים לשרת מרכזי. זה עשוי להיות צ'אטבוט בשירות Slack. אם אין צורך בקלט אנושי ישיר לאחר יצירה ראשונית כדי לבצע את העבודה, אז צריך לשקול את הזהות כ'לא-אנושית'.

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

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

כל NHIs מתחברות למערכות אחרות

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

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

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

כל NHIs מאובטחים חייבים שיהיה להם סוד

כדי להקים תקשורת מהימנה בין שני NHIs, חייב להיות סוד ייחודי, כמו מפתח API, טוקן או תעודה, כדי שהיישויות הללו יוכלו לאמת את עצמן. אנחנו יכולים להשתמש בסוד כדי להוכיח את זהותו של NHI ולמפות אותו באקוסיסטם. השאלה היא, היכן אנחנו מחפשים את הסודות הללו?

בעסק המודרני, במיוחד הגדולים יותר, יש בעצם רק שני מקומות שבהם סוד יכול להתקיים. האפשרות הראשונה שלך היא השיטה הטובה ביותר והכי בטוחה: מערכת ניהול סודות, כמו CyberArk's Conjur, Vault של HashiCorp, או AWS Secrets Manager. האפשרות השנייה הרבה פחות בטוחה אך, למרבה הצער, נפוצה מדי: מחוץ לארנק, בקוד, או בהגדרה בטקסט ברור.

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

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

לכל סוד של NHI יש סיפור מקור

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

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

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

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

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

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

גם, דבר מדאיג הוא שכאשר סוד חורג או פוגע בפרטיות, צוות לא יכול להחליפו עד שהם מבינים ראשית איך ההרשאות הוגדרו. לדוגמה, נניח שאתה יודע שסוד של שירות מעורב שקריטי למשימה נדחה בטעות למאגר הקוד הפומבי של GitHub. במקרה כזה, רק זמן יגרום לגילוי ושימוש על ידי מישהו מחוץ לארגון שלך. בדו"ח האחרון שלנו של קול המנהל, קובעי ההחלטות ב-IT הודו שלקח, בממוצע, 27 ימים לסובב את הסודות הקריטיים האלה. צוותים צריכים להיות מסוגלים לפעול בשניות או דקות, לא בימים.

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

כל הסודות NHI צריכים להיות מסובבים

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

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

אבל מה לגבי סודות ה-NHI שחיים מחוץ לכספות הללו, או אולי אותו סוד שמפוזר על פני מספר כספות? פלטפורמת סריקות סודות טובה צריכה אינטגרציה חלקה עם הכספות הללו כדי שהצוות שלך יוכל למצוא בקלות רבה יותר ולאחסן את הסודות הללו בבטחה במנהל הסודות ולהכין את הדרך לסיבוב אוטומטי. יישום ההתייחסות של GitGuardian עם Conjur של CyberArk נכנס לפרטים נוספים על איך אתה יכול לאוטומט את כל תהליך האחסון והסיבוב.

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

כל NHIs יהיו סיום

NHIs, דומים לעמיתיהם האנושיים, יש מחזורי חיים סופיים. ניתן לפנות להם כאשר שירות נכנס לפרישה, מוחלף, או כאשר לא נדרש יותר. ללא טיפול בהשבת וניקיון של NHIs כדי למנוע את התמדתם של סודות שלא נמצאים בשימוש או חיבורים מיושנים, אנו יוצרים נקודות עיוורון באבטחה. אך איך אנו יודעים מתי אנו בסופה של הדרך עבור NHI, במיוחד אם הסוד שלו עדיין תקף?

אחד התשובות היא שהוא לא צריך עוד לקיים כאשר NHI לא מתחבר עוד למערכת פעילה אחרת. זהו מבטיח שפוגעים לא יכולים לנצל סודות NHI לא פעילים כדי לקבל קרס בסביבתך. זכור כי פוגעים לא מקפידים כיצד יש להשתמש בסוד באופן נכון; הם רק מקפידים על מה שהם יכולים לעשות עם זה.

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

הבנת העולם סביב ה-NHIs שלך חיונית לאבטחה

ב-2022, מחקר של CyberArk הראה כי בסביבה כלשהי, לכל זהות אנושית יש צורך לנהל לפחות 45 זהויות לא-אנושיות. היחס הזה היום כנראה קרוב יותר ל-1 ל-100 והוא עולה מתמיד. הזמן הטוב ביותר להתמודד עם ממשלת NHI שלך וניהול מחזור החיים שלה היה לפני שנים. הזמן הבא הכי טוב הוא עכשיו.

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

אף על פי שזהויות המכונה גוברות על פני בני אדם, אין סיבה לעבוד לבד כדי לפתור את הבעיה הזו; אנו כולנו יחד בזה.