במסמך הזה, שמופיע ב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) ואמצעי בקרה אחרים שחשובים להטמעה של Zero Trust ולעמידה בדרישות הרגולטוריות.
- הטמעת 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:
- פיתוח ופריסה של מודלים של למידת מכונה בסביבה מאובטחת ומנוהלת באמצעות Gemini Enterprise Agent Platform. תכונות כמו הסבר על המודל ומדדי הוגנות יכולות לעזור לטפל בבעיות שקשורות ל-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 וחיפוש פרואקטיבי של איומים.