בלוג

לא כל כך נעים לראות אתר סגור; זה במיוחד נכון כאשר מדובר על אתר MegaUpload שנסגר בסוף השבוע האחרון על ידי הרשויות הפדראליות בארצות הברית לאחר חשד להפרת זכויות יוצרים שבוצעו על ידי האתר עצמו, וחשוב לזכור את זה: האתר עצמו, שכן החוק בארצות הברית אומר בצורה די ברורה שאתרי אינטרנט לא יהיו אחראים לתוכן הגולשים אם הם הפעילו מדיניות של הודעה והסרה (ראו את סעיף 512 לחוק זכויות היוצרים האמריקאי 00-55902 UMG v. Veoh), או כאשר מדובר על סגירת אתרים בישראל ללא צו שיפוטי.

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

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

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

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

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

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

תקנה 2 קובעת כי בעל מאגר יוציא מסמך מחייב שיבהיר (1) מהם פרטי המידע שנשמרים במאגר; (2) מהם המטרות לשימוש במאגר; (3) יפרט האם מידע מהמאגר יוצא מחוץ לגבולות המדינה; (4) האם מחזיק מאגר המידע מעבד את המידע; (5) הסיכונים לפגיעה בשלמות המידע, בחשיפתו של המידע וכיצד הוא מתכנן להתמודד איתם.

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

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

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

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

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

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

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

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

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

תקנה 11 מחייבת את אחראי האבטחה לנהל תיעוד של אירועי אבטחה ובמאגרים ברמה בינונית או גבוהה אף לקבוע נהלים לטיפול באירועי אבטחה.

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

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

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

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

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

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

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