Привет, друзья! Меня зовут Роман Татаркин, руководитель проектов в Cloud.ru. До этого я четыре года работал solution manager в направлениях информационной безопасности и сетевой архитектуры. В этой роли я стоял в самой гуще: мне нужно было понять реальные потребности заказчиков, обосновать требования по безопасности, перевести их на язык технических деталей и сформулировать техническое задание на реализацию.
За эти годы я видел одну и ту же ситуацию сотни раз. Поэтому мне, как и каждому IT-специалисту, знакомо чувство легкого (или не очень) раздражения, когда приходит очередное требование от службы безопасности установить DLP, переписать политики доступа, внедрить EDR...
Я написал эту статью, потому что долгое время находился в центре конфликта: с одной стороны безопасники, которые требуют инструменты, необходимые по приказу, с другой — разработчики, которые слушают эти требования с недоверием, потому что не видят в них логику. Действительно, на первый взгляд кажется, что это лишь бюрократия, которая тормозит проекты. Но что, если за этими требованиями стоит не прихоть безопасников, а четкая логика?
Эта статья — попытка разложить по полочкам, как на самом деле уст��оен мир требований к информационной безопасности. Я последовательно пройду по ключевым сущностям: от регуляторов, которые диктуют правила, через объекты, которые они защищают, до инструментов, которые помогают эти правила выполнить. Понимание этой цепочки — первый шаг к тому, чтобы требования ИБ перестали быть иррациональными и стали осмысленной частью работы.
Начало конфликта: почему IT и ИБ не слышат друг друга
Знакомая ситуация: приходит письмо от безопасников с требованием внедрить какой-то инструмент. Почему это часто вызывает конфликт?
Если вы погружены в разработку, администрирование или DevOps, такие требования кажутся навязанными сверху. Для разработчика это лишняя нагрузка на инфраструктуру и сроки. Безопасник же видит, что его требования не воспринимают всерьез и ставят под угрозу защищенность компании.
В итоге проекты тормозятся, требования выполняются спустя рукава, а взаимное недовольство растет. Но корень проблемы обычно не в злом умысле, а в разрыве понимания. С одной стороны — приказы регуляторов, ГОСТы, внутренние политики. С другой — простой и законный вопрос: «А зачем мне это конкретно?». Попробую разобраться.
Кто на самом деле задает эти правила? Это же внутренняя политика компании...
Нет, за большинством серьезных требований стоят не внутренние регламенты, а внешние регуляторы. В России — это целая система организаций, каждая со своей зоной ответственности. Их требования могут не пересекаться, а иногда даже слегка противоречить друг другу.
Разберу основных игроков.
ФСТЭК России — главный по защите государственной информации. Если компания работает с госданными, управляет ГИС, относится к критической инфраструктуре (КИИ) или имеет опасные производства (АСУ ТП), она под ее надзором. Именно ФСТЭК выпускает известные приказы (№ 17, 21, 31 и др.), которые подробно расписывают, что и как защищать.
ФСБ России — контролирует все, что связано с шифрованием (криптографией) и защитой от кибершпионажа. Используете шифрование или передаете данные по открытым каналам? ФСБ будет интересоваться.
Роскомнадзор (РКН) — страж персональных данных (ПДн). Его ориентир — закон 152-ФЗ. Обрабатываете информацию о людях (даже просто IP-адреса)? Вы на его радаре.
Банк России — отдельная вселенная требовательности. Для банков, страховых, платежных систем и финтеха его стандарты, например положения 683-П и 716-П, — это обязательные для исполнения требования, которые зачастую строже, чем у других регуляторов.
Минцифры России координирует создание государственных информационных систем и имеет серьезные рычаги влияния на подконтрольные проекты.
Отраслевые регуляторы (ФСО, Минпромторг, Минэнерго) добавляют свои специфичные требования для энергетики, промышленности и других отраслей.
Вывод напрашивается сам собой: когда вам приносят требование, первым делом спросите — кто его «автор»? Если это ФСТЭК или ФСБ — это, скорее всего, обязательный пункт по закону. Если это внутренняя политика на основе лучших практик (best practices) — здесь уже есть пространство для обсуждения и поиска оптимального решения.
С регуляторами разобрались, следующий вопрос — что они защищают
Регуляторы не издают приказы ради приказов. Они защищают совершенно конкретные объекты: информацию, системы и процессы. Понимание этого момента превращает абстрактное «надо» в осмысленное «зачем».
Информация — это первое, что нужно защищать. Персональные данные (ПДн) — это все, что позволяет идентифицировать человека.
Государственная тайна — информация, утечка которой вредит безопасности страны.
Коммерческая тайна — ноу-хау и конкурентные преимущества компании.
Системы — инструменты, которые обрабатывают информацию.
Информационные системы персональных данных (ИСПДн) обрабатывают ПДн граждан под контролем Роскомнадзора.
Государственные и муниципальные информационные системы (ГИС/МИС) —государственные реестры, порталы, системы управления.
КИИ — системы критической информационной инфраструктуры: энергетика, ЖКХ, транспорт. Их сбой опасен для общества.
АСУ ТП — системы, управляющие промышленными и опасными производствами.
Процессы — то, как вы работаете с информацией и системами.
Мониторинг инцидентов — умение видеть, когда что-то пошло не так.
Безопасная эксплуатация — своевременное обновление, настройка, резервное копирование.
Аудит и управление рисками — регулярная проверка, не остались ли требования только на бумаге.
Вот теперь логика проступает четче: DLP имеет прямой смысл, если в системе обрабатываются ПДн, — Роскомнадзор требует не допустить их утечки. Принцип Zero Trust оправдан для критической инфраструктуры, потому что компрометация одного сервера внутри сети может иметь катастрофические последствия.
Чем все это защищать и как не утонуть в выборе инструментов
Средства защиты информации (СЗИ) — это действительно огромный арсенал. Разберу его по категориям.
Технические инструменты — это фундамент. Антивирусы и EDR (Endpoint Detection and Response) — первая линия защиты конечных устройств. Не просто сканер сигнатур, а умный аналитик, который отслеживает поведение процессов на компьютерах и может автоматически пресекать атаки. Требуется ФСТЭК для важных систем.
Я видел, как EDR спасал компании от распространения вредоноса, которого никакой антивирус не поймал бы. Вручную на то, чтобы найти, откуда пришла атака, ушли бы часы. EDR это заметил за минуты.
Межсетевые экраны (firewall, NGFW) — ваш первый охранник. Обычный брандмауэр фильтрует трафик по портам и IP. NGFW (Next-Generation) умеет заглядывать внутрь трафика и понимать, какое приложение работает, что делает его на порядок эффективнее.
IDS/IPS (Intrusion Detection/Prevention Systems) — более продвинутый уровень. Специализированные системы для обнаружения и предотвращения вторжений в сеть (IDS/IPS) и для защиты именно веб-приложений (WAF) от SQL-инъекций и других атак.
Если FW блокирует подозрительный трафик по общим правилам, то IDS анализирует поведение, ловит сигнатуры известных атак и может остановить вторжение, которое FW пропустит.
WAF (Web Application Firewall) — специализированный брандмауэр для веб-приложений. Обычный FW не понимает SQL-инъекций или XSS. WAF изучает поведение приложения и блокирует именно такие атаки. Критичен для публичных веб-приложений.
DLP (Data Loss Prevention) — инструмент, который контролирует каналы передачи данных, чтобы коммерческая тайна или ПДн не утекли за пределы компании.
Управление уязвимостями (Vulnerability Management) — регулярное сканирование на предмет известных дыр (CVE) в ПО и конфигурациях. Без этого вы просто не знаете, насколько вы уязвимы.
SIEM (Security Information and Event Management) — центр управления, «мозговой центр», который собирает логи со всей инфраструктуры, анализирует их и ищет признаки атак.
Я видел, как SIEM обнаружил скрытую компрометацию, которую никто не заметил бы при ручном мониторинге. Потребовалось проанализировать миллионы логов. Человек бы это никогда не сделал.
SOAR (Security Orchestration, Automation, and Response) — помогает автоматизировать реакцию на инциденты. Вместе они дают вам видение того, что происходит в системе.
Криптографические модули (HSM, TPM) — аппаратные или виртуальные сейфы для ключей. Если система использует криптографию (а она должна, если есть требования от ФСБ), то ключи не должны лежать в обычных файлах, их должен хранить криптографический модуль.
Secure Boot и TEE (Trusted Execution Environment) — средства доверенной загрузки и изолированного выполнения кода. Они гарантируют, что система загружается от производителя, а не от хакера, и что критичный код выполняется изолированно.
Если технические инструменты — это скелет информационной безопасности, то организационные инструменты — ее сердце. Здесь я должен быть честен: даже самые продвинутые технические инструменты ничего не стоят без организационной базы.
Почему без организационных инструментов техника бесполезна
Политики доступа (RBAC, ABAC, Zero Trust) — это четкие правила «кто, что и когда может делать». От простых ролевых моделей до сложных систем, где доступ зависит от множества атрибутов. Самый простой подход — Role-Based Access Control (RBAC), где разработчик может читать исходный код, но не может удалять пользователей. Более гибкий — Attribute-Based Access Control (ABAC), гда доступ зависит от атрибутов: отдел, уровень допуска, время суток, IP-адрес. Самый требовательный — Zero Trust, где не верят никому, даже внутри сети: каждое действие требует проверки.
Процедуры реагирования на инциденты — это не просто документы в папке, а живой регламент, который отвечает на вопрос, кто и что делает в первые минуты после обнаружения атаки. Без этого в момент атаки вместо действий будет паника.
Самый слабый элемент защиты — человек, поэтому обучение персонала — не е-learning курс один раз в год, а регулярные тренинги по фишингу и цифровой гигиене. Согласитесь, что даже самый дорогой инструмент безопасности становится бесполезным, если сотрудник отправляет пароль по e-mail.
И, наконец, аудит и контроль — это проверка того, что все красивые политики и настройки работают на практике.
Теперь непосредственно об инструментах.
Аппаратные инструменты — физический уровень. Токены для двухфакторной аутентификации, аппаратные шифраторы (HSM), биометрические сканеры.
Аппаратные токены и смарт-карты — не просто красивая штука с микрочипом, а второй фактор аутентификации. Если пароль украдут, аккаунт не откроется без физического устройства.
Биометрические сканеры — контроль доступа по отпечаткам, лицу или сетчатке. Мощный инструмент, но требует осторожности из-за GDPR и 572-ФЗ.
Сетевые TAP-устройства — пассивные мониторы трафика. Позволяют копировать весь сетевой трафик в SIEM без влияния на производительность.
Аппаратные брандмауэры и маршрутизаторы — это не софтверные решения, а железо. Они обеспечивают более надежную фильтрацию и сегментацию сети.
Облачные инструменты — для облачной эры. Нативные сервисы безопасности от AWS, Azure, GCP; сканеры уязвимостей для контейнеров (Trivy, Clair).
Если IT-инфраструктура размещена в облаке, требования не исчезают, просто меняются инструменты.
Native облачные сервисы — AWS GuardDuty, Azure Sentinel, GCP Security Command Center. Это встроенные сервисы от провайдеров, которые мониторят активность в облачном аккаунте и ловят аномалии. Они дорогие, но интегрируются идеально с остальной инфраструктурой облака.
Облачные IAM-модели — системы контроля доступа в облаке работают иначе, чем в традиционной инфраструктуре. Вместо групп домена Active Directory — роли и политики облачного провайдера.
Сканеры контейнеров — Trivy, Clair. Если вы используете контейнеры, эти сканеры анализируют образы на наличие известных уязвимостей прямо в пайплайне CI/CD.
Платформенные инструменты — встроенные механизмы вроде SELinux/AppArmor или Windows Defender, которые ограничивают возможности приложений внутри ОС.
Как из этого всего многообразия выбрать именно то, что нужно
Первое правило: следить за регулятором, а не за модой
Не покупайте инструмент, потому что о нем говорят на конференции. Покупайте, потому что он прямо требуется ФСТЭК для вашей ГИС или Роскомнадзору для ИСПДн. Это экономит бюджет и гарантирует закрытие требований.
Второе правило: не хвататься за все сразу
Если на вас воздействуют несколько регуляторов, расставьте приоритеты. Начните с самого строгого, например, для финтеха — это Банк России, для госсектора — ФСТЭК.
Третье правило: думать об интеграциях
Красивый коробочный продукт, который не стыкуется с вашей SIEM или системой контроля доступа, создаст новые проблемы. Выбирайте инструменты, которые умеют «разговаривать» друг с другом.
Четвертое правило: не экономить на людях
Самый продвинутый инструмент в руках неподготовленного специалиста бесполезен, а иногда и опасен. Лучше начать с найма грамотного специалиста, а потом вместе с ним выбрать подходящий инструмент.
Я видел в своей практике, как компания купила дорогую систему мониторинга, но персонала на ее обслуживание не выделила. Через полгода система работала в базовом режиме, алерты игнорировались. Инвестиция была потрачена впустую. В следующем проекте они сначала наняли специалистов, потом выбрали инструмент — результат был совершенно другой.
Каков вывод
В этой статье я прошелся по основам информационной безопасности, но главное, что я понял на практике: информационная безопасность — это не магия и не тупая бюрократия. Это логичная система, где каждый регулятор отвечает за свой сегмент, каждый инструмент решает конкретную задачу, а каждое требование (пусть иногда и тяжелое в исполнении) имеет свою цель.
В следующий раз, когда к вам придут с требованием от ИБ, попробуйте задать три вопроса:
Какой регулятор за этим стоит?
Какую информацию или систему это должно защитить?
Какой инструмент решает эту задачу?
Ответы помогут перейти от роли пассивного исполнителя к роли партнера, который понимает смысл происходящего. А это — первый шаг к настоящему диалогу между IT и безопасностью.
В следующей статье я попробую разобраться, как правильно интегрировать эти инструменты в инфраструктуру и как организовать процесс так, чтобы ИБ не замораживала разработку.