ООО Топ Кросс


 
 Примеры использования. Модуль разграничения доступа

УПРАВЛЕНИЕ ДОСТУПОМ НА ОСНОВЕ МАНДАТНОЙ МЕТКИ

Одним из инструментов для построения политики разграничения доступа заложенных в Модуль является мандатная метка - специальное расширение, добавляемое в цифровой сертификат. ASN.1-тип мандатной метки описывается следующим образом:

MandateAccessLabels ::= SEQUENCE OF MandateAccessLabel SIZE (1..MAX)
MandateAccessLabel ::= SEQUENCE {
accessPolicy   OBJECT IDENTIFIER,
accessLevel    INTEGER (1..MAX)
}

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

  • идентификатор политики доступа для каждой из меток субъекта должен «наследоваться» от идентификатора политики доступа в одной из мандатных меток издателя;
  • уровень доступа для каждой из меток субъекта меньше либо равен уровню доступа из соответствующей метки издателя

Пример: В сертификатах издателя и субъекта указаны следующие метки:

 Идентификатор политики доступаУровень доступа
Издатель1.2.3.4.50100
Субъект1.2.3.4.50.1100
1.2.3.4.50.2200
1.2.3.4.51100

В процессе обработки цепочки сертификации, в сертификате субъекта:

  • метка с идентификатором { 1 2 3 4 50 1 } будет оставлена без изменений,
  • для метки { 1 2 3 4 50 2 } уровень доступа будет изменен на [ 100 ],
  • для метки { 1 2 3 4 51 } уровень доступа будет изменен на [ 0 ]

В переменные окружения CLIENT_CERT_MACL и SERVER_CERT_MACL устанавливаются только метки с ненулевым уровнем доступа.

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

УПРАВЛЕНИЕ ДОСТУПОМ НА ОСНОВЕ ПОЛИТИКИ ПРИМЕНЕНИЯ СЕРТИФИКАТА

В целом, использование идентификаторов политики применения сертификата в выражениях TCTLSRequireExpression либо в директивах RewriteCondition модуля mod_rewrite аналогично использованию мандатных меток. Однако присутствуют и существенные отличия:

  1. Порядок обработки данного расширения заданный стандартом, предусматривает либо полное отсутствие контроля за соотношением политик, указанных в сертификатах издателя и субъекта, либо крайне жесткое их связывание посредством расширения PolicyConstraints;
  2. Идентификаторы политик доступа в мандатных метках образуют древовидную структуру, отражающую распределение полномочий/ролей, при котором наличие метки с «корневым» идентификатором соответствует максимальному объему доступных полномочий/ролей. Таким образом, наличие мандатной метки с идентификатором политики доступа { 1 2 3 } и ненулевым уровнем, равнозначно наличию всех возможных меток с идентификаторами политик «наследующимися» от данного:
     {  1  2  3  1  }, {  1  2  3  4  5  },  {  1  2  3  99  } и т.п.
    

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

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

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

В ситуациях, когда перечисленные ограничения оказываются существенными, либо авторизация по содержимому X.509 сертификатов невозможна (нецелесообразна) в силу каких-либо других причин, для передачи авторизационной информации рекомендуется использовать атрибутные сертификаты. *


Примеры использования
Модуль разграничения доступа
© 2005-2012
LLC Top Cross
All Rights Reserved
 
 поиск
Google

 Цифровой Секретарь
клиентское программное обеспечение

на технологиях открытых ключей