Библиографический список
Таненбаум Э., ван Стеен М. Распределенные системы. Принципы и парадигмы. СПб.: Питер, 2003. — 877 с.
Лекция №25-26 Вопросы разработки
В распределенную систему, да впрочем, и в любую компьютерную систему, должны быть встроены механизмы защиты, при помощи которых можно будет реализовать различные правила защиты. При реализации служб защиты общего назначения следует учитывать несколько моментов. Ниже мы рассмотрим три таких важных момента: фокус управления, многоуровневую организацию механизмов защиты и простоту.
Фокус управления
Организуя защиту приложений (в том числе и распределенных), можно использовать три основных подхода, которые иллюстрирует рис. 8.2. Первый вариант — это защита непосредственно ассоциированных с приложением данных. Под «непосредственно» мы имеем в виду, что независимо от того, какие операции могут производиться с элементами данных, основная задача этого типа защиты — сохранение целостности данных. Обычно такая защита используется в системах баз данных, в этом случае заранее определяются различные ограничения целостности, автоматически проверяемые затем при каждой модификации элемента данных.
Рис. 8.2. Три подхода к противодействию угрозам защите. Защита от неверных операций (а). Защита от неавторизованных обращений (б). Защита от неавторизованных пользователей (в)
Второй вариант — это защита путем точного указания того, кто и как может использовать операции доступа к данным или ресурсам. В этом случае фокус управления тесно связан с механизмами контроля доступа, о которых мы поговорим подробнее чуть позже. Так, например, в системе, построенной на основе объектов, для каждого из методов, доступ к которым мы открываем клиентам, можно указать, какой именно клиент имеет право к нему обратиться. С другой стороны, методы контроля доступа могут применяться к интерфейсу, предоставляемому объектом, или собственно объекту. Этот подход также используется с целью детализации управления доступом.
Третий вариант — сосредоточить внимание непосредственно на пользователе, приняв меры, чтобы доступ к приложению имели только определенные люди, независимо от операций, которые они собираются производить. Так, например, банковская база данных может быть защищена путем закрытия доступа к ней всем, кроме высшего управленческого персонала. Другой пример: во многих университетах доступ к определенным данным и приложениям разрешен лишь преподавателям и персоналу, студентам же доступ к ним закрыт. В действительности управление сведено к определению ролей (roles) пользователей. После подтверждения соответствующей роли ей предоставляется или запрещается доступ к соответствующим ресурсам. Процесс разработки системы защиты состоит, в частности, в том, чтобы определить роли, которые могут потребоваться пользователям, и предоставить механизмы управления доступом на основе списков ролей.
Многоуровневая организация механизмов защиты
Важным моментом при разработке систем защиты является решение о том, сколько уровней должны иметь механизмы защиты. Уровень в данном контексте соответствует логической организации системы. Так, например, компьютерные сети часто построены из нескольких уровней, в соответствии с некоторой эталонной моделью. Также можно организовать и структуру распределенных систем, в которой имеются отдельные уровни для приложений, задач промежуточного уровня, служб и ядра операционной системы.
Комбинируя многоуровневые структуры компьютерных сетей и распределенных систем, мы получаем схему, представленную на рис. 8.3.
Рис. 8.3. Логическая многоуровневая организация распределенных систем
В сущности, на рисунке службы общего назначения отделены от коммуникационных служб. Это разделение очень важно для понимания распределения по уровням механизмов защиты распределенных систем и, в частности, для представления о доверии. Разница между доверием и защитой очень важна. Система может быть или не быть защищенной, особенно принимая во внимание различные случайности, но мнение клиента о том, что система защищена — это вопрос доверия. Уровень, на котором размещается механизм защиты, зависит от доверия клиента к защите служб этого уровня.
В качестве примера рассмотрим организацию, расположенную в нескольких географически удаленных друг от друга местах, которые соединены коммуникационной службой, такой как коммутируемая мультимегабитная служба данных (SwitchedMulti-megabitDataService,SMDS). СетьSMDSможно рассматривать как базовую сеть канального уровня, соединяющую локальные сети, в том числе и разнесенные в пространстве, как это показано на рис. 8.4.
Защиту можно обеспечить путем установки шифрующего устройства на каждом маршрутизаторе SMDS, как показано на рисунке. Эти устройства автоматически зашифровывают и расшифровывают пересылаемые пакеты, но не предоставляют никаких средств для организации безопасной связи в пределах одной локальной сети. Если Алиса из сети А посылает сообщение Бобу в сеть Б и беспокоится о том, что это письмо кто-нибудь перехватит, она должна быть уверена по крайней мере в том, что шифрование трафика с удаленными сетями работает успешно. Это означает, например, что она должна доверять системным администраторам обеих локальных сетей и полагать, что они принимают меры против вмешательства в работу шифрующих устройств.
Рис. 8.4. Несколько сайтов, связанных глобальной службой магистрали
Допустим теперь, что Алиса не доверяет защите трафика с удаленными сетями. Она может предпринять собственные меры, например, использовать службу защиты транспортного уровня, такую как служба SSL (Secure Socket Layer —уровень защищенных сокетов), которая служит, в частности, для защищенной пересылки почты по соединениямTCP. Важно отметить, чтоSSLпозволит Алисе установить защищенное соединение с Бобом. Все сообщения транспортного уровня будут зашифрованы — и на уровнеSMSDтоже, но Алисе это не важно. В данном случае Алиса доверяет своей службеSSL. Другими словами, она верит, чтоSSLее защитит.
В распределенных системах механизмы защиты часто размещаются на промежуточном уровне. Если Алиса не доверяет SSL, она может пожелать использовать локальную службу защитыRPC. И опять-таки она должна доверять этой службе, полагая, что та работает корректно, а в данном случае не допускает утечек информации и верно идентифицирует клиенты и серверы.
Службам защиты, размещаемым на промежуточном уровне распределенных систем, можно доверять только в том случае, если те службы, на которые они полагаются, также защищены. Так, например, если служба защиты RPCреализована частично на основеSSL, доверие к службеRPCзависит от того, насколько вы доверяетеSSL. Если вы не доверяете защитеSSL, то не можете доверять и уровню защиты, предоставляемому службойRPC.