Сайт работает — но безопасен ли он? Что проверить до первого инцидента

Сайт работает, заявки приходят, страницы открываются — и кажется, что с безопасностью всё в порядке. Пока не выясняется, что у ушедшего подрядчика остался доступ к хостингу, обновления месяцами никто не проверял, ключи интеграций лежат в переписке, журналы не смотрят, а резервную копию никогда не восстанавливали.

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

Если бизнес не может назвать актив, владельца, доступ и способ восстановления, он не контролирует риск — он просто надеется, что ничего не случится.

Веб-контур обычно шире самого сайта: домен и DNS, хостинг или облако, CMS, база данных, файловое хранилище, репозиторий, CI/CD, аналитика, CRM, почта, платёжный сервис, карты, CDN, API-ключи, резервные копии и аварийные аккаунты.

Для каждого актива зафиксируйте: что он делает, какие данные или операции затрагивает, кто бизнес-владелец, кто администрирует, как выдают доступ, где хранится резервная информация и как подтверждается состояние. Не обязательно делать идеальный документ в первый день. Важно обнаружить «бесхозные» куски, которые вспоминают только при сбое.

Карта нужна и для приоритизации. Недоступность блога и недоступность оплаты — разные последствия. Одна и та же техническая проблема требует разной скорости реакции в интернет-магазине, B2B-портале и информационном сайте.

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

CMS, плагины, серверные компоненты и библиотеки меняются. Вопрос не «обновлять ли всё немедленно», а есть ли перечень версий, источник уведомлений, оценка влияния, тестовый контур и обратимый релиз. Сканер может найти часть проблем, но не заменяет процесс: кто принимает решение, тестирует исправление и убеждается, что оно дошло до production.

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

Резервная копия полезна, только если есть проверенная процедура восстановления критичных сценариев. Файлы, база, конфигурация и секреты могут существовать отдельно. Наличие архива не доказывает, что сервис после восстановления принимает форму, показывает заказ или отправляет данные в CRM.

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

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

OWASP ASVS — открытый стандарт проверки технических контролей веб-приложений. Его не нужно пересказывать целиком в договоре на сайт. Он полезен как язык требований: проверка аутентификации, управления сессиями, доступом, конфигурацией, журналами и другими контролями должна быть конкретной, а не выражаться фразой «сделайте безопасно».

В разговоре о безопасности часто смешивают хорошую практику, условия договора и обязательную норму права. Это разные вещи. Многофакторный вход или независимое тестирование могут быть разумным контролем для конкретного риска. Заказчик может закрепить их в договоре. А обязательные требования российского права определяются применимым регулированием и конкретной информационной системой.

OWASP ASVS — добровольная отраслевая основа, а не российский нормативный акт и не сертификат безопасности. На дату проверки последняя стабильная версия ASVS — 5.0.0, выпущенная 30 мая 2025 года; перед публикацией этот номер нужно перепроверить. Стандарт полезен тем, что даёт проверяемый язык для требований и оценки технических контролей. Если в договоре ссылаются на отдельные требования ASVS, версию указывают вместе с идентификатором требования: иначе со временем ссылка может изменить смысл.

Если сайт и связанные системы образуют информационную систему персональных данных, применимые меры определяют с учётом статьи 19 Закона №152-ФЗ и уровня защищённости по постановлению Правительства №1119. Постановление устанавливает четыре уровня, а выбор зависит от вида данных, типа актуальных угроз, количества субъектов и обработки данных работников. Приказ ФСТЭК №21 относится к выбору организационных и технических мер для ИСПДн. Ни постановление, ни приказ нельзя превратить в одинаковый чек-лист для каждого сайта или применять без обследования.

Слабое место часто находится не в странице. Форма передаёт заявку в CRM, CRM — в почту, платёж — в банк, DNS управляет и сайтом, и корпоративной почтой. Поэтому проверка «сайта» без внешних сервисов оставляет слепые зоны.

Нужно отличать техническую безопасность от правовой работы с персональными данными. Если система обрабатывает персональные данные, применимые требования зависят от контекста и уровня защищённости информационной системы; универсального списка для любого сайта нет. Его нельзя заменить чек-листом из интернета. Юридическую применимость и состав обязательных мер должен подтверждать профильный специалист.

SSL, WAF и один сканер могут быть полезны, но ни один из них не создаёт управляемый контур безопасности в одиночку.

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

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

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

Безопасность не должна появляться только перед сдачей проекта. При добавлении формы команда проверяет данные, получателей и права доступа. При подключении API — владельца ключа, разрешения, журнал ошибок и способ отзыва. При обновлении компонента — тестовый контур и rollback. При увольнении — доступы, сессии, токены и recovery-контакты. Такие проверки не требуют от каждого сотрудника быть специалистом по ИБ, но требуют понятного маршрута к специалисту, когда риск выходит за пределы обычной работы.

В договоре с подрядчиком полезно разделить зоны: кто сообщает об уязвимостях компонентов, кто устанавливает исправления, кто поддерживает конфигурацию, кто хранит резервные данные, кто участвует в расследовании. Если ответ везде «подрядчик», компания остаётся без способа проверить обязательство и принять решение при конфликте. Если ответ везде «внутренний ИТ», но у него нет доступа к коду и облаку, схема столь же ненадёжна.

Ни одна такая мера не гарантирует отсутствие инцидентов. Её смысл — сократить неопределённость, заметить проблему раньше и иметь воспроизводимый путь восстановления. Именно это можно требовать от управляемого контура.

Фраза «доступы настроены» не является доказательством. Доказательством может быть актуальная матрица ролей, журнал пересмотра, выборочная проверка учётных записей и инструкция отзыва. «Копии есть» подтверждается не названием задания, а результатом восстановления в изолированном контуре и проверкой критичного действия. «Обновления ставим» — журналом версий, бюллетенями, тестом и результатом релиза.

Такой подход полезен и при работе с подрядчиком. Компания не обязана самостоятельно оценивать криптографию или проводить пентест. Но она вправе запросить объект контроля, владельца, дату последней проверки, найденное ограничение и следующий срок. Этот язык снижает зависимость от успокаивающих формулировок и не подменяет профессиональный аудит.

Банк данных угроз ФСТЭК — официальный справочный источник сведений об угрозах и уязвимостях. Но наличие или отсутствие записи там не доказывает защищённость конкретного сайта. Для оценки нужны версии компонентов, официальные бюллетени их производителей, сведения о том, используется ли уязвимая функция, и результат проверки именно вашего контура.

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

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

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

Смысл обзора не в том, чтобы самостоятельно назначить уровень защищённости или провести техническую экспертизу. Он выявляет места, где требуется специализированная работа и где бизнес потерял владельца. Так контроль превращается в регулярную управленческую практику, а не в реакцию на тревожную новость.

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

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

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

Реестр нужно пересматривать после каждого существенного изменения контура.

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

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