במסמך הזה, שמופיע בGoogle Cloud Well-Architected Framework: Financial services (FS) perspective, מופיע סקירה כללית של העקרונות וההמלצות לטיפול בדרישות האבטחה, הפרטיות והתאימות של עומסי עבודה של שירותים פיננסיים (FS) ב- Google Cloud. ההמלצות עוזרות לכם לבנות תשתית עמידה ותואמת, להגן על מידע אישי רגיש, לשמור על אמון הלקוחות, להתמודד עם המורכבות של הדרישות הרגולטוריות ולנהל ביעילות איומי סייבר. ההמלצות במסמך הזה תואמות לעקרון האבטחה של Well-Architected Framework.
האבטחה ב-Cloud היא נושא קריטי לארגונים פיננסיים, שהם יעד אטרקטיבי מאוד לפושעי סייבר בגלל הכמויות העצומות של נתונים רגישים שהם מנהלים, כולל פרטי לקוחות ורשומות פיננסיות. ההשלכות של תקרית אבטחת מידע חמורות במיוחד, כולל הפסדים כספיים משמעותיים, נזק תדמיתי לטווח ארוך וקנסות רגולטוריים משמעותיים. לכן, עומסי עבודה של FS צריכים אמצעי בקרה מחמירים לאבטחה.
כדי להבטיח אבטחה ותאימות מקיפות, חשוב להבין את האחריות המשותפת שלכם (ארגונים פיננסיים) ושל 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) בכל חשבונות המשתמשים, במיוחד בחשבונות עם גישה לנתונים או למערכות רגישים.
- תמיכה בביקורות ובחקירות שקשורות לתאימות לתקנות באמצעות יצירת רישום מקיף ומעקב אחרי גישת משתמשים ופעילות ברשת.
- אפשר להפעיל תקשורת פרטית ומאובטחת בין שירותים בתוך סביבותGoogle Cloud ובסביבות מקומיות בלי לחשוף את התנועה לאינטרנט הציבורי באמצעות Private Service Connect.
- כדי להטמיע אמצעי בקרה פרטניים לזהויות ולאשר גישה ברמת האפליקציה, מומלץ להשתמש בשרת proxy לאימות זהויות (IAP) במקום להסתמך על מנגנוני אבטחה שמבוססים על רשת, כמו מנהרות VPN. הגישה הזו עוזרת לצמצם את התנועה הרוחבית בסביבה.
הטמעה של אבטחה מוקדמת
רשויות רגולטוריות בתחום הפיננסי מעודדות נקיטת אמצעי אבטחה יזומים. זיהוי נקודות חולשה וטיפול בהן בשלב מוקדם במחזור החיים של הפיתוח עוזרים להפחית את הסיכון לאירועי אבטחה ואת הסיכון לקנסות על אי-עמידה בדרישות. העיקרון של אבטחת shift-left מעודד בדיקות אבטחה ושילוב מוקדם, ועוזר להפחית את העלות והמורכבות של התיקון.
כדי ליישם אבטחה מסוג 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:
- פיתוח ופריסה של מודלים של ML בסביבה מאובטחת ומפוקחת באמצעות Vertex AI. תכונות כמו הסבר על המודל ומדדי הוגנות יכולות לעזור לטפל בבעיות שקשורות ל-AI אחראי.
- אפשר להשתמש ביכולות ניתוח ותפעול של נתוני אבטחה ב-Google Security Operations, שמתבסס על AI ולמידת מכונה כדי לנתח כמויות גדולות של נתוני אבטחה, לזהות חריגות ולהפוך את התגובה לאיומים לאוטומטית. היכולות האלה עוזרות לשפר את אמצעי האבטחה הכוללים ולעקוב אחרי התאימות.
- הגדרת מדיניות ברורה לניהול פיתוח ופריסה של AI ולמידת מכונה, כולל שיקולים שקשורים לאבטחה ולאתיקה.
- התאמה לרכיבים של 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. הצפנה כזו היא דרישה בסיסית של תקנות רבות בנושא אבטחה ופרטיות.
- מטמיעים את אמצעי הבקרה שנדרשים כדי לעמוד בדרישות הרגולטוריות. מוודאים שהאמצעים פועלים כמו שצריך. לקבל אימות חוזר של אמצעי הבקרה על ידי מבקר חיצוני כדי להוכיח לרשות הרגולטורית שעומסי העבודה שלכם עומדים בדרישות התקנות.
תעדוף יוזמות אבטחה
בהתחשב במגוון הרחב של דרישות האבטחה, מוסדות פיננסיים צריכים לתת עדיפות ליוזמות שמבוססות על הערכת סיכונים ועל דרישות רגולטוריות. אנחנו ממליצים על גישה מדורגת:
- יצירת בסיס אבטחה חזק: התמקדות בתחומי הליבה של האבטחה, כולל ניהול זהויות והרשאות גישה (IAM), אבטחת רשת והגנה על נתונים. ההתמקדות הזו עוזרת לבנות אסטרטגיית אבטחה חזקה ומבטיחה הגנה מקיפה מפני איומים מתפתחים.
- התייחסות לתקנות קריטיות: חשוב לתת עדיפות לעמידה בתקנות חשובות כמו PCI DSS, GDPR וחוקים לאומיים רלוונטיים. כך תוכלו להבטיח את הגנה על נתונים, לצמצם את הסיכונים המשפטיים ולבנות אמון עם הלקוחות.
- הטמעת אבטחה מתקדמת: הטמעה הדרגתית של שיטות אבטחה מתקדמות כמו מודל אבטחה של אפס אמון, פתרונות אבטחה מבוססי-AI וחיפוש פרואקטיבי של איומים.