ניהול NAS דרך VPN: שמרו על השם, ותרו על הפורט הציבורי
הגיעו לדף הניהול דרך המנהרה, לא דרך פורט ציבורי חדש. פתרו את השם האמיתי, התאימו לו את התעודה, ואפשרו שירות אחד ממקור אחד.
דף הניהול של NAS עובד בבית ומפסיק לעבוד ברגע שהמנהל נוסע, אז מישהו פותח פורט והבעיה נעלמת יחד עם הפרטיות. יש צורה טובה יותר לזה. השאירו את הדף במקומו, תנו למנהרה לספק את הנגישות, והפכו את מה שאתם מתעדים לכתובת URL מלאה עם נתיב הרשאה בעל שם, ולא לכתובת התקן שמקרה עונה. כל החלטה בהמשך, מהשם דרך התעודה ועד הפורט היחיד המותר, נובעת מכך שכותבים את זה כך.
יחידת התכנון היא URL, לא כתובת
כתבו את הכניסה כ-URL מלא עם הפורט והסכמה שלו, ואז צרפו את התנאים: מי רשאי להשתמש בו, מאיזו רשת ובאיזה נתיב. דוגמה יכולה להיות https://nas.corp.example:8443 שמפורסם רק ללקוחות פרטיים מאושרים, כאשר השם והפורט מייצגים את מה שהתקן באמת מאזין לו.
המסגור הזה כופה את ההחלטות מוקדם. URL מרמז על שם, שם מרמז על תעודה, ותעודה מרמזת על הסדר אמון. כתובת אינה מרמזת על דבר מזה, וזו בדיוק הסיבה שהגרסה של כתובת בלבד שורדת עד לאזהרת הדפדפן הראשונה ואז הופכת להרגל של ללחוץ דרכה.
| Entry point | What it costs | When it fits |
|---|---|---|
| Private name over the tunnel | A private DNS zone and a certificate for that name | Administrators who already hold VPN access |
| Public reverse proxy | An exposed front end to patch and monitor | A documented, reviewed need for public reach |
| Vendor relay service | Trust in a third party path | A supported product design, not a workaround |
שמרו על השם שעבורו הונפקה התעודה
הלקוח זקוק לנתיב מותר לכתובת הפרטית של NAS, והסדר DNS פרטי יכול לפתור את שם המארח המיועד לכתובת הזו תוך שמירה על השם ששירות ה-HTTPS מצפה לו. שני החצאים חשובים: הנתיב מביא את החבילות לשם, והשם אומר ללקוח איזו זהות לאמת.
הקלדת הכתובת המספרית במקום משנה את דרישת הזהות. RFC 9525 מפריד בין השם שאליו הלקוח מתכוון לפנות לבין הזהות שהשירות מציג, ולכן תעודה שהונפקה עבור nas.corp.example יכולה להיכשל באופן לגיטימי כשהדפדפן הופנה אל 10.20.0.15. האזהרה נכונה, והתיקון הוא השם, לא חריגה.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleהריצו את שתיהן לפני שאתם מאשימים את המנהרה. הראשונה מראה אם השם הפרטי נפתר במקום שבו אתם חושבים, והשנייה מראה איזו תעודה ואילו שמות נושא חלופיים השירות מציג בפועל. CA פרטי יכול להיות בחירה מנוהלת היטב; מה שלא אמור להפוך לשגרה הוא ללמד אנשים להתעלם מאזהרות זהות.
תחמו את נתיב הניהול
אפשרו בדיוק את שירות הניהול מהמקור המיועד, גם בשער וגם ב-NAS. המשפט הזה מסתיר פרט שנושך: מאגר לקוחות מנותב ושער עם תרגום מקור מגיעים ל-NAS עם כתובות מקור שונות, ולכן כלל הרשאה שנכתב לאחד נכשל בשקט עבור השני.
NAS זקוק גם לנתיב חזרה, והדפדפן חייב להשתמש בפורט ובסכמה שהוגדרו ולא בברירת המחדל של היצרן מפוסט בפורום. להגיע להתקן אינו הרשאה להגיע לכל פורט בו. הפער בין התקן שעונה ל-ping לבין דף ניהול שנטען הוא הפער בין שני כללים נפרדים. כתבו אותם כשני כללים עם שני הערות, כדי שהאדם הבא יראה למה שניהם קיימים.
הפרידו בין קבלה ל-VPN לבין הרשאת NAS
לאפשר לך לעבור במנהרה אינו אותו דבר כמו להרשות לך לנהל את התקן. משתמש שזקוק באופן לגיטימי לאחסון קבצים לא אמור לרשת ניהול התקן רק מפני ששניהם חיים מאחורי שער אחד, ומודל החשבונות של NAS הוא המקום שבו יש לאכוף את ההפרדה הזו.
כתובת יציאה משותפת או מתורגמת גם היא אינה יכולה לזהות מנהל בודד. אם נתיב הביקורת צריך לנקוב בשם של אדם, הזהות חייבת לבוא מחשבון מאומת ולא מכתובת המקור של מנהרה שרבים משתמשים בה.
מה לא לפרסם בטעות
פרוקסי הפוך ציבורי וריליי של יצרן הם שניהם ארכיטקטורות אמיתיות, וכל אחד נושא את החלטות האמון והחשיפה שלו. אף אחד מהם אינו נעשה הכרחי מפני שמנהל נמצא מחוץ לבית, ואף אחד מהם לא אמור להופיע כתופעת לוואי של חשיפת שרת מדיה או שיתוף קבצים.
תעדו ארבעה דברים ועצרו: השם הפרטי, המאזין שאליו הוא ממופה, הקבוצה שמותר לה להשתמש בו, ונתיב השחזור אם המנהרה אינה זמינה. ארבעת אלה גם עונים על השאלות שבדיקת אירוע תשאל, וזה לא נכון לגבי צילום מסך של דף העברת פורטים. מה שמתקבל בסוף הוא נקודת כניסה ניהולית יציבה אחת ולא התקן שכל תכונה בו פונה לאינטרנט.