1 / 21

Распределенные системы (Безопасность) (часть 2)

Распределенные системы (Безопасность) (часть 2). Обеспечение контроля доступа. Код CORBA , обеспечивающий выполнение политики контроля доступа содержится в объекте accessDecision. Клиентское приложение ( отправитель сообщ. ). Целевой объект. Граница ORB. Execution Context.

xia
Download Presentation

Распределенные системы (Безопасность) (часть 2)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Распределенные системы(Безопасность)(часть 2)

  2. Обеспечение контроля доступа Код CORBA, обеспечивающий выполнение политики контроля доступа содержится в объекте accessDecision

  3. Клиентское приложение (отправитель сообщ.) Целевой объект Граница ORB Execution Context message( ) Credential Domain Policy Enforcement Code (объект accessDecision) Identity Domain Policy Privileges ORB подсистема обеспечения безопасности Место объекта accessDecision в системе

  4. Функционирование объекта accessDecision (ADO) 1. ORB отправляет запрос ADO о принятии решения о предоставлении доступа 2. ADO получает политику контроля доступа из домена 3. ADO получает предоставленные субъекту права 4. ADO получает требуемые для доступа к методу права 5. ADO сравнивает предоставленные и требуемые права 6. ORB обеспечивает выполнение политики

  5. Процедура контроля доступа Решение о доступе: предоставитьили запретить Политика доступа к домену Предоставляемые права Домен атрибуты безопасности accessDecision объект Целевой объект метод requiredRights объект access_allowed? атрибуты безопасности целевой объект:метод Interface Необходимые права

  6. Конфликты при принятии решения о предоставлении доступа • объект может принадлежать к более чем одному домену, что усложняет принятие решений. • домены могут иметь иерархическую структуру • объекты Access decision должны следовать правилам принятия решений

  7. Иерархическая структура доменов Домен верхнего уровня В иерархической структуре объект является членом домена. Который в свою очередь является членом другого домена Домен нижнего уровня объект

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

  9. Автономные домены В случае автономных доменов, политика доменов расположенных на более низком уровне иерархии является более приоритетной Домен верхнего уровня Домен нижнего уровня Домен, определяющий политику в случае конфликта объект

  10. Объединенные домены Домены могут быть объединенными. Что значит, что они должны иметь правила для разрешения конфликтов Домен верхнего уровня object

  11. Защита сообщений (message protection) • Система безопасности обеспечивает защиту сообщений таким образом, что неавторизованный субъект не может получить доступ к информации содержащейся в сообщении или модифицировать ее • Защита сообщений как и контроль доступа основана на политике • Политика защиты сообщений определяет, какое качество защиты (quality of protection QOP)требуется для того или иного сообщения.

  12. Качество защиты (Quality of Protection) Существует три типа защиты сообщений: 1. Message origin authentication (подлинность сообщений)обеспечивает аутентичность отправителя сообщения. 2. Message confidentiality (конфиденциальность сообщений)обеспечивает защиту информации в сообщении от доступа неавторизованных субъектов 3. Message integrity (целостность сообщений)обеспечивает защиту информации в сообщениях от модификации неавторизованными субъектами

  13. Определение политики • Политика защиты сообщений может быть определена владельцами объектов, владельцами систем, субъектами. • Владельцы объектов желают обеспечить защиту данных, проходящих через объекты • Владельцы системы желают обеспечить защиту сообщений, обрабатываемых ORB • Субъекты желают обеспечить защиту отправляемых и получаемых данных и сообщений

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

  15. Владельцы системы • Владельцы системы могут задать два типа политик защиты сообщений • Политика безопасности клиентских вызовов – определяет минимальный уровень защиты сообщений, отправляемых системой • Политика безопасности серверных вызовов – определяет минимальный уровень защиты для принимаемых сообщений и максимальный уровень защиты, поддерживаемый системой

  16. Обеспечение защиты сообщений (клиент) Если ORB собирается отправить сообщение, ему нужно просмотреть политику субъекта, которая содержится в учетной записи субъекта, политику владельца объекта, которая содержится в объектной ссылке, и политику владельца системы, которая содержится в в объекте client secure invocation policy текущего контекста выполнения

  17. Обеспечение защиты сообщений (клиент) Client Secure Invocation Policy Target Object Reference Max Supported QOP Required QOP Required QOP ORB Required Effective QOP Current Security Context Required QOP Credential

  18. Обеспечение защиты сообщений (получение) В случае, когда ORB получает сообщение, ему требуется определить QOP, примененное отправителем к данному сообщению, политику получающего субъекта и политику владельца системы

  19. Security Context Обеспечение защиты сообщений (сервер) Server Secure Invocation Policy Context Setup Token Supported QOPRequired QOP Applied QOP ORB Accepted Effective QOP Current Supported QOPRequired QOP Credential

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

  21. Principal authentication Session authentication Authorization Message invocation Change security environment Change security policy Create object Селекторы аудита • Destroy object • Non-Repudiation • All Events

More Related