SFTP, или SSH File Transfer Protocol, — сетевой протокол защищенной передачи и управления файлами через SSH. Он позволяет подключаться к удаленному серверу, просматривать каталоги, загружать и скачивать файлы, переименовывать их, изменять права и выполнять другие файловые операции.
SFTP широко используется для обмена документами между компаниями, автоматической передачи отчетов, интеграции информационных систем, резервного копирования и администрирования серверов.
Главное преимущество SFTP — передача данных внутри защищенного SSH-соединения. Логины, файлы и команды управления не передаются по сети открытым текстом.
SFTP объединяет защищенный транспорт SSH и полноценный набор операций для удаленной работы с файлами.
Что такое SFTP простыми словами
SFTP можно представить как защищенный файловый менеджер для удаленного сервера.
Пользователь подключается к Server через SSH Authentication и после этого видит доступные каталоги:
Client ↓ SFTP over SSH Server ↓ /files /reports /uploads
Он может скачать файл report.xlsx, загрузить новый документ или переместить его в другой каталог.
Расшифровка SFTP
SFTP расшифровывается как SSH File Transfer Protocol.
Иногда его ошибочно называют Secure FTP. Такое объяснение помогает понять назначение, но технически SFTP является отдельным протоколом, работающим поверх SSH, а не защищенной версией классического FTP.
Для чего нужен SFTP
Основные сценарии:
- передача файлов между компаниями;
- обмен бухгалтерскими отчетами;
- автоматическая выгрузка документов;
- загрузка файлов на сервер;
- Backup и архивирование;
- обмен данными между ERP и внешними системами;
- интеграция банковских и финансовых систем;
- работа разработчиков и администраторов;
- передача файлов между дата-центрами.
Как работает SFTP
Client устанавливает SSH Connection с Server.
После успешной Authentication внутри этого защищенного канала запускается SFTP Subsystem.
SFTP ↓ SSH ↓ TCP ↓ IP
Таким образом, SFTP использует механизмы Encryption, Integrity и Authentication, предоставляемые SSH.
SFTP и SSH
SSH — более широкий протокол удаленного доступа.
Через SSH можно открыть Shell, выполнить команду или создать Tunnel. SFTP использует SSH как защищенный транспорт, но предоставляет специализированный интерфейс для работы с файлами.
| SSH | SFTP |
|---|---|
| Удаленная Shell и команды | Управление файлами |
| Поддерживает туннелирование | Загрузка и скачивание файлов |
| Базовый защищенный протокол | Работает через SSH |
Порт SFTP
Поскольку SFTP работает через SSH, стандартно используется TCP Port 22.
sftp.example.com:22
Server может слушать и другой Port, если это предусмотрено конфигурацией.
Нужны ли дополнительные порты
Обычно SFTP использует одно SSH Connection.
Это важное отличие от классического FTP, который может создавать дополнительные соединения для передачи данных.
Благодаря этому SFTP проще пропускать через Firewall и NAT.
SFTP Client
SFTP Client — программа, с помощью которой пользователь или приложение подключается к Server.
Это может быть:
- консольная утилита;
- графический файловый менеджер;
- библиотека внутри приложения;
- интеграционный сервис;
- скрипт автоматизации.
SFTP Server
SFTP Server принимает SSH Connections и предоставляет пользователю доступ к определенной файловой системе.
На Linux SFTP часто является частью SSH Server и не требует отдельного FTP Server.
Подключение к SFTP
Типичный консольный вариант:
sftp user@sftp.example.com
После Authentication пользователь получает SFTP Prompt и может выполнять файловые команды.
Основные операции SFTP
| Операция | Назначение |
|---|---|
| ls | Просмотр файлов |
| cd | Переход в каталог |
| get | Скачать файл |
| put | Загрузить файл |
| mkdir | Создать каталог |
| rename | Переименовать файл |
| rm | Удалить файл |
Скачивание файла
После подключения файл можно получить командой:
get report.csv
Он скачивается с удаленного Server на Client.
Загрузка файла
Для отправки файла на Server используется:
put report.csv
Передача происходит внутри защищенного SSH Channel.
SFTP и FTP
SFTP и FTP — разные протоколы.
| SFTP | FTP |
|---|---|
| Работает через SSH | Использует собственный протокол |
| Шифрует соединение | Классический FTP передает данные без обязательного шифрования |
| Обычно один TCP Port | Использует отдельные управляющие и Data Connections |
| Удобнее для Firewall и NAT | Может требовать дополнительных сетевых правил |
SFTP и FTPS
FTPS — это FTP с TLS-защитой.
SFTP — совершенно другой протокол поверх SSH.
Несмотря на схожую задачу безопасной передачи файлов, они используют разные Servers, Ports и механизмы Authentication.
SFTP или FTPS
Выбор часто зависит от существующей инфраструктуры и требований партнера.
Если организация уже использует SSH, SFTP обычно проще интегрировать.
Если внешняя система требует именно FTPS, заменить его SFTP без изменения интеграции нельзя.
SFTP и SCP
SCP также используется для передачи файлов через SSH, но имеет более простой сценарий работы.
SFTP предоставляет полноценный файловый протокол: просмотр каталогов, переименование, удаление и управление удаленной файловой структурой.
SFTP и HTTPS
HTTPS API тоже может использоваться для загрузки файлов.
Если бизнес-интеграция требует современный API с Metadata, Authentication Tokens и бизнес-операциями, HTTPS часто удобнее.
SFTP полезен, когда процесс построен именно вокруг обмена файлами.
SFTP и WebDAV
WebDAV расширяет HTTP возможностями работы с файлами и каталогами.
SFTP использует SSH и чаще применяется для серверной автоматизации и B2B File Exchange.
Authentication в SFTP
Поскольку SFTP использует SSH, доступны соответствующие способы Authentication.
Наиболее распространены:
- Username и Password;
- SSH Public Key;
- SSH Certificate;
- дополнительная MFA в некоторых архитектурах.
Password Authentication
Пользователь вводит пароль, который передается внутри уже установленного защищенного SSH Channel.
При этом для автоматизированных интеграций постоянные Passwords часто менее удобны и сложнее безопасно хранить.
Public Key Authentication
Для автоматического обмена файлами часто используется SSH Key Pair.
Public Key размещается на SFTP Server, а Private Key хранится у клиента.
Server проверяет владение Private Key и разрешает соединение.
Почему ключи удобны для интеграций
Сервис может подключаться без ручного ввода Password.
При этом отдельному партнеру или системе можно выдать собственный Public Key и затем независимо отозвать его.
Private Key
Private Key является Secret.
Его нельзя публиковать в Source Code, Git Repository или отправлять вместе с файлами интеграции.
Для серверной автоматизации ключ следует хранить в Secret Manager или другом защищенном хранилище.
Passphrase
Private Key можно защитить Passphrase.
Для автоматизированных систем это создает дополнительную задачу безопасного предоставления Passphrase процессу, поэтому архитектуру Credentials нужно продумать заранее.
Host Key Verification
Client должен проверять Host Key SFTP Server.
Это помогает убедиться, что соединение установлено именно с ожидаемым Server, а не с подмененным узлом.
Почему нельзя отключать Host Key Verification
В автоматизации иногда возникает желание отключить проверку, чтобы Script не останавливался при первом подключении.
Это ухудшает защиту от Man-in-the-Middle.
Правильнее заранее получить Fingerprint Server через доверенный канал и сохранить его в Client Configuration.
SFTP и шифрование
Файлы передаются внутри SSH Encryption.
Это защищает содержимое от обычного перехвата на сетевом пути.
Также SSH обеспечивает контроль Integrity, помогая обнаруживать изменение Traffic при передаче.
Шифрование при передаче и хранении
SFTP защищает Data in Transit.
После сохранения файла на Disk его защита зависит уже от Storage, File Permissions и Encryption at Rest.
Поэтому SFTP не заменяет шифрование диска или самого документа.
SFTP и Firewall
Для стандартной конфигурации Firewall обычно должен разрешать TCP 22 между конкретным Client и SFTP Server.
Лучше использовать точное правило:
Partner IP → SFTP Server:22 ALLOW Internet → SFTP Server:22 DENY
если партнер имеет стабильный Source Address.
Почему не стоит открывать SFTP всему интернету
SFTP Server с публичным Port 22 становится целью автоматического сканирования и Brute Force.
Если доступ нужен только нескольким компаниям, его полезно ограничить Firewall, VPN или Allowlist.
SFTP через VPN
Для внутренних корпоративных интеграций SFTP можно сделать доступным только через Site-to-Site VPN.
Company A ↓ VPN Company B Network ↓ SFTP Server
Тогда SFTP Endpoint вообще не публикуется в интернет.
SFTP и NAT
Поскольку SFTP обычно использует одно TCP Connection, он относительно просто работает через NAT.
Client инициирует соединение к Public Address Server, а NAT Gateway поддерживает соответствующее Mapping.
SFTP и Proxy
В некоторых сетях SSH/SFTP Client может подключаться через промежуточный Proxy или Bastion.
Это полезно, если прямой доступ к SFTP Server из пользовательской сети запрещен.
SFTP и Bastion Host
Внутренний SFTP Server можно не публиковать напрямую.
Client ↓ SSH Bastion ↓ SFTP Server
Для автоматических B2B-интеграций чаще стремятся иметь отдельный контролируемый SFTP Endpoint, чтобы не смешивать административный Bastion и файловый сервис.
Права доступа SFTP
Каждому пользователю следует предоставлять только необходимые каталоги и операции.
Например, партнеру может быть разрешено загружать файлы в /incoming, но запрещено просматривать каталоги других организаций.
Принцип Least Privilege
SFTP Account не должен получать полноценный Shell Access, если пользователю требуется только обмен файлами.
Чем меньше доступных функций, тем меньше последствия компрометации Credentials.
SFTP-only пользователь
SSH Server можно настроить так, чтобы конкретный Account использовал только SFTP Subsystem.
Попытка открыть обычную SSH Shell при этом будет запрещена.
Это распространенный подход для партнерских интеграций.
Chroot
Chroot-подобная изоляция ограничивает пользователя определенной частью File System.
Например:
/sftp/customer-a/
Пользователь видит этот каталог как свою файловую область и не может перемещаться по системным каталогам Server.
Отдельный каталог для каждого партнера
При работе с несколькими организациями удобно создавать:
/partners/company-a/incoming /partners/company-a/outgoing /partners/company-b/incoming /partners/company-b/outgoing
Permissions должны исключать доступ одной компании к файлам другой.
Incoming и Outgoing
Каталог Incoming используется для файлов, которые партнер отправляет компании.
Outgoing — для файлов, которые компания подготовила партнеру.
Такое разделение упрощает автоматическую обработку.
SFTP в B2B-интеграциях
SFTP остается распространенным способом обмена файлами между организациями.
Например, одна система ежедневно формирует CSV с операциями и загружает его партнеру.
На другой стороне Integration Service забирает файл и импортирует данные.
SFTP и бухгалтерские системы
Через SFTP можно обмениваться:
- реестрами платежей;
- CSV-выгрузками;
- XML-документами;
- отчетами;
- архивами;
- данными для интеграции с ERP.
Точная структура файлов определяется договоренностью между системами.
SFTP и 1С
1С или промежуточный интеграционный сервис может автоматически выгружать файл и передавать его партнеру по SFTP.
Например, ночью формируется CSV с заказами:
1С ↓ CSV Integration Service ↓ SFTP Partner
На обратном пути можно получать подтверждения или обновленные справочники.
Почему SFTP удобен для legacy-интеграций
Не каждой старой системе легко предоставить современный REST API.
Создать файл по расписанию и положить его на SFTP Server зачастую значительно проще.
Поэтому File-based Integration остается востребованной.
Недостатки файловой интеграции
По сравнению с API SFTP обычно сложнее использовать для real-time взаимодействия.
Необходимо отдельно решать:
- имена файлов;
- расписание;
- повторную обработку;
- дубликаты;
- контроль целостности;
- архивирование;
- обработку ошибок.
Имена файлов
Для автоматизации полезно иметь предсказуемую схему:
orders_2026-08-17_001.csv
Имя может включать дату, тип документа и уникальный идентификатор.
Это упрощает Audit и предотвращает случайную перезапись.
Атомарная загрузка
Если система начинает читать файл, пока партнер еще продолжает его загружать, можно получить неполные данные.
Распространенный подход — сначала загрузить файл под временным именем, а после завершения выполнить Rename.
orders.csv.tmp ↓ upload complete orders.csv
Потребитель обрабатывает только файлы без временного расширения.
Почему Rename полезен
Переименование внутри одной файловой системы часто выполняется значительно быстрее полной передачи.
Так можно использовать имя файла как сигнал о завершении Upload.
Контроль целостности
SSH защищает Traffic от незаметного изменения при передаче, но бизнес-процессу иногда требуется отдельная проверка файла.
Например, вместе с архивом передается Checksum.
Получатель вычисляет Hash и сравнивает его с ожидаемым.
Checksum
Checksum помогает обнаружить повреждение или ошибочную замену файла.
Она особенно полезна для больших архивов и процессов, где файл перемещается через несколько систем.
Цифровая подпись файла
Если нужно подтвердить не только целостность канала, но и происхождение конкретного документа независимо от SFTP Session, файл можно дополнительно подписывать цифровой подписью.
SFTP и File Signature решают разные задачи.
Шифрование самого файла
Чувствительный файл можно зашифровать до Upload.
Тогда даже администратор SFTP Storage без ключа расшифрования не сможет прочитать содержимое.
Это может быть полезно при повышенных требованиях к защите данных.
SFTP и персональные данные
Если через SFTP передаются персональные или коммерчески чувствительные данные, необходимо контролировать не только канал передачи, но и Storage, Accounts, Logs, Retention и Backup.
Зашифрованный транспорт не делает весь бизнес-процесс автоматически безопасным.
Retention
Файлы не должны храниться на Exchange Server бесконечно без необходимости.
Например, успешно обработанные документы через определенный период перемещаются в Archive или удаляются согласно политике хранения.
Архивирование файлов
После обработки файл можно переместить:
/incoming/order.csv ↓ /archive/2026/08/order.csv
Это предотвращает повторную обработку и сохраняет Audit Trail.
Удаление файлов
Автоматическое удаление нужно проектировать осторожно.
Если файл удален до подтверждения успешного импорта, восстановить процесс будет сложнее.
Обычно сначала фиксируют успешную обработку, затем выполняют Archive или Cleanup.
Идемпотентность обработки
Один и тот же SFTP File может случайно быть загружен несколько раз.
Получатель должен уметь распознавать уже обработанные документы по File ID, Hash или бизнес-идентификатору.
Иначе могут появиться дубли заказов или операций.
SFTP и Retry
При Network Error Upload можно повторить.
Но Script должен понимать, существует ли на Server частично загруженный файл и можно ли безопасно продолжить операцию.
Resume
Некоторые SFTP Clients поддерживают продолжение прерванной передачи.
Это полезно для больших файлов через нестабильные каналы.
Поддержка и точное поведение зависят от Client и Server.
SFTP и большие файлы
Протокол подходит для передачи крупных файлов, но производительность зависит от Network Bandwidth, Latency, CPU для Encryption и Disk Speed.
Передавать очень большой файл через медленный международный канал может быть долго независимо от используемого протокола.
Compression
SSH может поддерживать Compression, но ее польза зависит от типа данных.
CSV и текст могут хорошо сжиматься, а ZIP, JPEG и другие уже сжатые форматы почти не выигрывают.
SFTP и Bandwidth
Если ночью одновременно запускаются десятки выгрузок, они могут занять значительную часть интернет-канала.
Для крупных интеграций полезно контролировать расписание и Bandwidth Limits.
Параллельная передача
Несколько файлов можно передавать параллельно через несколько Connections.
Это может повысить Throughput, но одновременно увеличивает нагрузку на SFTP Server и Network.
SFTP Server как точка отказа
Если десятки интеграций зависят от одного SFTP Endpoint, его недоступность останавливает весь File Exchange.
Для критичного бизнеса нужны Backup, Monitoring и план восстановления.
High Availability SFTP
Отказоустойчивость SFTP сложнее обычного запуска двух SSH Servers, потому что обе стороны должны видеть единое актуальное File Storage.
Для HA может использоваться Shared Storage, Replication или Managed File Transfer Platform.
SFTP и Managed File Transfer
MFT, или Managed File Transfer, — более широкая корпоративная платформа управления файловым обменом.
Она может использовать SFTP как один из Protocols и дополнительно предоставлять:
- Workflow;
- Audit;
- централизованное управление пользователями;
- Encryption;
- уведомления;
- Retry;
- расписания;
- High Availability.
Когда SFTP достаточно
Обычный SFTP Server подходит, если интеграций немного, процессы просты, а Workflow легко контролируется Scripts.
При сотнях партнеров и сложных регламентированных обменах MFT может быть удобнее.
SFTP в Docker
SFTP Server можно запускать в Container, но необходимо правильно организовать Persistent Storage, SSH Host Keys, Secrets и User Permissions.
Пересоздание Container не должно случайно менять Host Identity при каждом Deployment.
SFTP и Kubernetes
Размещение Stateful SFTP Service в Kubernetes требует учета Persistent Volumes, Stable Endpoint и Credentials.
Для простого B2B Exchange иногда удобнее использовать отдельный VM или Managed Service, чем усложнять Stateful Architecture кластера.
SFTP в облаке
В Cloud SFTP может работать на VM или как Managed File Transfer Service.
Managed вариант снимает часть задач по обновлению OS, High Availability и Storage, но Security Policy и User Access все равно остаются ответственностью владельца данных.
Object Storage или SFTP
Для современных внутренних приложений Object Storage часто удобнее SFTP.
Приложение использует API, временные ссылки, Events и IAM Policies.
Но внешний партнер может поддерживать только SFTP, поэтому оба подхода часто сосуществуют.
SFTP и Backup
SFTP можно использовать как транспорт для Backup Files, но сам SFTP Server не является Backup-системой.
Необходимо отдельно контролировать Retention, Versioning, Recovery и защиту от удаления.
Почему Exchange Folder не является Backup
Если исходный и переданный файл удалены или повреждены, наличие SFTP Folder не гарантирует восстановление.
Backup должен иметь отдельные копии и политику хранения.
Логи SFTP
Server должен фиксировать ключевые события:
| Событие | Зачем нужно |
|---|---|
| Login | Контроль доступа |
| Failed Login | Обнаружение атак и ошибок |
| Upload | Audit передачи |
| Download | Контроль получения файлов |
| Delete | Расследование потери данных |
| Rename | Контроль Workflow |
SFTP и SIEM
Authentication и File Transfer Events можно отправлять в SIEM.
Например, Alert создается, если Partner Account внезапно скачивает тысячи файлов, хотя обычно получает один отчет в день.
Мониторинг SFTP
Полезно отслеживать:
- доступность TCP Port;
- успешность Authentication;
- свободное место на Disk;
- очередь необработанных файлов;
- Failed Uploads;
- возраст последнего файла;
- скорость передачи.
Почему недостаточно проверять только Port 22
SSH Service может отвечать, но Disk заполнен или пользователь потерял права на каталог.
Поэтому Application Monitoring должен выполнять тестовую файловую операцию или контролировать реальные бизнес-файлы.
Disk Full
Если Storage заполнен, Client может успешно подключиться, но Upload завершится ошибкой.
Для SFTP Server необходимо заранее настраивать Alerts на свободное пространство.
Permission Denied
Пользователь может пройти Authentication, но не иметь права записать файл в конкретный каталог.
Нужно проверить File Ownership, Permissions и ограничения SFTP Account.
Connection Refused
Обычно означает, что на указанном IP и Port нет принимающего Service или соединение активно отклоняется.
Следует проверить SSH Server и Port.
Connection Timeout
Timeout чаще указывает на Firewall, Routing, неправильный IP или недоступность сети.
Это отличается от ошибки Authentication, которая происходит уже после установки Connection.
Host Key Changed
Если Fingerprint сервера неожиданно изменился, автоматическая интеграция может остановиться.
Не следует просто отключать проверку. Нужно выяснить, был ли Server действительно переустановлен или заменен.
Типичные ошибки SFTP
- Использовать общий Account для всех партнеров.
- Открыть SSH Port всему интернету без необходимости.
- Хранить Private Key в Source Code.
- Отключить Host Key Verification.
- Дать SFTP-пользователю обычную Shell.
- Не разделять каталоги партнеров.
- Обрабатывать частично загруженные файлы.
- Не учитывать дубликаты.
- Не архивировать обработанные документы.
- Не мониторить Disk Space.
Общий Account для партнеров
Если пять компаний используют один Login, невозможно нормально определить, кто загрузил конкретный файл.
При компрометации Credentials придется менять доступ сразу всем.
Лучше создавать отдельный Account или Key для каждой интеграции.
Как безопасно настроить SFTP
Шаг 1. Создать отдельную учетную запись
Не используйте административный Account для обмена файлами.
Шаг 2. Ограничить Shell
Если нужна только передача файлов, разрешите только SFTP.
Шаг 3. Изолировать каталог
Пользователь должен видеть только свою файловую область.
Шаг 4. Использовать SSH Keys
Для автоматизированных интеграций выдавайте отдельный Key каждой системе.
Шаг 5. Проверять Host Key
Сохраните доверенный Fingerprint Server.
Шаг 6. Ограничить Firewall
При возможности разрешите доступ только известным Networks или VPN.
Шаг 7. Настроить Logging
Фиксируйте Authentication и файловые операции.
Шаг 8. Добавить Monitoring
Контролируйте свободное место, Failed Transfers и поступление ожидаемых файлов.
Практический пример
Компания ежедневно обменивается платежными реестрами с внешним партнером.
На отдельном SFTP Server создается Account partner-bank без доступа к обычной SSH Shell.
Для него выделены каталоги:
/incoming /outgoing /archive
Партнер передает Public Key, а Private Key хранит у себя. Firewall разрешает SFTP Connection только с известной партнерской сети.
При Upload файл сначала получает имя payments.csv.tmp. После полной передачи выполняется Rename в payments.csv.
Integration Service обнаруживает новый готовый файл, проверяет его Hash и импортирует данные в учетную систему.
После успешной обработки файл перемещается в Archive. Его уникальный идентификатор записывается в Database, чтобы повторная загрузка не создала дубликаты операций.
Все Login и File Operations отправляются в централизованный Log. Monitoring проверяет, что ожидаемый дневной файл поступил вовремя и на Disk остается достаточно свободного места.
Таким образом, SFTP обеспечивает защищенный транспорт, а надежность бизнес-процесса дополняется Audit, Idempotency, Archive и Monitoring.
SFTP для бизнеса
SFTP особенно удобен для B2B-интеграций, где обмен строится вокруг файлов, а не real-time API.
Он понятен большому количеству корпоративных и legacy-систем, работает через один защищенный SSH Endpoint и хорошо автоматизируется.
Для бизнеса важно понимать, что надежная SFTP-интеграция — это не только защищенный Upload. Необходимо управлять Accounts, Keys, File Naming, архивированием, дубликатами, Monitoring и сроками хранения.
Преимущества SFTP
- шифрование трафика;
- SSH Key Authentication;
- обычно один сетевой Port;
- удобство автоматизации;
- полноценные операции с файлами;
- широкая поддержка корпоративными системами;
- простая интеграция через Scripts.
Недостатки SFTP
- файловая модель хуже подходит для real-time интеграций;
- необходимо отдельно обрабатывать дубликаты;
- нужно контролировать архивы и Storage;
- нет бизнес-семантики современного API;
- сложнее отслеживать состояние длинных Workflow;
- Server становится отдельным критичным компонентом.
Когда использовать SFTP
SFTP хорошо подходит, когда системы должны периодически обмениваться CSV, XML, архивами, отчетами и другими файлами.
Он особенно удобен при интеграции с внешними партнерами и Legacy Applications.
Когда лучше использовать API
Если требуется мгновенная обработка отдельных операций, подробные бизнес-ошибки и интерактивное взаимодействие, REST API или другой Application Interface часто удобнее.
Например, для создания одного заказа в реальном времени лучше POST Request, чем формирование CSV и ожидание следующего цикла обработки.
Связанные термины
| Термин | Связь с SFTP |
|---|---|
| SSH | Защищенный транспорт, поверх которого работает SFTP |
| FTP | Другой протокол передачи файлов |
| FTPS | FTP с TLS-защитой |
| SCP | Более простой способ передачи файлов через SSH |
| SSH Key | Используется для Authentication |
| Firewall | Ограничивает доступ к SFTP Server |
| VPN | Может закрывать SFTP от публичного интернета |
| Checksum | Используется для дополнительной проверки файла |
| Backup | Может использовать SFTP как транспорт |
| MFT | Корпоративная платформа управления файловыми обменами |
| REST API | Альтернативный подход к системной интеграции |
| Object Storage | Современное хранилище файлов с API-доступом |
Краткий итог
SFTP — протокол защищенного обмена файлами, работающий через SSH. Он позволяет загружать, скачивать, переименовывать, удалять файлы и управлять удаленными каталогами через зашифрованное соединение.
SFTP отличается от FTP и FTPS и обычно использует тот же TCP Port 22, что и SSH. Для Authentication можно применять Passwords, Public Keys и другие механизмы SSH.
В бизнес-интеграциях SFTP особенно полезен для регулярного обмена CSV, XML, отчетами и архивами. Для безопасной эксплуатации необходимо использовать отдельные Accounts, ограничивать доступ к файловой системе, проверять Host Key, защищать Private Keys и вести Audit операций. Надежный бизнес-процесс также должен учитывать частично загруженные файлы, дубликаты, архивирование и Monitoring.
