클라이언트리스였던 옛 포털에는 삭제 버튼, 즐겨찾기 별표, 이메일에 붙여 넣은 공유 경로가 있었습니다. 그중 통제는 하나뿐입니다. 포털을 교체한다는 것은 원격 사용자에게 아직 필요한 작업이 무엇이고 각 작업을 어디에서 강제할지 정하는 일이지, 우연히 작동했던 페이지의 레이아웃을 재현하는 일이 아닙니다. 두 가지 교체 형태가 대부분의 경우를 덮으며, 서로 다른 지점에서 실패합니다.

버튼은 권한이 아니다

작업 목록은 읽기, 업로드, 이름 바꾸기, 삭제입니다. 어떤 역할이 각각을 얻는지 정한 다음, 그 결정을 인터페이스가 아니라 파일 서비스에서 강제합니다. 새 포털에서 삭제 통제를 숨겨도 백엔드 권한은 그대로 남으므로, 네이티브 클라이언트와 같은 계정을 가진 사람은 여전히 파일을 지울 수 있습니다.

삭제는 사용자가 후회하는 작업이므로 별도의 결정이 필요합니다. 삭제한 항목을 실제로 어디에서 복구할 수 있는지 물어보고, 답이 노트북의 휴지통이나 포털 자체의 휴지통이라고 가정하지 마십시오. 네트워크 공유는 보통 삭제를 로컬 휴지통으로 라우팅하지 않습니다.

Windows 기반 공유에서 Volume Shadow Copy는 스냅샷 메커니즘과 백업 소프트웨어가 사용하는 조정을 제공하지만, 그 존재만으로 이 공유가 복원 가능한 버전을 보존하는지는 알 수 없습니다. 파일 서비스 소유자는 버전 정책을 확인하고 포털을 폐기하기 전에 복원을 시연해야 합니다.

옵션 A: 터널을 통한 네이티브 파일 클라이언트

매핑된 드라이브나 SMB 클라이언트는 사용자가 이미 아는 작업을 유지하며, 권한은 요청마다 파일 서버가 강제합니다. 중요한 신원은 파일 서비스의 신원이므로, 터널이 계속 트래픽을 나르고 계정이 남아 있는 한 VPN 제품이 바뀌어도 접근은 살아남습니다.

대가는 클라이언트가 서비스에 직접 도달해야 한다는 점입니다. 이름 확인, 포트 도달성, 인증 방식이 모두 원격 접근 설계의 일부가 되며, 예전에 연결을 프록시하던 포털은 그 요구 사항을 모두 숨겼습니다. 관리되지 않는 기기의 사용자는 파일 관리자에 마운트된 공유도 얻게 되는데, 이는 브라우저 탭보다 넓은 표면입니다. 이관 전에, 유예 기간이 아니라 첫날부터 발생하는 그 지원 부담을 예산에 넣으십시오.

이 형태의 가장 강력한 근거는 이전 버전과 복원 권한이 플랫폼에 네이티브이고 헬프 데스크가 현장에서 쓰는 것과 같은 절차를 쓸 수 있다는 점에서 오는 복구입니다.

옵션 B: 프록시 또는 애플리케이션 게이트웨이

파일을 가져와 브라우저로 스트리밍하는 포털은 파일 서비스를 사용자의 네트워크 경로 밖에 둡니다. 기기가 터널에 참여할 수 없거나 조직이 모든 요청을 한 병목 지점에서 기록하려 할 때 유용합니다. 절충은 프록시가 모든 작업의 참여자가 되며, 모든 일에 자체 서비스 계정을 쓰는 대신 사용자 신원을 파일 서비스까지 전달해야 한다는 것입니다.

삭제와 이름 바꾸기 동작은 상속이 아니라 구현해야 합니다. 프록시가 삭제 작업을 노출한다면 그 작업은 어떤 신원으로 백엔드를 호출하며, 감사 추적은 게이트웨이가 아니라 사용자를 지목해야 합니다. 프록시가 이름을 바꿀 수 없다면 사용자가 프로젝트 중간에 발견하기 전에 말하십시오.

링크 재작성은 이 형태가 조용히 의미를 바꾸는 지점입니다. 포털이 프록시하는 URL은 브라우저가 직접 여는 URL과 같은 객체가 아니며, 하나를 다른 것으로 바꾸면 작동하게 만들던 인증 맥락이 사라질 수 있습니다.

이름, 신원, 그리고 그 사이의 링크

도메인 탐색 목록이 아니라 승인된 서버와 공유 경로를 배포하십시오. 탐색은 터널을 건너지 못할 수 있는 검색 서비스에 의존하며, 사용자의 노트북이 도메인을 열거할 수 있어서 작동하는 경로는 다음 관리되지 않는 기기에서 깨지는 경로입니다.

싱글 사인온을 애플리케이션별로 검토하십시오. 포털용으로 발급된 토큰을 그것을 검증한 적 없는 파일 서비스로 재생해서는 안 되며, 식별자를 담은 쿼리 매개변수는 옛 책갈피에 있었기 때문만으로 공개 링크에 복사해서는 안 됩니다. 승인된 각 애플리케이션을 자체 신뢰 경계로 다루십시오.

RequirementNative clientProxy portal
Permission enforcementFile service, per requestProxy identity, then file service
Restore pathPlatform versions and backupsProxy trash plus backend restore
Device requirementsTunnel and clientBrowser only
Audit identityFile server logsProxy logs, if it forwards the user

요구 사항 목록에 비추어 선택하라

어느 형태도 완전히 이기지 않습니다. 작동하는 터널과 관리되는 노트북을 가진 인력은 복구와 권한이 재구현이 아니라 플랫폼에서 오기 때문에 네이티브 클라이언트에서 더 많은 것을 얻습니다. 계약자와 개인 기기가 섞인 집단은 신원 배관이 실제이고 공유 서비스 계정이 아니라면 프록시를 정당화할 수 있습니다.

네 가지 작업과 복구 답변에 대한 비교를 적고, 새 경로로 복원을 한 번 수행한 뒤에만 옛 포털을 폐기하십시오. 그 테스트는 성공한 로그인이 결코 건드리지 않는 설계 부분을 운동시킵니다.

관련 글