האם אתם עדיין צריכים VPN אם אתם משתמשים ב-Identity-Aware Proxy?

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

שני השערים מאשרים דברים שונים

שער יישום מחליט אם הבקשה הזו, מהזהות הזו, רשאית להגיע למשאב המוגן הזה. סקירת Identity-Aware Proxy של Google מתארת בדיוק את הצורה הזו: שכבת הרשאה מרכזית לפני יישומי HTTPS, המונחת על ידי תפקיד IAM. הגבול הוא המשאב, ויחידת הגישה היא הבקשה. VPN מנותב עושה משהו גס ורחב יותר: הוא מכניס לקוח לתחום רשת מוגדר, ולאחר מכן היישום עדיין מחליט מה הלקוח הזה רשאי לעשות.

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

מה שהפרוקסי לא מכסה, וה-VPN כן

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

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

זרימת העבודה של הלקוח קובעת יותר מתרשים הארכיטקטורה

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

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

מצב ההתקן אינו תכונה של אף אחד מהשערים

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

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

מצאו את המסלולים החלופיים לפני שאתם מוציאים משהו מכלל שימוש

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

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

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