Мне постоянно задают этот вопрос люди, которые используют веб-серверы на базе Windows. FTP, хотя и широко распространен, имеет множество недостатков, не все из которых могут быть решены простым установлением SSL / TLS поверх существующего протокола FTP.
Итак, существует ли протокол, конфигурация или другое решение, которое пользователь Windows может использовать для общедоступной передачи файлов вместо FTP? Типичные требования просты и интуитивно понятны:
Вот некоторые нет решения, которые не удовлетворяют требованиям вопроса, но все равно обычно предлагаются. Они включены здесь, чтобы убедить вас не предлагать их в качестве ответов.
Обратите внимание, что это очень явно и намеренно не а вопрос о покупках. Мы не спрашиваем, какой популярный продукт лучше всего соответствует обширному списку функций. Вместо этого мы ищем возможные решения общей проблемы.
Я думаю, что ключевая проблема, обозначенная в вашем списке запретов, заключается не в передаче файлов, а в качестве обучения, которое проводят соответствующие администраторы (или с которого, как ожидается, придется начать). Если организация не может настроить что-то подобное ни внутри компании, ни через аутсорсинговую ИТ-инфраструктуру, тогда я буду обеспокоен как заказчик, так и инвестор. (это оказывается более агрессивным / высокомерным, чем я предполагал, но я не могу придумать лучшего способа выразить это ...).
Чтобы ответить на ваши вопросы более прямо:
Cygwin + SSH
Это определенно может быть удобно для установки с помощью Cygwin, но есть коммерческие варианты, которыми может быть намного проще управлять. SCP / SFTP (через SSH) делает не обязательно подразумевает доступ к оболочке - во всех реализациях, которые я знаю, это может быть удалено от пользователей или невозможно вообще. В Linux ограниченные оболочки, такие как rssh обычно доступны, просто настройте всех пользователей, чтобы один из них был их оболочкой, так что вполне вероятно, что они также существуют в коллекции портов Cygwin (или могут быть скомпилированы локально, если нет). Другой вариант, если вы не уверены, что ограниченной оболочки будет достаточно, - чтобы все входы SSH проходили через шлюз, который не содержит абсолютно ничего полезного, которое могли бы запустить пользователи, и установить другие области хранения по локальной сети под пользователями. 'домов (хотя это было бы еще сложнее настроить).
RDP, который, хотя и имеет возможность обмена файлами, также предоставляет посетителю доступ к рабочему столу, позволяя ему делать больше, чем просто загружать и скачивать файлы.
Я согласен с тем, что RDP / RDS - неправильное решение только для обмена файлами, хотя вы можете надежно заблокировать своих пользователей RDP с очень ограниченными привилегиями.
FTPS, FTPES и другие решения на основе FTP. Шифрование - не единственная проблема FTP.
Согласовано.
Совместное использование файлов Windows, которое небезопасно для использования через Интернет и обычно блокируется интернет-провайдерами по этой причине.
Если вы контролируете клиентские ОС, которые подключаются, и они всегда подключаются по ссылкам приличного качества, тогда можно рассмотреть возможность совместного использования файлов Windows, если доступ к ним осуществляется только через какую-либо форму решения VPN. Хотя, если вы считаете, что управление SSH является серьезной проблемой управления инфраструктурой, мысль о VPN также может быть пугающей.
DAV, если его не ОЧЕНЬ легко настроить и защитить (что обычно не так)
Я сам не работал с DAV, поэтому не могу здесь давать какие-либо комментарии.