การดึงไฟล์เดียวไม่ต้องใช้ 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 และ tunneling ปิดเส้นทางที่จะเปลี่ยนบัญชีไฟล์เป็นจุดเข้าสู่เครือข่าย การจำกัดเพียงไดเรกทอรีที่มองเห็นไม่ได้พิสูจน์อะไรเกี่ยวกับสิ่งที่บัญชีเข้าถึงได้

หากคุณต้องการการแชร์ อย่าเผยแพร่มัน

บางครั้งการแชร์ต้นฉบับเป็นข้อกำหนดจริงๆ และคำตอบไม่ใช่การเปิด SMB ให้ไคลเอนต์อินเทอร์เน็ตตามอำเภอใจ คำแนะนำของ Microsoft คือบล็อกทราฟฟิก SMB โดยตรงที่ขอบเขต และด้วยเหตุผลที่ดี โปรโตคอลนี้ไม่ได้สร้างขึ้นเพื่อเผชิญกับเครือข่ายที่ไม่น่าเชื่อถือ มี SMB over QUIC และการออกแบบที่คล้ายกัน โดยมีข้อกำหนดแพลตฟอร์มเฉพาะที่ปลายทั้งสอง และไม่ใช่สวิตช์สากลสำหรับเซิร์ฟเวอร์ Samba ใดๆ หากใช้ไม่ได้ทั้งคู่ งานคือการจัดหาเส้นทางเข้าถึงที่รองรับแทนพอร์ตที่ส่งต่อ

ตัวเลือกบนเบราว์เซอร์เป็นคำตอบที่สามที่ชอบด้วยกฎหมายเมื่องานเข้ากัน มันนำการตัดสินใจของตัวเองมา บัญชี ลิงก์แชร์ การหมดอายุ เวอร์ชันที่เก็บไว้ และสำเนาใดเป็นผู้มีอำนาจ ลิงก์ที่ใครก็เปิดได้และพื้นที่ทำงานที่ต้องลงชื่อเข้าใช้เป็นตัวแทนนโยบายการเข้าถึงที่ต่างกัน และไม่ควรเลือกทั้งสองโดยบังเอิญ

สิ่งที่ต้องตรวจสอบก่อนส่งมอบการเข้าถึง

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

ไม่ว่าคุณจะเลือกการออกแบบใด ให้จำกัดขอบเขตไว้ที่ข้อมูลที่ตั้งใจและการดำเนินการที่ตั้งใจ คำสั่งแรกควรสำเร็จและคำสั่งที่สองควรถูกปฏิเสธ หากทั้งสองสำเร็จ บัญชีก็กว้างกว่าการงาน จากนั้นลบบัญชีและทำคำสั่งแรกซ้ำ ซึ่งตอนนี้ควรล้มเหลว รักษาเจ้าของไฟล์ต้นทางให้ระบุได้ เพื่อให้คำถามภายหลังเกี่ยวกับสำเนาที่มีอำนาจมีคำตอบ ผลลัพธ์ที่ควรบันทึกคือเวิร์กโฟลว์ไฟล์ที่ใช้ได้และเพิกถอนได้ ไม่ใช่ไอคอนการเชื่อมต่อที่หายไป

จดบันทึกว่าแอปพลิเคชันของผู้ใช้ต้องการโปรโตคอลใดจริงๆ และคุณรันการทดสอบสามอย่างใด เขียนสองบรรทัดนั้นป้องกันการทำงานซ้ำส่วนใหญ่