8.1.2. Вопросы разработки

В распределенную систему, да впрочем и в любую компьютерную систему, долж­ны быть встроены механизмы защиты, при помощи которых можно будет реали­зовать различные правила защиты. При реализации служб защиты общего назна­чения следует учитывать несколько моментов. Ниже мы рассмотрим три таких важных момента: фокус управления, многоуровневую организацию механизмов защиты и простоту [172].

Фокус управления

Организуя защиту приложений (в том числе и распределенных), можно исполь­зовать три основных подхода, которые иллюстрирует рис. 8.2. Первый вариант — это защита непосредственно ассоциированных с приложением данных. Под «не­посредственно» мы имеем в виду, что независимо от того, какие операции могут производиться с элементами данных, основная задача этого типа защиты — со­хранение целостности данных. Обычно такая защита используется в системах баз данных, в этом случае заранее определяются различные ограничения целостно­сти, автоматически проверяемые затем при каждой модификации элемента дан­ных [466].

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

Третий вариант — сосредоточить внимание непосредственно на пользователе, приняв меры, чтобы доступ к приложению имели только определенные люди, независимо от операций, которые они собираются производить. Так, например, банковская база данных может быть защищена путем закрытия доступа к ней всем, кроме высшего управленческого персонала. Другой пример: во многих университетах доступ к определенным данным и приложениям разрешен лишь преподавателям и персоналу, студентам же доступ к ним закрыт. В действитель­ности управление сведено к определению ролей (roles) пользователей. После подтверждения соответствующей роли ей предоставляется или запрещается дос­туп к соответствующим ресурсам. Процесс разработки системы защиты состоит, в частности, в том, чтобы определить роли, которые могут потребоваться пользо­вателям, и предоставить механизмы управления доступом на основе списков ро­лей. Мы еще поговорим о ролях в следующей главе.

Многоуровневая организация механизмов защиты

Важным моментом при разработке систем защиты является решение о том, сколько уровней должны иметь механизмы защиты. Уровень в данном контексте соответствует логической организации системы. Так, например, компьютерные сети часто построены из нескольких уровней, в соответствии с некоторой эталон­ной моделью, о чем мы говорили в главе 2. В главе 1 мы вводили понятие о такой структуре распределенных систем, в которой имеются отдельные уровни для приложений, задач промежуточного уровня, служб и ядра операционной систе­мы. Комбинируя многоуровневые структуры компьютерных сетей и распреде­ленных систем, мы получаем схему, представленную на рис. 8.3.

В сущности, на рисунке службы общего назначения отделены от коммуника­ционных служб. Это разделение очень важно для понимания распределения по уровням механизмов защиты распределенных систем и, в частности, для пред­ставления о доверии. Разница между доверием и защитой очень важна. Система может быть или не быть защищенной, особенно принимая во внимание различ­ные случайности, но мнение клиента о том, что система защищена — это вопрос доверия [351]. Уровень, на котором размещается механизм защиты, зависит от доверия клиента к защите служб этого уровня.

В качестве примера рассмотрим организацию, расположенную в нескольких географически удаленных друг от друга местах, которые соединены коммуника­ционной службой, такой как коммутируемая мультимегабитная служба данных (Switched Multi-megabit Data Service, SMDS). Сеть SMDS можно рассматривать как базовую сеть канального уровня, соединяющую локальные сети, в том числе и разнесенные в пространстве, как это показано на рис. 8.4 (дополнительную ин­формацию по SMDS можно найти в [238]).

Защиту можно обеспечить путем установки шифрующего устройства на каж­дом маршрутизаторе SMDS, как показано на рисунке. Эти устройства автомати­чески зашифровывают и расшифровывают пересылаемые пакеты, но не предо­ставляют никаких средств для организации безопасной связи в пределах одной локальной сети. Если Алиса из сети А посылает сообщение Бобу в сеть Б и бес­покоится о том, что это письмо кто-нибудь перехватит, она должна быть уверена по крайней мере в том, что шифрование трафика с удаленными сетями работает успешно. Это означает, например, что она должна доверять системным админи­страторам обеих локальных сетей и полагать, что они принимают меры против вмешательства в работу шифрующих устройств.

Допустим теперь, что Алиса не доверяет защите трафика с удаленными сетя­ми. Она может предпринять собственные меры, например, использовать службу защиты транспортного уровня, такую как служба SSL (Secure Socket Layer — уро­вень защищенных сокетов), которая служит, в частности, для защищенной пере­сылки почты по соединениям TCP. Мы более подробно рассмотрим SSL в гла­ве 11, когда будем обсуждать защиту в Web. Важно отметить, что SSL позволит Алисе установить защищенное соединение с Бобом. Все сообщения транспорт­ного уровня будут зашифрованы — и на уровне SMSD тоже, но Алисе это не важно. В данном случае Алиса доверяет своей службе SSL. Другими словами, она верит, что SSL ее защитит.

В распределенных системах механизмы защиты часто размещаются на проме­жуточном уровне. Если Алиса не доверяет SSL, она может пожелать использо­вать локальную службу защиты RPC. И опять-таки она должна доверять этой службе, полагая, что та работает корректно, а в данном случае не допускает уте­чек информации и верно идентифицирует клиенты и серверы.

Службам защиты, размещаемым на промежуточном уровне распределенных систем, можно доверять только в том случае, если те службы, на которые они по­лагаются, также защищены. Так, например, если служба защиты RPC реализова­на частично на основе SSL, доверие к службе RPC зависит от того, насколько вы доверяете SSL. Если вы не доверяете защите SSL, то не можете доверять и уров­ню защиты, предоставляемому службой RPC.

Распределение механизмов защиты

Зависимости между службами, требующими доверия, приводят к понятию дове­ренной вычислительной базы (Trusted Computing Base, TSB). TSB — это набор всех механизмов защиты (распределенной) компьютерной системы, необходимых для осуществления правил защиты. Чем меньше TSB, тем лучше. Если распределен­ная система построена на базе промежуточного уровня (надстройки над сущест­вующей сетевой операционной системой), ее защита может зависеть от защиты базовых локальных операционных систем. Другими словами, TSB в распределен­ной системе может включать в себя локальные операционные системы различ­ных хостов.

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

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

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

Подобное разделение эффективно уменьшает размер ТСВ до относительно небольшого числа аппаратных и программных компонентов. В ходе последую­щей защиты этих машин от внешних атак общее доверие к защите распределен­ной системы может быть еще увеличено. Предотвращение прямого доступа кли­ентов и их приложений к критически важным службам производится путем предоставления ограниченного интерфейса к защищенным системным компонен­там (Reduced Interfaces for Secure System Components, RISSC), как описано в [316]. Согласно этому подходу, любой критичный к уровню защиты сервер по­мещается на отдельную машину, изолированную от систем конечных пользова­телей, и использует низкоуровневые защищенные сетевые интерфейсы, как по­казано на рис. 8.5. Клиенты и их приложения работают на различных машинах и могут взаимодействовать с защищенным сервером только через эти сетевые ин­терфейсы.

Рис. 8.5. Применение принципов RISSC к защищенным распределенным системам

Простота

Простота

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

К сожалению, простых механизмов для реализации правил защиты часто не­достаточно. Рассмотрим снова эпизод, когда Алиса посылает письмо Бобу. Мы обсуждали его чуть раньше. Шифрование на канальном уровне — это простой и легко понятный механизм защиты от перехвата глобального трафика. Однако ес­ли Алиса хочет, чтобы ее письма мог получить только Боб, ей необходимо кое-что еще. Она нуждается в службах аутентификации пользовательского уровня, кроме того, чтобы доверять им, Алисе может потребоваться знать о том, как они работают. Поэтому аутентификация пользовательского уровня может потребо­вать как минимум представления о криптографических ключах и знания опреде­ленных механизмов, таких как сертификация, даже несмотря на то, что многие службы защиты полностью автоматизированы и прозрачны для пользователя.

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