Об информационной безопасности будущей системы ситуационных центров в России

28 июня 2014 г. был принят Федеральный закон № 172-ФЗ "О стратегическом планировании в Российской Федерации", описывающий общий подход к координации работы исполнительной власти на всех уровнях, от федерального до местного. Ранее указом Президента № 537 "О Стратегии национальной безопасности Российской Федерации до 2020 года" определялась долгосрочная стратегия безопасности РФ, а также вводилось понятие ситуационного центра как одного из инструментов стратегического планирования.

Указанные документы и множество других предпосылок подводят нас к тому, что в обозримом будущем в России будет создаваться сеть распределённых ситуационных центров. При этом детального понимания, что такое система ситуационных центров, как и с какими данными будет эта система и её составные части работать, ни у кого пока нет. Да, существуют рекомендации ФСО, различные перечни данных, необходимых для обработки тем или иным ведомствам, есть даже отдельные ведомственные ситуационные центры, в том числе распределённые, но в целом задача настолько уникальна и масштабна, что готового решения для неё просто не существует.

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

Есть ли сейчас у МЧС информация, как сегодня работают различные сети ситуационных центров? Публичной информации почти нет. Но легко предположить, что, пока различные ведомства только учатся пользоваться новым инструментом и взаимодействовать друг с другом на принципиально новом уровне, системы ситуационных центров будут довольно часто и существенно изменяться и расширяться. Соответственно связи между различными сетями ещё некоторое время будут возникать и видоизменяться.

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

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

Кроме традиционных для отрасли ИБ задач именно в случае с распределёнными сетями ситуационных центров появляется ещё несколько интересных прикладных задач. Необходимо быть уверенным, что, во-первых, в систему попали настоящие данные, во-вторых, при любой обработке данных из системы или конкретного аналитического разреза не пропали данные или их часть, в-третьих, при хранении либо передаче данные не видоизменялись.

Кроме того, нужно всегда иметь возможность узнать: откуда и какие данные в систему попали; о факте изменения данных и определить его источник; кто и когда читал данные, особенно ту их часть, которая ещё не превратилась в приказы по муниципалитету, министерству и т. д.

Дополнительные сложности вносят ещё два фактора:

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

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

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

С распространением стандарта ISO/ГОСТ 27001 постепенно становится привычным отказ от сокрытия учётных записей пользователей, осуществляющих доступ к данным через front-end, под единой системной учётной записью, обращающейся к данным в БД. Активно вышли на рынок коммерческие системы контроля привилегированных учётных записей.

Однако есть две проблемы:

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

Для решения задачи контроля доступа к данным нужно фактически создать мини-версию самих распределённых ситуационных центров, следящих исключительно за данными, местами их хранения и доступом к данным или хранилищам. Это можно сделать с помощью систем класса GRC — Governance, Risk Management and Compliance System, которые сейчас только приходят на российский рынок. Да и целостными такие системы пока назвать нельзя: они умеют работать с ограниченным количеством прикладных источников данных и образовывать сеть только с себе подобными.

Для обеспечения защиты системы ситуационных центров необходимо создать систему ИБ, решающую следующие задачи:

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

Система обеспечения ИБ должна работать в большей степени автоматически, в частности, помечать информацию в прикладной системе как "недостаточно надёжную" и создавать задачи о ручном расследовании инцидентов, связанных с необъяснимой (с программной точки зрения) модификацией прикладной информации.

Очевидно, что для комфортной работы в такой среде у служб ИТ и ИБ должно быть несколько дополнительных инструментов:

1. одобренная и используемая архитектура разработки узлов прикладной системы, запрещающая сокрытие пользовательского доступа к данным под системной учётной записью СУБД;
2. система, сопоставляющая пользовательский доступ к СУБД с реальной учётной записью пользователя во front-end (при невозможности выполнения п. 1);
3. система контроля привилегированных учётных записей;
4. система управления жизненным циклом учётных записей — IDM;
5. подробная ролевая модель и заранее продуманная матрица доступов;
6. подробная сервисная модель, описывающая работу всего комплекса систем, в первую очередь прикладных.

При создании всех этих систем ИБ особенно важно не забывать, что сами ситуационные центры объединены в сложноподчинённые сети, как ведомственные, так и по уровням управления. Это означает, что передача информации между узлами по определению является нормальным условием работы ситуационных центров. То есть необходимо либо наладить обмен информацией между системами ИБ различных систем центров, либо создать единую структуру, обеспечивающую работу ИТ- и ИБ-инфраструктур ситуационных центров. Оба варианта довольно сложны в реализации.

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

Алексей САБАНОВ, заместитель генерального директора компании "Аладдин Р.Д."

Вопросы, рассмотренные в статье, весьма важны и актуальны. Однако постановку задачи можно уточнить. Для защиты данных известны следующие основные функции:

• защита доступа - доступ к данным пользователь получает только при успешном прохождении им процедур идентификации и аутентификации;
• разграничение доступа - каждый пользователь, включая администратора, имеет доступ только к необходимой ему согласно занимаемой должности информации; при этом доступ должен быть строго персонифицирован, т. е. каждое действие однозначно соотносится с конкретным субъектом;
• шифрование данных - шифровать необходимо как передаваемые в сети данные для защиты от перехвата, так и данные, записываемые на носитель, для защиты от кражи носителя и несанкционированного просмотра/изменения нештатными средствами СУБД;
• контроль целостности данных - защита от модификаций, аудит самих данных и проверка (аутентификация) источника данных;
• аудит доступа к данным - действия с критичными данными должны протоколироваться, причём, как правило, не штатными средствами, к которым у администратора СУБД всегда имеется доступ. Доступ к журналу не должны иметь пользователи, на которых он ведётся.

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

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

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