כיצד להתיידד עם GOST R 57580 ווירטואליזציה של מיכל. תגובת הבנק המרכזי (ודעתנו בעניין)

לא מזמן ביצענו הערכה נוספת של עמידה בדרישות של GOST R 57580 (להלן פשוט GOST). הלקוח הוא חברה המפתחת מערכת תשלום אלקטרונית. המערכת רצינית: יותר מ-3 מיליון משתמשים, יותר מ-200 אלף עסקאות מדי יום. לוקחים שם ברצינות רבה את אבטחת המידע.

במהלך תהליך ההערכה, הלקוח הודיע ​​כלאחר יד שמחלקת הפיתוח, בנוסף למכונות וירטואליות, מתכננת להשתמש בקונטיינרים. אבל עם זה, הוסיף הלקוח, יש בעיה אחת: ב-GOST אין מילה על אותו Docker. מה עלי לעשות? כיצד להעריך את אבטחת המכולות?

זה נכון, GOST כותב רק על וירטואליזציה של חומרה - על איך להגן על מכונות וירטואליות, היפרוויזר ושרת. ביקשנו הבהרות מהבנק המרכזי. התשובה תמהה אותנו.

GOST ווירטואליזציה

ראשית, נזכיר כי GOST R 57580 הוא תקן חדש המפרט "דרישות להבטחת אבטחת מידע של ארגונים פיננסיים" (FI). FIs אלה כוללים מפעילים ומשתתפי מערכות תשלום, ארגוני אשראי וארגונים שאינם אשראי, מרכזי תפעול וסליקה.

מ-1 בינואר 2021, FI נדרשים לנהל הערכת עמידה בדרישות ה- GOST החדש. אנחנו, ITGLOBAL.COM, חברת ביקורת המבצעת הערכות מסוג זה.

ל-GOST יש תת-סעיף המוקדש להגנה על סביבות וירטואליות - מס' 7.8. המונח "וירטואליזציה" לא מצוין שם; אין חלוקה לחומרה ולווירטואליזציה של מיכל. כל מומחה IT יגיד שמבחינה טכנית זה לא נכון: מכונה וירטואלית (VM) ומיכל הן סביבות שונות, עם עקרונות בידוד שונים. מנקודת המבט של הפגיעות של המארח עליו פרוסים קונטיינרים VM ו-Docker, זה גם הבדל גדול.

מסתבר שגם הערכת אבטחת המידע של VMs ומכולות צריכה להיות שונה.

השאלות שלנו לבנק המרכזי

שלחנו אותם למחלקת אבטחת מידע בבנק המרכזי (אנו מציגים את השאלות בצורה מקוצרת).

1. כיצד לשקול מכולות וירטואליות מסוג Docker בעת הערכת תאימות GOST? האם נכון להעריך את הטכנולוגיה בהתאם לסעיף קטן 7.8 של GOST?
2. כיצד להעריך כלי ניהול קונטיינרים וירטואליים? האם ניתן להשוות אותם לרכיבי וירטואליזציה של שרתים ולהעריך אותם לפי אותו תת-סעיף של GOST?
3. האם אני צריך להעריך בנפרד את אבטחת המידע בתוך מכולות Docker? אם כן, אילו אמצעי הגנה יש לשקול לכך במהלך תהליך ההערכה?
4. אם קונטיינריזציה משולה לתשתית וירטואלית ומוערכת בהתאם לסעיף קטן 7.8, כיצד מיושמות דרישות GOST ליישום כלי אבטחת מידע מיוחדים?

תגובת הבנק המרכזי

להלן הקטעים העיקריים.

"GOST R 57580.1-2017 קובע דרישות ליישום באמצעות יישום אמצעים טכניים ביחס לאמצעים הבאים ZI סעיף קטן 7.8 של GOST R 57580.1-2017, אשר, לדעת המחלקה, ניתן להרחיב למקרים של שימוש בווירטואליזציה של מיכלים טכנולוגיות, תוך התחשבות בדברים הבאים:

• יישום אמצעים ZSV.1 - ZSV.11 לארגון זיהוי, אימות, הרשאה (בקרת גישה) בעת יישום גישה לוגית למכונות וירטואליות ורכיבי שרת וירטואליזציה עשויים להיות שונים ממקרים של שימוש בטכנולוגיית וירטואליזציה של מיכל. בהתחשב בכך, על מנת ליישם מספר צעדים (לדוגמה, ZVS.6 ו- ZVS.7), אנו מאמינים שניתן להמליץ ​​למוסדות פיננסיים לפתח אמצעי פיצוי שירדוף אחר אותן מטרות;
• יישום אמצעים ZSV.13 - ZSV.22 לארגון ובקרה של אינטראקציית מידע של מכונות וירטואליות מספק פילוח של רשת המחשבים של ארגון פיננסי כדי להבחין בין אובייקטי אינפורמטיזציה המיישמים טכנולוגיית וירטואליזציה ושייכים למעגלי אבטחה שונים. בהתחשב בכך, אנו מאמינים שמומלץ להקפיד על פילוח מתאים בעת שימוש בטכנולוגיית וירטואליזציה של קונטיינרים (הן ביחס לקונטיינרים וירטואליים הניתנים להפעלה והן ביחס למערכות וירטואליזציה המשמשות ברמת מערכת ההפעלה);
• יישום האמצעים ZSV.26, ZSV.29 - ZSV.31 לארגון ההגנה על תמונות של מכונות וירטואליות צריך להתבצע באנלוגיה גם על מנת להגן על תמונות בסיסיות ועדכניות של קונטיינרים וירטואליים;
• יישום האמצעים ZVS.32 - ZVS.43 להקלטת אירועי אבטחת מידע הקשורים לגישה למכונות וירטואליות ולרכיבי וירטואליזציה של שרתים צריך להתבצע באנלוגיה גם ביחס לאלמנטים של סביבת הוירטואליזציה המטמיעים טכנולוגיית וירטואליזציה של קונטיינרים".

מה זה אומר

שתי מסקנות עיקריות מתגובת מחלקת אבטחת מידע בבנק המרכזי:

• אמצעים להגנה על קונטיינרים אינם שונים מאמצעים להגנה על מכונות וירטואליות;
• מכאן נובע כי בהקשר של אבטחת מידע, הבנק המרכזי משווה שני סוגי וירטואליזציה - קונטיינרים של Docker ו-VMs.

בתגובה מוזכרים גם "אמצעי פיצוי" שיש ליישם כדי לנטרל את האיומים. פשוט לא ברור מהם ה"אמצעים המפצים" הללו וכיצד למדוד את הלימותם, השלמות והיעילות שלהם.

מה רע בעמדת הבנק המרכזי?

אם אתה משתמש בהמלצות הבנק המרכזי במהלך הערכה (והערכה עצמית), עליך לפתור מספר קשיים טכניים והגיוניים.

• כל מיכל בר הפעלה מצריך התקנת תוכנת הגנת מידע (IP) עליו: אנטי וירוס, ניטור שלמות, עבודה עם יומנים, מערכות DLP (Data Leak Prevention) וכן הלאה. את כל זה ניתן להתקין על VM ללא בעיות, אבל במקרה של קונטיינר, התקנת אבטחת מידע היא מהלך אבסורדי. המיכל מכיל את הכמות המינימלית של "ערכת גוף" הדרושה כדי שהשירות יפעל. התקנת SZI בו סותרת את משמעותה.
• יש להגן על תמונות מיכל על פי אותו עיקרון; גם איך ליישם זאת לא ברור.
• GOST דורש הגבלת גישה לרכיבי וירטואליזציה של השרת, כלומר, ל-Hypervisor. מה נחשב רכיב שרת במקרה של Docker? האם זה לא אומר שכל קונטיינר צריך להיות מופעל על מארח נפרד?
• אם עבור וירטואליזציה קונבנציונלית ניתן לתחום VMs לפי קווי מתאר אבטחה ומקטעי רשת, אז במקרה של קונטיינרים של Docker בתוך אותו מארח, זה לא המקרה.

בפועל, סביר להניח שכל מבקר יעריך את אבטחת המכולות בדרכו שלו, על סמך הידע והניסיון שלו. ובכן, או אל תעריך את זה בכלל, אם אין לא אחד ולא השני.

ליתר בטחון, נוסיף שהחל מ-1 בינואר 2021, הציון המינימלי חייב להיות לא נמוך מ-0,7.

אגב, אנו מפרסמים באופן קבוע תגובות והערות מהרגולטורים הקשורים לדרישות של GOST 57580 ותקנות הבנק המרכזי שלנו ערוץ טלגרם.

מה לעשות

לדעתנו, לארגונים פיננסיים יש רק שתי אפשרויות לפתרון הבעיה.

1. הימנע מיישום מכולות

פתרון למי שמוכן להרשות לעצמו להשתמש רק בווירטואליזציה של חומרה ובמקביל חושש מדירוג נמוך לפי GOST וקנסות מהבנק המרכזי.

בנוסף: קל יותר לעמוד בדרישות של סעיף קטן 7.8 של GOST.

מינוס: נצטרך לנטוש כלי פיתוח חדשים המבוססים על וירטואליזציה של קונטיינרים, בפרט Docker ו-Kubernetes.

2. לסרב לעמוד בדרישות של סעיף קטן 7.8 של GOST

אך במקביל, יישם את השיטות המומלצות בהבטחת אבטחת מידע בעבודה עם קונטיינרים. זהו פתרון למי שמעריך טכנולוגיות חדשות וההזדמנויות שהן מספקות. ב"שיטות עבודה מומלצות" אנו מתכוונים לנורמות ותקנים המקובלים בתעשייה להבטחת האבטחה של מכולות Docker:

• אבטחה של מערכת ההפעלה המארח, רישום מוגדר כהלכה, איסור על חילופי נתונים בין מיכלים וכן הלאה;
• שימוש בפונקציית Docker Trust לבדיקת תקינות התמונות ושימוש בסורק הפגיעות המובנה;
• אסור לשכוח את אבטחת הגישה מרחוק ואת מודל הרשת בכללותו: התקפות כמו זיוף ARP והצפה של MAC לא בוטלו.

בנוסף: אין הגבלות טכניות על השימוש בווירטואליזציה של מיכל.

מינוס: יש סבירות גבוהה שהרגולטור יעניש על אי עמידה בדרישות GOST.

מסקנה

הלקוח שלנו החליט לא לוותר על מכולות. במקביל, הוא נאלץ לשקול מחדש באופן משמעותי את היקף העבודה ואת עיתוי המעבר לדוקר (הם נמשכו חצי שנה). הלקוח מבין היטב את הסיכונים. הוא גם מבין שבמהלך ההערכה הבאה של עמידה ב-GOST R 57580, הרבה יהיה תלוי במבקר.

מה היית עושה במצב הזה?

מקור: www.habr.com