העברת אפליקציית ווב ארגונית אל מאחורי ה-VPN: מדריך למעבר

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

שלב 1: רשמו מה המשתמשים עושים היום

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

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

שלב 2: הפרידו בין המנהרה להתחברות

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

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

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

שלב 3: מצאו את הקוראים שאינם עובדים

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

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

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

שלב 4: הוציאו את הנתיב הציבורי, לא רק את רשומת ה-DNS

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

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

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

שלב 5: עברו על הקבלה בעצמכם

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

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

שלב 6: תרגלו את היום הרע

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

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

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