IaaS 152-FZ: אז אתה צריך אבטחה

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

• דקויות של סיווג PD לקטגוריות - כאשר חנות מקוונת קטנה אוספת נתונים הקשורים לקטגוריה מיוחדת מבלי לדעת על כך;

• שבו אתה יכול לאחסן גיבויים של PD שנאסף ולבצע עליהם פעולות;

• מה ההבדל בין אישור למסקנה של ציות, אילו מסמכים כדאי לבקש מהספק וכאלה.

לבסוף, נשתף אתכם בניסיון שלנו במעבר ההסמכה. ללכת!

המומחה במאמר היום יהיה אלכסיי אפנסייב, IS מומחה לספקי ענן IT-GRAD ו-#CloudMTS (חלק מקבוצת MTS).

דקויות הסיווג

לעתים קרובות אנו נתקלים ברצון של לקוח לקבוע במהירות, ללא ביקורת IS, את רמת האבטחה הנדרשת עבור ISPD. חלק מהחומרים באינטרנט בנושא זה יוצר רושם מוטעה שמדובר במשימה פשוטה ודי קשה לטעות.

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

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

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

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

כפי שעולה מדוגמאות קצרות אלו, העבודה עם נתונים אישיים אינה תמיד פשוטה ופשוטה. אתה צריך לא רק לדעת שאתה עובד איתם, אלא גם להיות מסוגל לסווג אותם נכון, להבין איך עובד ה-IP כדי לקבוע נכון את רמת האבטחה הנדרשת. במקרים מסוימים עלולה להתעורר השאלה כמה נתונים אישיים הארגון צריך בפועל כדי לפעול. האם אפשר לסרב לנתונים הכי "רציניים" או פשוט מיותרים? בנוסף, הרגולטור ממליץ על ביטול פרסונליות של נתונים אישיים במידת האפשר. 

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

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

אפשרויות לבניית ISPD

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

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

לעתים קרובות הבחירה עבור חברה היא בין שתי אפשרויות:

1. בנה את ה-IS המתאים על פתרונות החומרה והתוכנה שלך, אולי בחדר השרתים שלך.

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

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

• קושי בקנה מידה;

• תקופת יישום ארוכה של פרויקט: יש צורך לבחור, לרכוש, להתקין, להגדיר ולתאר את המערכת;

• הרבה עבודת "נייר", כדוגמה - פיתוח חבילת תיעוד שלמה לכל ה-ISPD.

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

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

• עלויות הון מומרות לעלויות תפעול;

• הספק מצדו מבטיח מתן רמת אבטחה וזמינות הנדרשת על בסיס פתרון סטנדרטי מוכח;

• אין צורך להחזיק צוות מומחים שיבטיח את פעולת ה-ISPD ברמת החומרה;

• ספקים מציעים פתרונות גמישים ואלסטיים הרבה יותר;

• למומחים של הספק יש את כל האישורים הדרושים;

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

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

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

• נתונים עלולים להיגנב במהלך שידור או העברה

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

• מסכות מופע יבואו ויוציאו/אוטמות/ מנתקים את החשמל לשרת

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

• האקרים יפרצו את הענן ויגנבו נתונים

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

• הספק/עובדים של הספק יגנבו נתונים אישיים למטרות רווח אישי

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

• אתה משלם מעט כי אתה משלם עבור שירותים עם הנתונים העסקיים שלך.

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

בחירת ספק ענן עבור ISPD

כיום, השוק מציע פתרונות רבים לחברות שהן מפעילות PD. להלן רשימה כללית של המלצות לבחירה הנכונה.

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

• שימו לב שהפלח חייב לעמוד בדרישות, מה שאומר שהוא חייב להיות בעל תעודה המעידה על רמת אבטחה שאינה נמוכה מזו הנדרשת ב-IP שלכם. קורה שספקים מפרסמים רק את העמוד הראשון של התעודה, שממנו מעט ברור, או מתייחסים לביקורות או נהלי ציות מבלי לפרסם את התעודה עצמה ("היה ילד?"). כדאי לבקש זאת - זהו מסמך ציבורי המציין מי ביצע את ההסמכה, תקופת התוקף, מיקום הענן וכו'.

• על הספק לספק מידע על היכן נמצאים האתרים שלו (אובייקטים מוגנים) כדי שתוכל לשלוט במיקום הנתונים שלך. נזכיר לך שהאיסוף הראשוני של נתונים אישיים חייב להתבצע בשטח הפדרציה הרוסית; בהתאם לכך, מומלץ לראות את הכתובות של מרכז הנתונים בחוזה/תעודה.

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

• רצוי מאוד שספק הענן יספק שירותים נוספים בתחום אבטחת המידע. אלו יכולים להיות שירותים שונים: הגנה מפני התקפות DDoS ו-WAF, שירות אנטי וירוס או ארגז חול וכו'. כל זה יאפשר לכם לקבל הגנה כשירות, לא להסיח את דעתכם ממערכות מיגון מבנים, אלא לעבוד על אפליקציות עסקיות.

• הספק חייב להיות בעל רישיון של FSTEC ו-FSB. ככלל, מידע כזה מפורסם ישירות באתר. הקפידו לבקש מסמכים אלו ולבדוק האם הכתובות למתן שירותים, שם חברת הספק וכדומה נכונות. 

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

איך עברנו את ההסמכה

לאחרונה, עברנו בהצלחה את האישור מחדש של התשתית של "Secure Cloud FZ-152" לעמידה בדרישות לעבודה עם נתונים אישיים. העבודה בוצעה על ידי מרכז ההסמכה הלאומי.

נכון לעכשיו, "FZ-152 Secure Cloud" מוסמך לאירוח מערכות מידע המעורבות בעיבוד, אחסון או שידור של נתונים אישיים (ISPDn) בהתאם לדרישות של רמה UZ-3.

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

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

במקרה שלנו, החפץ המוגן מורכב משני מקומות.

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

• החלק השני של האובייקט הוא כלי ניהול ענן. אלו תחנות עבודה (תחנות עבודה של מנהל) מהן מנוהל הקטע המוגן.

מיקומים מתקשרים דרך ערוץ VPN בנוי על CIPF.

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

דיאגרמת בלוקים "דרך עיני המעריך"

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

הפרדה ברמת ההפשטה

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

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

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

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

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

מקור: www.habr.com