ВведениеДля любой организации в современном мире воздействие атак на ее ресурсы является существенной проблемой, актуальность которой из года в год только возрастает; для противодействия им создаются соответствующие системы защиты [1]. По причине же многообразия атак (программно-математических, перемещения, природных, технических и др.) системы защиты вынужденно строятся из целого набора специализированных подсистем, каждая их которых ответственна за свой класс (канал). Однако из этого и следует одно из основных противоречий предметной области. Совместная работа подсистем, построенных на различной базе, но в рамках единой системы, как правило, имеет меньшую суммарную эффективность защиты [2, 3] – подсистемы начинают конфликтовать, снижая результативность; противодействие атакам, состоящим из нескольких классов, требует дополнительного времени для связывания их надсистемой в единый вектор [4], снижая оперативность; методы и средства согласования взаимодействия подсистем требуют дополнительных накладных расходов (как программно-аппаратных, так и человеческих), что приводит к росту ресурсоемкости. И, как было показано неоднократно ранее авторами [5, 6, 7], разрешение противоречия может быть обеспечено только на этапе проектирования системы защиты путем синтеза ее научно-обоснованной и практически-состоятельной архитектуры (как, например, в [8]), которая как раз и закладывает фундамент потенциальной эффективности [9, 10] (в данном контексте под архитектурой системы понимается состав ее подсистем, а также организация их информационно-технического взаимодействия). Поэтому этот вопрос является крайне принципиальным и требует своего осмысления. Постулировать основные принципы проектирования архитектуры современных систем защиты и предполагается в настоящей статье. Принципы проектированияИспользуя богатый опыт в анализе проблемных вопросов систем защиты информации [11, 12, 13], а также в оценке их результирующей эффективности [14], были сформулированы следующие пять принципов, следование которым, по мнению авторов, позволит синтезировать архитектуру систем защиты информационных ресурсов, избавленную от множества внутренних противоречий, присутствующих в эволюционно построенных (т.е. постепенно, без заранее спроектированной структуры). 1. Искусственность декомпозиции (целенаправленность)Большинство систем защиты создавалось, адаптируясь к изменяемому миру – по мере возникновения новых классов угроз, появления средств защиты, формирования требований к работе. Тем самым создание архитектур систем представляло собой эволюционный процесс. При этом входящие в состав подсистемы формировались из уже существующих (независимых) элементов, что негативно сказывалось на результирующей эффективности системы защиты, поскольку элементы изначально создавались для достижения собственных целей, которые после включения в состав единой системы оказывались несогласованными. Так, например, подсистема контроля и управления доступом будет стремиться не допустить на территорию организации лиц без пропуска, а в случае обнаружения подсистемой пожарной сигнализации очага возгорания и автоматического вызова «внешней» пожарной бригады, последняя не сможет пройти через проходную (по крайне мере, потребуется время для предоставления им доступа) – явный диссинергетический эффект [15].Его предотвращение приводит к первому принципу построения системы защиты – искусственной декомпозиции на подсистемы с учетом общей целенаправленности. В результате архитектура будет изначально создаваться так, чтобы гармонизировать частные цели подсистем в направлении основной цели системы [16, 17, 18, 19]. Яркий пример – создание «продвинутых» систем охранно-пожарной сигнализации.Представим применение принципа с помощь следующей схемы (Рис. 1).                                                                                            а)                                                                                                                                                                б) Рисунок 1 – Пример создания систем защиты:а) эволюционный процесс; б) целенаправленный процесс Согласно схеме, изначально (см. рис. 1а) каждая из подсистем имеет свою «изолированную» цель, поскольку создавалась независимо от других. В случае применения первого принципа (см. рис. 1б) все подсистемы «работают» на общую цель. 2. Необходимость и достаточность подсистемСоздание архитектуры системы защиты из набора уже имеющихся подсистем имеет два существенных недостатка. Во-первых, используемые подсистемы могут иметь перекрывающийся функционал, как излишне дублируя решаемые задачи, так и мешая тем самым друг другу. Например, достаточно часто задача обновления программного обеспечения серверов ложится как на подсистему сетевой безопасности, так и внутренней технической поддержки. Во-вторых, может сложиться ситуация, когда существующие подсистемы будут выполнять только часть требуемых задач, а создание новой ради решения оставшихся задач окажется нецелесообразным. Например, подсистема контроля и управления доступом не ведет запись заезжающих на территорию автомобилей (а только управляет поднятием шлагбаума), что не позволит в последствие сопоставить архивы событий при возникновении инцидента. Препятствование дублированию и коллизиям возможно с помощью второго принципа построения системы защиты – необходимости и достаточности деления на подсистемы [20, 21]. Тем самым все множество подсистем перекроет все необходимые задачи, а каждая из подсистем не будет «залезать» в зону ответственности другой.Представим применение второго принципа с помощь следующей схемы (Рис. 2).                                             а)                                                                                                                                         б) Рисунок 2 – Пример проектирования архитектуры из набора подсистем:а) существующих; б) необходимых и достаточных Согласно схеме, изначально (см. рис. 2а) область задач (пунктиром) покрыта подсистемами не полностью или избыточно, а также с взаимным перекрытием. Затем, после применения второго принципа (см. рис. 2б) область задач оказывается полностью «покрыта» функционалом подсистем без их взаимного пересечения. 3. Структурная инвариантностьРазвитие современного мира, и в особенности повсеместное внедрение все новых IT-решений, приводит к постоянному изменению условий проведения старых атак, а также к появлению качественно новых. Все это требует как адаптации существующих механизмов и подсистем защиты, так и создания новых. При этом постоянные перестройки архитектуры их единой системы, очевидно, будет крайне негативным вариантом – не говоря о постоянных финансовых затратах; модернизация и ввод в эксплуатацию новой версии такой архитектуры попросту может не успевать за эволюционированием атакующих воздействий. Например, появление в организациях киберфизических устройств, полностью управляемых искусственным интеллектом (по аналогии с развитием беспилотных автомобилей в концепции Умного города), приведет и к новому классу атак, направленному на интеллектуальный центр управления. Создание же и внедрение в работающую архитектуру новой подсистемы защиты, а также ее согласование с остальными подсистемами, может оказаться невозможным и потребует частичного перестроения всей системы. Исходя из этого, имеет смысл изначально создавать такую архитектуру (и, следовательно, производить деление на подсистемы), которая бы оказывалась неизменной во времени – т.е. не требовала качественных перестроений при возникновении новых задач. Это соображение приводит к третьему принципу – структурной инвариантности архитектуры системы защиты [22, 23]. Учет принципа позволит расширять набор механизмов защиты от атак, осуществляя параметрический, но не структурный синтез новой системы.Представим применение третьего принципа с помощь следующей схемы (Рис. 3).                                                                           а)                                                                                                                                                    б) Рисунок 3 – Пример инвариантной архитектуры системы защиты в условиях:а) традиционных атак; б) нового класса атак (задач) Согласно схеме, изначально (см. рис. 3а) каждая из четырех подсистем отражает собственный класс атак. После появления нового класса (см. рис. 3б) «мощность» Подсистемы 4 (в смысле объема решаемых ею задач) возросла для дополнительного противодействия Атакам класса 5; при этом в систему защиты внесены параметрические (объем задач), но не структурные (количество подсистем) изменения. 4. Универсализация взаимодействияНеобходимость совместной работы множества подсистем требует от них постоянного информационно-технического взаимодействия. Качественная же различность подсистем ведет к тому, что используемые ими информационные объекты, а также логика обмена последними, не позволяют их применить для полноценного взаимодействия, однозначно понятного всем его участникам. Например, в подсистеме контроля и управления доступом можно предположить наличие таких объектов, как запрос на идентификацию посетителя, открытие турникета, незаконное проникновение и др.; а для подсистемы пожарной сигнализации – повышение температуры в комнате, включение системы пожаротушения, вызов внешней пожарной бригады. Очевидно, что эти подсистемы с такими объектами обмена никогда не смогут «договориться» иначе как по уникальному протоколу. Таким образом, возникает необходимость в четвертом принципе – универсализации взаимодействия подсистем защиты [24]. Применение этого принципа позволит подсистемам общаться на базе единых объектов и используя понятную логику.Представим применение четвертого принципа с помощь следующей схемы (Рис. 4).                                          а)                                                                                                                                                      б) Рисунок 4 – Пример информационно-технического взаимодействия подсистем:а) уникального; б) универсального Согласно схеме, изначально (см. рис. 4а) каждая из подсистем взаимодействует с другими, используя собственные уникальные формат и алгоритмы. После перевода всех взаимодействий на одну базу объектов обмена и логику (см. рис. 4б) будет реализован четвертый принцип. 5. Единое информационное пространствоПомимо того, что подсистемы должны иметь универсальное взаимодействие друг с другом, они также должны обладать одинаковыми знаниями для принятия соответствующих решений. Таким образом, требуется синхронизация общей информации и унифицированный формат ее хранения. Так, обнаружение нового сценария атаки одной подсистемой должно стать известным и всем остальным, поскольку эта атака может оказаться частью вектора, действующего сразу через несколько зон ответственности подсистем. Например, диагностирование подсистемой контроля и доступа факта прохождения нарушителя путем клонирования электронного пропуска должно предупредить подсистемы сетевой безопасности и видеонаблюдения о высокой технической подготовки нарушителя и, следовательно, более высоких рисках взлома сети и нейтрализации видеокамер и датчиков сигнализации. Таким образом, возникает пятый принцип – использование единого информационного пространства [25-29]. Архитектура систем защиты, построенных с помощью этого принципа, позволит подсистемам использовать данные и функции из общего («расшаренного», от англ. to share) пространства – т.е. всегда находящиеся в актуализированном состоянии.Представим применение пятого принципа с помощь следующей схемы (Рис. 5).                                                                                       а)                                                                                                                                                                    б) Рисунок 5 – Пример организации информационного пространства подсистем:а) собственного; б) единого Согласно схеме, изначально (см. рис. 5а) каждая из подсистем содержит в себе собственную базу данных (возможно, с функциями их обработки), необходимых, в том числе, другим подсистемам. После перевода всех подсистем на единое информационное пространство (см. рис. 5б) они начинают общаться именно с ним, как с полномочным представителем баз данных всех подсистем. ВыводыАнализ проблемных вопросов современных систем защиты, а также богатый авторский опыт, позволили обоснованно предложить пять принципов построения таких систем. Принципы оказывают непосредственное влияние как на состав подсистем (включая решаемые ими задачи), так и на их взаимодействие. Применение одновременно всех принципов является достаточно сложной задачей, как с научной, так и с технической стороны. Тем не менее, перспективное направление их реализации авторами видится в следующем. Во-первых, это синтез состава подсистем с использованием категориального деления, что позволит соблюсти первые три принципа. А, во-вторых - организация универсального протокола (как совокупности объектов обмена и его логики) [30] информационно-технического взаимодействия между ними, что приведет к соблюдению последних двух принципов. Дальнейшим направлением исследований должна стать выработка рекомендаций для более точного соответствия реализаций архитектуры разрабатываемых систем защиты каждому из описанных принципов ее проектирования.