האם אתם עדיין זקוקים ל-VPN אתר כשהאפליקציה משתמשת ב-mTLS וב-SSO?
עברו על הערוצים שהכניסה לאפליקציה שלכם לעולם אינה מכסה, ואז החליטו אם הגישה לרשת הפרטית מיותרת או שעדיין היא הדרך היחידה אל המארח.
אתם מתחברים ב-mTLS, לוח הבקרה נטען, והטענה שה-VPN של האתר מיותר כעת נשמעת סבירה בערך כל עוד לא תצטרכו לשחזר מסד נתונים בשתיים לפנות בוקר. גבול ה-TLS של האפליקציה מתאר ערוץ אחד. המארח, מסד הנתונים, יעד הגיבוי וחשבון הענן נושאים כל אחד את נתיב הכניסה שלו, את הזהות שלו ואת המאשר שלו, ואף אחד מהם אינו מתורגל בכניסה מוצלחת.
צאו החוצה ממסך הכניסה
התחברו כפי שמשתמש רגיל עושה ורשמו כל קפיצה שהבקשה נוגעת בה: דפדפן, קצה, מאזין האפליקציה, מאגר הפעלות, API צד אחורי. לכל קפיצה יש בעלים והחלטת אימות. כעת חזרו על המסלול עבור מי שמטל תיקונים במארח, ועבור המשימה שכותבת את הגיבוי הלילי. המסלולים האלה מתפצלים בדרך כלל כבר בקפיצה הראשונה.
הפיצול הזה הוא השאלה שראויה לתשובה. VPN אתר מיותר רק כאשר לכל ערוץ במסלול השני יש מדיניות כניסה והרשאה שעומדת בפני עצמה.
חמישה ערוצים שהכניסה לאפליקציה לעולם אינה מכסה
הטבלה למטה היא תבנית מלאי, לא רשימת בדיקה לפריסה. מלאו את העמודה השנייה במה שהסביבה שלכם באמת אוכפת היום.
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
שיתוף ספק זהות אינו מאחד את ההרשאות האלה. משתמש שמורשה לשלוח בקשת API אינו מורשה בכך להחליף דיסק של מכונה וירטואלית או לשחזר מסד נתונים באמצעות פרטי הכניסה של האפליקציה. תקציר ארכיטקטורת האפס אמון של NIST שומר בדיוק מסיבה זו על הפרדה בין אימות והרשאה של משאבים לבין מיקום ברשת.
מהנדס תמיכה שיכול לקרוא קריאה אינו מורשה בכך לפתוח קונסולה במארח שמאחוריה.
נתיב הוא אמיתי רק אם החלופה נשארת סגורה
הגבלת הנגישות למאזינים ניהוליים פרטיים היא תחליף לגיטימי ל-VPN אתר, בתנאי שההגבלה נאכפת ולא רק מצוירת. הכשל הרגיל הוא מאזין חלופי שאיש לא זכר: שירות שעדיין קשור לכל הממשקים, כלל קבוצת אבטחה שנפתח לקבלן, פורט ניהול שנגיש מהאינטרנט.
בדקו מאזינים ולא תרשימים. במארח, פרטו מה באמת קשור באמצעות ss -ltnp ואשרו שפורטי הניהול יושבים על כתובת פרטית. בקונסולת הענן, קראו את כללי הכניסה של תת-הרשת של עומס העבודה וחפשו 0.0.0.0/0 על כל דבר ניהולי. לאחר מכן נסו את החיבור מחוץ לנתיב הפרטי, כי הבדיקה הזו היא זו שעונה על השאלה.
כלל אחד פתוח לעולם ב-SSH מבטל כל טיעון שהציע תכנון המנהרה.
כתבו את המפה לפני שאתם משווים תכנונים
לכל שורה במלאי, רשמו מי מאשר זהויות, מי מעדכן את כללי הגישה, מי מסיר פרטי כניסה כשמישהו עוזב, ומי מטפל בשחזור כשהנתיב עצמו נשבר. ארבעה שמות לשורה מספיקים כדי לחשוף את השורות שבהן התשובה היא חשבון משותף ודף ויקי בן שלוש שנים.
לאחר מכן אמתו הרשאה אחת וסירוב אחד לכל ערוץ. הרשאה מוכיחה שהזהות המיועדת יכולה להגיע למשאב בנתיב המיועד. סירוב מוכיח שזהות דומה אינה יכולה, וזו הבדיקה שאנשים מדלגים עליה, ולכן מאזינים חלופיים שורדים ביקורות. השוו את התכנון המוצע לתוצאות האלה, ולא לתצורת ה-TLS של האפליקציה, שמעולם לא תרגלה אף אחת מהן.
היכן VPN אתר עדיין זוכה במקומו
מנהרה או שער צר היא התשובה הנכונה כאשר למשאב אין אימות משלו לכל בקשה: פורטי תחזוקה של מסדי נתונים, יעדי גיבוי, קונסולות היפרוויזור, ניהול מחוץ לפס. המאזינים האלה סומכים על הרשת, ולכן הרשת חייבת להיות זו שמאמתת את הקורא.
זו אינה התשובה היחידה. שער שמסיים הרשאה לכל משאב יכול להיות צר יותר ממנהרה על פני כל תת-הרשת, והוא משאיר עקבות ביקורת טובים יותר ממארח קפיצה משותף.
סדר העבודה: השלימו את המלאי, סגרו את החלופות, אמתו סירוב אחד לכל שורה, ורק אז פרשו את המנהרה. אם שורה אינה יכולה לייצר סירוב, החזיקו בנתיב הפרטי עד שהיא תוכל.