파일 하나를 가져오는 데 전체 네트워크 VPN은 필요하지 않다
폴더 하나와 파일 하나 때문에 사무실 LAN 전체로 가는 경로를 정당화하기는 어렵습니다. 사용자가 해야 할 작업을 기준으로 전송, 공유, 브라우저 옵션을 비교하십시오.
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 트래픽을 차단하는 것이며, 그럴 만한 이유가 있습니다. 이 프로토콜은 신뢰할 수 없는 네트워크를 상대하도록 만들어지지 않았습니다. QUIC을 통한 SMB와 유사한 설계가 있으며 양쪽 끝에 특정 플랫폼 요구 사항이 있지만, 임의의 Samba 서버를 위한 만능 스위치는 아닙니다. 둘 다 해당하지 않는다면 작업은 전달된 포트가 아니라 지원되는 액세스 경로를 제공하는 것입니다.
브라우저 기반 옵션은 작업에 맞을 때 정당한 세 번째 답입니다. 계정, 공유 링크, 만료, 보존된 버전, 어떤 사본이 권위 있는지와 같은 자체 결정을 가져옵니다. 누구나 열 수 있는 링크와 로그인이 필요한 작업 공간은 서로 다른 액세스 정책을 나타내며, 어느 것도 우연히 선택해서는 안 됩니다.
액세스를 넘기기 전에 무엇을 확인할지
sftp [email protected] <<< "get /shared/template.docx /tmp/probe.docx" ssh [email protected] "cat /etc/passwd"
어떤 설계를 선택하든 의도한 데이터와 의도한 작업으로 범위를 제한하십시오. 첫 번째 명령은 성공해야 하고 두 번째는 거부되어야 합니다. 둘 다 성공하면 계정이 작업보다 넓습니다. 그런 다음 계정을 제거하고 첫 번째를 반복하면 이제 실패해야 합니다. 소스 파일의 소유자를 식별 가능하게 유지하여 권위 있는 사본에 대한 나중 질문에 답이 있게 하십시오. 기록할 가치가 있는 결과는 사용 가능하고 취소 가능한 파일 워크플로이며, 사라진 연결 아이콘이 아닙니다.
사용자의 애플리케이션에 실제로 어떤 프로토콜이 필요한지, 어떤 세 가지 테스트를 실행했는지 적으십시오. 그 두 줄이 대부분의 재작업을 막습니다.