המסמך הזה הוא חלק מהסדרה Google Cloud Well-Architected Framework: נקודת המבט של שירותים פיננסיים (FS), והוא מספק סקירה כללית של העקרונות וההמלצות לעמידה בדרישות האבטחה, הפרטיות והתאימות של עומסי עבודה של שירותים פיננסיים (FS) ב- Google Cloud. ההמלצות עוזרות לכם לבנות תשתית עמידה שתואמת לדרישות, להגן על מידע רגיש, לשמור על אמון הלקוחות, להתמודד עם הדרישות הרגולטוריות המורכבות ולנהל ביעילות את איומי הסייבר. ההמלצות במסמך הזה תואמות לעקרונות האבטחה של Well-Architected Framework.
אבטחה במחשוב ענן היא נושא קריטי לארגונים בתחום השירותים הפיננסיים, שמושכים מאוד פושעי סייבר בגלל הכמויות העצומות של מידע רגיש שהם מנהלים, כולל פרטי לקוחות ורשומות פיננסיות. ההשלכות של פרצת אבטחה הן חמורות במיוחד, כולל הפסדים כספיים משמעותיים, פגיעה במוניטין לטווח ארוך וקנסות רגולטוריים משמעותיים. לכן, עומסי עבודה של שירותים פיננסיים דורשים אמצעי בקרה מחמירים לאבטחה.
כדי להבטיח אבטחה מקיפה ועמידה בדרישות, חשוב להבין את האחריות המשותפת שלכם (ארגונים בתחום השירותים הפיננסיים) ושל Google Cloud. Google Cloud אחראית לאבטחת התשתית הבסיסית, כולל אבטחה פיזית ואבטחת רשת. אתם אחראים לאבטחת הנתונים והאפליקציות, להגדרת בקרת הגישה ולהגדרה ולניהול של שירותי האבטחה. כדי לתמוך במאמצי האבטחה שלכם, Google Cloud סביבת השותפים מציעה שילוב אבטחה ושירותים מנוהלים.
המלצות האבטחה במסמך הזה ממופות לעקרונות הליבה הבאים:
- הטמעת אבטחה משלב התכנון (Security by design)
- הטמעה של מודל אבטחה של אפס אמון
- הטמעת אבטחה בגישת Shift-Left
- הטמעת הגנת סייבר מונעת
- שימוש ב-AI באופן מאובטח ואחראי, ושימוש ב-AI למטרות אבטחה
- עמידה בדרישות הרגולטוריות, בדרישות התאימות ובדרישות הפרטיות
- תעדוף של יוזמות אבטחה
הטמעת אבטחה משלב התכנון (security-by-design)
תקנות פיננסיות כמו תקן אבטחת הנתונים המקובל בתעשיית כרטיסי תשלום (PCI DSS), חוק Gramm-Leach-Bliley (GLBA) בארצות הברית וחוקים לאומיים שונים להגנה על נתונים פיננסיים, מחייבים לשלב אבטחה במערכות כבר מההתחלה. העיקרון של אבטחה כבר בשלב התכנון מדגיש את השילוב של אבטחה לאורך כל מחזור החיים של הפיתוח, כדי לצמצם את נקודות החולשה כבר מההתחלה.
כדי ליישם את העיקרון "אבטחה כחלק מהתכנון" בעומסי העבודה של FS ב-Google Cloud, כדאי להביא בחשבון את ההמלצות הבאות:
- כדי לוודא שאתם נותנים רק את ההרשאות שצריך, כדאי להשתמש בעיקרון של הרשאות מינימליות באמצעות בקרת גישה מבוססת-תפקיד (RBAC) בניהול זהויות והרשאות גישה (IAM). השימוש ב-RBAC הוא דרישה מרכזית בהרבה תקנות פיננסיות.
- אכיפת היקפי אבטחה סביב השירותים והנתונים הרגישים שלכם ב- Google Cloud באמצעות VPC Service Controls. היקפי האבטחה עוזרים לפלח ולהגן על נתונים ומשאבים רגישים, ולמנוע זליגת נתונים וגישה לא מורשית, כפי שנדרש בתקנות.
- להגדיר את הגדרות האבטחה כקוד באמצעות כלים של תשתית כקוד (IaC) כמו Terraform. בגישה הזו, אמצעי הבקרה לאבטחה מוטמעים כבר בשלב הפריסה הראשוני, מה שעוזר להבטיח עקביות ויכולת ביקורת.
- סורקים את קוד האפליקציה על ידי שילוב של בדיקת אבטחת אפליקציות סטטית (SAST) בצינור עיבוד הנתונים של CI/CD באמצעות Cloud Build. הגדירו שערי אבטחה אוטומטיים כדי למנוע פריסה של קוד שלא עומד בדרישות.
- לספק ממשק מאוחד לתובנות בנושא אבטחה באמצעות Security Command Center. השימוש ב-Security Command Center מאפשר מעקב רציף וזיהוי מוקדם של הגדרות שגויות או איומים שעלולים להוביל להפרות רגולטוריות. כדי לעמוד בדרישות של תקנים כמו ISO 27001 ו-NIST 800-53, אתם יכולים להשתמש בתבניות של ניהול מצב האבטחה.
- עוקבים אחרי הירידה במספר נקודות החולשה שמזוהות בפריסות בסביבת הייצור, ואחרי אחוז הפריסות של IaC שעומדות בשיטות המומלצות לאבטחה. אתם יכולים להשתמש ב-Security Command Center כדי לזהות נקודות חולשה ולראות מידע על תאימות לתקני אבטחה. מידע נוסף זמין במאמר ממצאי פגיעויות.
הטמעה של מודל אבטחה של אפס אמון
התקנות הפיננסיות המודרניות מדגישות יותר ויותר את הצורך באמצעי בקרה מחמירים על הגישה ובאימות מתמשך. הדרישות האלה משקפות את העיקרון של מודל אבטחה של אפס אמון, שמטרתו להגן על עומסי העבודה מפני איומים וגורמים זדוניים פנימיים וחיצוניים. העיקרון של מודל אבטחה של אפס אמון דוגל באימות רציף של כל משתמש ומכשיר, מה שמבטל את האמון המשתמע ומפחית את הסיכון לתנועה רוחבית.
כדי להטמיע את המודל, כדאי לפעול לפי ההמלצות הבאות:
- כדי להפעיל בקרת גישה מבוססת-הקשר על סמך זהות המשתמש, אבטחת המכשיר, המיקום וגורמים אחרים, משלבים את אמצעי הבקרה של IAM עם Chrome Enterprise Premium. כך אפשר לוודא שהאימות מתבצע באופן רציף לפני שניתנת גישה לנתונים ולמערכות הפיננסיות.
- כדי לספק ניהול זהויות והרשאות גישה מאובטח וניתן להתאמה, צריך להגדיר את Identity Platform (או את ספק הזהויות החיצוני אם משתמשים באיחוד שירותי אימות הזהות של כוח העבודה). להגדיר אימות רב-שלבי (MFA) ואמצעי בקרה אחרים שחיוניים להטמעת מודל אבטחה של אפס אמון, ולעזור להבטיח עמידה בתקנות.
- הטמיעו אימות רב-שלבי בכל חשבונות המשתמשים, במיוחד בחשבונות עם גישה לנתונים או למערכות רגישים.
- תמיכה בביקורות ובחקירות שקשורות לעמידה בתקנות, באמצעות רישום מקיף ביומן ומעקב אחרי גישת המשתמשים והפעילות ברשת.
- להפעיל תקשורת פרטית ומאובטחת בין שירותים ב-Google Cloud ובסביבות מקומיות, בלי לחשוף את התנועה לאינטרנט הציבורי, באמצעות Private Service Connect.
- הטמיעו אמצעי בקרה פרטניים לזהויות ותנו הרשאת גישה ברמת האפליקציה באמצעות שרת proxy לאימות זהויות (IAP), במקום להסתמך על מנגנוני אבטחה שמבוססים על הרשת, כמו מנהרות VPN. הגישה הזו עוזרת לצמצם את התנועה הרוחבית בסביבה.
הטמעת אבטחה מוקדמת (shift-left)
רשויות רגולטוריות בתחום הפיננסי מעודדות נקיטת אמצעי אבטחה יזומים. זיהוי נקודות חולשה וטיפול בהן בשלב מוקדם במחזור החיים של הפיתוח עוזרים לצמצם את הסיכון לאירועי אבטחה ואת האפשרות לקנסות על אי-עמידה בדרישות. העיקרון של אבטחה בהזזה שמאלה (shift-left) מקדם בדיקות אבטחה ושילוב בשלב מוקדם, מה שעוזר להפחית את העלות והמורכבות של התיקון.
כדי להטמיע אבטחה מסוג Shift-Left, כדאי לפעול לפי ההמלצות הבאות:
כדי להבטיח בדיקות אבטחה אוטומטיות בשלב מוקדם בתהליך הפיתוח, משלבים כלי סריקת אבטחה, כמו סריקת נקודות חולשה בקונטיינרים וניתוח קוד סטטי, בצינור עיבוד הנתונים של CI/CD באמצעות Cloud Build.
כדי לוודא שרק פריטי מידע שנוצרו בתהליך הפיתוח (Artifact) מאובטחים נפרסים, משתמשים ב-Artifact Registry, שמספק מאגר מאובטח ומרכזי לחבילות תוכנה ולקובצי אימג' של קונטיינרים עם סריקה משולבת של נקודות חולשה. כדי לצמצם את הסיכון למתקפות של בלבול ביחסי תלות, כדאי להשתמש במאגרים וירטואליים ולתת עדיפות לארטיפקטים הפרטיים על פני מאגרים מרוחקים.
כדי לסרוק באופן אוטומטי אפליקציות אינטרנט ולחפש נקודות חולשה נפוצות, משלבים את Web Security Scanner (חלק מ-Security Command Center) בצינורות עיבוד הנתונים לפיתוח.
הטמיעו בדיקות אבטחה של קוד המקור, תהליך ה-build ומקור הקוד באמצעות מסגרת Supply-chain Levels for Software Artifacts (SLSA). אוכפים את המקור של עומסי העבודה שפועלים בסביבות שלכם באמצעות פתרונות כמו Binary Authorization. כדי לוודא שעומסי העבודה משתמשים רק בספריות מאומתות של תוכנות בקוד פתוח, משתמשים ב-Assured Open Source Software.
עוקבים אחרי מספר נקודות החולשה שזוהו ותוקנו במחזור החיים של הפיתוח, אחוז פריסות הקוד שעוברות סריקות אבטחה והירידה באירועי האבטחה שנגרמו בגלל נקודות חולשה בתוכנה. ב- Google Cloud יש כלים שעוזרים לעקוב אחרי סוגים שונים של עומסי עבודה. לדוגמה, לעומסי עבודה בקונטיינרים, השתמשו בתכונה של סריקת קונטיינרים ב-Artifact Registry.
הטמעת הגנת סייבר מונעת
מוסדות פיננסיים הם יעד מרכזי למתקפות סייבר מתוחכמות. בדרך כלל, התקנות דורשות מודיעין איומי סייבר חזק ומנגנוני הגנה פרואקטיביים. הגנת סייבר מונעת מתמקדת בזיהוי איומים ובתגובה אליהם באופן יזום, באמצעות ניתוח מתקדם ואוטומציה.
כדאי לשקול את ההמלצות הבאות:
- זיהוי איומים פוטנציאליים וצמצום שלהם באופן יזום, באמצעות שירותי מודיעין איומי סייבר, תגובה לאירוע ואימות אבטחה של Mandiant.
- להגן על אפליקציות אינטרנט וממשקי API מפני ניצול לרעה של פרצות אבטחה באינטרנט ומתקפות DDoS בקצה הרשת באמצעות Google Cloud Armor.
- צוותי האבטחה יכולים להשתמש ב-Security Command Center כדי לצבור ממצאים והמלצות בנושא אבטחה, לתעדף אותם ולטפל באופן יזום בסיכונים פוטנציאליים.
- כדי לוודא שההגנות המונעות ותוכניות התגובה לאירועים פועלות כמו שצריך, כדאי לבצע סימולציות אבטחה ובדיקות חדירה באופן קבוע.
- מודדים את הזמן שלוקח לזהות אירועי אבטחה ולהגיב להם, את היעילות של המאמצים להפחתת מתקפות DDoS ואת מספר מתקפות הסייבר שנמנעו. אתם יכולים לקבל את המדדים והנתונים הנדרשים ממרכזי הבקרה של Google Security Operations SOAR.
שימוש ב-AI באופן מאובטח ואחראי, ושימוש ב-AI למטרות אבטחה
השימוש ב-AI וב-ML הולך ומתרחב בתרחישים של שירותים פיננסיים, כמו זיהוי הונאות ומסחר אלגוריתמי. התקנות מחייבות להשתמש בטכנולוגיות האלה באופן אתי, שקוף ומאובטח. AI יכול גם לעזור לשפר את יכולות האבטחה. כדאי להביא בחשבון את ההמלצות הבאות לשימוש ב-AI:
- לפתח ולפרוס מודלים של ML בסביבה מאובטחת ומנוהלת באמצעות Gemini Enterprise Agent Platform. תכונות כמו הסבר על המודל ומדדי הוגנות יכולות לעזור לטפל בחששות שקשורים ל-AI אחראי.
- להשתמש ביכולות של Google Security Operations לניתוח ותפעול של נתוני אבטחה, שמתבססות על AI ו-ML כדי לנתח כמויות גדולות של נתוני אבטחה, לזהות חריגות ולהפוך את התגובה לאיומים לאוטומטית. היכולות האלה עוזרות לשפר את מצב האבטחה הכולל ולעקוב אחרי התאימות.
- הגדירו מדיניות ניהול ברורה לפיתוח ולפריסה של AI ו-ML, כולל שיקולים שקשורים לאבטחה ולאתיקה.
- להתאים את עצמכם לרכיבים של Secure AI Framework (SAIF), שמספקת גישה מעשית לטיפול בבעיות אבטחה וסיכונים במערכות AI.
- עוקבים אחרי הדיוק והיעילות של מערכות מבוססות-AI לזיהוי הונאות, הירידה בתוצאות חיוביות שגויות בהתראות אבטחה והשיפור ביעילות בזכות אוטומציה של אבטחה מבוססת-AI.
עמידה בדרישות הרגולציה, התאימות והפרטיות
שירותים פיננסיים כפופים למגוון רחב של תקנות, כולל דרישות לגבי מיקום אחסון הנתונים, נתיבי ביקורת ספציפיים ותקנים להגנה על נתונים. כדי לוודא שמידע רגיש מזוהה, מוגן ומנוהל כמו שצריך, ארגונים בתחום השירותים הפיננסיים צריכים מדיניות חזקה של משילות מידע (data governance) וסכמות לסיווג נתונים. כדי לעמוד בדרישות הרגולטוריות, כדאי לפעול לפי ההמלצות הבאות:
- להגדיר גבולות נתונים ב- Google Cloud לעומסי עבודה רגישים ומפוקחים באמצעות Assured Workloads. כך תוכלו לעמוד בדרישות התאימות של הממשלה ושל התחום הספציפי, כמו FedRAMP ו-CJIS.
- זיהוי, סיווג והגנה על מידע אישי רגיש, כולל מידע פיננסי, באמצעות הטמעה של Sensitive Data Protection. כך תוכלו לעמוד בתקנות בנושא פרטיות נתונים כמו GDPR ו-CCPA.
- מעקב אחרי פרטים של פעילויות ניהוליות וגישה למשאבים באמצעות יומני הביקורת של Cloud. היומנים האלה חיוניים כדי לעמוד בדרישות הביקורת שנקבעו בתקנות פיננסיות רבות.
- כשבוחרים Google Cloud אזורים לעומסי העבודה ולנתונים, צריך להביא בחשבון את התקנות המקומיות שקשורות למיקום אחסון הנתונים. התשתית הגלובלית של Google Cloud מאפשרת לבחור אזורים שיכולים לעזור לכם לעמוד בדרישות של מיקום אחסון הנתונים.
- לנהל את המפתחות שמשמשים להצפנת נתונים פיננסיים רגישים במנוחה ובמעבר באמצעות Cloud Key Management Service. הצפנה כזו היא דרישה בסיסית בתקנות רבות בנושא אבטחה ופרטיות.
- מטמיעים את אמצעי הבקרה שנדרשים כדי לעמוד בדרישות הרגולטוריות. מוודאים שאמצעי הבקרה פועלים כמו שצריך. מבקשים מגורם ביקורת חיצוני לאמת שוב את אמצעי הבקרה כדי להוכיח לרגולטור שעומסי העבודה שלכם עומדים בתקנות.
תעדוף יוזמות אבטחה
בגלל המגוון הרחב של דרישות האבטחה, מוסדות פיננסיים צריכים לתעדף יוזמות שמבוססות על הערכת סיכונים ועל דרישות רגולטוריות. אנחנו ממליצים על הגישה המדורגת הבאה:
- הקמת תשתית אבטחה חזקה: התמקדות בתחומים העיקריים של אבטחה, כולל ניהול זהויות והרשאות גישה, אבטחת רשת והגנה על נתונים. ההתמקדות הזו עוזרת לבנות מצב אבטחה חזק ומסייעת להבטיח הגנה מקיפה מפני איומים מתפתחים.
- עמידה בתקנות קריטיות: חשוב לתת עדיפות לעמידה בתקנות מרכזיות כמו PCI DSS, GDPR וחוקים לאומיים רלוונטיים. כך אפשר להגן על הנתונים, לצמצם סיכונים משפטיים ולבנות אמון עם הלקוחות.
- הטמעת אבטחה מתקדמת: הטמעה הדרגתית של שיטות אבטחה מתקדמות כמו מודל אבטחה של אפס אמון, פתרונות אבטחה מבוססי-AI וחיפוש איומים יזום.