Информационная безопасность бизнеса: как защитить данные, доступы и серверы

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

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

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

Что именно вы защищаете: активы, точки входа и три разных последствия

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

Активы небольшой компании

• Почта и учётные записи. Через почту идёт переписка с контрагентами, и через неё же восстанавливают пароль почти ко всем остальным сервисам. Доступ к почте открывает дорогу к CRM, банку, хостингу и облачным дискам.
• 1С и базы данных. Остановка означает, что не выписать документы, не принять заказ, не провести оплату.
• Файловые серверы и общие папки. Частая цель шифровальщика: к общим папкам подключены все, права разграничены редко.
• Персональные данные. Клиентская база, кадровые документы, сканы паспортов подрядчиков. Их утечка создаёт отдельные обязанности и отдельные штрафы.
• Сайт и личные кабинеты. Через них компания получает заявки и платежи.
• Удалённый доступ. VPN-шлюз, опубликованный наружу RDP (подключение к рабочему столу Windows по сети), терминальный сервер. Это дверь, которая по определению открыта в интернет.

Точки входа

До активов добираются шестью путями:

1. Украденный или подобранный пароль.
2. Письмо с вложением или ссылкой, которое открыл сотрудник.
3. Необновлённое программное обеспечение на сервере или сетевом устройстве.
4. Сервис, опубликованный в интернет без нужды.
5. Доступ бывшего сотрудника или подрядчика, который никто не отозвал.
6. Физический вынос ноутбука или флешки.

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

Три последствия, которые нельзя смешивать

У этих последствий разные меры защиты. Резервная копия не спасает от утечки: данные уже скопированы. Антивирус в одиночку не выручит при шифровальщике, если копии лежат в той же сети под той же учётной записью.

При утечке персональных данных действуют жёсткие сроки. По части 3.1 статьи 21 закона 152-ФЗ у оператора есть 24 часа, чтобы сообщить Роскомнадзору о самом инциденте, и 72 часа — чтобы доложить о результатах внутреннего разбора. Часы начинают идти с момента, когда факт установил оператор, уполномоченный орган или иное заинтересованное лицо. Срок может течь, даже если компания узнала об утечке последней.

Риски по приоритету: что проверить и кто исправляет

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

Строку про Wi-Fi можно закрыть быстро: отдельная гостевая сеть, WPA2-AES или WPA3 вместо устаревших WPA и WEP, отключённый WPS и смена ключа при уходе человека, который его знал. Подробный порядок проверки на двенадцать пунктов собран в чек-листе безопасности корпоративного Wi-Fi.

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

Порядок внедрения: шесть направлений, у каждого свой критерий проверки

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

1. Инвентаризация: что у вас есть

Соберите список: серверы и их роли, рабочие станции, сетевое оборудование, внешние сервисы с подписками (почта, облачные диски, CRM, хостинг, домен), учётные записи с правами администратора, поставщик каждого сервиса. Отдельной строкой — что из этого доступно из интернета.

Владелец: IT-ответственный. Критерий проверки: список открывается за минуту, в нём нет строк «кажется, ещё был какой-то сервер», и у каждого внешнего сервиса указан человек, который за него отвечает.

2. Доступы: привилегированные учётные записи, второй фактор, минимальные права

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

Про второй фактор нужна точность, потому что в старых инструкциях он сводится к «на телефон приходит код». Методы отличаются по стойкости. Код в SMS перехватывают. Обычное push-подтверждение обходят приёмом push bombing, он же усталость от подтверждений: человека заваливают запросами, пока он не нажмёт «разрешить». Так это описывает CISA, агентство кибербезопасности США. Устойчивые к фишингу методы — аппаратные ключи и FIDO2: подтверждение привязано к адресу сайта, поэтому поддельная страница его не получит. Для компаний, которые не могут внедрить их сразу, CISA называет лучшими доступными вариантами одноразовые коды в приложении-генераторе или push с подтверждением номера на экране.

Пароли при этом работают по другим правилам, чем десять лет назад. Действующая редакция стандарта NIST SP 800-63B-4, вышедшая в июле 2025 года (NIST — американский институт стандартов, в России он ничего не предписывает), прямо запрещает требовать от людей периодическую смену пароля: менять его обязательно только при признаках компрометации. Требования «заглавная плюс цифра плюс спецсимвол» там тоже запрещены. В документе объяснено почему: человек, который выбрал бы password, при требовании заглавной и цифры выберет Password1. Вместо этого — длина (минимум 15 символов, если пароль работает единственным фактором, и минимум 8, если он часть многофакторного входа), сверка нового пароля со списком известных и утёкших паролей и ограничение числа попыток входа.

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

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

3. Обновления: группами по степени риска

Разделите парк на три группы. Первая — то, что смотрит в интернет: VPN-шлюз, межсетевой экран, почтовый шлюз, сайт. Обновления безопасности здесь ставят в течение считанных дней. Вторая — серверы внутри сети: домен, 1С, файловые и гипервизор (машина, на которой запущены виртуальные серверы компании). Их обновляют в плановое окно с предварительной проверкой на тестовой машине или на снимке состояния виртуальной машины, к которому можно откатиться за минуты. Третья — рабочие станции, где автоматические обновления можно просто не выключать.

Отдельно проверьте сроки поддержки.

Владелец: IT-ответственный. Критерий проверки: по каждой группе видно дату последнего установленного обновления безопасности, и ни одна система с истёкшей поддержкой не смотрит в интернет.

4. Резервные копии: разделение копий и проверенное восстановление

Копия, которую никто не восстанавливал, — это надежда, а не копия. Базовая схема известна как правило 3-2-1: три копии данных, на двух разных носителях, одна — вне площадки. Эта формулировка есть в старом документе на сайте CISA. В нём ничего не сказано об изоляции копий, поэтому добавьте ещё одно условие: хотя бы одна копия недоступна из рабочей сети. Это отключённый носитель или хранилище с неизменяемыми копиями.

Условие не теоретическое. Руководство #StopRansomware выпустили CISA, центр обмена информацией MS-ISAC, Агентство национальной безопасности и ФБР. В нём прямо описано: операторы шифровальщиков целенаправленно удаляют или шифруют доступные резервные копии и теневые копии системы. Теневые копии — это встроенные в Windows снимки файлов, из которых откатывают отдельный файл на несколько дней назад. Для доступа к самой системе резервного копирования используют украденные учётные данные. Там же сказано, что автоматических копий в облако может быть недостаточно: если файлы на машине зашифрованы, они синхронизируются в облако и могут перезаписать нетронутые данные. Корзина и история версий облачного диска выручают при случайном удалении файла, с шифрованием это работает хуже.

Владелец: IT-ответственный, контроль за руководителем. Критерий проверки: раз в квартал выполняется пробное восстановление одной базы и одной папки на отдельную машину, результат записывается с датой и временем, которое заняло восстановление.

5. Сеть, удалённый доступ и журналы

Разделите сеть хотя бы на три части: рабочие машины, серверы, гостевой Wi-Fi с личными устройствами. На управляемом коммутаторе это отдельные VLAN, на простом роутере — отдельная гостевая сеть с запретом доступа из неё в рабочую подсеть. Удалённый доступ пустите через VPN с вторым фактором: WireGuard или IPsec на шлюзе, OpenVPN там, где он уже стоит. Публиковать RDP напрямую в интернет не нужно; если убрать публикацию нельзя сегодня, оставьте доступ только с известных адресов и закройте порт 3389 для всего остального. Между офисами поднимите шифрованный канал на IPsec между шлюзами. Собирайте журналы входов с серверов и сетевого оборудования в одном месте — на Syslog-сервере, то есть службе, которая принимает журналы по сети, или через штатный сбор событий Windows. Назначьте день недели, в который их смотрят. Средства обнаружения вторжений дают эффект только после этого шага, иначе их оповещения никто не читает; как они устроены, разобрано отдельно в статье про защиту корпоративной сети от взломов и вторжений.

Владелец: IT-ответственный или подрядчик по сети. Критерий проверки: три пункта. Список портов, видимых из интернета, совпадает со списком сервисов, которые там должны быть, и в нём нет ни одного «не знаю, зачем это открыто». С гостевого Wi-Fi не открывается рабочая общая папка. Журналы входов за последние 30 дней лежат в одном месте, и у них есть назначенный читатель с днём недели.

6. Люди: разбор конкретных писем

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

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

Как проверить защиту руками: команды для IT-ответственного

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

Что слушает сеть

Windows 10 и 11, Windows Server 2016 и новее (на Server 2012 и 2012 R2 команды тоже есть, но в актуальной документации Microsoft эти версии уже не описаны). Права администратора для списка сокетов — пар «адрес плюс порт», на которых служба ждёт подключений — не нужны. Чтобы сопоставить идентификатор из колонки OwningProcess с именем процесса, скорее всего понадобится запуск от администратора: требования к правам в документации не описаны.

Get-NetTCPConnection -State Listen | Sort-Object LocalPort | Select-Object LocalAddress,LocalPort,OwningProcess
Get-NetUDPEndpoint | Sort-Object LocalPort | Select-Object LocalAddress,LocalPort,OwningProcess

Linux с установленным пакетом сетевых утилит iproute2 (есть по умолчанию в Ubuntu, Debian, Astra Linux, РЕД ОС). Без root адреса и порты видны, но колонка процессов останется пустой. Первая команда печатает слушающие сокеты, вторая — правила встроенного в Linux межсетевого экрана nftables, то есть что он вообще пропускает внутрь:

sudo ss -tulpn
sudo nft list ruleset

Смотрите на номер порта и адрес, на котором служба ждёт подключений. 0.0.0.0 и :: означают «слушает на всех интерфейсах», 127.0.0.1 — только локально. Разбираться надо, если СУБД, сервер 1С, общие папки или RDP слушают все интерфейсы на машине, которая смотрит в интернет.

Команды показывают состояние самой машины; доступность снаружи по их выводу не определить. Между службой и интернетом стоят брандмауэр и трансляция адресов на маршрутизаторе: пока порт не проброшен вручную, служба внутри сети снаружи не отвечает. Доступность из интернета проверяют отдельно — по правилам проброса портов на роутере и правилам межсетевого экрана на входе в сеть. Если на Linux правила заведены через предыдущий механизм iptables, nft list ruleset может показать пустой вывод, хотя фильтрация работает.

Какие обновления реально установлены

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object HotFixID,Description,InstalledOn -First 20

grep -E ' (install|upgrade) ' /var/log/dpkg.log | tail -40
dnf history list

Первая команда работает на Windows, вторая — на Debian, Ubuntu и Astra Linux, третья — на РЕД ОС и других дистрибутивах с пакетным менеджером dnf. Две последние показывают все установленные пакеты без деления на обновления безопасности и прочие, а старые записи журнала со временем ротируются, поэтому глубина истории ограничена.

У Get-HotFix есть ограничение: по документации Microsoft команда возвращает только обновления, установленные через штатный механизм Component Based Servicing, которым ставятся компоненты и накопительные обновления. Обновления, установленные пакетом MSI или скачанные с сайта Windows Update, она не показывает. Полный номер сборки системы надёжнее:

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' | Select-Object ProductName,DisplayVersion,CurrentBuild,UBR

Номер сборки складывается из CurrentBuild и UBR (последняя часть номера, она меняется с каждым накопительным обновлением). Именно его вендор указывает в бюллетенях безопасности.

Состояние резервных копий

На Windows Server с установленной ролью резервного копирования, от администратора:

Get-WBSummary

wbadmin get versions

Обе команды знают только про штатное резервное копирование Windows. Если копии делает Veeam, Acronis, встроенная выгрузка 1С или свой скрипт, их состояние смотрят в самой программе.

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

systemctl list-timers --all
sudo journalctl -u backup.service --since "-7d" -p err --no-pager

Имя юнита подставьте своё. Нужны три ответа: когда последний запуск, был ли он удачным, когда следующий. Если резервное копирование собрано самописным скриптом по расписанию cron без записи результата в журнал, ответов не будет вообще — это само по себе находка.

Журналы входов

Неудачные попытки входа на Windows за сутки (событие 4625, журнал Security, нужны права администратора):

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} | Select-Object TimeCreated,Message -First 20 | Format-List

То же на Linux:

sudo journalctl -u ssh -u sshd --since "-1d" --grep 'Failed password|Invalid user|authentication failure' --no-pager
sudo lastb -n 30 -F -i

Единичные неудачные входы — обычный шум: кто-то опечатался. Разбираться стоит в двух случаях: сотни попыток по разным именам с одного адреса и удачный вход сразу после серии неудачных.

Пустой вывод не означает, что попыток не было. На Windows аудит отказов входа может быть отключён политикой, а журнал Security перезаписывается по кругу при нехватке места. На Linux файл btmp, из которого читает lastb, есть не во всех дистрибутивах, и неудачные попытки входа по ключу в него не попадают.

Удалённый доступ и второй фактор

Действующие настройки SSH (именно действующие: файл конфигурации может с ними расходиться):

sudo sshd -T | grep -iE '^(port|passwordauthentication|permitrootlogin|pubkeyauthentication)'

passwordauthentication yes означает, что вход по паролю разрешён и сервер подбирают. Целевое состояние для сервера, доступного извне: вход по ключу, passwordauthentication no, permitrootlogin no. Оговорка: без ключа -C команда не разворачивает блоки Match, поэтому исключения для отдельных пользователей и подсетей в таком выводе не видны.

Включён ли для RDP сетевой уровень аутентификации, то есть проверка логина и пароля до того, как сервер покажет рабочий стол (значение UserAuthenticationRequired, равное 1, означает, что он включён):

Get-CimInstance -Namespace root/CIMV2/TerminalServices -ClassName Win32_TSGeneralSetting | Select-Object TerminalName,UserAuthenticationRequired,SecurityLayer,PolicySourceUserAuthenticationRequired

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

Для облачного каталога Microsoft Entra ID, где лежат учётные записи компании, выборка администраторов без второго фактора делается так:

Connect-MgGraph -Scopes 'AuditLog.Read.All'
Get-MgReportAuthenticationMethodUserRegistrationDetail -Filter "isMfaRegistered eq false" -All | Where-Object IsAdmin -eq $true | Select-Object UserPrincipalName,IsMfaRegistered,IsMfaCapable

Здесь три нюанса. Отобрать администраторов на стороне сервера нельзя: свойство isAdmin фильтрацию в запросе не поддерживает, поэтому отбор идёт уже на вашей машине. Отчёт показывает только то, что метод второго фактора зарегистрирован. Требуется ли он при входе, задают политики условного доступа (правила, которые решают, у кого и при каких условиях второй фактор спрашивают обязательно) или параметры безопасности по умолчанию. Администратор с зарегистрированным методом всё ещё может входить по одному паролю. Данные отчёта обновляются до 36 часов, а отключённые и недавно удалённые учётные записи в него не попадают, поэтому отключённая админская запись в выводе не появится, хотя её могут включить обратно. Для запуска нужен установленный модуль Microsoft Graph PowerShell и роль, позволяющая читать отчёты.

Две уязвимости 2025 и 2026 годов: WSUS и vCenter

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

CVE-2025-59287: сервер обновлений как входная дверь

Уязвимость в роли Windows Server Update Services (WSUS) — сервере, который в компании с доменом ставят специально для централизованной установки обновлений. Служба принимает присланный по сети объект и собирает его обратно, не проверяя содержимое, поэтому вместе с данными приезжает и чужой код: это и называется небезопасной десериализацией. Итог — выполнение кода по сети без аутентификации, оценка CVSS 9.8 по базовому вектору (CVSS — общая десятибалльная шкала опасности уязвимости; 9.8 означает, что код запускают по сети и без пароля).

Бюллетень Microsoft вышел 14 октября 2025 года в составе плановых обновлений, а 23 октября Microsoft выпустил внеплановое обновление, потому что первого исправления оказалось недостаточно. Для серверов в программе горячих исправлений, где обновления ставятся без перезагрузки, 24 октября вышло отдельное обновление. В тот же день CISA внесла уязвимость в каталог эксплуатируемых и дала федеральным агентствам США срок до 14 ноября. О срочности говорит внеплановое обновление: плановые обновления Microsoft выпускает раз в месяц, а это вышло через девять дней после бюллетеня.

Как проверить применимость:

Get-WindowsFeature -Name UpdateServices*
Get-HotFix | Where-Object { $_.HotFixID -eq 'KB5070884' }

Первая команда покажет, включена ли роль. Microsoft отдельно оговаривает: роль WSUS по умолчанию выключена, и сервер без неё не уязвим. Вторая проверяет наличие обновления, в примере — для Windows Server 2022; свои номера: KB5070882 для Server 2016, KB5070883 для Server 2019, KB5070884 для Server 2022, KB5070881 для Server 2025, KB5070886 и KB5070887 для Server 2012 R2 и 2012.

У второй команды то же ограничение, что описано выше: Get-HotFix видит не все способы установки, поэтому пустой вывод означает «не подтверждено» и не доказывает, что обновление не стоит. Окончательный ответ даёт номер сборки: сверьте CurrentBuild и UBR с исправленной сборкой из бюллетеня по вашему KB.

Если обновление поставить нельзя сейчас, в бюллетене описаны два обходных пути: отключить роль WSUS (клиенты перестанут получать с него обновления) или заблокировать входящий трафик на порты 8530 и 8531 на хостовом межсетевом экране (именно на хостовом, не только на периметровом). Оба делают WSUS неработоспособным, и снимать их Microsoft советует только после установки обновления.

CVE-2026-59310: гипервизор, под которым живёт весь бизнес

vCenter — единая панель управления виртуальными серверами VMware: через неё создают, переносят и выключают машины. Внутри неё работает Syslog-сервер, служба приёма журналов от других машин по сети. В нём нашли обход каталога: в имя файла подставляют путь вида ../, и служба пишет файл за пределами своей папки. Оценка CVSS 9.8. В бюллетене сказано, что злоумышленник с сетевым доступом к vCenter может выполнить произвольный код; базовый вектор указывает, что ни прав в системе, ни действий пользователя для этого не нужно, а условий вида «нужна включённая опция» бюллетень не называет.

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

Бюллетень Broadcom вышел 29 июля 2026 года, обновлён 19 августа. 18 августа CISA внесла уязвимость в каталог эксплуатируемых с пометкой о подтверждённом использовании в кампаниях вымогателей и дала федеральным агентствам три дня на устранение.

Затронутые версии и исправления:

Версию видно без командной строки: откройте интерфейс управления по адресу https://<адрес-вашего-vcenter>:5480 и посмотрите блок с текущей версией и номером сборки. Версия в этом интерфейсе и версия в vSphere Client могут отличаться, потому что это разные компоненты; ориентироваться надо на интерфейс управления.

Обходных путей у этой уязвимости нет: в бюллетене в колонке с обходными решениями стоит «None». До обновления риск можно снизить: убрать vCenter из публичного доступа и держать его в отдельном административном сегменте сети. В бюллетене этой меры нет, это общая практика.

Что из этого следует для компании

За последний год в каталог эксплуатируемых уязвимостей CISA добавляли записи 2008-2024 годов, включая уязвимости того же vCenter и Exchange. Атакуют и то, что не обновляли годами, потому что «работает же». Поэтому нужен порядок: у каждой системы есть ответственный, окно обновления и дата последней проверки. Одна срочная установка обновления после громкой новости закрывает одну дыру из списка, который накопился за годы.

Если инцидент уже случился

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

1. Изолируйте подозрительную машину, не выключая её. Отключите сетевой кабель или отключите Wi-Fi, но не выдёргивайте питание и не переустанавливайте систему: вместе с ними уйдут журналы и следы, по которым видно, как попали внутрь и что успели забрать.
2. Смените доступы с другого устройства. Пароли администраторов, пароли к почте, банку, хостингу, регистратору домена и системе резервного копирования меняйте с машины, которая точно не затронута. Одновременно завершите активные сессии, иначе смена пароля не выгонит того, кто уже внутри.
3. Проверьте резервные копии прежде, чем что-то восстанавливать. Убедитесь, что копии на месте, что к ним не было доступа с заражённых учётных записей и что они открываются. Если копии лежали в той же сети под теми же правами, считайте их под вопросом до проверки.
4. Ищите причину, а потом восстанавливайте. Восстановление на ту же непропатченную систему с теми же доступами заканчивается повторным заражением через несколько дней.
5. Проверьте, могли ли персональные данные утечь: их скопировали или к ним получили доступ. Если да, включается обязанность уведомить Роскомнадзор в сроки из первого раздела: сутки на сообщение об инциденте, трое на итоги внутреннего разбора. Неуведомление обойдётся организации в 1-3 млн рублей по части 11 статьи 13.11 КоАП. Сама утечка сведений о 1 000 — 10 000 человек — это 3-5 млн рублей по части 12 той же статьи. Эти составы введены законом от 30 ноября 2024 года и действуют с 30 мая 2025 года. Оборотный штраф (от 1 до 3% годовой выручки, не менее 20 млн и не более 500 млн рублей) применяется только при повторном нарушении.
6. Зафиксируйте хронологию. Что заметили, когда, что сделали, кто принимал решения. Это нужно и для внутреннего расследования, и для общения с регулятором.

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

Когда нужен внешний аудит информационной безопасности

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

1. Нет инвентаризации активов и внешних сервисов.
2. Никогда не пробовали восстановиться из резервной копии.
3. Доступы уволенных не отзывались.
4. Из интернета доступны сервисы, про которые никто не может объяснить, зачем они открыты.
5. Инциденты повторяются, а причину каждый раз не находят.

Аудит и сопровождение решают разные задачи.

Как устроена сама процедура проверки, подробно разобрано в статье про аудит IT-безопасности.

Законодательного соответствия аудит сам по себе не даёт. Выполнение требований 152-ФЗ — отдельная работа с документами, уведомлением регулятора и организационными мерами, и ни одна техническая проверка её не заменяет.

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

Об авторе статьи

Алексей Блок

Технический эксперт компании «Инновационные Информационные Системы». Специализируется на построении, модернизации и сопровождении корпоративной IT-инфраструктуры.

Профессиональные интересы: DevOps, контейнеризация, Kubernetes, информационная безопасность, IT-аудит, обслуживание серверов, системное администрирование, настройка сетей.

Больше информации.