במסמך הזה, שמופיע בGoogle Cloud Well-Architected Framework: Financial services (FS) perspective, מוצג סקירה כללית של העקרונות וההמלצות לטיפול בדרישות האבטחה, הפרטיות והתאימות של עומסי עבודה של שירותים פיננסיים (FS) ב- Google Cloud. ההמלצות עוזרות לכם לבנות תשתית עמידה ותואמת, להגן על מידע אישי רגיש, לשמור על אמון הלקוחות, להתמודד עם המורכבות של הדרישות הרגולטוריות ולנהל ביעילות איומי סייבר. ההמלצות במסמך הזה תואמות לעקרון האבטחה של Well-Architected Framework.
האבטחה במחשוב ענן היא נושא קריטי לארגונים פיננסיים, שהם יעד אטרקטיבי מאוד לפושעי סייבר בגלל הכמויות העצומות של מידע אישי רגיש שהם מנהלים, כולל פרטי לקוחות ודוחות כספיים. ההשלכות של תקרית אבטחת מידע הן חמורות במיוחד, כולל הפסדים כספיים משמעותיים, פגיעה במוניטין לטווח ארוך וקנסות רגולטוריים משמעותיים. לכן, עומסי העבודה של ארגונים פיננסיים צריכים להיות מוגנים באמצעות אמצעי בקרה מחמירים.
כדי להבטיח אבטחה ותאימות מקיפות, חשוב להבין את האחריות המשותפת שלכם (ארגונים בתחום השירותים הפיננסיים) ושל Google Cloud. Google Cloud אחראית על אבטחת התשתית הבסיסית, כולל אבטחה פיזית ואבטחת רשת. אתם אחראים לאבטחת הנתונים והאפליקציות, להגדרת בקרת הגישה ולהגדרה ולניהול של שירותי אבטחה. כדי לתמוך במאמצי האבטחה שלכם, Google Cloud סביבת השותפים מציעה שילוב אבטחה ושירותים מנוהלים.
ההמלצות בנושא אבטחה במסמך הזה ממופות לעקרונות הליבה הבאים:
- הטמעת אבטחה משלב התכנון
- הטמעה של מודל אבטחה של אפס אמון
- הטמעת אבטחה מוקדמת
- הטמעה של הגנת סייבר מונעת
- שימוש מאובטח ואחראי ב-AI, ושימוש ב-AI למטרות אבטחה
- עמידה בדרישות רגולטוריות, בדרישות תאימות ובדרישות פרטיות
- מתן עדיפות ליוזמות אבטחה
הטמעה של אבטחה משלב התכנון
תקנות פיננסיות כמו תקן אבטחת הנתונים המקובל בתעשיית כרטיסי תשלום (PCI DSS), Gramm-Leach-Bliley Act (חוק GLBA) בארצות הברית וחוקים שונים להגנה על נתונים פיננסיים ברמה הלאומית מחייבים לשלב אבטחה במערכות כבר מההתחלה. העיקרון של אבטחה מובנית מדגיש את השילוב של אבטחה לאורך מחזור החיים של הפיתוח, כדי למזער את נקודות החולשה כבר מההתחלה.
כדי ליישם את העיקרון של אבטחה מובנית בעומסי העבודה של FS ב-Google Cloud, כדאי לפעול לפי ההמלצות הבאות:
- כדי לוודא שמוענקות רק ההרשאות הנדרשות, צריך להחיל את העיקרון של הרשאות מינימליות באמצעות בקרת גישה מפורטת מבוססת-תפקידים (RBAC) בניהול הזהויות והרשאות הגישה (IAM). השימוש ב-RBAC הוא דרישה מרכזית ברגולציות פיננסיות רבות.
- אפשר להשתמש ב-VPC Service Controls כדי לאכוף אזורי אבטחה מסביב לשירותים ולנתונים הרגישים שלכם ב- Google Cloud . גבולות הגזרה עוזרים לפלח ולהגן על מידע אישי רגיש ומשאבים, ולמנוע זליגת נתונים וגישה לא מורשית, כפי שנדרש בתקנות.
- להגדיר את הגדרות האבטחה כקוד באמצעות כלים של תשתית כקוד (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) ואמצעי בקרה אחרים שחשובים להטמעה של מודל אבטחה של אפס אמון ולעמידה בתקנות.
- הטמעת MFA בכל חשבונות המשתמשים, במיוחד בחשבונות עם גישה למידע אישי רגיש או למערכות.
- תמיכה בביקורות ובחקירות שקשורות לתאימות לתקנות על ידי הקמת רישום מקיף ומעקב אחר גישת משתמשים ופעילות ברשת.
- אפשר להשתמש ב-Private Service Connect כדי לאפשר תקשורת פרטית ומאובטחת בין שירותים בסביבותGoogle Cloud ובסביבות מקומיות, בלי לחשוף את התנועה לאינטרנט הציבורי.
- כדי לצמצם את התנועה הרוחבית בסביבה, כדאי להטמיע אמצעי בקרה מפורטים של זהויות ולאשר גישה ברמת האפליקציה באמצעות שרת proxy לאימות זהויות (IAP), במקום להסתמך על מנגנוני אבטחה שמבוססים על רשתות כמו מנהרות VPN.
הטמעה של אבטחה מוקדמת
רשויות רגולטוריות פיננסיות מעודדות נקיטת אמצעי אבטחה יזומים. זיהוי נקודות חולשה וטיפול בהן בשלב מוקדם במחזור החיים של הפיתוח עוזרים להפחית את הסיכון לתקריות אבטחה ואת הסיכוי לקנסות על אי-עמידה בדרישות. העיקרון של shift-left security (הזזה שמאלה של אבטחה) מעודד בדיקות אבטחה ושילוב מוקדם, ועוזר להפחית את העלות והמורכבות של התיקון.
כדי ליישם אבטחה מסוג Shift-Left, כדאי לפעול לפי ההמלצות הבאות:
כדי להבטיח בדיקות אבטחה אוטומטיות בשלב מוקדם בתהליך הפיתוח, אפשר לשלב כלי סריקה לאבטחה, כמו סריקת נקודות חולשה במאגרי נתונים וניתוח קוד סטטי, בצינור CI/CD באמצעות Cloud Build.
כדי לוודא שרק ארטיפקטים מאובטחים נפרסים, כדאי להשתמש ב-Artifact Registry כדי לספק מאגר מאובטח ומרכזי לחבילות תוכנה ולקובצי אימג' של קונטיינרים עם סריקה משולבת של נקודות חולשה. כדאי להשתמש במאגרים וירטואליים כדי לצמצם את הסיכון למתקפות של בלבול תלות על ידי מתן עדיפות לארטיפקטים הפרטיים על פני מאגרים מרוחקים.
אפשר לסרוק באופן אוטומטי אפליקציות אינטרנט כדי למצוא נקודות חולשה נפוצות באמצעות שילוב של Web Security Scanner, שהוא חלק מ-Security Command Center, בצינורות הפיתוח.
כדי להטמיע בדיקות אבטחה לקוד המקור, לתהליך build ולמקור הקוד, אפשר להשתמש במסגרת Supply-chain Levels for Software Artifacts (SLSA). אפשר לאכוף את המקור של עומסי העבודה שפועלים בסביבות שלכם באמצעות פתרונות כמו Binary Authorization. כדי לוודא שעומסי העבודה שלכם משתמשים רק בספריות מאומתות של תוכנה בקוד פתוח, אתם יכולים להשתמש ב-Assured Open Source.
לעקוב אחרי מספר הפגיעויות שמזוהות ומתוקנות במחזור החיים של הפיתוח, אחרי אחוז פריסות הקוד שעוברות סריקות אבטחה ואחרי הירידה במספר אירועי האבטחה שנגרמים כתוצאה מפגיעויות בתוכנה. Google Cloud מספקת כלים שיעזרו לכם לעקוב אחרי נתונים כאלה לסוגים שונים של עומסי עבודה. לדוגמה, לעומסי עבודה מבוססי קונטיינרים, אפשר להשתמש בתכונת סריקת הקונטיינרים של Artifact Registry.
הטמעה של הגנת סייבר מונעת
מוסדות פיננסיים הם מטרות עיקריות למתקפות סייבר מתוחכמות. תקנות רבות מחייבות מודיעין איומים חזק ומנגנוני הגנה יזומים. הגנה מקדימה מפני מתקפות סייבר מתמקדת בזיהוי יזום של איומים ובתגובה לאיומים באמצעות ניתוח מתקדם ואוטומציה.
כדאי לשקול את ההמלצות הבאות:
- זיהוי יזום של איומים פוטנציאליים וצמצום הסיכון שלהם באמצעות שירותי מודיעין איומי סייבר, תגובה לאירוע ואימות אבטחה של Mandiant.
- הגנה על אפליקציות אינטרנט וממשקי API מפני ניצול לרעה של האינטרנט ומתקפות DDoS בקצה הרשת באמצעות Google Cloud Armor.
- אפשר לצבור ולתעדף ממצאים והמלצות בנושא אבטחה באמצעות Security Command Center, וכך לאפשר לצוותי האבטחה לטפל באופן יזום בסיכונים פוטנציאליים.
- כדי לוודא שאמצעי ההגנה המקדימים ותוכניות התגובה לאירועים יעילים, מומלץ לבצע סימולציות אבטחה ובדיקות חדירה באופן קבוע.
- למדוד את הזמן שנדרש לזיהוי אירועי אבטחה ולתגובה להם, את היעילות של מאמצי המיתון של מתקפות DDoS ואת מספר מתקפות הסייבר שנמנעו. אפשר לקבל את המדדים והנתונים הנדרשים מלוחות הבקרה של Google Security Operations SOAR ו-SIEM.
שימוש מאובטח ואחראי ב-AI, ושימוש ב-AI למטרות אבטחה
נעשה שימוש הולך וגובר ב-AI וב-ML בתרחישי שימוש בשירותים פיננסיים, כמו זיהוי הונאות ומסחר אלגוריתמי. התקנות מחייבות שימוש בטכנולוגיות האלה באופן אתי, שקוף ומאובטח. בנוסף, AI יכול לעזור לשפר את יכולות האבטחה שלכם. כדאי לשקול את ההמלצות הבאות לשימוש ב-AI:
- פיתוח ופריסה של מודלים של למידת מכונה בסביבה מאובטחת ומנוהלת באמצעות Vertex AI. תכונות כמו הסבר על מודלים ומדדי הוגנות יכולות לעזור לטפל בבעיות שקשורות ל-AI אחראי.
- להשתמש ביכולות ניתוח ותפעול של נתוני אבטחה ב-Google Security Operations, שמבוססות על AI ועל למידת מכונה (ML) כדי לנתח כמויות גדולות של נתוני אבטחה, לזהות חריגות ולהפוך את התגובה לאיומים לאוטומטית. היכולות האלה עוזרות לשפר את אמצעי האבטחה הכוללים ולעקוב אחרי התאימות.
- הגדרת מדיניות ברורה לניהול פיתוח ופריסה של AI ו-ML, כולל שיקולים שקשורים לאבטחה ולאתיקה.
- התאמה לרכיבים של Secure AI Framework (SAIF), שמספק גישה מעשית לטיפול בבעיות אבטחה ובסיכונים של מערכות AI.
- מעקב אחרי הדיוק והיעילות של מערכות לזיהוי הונאות מבוססות-AI, צמצום התוצאות החיוביות השגויות בהתראות אבטחה ושיפור היעילות באמצעות אוטומציה של אבטחה מבוססת-AI.
עמידה בדרישות רגולטוריות, בדרישות תאימות ובדרישות בנושא פרטיות
שירותים פיננסיים כפופים למגוון רחב של תקנות, כולל דרישות לגבי מיקום הנתונים, נתיבי ביקורת ספציפיים ותקנים להגנה על נתונים. כדי לוודא שמידע אישי רגיש מזוהה, מוגן ומנוהל בצורה נכונה, ארגונים בתחום השירותים הפיננסיים צריכים מדיניות חזקה למשילות מידע (data governance) ותוכניות לסיווג נתונים. כדי לעמוד בדרישות הרגולטוריות, כדאי לפעול לפי ההמלצות הבאות:
- כדי להגדיר גבולות נתונים ב- Google Cloud לעומסי עבודה (workloads) רגישים וכפופים לרגולציה, משתמשים ב-Assured Workloads. כך תוכלו לעמוד בדרישות התאימות של הממשלה ושל התעשייה, כמו FedRAMP ו-CJIS.
- מזהים ומסווגים מידע רגיש, כולל מידע פיננסי, ומגנים עליו באמצעות הטמעה של מניעת אובדן נתונים בענן (Cloud DLP). כך תוכלו לעמוד בדרישות של תקנות בנושא פרטיות נתונים כמו GDPR ו-CCPA.
- כדי לעקוב אחרי פרטים של פעילויות אדמין וגישה למשאבים, אפשר להשתמש ביומני ביקורת של Cloud. היומנים האלה חיוניים כדי לעמוד בדרישות הביקורת שנקבעו על ידי תקנות פיננסיות רבות.
- כשבוחרים Google Cloud אזורים לעומסי העבודה ולנתונים, חשוב לקחת בחשבון תקנות מקומיות שקשורות למיקום הנתונים. Google Cloud התשתית הגלובלית מאפשרת לכם לבחור אזורים שיעזרו לכם לעמוד בדרישות בנוגע למיקום הנתונים.
- ניהול המפתחות שמשמשים להצפנת נתונים פיננסיים רגישים במנוחה ובמעבר באמצעות Cloud Key Management Service. הצפנה כזו היא דרישה בסיסית של תקנות רבות בנושאי אבטחה ופרטיות.
- מטמיעים את אמצעי הבקרה שנדרשים כדי לעמוד בדרישות הרגולטוריות. מוודאים שהאמצעים פועלים כצפוי. לקבל אימות חוזר של אמצעי הבקרה על ידי מבקר חיצוני כדי להוכיח לרשות הרגולטורית שעומסים דינמיים תואמים לתקנות.
הגדרת סדר עדיפויות ליוזמות אבטחה
בהתחשב במגוון הרחב של דרישות האבטחה, מוסדות פיננסיים צריכים לתת עדיפות ליוזמות שמבוססות על הערכת סיכונים ועל דרישות רגולטוריות. אנחנו ממליצים על גישה מדורגת:
- יוצרים בסיס אבטחה חזק: מתמקדים בתחומי הליבה של האבטחה, כולל ניהול זהויות וגישה, אבטחת רשת והגנה על נתונים. המיקוד הזה עוזר לבנות אסטרטגיית אבטחה חזקה ומבטיח הגנה מקיפה מפני איומים מתפתחים.
- התייחסות לתקנות קריטיות: חשוב לתת עדיפות לציות לתקנות מרכזיות כמו PCI DSS, GDPR וחוקים לאומיים רלוונטיים. כך תוכלו להבטיח את ההגנה על הנתונים, לצמצם סיכונים משפטיים ולבנות אמון עם הלקוחות.
- הטמעת אבטחה מתקדמת: הטמעה הדרגתית של שיטות אבטחה מתקדמות כמו מודל אבטחה של אפס אמון, פתרונות אבטחה מבוססי-AI וחיפוש פרואקטיבי של איומים.