COBOL עדיין מנהלת כ-95% מעסקאות כספומט, 80% מעסקאות נקודת המכירה הפיזיות, ואת לוגיקת העיבוד המרכזית של רוב הבנקים הגדולים, חברות הביטוח וסוכנויות ממשלתיות ברחבי העולם. הארגונים המפעילים קוד זה כפופים גם למסגרות הרגולטוריות התובעניות ביותר בתחום הטכנולוגיה: GDPR, DORA, HIPAA, PCI-DSS, Basel III, ומשטרים ספציפיים למגזר הנאכפים על ידי ה-FCA, OCC, APRA ועשרות רשויות לאומיות אחרות. כאשר ארגונים אלה שוקלים להעביר עומסי עבודה לענן, השאלה אינה רק טכנית. היא משפטית, חוזית וניתנת להוכחה לרואה חשבון חיצוני בלוח זמנים ספציפי.
ענן היברידי, שמירה על עומסי עבודה מסוימים באתר תוך העברת אחרים לתשתית ענן, אינו עמדת פשרה עבור ארגונים מוסדרים המריצים COBOL. לעתים קרובות זוהי התשובה הנכונה מבחינה ארכיטקטונית. דרישות אחסון נתונים תחת GDPR והמקבילות הלאומיות שלה עשויות לאסור באופן חוקי על נתונים מסוימים לעזוב תחום שיפוט ספציפי. דרישות חוסן תפעולי תחת DORA דורשות להדגים שפונקציות פיננסיות קריטיות יכולות לעמוד בהפסקות של ספקי ענן. דרישות שלמות חישוב עבור הון רגולטורי תחת באזל III דורשות שחישובים ספציפיים יהיו ניתנים לשחזור, ניתנים לביקורת ומוכחשים מפני פגיעה, מאפיינים שקל יותר להדגים כאשר החישוב מתבצע בתשתית שהארגון שולט בה.
מצא פערים בתאימות לפני תחילת ההעברה
SMART TS XL חושף אישורים מקודדים, נתיבי ביקורת חסרים ודפוסי נתונים מוסדרים במקור COBOL.
מידע נוסףהאתגר הוא שארכיטקטורת ענן היברידית עבור COBOL מוסדר מוגבלת יותר ממה שהנחיות ענן היברידי גנריות מודעות לה. אסטרטגיית שילוב הענן ההיברידי שלכם מספקת איזון חיוני בין חדשנות ליציבות במהלך מעבר ממערכת המרכזית לענן. איזון זה נכון כעיקרון. מה שהיא משמיטה הוא הארכיטקטורה הטכנית והספציפית הנדרשת כדי לשרטט את הגבול בין המערכת המקומית לענן במקום שמספק את הרגולטורים, שומר על המשכיות תפעולית ויוצר נתיב מעבר במקום פיצול קבוע.
מדריך זה מכסה כיצד כל מסגרת רגולטורית מרכזית מעצבת את החלטת הגבול ההיברידי, את ארבעת הדפוסים הארכיטקטוניים שעובדים עבור סביבות COBOL מוסדרות, את מצבי כשל התאימות שארכיטקטורות היברידיות מציגות אם לא תוכננו עבורן, ומה בודקים בפועל כאשר הם סוקרים סביבת COBOL היברידית.
כיצד תקנות מעצבות את הגבול ההיברידי
ההחלטה המשמעותית ביותר בארכיטקטורת ענן היברידית עבור ארגון מוסדר אינה באיזה ספק ענן להשתמש או אילו עומסי עבודה להעביר תחילה. אלא היכן למתוח את גבול התאימות: אילו נתונים ואילו עיבודים חייבים להישאר מקומיים, ואילו יכולים לעבור לתשתית ענן מבלי לגרום להפרה רגולטורית.
כל מסגרת עיקרית מטילה דרישות שונות על גבול זה:
| תקנה | תחום שיפוט | אילוץ היברידי ראשוני | מה חייב להישאר במקום |
|---|---|---|---|
| GDPR / nFADP | האיחוד האירופי, שוויץ | אחסון נתונים עבור נתונים אישיים של תושבי האיחוד האירופי/EEA | כל מערכת COBOL המעבדת נתונים אישיים של האיחוד האירופי ללא החלטת נאותות עבור אזור הענן היעד |
| דורה | שירותים פיננסיים של האיחוד האירופי | חוסן תפעולי; ניהול סיכונים של צד שלישי עבור ספקי טכנולוגיות מידע ותקשורת | פונקציות קריטיות או חשובות חייבות להיות בעלות אסטרטגיות יציאה; מגבלות סיכון ריכוזיות חלות |
| HIPAA | שירותי הבריאות האמריקאיים | ספק ענן לא יכול לעבד PHI ללא BAA; דרישות הצפנה | ePHI במעבר ובמנוחה בכל נתיב ענן דורש בקרות מתועדות |
| PCI-DSS גרסה 4.0 | גלובלי (תשלומים בכרטיס) | סביבת נתוני בעל הכרטיס חייבת להיות מבודדת לרשת | מערכות עיבוד CHD; ניהול מפתחות הצפנה |
| באזל III/IV | בנקאות גלובלית | חישובי הון רגולטורי חייבים להיות ניתנים לשחזור ולביקורת | מנועי חישוב שבהם מוכחת יכולת ביקורת באמצעות בקרת תשתית |
| FCA / PRA (בריטניה) | שירותים פיננסיים בבריטניה | חוסן תפעולי; שירותים עסקיים חשובים חייבים לעמוד בסבילות השפעה | תלוי בהוכחת הסכם רמת שירות; ענן אינו נשלל אך יש להציגו כראיה |
| OCC (בנקאות אמריקאית) | בנקים לאומיים בארה"ב | ניהול סיכוני ספקים; בדיקת נאותות של צד שלישי | אין איסור מוחלט, אך נדרשות תוכניות סיכון ריכוזיות ויציאה |
התוצאה המעשית עבור עומסי עבודה של COBOL:
לא ניתן להעביר תוכנית COBOL אצווה המעבדת נתוני חשבונות לקוחות באיחוד האירופי לאזור ענן מחוץ לאיחוד האירופי/EEA אלא אם כן ספק הענן קיבל החלטת נאותות או שאמצעי הגנה מתאימים (סעיפי חוזים סטנדרטיים) קיימים. אותה תוכנית המעבדת רק נתונים תפעוליים פנימיים יש גמישות רבה יותר.
לפני שרטוט הגבול ההיברידי, כל ארגון מוסדר צריך להשלים סיווג נתונים מול תיק ה-COBOL שלו: אילו תוכניות נוגעות לנתונים אישיים, אילו נוגעות לנתוני בעלי כרטיסים, אילו נוגעות לנתוני PHI, ואילו מעבדות חישובי הון רגולטורי. סיווג זה קובע אילו תוכניות יכולות לעבור בחופשיות ואילו חייבות להישאר מאחורי גבול התאימות ללא קשר להעדפה טכנית.
בעיית תאימות COBOL שאף אחד לא מזכיר
תוכניות COBOL מציגות סיכוני תאימות ספציפיים לשפה ולעידן שלה, שהנחיות תאימות גנריות לענן אינן מטפלות בהן. סיכונים אלה קיימים כיום באופן מקומי והופכים לבעיות נראות בסביבה היברידית שבה המבקר מצפה לראות בקרות משני צידי הגבול.
פערים בנתיב ביקורת. תוכניות COBOL בדרך כלל כותבות לקבצים ולמסדי נתונים ללא רישום טרנזקציות מקורי. עדכון VSAM KSDS ב-COBOL אינו מייצר, כברירת מחדל, תיעוד בלתי ניתן לשינוי של מי שינה מה, מתי, ומאיזה ערך לאיזה ערך. בסביבה מוסדרת, זהו פער תאימות, והעברת תוכנית עם פער זה לסביבה היברידית שבה בצד הענן יש רישום ביקורת מודרני הופך את הפער לגלוי יותר, לא פחות.
אישורים ומפתחות הצפנה מקודדים בקפידה. יישומי COBOL מדור קודם חסרים לעתים קרובות תכונות מודרניות כמו בקרת גישה מבוססת תפקידים, ניטור בזמן אמת ופרוטוקולי הצפנה, מה שהופך אותם לפגיעים לאיומי סייבר מתוחכמים. ניתוח סטטי של תוכניות COBOL חושף באופן שגרתי מפתחות מקודדים בקפידה, סיסמאות באחסון עבודה ומחרוזות חיבור המוטמעות בקוד המקור. בסביבה היברידית שחייבת לעמוד בדרישות ניהול מפתחות PCI-DSS או בקרות הצפנה HIPAA, דפוסים אלה דורשים תיקון לפני ההעברה, לא אחריה.
שחזור חישוב. לאריתמטיקה העשרונית הארוזה של COBOL (COMP-3) יש מאפייני דיוק ועיגול ספציפיים. חישוב הון רגולטורי שפועל כהלכה על z/OS עשוי להניב תוצאות שונות ב-Linux עקב הבדלים בין המהדרים בטיפול בעשרוני. ההבדל עשוי להיות סנטים לעסקה, או שהוא עשוי להיות מהותי ליחס הון. סביבות היברידיות המפצלות רכיבי חישוב בין פלטפורמות חייבות לאמת שקילות מספרית במפורש.
ארבע תבניות ארכיטקטוניות היברידיות עבור COBOL מוסדר
עומסי עבודה שונים המוסדרים דורשים ארכיטקטורות היברידיות שונות. אין דפוס אוניברסלי, אך ארבעת אלה מכסים את מגוון המצבים בהם נתקלים רוב הארגונים המוסדרים.
תבנית 1: שער ה-API של גבולות תאימות
הכי טוב עבור: ארגונים שבהם לוגיקת עסקית של COBOL חייבת להישאר מקומית מסיבות רגולטוריות, אך יישומים מודרניים, ניתוח נתונים ושירותים הפונים ללקוחות יכולים לעבור לענן.
תוכניות COBOL נשארות על גבי המחשב המרכזי. שכבת API דקה, שבדרך כלל פועלת על תשתית סמוכה לענן או בתוך הרשת הפרטית של הארגון, חושפת את פונקציונליות COBOL כנקודות קצה REST או gRPC. יישומים מבוססי ענן קוראים לנקודות קצה אלו. תוכנית COBOL לעולם לא זזה; הממשק אליה כן.
Cloud Region (permitted) Compliance Boundary On-Premises (required)
┌─────────────────────┐ │ ┌──────────────────────────┐
│ New cloud-native │ │ │ COBOL programs │
│ applications │──── API ─────┤──────────────│ (regulated processing) │
│ │ call │ │ │
│ Analytics │ │ │ VSAM files (PHI/CHD) │
│ platforms │ │ │ │
│ │ │ │ Audit logs │
└─────────────────────┘ │ └──────────────────────────┘יתרון תאימות: הנתונים המוסדרים לעולם אינם חוצים את הגבול. שער ה-API מטפל באימות, הרשאה ורישום בגבול, ומספק כיסוי של מסלול ביקורת שתוכנית COBOL עצמה עשויה לא ליצור. הענן לעולם אינו מעבד נתונים מוסדרים ישירות.
דרישות תפעוליות: שכבת ה-API חייבת להיות מתוכננת לטפל במודל הסינכרוני של COBOL, המודל של תגובה לבקשות. משימות אצווה ארוכות טווח של COBOL דורשות דפוסים אסינכרוניים עם מנגנוני קריאה חוזרת או סקר במקום קריאות API סינכרוניות שפוגות מהזמן הקצוב.
תבנית 2: חלוקת נתונים לפי רגישות רגולטורית
הכי מתאים ל: ארגונים עם נתונים מוסדרים וגם נתונים שאינם מוסדרים באותה סביבת COBOL, שבה ניתן להפריד נתונים מוסדרים מנתונים תפעוליים.
נתוני עסקאות המפעילים דרישות רגולטוריות, נתונים אישיים, נתוני כרטיסי אשראי, PHI, נשארים באתר. נתונים מצטברים, אנונימיים או תפעוליים שאינם מפעילים הגבלות רגולטוריות עוברים לאחסון ועיבוד בענן. תוכניות COBOL המייצרות פלטים מוסדרים ממשיכות לפעול על גבי המחשב המרכזי. תוכניות דיווח הצורכות נתונים מצטברים פועלות בענן.
דרישת יישום קריטית: שלב הצבירה והאנונימיזציה חייב להיות ניתן לביקורת. התהליך שהופך נתונים מוסדרים לנתונים לא מוסדרים לצורך העברת נתונים בענן חייב להירשם, להיבדק ולהיות כפוף לבקרות משלו. תהליך זיהוי עצמי שנכשל בתנאי קלט ספציפיים עלול לייצר נתוני ענן שמזהים מחדש אנשים בשוגג, הפרה של GDPR הנגרמת על ידי ארכיטקטורה שתוכננה למנוע זאת.
תבנית 3: אימות כפול
הכי טוב עבור: ארגונים המעבירים עומסי עבודה של COBOL המבצעים חישובים מוסדרים, כאשר יש להדגים לרגולטור שקילות פונקציונלית בין מערכות ישנות לחדשות לפני המעבר.
תוכנית COBOL המקורית ממשיכה לפעול על גבי המחשב המרכזי, ומעבדת נתונים חיים. יישום מקביל, שעבר תכנון מחדש או שינוי פלטפורמה, פועל בו זמנית על גבי תשתית ענן, ומעבד את אותם נתוני קלט. הפלט מושווים בזמן אמת. פערים מסומנים, נחקרים ונפתרים לפני שמימוש הענן מאושר כמערכת הרשומה.
ערך תאימות: ריצה כפולה עומדת בדרישת השקילות הניתנת להוכחה שמטילים הרגולטורים על שינויים במערכות המבצעות חישובים רגולטוריים. הארגון יכול להציג לרואה החשבון תיעוד של N חודשים של פעולה מקבילה, תהליך ההתאמה שהוחל על אי התאמות, ואת הראיות לכך שהמערכת החדשה מייצרת תפוקות זהות באופן מהותי תחת כל תנאי הקלט שנבדקו.
עלות תפעולית: הפעלת שתי מערכות במקביל היא יקרה. ריצה כפולה היא מנגנון מעבר, לא ארכיטקטורה קבועה. לוח הזמנים להשלמת האימות והקיצוץ צריך להיות מוגדר בתוכנית הפרויקט ומוסכם עם הרגולטור הרלוונטי כאשר נדרש אישור מראש (כפי שקורה תחת DORA עבור שינויים בפונקציות קריטיות).
תבנית 4: איור חונק עם גבול ציות
הכי טוב עבור: ארגונים הבונים יכולות חדשות בענן תוך שמירה על עומסי עבודה מוסדרים של COBOL מקומיים לטווח ארוך, עם נתיב הגירה מוגדר לכל עומס עבודה עם השגת הסמכה.
תכונות חדשות ופונקציונליות הפונה ללקוחות בנויות כשירותים טבעיים לענן מההתחלה. עומסי עבודה מוסדרים של COBOL נשארים מקומיים, נגישים דרך תבנית שער ה-API. עם הזמן, תוכניות COBOL בודדות מאושרות לפריסה בענן, משלימות אימות כפול, עומדות באישור מוקדם רגולטורי במידת הצורך, ועוברות לצד הענן של הגבול. המחשב המרכזי מתכווץ בהדרגה ככל שכל תוכנית משלימה את הסמכת התאימות שלה.
למה זה עובד עבור ארגונים מוסדרים: זה מאפשר מהירות מודרניזציה על עומסי עבודה שאינם מוסדרים תוך יישום הקפדה מתאימה על עומסים מוסדרים. גבול התאימות הוא מפורש, ניתן לביקורת ונע בכיוון אחד. הארגון יכול להדגים לרגולטורים שכל עומס עבודה בצד הענן עבר תהליך הסמכה מוגדר, ולכל עומס עבודה בצד המקומי יש מפת דרכים להסמכה.
מה שואלים מבקרים בפועל לגבי סביבות COBOL היברידיות
תאימות אינה מצב, אלא תהליך שניתן להדגמה. השאלה אינה האם הארכיטקטורה ההיברידית שלך תואמת. השאלה היא האם אתה יכול להוכיח זאת למישהו שתפקידו למצוא בעיות.
להלן השאלות ששואלים מבקרים מגופים רגולטוריים מרכזיים בהקשר של סביבות COBOL היברידיות, ואילו ראיות עומדות בקריטריונים של כל אחת מהן:
"היכן נתונים אלה נמצאים במנוחה, ובאילו תחומי שיפוט?" נדרש: מפת נתונים עדכנית המציגה כל מאגר נתונים, קבצי VSAM, טבלאות DB2, אחסון אובייקטים בענן, עם תחומי שיפוט, סיווג ובקרות הקיימות. תוכניות COBOL שכותבות למערכי נתונים חייבות להופיע במפה זו כאשר הפלט שלהן מסווג.
"הראה לי את מסלול הביקורת עבור עסקה זו." נדרש: מעקב מקצה לקצה מתחילת העסקה דרך כל מערכת שנגעה בנתונים, כולל תוכנית COBOL שעיבדה אותם. אם תוכנית COBOL אינה מייצרת רשומות ביקורת משלה, התשתית הסובבת חייבת לפצות, פונקציה שיש לתכנן במפורש, לא להניח.
"מה קורה לפונקציות הקריטיות שלך אם יש הפסקת חשמל אצל ספק הענן שלך?" נדרש (DORA): תרחישי חוסן תפעוליים מתועדים, RPO ו-RTO שנבדקו עבור פונקציות קריטיות, והוכחות לכך שמערכות מקומיות יכולות לפעול באופן עצמאי מתלות ענן למשך הזמן שצוין במדיניות החוסן של הארגון.
"איך אתה יודע שהמערכת שהועברה מניבה את אותן תוצאות כמו המקור?" נדרש: רשומת ההתאמה הכפולה, כיסוי מקרה בדיקה, ועבור עומסי עבודה רגישים לחישוב, ניתוח שקילות מספרית.
"מי יכול לגשת לנתונים מוסדרים בצד הענן, ואילו אישורים מסדירים גישה זו?" נדרש: תיעוד מדיניות IAM, רישומי ניהול גישה להרשאות, והוכחות לכך שבקרות הגישה בצד הענן מגבילות לפחות כמו אלו בצד המקומי.
מסגרת החלטה להצבת הגבול ההיברידי
לא כל תוכנית COBOL שייכת לאותו צד של הגבול ההיברידי. רשימת בדיקה זו קובעת את המיקום עבור כל עומס עבודה:
מעבר לענן ללא אילוצים רגולטוריים:
- התוכנית אינה מעבדת נתונים אישיים של אנשים בתחומי שיפוט של GDPR/nFADP
- התוכנית אינה מעבדת נתוני בעל כרטיס (אי הכללת טווח PCI-DSS אושרה)
- התוכנית אינה מעבדת PHI (אי הכללת היקף HIPAA אושרה)
- התוכנית אינה מבצעת חישובים המהווים קלט ליחסי הון רגולטוריים
- לתוכנית אין אישורים קשיחים או מפתחות הצפנה במקור
- פלטי התוכנית אינם כפופים לדרישות אחסון נתונים באף תחום שיפוט
דורש תכנון תאימות לפני מעבר לענן:
- התוכנית מייצרת או מעבדת נתונים אישיים, משלימה הערכת השפעה על הנתונים
- התוכנית כוללת PCI-DSS, SAQ/ROC מלא לסביבת ענן
- התוכנית מבצעת חישובי הון רגולטורי, ניתוח שקילות מספרית מלא
- התוכנית חסרה יצירת נתיב ביקורת, תכנון בקרות מפצות לפני ההעברה
- התוכנית מכילה מפתחות מקודדים, יש לתקן זאת לפני חשיפה לנתיב רשת הענן
יש להישאר במקום עד לאישור מוקדם של הרגולטורים:
- התוכנית מסווגת כפונקציה קריטית או חשובה תחת DORA
- התוכנית כפופה לדרישות החוסן התפעולי של FCA/PRA כשירות עסקי חשוב
- הרגולטור דרש במפורש הודעה או אישור מראש לשינויים במערכת (נפוץ בבנקאות הליבה)
איך SMART TS XL תומך בתכנון ארכיטקטורה היברידית עבור COBOL מוסדר
ההחלטות המתוארות במדריך זה, היכן למקם את גבול התאימות, אילו תוכניות מעבדות נתונים מוסדרים, אילו מכילות דרישות תיקון אבטחה, אילו פונקציות חישוב הדורשות אימות שקילות, דורשות ידע מבני מדויק של כל תוכנית בתיק ה-COBOL. לא ניתן להניח ידע זה מהתיעוד. בסביבות COBOL מוסדרות, התיעוד הקיים נכתב בדרך כלל עבור מערכת ששונתה מאז עשרות פעמים ללא עדכוני תיעוד תואמים.
SMART TS XL"S ניתוח קוד סטטי חושף את דפוסי האבטחה והתאימות בקוד המקור של COBOL הקובעים לאיזה צד של הגבול ההיברידי שייכת כל תוכנית: אישורים מקודדים ב-WORKING-STORAGE, טיפול במפתחות הצפנה, יצירת יומן ביקורת (או היעדרה) ודפוסי חישוב המשפיעים על ההון הרגולטורי. ממצאים אלה תומכים בעבודת תכנון התאימות שחייבת להקדים הצבת גבול היברידי עבור עומסי עבודה מוסדרים.
מיפוי תלות היישומים מראה אילו תוכניות חולקות נתונים עם אילו אחרות, ואת דפוסי הגישה לערכת נתונים בין-תוכניות הקובעים האם הצבת תוכנית אחת בענן יוצרת זרימת נתונים מוסדרת מעבר לגבול שלא הייתה צפויה. תוכנית COBOL שנראית כמעבדת רק נתונים תפעוליים עשויה לקרוא מקובץ VSAM המכיל גם נתונים אישיים שנכתבו על ידי תוכנית אחרת. מפת התלות הופכת את יחסי שיתוף הנתונים הללו לגלויים לפני ששורטטים את הגבול ההיברידי.
יכולת ניתוח ההשפעה הופכת שינויי גבולות לניתנים לביקורת: כאשר תוכנית עוברת ממצב מקומי לענן, ניתוח ההשפעה מונה כל תוכנית אחרת המושפעת ממעבר זה, את הקוראים, את צרכני מערך הנתונים, את זרמי המשימות של JCL , ומספק את היקף השינוי כראיה עבור הרגולטור וכבסיס לתוכנית בדיקות השקילות.
יכולת החיפוש הארגוני הופכת את מלאי התאימות לניתן לשאילתה בכל התוכנית ההיברידית: מצא כל תוכנית שמעבדת סוג נתונים ספציפי, כל תוכנית שניגשת לאשכול VSAM ספציפי, כל קובץ מקור COBOL המכיל תבנית ספציפית, על פני מיליוני שורות, תוך שניות. עבור ארגון מוסדר המדגים לרואה חשבון שכל התוכניות הנכללות במסגרת זוהו והוערכו, מלאי זה הניתן לשאילתה הוא הראיה המחליפה אימות ידני.
לרגולטור לא אכפת מלוח הזמנים של ההגירה שלך
ענן היברידי אינו מצב זמני עבור ארגונים מוסדרים המריצים COBOL. עבור רבים מהם, זהו מודל התפעול הקבוע, לא בגלל מגבלות טכניות, אלא משום שהמסגרת הרגולטורית המסדירה את הנתונים והתפקודים שלהם דורשת שליטה מקומית על עומסי עבודה ספציפיים ללא הגבלת זמן. השאלה הנכונה אינה "איך נוותר על המחשב המרכזי" אלא "אילו עומסי עבודה יכולים לעבור לענן, תחת איזו ארכיטקטורת תאימות, ועם אילו ראיות לכך שהגבול נשלט כראוי".
מערכות היברידיות נותנות לארגונים את הגמישות לשמור על רכיבים מדור קודם מקומיים תוך מתן אפשרות לשילובי ענן. עבור תעשיות מפוקחות, גמישות זו אינה אופציונלית, היא חובה עבור קטגוריות עומסי עבודה ספציפיות. הארגונים שמצליחים עם ארכיטקטורות COBOL היברידיות הם אלה שמתכננים את גבולות התאימות במפורש, מכשירים אותם לביקורת מההתחלה, ומתייחסים לייצור ראיות רגולטוריות כדרישה אדריכלית ולא כתיעוד שנחשב לאחר מחשבה.
