Семь ошибок при развертывании корпоративного файлового хранилища

Перенести документы из публичного облака на собственные серверы еще не значит закрыть вопрос безопасности. Меняется прежде всего модель ответственности. В облаке часть инфраструктурных рисков берет на себя провайдер. В on-premise контуре сетевые правила, обновления, резервное копирование, права пользователей и журналы событий становятся заботой самой компании.

И здесь легко попасть в ловушку. Раз сервер стоит «у нас», до него никто не доберется. Доберется, если архитектура это позволяет.

1. Административный интерфейс смотрит в интернет

Пользовательский веб-интерфейс файлового сервиса может быть доступен извне. Административный контур — другое дело. Панель управления, SSH, служебные API и интерфейсы гипервизора не должны превращаться в обычные интернет-сервисы.

Чем меньше точек администрирования видно снаружи, тем меньше поверхность атаки. Практичный вариант использовать VPN, bastion host или отдельный защищенный сегмент, MFA и журналирование административных действий.

2. Хранилище живет в одной сети со всем остальным

Файловое хранилище часто разворачивают там, где проще: рядом с прикладными серверами, интеграциями и внутренними сервисами. В результате компрометация одного узла дает атакующему пространство для дальнейшего движения по сети.

Сегментация нужна не ради красивой схемы в draw.io. Она ограничивает последствия инцидента. Пользовательский трафик, база данных, административный контур, интеграции и резервное копирование не обязаны доверять друг другу только потому, что принадлежат одной компании.

3. Права выдаются «чтобы не мешать работе»

Самый быстрый способ закончить внедрение — дать отделу доступ ко всей папке. Самый быстрый способ потерять контроль это оставить все так навсегда.

Права должны соответствовать реальной роли сотрудника и пересматриваться при переводах, увольнениях и изменении проектов. Особенно опасны общие учетные записи и накопленные привилегии: через год никто уже не помнит, почему конкретный пользователь видит каталог, к которому не имеет отношения.

4. У каждого сервиса свои учетные записи

Локальные аккаунты удобны на пилоте. В промышленной эксплуатации они быстро превращаются в отдельную систему кадрового учета, только без кадровиков.

Централизованная аутентификация через корпоративный каталог или Identity Provider позволяет применять общие политики, быстрее отзывать доступ и не оставлять забытые аккаунты после ухода сотрудников. Для привилегированных ролей нужна отдельная политика и многофакторная аутентификация.

5. Аудит есть, но им никто не пользуется

Галочка «вести журнал» сама по себе ничего не защищает. Если логи лежат на том же сервере, хранятся неделю и никогда не анализируются, при инциденте они превращаются в коллекцию строк, из которой поздно восстанавливать картину.

Журнал должен отвечать на практические вопросы: кто вошел, кто скачал или удалил файл, кто изменил права, что делал администратор. Для критичных систем события разумно передавать во внешнюю систему сбора и корреляции, чтобы их нельзя было тихо удалить вместе с исходным сервером.

6. Резервная копия существует только в отчете

Зеленый статус backup job еще не означает, что данные можно восстановить. Проверенной резервная копия становится только после успешного восстановления.

Бэкап, доступный с теми же привилегиями из той же инфраструктуры, уязвим для того же инцидента, что и основное хранилище. Поэтому нужны изоляция копий, отдельные учетные данные, защита от изменения и регулярные тесты. Проверять стоит не только файлы, но и конфигурацию, метаданные, базу и ключевые зависимости.

7. Обновления ждут «удобного окна»

On-premise дает компании право самой выбирать момент обновления. Но вместе с этим появляется обязанность следить за исправлениями безопасности и понимать, какие уязвимости относятся к конкретной версии продукта, ОС, СУБД и инфраструктурных компонентов.

Бесконечное «не трогаем, пока работает» постепенно превращает стабильную систему в архив известных уязвимостей. Нормальный процесс включает тестовый контур, план отката и понятный срок установки критических исправлений.

Свой контур — это не броня

У on-premise есть сильное преимущество. Организация сама определяет, где находятся данные, кто к ним подключается, как устроена сеть и какие средства защиты используются. Но контроль не равен безопасности автоматически.

Безопасность появляется, когда собственный контур действительно управляется: административные интерфейсы изолированы, сеть сегментирована, права ограничены, аутентификация централизована, события собираются, резервные копии восстанавливаются, обновления не лежат месяцами в очереди.

Поэтому главный вопрос при переходе в on-premise звучит не «где физически лежат наши файлы?». Полезнее спросить: кто и каким способом сможет до них добраться, если что-то пойдет не по плану?