ПД№1: школа персональных данных № 1

Будущее ИБ в надежных руках 🛡💻 Вчера входил в жюри БАУМАНТЕХ и оценивал проекты второй смены по информационной безопасности для ребят из БАУМАНТЕХ.ДЕТИ. Удивительно, как за короткий интенсив подростки успевают примерить на себя роль настоящих специалистов по кибербезу. Буквально за одну неделю каждая команда разработала свой ИБ-продукт. Горжусь, что могу участвовать в таком проекте и видеть, как растет крутая смена. Вперед, в мир большого кибербеза! 🚀 #БауманТех

🛠 Запускаю бесплатный практикум по аудиту ИСПДн Качество аудита ИСПДн решается не на этапе отчета, а на этапе сбора информации (обследования). Если обследование проведено бессистемно, это неизбежно проявится в отчете: неполное покрытие компонентов, слепые зоны в рисках и выводы, построенные на ощущениях, а не на фактах. Поэтому я сделал универсальный опросник для аудита ИС (goGRC), который использую в каждом своем проекте: от первичного обследования ИСПДн по приказу ФСТЭК № 21 до подготовки к сертификации по PCI DSS или ISO 27001. На практикуме разберем опросник и его 56 вкладок: управление аудитом, компоненты ИС, ИТ и ИБ-процессы вокруг информационной системы, справочные материалы. 🎯 Результат: каждый участник разработает собственный опросник и научится работать с ним на реальных задачах. Детали: 🔹 Участие: бесплатное, по отбору, 20 мест 🔹 Формат: онлайн, 8 встреч по 1,5 часа (4 недели), в Яндекс.Телемост 🔹 График: понедельник и среда, 19:00 (Мск) 🔹 Старт: 3 августа Кому подойдет: аудиторам ИБ, комплаенс менеджерам, DPO, специалистам по защите ПДн, руководителям ИБ – всем, кому нужен системный инструмент обследования. Как попасть: напишите мне в ЛС – почему хотите участвовать, кем и где работаете. Дальше короткий созвон-интервью, решение по каждому принимаю индивидуально. Практикум рассчитан на внутренних специалистов, не на консультантов. #ВебинарПДн1 #ПрактикумПДн1 #АудитыИБ

продолжение... 2. С другой стороны, если что-то не проверишь, сразу как-будто бы попадаешь под нарушение. 1. Закон не требует «проверить все» - ни 152-ФЗ, ни ISO 27001. Меры защиты выбираются по рискам: если риск низкий и это задокументировано - отсутствие глубокой проверки не нарушение. 2. Регулятор смотрит на систему, а не на идеал. Достаточно базового набора мер и документированного процесса управления (реестры, карта рисков, PDCA). Единичные пропуски без реального ущерба - это замечания, а не основания для штрафов. 3. Аудит - инструмент улучшения, а не экзамен. Невыявленная находка - не провал, а повод актуализировать чек-лист в следующем цикле. Ваша цель доказать осознанное управление рисками, а не 100% покрытие всех ИСПДн/процессов обработки. Как только это поймете, сразу жить станет легче. И на вопрос руководства “почему эта система еще не проверена”, вы ответите - “в соответствии с графиком ее аудит запланирован на 4 квартал 2026” или что-то вроде того. 3. И если контроль осуществлять, например, комиссионно (с участием ответственного за защиту, собственной безопасности, делопроизводителя, например) - у кого-нибудь была подобная практика? Или весь контроль осуществляется исключительно ДПО? Коллективная ответственность - форма безответственности, по этому: 1. Комиссия = размытая ответственность. Когда проверяют «все вместе», каждый надеется на коллег - в итоге глубокого анализа не получается. За результат должен отвечать один человек: если вы DPO - вы и ведете аудит, чтобы контролировать фокус и качество. 2. Не нужно знать все самому. Ваша задача как ведущего - выявлять несоответствия, а не быть техническим экспертом во всем. Где не хватает компетенции - точечно привлекаете сисадмина, разработчика или безопасника под конкретный вопрос. 3. Это быстрее и практичнее. Индивидуальный аудит не требует долгих согласований и кворумов. Провели за 2-3 дня -> сразу план улучшений -> следующий цикл PDCA. Меньше бюрократии - больше реальной пользы для СМИБ. #МнениеDPO

Евгения, добрый день! 1. Поделитесь, пожалуйста, практикой разработки положения о внутреннем контроле и (или) аудите соответствия обработки персональных данных Федеральному закону № 152-ФЗ. Может, кто-то уже решил для себя, как будет корректней. Проанализировала имеющиеся в открытом доступе примеры положений о контроле, и в отдельных содержится примерный перечень вопросов, подлежащих контролю. Во-первых, положения (регламенты, политики) - лишь отражение действующих процессов - вслепую примерять чужие документы нельзя неэффективно. Судя по вашему письму, те варианты положения, которые вы нашли, вас не устроили по каким-то причинам. Возможно, они идут вразрез с практикой в вашей организации или попросту не могут быть реализованы (нецелесообразны) в таком виде. Вам нужно придумать свой процесс и описать его в положении (кто какие процедуры выполняет, в какие сроки, как ведется учет результатов аудита, как и кто устраняет недостатки и др.). После каждого аудита процесс будет совершенствоваться (цикл PDCA), а положение - дорабатываться. На первых порах чек-листа с базовыми действиями и проверочными мероприятиями будет более чем достаточно (и не обязательно этот документ называть “положением”). Во-вторых, одни и те же процессы в организациях разного масштаба будут разными. И это нормально. Например: Крупная компания: В компании внутренний аудит обработки ПДн проводится по утвержденному графику силами выделенной команды внутреннего контроля или DPO с использованием автоматизированных инструментов картирования данных и проверки контролов. Результаты фиксируются в GRC-платформе, а план корректирующих действий отслеживается до закрытия с регулярной отчетностью перед комитетом по комплаенсу. Средний бизнес: В компании аудит соответствия обработки ПДн координируется назначенным ответственным за комплаенс или DPO, который использует чек-листы и автоматизированные скрипты для выборочной проверки настроек доступа и логирования. Результаты обсуждаются на ежеквартальных встречах с владельцами процессов, а приоритетные доработки вносятся в бэклог ИТ-команды. Малый бизнес: В компании аудит обработки ПДн проводится прагматично: основатель или техлид раз в полгода проходит по чек-листу ключевых систем, проверяет настройки доступа, шифрование и журналы, а результаты фиксируются в общей таблице задач. Выявленные несоответствия сразу закрываются через изменения в конфигурациях или обновление инструкций для команды. Выбирайте что вам ближе, и не гонитесь за “идеальным” комплаенсом. “Незрелый” компаленс вреден для бизнеса также как “перезрелый” (излишне бюрократизированный). #МнениеDPO

ПД№1: школа персональных данных № 1 pinned «‼️ Резервный (да кого я обманываю, скорее всего - основной) канал в MAX: https://max.ru/join/mV0Lat0-2dolbbgRO7PFROurmtHyrXzJOHkabB0hWfk Пока буду постить в оба канала, а там посмотрим.»

‼️ Резервный (да кого я обманываю, скорее всего - основной) канал в MAX: https://max.ru/join/mV0Lat0-2dolbbgRO7PFROurmtHyrXzJOHkabB0hWfk Пока буду постить в оба канала, а там посмотрим.

📝 Обзор изменений ПП № 171 (Разработка и производство СЗИ): Было vs Стало Для разработчиков средств защиты конфиденциальной информации (СЗИ) изменения вносятся в ПП № 171. Здесь регулятор сделал упор на количество программистов в штате и обязательные процессы безопасной разработки. 👥 1. Кадровый состав (Общий штат: руководитель + инженеры) Требования к штату теперь зависят от того, создаете ли вы «железо» или программное обеспечение: Разработка технических средств (аппаратные решения): Было: 3 человека (1 руководитель + 2 инженера) Стало: 6 человек (1 руководитель + 5 инженеров) Разработка программных (ПО) и программно-технических средств: Было: 3 человека (1 руководитель + 2 инженера) Стало: 11 человек (1 руководитель + 10 инженеров) 🚫 2. Ограничения по гражданству Вводится полный запрет на иностранное влияние в управлении: Было: Не допускались только иностранные юридические лица. Стало: Запрещено работать иностранным юрлицам, компаниям с иностранными руководителями и иностранным ИП. 🛡 3. Безопасная разработка (ГОСТ) Это самое концептуальное изменение для софтверных компаний. Было: Достаточно общей системы контроля качества разработки. Стало: Обязательное внедрение процессов безопасной разработки ПО в соответствии с новым национальным стандартом ГОСТ Р 5639-2024 . При подаче на лицензию нужно будет представить копию руководства по безопасной разработке. 💻 4. Импортозамещение и анализ кода Было: Требование наличия программных средств контроля исходных текстов (без уточнения происхождения). Стало: Использование оборудования и ПО преимущественно отечественного производства, расположенного в РФ. В состав средств контроля обязательно должны входить инструменты анализа исходных кодов программного обеспечения. 🔍 5. Проверки Как и в случае с ТЗКИ, ФСТЭК теперь может проводить не только документарную, но и выездную оценку соискателя. Итог: Лицензия разработчика теперь требует полноценной команды программистов (10+ человек) и перестройки всех внутренних процессов под стандарты безопасного кода.

📝 Обзор изменений ПП № 79 (ТЗКИ): Было vs Стало Опубликован проект изменений в ПП № 79 о лицензировании технической защиты. Основной акцент — на радикальном увеличении штата. 👥 1. Кадровый состав (Общий штат: руководитель + инженеры) Главное изменение — отказ от единого требования в «3 человека» для всех. Теперь штат зависит от сложности работ: Проектирование, монтаж и ремонт (пп. а, б, д, е): Было: 3 человека (1 руководитель + 2 инженера). Стало: 6 человек (1 руководитель + 5 инженеров). Аттестация и контроль защищенности (пп. г): Было: 3 человека (1 руководитель + 2 инженера). Стало: 10 человек (1 руководитель + 9 инженеров). Мониторинг ИБ / SOC (пп. в): Было: 3 человека (1 руководитель + 2 инженера). Стало: 16 человек (1 руководитель + 15 инженеров). 🚫 2. Ограничения по гражданству Регулятор закрывает лазейки для «иностранного элемента» в управлении: Было: Запрет только для иностранных юридических лиц. Стало: Дополнительно запрещено работать индивидуальным предпринимателям с иностранным гражданством, а также компаниям, чьи руководители являются иностранными гражданами. 💻 3. Оборудование и импортозамещение Вводится жесткий курс на технологический суверенитет: Было: Требовалось наличие оборудования и ПО на любом законном основании. Стало: Оборудование и ПО должны быть преимущественно отечественного производства, располагаться строго на территории РФ, а право на софт должно включать право использования. 🔍 4. Оценка соответствия (Проверки) ФСТЭК переходит к более глубокому контролю при лицензировании: Было: Оценка соответствия проводилась только в форме документарной проверки. Стало: Оценка может проводиться как в документарной, так и в выездной форме. Форму и порядок теперь определяет сам лицензирующий орган. Итог: Лицензия на ТЗКИ (особенно в части мониторинга и аттестации) становится «дорогим удовольствием», доступным только для крупных игроков с реальным штатом и отечественным стеком технологий.

Channel photo updated

Postmortem: Попадание секретного токена в централизованные логи 1. Краткое резюме В ходе проверки журналов событий (логов) было обнаружено, что секретный токен доступа к системе автоматизации (Jenkins) был передан небезопасным способом и, как следствие, оказался в централизованной системе логирования. Инцидент не привел к подтвержденному взлому, однако: ⇢ токен считается скомпрометированным; ⇢ был выявлен системный риск, который может повторяться; ⇢ потребовалась координация между ИБ и системными администраторами. Основной итог: проблема признана, зафиксированы единые правила работы с секретами, определены корректирующие меры. 2. Что произошло 1. Один из автоматических скриптов выполнял запрос к системе CI/CD Jenkins. 2. Для авторизации использовался секретный токен. 3. Этот токен был: ⇢ передан непосредственно в командной строке (как часть команды); ⇢ зафиксирован системой аудита процессов; ⇢ отправлен в централизованное хранилище логов (Grafana). 4. В результате токен оказался доступен более широкому кругу лиц, чем предполагалось изначально. 3. Почему это проблема Хотя доступ к логам формально ограничен, ситуация опасна по следующим причинам: ⇢ централизованные логи не предназначены для хранения секретов; ⇢ любой секрет в логах живет дольше, чем сам инцидент, и может быть случайно скопирован, сохранен, переиспользован; ⇢ расширяется зона риска: больше людей, больше систем, больше потенциальных точек компрометации. Важно: Инцидент не про «кто-то с полным доступом (root) и так все видит», а про снижение вероятности утечки при частичном, временном или ошибочном доступе. 4. Первопричина Основная причина: секретный токен был передан в аргументах команды, что гарантированно оставляет следы в системах мониторинга и аудита. Сопутствующие факторы: ⇢ отсутствие единых, явно зафиксированных правил обращения с секретами; ⇢ разное понимание модели угроз между ИБ и системными администраторами; ⇢ неочевидность того, что именно является «утечкой», а что — «ожидаемым поведением системы». 5. Что не является причиной Важно зафиксировать, что НЕ является причиной инцидента: ⇢ система аудита; ⇢ система логирования; ⇢ наличие администраторских доступов; ⇢ действия конкретных сотрудников (умысла не было). Эти системы работали ровно так, как задумано. 6. Обнаружение и реагирование Инцидент выявлен специалистами ИБ при анализе логов. Было проведено расследование, в рамках которого: ⇢ определен скрипт; ⇢ найден владелец; ⇢ подтвержден способ передачи токена. По текущему логу: ⇢ «починить прошлое» невозможно; ⇢ токен признан скомпрометированным. 7. Принятые решения 7.1 Оперативные меры ⇢ Токен считается утекшим ⇢ требуется ротация токена (выпуск нового). ⇢ Владелец скрипта подтвердил готовность внести изменения. 7.2 Системные меры (ключевой результат) Зафиксированы единые правила работы с секретами. Запрещено: ⇢ передавать секреты в командной строке, в URL, в выводе программ (stdout / stderr); ⇢ логировать заголовки авторизации, токены, пароли и API-ключи. Разрешено и рекомендовано: ⇢ хранить секреты в специализированных хранилищах (Vault и аналоги) либо в файлах с жесткими правами доступа; ⇢ в командах передавать путь к файлу секрета либо идентификатор секрета, а не сам секрет. 8. Итоговый статус 1. Инцидент закрыт. 2. Риск признан реальным, но управляемым. 3. Команды пришли к общему пониманию, что абсолютной безопасности не существует, но каждая мера снижает риск — и это имеет смысл. 9. Уроки 1. «Root все видит» — не оправдание для небезопасных практик. 2. Централизованные логи усиливают последствия ошибок. 3. Даже технически корректное решение может быть рискованным с точки зрения безопасности. 4. Четко зафиксированные правила снижают конфликты и время расследований. См. также Секрет | токен | командная строка | логи / журнал событий | CI/CD | централизованное логирование | аудит процессов | root-доступ | ротация токена | blast radius | lateral movement | privilege escalation | Vault / secret storage Больше разборов инцидентов по тегу #Postmortem

Channel photo updated

✅ УКФ.4 – Документирование информации (данных) об изменениях в конфигурации информационной системы и системы защиты персональных данных (Приказ ФСТЭК № 21) Требование обязывает фиксировать все изменения конфигурации ИС и СЗПДн, обеспечивая полноту и прослеживаемость действий, влияющих на безопасность персональных данных. 🗂 Примечания по применимости Требование распространяется на: ⇢ изменения конфигураций серверов, сетевого оборудования, виртуальной инфраструктуры; ⇢ изменения настроек СрЗИ; ⇢ корректировки политик доступа, логирования, сегментации; ⇢ внедрение нового ПО, обновлений и модулей. Не распространяется на: ⇢ косметические изменения, не влияющие на безопасность (например, UI-настройки). 🎯 Цель ⇢ Обеспечить возможность восстановления истории изменений для расследований и аудита. ⇢ Исключить несанкционированные или незаметные изменения конфигурации. ⇢ Повысить управляемость и прозрачность процессов эксплуатации. 🧰 Лучшие практики ⇢ Ведение журнала изменений (Change Log) в рамках процесса Change Management; ⇢ Фиксация: даты, автора, описания изменения, согласований и результатов внедрения; ⇢ Автоматизация записи изменений через системы управления конфигурациями (Ansible, GPO); ⇢ Хранение записей в защищенном репозитории (PAM/CMDB/SIEM); ⇢ Привязка изменений к инцидентам, заявкам и задачам. 🏷 Примеры ⇢ Пример 1: Изменение правил межсетевого экрана фиксируется в системе управления изменениями: кто внес, когда, что изменил, кем согласовано. ⇢ Пример 2: Настройки сервера документируются автоматически в CMDB после каждого развертывания Ansible-скрипта. 🧩 Индивидуальный подход Допускается варьировать: ⇢ глубину документирования (минимальная/расширенная); ⇢ уровень автоматизации; ⇢ формат хранения записей (электронный журнал, система заявок, CMDB). Главное — изменения должны быть полными, однозначными и прослеживаемыми. 🔎 Дополнительная информация ⇢ Документирование облегчает расследование инцидентов и подтверждение соответствия требованиям ИБ. ⇢ Полезно сочетать журнал изменений с baseline-конфигурациями. 🔬 Способы тестирования ⇢ Проверка журналов изменений, записей RFC и CMDB; ⇢ Сравнение фактических конфигураций с документированными; ⇢ Проверка целостности хранилища изменений; ⇢ Интервью с администраторами и специалистами ИБ. 📖 Термины Конфигурация ИС | изменения конфигурации ИС | СЗПДн | Change Management | RFC (Request for Change) | Change Log | Ansible | GPO | PAM | CMDB | SIEM | соответствие требованиям ИБ Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3 ☰ Все | 🏠 Главная

✅ УКФ.3 – Анализ потенциального воздействия планируемых изменений в конфигурации информационной системы и системы защиты персональных данных на обеспечение защиты персональных данных и согласование изменений в конфигурации информационной системы с должностным лицом (работником), ответственным за обеспечение безопасности персональных данных (Приказ ФСТЭК № 21) Требование устанавливает необходимость оценивать риски, которые могут возникнуть из-за планируемых изменений конфигурации, и согласовывать такие изменения с назначенным лицом, ответственным за обеспечение безопасности ПДн. 🧭 Примечания по применимости Требование распространяется на: ⇢ изменения конфигураций серверов, сетевого оборудования, виртуальной инфраструктуры; ⇢ изменения настроек СрЗИ; ⇢ корректировки политик доступа, логирования, сегментации; ⇢ внедрение нового ПО, обновлений и модулей. Не распространяется на: ⇢ косметические изменения, не влияющие на безопасность (например, UI-настройки). 🎯 Цель ⇢ Предотвратить внесение изменений, способных ослабить защиту ПДн. ⇢ Обеспечить участие специалиста по ИБ в процессе изменений. ⇢ Снизить риски инцидентов, вызванных небезопасными конфигурациями. 🧰 Лучшие практики ⇢ Проведение формализованного анализа рисков перед изменением (impact assessment); ⇢ Согласование изменений с ответственным за безопасность ПДн и ИБ-службой; ⇢ Тестирование изменений в тестовой среде; ⇢ Оценка влияния изменений на доступы, журналы, сегментацию, шифрование; ⇢ Документирование результатов анализа и решений по внедрению. 🏷 Примеры ⇢ Пример 1: Перед изменением политики межсетевого экрана проводится оценка риска влияния на защищенность ПДн, решение согласуется ответственным за ИБ. ⇢ Пример 2: Внедрение нового модуля CRM проходит анализ на предмет возможного доступа к ПДн и согласовывается с ответственным за СЗПДн. 🧩 Индивидуальный подход Организация может адаптировать: ⇢ глубину оценки влияния изменений; ⇢ перечень обязательных согласующих лиц; ⇢ формат анализа (анкета, чек-лист, экспертная оценка). Главное — никакие изменения, влияющие на безопасность ПДн, не должны вноситься без согласования. 🔎 Дополнительная информация ⇢ Изменения конфигурации — одна из ключевых причин инцидентов, связанных с нарушением безопасности ПДн. ⇢ Согласование помогает избежать незамеченных рисков и ошибок конфигурирования. 🔬 Способы тестирования ⇢ Проверка регламентов оценки и согласования изменений; ⇢ Анализ журналов Change Management; ⇢ Проверка наличия согласований в документации по RFC; ⇢ Интервью с ответственным за безопасность ПДн и администраторами. 📖 Термины Конфигурация ИС | СЗПДн | Change Management | RFC (Request for Change) | impact assessment | СрЗИ | изменения конфигурации ИС | ответственный за обеспечение безопасности ПДн | служба ИБ I UI Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3 ☰ Все | 🏠 Главная

✅ УКФ.2 – Управление изменениями конфигурации информационной системы и системы защиты персональных данных (Приказ ФСТЭК № 21) Требование обязывает организовать контролируемый процесс изменения конфигураций ИС и систем защиты ПДн, чтобы исключить хаотичные, несанкционированные или рискованные изменения, влияющие на безопасность и устойчивость системы. 🔧 Примечания по применимости Требование распространяется на: ⇢ серверы, рабочие станции, сетевое оборудование, СрЗИ; ⇢ виртуальную инфраструктуру и облачные сервисы; ⇢ системные и прикладные настройки, политики доступа. Не распространяется на: ⇢ изменения, не влияющие на безопасность или работу ИС (например, пользовательские настройки интерфейса). 🎯 Цель ⇢ Исключить неконтролируемые изменения конфигурации. ⇢ Обеспечить предсказуемость, стабильность и безопасность работы ИС. ⇢ Снизить риски инцидентов, связанных с ошибками конфигурации. 🧰 Лучшие практики ⇢ Введение формализованной процедуры Change Management; ⇢ Разделение сред: Dev ⇢ Stage ⇢ Prod; ⇢ Тестирование изменений перед внедрением; ⇢ Обязательное документирование и логирование всех изменений; ⇢ Применение системы контроля конфигураций (GPO, Ansible). 🏷 Примеры ⇢ Пример 1: Перед изменением правил на межсетевом экране создается RFC (Request for Change), проводится проверка ИБ и тестирование в тестовой среде. ⇢ Пример 2: Изменение параметров сервера фиксируется в журнале изменений; доступ к инструментам изменений — только у уполномоченных лиц. 🧩 Индивидуальный подход Организация может адаптировать: ⇢ глубину проверки изменений (по уровню риска); ⇢ порядок согласований (ИБ, эксплуатация, руководитель); ⇢ степень автоматизации внесения и контроля изменений. Главное — все изменения должны быть управляемыми и прослеживаемыми. 🔎 Дополнительная информация ⇢ Неправильная конфигурация — одна из самых частых причин утечек и инцидентов. ⇢ Использование DevOps/DevSecOps практик может повысить качество и скорость внедрения изменений. 🔬 Способы тестирования ⇢ Проверка регламентов управления изменениями; ⇢ Анализ журналов изменений (журналы CI/CD, системы управления конфигурациями); ⇢ Сверка фактической конфигурации с baseline; ⇢ Интервью с администраторами и ИБ. 📖 Термины Управление изменениями / Change Management | RFC (Request for Change) | СЗПДн | политика доступа | Dev-среда | Stage-среда | Prod-среда | тестирование изменений | журналирование событий безопасности | система контроля конфигураций | Ansible | GPO | DevSecOps | CI/CD Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3 ☰ Все | 🏠 Главная

✅ УКФ.1 – Определение лиц, которым разрешены действия по внесению изменений в конфигурацию информационной системы и системы защиты персональных данных (Приказ ФСТЭК № 21) Требование предписывает формально определить круг лиц, имеющих право изменять конфигурации ИС и систем защиты ПДн, чтобы исключить несанкционированные и неконтролируемые изменения. 👤 Примечания по применимости Требование распространяется на: ⇢ администраторов систем, сетей, БД; ⇢ администраторов СрЗИ; ⇢ лиц, ответственных за эксплуатацию ИС и ее конфигураций. Не распространяется на: ⇢ пользователей, не выполняющих технические функции и не имеющих прав на изменение конфигурации. 🎯 Цель ⇢ Исключить внесение изменений в ИС посторонними лицами. ⇢ Обеспечить прозрачность, подотчетность и контроль всех изменений. ⇢ Снизить риски инцидентов из-за ошибок, саботажа или несанкционированных действий. 🧰 Лучшие практики ⇢ Формальное закрепление перечня ответственных лиц (приказ, регламент, матрица ролей); ⇢ Использование ролевой модели (RBAC) для администраторов; ⇢ Разделение администраторских функций между ролями (сети, БД, СрЗИ); ⇢ Двухфакторная аутентификация для привилегированных пользователей; ⇢ Журналирование всех изменений конфигураций. 🏷 Примеры ⇢ Пример 1: Перечень администраторов систем и СрЗИ утверждается приказом, доступ предоставляется только им. ⇢ Пример 2: Для изменений конфигурации межсетевого экрана требуется авторизация через привилегированный доступ и запись в журнал. 🧩 Индивидуальный подход Допускается варьировать: ⇢ детализацию ролей (администратор ОС / БД / виртуализации / СрЗИ); ⇢ процедуру предоставления и отзыва прав; ⇢ контроль доступа через специализированные PAM-системы. Главное — документировать и контролировать полномочия. 🔎 Дополнительная информация ⇢ Неопределенные полномочия — частая причина критичных инцидентов. ⇢ Лучший подход — совмещение RBAC + приказов + PAM. 🔬 Способы тестирования ⇢ Проверка приказов и регламентов назначения ответственных; ⇢ Анализ фактических прав администраторов (AD/LDAP, роли в системах); ⇢ Проверка журналов изменений; ⇢ Интервью с администраторами и ИБ. 📖 Термины Конфигурация ИС | система защиты ПДн / СЗПДн | несанкционированные изменения | привилегированный пользователь | непривилегированный пользователь | неотказуемость | матрица ролей | RBAC | системный администратор | MFA | БД | журналирование событий ИБ | PAM | AD| LDAP Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3 ☰ Все | 🏠 Главная

✅ ЗИС.20 – Защита беспроводных соединений, применяемых в информационной системе (Приказ ФСТЭК № 21) Требование обязывает обеспечивать защищенное использование беспроводных технологий в ИС, предотвращая перехват, подмену и несанкционированный доступ через Wi-Fi и другие радиоканалы. 📡 Примечания по применимости Требование распространяется на: ⇢ корпоративные Wi-Fi сети, беспроводные контроллеры, точки доступа; ⇢ мобильные устройства сотрудников; ⇢ беспроводные сегменты, задействованные в обработке ПДн или служебных данных. Не распространяется на: ⇢ участки сети, где беспроводной доступ отключен и документированно запрещен. 🎯 Цель ⇢ Предотвратить несанкционированное подключение к ИС через радиоканал. ⇢ Исключить перехват или подмену данных, передаваемых по беспроводным сетям. ⇢ Снизить риски атак типа rogue-AP, MITM и перехвата трафика. 🧰 Лучшие практики ⇢ Использование современных протоколов защиты (WPA3, WPA2-Enterprise + 802.1X); ⇢ Аутентификация пользователей через RADIUS/сертификаты; ⇢ Изоляция гостевых и корпоративных сетей; ⇢ Отключение WPS, устаревших шифров и открытых SSID; ⇢ Мониторинг и обнаружение rogue-AP и подозрительных устройств. 🏷 Примеры ⇢ Пример 1: Корпоративный Wi-Fi использует WPA2-Enterprise, аутентификация проводится через RADIUS, гости — в отдельном сегменте. ⇢ Пример 2: Система обнаружения Wi-Fi-угроз автоматически блокирует попытки подключения к несанкционированным точкам доступа. 🧩 Индивидуальный подход Допускается адаптация: ⇢ методов аутентификации (сертификаты, EAP-TLS, учетные записи AD); ⇢ уровней сегментации и изоляции; ⇢ требований к мобильным устройствам (MDM, шифрование). Главное — исключить доступ к ИС через незащищенные беспроводные каналы. 🔎 Дополнительная информация ⇢ Беспроводные сети — один из наиболее уязвимых векторов атак. ⇢ Необходимо регулярно проводить радиоаудит и проверку конфигураций. 🔬 Способы тестирования ⇢ Проверка настроек Wi-Fi точек доступа и контроллеров; ⇢ Сканирование на наличие rogue-AP; ⇢ Анализ журналов аутентификации и шифрования; ⇢ Интервью с администраторами и ИБ. 📖 Термины Беспроводные технологии | беспроводные сети | беспроводные контроллеры | точка доступа Wi-Fi | гостевая сеть | мобильные устройства | rogue-AP | MITM | перехвата трафика | WPA3 | 802.1X | RADIUS | SSID | мониторинг точек доступа Все требования Приказа ФСТЭК № 21 по тегам #ПриказФСТЭК21 и #УЗ_3 ☰ Все | 🏠 Главная