Защита информации — это не антивирус и не файрвол
Когда мне говорят «мы внедрили защиту информации», я прошу показать две вещи: реестр данных и матрицу ответственности. В большинстве случаев их нет. Есть антивирус, файрвол и политика на 40 страниц в PDF, которую никто не открывал. Формально защита есть, фактически — нет: никто не знает, что именно защищается и кто отвечает за конкретный массив данных.
Защита информации — управленческая задача, а не набор железок. Техника лишь исполняет решения, принятые на уровне классификации данных и распределения ролей. Если этих решений нет, файрвол защищает «всё сразу», то есть ничего.
Базовые принципы: что именно защищают
Классическая триада CIA — конфиденциальность, целостность, доступность — до сих пор рабочая рамка, но её часто сводят к одной конфиденциальности. Это ошибка.
- Конфиденциальность — данные видит только тот, кому положено. Ключевой вопрос: как утечка скажется на людях и на бизнесе.
- Целостность — данные не изменены незаметно. Для финансовой отчётности и медицинских записей это важнее секретности.
- Доступность — данные доступны, когда нужны. Для АСУ ТП и систем жизнеобеспечения час простоя стоит дороже любой утечки.
Практический вывод: приоритеты у разных массивов разные. Если защищать всё одинаково строго, вы гарантированно защищаете плохо — и получаете саботаж пользователей.
Классификация данных: три оси, а не одна
Главная ошибка — делить всё на «секретно» и «не секретно». Рабочая классификация строится минимум по трём независимым осям: юридический статус, критичность для бизнеса и регуляторный режим. Один и тот же файл может быть одновременно персональными данными, коммерческой тайной и частью государственной информационной системы.
Ось 1. Юридический статус
- Персональные данные — по 152-ФЗ любые сведения, относящиеся к конкретному физлицу: ФИО, телефон, email, IP-адрес в связке с человеком, кадровые и платёжные данные.
- Специальные категории (ст. 10 152-ФЗ): здоровье, биометрия, национальность, религиозные убеждения, судимость. Обработка требует отдельных оснований и, как правило, письменного согласия.
- Государственная тайна — закон 5485-1: отдельный режим, отдельные допуски и помещения.
- Охраняемая законом тайна — банковская, налоговая, врачебная, адвокатская, тайна связи.
- Коммерческая тайна — 98-ФЗ. Режим возникает только после введения его приказом и ознакомления сотрудников под подпись; без этого надпись «конфиденциально» на документе никого ни к чему не обязывает.
Отдельная тема — обезличенные данные. Многие считают, что после удаления ФИО требования 152-ФЗ снимаются. На практике риск реидентификации никто не отменял, а регуляторика в этой части продолжает ужесточаться.
Ось 2. Критичность для бизнеса
Внутренняя шкала обычно на 3–4 уровня. Пример, который я вижу чаще всего и считаю рабочим:
- Публичные (Public) — маркетинговые материалы, прайсы, открытая документация. Утечка не критична.
- Внутренние (Internal) — регламенты, рабочая переписка, проектные заметки. Утечка неприятна, но не смертельна.
- Конфиденциальные (Confidential) — клиентские базы, договоры, финансовые прогнозы, исходный код. Утечка означает прямые потери и репутационный ущерб.
- Строго ограниченные (Restricted) — ключи, криптоматериалы, персональные данные спецкатегорий, чувствительная инфраструктурная информация. Доступ — только по явному разрешению.
Важно: уровень присваивает владелец данных, а не ИБ и не тот, кто громче всех кричит. Иначе получится классификация ради галочки.
Ось 3. Регуляторный режим
От принадлежности системы зависит, какие документы придётся выполнять:
- Персональные данные — приказ ФСТЭК №21, определение уровня защищённости (УЗ-1…УЗ-4) по категории данных и числу субъектов;
- Государственные информационные системы — приказ ФСТЭК №17 и класс защищённости К1…К4;
- Критическая информационная инфраструктура — 187-ФЗ и приказ ФСТЭК №239, включая категорирование объектов;
- АСУ ТП, медицинские и платёжные системы — отраслевые требования плюс PCI DSS, если работаете с картами.
Эти режимы комбинируются, поэтому на вопрос «какого класса у нас система» нельзя ответить одним словом. Корректный ответ выглядит так: ГИС класса К2, обрабатывает ПДн, УЗ-2, объект КИИ без категории.
Ссылки на регуляторов стоит проверять по первоисточникам — fstec.ru и consultant.ru, а не по статьям пятилетней давности.
Зоны ответственности: кто за что отвечает
Второй вопрос после «что защищаем» — «кто отвечает». Классическая модель предполагает четыре роли, и путать их нельзя.
- Владелец данных (Data Owner) — бизнес-руководитель, отвечающий за смысл и качество массива. Он решает, какой уровень конфиденциальности присвоить и кто получает доступ: бухгалтерия — для финансов, HR — для кадров, продажи — для клиентской базы.
- Стюард (Data Steward) — специалист, который ведёт каталог данных, следит за описаниями, метками и актуальностью. Часто это аналитик или ответственный за обработку ПДн.
- Администратор (Data Custodian) — тот, кто технически исполняет: настраивает права, шифрование, бэкапы, хранит ключи. Обычно это sysadmin или DevOps-инженер.
- Служба ИБ — устанавливает правила, контролирует их исполнение, расследует инциденты и проводит аудит. Она не владеет данными и не должна быть единственным барьером между злоумышленником и базой.
Самый частый провал, который я встречал: ИБ назначают одновременно владельцем, администратором и контролёром. Получается конфликт интересов — тот, кто придумал правило, сам его исполняет и сам себя проверяет. Второй по частоте — «данные принадлежат компании», то есть никому конкретно.
Полезно зафиксировать распределение в формате RACI по каждому массиву: кто делает (R), кто утверждает (A), кого консультируют (C), кого информируют (I). Документ на одну страницу экономит месяцы споров.
Как связать классификацию и ответственность: 7 шагов
- Составьте реестр данных: какие массивы есть, где лежат, как передаются. Без этого шага остальное бессмысленно.
- Определите режим каждого массива: 152-ФЗ, ГИС, КИИ, коммерческая тайна или ничего из перечисленного.
- Присвойте внутренний уровень критичности по шкале Public / Internal / Confidential / Restricted.
- Назначьте владельца на каждый массив персонально, а не «по подразделению».
- Опишите требования к каждому уровню: где можно хранить, кому передавать, нужно ли шифрование, сколько хранить.
- Проставьте метки физически: теги в СУБД и облаке, грифы на документах, класс в каталоге данных.
- Настройте проверку: аудит доступов, отчёты DLP, регулярный пересмотр прав (access review) раз в квартал.
Инструменты: где помогают, а где создают иллюзию
DLP (Data Leak Prevention) контролирует потоки данных и сигналит о выгрузках. Полезен ровно настолько, насколько размечены данные: без меток это генератор ложных срабатываний и отчётов для совещания. На российском рынке представлены InfoWatch Traffic Monitor, Solar Dozor, «Гарда» — выбор зависит от бюджета, зрелости процессов и требований импортозамещения.
Каталог данных решает самую скучную и самую важную задачу — где вообще лежат ваши данные. Обычно это выясняется во время инцидента, и это плохой момент для открытий.
Шифрование и KMS снижают ущерб при утечке носителя или бэкапа, но не спасают от ошибок конфигурации и от прав, выданных «на всякий случай». Отдельный вопрос — хранение ключей: если ключи лежат рядом с данными, они бесполезны.
Обезличивание и тестовые среды — многие утечки идут из dev-контуров, куда скопировали продовые данные. Замаскированные данные в тестовой среде решают проблему, но требуют процесса, а не разового скрипта.
Антипаттерны
- Политика ИБ утверждена, но не привязана к конкретным массивам и ролям.
- У всех данных один уровень защиты — максимальный, из-за чего пользователи ищут обходные пути.
- ИБ отвечает за всё: от политики до настройки бэкапов.
- Классификация есть на бумаге, меток в системах нет.
- Реестр данных лежит в Excel на ноутбуке одного сотрудника.
Чек-лист на первую неделю
- Выпишите 5 самых важных массивов данных и их владельцев — по именам.
- Проверьте, где эти данные физически находятся: прод, бэкапы, dev, ноутбуки, облако.
- Отметьте для каждого массива регуляторный режим (ПДн, ГИС, КИИ, коммерческая тайна).
- Сверьте, что доступ выдан по принципу минимально необходимого, и закройте старые права.
- Убедитесь, что ключи и секреты не хранятся рядом с защищаемыми данными и не лежат в git.
- Назначьте дату следующего пересмотра прав и внесите её в календарь — иначе не случится.
Вывод
Защита информации начинается не с покупки DLP, а с двух страниц текста: реестр данных и матрица ответственности. Классификация по трём осям — юридический статус, критичность, регуляторный режим — отвечает на вопрос «что защищаем». Роли владельца, стюарда, администратора и службы ИБ отвечают на вопрос «кто отвечает». Всё остальное — техника, которая без этих ответов превращается в дорогой реквизит для аудита.
