Кибербезопасность в государственной и муниципальной администрации

Роль кибербезопасности и угрозы для органов власти

Зачем кибербезопасность нужна государственной и муниципальной администрации

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

предоставление госуслуг и муниципальных сервисов

работа реестров, архивов, систем документооборота

управление городским хозяйством и критической инфраструктурой

защита персональных данных и служебной информации

поддержание общественной стабильности и доверия к институтам власти

Органы власти одновременно являются:

владельцами данных (персональные данные, сведения о собственности, социальные выплаты)

регуляторами (устанавливают требования безопасности для подведомственных организаций)

операторами сервисов (порталы, МФЦ, системы межведомственного взаимодействия)

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

Что именно защищают органы власти

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

Данные

- персональные данные граждан - данные о выплатах, льготах, налогах, штрафах - сведения ограниченного распространения (служебная информация)

Сервисы и процессы

- порталы и личные кабинеты - электронный документооборот - межведомственный обмен - системы записи/очередей, call-центры, МФЦ

Инфраструктуру

- рабочие места сотрудников - серверы, сети, Wi‑Fi - облачные сервисы и хостинг - резервное копирование и хранилища

Доверие и репутацию

- доверие к электронным услугам - легитимность решений и процедур

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

Особенности органов власти, которые усиливают риски

В сравнении с коммерческими организациями администрация часто сталкивается со специфическими условиями:

Масштаб и разнообразие ИТ-среды

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

Жесткие требования к доступности

1. Порталы и услуги должны работать в пиковые периоды. 2. Остановка сервиса может означать невозможность получить пособие, справку, запись к врачу или регистрацию.

Высокая привлекательность для атакующих

1. Доступ к персональным данным и документам. 2. Возможность влияния на общественные процессы. 3. Политическая и экономическая мотивация атак.

Сложность управления поставщиками

1. Закупочные процедуры и длительные циклы обновления. 2. Зависимость от подрядчиков, интеграторов, хостинга.

Базовые понятия: угроза, уязвимость, риск и инцидент

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

Угроза — то, что может причинить вред (например, фишинг, вредоносное ПО, злоупотребление доступом).

Уязвимость — слабое место, которое позволяет угрозе реализоваться (например, отсутствие MFA, устаревший сервер, неверные права доступа).

Риск — сочетание вероятности и ущерба, если угроза реализуется через уязвимость.

Инцидент — фактически произошедшее событие, влияющее на конфиденциальность, целостность или доступность.

Модель, на которой удобно держать фокус, — триада конфиденциальность, целостность, доступность:

Конфиденциальность: кто имеет право видеть данные.

Целостность: кто и как может изменять данные, и можно ли доверять их корректности.

Доступность: можно ли получить услугу и данные вовремя.

Кто атакует органы власти

Типовые категории нарушителей отличаются мотивацией и методами:

Киберпреступники

- чаще всего ради денег (вымогательство, продажа данных)

Группы, действующие в интересах государств

- шпионаж, влияние, нарушение работы институтов

Хактивисты

- публичные атаки ради идеологии или внимания

Недобросовестные инсайдеры

- злоупотребление доступом сотрудника или подрядчика

Случайные нарушители

- ошибки персонала, неправильные настройки, потеря носителей

Основные классы угроз для органов власти

Ниже перечислены наиболее распространенные угрозы для администрации и подведомственных организаций (школы, МФЦ, учреждения культуры, ЖКХ и т. п.).

Социальная инженерия и фишинг

Фишинг — один из самых частых входов в инфраструктуру, потому что атаковать человека обычно проще, чем хорошо защищенную систему.

Типовые сценарии:

письмо «от руководства» с просьбой срочно оплатить/подписать/открыть документ

поддельная страница входа в почту или портал

звонок в службу поддержки с попыткой получить пароль или код

Почему опасно для органов власти:

компрометация почты может дать доступ к переписке, документам, дальнейшим атакам

через учетные записи сотрудников злоумышленники часто переходят к подведомственным системам

Вымогательское ПО (ransomware)

Ransomware обычно шифрует данные или блокирует работу, а затем требует выкуп. Часто применяется двойное давление:

шифрование, чтобы остановить работу

кража данных с угрозой публикации

Для администрации это критично из-за зависимости от непрерывности услуг и большого объема чувствительных данных.

Компрометация цепочки поставок (supply chain)

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

Примеры точек риска:

подрядчик с широкими правами на администрирование

централизованные системы обновления

интеграции через API без достаточного контроля

DDoS и нарушения доступности

DDoS-атаки перегружают сервис и делают его недоступным.

Для органов власти последствия обычно публичны:

недоступность порталов и записи

срыв сроков подачи заявлений

рост нагрузки на call-центры и очные точки обслуживания

Утечки данных и ошибки конфигурации

Частые причины:

неверные права доступа к папкам/реестрам

публикация данных в открытых хранилищах

отправка документов не тому адресату

потеря устройств или носителей

Эксплуатация уязвимостей и устаревших систем

Проблема усугубляется тем, что:

обновления требуют согласований и простоя

есть специализированное ПО, которое «нельзя трогать»

системы могут быть связаны с критичными процессами

Инсайдерские угрозы и злоупотребление полномочиями

Инсайдер может:

копировать базы и документы

вносить изменения в реестры

создавать «закладки» (скрытые учетные записи, правила пересылки)

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

Дезинформация и атаки на доверие

Для органов власти важно защищать не только ИТ, но и коммуникационный контур:

захват официальных аккаунтов

подмена новостей и объявлений

рассылки от имени ведомства

Это напрямую влияет на общественное поведение и доверие.

Угрозы, последствия и типовые цели атакующих

| Угроза | Типовая цель атакующего | Что страдает в первую очередь | Пример последствий для органов власти | |---|---|---|---| | Фишинг | Получить учетные данные, закрепиться | Конфиденциальность, затем целостность | Компрометация почты, дальнейшее проникновение в системы | | Ransomware | Выкуп, давление через утечку | Доступность и конфиденциальность | Остановка сервисов, утечка баз, паралич документооборота | | Supply chain | Массовый доступ через подрядчика/ПО | Все компоненты триады | Одновременная компрометация нескольких ведомств/учреждений | | DDoS | Срыв работы, демонстрация силы | Доступность | Недоступность портала, рост очередей, репутационный ущерб | | Ошибки доступа/конфигурации | Непреднамеренный «открытый доступ» | Конфиденциальность | Публикация персональных данных, нарушения требований закона | | Инсайдер | Личная выгода/месть/злоупотребление | Целостность и конфиденциальность | Подмена данных в реестрах, несанкционированные выгрузки |

Что считать «успехом» кибербезопасности в администрации

Успех — это не отсутствие инцидентов (это нереалистично), а способность:

предотвращать наиболее вероятные и опасные атаки

обнаруживать инциденты быстро (не через месяцы)

сдерживать распространение внутри сети

восстанавливаться в разумные сроки

доказывать соблюдение требований и управляемость процессов

Эту логику отражают широко используемые подходы к построению киберзащиты, например NIST Cybersecurity Framework и практики управления информационной безопасностью (например, ISO/IEC 27001).

Почему органы власти должны действовать проактивно

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

восстановление после атак дороже профилактики

утечки персональных данных имеют длительные последствия

повторные атаки вероятны, если не устранены системные причины

доверие граждан восстанавливается медленно

Чтобы оставаться в актуальной картине угроз, полезно опираться на регулярные обзоры и рекомендации профильных организаций, например:

ENISA Threat Landscape

рекомендации по противодействию вымогательству от CISA (Stop Ransomware)

Карта поверхности атаки органа власти

Ниже — упрощенная схема того, откуда чаще всего начинается атака и куда она может развиваться.

!Упрощенная карта, показывающая основные точки входа атак и распространение внутри инфраструктуры

Как эта тема связана со следующими темами курса

Эта статья задает контекст: зачем кибербезопасность нужна органам власти и какие угрозы наиболее типичны.

Далее в курсе логично перейти к вопросам:

как выстроить управление кибербезопасностью (роли, ответственность, процессы)

как проводить оценку рисков и определять приоритеты защиты

какие минимальные меры (MFA, резервное копирование, сегментация, управление уязвимостями) дают наибольший эффект

как организовать реагирование на инциденты и взаимодействие с подрядчиками

Нормативные требования и политика защиты информации

Как эта тема связана с угрозами для органов власти

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

заранее определить что именно и на каком уровне должно быть защищено

распределить ответственность (чтобы безопасность не была «ничьей задачей»)

обеспечить доказуемость соблюдения требований при проверках и расследованиях

сократить хаос в действиях при инцидентах и в повседневной работе

Нормативка и политика не заменяют технические меры, но задают рамки: какие меры обязательны, кто их выполняет, как контролируется результат.

Что считается нормативными требованиями в кибербезопасности

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

Уровни требований по источнику

Законы и кодексы: базовые обязательные требования (например, к персональным данным, тайнам, ответственности).

Подзаконные акты и нормативные документы регуляторов: конкретизируют, как выполнять требования закона (часто описывают меры защиты, порядок контроля, требования к системам).

Отраслевые требования и ведомственные регламенты: требования к конкретным процессам (электронные услуги, межведомственный обмен, архивы, делопроизводство).

Договорные обязательства: условия контрактов с подрядчиками, SLA, требования к обработке данных.

Стандарты и фреймворки: чаще всего добровольные, но полезны как «каркас» (например, [ISO/IEC 27001] (https://www.iso.org/isoiec-27001-information-security.html), [NIST Cybersecurity Framework] (https://www.nist.gov/cyberframework)).

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

Типовые области регулирования для органов власти

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

Защита персональных данных

Персональные данные граждан и сотрудников — один из самых «тяжелых» по последствиям классов информации.

Организации обычно обязаны:

определить цели и основания обработки

ограничить доступ по принципу необходимости

обеспечивать безопасность хранения и передачи

управлять инцидентами и утечками

Для поиска и сверки актуальных редакций национальных законов и подзаконных актов используйте официальные источники публикации нормативных актов, например [Официальный интернет-портал правовой информации] (https://pravo.gov.ru/).

Если ваша практика связана с правом ЕС или взаимодействием с европейскими субъектами, полезно знать первоисточник: [GDPR (Регламент (ЕС) 2016/679)] (https://eur-lex.europa.eu/eli/reg/2016/679/oj).

Информация ограниченного доступа и служебная информация

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

Ключевые задачи здесь:

правила классификации и маркировки

контроль распространения и копирования

отдельные требования к хранению, передаче и уничтожению

Критически важные системы и непрерывность оказания услуг

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

Отсюда обычно следуют требования:

резервное копирование и восстановление

планирование отказоустойчивости

управление изменениями и обновлениями

мониторинг и реагирование

Если вы работаете в контуре ЕС, смежный ориентир по управлению киберрисками для существенных/важных субъектов: [Директива NIS2 (ЕС) 2022/2555] (https://eur-lex.europa.eu/eli/dir/2022/2555/oj).

Закупки и управление подрядчиками

Даже если требования к защите хорошо прописаны внутри, уязвимость часто возникает на стыке с подрядчиками (хостинг, сопровождение, разработка, МФУ, обслуживание рабочих мест).

Типовые обязательства:

закрепить требования безопасности в договоре

ограничить и контролировать доступ подрядчика

предусмотреть порядок уведомления об инцидентах

определить правила передачи/возврата данных и носителей

Как определить применимость требований

Частая ошибка — «писать политики по максимуму» без понимания, что реально применимо. Правильнее действовать от области применения.

Вопросы, которые нужно прояснить в начале

Какие данные обрабатываются (персональные, служебные, иные ограниченные, общедоступные).

Какие системы задействованы (порталы, реестры, АРМ, облака, мобильные устройства).

Кто участвует (сотрудники, подведомственные организации, подрядчики, другие ведомства).

Где границы ответственности (что администрируется вами, что — поставщиком).

Какие последствия критичны (недоступность услуг, подмена данных, утечка).

Результатом должен быть короткий документ или реестр: какая система, какие данные, какие требования, какие ответственные.

Политика защиты информации: что это и зачем она нужна

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

Политика отвечает на вопросы:

что защищаем и почему это важно

кто за что отвечает

какие минимальные меры обязательны

как контролируем выполнение и что делаем при нарушениях

Важно: политика — это не один документ «на 50 страниц», а система документов разного уровня.

!Иерархия внутренних документов: от общей политики к конкретным инструкциям

Минимальный состав политики и обязательных регламентов

Ниже — практичный «минимальный комплект» для большинства органов власти. Его можно расширять, но важно, чтобы каждый документ реально работал.

Базовые документы верхнего уровня

Политика защиты информации: цели, принципы, область применения, роли, ответственность, общий контроль.

Политика управления рисками: как оцениваются риски и как выбираются меры.

Политика классификации информации: уровни чувствительности и правила обращения.

Ключевые процедуры

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

Управление доступом.

Управление учетными записями и привилегиями.

Управление изменениями и обновлениями.

Резервное копирование и восстановление.

Реагирование на инциденты.

Управление уязвимостями.

Управление подрядчиками и внешними сервисами.

Обучение и осведомленность персонала.

Технические стандарты (как «обязательные правила настройки»)

требования к MFA для критичных систем

минимальные требования к паролям и сессиям

правила логирования и хранения журналов

базовая сегментация сети и удаленный доступ

шифрование при передаче и хранении (где применимо)

Роли и ответственность: кто должен что делать

Чтобы политика не была декларацией, роли должны быть назначены документально.

Типовые роли

Руководитель органа/учреждения: утверждает политику, принимает риск, обеспечивает ресурсы.

Ответственный за информационную безопасность (CISO/ИБ-координатор): владелец процесса ИБ, контроль внедрения мер, методология, отчетность.

ИТ-подразделение: внедрение технических мер, эксплуатация, журналирование, резервное копирование.

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

Юристы и комплаенс: трактовка требований, договорные условия, проверка правовых оснований обработки данных.

Кадровая служба: доступы при приеме/увольнении, обучение, дисциплинарные меры.

Закупки/контрактная служба: требования безопасности в ТЗ и договорах, контроль обязательств подрядчиков.

> Если «у безопасности нет владельца», то при инциденте неизбежно появляется разрыв: все участники считают, что отвечал кто-то другой.

Классификация информации и модель обращения с данными

Классификация позволяет связывать тип данных с конкретными мерами защиты, не усложняя правила для всего подряд.

Пример практичной схемы уровней

Это пример, который адаптируется под ваши регламенты.

Публичная информация: можно публиковать без ограничений.

Внутренняя: для сотрудников, без публикации наружу.

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

Конфиденциальная: персональные данные и другие чувствительные категории, усиленные меры.

Что обязательно определить в политике классификации

критерии отнесения информации к уровню

правила маркировки документов и файлов

допустимые каналы передачи для каждого уровня

сроки хранения и правила уничтожения

ответственность за нарушение правил

Принцип «доказуемости»: как показать, что требования выполняются

В государственном секторе важен не только факт защиты, но и возможность подтвердить его.

Что обычно считается доказательствами

утвержденные политики и регламенты (с датами и версиями)

приказы о назначении ответственных

реестр систем и данных (область применения)

журналы изменений, обновлений, выдачи прав

отчеты о резервном копировании и тестовом восстановлении

протоколы обучения и информирования сотрудников

отчеты по инцидентам и корректирующим мерам

Как избежать «бумажной безопасности»

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

Показатели должны быть измеряемыми (например, доля систем с MFA, время отключения учетной записи уволенного сотрудника).

Контроль должен быть регулярным (внутренние проверки, выборочные аудиты).

Как стандарты помогают выстроить систему (даже если они не обязательны)

Стандарты полезны как «шаблон здравого смысла», особенно если нормативные акты задают цель, но не дают структуры.

[ISO/IEC 27001] (https://www.iso.org/isoiec-27001-information-security.html): система управления информационной безопасностью (политики, роли, непрерывное улучшение).

[NIST Cybersecurity Framework] (https://www.nist.gov/cyberframework): удобная модель для построения программы защиты по функциям Identify, Protect, Detect, Respond, Recover.

Смысл использования фреймворка в администрации:

легче связать меры с рисками и угрозами

проще объяснять руководству и проверяющим логику программы

легче планировать развитие (дорожная карта)

Практический алгоритм внедрения требований и политики

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

Определить область применения: реестр систем, данных, подрядчиков, интеграций.

Собрать «карту требований»: какие обязательные нормы действуют для каждой категории данных и систем.

Оценить разрывы: что уже выполняется, а что нет (процессно и технически).

Утвердить базовую политику и роли: назначить ответственных, закрепить полномочия.

Внедрить минимальные обязательные меры:

- MFA для критичных доступов - резервное копирование с тестовым восстановлением - учет и контроль администраторских прав - журналирование ключевых событий

Настроить работу с подрядчиками: договорные требования, доступы, уведомления об инцидентах.

Встроить контроль: внутренние проверки, метрики, пересмотр политики при изменениях.

Связь со следующими темами курса

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

Далее логично перейти к практическим вопросам:

как проводить оценку рисков и приоритизировать меры

какие технические базовые меры дают наибольший эффект в администрации

как организовать реагирование на инциденты и взаимодействие с внешними участниками

как выстроить контроль подрядчиков и управление цепочками поставок

Архитектура безопасности: сети, идентичности, данные и облака

Зачем администрации говорить об архитектуре безопасности

В предыдущих темах мы:

определили типовые угрозы для органов власти (фишинг, вымогатели, DDoS, утечки, инсайдеры)

разобрали, как нормативные требования и внутренняя политика превращают эти угрозы в управляемые обязательства (роли, регламенты, доказуемость)

Архитектура безопасности — это следующий шаг: перевод требований и приоритетов в согласованный набор технических и организационных решений, который:

уменьшает вероятность инцидента и ограничивает его масштаб

делает защиту управляемой (понятно, что где защищаем и почему так)

упрощает проверки и расследования (видно, где должны быть журналы, кто владелец, как устроены доступы)

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

Принципы, на которых строится современная архитектура

Защита по слоям

Один контроль почти никогда не спасает. Работает сочетание:

сетевых барьеров и сегментации

строгого управления доступом

защиты данных (шифрование, классификация, DLP)

мониторинга и реагирования

Минимально необходимый доступ

Пользователи и системы получают только те права, которые нужны для работы.

Ключевые механизмы:

least privilege (минимальные привилегии)

разделение обязанностей (чтобы один человек не мог сделать всё в одиночку)

контроль привилегированных учетных записей (PAM)

Модель Zero Trust как удобная «оптика»

Zero Trust — это подход, в котором:

не доверяют сетевому периметру «по умолчанию»

проверяют идентичность, устройство, контекст и политику доступа при каждом запросе

считают, что компрометация возможна, и заранее ограничивают распространение

Полезные первоисточники:

NIST SP 800-207 Zero Trust Architecture

CISA Zero Trust Maturity Model

Опорные элементы архитектуры: сети, идентичности, данные, облака

Чтобы архитектура была целостной, удобно мыслить четырьмя «опорами»:

сеть и периметр (как ходит трафик и где он контролируется)

идентичности и доступ (кто и как получает права)

данные (что именно защищаем и какими мерами)

облака и внешние сервисы (где границы ответственности)

!Обзорная карта: как четыре опоры совместно защищают ключевые государственные сервисы

Сети: сегментация, удаленный доступ и контроль трафика

Что важно для органов власти

В типовом органе власти есть несколько классов сетевых зон:

пользовательская зона (рабочие места, Wi‑Fi)

серверная зона (реестры, файловые ресурсы, приложения)

зона администрирования (доступ администраторов, средства управления)

DMZ/публикация сервисов (порталы, шлюзы)

отдельные сегменты подведомственных организаций и подрядчиков

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

Сегментация сети и контроль межсегментного обмена

Базовый принцип:

сегментируем по функциям и критичности

разрешаем только необходимое взаимодействие между сегментами

фиксируем правила и владельцев потоков (какой сервис кому и зачем нужен)

Практические меры:

VLAN/VRF и межсетевые экраны между сегментами

отдельный сегмент для административного доступа

запрет прямого доступа с пользовательских ПК к критичным базам

микросегментация для наиболее критичных систем, где это возможно

Удаленный доступ: VPN уже недостаточно как единственная мера

Удаленная работа, выезды, подрядчики — типичная реальность.

Что важно обеспечить:

сильная аутентификация (MFA)

ограничение по устройствам (только управляемые, соответствующие требованиям)

минимизация «плоского доступа» во внутреннюю сеть

Варианты:

VPN с MFA и строгими маршрутами/ACL (минимальный вариант)

ZTNA (доступ на уровне приложений, а не всей сети), где это реализуемо

DNS/WEB/почтовые шлюзы как «массовая» защита от фишинга

Так как фишинг — один из главных входов, архитектурно важно иметь уровни фильтрации:

фильтрация вложений и ссылок в почте

DNS-фильтрация вредоносных доменов

web-прокси/защита от загрузки вредоносного ПО

Что фиксировать в документах (доказуемость)

Чтобы сеть была управляемой, обычно нужны:

актуальная схема сегментов и точек выхода в интернет

перечень межсегментных правил (кто владелец, зачем, срок пересмотра)

регламент удаленного доступа (для сотрудников и подрядчиков)

Идентичности: IAM, MFA, роли и привилегии

Почему идентичность — новый «периметр»

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

Поэтому архитектурно ключевое — управление идентичностями (IAM): кто, как и на каких условиях получает доступ.

Жизненный цикл учетной записи (Joiner–Mover–Leaver)

Это процесс, который должен быть формализован вместе с кадровыми и ИТ-процедурами:

прием: создание учетной записи по заявке, назначение ролей

перевод: изменение ролей и прав, отзыв лишних доступов

увольнение: быстрое отключение и отзыв токенов/сеансов

Риск администрации — задержки в отключении доступов и «вечные» учетные записи подрядчиков.

MFA как обязательный минимум для критичных доступов

MFA особенно важно включать для:

почты и средств совместной работы

удаленного доступа

админ-доступа

доступа к реестрам и системам с персональными данными

Архитектурная идея: даже если пароль украли, атака должна упереться во второй фактор.

RBAC и ABAC: как задавать права

Чтобы не управлять доступами вручную «по людям», применяют модели:

RBAC (role-based): права привязаны к ролям (например, «оператор МФЦ», «специалист соцвыплат»)

ABAC (attribute-based): доступ зависит от атрибутов и контекста (роль, подразделение, тип устройства, время, уровень классификации данных)

Для большинства органов власти RBAC — базовый и наиболее реализуемый подход. ABAC полезен там, где нужен контекст (например, доступ к данным только с управляемых устройств и только из защищенной сети).

PAM: защита привилегированных учетных записей

Привилегированные учетные записи (администраторы домена, администраторы баз, облачных консольных доступов) — «цель №1».

PAM обычно включает:

отдельные админ-учетки (не совпадают с повседневными)

выдачу доступа «по запросу» и на ограниченное время

запись и аудит действий (где возможно)

хранение секретов в защищенном хранилище

Сквозная идентификация и SSO

Чтобы снизить хаос учетных записей и улучшить контроль:

вводят единый каталог (где применимо)

подключают сервисы через SSO

централизуют требования (MFA, политика паролей, ограничения по устройствам)

Данные: классификация, шифрование, DLP и резервное копирование

Начинаем с классификации данных и потоков

Из прошлой темы о политике защиты информации следует: без классификации невозможно назначить «адекватные» меры.

Архитектурно важно ответить:

где хранятся данные разных уровней (файловые ресурсы, базы, облачные диски)

как они передаются (почта, межведомственные шлюзы, API)

где образуются копии (выгрузки, отчеты, кэши, резервные копии)

Шифрование: при передаче и при хранении

Шифрование — не универсальная защита от всего, но мощный базовый контроль:

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

в хранении: снижает ущерб при краже носителя/снимка диска/доступа к хранилищу

Ключевой архитектурный вопрос — управление ключами:

где хранятся ключи

кто имеет к ним доступ

как осуществляется ротация

что происходит при компрометации

DLP и контроль каналов утечек

DLP (data loss prevention) помогает снижать риск утечек через:

почту

мессенджеры и web

съемные носители

облачные хранилища

Но DLP работает только при наличии классификации и четких правил: что считать «конфиденциальным» и какие действия запрещены.

Резервное копирование как элемент архитектуры устойчивости

Вымогатели делают резервное копирование критически важным.

Архитектурные признаки «живого» бэкапа:

есть резервные копии, изолированные от основной доменной среды (по возможности)

есть неизменяемые копии (immutability) или эквивалентные меры

регулярно проводится тестовое восстановление

определены целевые показатели восстановления (в терминах времени и допустимой потери данных)

> Бэкап без тестового восстановления — это гипотеза, а не гарантия.

Журналирование доступа к данным

Если данные ценны, должна быть возможность ответить на вопросы:

кто обращался к данным

когда и откуда

какие операции выполнял

Это важно и для расследований, и для доказуемости соблюдения требований.

Облака и внешние сервисы: границы ответственности и контроль конфигураций

Модель разделения ответственности

В облаках и у подрядчиков безопасность почти всегда делится:

поставщик отвечает за безопасность облачной платформы/инфраструктуры

заказчик отвечает за конфигурации, доступы, данные и правильное использование сервиса

Эта логика подробно описана в отраслевых материалах, например:

Cloud Security Alliance Guidance

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

Конфигурационные риски — главный источник инцидентов в облаке

Типовые причины проблем:

публичный доступ к хранилищам

ключи и токены в коде/репозиториях

чрезмерные права сервисных учетных записей

отсутствие журналирования и оповещений

Архитектурные меры:

централизованное управление учетными записями и MFA

политика «запрещено по умолчанию» для публичного доступа

непрерывная проверка конфигураций (класс решений CSPM)

обязательное включение логов доступа и действий в консоли

Контрактные требования к облакам и подрядчикам

Из нормативной темы следует: требования должны быть закреплены договором.

Что особенно важно прописывать:

состав данных и уровни их чувствительности

место обработки и хранения (если применимо в вашем регулировании)

требования к журналам и срокам их хранения

порядок уведомления об инцидентах и сроки

порядок удаления данных и возврата носителей/копий

ограничения на привлечение субподрядчиков

Как «собрать» архитектуру в работающую программу

Ниже — практичная последовательность, которая хорошо сочетается с подходами NIST и ISO.

Ориентиры:

NIST Cybersecurity Framework

ISO/IEC 27001

CIS Critical Security Controls v8

Шаги внедрения

Описать критичные сервисы и данные (реестры, выплаты, документооборот, МФЦ, порталы) и привязать владельцев.

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

Выделить зоны и сегменты, определить допустимые связи.

Централизовать идентичности:

- MFA для критичных доступов - RBAC для типовых ролей - PAM для привилегий

Укрепить контур данных:

- классификация - шифрование где уместно - резервное копирование с тестовым восстановлением - журналирование доступа

Для облаков:

- согласовать shared responsibility - стандартизировать конфигурации и контроль - закрепить требования в договорах

Подключить мониторинг и реагирование:

- сбор логов с ключевых узлов - корреляция событий - отработка сценариев (фишинг, утечка, ransomware)

Типовые компромиссы и ошибки в госсекторе

Ошибка «периметр всё решит»

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

Ошибка «права выдадим, потом разберемся»

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

Ошибка «облако = автоматически безопасно»

Без контроля конфигураций и доступов облако часто повышает риск утечки.

Ошибка «бэкапы есть» без восстановления

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

Связь с последующими темами курса

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

Далее в курсе логично углубляться в:

оценку рисков и приоритизацию мер (что делать первым при ограниченных ресурсах)

базовые технические меры «с наибольшим эффектом» (MFA, сегментация, EDR, управление уязвимостями)

мониторинг, реагирование и взаимодействие с внешними участниками (подрядчики, регуляторы, CERT)

Управление рисками, уязвимостями и поставщиками

Как эта тема связана с предыдущими

В предыдущих статьях курса мы:

определили типовые угрозы для органов власти (фишинг, ransomware, DDoS, утечки, инсайдеры)

разобрали, как нормативные требования и внутренняя политика превращают угрозы в обязательства (роли, регламенты, доказуемость)

рассмотрели архитектуру безопасности: сети, идентичности, данные и облака

Эта тема отвечает на практический вопрос: как регулярно принимать решения, что защищать в первую очередь, если ресурсов всегда меньше, чем задач.

Для этого в администрации нужны три связанные дисциплины:

управление рисками: выбрать приоритеты и обосновать их руководству

управление уязвимостями: системно снижать вероятность атак, а не «латать по новости»

управление поставщиками: контролировать риски на границе с подрядчиками, облаками и разработчиками

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

!Обзорная связь трех процессов, чтобы они работали как единая система

Управление рисками в органах власти

Что такое риск и чем он отличается от «проблемы»

Риск в кибербезопасности — это возможность того, что конкретная угроза нанесет конкретный ущерб конкретному активу.

Чтобы риск был управляемым, он должен быть описан без абстракций:

актив (например, реестр льгот, система электронного документооборота, портал записи)

сценарий (например, компрометация учетной записи сотрудника через фишинг)

последствие (недоступность услуги, утечка персональных данных, подмена записей)

текущие меры (MFA включена только для части пользователей)

владелец риска (руководитель процесса или системы, который может принять решение)

В качестве ориентиров по методологии риск-оценки часто используют материалы NIST, например NIST SP 800-30 Rev.1.

Зачем администрации формальный процесс управления рисками

Процесс нужен, чтобы:

приоритизировать бюджет и проекты (что сделать в этом квартале, что можно отложить)

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

обосновывать требования к подрядчикам (почему в контракте нужен аудит, логи, сроки уведомления)

управлять исключениями (почему «устаревшую систему нельзя обновить» и чем компенсируем)

Роли в управлении рисками

Типовая схема ответственности:

владелец риска: руководитель сервиса/процесса, принимает решения (снижать, принимать, переносить)

ИБ-координатор/служба ИБ: методология, фасилитация оценки, консолидация реестра

ИТ: фактическое внедрение мер, сроки исправлений, учет активов

юристы/комплаенс: требования по данным и уведомлениям, договорные формулировки

закупки: включение требований в ТЗ и контроль выполнения условий контракта

Реестр рисков как основной артефакт

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

Минимально полезные поля реестра:

идентификатор риска

система/процесс (владелец)

описание сценария

затронутые данные (уровень чувствительности)

последствия для конфиденциальности, целостности, доступности

текущие меры

оценка приоритета (по выбранной шкале)

план обработки риска (меры, сроки, ответственные)

статус и дата пересмотра

Как оценивать приоритет без «математики ради математики»

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

Практичная модель:

вероятность: низкая / средняя / высокая

ущерб: низкий / средний / высокий

приоритет: определяется матрицей (например, всё с высоким ущербом и средней вероятностью уже является высоким приоритетом)

Чтобы шкала была не «вкусовщиной», заранее закрепляют критерии ущерба, например:

сколько граждан затронуто

допустимое время простоя услуги

есть ли персональные данные или служебная информация ограниченного распространения

возможна ли подмена данных в реестре

насколько публичным будет инцидент

Варианты обработки риска

Классические варианты решений:

снизить риск: внедрить меры (MFA, сегментация, резервное копирование, мониторинг)

избежать риска: отказаться от небезопасного решения или функции

перенести риск: часть ответственности и затрат переложить на третью сторону (например, через контракт и страхование), но не ожидать, что ответственность исчезнет полностью

принять риск: оставить как есть, но только с формальным решением владельца и планом пересмотра

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

Управление уязвимостями

Уязвимость, конфигурационная ошибка и «известная эксплуатируемая уязвимость»

Чтобы не путать термины:

уязвимость: техническая слабость в ПО или системе, которую можно использовать для атаки

конфигурационная ошибка: небезопасная настройка (например, публичный доступ к хранилищу, избыточные права)

известная эксплуатируемая уязвимость: уязвимость, по которой есть подтвержденные случаи эксплуатации «вживую»

В повседневной практике управление уязвимостями включает и уязвимости, и конфигурации.

Полезные ориентиры:

каталог активно эксплуатируемых уязвимостей CISA Known Exploited Vulnerabilities Catalog

планирование патч-менеджмента NIST SP 800-40 Rev.4

Почему «сканер уязвимостей» не равен управлению уязвимостями

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

понятный периметр охвата (какие активы в программе, какие исключены и почему)

приоритизацию по реальному риску, а не по количеству находок

исправление в согласованные сроки

проверку исправления

отчетность для руководства и владельцев систем

Базовый жизненный цикл управления уязвимостями

Ниже — практичный цикл, который применим и в небольшом муниципалитете, и в крупном ведомстве.

Учет активов

Обнаружение

Приоритизация

Исправление или компенсация

Проверка и закрытие

Отчетность и улучшение процесса

!Наглядная схема, чтобы отличать процесс от разовых сканов

Инвентаризация: без нее приоритизация невозможна

Инвентаризация — это ответы на вопросы:

какие серверы, рабочие станции, сетевые устройства, облачные ресурсы существуют

какие из них критичны для услуг и данных

кто владелец системы

что доступно из интернета

Если полного учета нет, разумный минимум:

начать с критичных сервисов и «публичного периметра»

отдельно вести список систем с персональными данными

Приоритизация: что исправлять первым

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

На практике первыми идут находки, которые одновременно:

затрагивают критичный сервис или систему с персональными данными

эксплуатируются в реальности (например, находятся в KEV-каталоге)

доступны из интернета или из пользовательского сегмента без дополнительных барьеров

дают повышение привилегий или удаленное выполнение кода

Также важно учитывать реальность эксплуатации:

есть ли рабочий эксплойт

есть ли компенсирующие меры (сегментация, изоляция, отсутствие маршрута)

можно ли быстро исправить без остановки услуги

Исправление: патч, настройка или компенсирующие меры

Варианты реакции на уязвимость:

патч/обновление: предпочтительно, если возможно без непропорционального ущерба доступности

изменение конфигурации: закрытие портов, отключение небезопасных протоколов, ужесточение прав

компенсирующие меры, если обновить нельзя

- изоляция в отдельный сегмент - ограничение сетевых потоков - запрет доступа из пользовательской зоны - усиленный мониторинг и журналирование

Компенсирующие меры должны быть документированы как часть обработки риска, иначе это превращается в «временное навсегда».

Сроки исправления и исключения

Чтобы процесс работал, вводят целевые сроки исправления (часто их называют SLA — согласованный уровень сервиса, то есть срок выполнения).

Важно не копировать сроки «как в банке», а привязать к критичности, например:

критичные уязвимости на интернет-периметре: очень короткий срок

высокие уязвимости во внутренних системах: короткий срок

средние: планово

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

кто согласует (владелец системы и владелец риска)

какие компенсирующие меры обязательны

на какой срок выдается исключение

дата пересмотра

Метрики, которые показывают управляемость

Примеры метрик, понятных руководству:

доля критичных активов, покрытых регулярным сканированием

доля уязвимостей из KEV, устраненных в целевой срок

среднее время исправления для критичных находок

количество исключений с просроченной датой пересмотра

Управление поставщиками и подрядчиками (Third Party Risk Management)

Почему поставщики — отдельный источник риска

Даже при хорошей внутренней защите администрация часто уязвима через внешних участников:

сопровождение информационных систем (удаленный админ-доступ подрядчика)

разработка и обновления (риск внедрения уязвимостей)

хостинг и облака (ошибки конфигурации, утечки)

сервисы рассылок, колл-центры, интеграции через API

Управление поставщиками — это не «недоверие», а контроль границ ответственности и минимизация масштаба инцидентов.

В качестве методологического ориентира по управлению рисками цепочки поставок часто используют NIST SP 800-161 Rev.1.

Модель жизненного цикла поставщика

Процесс удобно строить как жизненный цикл.

Отбор и оценка до договора

Требования в контракте

Онбординг и выдача доступов

Операционный контроль

Инциденты и изменения

Завершение работ и отзыв доступов

!Наглядно показывает, что контроль начинается до подписания и не заканчивается актом

Классификация поставщиков по критичности

Чтобы не проверять одинаково всех, вводят категории, например:

критичные: имеют доступ к персональным данным, реестрам, администрированию или обеспечивают доступность ключевых услуг

значимые: обрабатывают внутренние данные или поддерживают важные процессы

некритичные: не имеют доступа к чувствительным данным и инфраструктуре

Категория определяет глубину проверки и жесткость условий.

Что важно закрепить в договоре

Минимальный набор требований, который обычно оправдан для критичных поставщиков:

область данных: какие данные обрабатываются и на каких основаниях

границы ответственности: кто за что отвечает в безопасности (особенно в облаках)

управление доступом: MFA, именные учетные записи, запрет общих логинов

журналирование: какие логи ведутся и сколько хранятся, доступ администрации к логам

уведомление об инцидентах: срок первичного уведомления и формат взаимодействия

управление уязвимостями: сроки установки критичных обновлений, порядок экстренных исправлений

субподрядчики: запрет или контроль привлечения третьих лиц

удаление/возврат данных: порядок, сроки, подтверждающие акты

право на проверку: аудит, предоставление подтверждений выполнения требований

Чтобы связать контракт с практикой, требования должны быть проверяемыми: не «обеспечивает высокий уровень безопасности», а «MFA обязательно для всех учетных записей с доступом к системе».

Доступ подрядчика: как не превратить его в «черный ход»

Типовые меры, которые резко снижают риск:

доступ только через контролируемый канал (VPN с MFA или ZTNA, где применимо)

минимальные маршруты и правила (подрядчик видит только то, что нужно)

отдельные учетные записи подрядчика, запрет общих аккаунтов

учет заявок на работы и окно изменений

журналирование действий и регулярный пересмотр активных доступов

Поставщик как часть ваших рисков и уязвимостей

Важно связать процессы:

риски по поставщикам должны попадать в реестр рисков

уязвимости на стороне поставщика, влияющие на ваши системы, должны иметь владельца и сроки

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

Хорошим «каркасом» для привязки практик к контролям могут быть CIS Critical Security Controls v8, в том числе контроли по управлению уязвимостями и поставщиками.

Как объединить риски, уязвимости и поставщиков в один управляемый контур

Логика связки

Рабочая связка выглядит так:

уязвимости и события мониторинга дают факты о слабых местах

управление поставщиками дает понимание внешних зависимостей и «где у вас чужие руки в системе»

управление рисками превращает эти факты в решения: что исправлять первым, что финансировать, что принимать

Минимальный план внедрения на 60–90 дней

Ниже — реалистичный стартовый план для администрации с ограниченными ресурсами.

Собрать короткий реестр критичных сервисов и данных

Назначить владельцев систем и владельцев рисков

Запустить базовую программу уязвимостей

Сделать инвентаризацию внешних поставщиков и доступов

Обновить типовой шаблон договора для критичных поставщиков

Создать первую версию реестра рисков и вынести 5–10 решений на руководство

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

Связь с дальнейшими темами курса

Эта тема создает управленческий фундамент для следующих практик:

приоритизация базовых технических мер (MFA, сегментация, резервное копирование, EDR)

построение мониторинга и реагирования на инциденты

организация взаимодействия с внешними участниками (подрядчики, CERT, регуляторы)

Инциденты, реагирование и киберустойчивость госуслуг

Как эта тема связана с предыдущими

В предыдущих статьях мы последовательно выстроили основу:

поняли, какие угрозы наиболее типичны для органов власти (фишинг, ransomware, DDoS, утечки, инсайдеры)

разобрали, как нормативные требования и внутренняя политика превращают безопасность в управляемые обязанности

рассмотрели архитектурные меры (сети, идентичности, данные, облака)

научились приоритизировать работу через риски, уязвимости и контроль поставщиков

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

Ключевые понятия темы:

киберинцидент и его классификация

реагирование на инциденты как процесс (люди, процедуры, инструменты)

киберустойчивость госуслуг: способность продолжать оказывать услуги и быстро восстанавливаться

В качестве базовой «рамки» для процессов реагирования удобно опираться на руководство NIST SP 800-61 Rev.2 Computer Security Incident Handling Guide.

Что считается инцидентом в администрации

Чтобы не путать термины и не перегружать систему ложными тревогами, полезно различать:

событие безопасности: любое наблюдаемое отклонение (например, 20 неудачных входов в почту)

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

утечка данных: частный случай инцидента, связанный с несанкционированным раскрытием информации

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

Цели реагирования на инциденты

Реагирование нужно не для того, чтобы «найти виноватых», а чтобы достигать измеримых результатов:

быстро выявлять инцидент и подтверждать факт компрометации

ограничивать распространение внутри инфраструктуры

восстанавливать госуслуги в приемлемые сроки

сохранять доказательства для разбирательств и проверок

устранять первопричины, чтобы инцидент не повторился

В логике NIST Cybersecurity Framework реагирование напрямую связано с функциями Detect, Respond, Recover, а подготовка и устойчивость зависят от Identify и Protect.

Организация реагирования: роли, полномочия, взаимодействие

Почему «план реагирования» важнее набора разрозненных действий

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

параллельные несогласованные действия разных подразделений

запоздалое отключение доступов и несанкционированные изменения «в панике»

потеря логов и цифровых доказательств

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

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

Типовые роли в реагировании

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

руководитель реагирования (Incident Manager): координация, приоритизация, решение о переключении в режим аварийного управления

служба ИБ / ИБ-координатор: анализ, рекомендации по сдерживанию, коммуникация по безопасности

ИТ-эксплуатация: изоляция узлов, изменения конфигураций, восстановление, резервное копирование

владельцы сервисов: решение о допустимом простое, переключении на резервные сценарии, приоритеты восстановления

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

пресс-служба / коммуникации: публичные сообщения, работа с гражданами и СМИ, предотвращение дезинформации

закупки / контрактная служба: включение поставщика в реагирование, запрос логов и выполнения договорных обязательств

подрядчики и облачные провайдеры: действия в своей зоне ответственности и предоставление артефактов

Взаимодействие с внешними структурами

Орган власти должен заранее определить:

как и когда привлекаются национальные или отраслевые команды реагирования (CERT/CSIRT), если применимо

кто контактирует с правоохранительными органами

кто и в какие сроки уведомляет регуляторов (особенно по персональным данным)

Для европейского контура важно учитывать требования уведомления при утечках персональных данных в рамках GDPR.

Жизненный цикл реагирования

Практически применимая модель (по NIST SP 800-61 Rev.2 Computer Security Incident Handling Guide) включает четыре блока:

Подготовка

Обнаружение и анализ

Сдерживание, устранение, восстановление

Действия после инцидента

!Схема показывает, что реагирование — это цикл, а пост-инцидентные выводы возвращаются в подготовку

Подготовка: что должно быть сделано до атаки

Подготовка обычно решает половину исхода инцидента. Минимально полезный набор:

актуальный реестр критичных сервисов и владельцев

контакты и порядок эскалации (24/7, если критично)

централизованное журналирование ключевых систем и доступов

резервное копирование с регулярным тестовым восстановлением

сценарные плейбуки для наиболее вероятных атак

заранее определенный порядок работы с подрядчиками при инциденте

Обнаружение и анализ: триаж и подтверждение

Задача этого этапа — быстро ответить на вопросы:

что именно произошло (фишинг, вредонос, утечка, DDoS, компрометация подрядчика)

каков масштаб (какие системы, учетные записи, сегменты, данные)

продолжается ли атака сейчас

что критичнее всего для граждан и услуг

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

Полезный инструмент для унификации анализа техник атак — база MITRE ATT&CK, которая помогает связывать наблюдаемые действия злоумышленника с типовыми тактиками.

Сдерживание, устранение, восстановление

Этот блок опасен «необратимыми» ошибками, поэтому важно разделять цели:

сдерживание: остановить распространение и уменьшить ущерб

устранение: убрать причину присутствия атакующего (вредонос, бэкдор, украденные токены)

восстановление: вернуть работоспособность сервисов и доверие к данным

Критично: восстановление должно учитывать целостность. Быстро «включить сервис» недостаточно, если данные могли быть подменены.

Действия после инцидента

После инцидента должны появиться артефакты управляемости:

отчет по инциденту и таймлайн

список пострадавших активов и учетных записей

выводы о первопричинах

план корректирующих мер со сроками и ответственными

обновления политик, плейбуков, архитектуры и требований к поставщикам

Классификация инцидентов и уровни критичности

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

Пример практичной шкалы:

| Уровень | Признаки | Типовые действия | |---|---|---| | Низкий | Локальное событие без подтвержденной компрометации | Триаж, сбор фактов, усиление мониторинга | | Средний | Компрометация учетной записи или одного узла без признаков распространения | Смена паролей/токенов, изоляция узла, проверка журналов | | Высокий | Затронуты критичные сервисы, персональные данные или есть lateral movement | Эскалация руководству, массовая ревизия доступов, расширенная изоляция сегментов | | Критический | Массовый сбой госуслуг, ransomware, подмена данных в реестрах, масштабная утечка | Аварийный режим, отключения по сети, переключение на резервные сценарии, кризисные коммуникации |

Важно закрепить критерии заранее: например, «сколько граждан затронуто» и «какова допустимая длительность простоя».

Плейбуки: как действовать в типовых сценариях

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

Компрометация почты через фишинг

Зафиксировать признаки компрометации (правила пересылки, входы из необычных локаций, рассылка от имени пользователя).

Немедленно сбросить сессии и токены пользователя, сменить пароль, включить или усилить MFA.

Проверить почтовый ящик на правила пересылки, делегирования, скрытые фильтры.

Оценить, к каким системам мог быть доступ из почты (сброс паролей, ссылки на порталы, документы с доступами).

Провести точечный поиск по аналогичным письмам и индикаторам у других пользователей.

Зафиксировать артефакты: заголовки писем, URL, вложения, журналы входа.

Ransomware в инфраструктуре учреждения

Изолировать пораженные узлы от сети (вплоть до отключения портов) и остановить распространение.

Отключить или ограничить межсегментный обмен из пользовательской зоны, если есть признаки lateral movement.

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

Убедиться, что резервные копии недоступны для атакующего (изоляция, неизменяемость, отдельные учетные записи).

Провести оценку: было ли только шифрование или также эксфильтрация данных.

Восстановление проводить по приоритету критичных услуг и только после проверки «чистоты» восстановляемого контура.

После восстановления обеспечить усиленный мониторинг и закрытие первичного вектора (фишинг, уязвимость, RDP, подрядчик).

Практические рекомендации по противодействию вымогателям и восстановлению собраны в материалах CISA Stop Ransomware.

DDoS на портал госуслуг или сайт администрации

Подтвердить, что проблема именно в перегрузке, а не во внутреннем отказе.

Переключиться на заранее согласованный сценарий с провайдером связи или анти-DDoS сервисом.

Ограничить нефункциональный трафик (rate limiting, временные правила на периметре) с учетом риска блокировки легитимных пользователей.

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

Зафиксировать таймлайн и параметры атаки для последующего улучшения защиты и претензионной работы.

Инцидент у подрядчика или облачного провайдера

Запросить первичное уведомление по согласованному каналу и в согласованном формате.

Уточнить, какие ваши данные и сервисы затронуты, и какие меры сдерживания применены.

Проверить ваши учетные записи и токены, связанные с поставщиком (ротация секретов, отзыв ключей).

Запросить логи и подтверждения выполнения мер, предусмотренных контрактом.

При необходимости запустить собственные процедуры уведомления и кризисной коммуникации.

Зафиксировать выводы в реестре рисков и пересмотреть требования к поставщикам.

Коммуникации и доказуемость

Внутренние коммуникации

Внутри организации должно быть заранее определено:

кто принимает решения об отключениях и переключении на резервные режимы

кто утверждает внешние сообщения

кто ведет единый таймлайн и журнал решений

Внешние коммуникации с гражданами и СМИ

Смысл коммуникаций во время инцидента:

снизить неопределенность и предотвратить слухи

дать гражданам понятные альтернативные действия

не раскрывать технические детали, которые помогут атакующему

Доказуемость и цифровые следы

Из предыдущих тем про политику и процессы следует принцип доказуемости. Для реагирования это означает:

фиксировать ключевые решения (кто и когда санкционировал действия)

сохранять логи и артефакты (с учетом защиты персональных данных)

обеспечивать контролируемую работу с доказательствами, чтобы не «сломать» расследование и проверку

Киберустойчивость госуслуг: как не остановиться даже при атаке

Что такое киберустойчивость

Киберустойчивость — способность органа власти:

продолжать оказывать критичные услуги при нарушениях

ограничивать ущерб от атак

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

сохранять доверие к данным и решениям

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

Непрерывность и восстановление: минимальные управленческие артефакты

Для критичных сервисов должны быть определены:

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

допустимые простои и приоритеты восстановления

резервные сценарии (включая частично ручные или упрощенные)

В качестве ориентира по планированию непрерывности и восстановлению для ИТ часто используют NIST SP 800-34 Rev.1 Contingency Planning Guide.

Если организация строит систему управления непрерывностью на уровне всей деятельности, полезен стандарт ISO 22301:2019 Security and resilience — Business continuity management systems.

Резервное копирование как элемент киберустойчивости

Чтобы бэкап реально работал в условиях ransomware, обычно нужны:

изоляция резервных копий от основной доменной среды (по возможности)

защита от удаления и модификации (неизменяемые копии или эквивалент)

регулярное тестовое восстановление

четкий приоритет восстановления: что поднимается первым для восстановления госуслуг

Устойчивость идентичностей и администрирования

Во многих атаках «ломается» не только сервис, но и контур управления:

доменная инфраструктура

учетные записи администраторов

доступы в облачные консоли

Поэтому для устойчивости важны:

отдельные привилегированные учетные записи и контроль привилегий (PAM)

возможность аварийного доступа по строго регламентированной процедуре

защищенное хранение секретов и ротация ключей

Архитектурные меры устойчивости

Меры зависят от масштаба, но логика едина:

сегментация сети, чтобы заражение рабочего места не «перепрыгивало» в реестры

минимизация «плоского» удаленного доступа подрядчиков

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

защита внешних сервисов от DDoS совместно с провайдерами

Учения и улучшение: как сделать реагирование реальным

Планы и плейбуки без тренировки часто не исполняются.

Практически полезные форматы:

tabletop-учения: разбор сценария за столом (фишинг, утечка, ransomware)

технические отработки: восстановление из бэкапа, изоляция сегмента, отзыв доступов подрядчика

проверки уведомлений и коммуникаций: кто и как публикует сообщения, как информируются МФЦ и колл-центры

Метрики, которые показывают управляемость

Метрики нужны не ради отчетности, а чтобы управлять улучшениями. Примеры:

время обнаружения (MTTD) и время восстановления (MTTR)

доля критичных систем, с которых централизованно собираются логи

доля критичных учетных записей с MFA

частота тестового восстановления и процент успешных восстановлений

количество инцидентов, где первопричина устранена и подтверждена

Минимальный план внедрения реагирования и устойчивости на 60–90 дней

Утвердить владельца процесса реагирования и схему эскалации.

Составить список критичных госуслуг, систем и владельцев.

Определить минимальную шкалу критичности инцидентов и критерии.

Подготовить 3–4 плейбука: фишинг, ransomware, DDoS, инцидент у подрядчика.

Проверить резервное копирование: изоляция и тестовое восстановление.

Обязать MFA для почты, удаленного доступа и администрирования.

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

Провести tabletop-учение и по итогам обновить документы и технические настройки.

Связь с дальнейшим развитием курса

Тема инцидентов и киберустойчивости объединяет все предыдущие темы в «проверку реальностью»:

угрозы и уязвимости проявляются как инциденты

нормативные требования требуют доказуемых действий и отчетности

архитектура определяет, насколько быстро вы сдержите атаку

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

Дальнейшее углубление обычно идет в сторону:

построения мониторинга и обнаружения (логи, корреляция событий, SOC-функции)

зрелого управления доступом и привилегиями

расширенной практики устойчивости: сценарии деградации услуг, резервные контуры, регулярные учения