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