איפה הדאטה שלכם באמת חיה

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

אזור הוא רמז למיקום של העותק הראשי של הדאטה שלכם. זהו. הוא אומר לכם איפה ה-VM עולה ואיפה ה-block volume יושב. הוא לא אומר כלום על איפה הגיבויים נוחתים, מאיזו יבשת רץ הדאשבורד, או איפה יושב מהנדס התמיכה כשהוא פותח חיבור לחשבון שלכם. לבחור eu-west מתפריט נפתח זו ההתחלה של השיחה, לא הסוף שלה.

תושבות, שליטה, ורצפת ה-GDPR

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

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

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

כללי ההעברה של GDPR הם החלק המחייב לגבי דאטה אירופית. העברת מידע אישי אל מחוץ ל-EEA דורשת בסיס חוקי: החלטת התאמה (adequacy), סעיפים חוזיים סטנדרטיים (SCCs), הביטחונות הנכונים. “אנחנו משכפלים גיבויים ל-us-east בשביל עמידות” זו העברה חוצת-גבולות, גם אם אף אחד לא החליט על זה בכוונה. ה-job שמשכפל לא קורא את החוזה.

נקודות הדליפה החמקניות

ה-data plane הוא לעתים רחוקות המקום שבו דברים משתבשים. הדליפות נמצאות בצנרת שאף אחד לא מצלם מסך שלה.

• Control planes. ה-VMs שלכם רצים ב-eu-west, אבל הפאנל, ה-API ומוח התזמור רצים לא פעם מאזור-בית אחד. כל קריאת API, כל מטריקה, כל שינוי קונפיגורציה יכולים לעבור דרך שם. ה-workload מקומי; ה-metadata על ה-workload שלכם נמצאת במטוס.
• גיבויים ו-snapshots. פיצ’רים של עמידות מתים על העתקה בין אזורים לטובת הביטחון. הנדסה הגיונית, הפתעת ציות נוראית. תמיד תבדקו איפה העותק השני חי.
• גישת תמיכה. כשאתם פותחים טיקט ומעניקים גישה, איפה נמצא המהנדס הזה? תחת איזה שיפוט? שכבת תמיכה אופשור יכולה להיות העברה שלא מופיעה בכלל בדיאגרמת הארכיטקטורה שלכם.
• לוגים וטלמטריה. לוגינג מרכזי הוא ערוץ הדלפה בשוגג הקלאסי. כתובות IP, מזהי משתמשים, גופי בקשה — הכל מידע אישי, הכל נשלח בשקט לאן שמקרה ה-log cluster במקרה חי.

תשאלו את הספק שלכם את ארבע השאלות האלה בכתב. השתיקות מספרות לכם יותר מהתשובות.

איך Kaligon Cloud מטפלת בזה

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

הדאטה שלכם נשארת באזור שאתם בוחרים. לא העותק הראשי עם כוכביות — הדאטה. Block volumes משוכפלים בתוך האזור, snapshots נשארים בתוך האזור, ואין job עמידות מפתיע חוצה-אזורים ששולח עותק לאנשהו “בשביל הביטחון”. אין דמי egress בין משאבים באותו אזור, מה שאומר שגם לא דוחפים אתכם כלכלית לפזר דאטה מסביב. לוג הביקורת של 90 הימים נותן לכם מי-עשה-מה, בתוך האזור, כך שאתם יכולים להוכיח את זה במקום להבטיח.

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

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