Защита инфраструктуры: что проверить до договора
Защиту инфраструктуры заказывают не с выбора подрядчика, а с трезвого взгляда на собственные системы. Где лежат данные, кто имеет доступ, какие сервисы нельзя останавливать даже на час — с этих вопросов начинается работа, иначе договор быстро превращается в красивую папку без пользы.
Что подготовить до разговора с подрядчиком
До первого созвона нужно собрать карту активов, список критичных сервисов, текущие меры защиты и ограничения по доступам. Без этих данных подрядчик будет оценивать риски вслепую, а заказчик получит смету, похожую на гадание.
На практике самая мутная часть — не серверы и не сетевое оборудование, а старые связи между системами. Один бухгалтерский сервис тянет данные из базы, база завязана на файловое хранилище, хранилище открыто для филиала, о котором давно вспоминают только в декабре. В такой схеме защита инфраструктуры начинается с инвентаризации, причём не ради красивой таблицы, а ради понимания, что именно нельзя потерять.
Информационные технологии (IT) любят порядок на бумаге, но живут часто иначе. Где-то администратор хранит доступы в личном менеджере паролей, где-то подрядчик пятилетней давности всё ещё имеет учётную запись, где-то резервные копии создаются, но ни разу не проверялись на восстановление. Честно говоря, именно такие детали потом решают судьбу проекта.
- перечень серверов, рабочих станций, облачных сервисов и сетевых устройств;
- описание данных: персональные, финансовые, коммерческие, технические;
- список внешних подключений, подрядчиков и удалённых пользователей;
- текущие средства защиты и срок действия лицензий;
- регламент резервного копирования и последний тест восстановления.
А ведь один пропущенный удалённый доступ способен перечеркнуть дорогой проект. Поэтому перед заказом работ полезно смотреть не только на «железо», но и на людей: кто заводит учётные записи, кто увольняет сотрудников из систем, кто разрешает доступ подрядчикам ночью. В инфраструктуре редко ломается что-то одно. Обычно слабое место появляется там, где техника, процесс и привычка встречаются без контроля.
Как понять реальный объём работ
Объём работ определяется не числом компьютеров, а критичностью сервисов, уровнем рисков, архитектурой сети и требованиями к непрерывности. Две компании с одинаковым парком техники могут получить разные проекты защиты.
Простой пример: у одной организации сто рабочих мест и один файловый сервер, у другой — те же сто рабочих мест, но ещё личный кабинет клиентов, интеграция с платёжным шлюзом и удалённые инженеры по всей стране. Формально размер похож. По рискам — разные миры. Поэтому хорошая оценка начинается с вопросов, которые иногда звучат неудобно: кто остановит бизнес-процесс при атаке, сколько часов допустим простой, какие данные утекут первыми?
| Зона проверки | Что выяснить | Почему это влияет на цену |
|---|---|---|
| Сеть | Сегменты, удалённые доступы, межсетевые правила | Чем сложнее связи, тем больше настройка и тестирование |
| Данные | Типы сведений, места хранения, права пользователей | Защита персональных и финансовых данных требует особого контроля |
| Сервисы | Критичность, допустимый простой, зависимые системы | Непрерывные сервисы защищают без грубых отключений |
| Люди | Роли администраторов, подрядчиков, сотрудников | Ошибки доступа часто дают атакующему первый вход |
Не все работы нужны сразу. Сначала закрывают входные двери: удалённый доступ, привилегированные учётные записи, обновления, резервные копии, журналы событий. Затем переходят к мониторингу, сегментации, защите почты, обучению сотрудников. Такая очередность родилась не из учебников, а из расследований инцидентов: злоумышленник редко начинает с экзотики, ему хватает открытого сервиса или пароля, который годами гулял по чатам.
Какие пункты внести в техническое задание
В техническом задании нужны границы работ, измеримые результаты, порядок доступа, требования к отчётам и правила приёмки. Если этих пунктов нет, спор о качестве начнётся уже после первой поставки.
Техническое задание должно отвечать на скучные, но болезненные вопросы. Кто выдаёт доступ подрядчику? В какие часы он работает? Какие действия запрещены без письменного согласования? Как фиксируются изменения? Где хранится отчёт? При внешней простоте эти вопросы защищают обе стороны: заказчик не теряет контроль, исполнитель не работает в серой зоне.
- описать контур: офис, облака, филиалы, удалённые пользователи;
- разделить работы на обследование, настройку, тестирование и сопровождение;
- задать формат отчёта: найденный риск, доказательство, способ устранения, приоритет;
- указать требования к сохранности данных и запрет на несанкционированное копирование;
- закрепить критерии приёмки: что считается выполненной работой.
Кстати, в договоре часто забывают про аварийный сценарий. Если настройка защиты нарушит работу сервиса, кто откатывает изменения и за какое время? Где лежит резервная конфигурация? Кто отвечает за связь с владельцем системы? Эти детали не выглядят эффектно на презентации, зато в день сбоя отделяют рабочий проект от хаоса.
Отдельной строкой нужна конфиденциальность. Подрядчик при обследовании видит сетевые схемы, имена серверов, учётные политики, иногда фрагменты клиентских данных. Доступ к такой информации дают только по роли и сроку, а после завершения проекта учётные записи закрывают. Здесь нет мелочей: забытый доступ через полгода превращается в чужой вход в инфраструктуру.
Как отличить зрелого исполнителя от продавца коробок
Зрелый исполнитель сначала выясняет контекст, риски и ограничения, а уже потом предлагает инструменты. Если разговор сразу сводится к покупке лицензий, проекту не хватает инженерной части.
Сильный подрядчик задаёт неприятные вопросы и не обещает чудес. Он просит схемы, уточняет критичность сервисов, проверяет резервное копирование, спрашивает про старые инциденты. Продавец коробок говорит про продукт, зрелая команда говорит про сценарии атаки, порядок внедрения и последствия для бизнеса. Разница слышна уже на первом обсуждении.
| Признак | Надёжный подход | Тревожный сигнал |
|---|---|---|
| Оценка | Запрашивают данные об инфраструктуре | Называют цену без обследования |
| Решение | Объясняют, какие риски закрывает каждая мера | Продвигают один продукт для всех задач |
| Отчёт | Дают доказательства, приоритеты и план исправлений | Пишут общие фразы без проверяемых выводов |
| Сопровождение | Описывают реакцию на сбои и изменения | Исчезают после установки средств защиты |
Есть ещё один признак, почти бытовой. Хороший специалист не раздражается, когда его просят объяснить ограничение, риск или цену. Он не упрощает до детского уровня, но переводит инженерный язык на язык последствий: где простой, где утечка, где штраф, где репутационный удар. После такого разговора у руководителя появляется не иллюзия полной безопасности, а рабочая картина угроз.
Финальное решение редко рождается из одного коммерческого предложения. Нужны встреча с техническими специалистами, короткое обследование, согласование границ и проверка договора юристами. Да, звучит буднично. Зато защита инфраструктуры держится именно на будничных вещах: списках доступов, журналах, копиях, правилах изменения конфигураций и людях, которые отвечают за каждое действие.
Вывод
Перед заказом защиты инфраструктуры нужно собрать факты о системах, данных, доступах и критичных процессах. Тогда подрядчик проектирует меры под реальный контур, а не под абстрактную схему из презентации.
Хороший проект начинается до договора: с инвентаризации, честного разговора о рисках и ясных критериев приёмки. Если эти основы зафиксированы, инструменты становятся частью системы защиты, а не дорогим набором настроек, о которых вспоминают только после инцидента.