Архитектурная безопасность

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

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

• при реализации системы защиты в виде совокупности сервисов может существовать способ миновать отдельные защитные средства, нарушая тем самым целостность планируемой цепочки сервисов безопасности (пример — наличие модемных выходов в Интернет, идущих в обход межсетевых экранов);
• при построении информационной системы в многоуровневой архитектуре клиент/сервер может существовать способ обхода одного или нескольких уровней, на которых сосредоточены средства защиты.

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

Еще одним важным архитектурным принципом следует признать минимизацию объема защитных средств, выносимых на клиентские системы. Причин тому несколько:

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

К необходимому минимуму следует отнести реализацию сервисов безопасности на сетевом и транспортном уровнях стека протоколов TCP/IP и поддержку механизмов аутентификации, устойчивых к сетевым угрозам.

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

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

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

Стандарты в области безопасности распределенных систем	Содержание	Сервисы безопасности