Отношения бизнеса и контролирующих органов в сфере ИБ

Чужие правила

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

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

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

Другое заблуждение — считать требования по безопасности проблемой тех, кто работает с государством. Персональные данные есть у любого бизнеса с клиентской базой. Интернет-магазин, стоматология, фитнес-клуб, сервис доставки — все они операторы ПДн по ФЗ-152. Закон не спрашивает про размер выручки.

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

Первые обязательства

Формально обязанности возникают рано. Таблица с именами и телефонами клиентов — уже персональные данные. ФЗ-152 требует понимать: что собираете, где храните, кто имеет доступ.

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

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

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

Больше данных больше — больше ответственности 

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

Здесь начинается градация. Уровни защищенности персональных данных — от УЗ-4 до УЗ-1. Четвертый — для общедоступной информации, базовые меры. Первый — для чувствительных категорий: здоровье, убеждения, биометрия. Чем серьезнее данные, тем строже требования.

Приказ ФСТЭК №21 раскладывает это по полочкам. Идентификация пользователей, управление доступом, регистрация событий, антивирусная защита, поиск уязвимостей. Для каждого уровня — свой набор мер. Чтобы реализовать все на собственных серверах, нужна полноценная функция безопасности внутри компании: люди, процессы, инструменты.

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

Когда ставки растут

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

Правила здесь другие. Для работы с государственными информационными системами — приказ ФСТЭК №17, обязательная аттестация. Если компания относится к критической информационной инфраструктуре по ФЗ-187 — энергетика, транспорт, связь, финансы, здравоохранение — требования еще жестче.

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

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

Продукт и система

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

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

Аттестация — проверка системы. Как сертифицированные компоненты собраны вместе, как настроены, кто администрирует, как устроена реакция на инциденты. Оценивается не отдельная деталь, а конструкция целиком.

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

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

Язык доказательств

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

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

Можно выстроить все самостоятельно: нанять людей, купить решения, пройти проверки, а затем поддерживать актуальность. На выходе получатся полный контроль и полная ответственность за каждый элемент. Использовать готовую аттестованную инфраструктуру — более быстрый путь. Часть требований уже закрыта, часть ответственности — на провайдере. Затраты предсказуемы, а запуск более быстрый.

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