הורדת קובץ אחד אינה מצריכה VPN רשת מלא

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

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

התחילו מהעריכה, לא מהתיקייה

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

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

SFTP הוא פרוטוקול העברה, לא שיתוף

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

sftp [email protected]
put report.pdf /upload/report.pdf
get /shared/template.docx

זהו כל זרימת העבודה לקובץ גמור: התחבר, שים, קח. חשבון העברה בלבד צריך גם שירות SSH מוגבל, לא רק את מערכת הקבצים. chroot או ForceCommand internal-sftp מגבילים מה שההפעלה יכולה להריץ, ונטרול העברת TCP ומנהרות סוגר את הנתיבים שאחרת היו הופכים חשבון קבצים לנקודת כניסה לרשת. הגבלת התיקייה הנראית בלבד אינה מוכיחה דבר על מה שהחשבון יכול להגיע אליו.

אם אתם צריכים את השיתוף, אל תפרסמו אותו

לפעמים השיתוף המקורי הוא באמת הדרישה, והתשובה אינה לחשוף את SMB ללקוחות אינטרנט שרירותיים. ההנחיה של Microsoft היא לחסום תעבורת SMB ישירה בגבול, ומסיבה טובה: הפרוטוקול לא נבנה להתמודד עם רשתות לא מהימנות. קיימים SMB over QUIC ועיצובים דומים, עם דרישות פלטפורמה ספציפיות בשני הקצוות, והם אינם מתג אוניברסלי לשרת Samba שרירותי. אם אף אחד מהם לא חל, העבודה היא לספק נתיב גישה נתמך במקום פורט מועבר.

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

מה לבדוק לפני מסירת הגישה

sftp [email protected] <<< "get /shared/template.docx /tmp/probe.docx"
ssh [email protected] "cat /etc/passwd"

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

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