סיפור לקוח: אבטחת מידע בארגון מבוזר ומדוע בחרו ב- Akeyless
העלנו על הכתב (ותרגמנו) סיפור לקוח מעניין, המסופר מנקודת מבט של ה- CISO ומנהל קבוצת אבטחת המידע בחברת Crum & Forster (חברת ביטוח מארה"ב עם כ- 3000 עובדים).
במפגש הוא סיפר על אבטחת מידע מרכזית בארגון מבוזר (עם 37 משרדים ועבודה מהבית),
מדוע חשוב להשתמש ב- Secrets Management כשעוברים לענן,
ומדוע בחרו בפתרון ניהול הסודות של Akeyless.
המפגש איתו היה במסגרת כנס KeyConf שהיה בארה"ב בדצמבר 2021,
ובו הוא סיפר על גישת העבודה שלהם מול הלקוחות שלהם בארגון והסביר מדוע בחרו ב- Akeyless ומדוע הם מרוצים מפתרון זה.
הקלטת המפגש כאן בסוף המאמר.
תרגום:
שמי הוא Chris Holden. אני ה-CISO של Crum & Forster, ואני רוצה לדבר קצת על אבטחה מרכזית (Centralized) בארגון מבוזר – ולמעשה הדרך שבה אני ניגש או שאנחנו ניגשים לאבטחת סייבר באופן פנימי ובונים אותו עבור החברה שלנו, שהיא מאוד מבוזרת.
אז קצת עלי: אני ה-CISO ב-Crum & Forster, כפי שציינתי. אני עוסק באבטחת סייבר בערך 10 שנים פלוס.
מילאתי תפקידים רבים לאורך כל הדרך מזיהוי פורנזי/ פלילי, תגובה לאירועים, לבדיקות חדירה, בדיקות אבטחת יישומים ופיתוח תוכניות סייבר, הן פנימית והן ביכולות הייעוץ לאורך השנים. אני גר בצפון מדינת ניו יורק עם משפחתי. התחביבים שלי הם נגרות ולהיות handyman .
על חברת Crum & Forster
Crum & Forster היא חברת פתרונות ביטוח רכוש ותאונות נפגעים מובילה בשוק ובריאות ומומחיות. אנחנו מוכרים פרמיות ביטוח בהיקף של כ- 3.1 מליארד דולר בשנה. יש לנו כ-3000 עובדים, ואנחנו מגייסים באופן פעיל להרבה תפקידים. גדלנו משמעותית בשנתיים האחרונות מאז שהייתי שם. ויש לנו כ-37 משרדים ברחבי ארה"ב ומדיניות עבודה מרחוק מלאה, כך שיש לנו כ 2500 משרדים בערך , בפועל.
כפי שניתן לראות כאן מהשקופית הזו, יש לנו מספר יחידות עסקיות. וזה הולך להיות נושא מרכזי למה שאנחנו הולכים לדבר עליו עוד מעט. השנה החברה קיימת בדיוק 200 שנה. ה-IT קיים בחברה כבר קצת יותר מ-20 שנה. ואבטחת סייבר התחילה 6 חודשים לפני שהצטרפתי לחברה לפני 4 שנים. אז, בסך הכל, הכל חדש יחסית, בנוי על תוכנית אבטחת סייבר, ואנחנו מחליפים פתרונות legacy בדברים חדשים יותר.
על תפקידו כ- CISO בחברה
בתור CISO יש לי 7 מהנדסים במשרה מלאה תחתיי, 2 מהם מתמקדים בענן ואבטחת יישומים. ויש לי 2 עמדות פתוחות, פוטנציאליות 3 בקרוב. זה יהיה עבור הצוות שלי.
כפי שציינתי קודם לכן, אנו מפעילים 6 תשתיות ארגוניות שונות ונבדלות. אמנם העסק שלנו מרוכז וביטוחי, אבל אנחנו נותנים ליחידות העסקיות לפעול בצורה אוטונומית כדי לעורר יצירתיות ותחרות בין היחידות העסקיות השונות (מבחינה עסקית). אז מה שזה אומר עבורנו מנקודת מבט טכנית הוא שכולנו מרובי עננים ולכל יחידה עסקית יש צוותי פיתוח משלה, ארכיטקטורה משלה. אז, אנחנו מבינים שאנחנו חווים את מה שהוזכר מקודם – התפשטות של הסודות (Sprawl).
שינוי גישת העבודה מול הלקוחות שלנו
מה שגילינו במהלך השנים של הוספת אבטחה לחברה, זה שאנחנו לא יכולים לדחוף בכח Security לעובדי החברה – זה צריך להגיע ביוזמתם ולהמשך ("Pull") על ידי היחידות העסקיות. הדרך שבחרנו לעשות זאת היא באמצעות "שגרירים" מכל צוות, והם אנשי הקשר הישירים שלנו עבור הצוות. ככה ריכזנו את התקשורת מול הצוותים. כל יחידה עסקית הקצתה חבר צוות מטעמה לענייני Security – ואנחנו עובדים מולו.
מדיניות חדשה ("Vendor-less")
התחלנו גם ליישם מדיניות "ללא ספקים". בהתחלה, הגישה שלנו היתה "אנחנו הולכים לצאת ברכש. אנחנו הולכים לקנות את פתרון האבטחה המסויים הבא, ואתם הולכים להשתמש בו".
אבל אף אחד לא רוצה שיגידו לו מה לעשות. אנשים רוצים לקבל מידע, והם יכולים לעזור לבנות את התוכנית, את ההליך ליישם את הטכנולוגיה, הם הרבה יותר מוכנים לאמץ. ההחזר על ההשקעה שלך הרבה יותר מהיר. וקבלה כללית הרבה יותר קלה לעבור.
אז עזבנו את הגישה הזו, ומה שהתחלנו לעשות היה לעבוד ללא בחירת ספק הפתרון מראש, והתחלנו גם להציע פתרון מרכזי (centralized) יחד עם זה.
אם למשל היינו צריכים Web application Firewall , היינו אומרים, "אוקיי, אתה צריך WAF. זה צריך לעמוד בקריטריונים הבאים. אתה צריך לעבוד עם הממשלה ולעמוד ב- compliance בכל רבעון, חודש, שנה וכד', ואתה יכול להשתמש בכל פתרון שאתה רוצה. אבל יש לנו גם הצעה בשבילך עם פתרון שלא תצטרך לצאת ולקנות, לא תצטרך להתעסק עם הקונפיגורציה שלו ולא תצטרך להתעסק עם הניטור שלו".
אז מה שמצאנו במהלך השנים הוא שהיה לנו רק מקרה אחד שבו מישהו אומר, "טוב, אני הולך לפי הפתרון שלי" – זה נמשך 3 חודשים שהוא ניסה את הגישה שלו, ואז הוא חזר בו ועבר לפתרון שלנו.
חלק גדול נוסף שהניע את האפקטיביות הזו הוא הדרך שבה התחלנו לבנות את ה- POC כשחיפשנו טכנולוגיה חדשה להשתמש בה: צירפנו את כל בעלי העניין כבר מההתחלה ונתנו להם מידע שיעזור להם מההתחלה.
זה עזר ב-2 היבטים שונים:
- זה נתן להם בעלות על המוצר.
- בהיותנו בתחום האבטחה, אנחנו לא מפתחים. אנחנו לא אלה שישתמש בטכנולוגיה ביומיום ויתפעלו אותה. אנחנו לא היחידות העסקיות. יש ניואנסים של איך הם עובדים ומה הם צריכים כדי לבצע את העבודה שלהם – ורק הם מכירים אותה. אני אולי חושב שהם צריכים את הכלי הזה, אבל אני לא מכיר מספיק את הניואנסים של היום-יום שלהם כדי ליישם את זה באמת. לכן, מעורבותם מההתחלה הייתה משימה הכרחית לחלוטין כדי להניע את הדליברי של זה בזמן.
ואז כבר ציינתי שאנחנו מספקים להם חופש בחירה עסקי, שבסופו של דבר חוזרים לפתרון האבטחה 9 פעמים מתוך 10, או 10 פעמים מתוך 10 עכשיו, אני צריך לומר.
אז כפי שציינתי, אנחנו חברה בת 200 שנה, וה- IT קיים בה 20 שנה. כשאני הצטרפתי לחברה לפני 4 שנים, הכל היה מורכב מהרבה מערכות legacy ישנות, עם data centers שלנו (on-premises) ובלי מערכות בענן כלל. מאז שהצטרפתי זה השתנה במהירות, והגביר את הצורך בניהול סודות. ניהול סודות תמיד היה נושא שמצריך טיפול אצלנו – הוא פשוט הצריך גישה שונה עד שעברנו לענן, וגם הפתרון הצריך התעסקות ב- scale גדול יותר מאז שעברנו לענן.
לפני שהלכנו לענן, עדיין היינו צריכים לשמור על מפתחות הצפנה עבור שרתי databases ומערכות on-premises ,
ונתקלנו פעמים רבות במצבים שההסיסמאות ממש כתובות hard-coded בקוד או בקבצי קונפיגורציה, שזו לא דרך מאובטחת כמובן.
אבל אז הכל עדיין היה on-prem, וחשבנו "יש לנו firewall והרשתות הפנימיות שלנו בטוחות, אז הכל בסדר".
ואז התחלנו לעבור בפתאומיות לענן. וכתוצאה מכך היתה לנו התפזרות סודות (secret sprawl) בענן: מאות חשבונות ארגוניים שונים, התלויים בכל ספקי הענן: AWS, Azure, GCP , והכל עבור אפליקציה אחת. ומפתחות הגישה מאוחסנים על המחשבים האישיים של המפתחים!
זה הפך לבעיה מסיבית שלא ניתנת לשליטה, ללא דרך מרכזית לבטל את המפתחות האלה במקרה שמשהו רע יקרה.
כפי שציינתי קודם, ביליתי הרבה זמן בפורניזקה, זיהוי פלילי ובתגובה לאירועים במהלך הקריירה שלי. התגובה לאירוע היא בראש מעייניי, ולכן ביטול המפתחות הוא עניין סופר חשוב. אני רוצה לעשות את החיים שלי קלים ככל האפשר כשהדברים משתבשים.
אז מה האפשרויות שלנו עכשיו לניהול סודות? זיהינו את הצורך לנהל סודות לפני שעוברים לענן. לפני כשנתיים, התחלנו לבדוק ולהקים פרויקט באופן רשמי, התחלנו לצאת ולחפש מה עומד לרשותנו בעולם ניהול הסודות. הבנו שאנחנו צריכים משהו עבור שיפקח על גישה machine-to-machine, שיהיה יותר מרכזי וטוב יותר ממה שהיה לנו.
אז מה היו האפשרויות שלנו בכל הנוגע לניהול הסודות? התחלנו להסתכל על החברות הותיקות שמציעות פתרונות Privilege Access Management . והן אכן מציעות פתרונות לניהול סודות, אבל הם עדיין נקטו בגישה שממוקדת בגישה לאנשים (ולא מכונות) – התחברות, כניסה, יציאה וגישה למידע מסויים. זה היה נהדר עבור משתמשים אדמיניסטרטיביים קלאסיים, אבל לא ממש התאים ל- use cases שבאמת היינו צריכים לעבודה השוטפת כ- DevOps. אז זה לא באמת יעבוד עבורנו. לא מצאנו פתרון טוב מצד הכלים הותיקים מסוג זה.
מה שעשינו אז זה להתחיל לבדוק את ספקי הענן ואת פתרונות ה – KMS שלהם, שהיו ללא ספק טובים מאוד.
אבל מגיעים עם סט מוגבל מאוד של use cases שעבורם יש פתרון.
הם גם מתמקדים רק ב-API לסודות סטטיים (Static Secrets). והניהול היה ברמת ה- account, בצורה שלא ניתן לספק כך פתרון מרכזי עבור ארגון שלם (מה שהיה עבורנו חשוב מאוד). אז הבנו שזה לא מתאים לנו, במיוחד כשהתחלנו ללכת לסביבות ענן היברידיות ו- multi-tenancy עבור האפליקציות שלנו. ראינו שלא ניתן לגדול בצורה זו.
האם פתרון קוד פתוח בהכרח מתאים לנו ?
אז התחלנו להסתכל על פריסה עצמית של קוד פתוח (HashiCorp Vault). ואחת האמירות האהובות עלי על קוד פתוח היא " קוד פתוח זה בחינם כל עוד אתה לא מעריך את הזמן שלך".
מה שאני מתכוון בכך הוא היכולות ההנדסיות הנדרשות והדרושות כדי לעמוד בפתרונות האלה, להביא אותם לתפעול, לאבטח אותם, לקבל את החוסן הדרוש לנו,
כמו גם השלמות שחייבת להיות מובנה בניהול סודות. ניהול סודות זה נהדר, אבל אם אינך יכול לגשת למפתחות שלך או שהמערכת למטה אז שום דבר לא יעבוד, וזו בעיה גדולה מאוד. לזמינות המערכת חשיבות קריטית בניהול סודות.
אז מצאנו שזה מצריך הרבה התעסקות פיתוחית /הנדסית, ועלות הכוללת על הבעלות של זה (TCO), מנקודת המבט ההנדסית ומנקודת המבט של התשתית, הייתה מאוד גבוהה ולא יכולנו לתמוך בזה. כפי שציינתי קודם, יש לי סה"כ 7 מהנדסים, אין לי זמן שאנשים יתמסרו לתיקון ועדכון ודברים כאלה.
ולכן יש לנו את Akeyless, שמספקת לנו את הטוב מכל העולמות.
על Akeyless
זה פתרון שנבנה באופן מודרני ותומך גם במערכות חדשות וגם במערכות legacy , והוא נותן גם תמיכה היברידית וגם תמיכה ב- multi-cloud .
מה שמאוד שכנע אותנו לבחור בפתרון של Akeyless זה העניין שזה פתרון Software as a service אמיתי – מה שאומר אפס התעסקות בתחזוקה עבורי.
ובנוסף הפתרון גם מציע מודל הצפנה חזק שמונע את הדבר הכי גרוע שיכול לקרות במערכות כאלה – שהמפתחות שלך יפרצו.
הדבר השני הגרוע שיכול לקרות זה שהמערכת תפול ולא תהיה זמינה – וגם את זה Akeyless פותרת בצורה נהדרת.
לסיכום:
גילינו שעלות הפתרון היתה נמוכה משמעותית, ופריסת הפתרון היתה מהירה הרבה יותר, כך שגם אנחנו וגם הלקוחות שלנו בארגון מרוצים מנקודת המבט העסקית – גם החזר השקעה מהיר וגם הפתרון לטווח ארוך שחיפשנו.
