לא כל כך נעים לראות אתר סגור: כיצד לאבטח מידע באתר אינטרנט?

לא כל כך נעים לראות אתר סגור; זה במיוחד נכון כאשר מדובר על אתר 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: אפשרות להתאוששות במקרה אסון).

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

16 תגובות ל-“לא כל כך נעים לראות אתר סגור: כיצד לאבטח מידע באתר אינטרנט?

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

  2. חץ,

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

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

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

  3. זה לא ממש אפשרי. אי אפשר לחייב את אמזון (לדוגמא) לעמוד ברמה מסויימת של אבטחה, וגם ספקים בארץ לא יכולים כל כך…
    אני אנסה לתאר את זה כך: אם אני פותח קניון וירטואלי ואתה פותח שם חנות, אז כל מה שאתה אומר נכון וצודק.
    אם לעומת זאת אני מציע שרות של אחסון משותף שבו אתה יהונתן מאחסן בלוג ומחר אתה מקים חנות לחבר שלך על אותו אחסון – לי אין שום אפשרות לדעת זאת, האחסון שלך הוא יחסית עצמאי, ואתה יכול להתקין מה שאתה רוצה, ואין לשום ספק משאבים לבוא ולרוץ אחרי הלקוחות כדי לבדוק מה הם האתרים שהוא מאחסן, אם המידע מוצפן וכו'.
    יותר גרוע — כשאתה לוקח שרת VPS, לי כספק אין שום כניסה אליו ובוודאי שאינני יכול לבדוק מה המאגר שיש (אם יש) האם מוצפן וכו'. השרת הוא שלך ואתה האחראי היחיד לגבי מה שקורה שם.

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

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

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

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

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

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

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

    אלע"ד – אני לא עורך דין.

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

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

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

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

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

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

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

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

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

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

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

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

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *