במי אתם בוטחים כשאתם מריצים בעצמכם את שרת ה-VPN

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

שלב 1: למפות את הצדדים

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

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

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

שלב 2: לרשום מה הרווחתם

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

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

שלב 3: לקבל את רשימת התחזוקה

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

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

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

שלב 4: לוותר על הנחת האנונימיות

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

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

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

שלב 5: לבחור בזה מסיבה מוצהרת

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

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

שלב 6: לתכנן את היציאה

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

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