Система защиты информации в информационных системах

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

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

Что такое система защиты информации информационных систем

Система защиты информации информационных систем (СЗИ ИС) — это не один антивирус и не папка с паролями, а согласованный комплекс организационных, технических и правовых мер, которые обеспечивают конфиденциальность, целостность и доступность данных на всём протяжении их жизненного цикла. Формально это совокупность подсистем, регламентов и ответственных лиц, работающих по единому замыслу и подчинённых одной цели: не допустить, чтобы информация была раскрыта, изменена или уничтожена без санкции владельца.

Ключевое слово здесь — система. Отдельный замок на двери серверной или корпоративный антивирус решают частную задачу, но не образуют защиты. Система появляется, когда меры связаны между собой: политика доступа определяет, кто и к каким данным допущен; средства аутентификации подтверждают, что это действительно он; журналы фиксируют каждое действие; а регламент реагирования описывает, что делать, если что-то пошло не так. Уберите любой элемент — и остальные теряют смысл.

Для владельца бизнеса или руководителя ИТ-направления практический вывод прост: защита информации — это управленческая дисциплина, а не набор гаджетов. Её нельзя «купить», её можно только выстроить и затем поддерживать. Именно поэтому в основе любой СЗИ лежат три вопроса: что мы защищаем, от кого и с какой ценой допустимых потерь. Ответы на них определяют всё остальное — от выбора шифрования до того, сколько сотрудников и часов потребуется на сопровождение.

Отличайте СЗИ ИС от смежных понятий. Антивирусная программа — это средство защиты, один из инструментов. Защита информации как таковая — более широкая область, охватывающая и бумажный документооборот, и физическую охрану. А СЗИ ИС — это прикладная дисциплина применительно к конкретной информационной системе: банковской АБС, платёжному шлюзу, корпоративному порталу, государственному реестру. Именно привязка к конкретной системе делает требования измеримыми и проверяемыми.

Из чего состоит система: субъекты, объекты и средства защиты

Любую СЗИ удобно раскладывать на три слоя: субъекты, объекты и средства. Субъекты — это те, кто защищает и кто пользуется: администраторы безопасности, служба ИБ, рядовые сотрудники, подрядчики, а также внешние нарушители, от которых защищаются. Объекты — то, что защищается: сами данные, носители, каналы связи, учётные записи, программное обеспечение, помещения. Средства — инструменты, которыми субъекты воздействуют на объекты, чтобы обеспечить их сохранность.

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

• Организационные — приказы, регламенты, инструкции, разграничение зон ответственности, обучение персонала, режим допуска.
• Технические — межсетевые экраны, средства антивирусной защиты, системы обнаружения вторжений, DLP-системы, средства криптографической защиты информации (СКЗИ).
• Программные — системы управления доступом, средства контроля целостности, сканеры уязвимостей, SIEM-платформы для сбора и анализа событий.
• Физические — охрана, видеонаблюдение, контроль доступа в помещения, защита от утечек по электромагнитным каналам.
• Правовые — договоры о неразглашении, соглашения об обработке персональных данных, локальные акты об ответственности за нарушение режима.

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

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

Классы защищённости и уровни доверия по ГОСТ и приказам ФСТЭК

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

Основные развилки классификации:

• Класс защищённости — определяется по документам ФСТЭК для государственных информационных систем и иных систем, обрабатывающих защищаемую информацию. Класс зависит от уровня значимости информации и масштаба системы.
• Уровень защищённости персональных данных (УЗ) — устанавливается по постановлению Правительства РФ в зависимости от категории данных (специальные, биометрические, общедоступные, иные) и числа субъектов.
• Уровень доверия — применяется к средствам защиты информации: чем выше уровень, тем строже требования к их разработке, тестированию и документации.
• Отраслевые требования — например, для банковских технологических процессов Банк России устанавливает собственные стандарты и обязательные к исполнению положения.

Практический смысл классификации — в объёме мер. Система низшего класса может обойтись базовым набором: разграничение доступа, парольная политика, резервное копирование, антивирус. Для высокого класса добавляются обязательная криптографическая защита каналов, усиленная регистрация событий безопасности, регулярный контроль защищённости, аттестация и многое другое. Ошибиться в классе — значит либо переплатить за избыточные меры, либо получить предписания надзорных органов и риск штрафов.

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

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

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

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

• Внешний нарушитель — хакер-одиночка, криминальная группа, конкуренты, иностранные спецслужбы. Различаются ресурсами и целями.
• Внутренний нарушитель — сотрудник без прав доступа, сотрудник с легальным доступом, администратор, уволенный работник, подрядчик. Внутренние угрозы часто опаснее: у нарушителя уже есть легальный вход.
• Случайный нарушитель — тот, кто действует по неосторожности: переслал данные не туда, потерял носитель, установил сомнительное ПО.

Порядок разработки модели угроз обычно такой:

1. Инвентаризация: описать систему, её границы, состав данных, пользователей, связи с другими системами.
2. Идентификация угроз: составить перечень сценариев — от утечки через фишинг до физического хищения носителя.
3. Оценка вероятности и ущерба: для каждой угрозы определить, насколько она реалистична и что произойдёт при реализации.
4. Ранжирование: выделить актуальные угрозы, отбросив маловероятные и незначимые.
5. Выбор мер: под каждую актуальную угрозу подобрать средство или процедуру, закрывающую её.
6. Документирование и пересмотр: утвердить модель, назначить сроки пересмотра (обычно не реже раза в год или при существенных изменениях).

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

Криптография, разграничение доступа и регистрация событий

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

Криптография. Средства криптографической защиты информации (СКЗИ) обеспечивают конфиденциальность (шифрование данных и каналов), целостность (электронная подпись, имитовставка) и подтверждение авторства. В России для защиты персональных данных и гостайны применяются преимущественно отечественные криптоалгоритмы, прошедшие сертификацию. Ключевой нюанс: шифрование защищает данные только тогда, когда ключи хранятся отдельно от зашифрованных массивов и доступ к ним строго ограничен. Если ключ лежит рядом с базой, шифрование превращается в декорацию.

Разграничение доступа. Работает по принципу минимально необходимых прав: сотрудник получает ровно тот доступ, который нужен для его задач, и ни уровнем больше. Реализуется через роли, группы, матрицы доступа, мандатные и ролевые модели. Обязательные элементы — периодический пересмотр прав (при переводе, увольнении, смене должности) и запрет на использование общих учётных записей. Административные права выдаются персонально и поимённо, а не «на отдел».

Регистрация событий. Журналы фиксируют входы, изменения данных, обращения к защищаемым ресурсам, срабатывания средств защиты. Ценность регистрации не в самом факте записи, а в возможности анализа: без SIEM или хотя бы регулярного просмотра логов журналы бесполезны. Практика показывает: инцидент обнаруживают либо по аномалии в логах, либо спустя месяцы, когда ущерб уже нанесён. Настройте оповещения на критичные события — множественные неудачные входы, доступ в нерабочее время, попытки повышения привилегий.

Связка этих трёх элементов даёт эффект синергии: криптография защищает данные при передаче и хранении, разграничение доступа не пускает лишних, регистрация показывает, кто и что делал. Уберите одно — и остальные теряют опору. Шифрование без контроля доступа бесполезно, контроль без логирования недоказуем, логи без шифрования легко подделать.

Как защищают банковские и платёжные информационные системы

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

Ключевые особенности защиты в этой сфере:

• Обязательная сертификация средств защиты. Применяются преимущественно сертифицированные ФСТЭК и ФСБ решения, а также стандарты Банка России для защиты информации в платёжных технологиях.
• Многофакторная аутентификация. Вход в банковские приложения и подтверждение операций требуют нескольких факторов: пароль, одноразовый код, биометрия. Код из SMS — аналог вашей подписи, и настоящие сотрудники банка никогда его не спрашивают. Назвав код постороннему, вы сами подтверждаете операцию.
• Фрод-мониторинг в реальном времени. Системы анализируют операции на предмет аномалий: нетипичная сумма, новое устройство, необычная география. Подозрительная операция блокируется до подтверждения клиентом.
• Сегментация сетей. Платёжный контур изолирован от корпоративной сети, доступ между сегментами строго регламентирован.
• Непрерывный контроль и аудит. Регулярные проверки защищённости, тестирование на проникновение, мониторинг инцидентов.

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

Отдельная зона риска — платёжные сервисы и агрегаторы, которые не являются банками. Здесь требования к защите ниже, а ответственность за операции часто размыта. Если сервис обещает доходность выше рыночной и торопит с переводом, это повод остановиться и проверить его статус. Мошенники маскируются под легальные платформы, и лучший фильтр — официальный реестр регулятора.

Аттестация, аудит и контроль эффективности защиты

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

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

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

Контроль эффективности — регулярная проверка, что средства защиты выполняют свои функции. Сюда входят:

1. Проверка актуальности обновлений и сигнатур средств защиты.
2. Тестирование на проникновение (пентест) — имитация атак для выявления уязвимостей.
3. Анализ журналов на предмет пропущенных инцидентов.
4. Проверка корректности прав доступа после кадровых изменений.
5. Оценка реакции персонала на учебные фишинговые рассылки.
6. Ревизия резервных копий и проверка восстановления из них.

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

Что делать при инциденте: план реагирования и уведомления

Даже самая защищённая система рано или поздно сталкивается с инцидентом. Разница между управляемой ситуацией и катастрофой — в наличии заранее прописанного плана реагирования. Импровизация в момент атаки почти всегда приводит к ошибкам: паника, потеря времени, уничтожение следов.

План реагирования должен содержать чёткие роли и последовательность действий. Примерная логика:

1. Обнаружение и фиксация. Зафиксировать факт инцидента, время, источник сигнала. Не выключать оборудование и не удалять логи — это уничтожит доказательства.
2. Локализация. Изолировать затронутый сегмент, заблокировать скомпрометированные учётные записи, при необходимости отключить сетевой доступ. Цель — не дать инциденту распространиться.
3. Оценка масштаба. Определить, какие данные и системы затронуты, есть ли утечка, кто мог получить доступ.
4. Уведомление ответственных. Поставить в известность руководство, службу ИБ, юридический отдел. При утечке персональных данных — уведомить регулятора в установленные законом сроки.
5. Устранение причины. Закрыть уязвимость, обновить средства защиты, сменить пароли и ключи.
6. Восстановление. Восстановить работу из проверенных резервных копий, убедившись, что в них нет вредоносного кода.
7. Разбор и выводы. Провести анализ инцидента, обновить модель угроз и регламенты, обучить персонал.

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

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

Информационный сервис. Не является финансовой рекомендацией. Окончательные условия уточняйте на сайте банка.