"וכך זה יעשה": שספקי ענן לא מנהלים משא ומתן על נתונים אישיים

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

צילום מאת סטיב קריספ, רויטרס

דברים מוזרים! נכנסנו לאתר של חברת X, למדנו את מסמכי ההסמכה שלהם, נענענו בראשנו והבנו: יש הרבה שאלות פתוחות בהצבת נתונים אישיים ויש להתייחס אליהן ביסודיות. זה מה שנעשה בפוסט הזה.

איך הכל צריך לעבוד

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

סוגי האיומים הנוכחיים מוגדרים ב צו של ממשלת הפדרציה הרוסית מס' 1119 מיום 1 בנובמבר 2012 "על אישור דרישות להגנה על נתונים אישיים במהלך עיבודם במערכות מידע אישיות":

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

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

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

העיקר בהגדרות הללו הוא נוכחותן של יכולות לא מתועדות (לא מוצהרות). כדי לאשר את היעדר יכולות תוכנה לא מתועדות (במקרה של הענן, מדובר ב-hypervisor), ההסמכה מתבצעת על ידי FSTEC מרוסיה. אם מפעיל ה-PD מקבל שאין יכולות כאלה בתוכנה, אז האיומים המתאימים אינם רלוונטיים. איומים מסוגים 1 ו-2 נחשבים לעתים רחוקות מאוד רלוונטיים על ידי מפעילי PD.

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

FSTEC מפרטת בבירור את כל האיומים העיקריים ב NOS (בסיס נתונים של איומים). ספקי תשתית ענן ומעריכים משתמשים במסד נתונים זה בעבודתם. להלן דוגמאות לאיומים:

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

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

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

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

ובהתאם ל בהוראת FSTEC מס' 21 מתאריך 18 בפברואר 2013, על ה-Hypervisor להיות מאושר כלא-NDV ברמה 4, אחרת השימוש במידע אישי ברמה 1 ו-2 איתו יהיה בלתי חוקי ("סעיף 12. ... להבטחת רמות 1 ו-2 של אבטחת מידע אישי, וכן להבטיח רמה 3 של אבטחת מידע אישי במערכות מידע שעבורן מסווגים איומים מסוג 2 כעדכניים, נעשה שימוש בכלי אבטחת מידע אשר תוכנתם נבדק לפחות לפי 4 רמות שליטה על היעדר יכולות לא מוצהרות").

רק hypervisor אחד, שפותח ברוסיה, הוא בעל רמת ההסמכה הנדרשת, NDV-4. אופק שמש. בלשון המעטה, לא הפתרון הפופולרי ביותר. עננים מסחריים בנויים בדרך כלל על בסיס VMware vSphere, KVM, Microsoft Hyper-V. אף אחד מהמוצרים הללו אינו מוסמך NDV-4. למה? סביר להניח שקבלת הסמכה כזו ליצרנים עדיין אינה מוצדקת כלכלית.

וכל מה שנותר לנו לנתונים אישיים ברמה 1 ו-2 בענן הציבורי הוא Horizon BC. עצוב אבל נכון.

איך הכל (לדעתנו) באמת עובד

במבט ראשון, הכל די קפדני: יש לחסל את האיומים הללו על ידי הגדרה נכונה של מנגנוני ההגנה הסטנדרטיים של hypervisor מוסמך על פי NDV-4. אבל יש פרצה אחת. בהתאם לצו FSTEC מס' 21 ("סעיף 2 אבטחת הנתונים האישיים בעת עיבודם במערכת המידע האישי (להלן מערכת המידע) מובטחת על ידי המפעיל או מי שמעבד נתונים אישיים מטעם המפעיל בהתאם ל- חֲקִיקָה הפדרציה הרוסית"), ספקים מעריכים באופן עצמאי את הרלוונטיות של איומים אפשריים ובוחרים אמצעי הגנה בהתאם. לכן, אם לא תקבל את האיומים UBI.44 ו-UBI.101 כעדכניים, אזי לא יהיה צורך להשתמש ב-hypervisor מוסמך לפי NDV-4, שזה בדיוק מה שצריך לספק הגנה מפניהם. וזה יספיק כדי לקבל תעודת תאימות של הענן הציבורי לרמות 1 ו-2 של אבטחת מידע אישי, ש-Roskomnadzor תהיה מרוצה ממנה לחלוטין.

כמובן, בנוסף לרוסקומנדזור, FSTEC עשויה להגיע עם בדיקה - והארגון הזה הרבה יותר קפדני בנושאים טכניים. היא כנראה תתעניין מדוע דווקא האיומים UBI.44 ו-UBI.101 נחשבו ללא רלוונטיים? אבל בדרך כלל FSTEC מבצעת בדיקה רק כאשר היא מקבלת מידע על אירוע משמעותי כלשהו. במקרה זה, השירות הפדרלי מגיע לראשונה למפעיל הנתונים האישיים - כלומר הלקוח של שירותי הענן. במקרה הגרוע, המפעיל מקבל קנס קטן - למשל על טוויטר בתחילת השנה בסדר במקרה דומה הסתכם ב-5000 רובל. ואז FSTEC ממשיכה לספק שירותי הענן. אשר בהחלט עלול להיפסל רישיון עקב אי עמידה בדרישות הרגולטוריות - ומדובר בסיכונים שונים לחלוטין, הן עבור ספקית הענן והן עבור לקוחותיה. אבל, אני חוזר, כדי לבדוק FSTEC, אתה בדרך כלל צריך סיבה ברורה. אז ספקי ענן מוכנים לקחת סיכונים. עד לאירוע החמור הראשון.

יש גם קבוצה של ספקים "אחראים יותר" המאמינים שאפשר לסגור את כל האיומים על ידי הוספת תוסף כמו vGate ל-Hypervisor. אבל בסביבה וירטואלית המופצת בין לקוחות עבור איומים מסוימים (לדוגמה, UBI.101 לעיל), מנגנון הגנה יעיל יכול להיות מיושם רק ברמה של hypervisor מוסמך לפי NDV-4, שכן כל מערכות תוסף ל- הפונקציות הסטנדרטיות של ה-Hypervisor לניהול משאבים (במיוחד RAM) אינן משפיעות.

איך אנחנו עובדים

יש לנו קטע ענן מיושם על hypervisor מאושר על ידי FSTEC (אך ללא הסמכה ל-NDV-4). פלח זה מאושר, כך שניתן לאחסן נתונים אישיים בענן על בסיסו 3 ו-4 רמות אבטחה - אין צורך להקפיד על דרישות להגנה מפני יכולות לא מוכרזות כאן. הנה, אגב, הארכיטקטורה של קטע הענן המאובטח שלנו:

מערכות לנתונים אישיים 1 ו-2 רמות אבטחה אנו מיישמים רק על ציוד ייעודי. רק במקרה הזה, למשל, האיום של UBI.101 ממש לא רלוונטי, שכן מדפי שרתים שאינם מאוחדים על ידי סביבה וירטואלית אחת לא יכולים להשפיע זה על זה גם כשהם נמצאים באותו מרכז נתונים. למקרים כאלה אנו מציעים שירות השכרת ציוד ייעודי (הוא נקרא גם Hardware as a service).

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

פלט

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

מקור: www.habr.com