פרקטיקות למניעת דליפת מידע סודי

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

1. בזמנים בהם האפליקציה אותה אנו מפתחים נמצאת בשלב הפיתוח / הבדיקות / ה- builds, יש להריץ כלי SAST כמו SonarQube או GitLab security כדי לאתר מקומות בהם סיסמאות או מידע רגיש נמצאים hard-coded (ואולי אפילו לא מוצפנים).
   חשוב גם לזכור שאיתור מוקדם (בשלב הפיתוח) חוסך כסף רב ומונע אובדן מוניטין (בהשוואה למצב שבו צריך לתקן זאת ב- production כאשר משתמשים אמיתיים נפגעים מכך, במקביל לכך שהנתונים ועצם הטעות חשופים לעין כל). לכן כדאי להכניס את בדיקות ה- security כחלק מתהליך ה- CI/CD ובאופן אוטומטי
   
2. הסיסמאות היו אמורות להיות מוצפנות כמובן. אבל יותר מכך – בסביבת production מומלץ להשתמש בכלים כמו HashiCorp Vault ולא לאחסן מידע סודי בקוד עצמו או בשרת (אפילו שהוא מוצפן) – אלא לבצע הזדהות (אותנטיקציה) מתוך הקוד/ האפליקציה אל מול כספת מרכזית מאובטחת שתכריע (בזמן אמת ובמהירות) האם לתת גישה למשתמש / ל- service או למכונה – או לא לתת גישה.

באופן כללי יותר – ישנן פרקטיקות נוספות כדי למנוע מצבים דומים:

1. למנוע מצב שבו קבצים סודיים או כאלה המחזיקים מידע סודי, יכנסו בטעות ל- repo דרך חוקים מוגדרים מראש (כגון push rules המגיעים בדרך כלל מכיוון כלי ה- version control כגון GitLab / GitHub / Bitbucket)
2. ב- GitLab CI ניתן להגדיר משתני סביבה שיחזיקו סיסמאות בכדי לא לשמור את הסיסמאות בתוך קבצי קונפיגורציה. בנוסף, ניתן להגדיר את המשתנים כ-masked, ואז אי אפשר יהיה לראות את תוכנם בקבצי הלוגים של הריצות (jobs).
3. הרצת Dynamic Application Security Testing (בדיקות אבטחה דינאמיות – DAST ) על אתר או אפליקציית web , בזמן ריצה, בכדי לנטרל איומים כמו XSS או פרצות אבטחה שמאפשרות לאנשים לא מורשים להכנס למערכת
4. מחיקת CI/CD pipeline אם אין יותר צורך במידע שבו – כגון קבצי logs (וזאת בכדי למנוע מצב שהיה בו מידע רגיש שיהיה נגיש בעתיד)
5. אבטחת / הקשחת pipelines באופן כללי – לא לתת גישה לכל המשתמשים אל כלי ה- CI/CD . להגדיר באילו branches יורץ ה- CI/CD ועוד.
6. במידה ומשתמשים ב- containers ו/או Kubernetes: חשוב לספק הגנה על קונטיינרים והרצת בדיקה סטטית על תוכנם ע"מ למצוא vulnerabilities – בפרט אם המערכת מסתמכת על קונטיינרים ציבוריים חיצוניים שנבנו מחוץ לחברה (לרוב מבוססי Docker)
7. בדיקת קוד פתוח שמסתמכים עליו וכן ה- dependencies עליו הוא נסמך, ובאופן שוטף (מומלץ כחלק מה- CI/CD ). ישנם מספר כלים המתמחים בנושא זה.
8. עובדים עם תשתית בענן?
   כדאי לוודא שמסדי נתונים ו- Object store כגון S3 לא חשופים לעולם. נושא זה ניראה אולי טריוולי אבל זו נקודה שחברות מפספסות שוב ושוב. בשום שלב אין צורך שמסד הנתונים יהיה חשוף ישירות לגישה מחוץ לארגון. כנ"ל בנוגע ל- Storage : כל הגישה מבחוץ צריכה להיות דרך API שגם הוא חייב להיות מאובטח עם הרשאות לכל סוג קריאה. נושאים אלו רלוונטים גם למקרה של PayBox וגם למקרה של הדליפה של מאגר הבוחרים.
9. כדאי לוודא שגישה ע"י משתמשים מאובטחת ב- 2FA. נושא זה מקטין מאוד את הסיכוי לפריצה גם כאשר הסיסמא ידועה. במידה ויש צורך לחשוף API (בין אם של ה Cloud provider ובין אם של המערכת) לצריכה ע"י שירותים אחרים יש לוודא שימוש  ב- Tokens שמוחלפים באופן תדיר (גם עבור גישה מתוך הארגון -למשל עבור תהליכי CI).
10. ניהול הרשאות בקבוצות ומידור: יש צורך לייצר קבוצות משתמשים לפי רמות הרשאה. יש להבדיל בין גישה לסביבות של production לבין סביבות אחרות כגון Dev ו- QA. יש להמנע ככל האפשר מלתת הרשאות גורפות גם ברמה התשתית (גישה ל- DB, STORAGE וכ"ו) וגם ברמה האפליקטיבית (אילו נתונים המשתמש יכול לראות)
11. יש להתייחס לכל המידע בכל מקום: לוגים, Monitoring, גיבויים וכיו"ב. בכל מקום שאוספים מידע יש לוודא שהוא מוגן. יש לקחת בחשבון ספקים חיצוניים ולוודא מה רמת האבטחה שהם מספקים. קל לפספס את הנושאים האלו כאשר מתרכזים מאוד במסדי נתונים והאפליקציה.
12. מומלץ לשכור חברות שינסו לפרוץ באופן אקטיבי ויבצעו penetration tests. דרך זו תאפשר לגלות חורים במקומות לא טריוואלים לפני פריצה זדונית.
13. הטמעה של כלים אוטומטיים שיעקבו אחרי הפעילות השוטפת וישלחו התראות כאשר יש שימוש יוצא דופן ואנומליות. כלים אלו אולי לא ימנעו את הפרצה אבל יכולים למנוע את גודל הנזק ולהקטין את משך הזמן שבו הארגון חשוף.

קישורים רלבנטים:

• אתר מידע על Vault בעברית
• הסבר על גישת Quality Gates של SonarQube
• הסבר על Vault (וידאו)
• כתבה על התקלה ב- PayBox (מתוך אתר TheMarker) (נגרמה עקב מעבר לשרת production אחר וזה נעשה בצורה שגויה ולא מאובטחת)
• אתר אלקטור גרם לדליפה מידע על כל בעלי זכות הבחירה בארץ (כתבה בערוץ 12)
• אתר מידע על GitLab בעברית