לא משנה כמה ננתח את המיתוסים והאגדות סביב הציות לתקן 152-FZ, משהו תמיד נשאר מאחורי הקלעים. היום נרצה לדון בניואנסים הלא תמיד ברורים מאליהם, שגם חברות גדולות וגם עסקים קטנים מאוד עשויים להיתקל בהם:
המורכבויות של סיווג נתונים אישיים לקטגוריות - כאשר חנות מקוונת קטנה אוספת נתונים הקשורים לקטגוריה מיוחדת מבלי לדעת על כך כלל;
היכן ניתן לאחסן גיבויים של נתונים אישיים שנאספו ולבצע עליהם פעולות;
מה ההבדל בין תעודה להצהרת תאימות, אילו מסמכים לבקש מהספק וכל הדברים האלה.
לבסוף, נשתף אתכם בחוויה האישית שלנו במעבר ההסמכה. יאללה!
המומחה במאמר של היום יהיה אלכסיי אפנסייב, מומחה בנושאי אבטחת מידע של ספקי הענן IT-GRAD ו-#CloudМТS (חלק מקבוצת MTS).
דקויות של סיווג
לעתים קרובות אנו נתקלים ברצון של לקוחות לקבוע במהירות את רמת האבטחה הנדרשת עבור ISPD ללא ביקורת מערכות מידע. חומרים מסוימים באינטרנט בנושא זה יוצרים את הרושם המוטעה שמדובר במשימה פשוטה וקשה למדי לטעות.
כדי לקבוע את רמת ההגנה האישית (PD), יש להבין אילו נתונים ייאספו ויעובדו על ידי מערכת המידע של הלקוח. לעיתים קשה להגדיר בבירור את דרישות ההגנה ואת קטגוריית ה-PD שעסק מפעיל. אותם סוגים של נתונים אישיים ניתנים להערכה ולסיווג בדרכים שונות לחלוטין. לכן, במקרים מסוימים, חוות הדעת של העסק עשויה להיות שונה מחוות דעתו של רואה החשבון או אפילו של המפקח. בואו נבחן מספר דוגמאות.
צי רכבים. נראה שמדובר בסוג עסק מסורתי למדי. ציי רכב רבים פועלים כבר עשרות שנים, ובעליהם שוכרים יזמים פרטיים ויחידים. ככלל, נתוני עובדים נופלים תחת דרישות UZ-4. עם זאת, כדי לעבוד עם נהגים, יש צורך לא רק לאסוף נתוני שאלונים, אלא גם לבצע בקרה רפואית בשטח הצי לפני תחילת המשמרת, והמידע שנאסף בתהליך נופל מיד לקטגוריה של נתונים רפואיים - וזהו נתונים אישיים מקטגוריה מיוחדת. בנוסף, הצי יכול לבקש אישורים שיאוחסנו לאחר מכן בתיק הנהג. סריקה של אישור כזה בצורה אלקטרונית - נתונים על מצב הבריאות, נתונים אישיים מקטגוריה מיוחדת. משמעות הדבר היא ש-UZ-4 כבר אינו מספיק, נדרש לפחות UZ-3.
חנות מקוונת. נראה כי השמות, האימיילים ומספרי הטלפון שנאספו משתייכים לקטגוריה נגישה באופן כללי. עם זאת, אם הלקוחות שלכם מציינים העדפות גסטרונומיות, כגון חלאל או כשר, מידע כזה עשוי להיחשב כנתונים על שיוך דתי ואמונות. לכן, בעת בדיקה או ביצוע אמצעי בקרה אחרים, המפקח עשוי לסווג את הנתונים שאתם אוספים כקטגוריה מיוחדת של נתונים אישיים. אם חנות מקוונת אספה מידע האם הלקוח שלה מעדיף בשר או דגים, הנתונים יכולים להיות מסווגים כקטגוריה של נתונים אישיים אחרים. אגב, מה עלינו לעשות עם צמחונים? הרי ניתן לסווג זאת גם כאמונות פילוסופיות, השייכות גם לקטגוריה מיוחדת. אבל, מצד שני, זו עשויה להיות פשוט עמדתו של אדם שהוציא בשר מהתזונה שלו. למרבה הצער, אין טבלה שמגדירה בבירור את קטגוריית הנתונים האישיים במצבים "עדינים" כאלה.
סוכנות פרסום בעזרת שירות ענן מערבי מסוים, מעבד נתונים זמינים לציבור של לקוחותיו - שמות מלאים, כתובות דוא"ל ומספרי טלפון. נתונים אישיים אלה, כמובן, קשורים ל-PDn. עולה השאלה: האם זה חוקי לבצע עיבוד כזה? האם ניתן להעביר נתונים כאלה ללא דה-פרסונליזציה מחוץ לפדרציה הרוסית, למשל, לאחסן גיבויים בעננים זרים מסוימים? כמובן שזה אפשרי. לסוכנות יש את הזכות לאחסן נתונים אלה מחוץ לרוסיה, אך האיסוף הראשוני, על פי החקיקה שלנו, חייב להתבצע בשטח הפדרציה הרוסית. אם מגבים מידע כזה, מחשבים סטטיסטיקות מסוימות על סמך זה, עורכים מחקר או מבצעים איתו פעולות אחרות - כל זה יכול להיעשות על משאבים מערביים. הנקודה המרכזית מנקודת מבט של חקיקה היא היכן נאסף ה-PDn. לכן, חשוב לא לבלבל בין האיסוף הראשוני לעיבוד.
כפי שעולה מהדוגמאות הקצרות הללו, עבודה עם PDn אינה תמיד פשוטה וישירה. יש צורך לא רק לדעת שעובדים איתם, אלא גם להיות מסוגלים לסווג אותם נכון, להבין כיצד מערכת המידע פועלת על מנת לקבוע נכון את רמת ההגנה הנדרשת. במקרים מסוימים, עשויה להתעורר השאלה איזה נפח של PDn נחוץ בפועל לארגון כדי לפעול. האם ניתן לסרב לנתונים "הרציניים" ביותר או פשוט מיותרים? בנוסף, הרגולטור ממליץ על ביטול פרסונליזציה של PDn במידת האפשר.
כמו בדוגמאות לעיל, לעיתים ייתכן שתיתקלו במצב שבו גופי הפיקוח מפרשים את נתוני ה-PDn שנאספו בצורה שונה במקצת ממה שהערכתם אותם בעצמכם.
כמובן, ניתן לשכור מבקר או אינטגרטור מערכות כעוזר, אך האם ה"עוזר" יהיה אחראי על ההחלטות המתקבלות במקרה של ביקורת? ראוי לציין שהאחריות תמיד מוטלת על בעל ה-ISPDN - מפעיל המידע האישי. לכן, כאשר חברה מבצעת עבודה כזו, חשוב ליצור קשר עם שחקנים רציניים בשוק השירותים הללו, למשל, חברות המבצעות עבודות הסמכה. לחברות הסמכה ניסיון רב בביצוע עבודות כאלה.
אפשרויות לבניית ISPD
בניית ISPDN היא לא רק סוגיה טכנית, אלא גם סוגיה משפטית במובנים רבים. מנהל ה-IT או מנהל האבטחה בהחלט צריכים להתייעץ עם עורך דין. מכיוון שלחברה לא תמיד יש מומחה עם הפרופיל הדרוש לכם, כדאי לפנות לרואי חשבון ויועצים. רגעים חמקמקים רבים עשויים להיות כלל לא ברורים מאליהם.
הייעוץ יאפשר לכם לקבוע עם אילו נתונים אישיים אתם מתמודדים ומהי רמת ההגנה הנדרשת. בהתאם לכך, תקבלו מושג על מערכות המידע שיש ליצור או להשלים באמצעות כלי אבטחה ופעילות תפעולית.
לעיתים קרובות לחברה יש שתי אפשרויות לבחור מביניהן:
בנו את מערכת המידע המתאימה על פתרונות התוכנה והחומרה שלכם, אולי בחדר השרתים שלכם.
צרו קשר עם ספק ענן ובחרו פתרון אלסטי, כגון "שרת וירטואלי" שכבר קיבל הסמכה.
רוב מערכות המידע (IS) שמעבדות PDn משתמשות בגישה המסורתית, אשר, מנקודת מבט עסקית, קשה לכנותה קלה ומוצלחת. בבחירת אפשרות זו, יש להבין שהפרויקט הטכני יכלול תיאור של הציוד, כולל פתרונות ופלטפורמות תוכנה וחומרה. משמעות הדבר היא שתצטרכו להתמודד עם הקשיים והמגבלות הבאים:
קושי בקנה מידה;
תקופת יישום ארוכה של הפרויקט: יש צורך לבחור, לרכוש, להתקין, להגדיר ולתאר את המערכת;
הרבה עבודת "נייר", למשל, פיתוח חבילת תיעוד מלאה עבור כל מערכת המידע של נתונים אישיים.
בנוסף, עסקים, ככלל, מבינים רק את הרמה ה"עליון" של מערכות המידע שלהם - היישומים העסקיים שהם משתמשים בהם. במילים אחרות, אנשי IT מוסמכים בתחומם הצר. אין הבנה כיצד כל הרמות הנמוכות פועלות: כלי הגנה על תוכנה וחומרה, מערכות אחסון, גיבויים, וכמובן, כיצד להגדיר כלי הגנה בהתאם לכל הדרישות, בונים את חלק ה"חומרה" של התצורה. חשוב להבין: זוהי שכבת ידע עצומה שנמצאת מחוץ לעסק של הלקוח. כאן הניסיון של ספק ענן המספק "שרת וירטואלי" מוסמך יכול להיות שימושי.
בתורם, לספקי ענן יש מספר יתרונות אשר, ללא הגזמה, יכולים לכסות 99% מצרכי העסק בתחום הגנת המידע האישי:
הוצאות הון מומרת להוצאות תפעוליות;
הספק, מצידו, מבטיח את אספקת רמת האבטחה והזמינות הנדרשת על סמך פתרון סטנדרטי מוכח;
אין צורך להעסיק צוות מומחים שיבטיח את תפעול מערכת המידע האישי ברמת החומרה;
ספקים מציעים פתרונות גמישים וגמישים הרבה יותר;
למומחי הספק יש את כל האישורים הנדרשים;
התאימות אינה נמוכה יותר מאשר בעת בניית ארכיטקטורה משלך, תוך התחשבות בדרישות ובהמלצות של הרגולטורים.
המיתוס הישן לפיו לא ניתן להציב מידע אישי בענן עדיין נפוץ ביותר. הוא נכון רק בחלקו: לא באמת ניתן להציב מידע אישי הראשון שנתקלתי בו ענן. יש צורך לעמוד באמצעים טכניים מסוימים, להשתמש בפתרונות מוסמכים מסוימים. אם הספק עומד בכל הדרישות החוקיות, הסיכונים הכרוכים בדליפת PDn ממוזערים. לספקים רבים יש תשתית נפרדת לעיבוד PDn בהתאם ל-152-FZ. עם זאת, יש לגשת לבחירת ספק גם עם הכרת קריטריונים מסוימים, עליהם בהחלט ניגע בהמשך.
לקוחות פונים אלינו לעתים קרובות עם חששות לגבי הצבת PDn בענן של הספק. ובכן, בואו נדון בהן מיד.
נתונים עלולים להיגנב במהלך העברה או הגירה
אין צורך לדאוג בקשר לכך - הספק מציע ללקוח יצירת ערוץ העברת נתונים מאובטח הבנוי על פתרונות מוסמכים, אמצעי אימות משופרים עבור צדדים נגדיים ועובדים. כל שנותר הוא לבחור את שיטות ההגנה המתאימות וליישם אותן כחלק מהעבודה עם הלקוח.
המופע במסכות יבוא וייקח/יאטום/ינתק את השרת מאנרגיה
מובן למדי שלקוחות חוששים שתהליכים עסקיים שלהם יופרעו עקב חוסר שליטה על התשתית. ככלל, זוהי המחשבה של אותם לקוחות שהחומרה שלהם הייתה ממוקמת בעבר בחדרי שרתים קטנים, ולא במרכזי נתונים ייעודיים. במציאות, מרכזי נתונים מצוידים באמצעים מודרניים לאבטחת מידע ופיזית כאחד. כל פעולה במרכז נתונים כזה כמעט בלתי אפשרית לביצוע ללא עילה וניירת מספקים, ופעילויות כאלה דורשות עמידה במספר נהלים. בנוסף, "משיכת" השרת שלך ממרכז הנתונים יכולה להשפיע על לקוחות אחרים של הספק, ואף אחד לא צריך את זה. בנוסף, אף אחד לא יוכל להצביע על השרת הווירטואלי "שלך", כך שאם מישהו רוצה לגנוב אותו או לעשות מסכה, הוא יצטרך להתמודד תחילה עם הרבה בירוקרטיה. במהלך תקופה זו, סביר להניח שיהיה לך זמן לעבור לאתר אחר מספר פעמים.
האקרים יפרצו לענן ויגנבו מידע
האינטרנט והתקשורת המודפסת מלאים בכותרות על איך עוד ענן נפל קורבן לפושעי סייבר, ומיליוני רשומות עם נתונים אישיים דלפו לרשת. ברוב המכריע של המקרים, נקודות תורפה לא נמצאו בצד הספק, אלא במערכות המידע של הקורבנות: סיסמאות חלשות או ברירת מחדל, "חורים" במנועי אתרים ובמאגרי מידע, רשלנות בנאלית של עסקים בבחירת כלי הגנה וארגון הליכי גישה לנתונים. כל הפתרונות המוסמכים נבדקים לאיתור נקודות תורפה. אנו גם עורכים באופן קבוע בדיקות חדירה "בקרה" וביקורות אבטחה באופן עצמאי ובאמצעות ארגונים חיצוניים. עבור הספק, מדובר בעניין של מוניטין ועסק בכללותו.
הספק/עובדי הספק יגנבו מידע אישי למטרות אנוכיות
זהו נושא רגיש למדי. מספר חברות בעולם אבטחת המידע "מפחידות" את לקוחותיהן ומתעקשות ש"עובדים פנימיים מסוכנים יותר מהאקרים מבחוץ". אולי, במקרים מסוימים, זה נכון, אבל אי אפשר לבנות עסק ללא אמון. מעת לעת, מגיעים חדשות לפיהן עובדי הארגון עצמו מדליפים נתוני לקוחות לפורצים, ואבטחת הפנים מאורגנת לעיתים גרוע בהרבה מאשר חיצונית. חשוב להבין שכל ספק גדול אינו מעוניין כלל במקרים שליליים. פעולות עובדי הספק מוסדרות היטב, התפקידים ותחומי האחריות מחולקים. כל תהליכי העסק בנויים בצורה כזו שמקרים של דליפת נתונים הם בלתי סבירים ביותר ותמיד מורגשים לשירותים פנימיים, כך שלקוחות לא צריכים לחשוש מבעיות מצד זה.
אתם משלמים מעט כי אתם משלמים עבור שירותים באמצעות נתוני העסק שלכם.
מיתוס נוסף: לקוח ששוכר תשתית מאובטחת במחיר נוח למעשה משלם עליה באמצעות הנתונים שלו - כך חושבים לעתים קרובות מומחים, שלא אכפת להם לקרוא כמה תיאוריות קונספירציה לפני השינה. ראשית, האפשרות לבצע פעולות כלשהן עם הנתונים שלכם פרט לאלה שצוינו בהזמנה היא למעשה אפסית. שנית, ספק ראוי מעריך את מערכת היחסים שלו אתכם ואת המוניטין שלו - יש לו לקוחות רבים מלבדכם. התרחיש ההפוך סביר יותר, שבו הספק יגן בקנאות על הנתונים של לקוחותיו, עליהם מבוסס עסקיו, בין היתר.
בחירת ספק ענן עבור ISPDN
כיום, השוק מציע פתרונות רבים לחברות שהן מפעילות PDn. להלן רשימה כללית של המלצות לבחירת הפתרון הנכון.
על הספק להיות מוכן לחתום על הסכם רשמי המתאר את התחייבויות הצדדים, הסכם רמת השירות ותחומי האחריות במפתח לעיבוד PDn. למעשה, בינך לבין הספק, בנוסף להסכם השירות, יש לחתום על הוראה לעיבוד PDn. בכל מקרה, כדאי ללמוד אותן בעיון. חשוב להבין את תיחום תחומי האחריות בינך לבין הספק.
שימו לב כי על הסגמנט לעמוד בדרישות, כלומר עליו להיות בעל תעודה המציינת רמת אבטחה לא נמוכה מזו הנדרשת על ידי מערכת המערכות שלכם. קורה שספקים מפרסמים רק את העמוד הראשון של התעודה, שממנו מעט מאוד ברור, או מתייחסים לביקורת או להליכי תאימות מבלי לפרסם את התעודה עצמה ("האם היה שם ילד?"). כדאי לבקש אותה - זהו מסמך ציבורי המציין מי ביצע את ההסמכה, תקופת התוקף, מיקום הענן וכו'.
על הספק לספק מידע על מיקום האתרים שלו (אובייקטים מוגנים) כדי שתוכל לשלוט במיקום הנתונים שלך. נזכיר לך כי האיסוף הראשוני של PDn חייב להתבצע בשטח הפדרציה הרוסית, בהתאם לכך, מומלץ לראות את כתובות מרכז הנתונים בהסכם/תעודה.
על הספק להשתמש בכלי אבטחת מידע מוסמכים וכלי הגנה על מידע קריפטוגרפי. כמובן, רוב הספקים אינם מפרסמים את אמצעי ההגנה הטכניים ואת הארכיטקטורה של הפתרונות שלהם. אבל אתה, כלקוח, לא יכול שלא לדעת על כך. לדוגמה, כדי להתחבר מרחוק למערכת הניהול (פורטל ניהול), עליך להשתמש בכלי אבטחה. הספק לא יוכל לעקוף דרישה זו ויספק לך (או ידרוש ממך להשתמש) בפתרונות מוסמכים. קח את המשאבים לנסיעת ניסיון ותבין מיד כיצד ומה מסודר.
רצוי מאוד שספק הענן יספק שירותים נוספים בתחום אבטחת המידע. אלה יכולים להיות שירותים מגוונים: הגנה מפני התקפות DDoS ו-WAF, שירות אנטי-וירוס או ארגז חול וכו'. כל זה יאפשר לכם לקבל הגנה כשירות, לא להיות מוסחים על ידי בניית מערכות הגנה, אלא להתמודד עם יישומים עסקיים.
הספק חייב להיות בעל רישיון של FSTEC ו-FSB. ככלל, מידע כזה מתפרסם ישירות באתר האינטרנט. הקפידו לבקש מסמכים אלה ולבדוק האם כתובות ספק השירות, שם חברת הספק וכו' מצוינות כהלכה.
בואו נסכם את זה. השכרת תשתית תאפשר לכם לוותר על השקעות CAPEX ולהשאיר רק את יישומי העסק שלכם ואת הנתונים עצמם בתחום האחריות שלכם, ולהעביר את הנטל הכבד של הסמכת חומרה ותוכנה לספק.
איך עברנו את ההסמכה
לאחרונה עברנו בהצלחה את תהליך ההסמכה המחודש של התשתית של "Protected Cloud FZ-152" לעמידה בדרישות העבודה עם נתונים אישיים. העבודה בוצעה על ידי "מרכז ההסמכה הלאומי".
נכון לעכשיו, ה-"Protected Cloud FZ-152" מאושר לאירוח מערכות מידע המעורבות בעיבוד, אחסון או העברה של נתונים אישיים (ISPD) בהתאם לדרישות רמה UZ-3.
הליך ההסמכה כרוך בבדיקת עמידה של תשתית ספק הענן ברמת ההגנה. הספק עצמו מספק את שירות ה-IaaS ואינו מפעיל של נתונים אישיים. התהליך כרוך בהערכת אמצעים ארגוניים (תיעוד, הזמנות וכו') וטכניים (הגדרת כלי אבטחה וכו').
אי אפשר לקרוא לזה טריוויאלי. למרות העובדה ש-GOST על תוכניות ושיטות לביצוע פעילויות הסמכה הופיע בשנת 2013, תוכניות מחמירות לאובייקטי ענן עדיין אינן קיימות. מרכזי הסמכה מפתחים תוכניות אלה על סמך המומחיות שלהם. עם הופעתן של טכנולוגיות חדשות, התוכניות הופכות מורכבות ומודרניות יותר, בהתאם לכך, על המאשר להיות בעל ניסיון בעבודה עם פתרונות ענן ולהבין את הפרטים הספציפיים.
במקרה שלנו, האובייקט המוגן מורכב משני מיקומים.
משאבי ענן (שרתים, מערכות אחסון, תשתית רשת, כלי אבטחה וכו') ממוקמים ישירות במרכז הנתונים. כמובן, מרכז נתונים וירטואלי כזה מחובר לרשתות ציבוריות, ובהתאם לכך יש לעמוד בדרישות מסוימות של חומת אש, כגון שימוש בחומות אש מאושרות.
החלק השני של האובייקט הוא כלי ניהול ענן. אלו הן תחנות עבודה (תחנת עבודה של מנהל) מהן מנוהל הסגמנט המוגן.
המיקומים מחוברים באמצעות VPN- ערוץ שנבנה על כלי הגנה על מידע קריפטוגרפי.
מאחר וטכנולוגיות וירטואליזציה יוצרות את התנאים המוקדמים להופעת איומים, אנו משתמשים גם בכלי אבטחה מוסמכים נוספים.
תרשים מבני "דרך עיני המאשר"
אם הלקוח דורש הסמכה של ISPDN שלו, לאחר שכירת IaaS, הוא יצטרך רק לבצע הערכה של מערכת המידע מעל רמת מרכז הנתונים הווירטואלי. הליך זה כולל בדיקת התשתית והתוכנה בה נעשה שימוש. מכיוון שניתן להתייחס לתעודת הספק עבור כל בעיות התשתית, תצטרכו לעבוד רק עם התוכנה.
הפרדה ברמת ההפשטה
לסיכום, נספק רשימת בדיקה קטנה לחברות שכבר עובדות עם PDn או שרק מתכננות לעשות זאת. אז, איך לעבד ולא להישרף.
כדי לבצע ביקורת ולפתח מודלים של איומים ופריצות, הזמינו יועץ מנוסה ממעבדות הסמכה שיסייע בפיתוח המסמכים הדרושים ויוביל אתכם לשלב הפתרונות הטכניים.
בבחירת ספק שירותי ענן, שימו לב לזמינות של תעודה. כדאי שהחברה פרסמה אותה בפומבי ישירות באתר האינטרנט. הספק חייב להיות בעל רישיון של FSTEC ו-FSB, והשירות שהוא מציע חייב להיות מאושר.
ודאו שיש לכם חוזה רשמי והזמנה חתומה לעיבוד PDn. בהתבסס על כך, תוכלו לבצע גם בדיקת תאימות וגם הסמכה של ISPDN. אם עבודות אלו בשלב הפרויקט הטכני ויצירת התכנון והתיעוד הטכני נראות לכם מעיקות, כדאי לפנות לחברות ייעוץ חיצוניות מבין מעבדות ההסמכה.
אם אתם מעוניינים בעיבוד נתונים אישיים, נשמח לראותכם בוובינר שיתקיים ב-18 בספטמבר, ביום שישי הקרוב. .
מקור: www.habr.com
