Протоколы безопасного сетевого взаимодействия
         

Архитектура PKI


Основой для достижения безопасности в Internet являлось создание протоколов безопасности, таких как TLS, SSH и IPSec. Все эти протоколы используют криптографию с открытым ключом для предоставления таких сервисов как конфиденциальность, целостность данных, аутентификация исходных данных и невозможность отказа. Целью PKI является предоставление доверенного и действительного ключа и управление сертификатом открытого ключа, который необходим для аутентификации, невозможности отказа и конфиденциальности.

Пользователи систем, основанных на открытом ключе, должны быть уверены, что когда они используют открытый ключ, субъект, с которым они связываются, является собственником соответствующего закрытого ключа. Эта уверенность достигается благодаря использованию PKCs, которые являются структурами данных, связывающих значения открытого ключа с субъектами. Связывание обеспечивается при наличии доверенного СА, который проверяет идентификацию субъекта и подписывает каждый PKC.

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

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

Получатель подписанных данных должен убедиться, что предоставленная идентификация пользователя соответствует идентификации, содержащейся в PKC. Получатель проверяет, не отменен ли в полученной цепочке сертификатов какой-либо PKC (например, посредством получения соответствующего текущего CRL или on-line запроса статуса сертификата) и все ли PKCs находились в рамках своих периодов действительности в момент подписывания данных. Получатель должен убедиться, что данные не содержат никаких значений, для которых подписывающая сторона не имеет авторизации. Получатель проверяет, не изменялись ли данные после подписывания, используя открытый ключ в PKC. Если все эти проверки проходят, получатель может считать, что данные были подписаны указанной подписывающей стороной.


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

Замечание: конечно, возможно, что данные были подписаны кем-то еще, если, например, закрытый ключ подписывающей стороны скомпрометирован. Безопасность зависит от всех частей системы, использующей сертификаты; она включает: физическую безопасность размещения компьютеров; безопасность персонала (например, возможность доверять людям, которые реально разрабатывают, инсталлируют, выполняют и сопровождают систему); безопасность, обеспечиваемую СА. Нарушение в любой из этих областей может послужить причиной нарушения безопасности всей системы. PKIX ограничена в предметной области и адресована только результатам, относящимся к функционированию подсистемы PKI.

PKI определяется как:

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

PKI состоит из следующих типов компонентов:

САs, которые выпускают и отменяют PKCs. RAs, которые ручаются за связь между открытыми ключами и идентификациями держателей сертификатов, а также другими атрибутами. Держатели PKCs, для которых выпущен сертификат, могут подписывать и шифровать документы, используя закрытые ключи. Клиенты, которые проверяют цифровые подписи и соответствующие верификационные пути с помощью известного открытого ключа доверенного СА и дешифруют документы, используя открытые ключи из сертификатов держателей PKCs. Репозитории, которые хранят и делают доступными PKCs и CRLs.

На рис.13.1 показан упрощенный взгляд на архитектурную модель PKI.


Рис. 13.1.  Участники PKI


Битовые строки


Тип BIT STRING обозначает битовые последовательности произвольной длины (включая ноль). Нотация BIT STRING имеет формат.

BIT STRING

Например, тип SubjectPublicKeyInfo имеет компонент PublicKey типа BIT STRING:

SubjectPublicKeyInfo ::= SEQUENCE { Algorithm AlgorithmIdentifier, PublicKey BIT STRING }



Целое


Тип INTEGER представляет любые целые числа (положительные, отрицательные или 0). Тип INTEGER используется для номеров версий, криптографических параметров (показателей, модулей и т.п.) и типов RSAPublicKey, RSAPrivatKey, DHParameter, PBEParameter. Нотация типа INTEGER имеет формат:

INTEGER [{identifier1(value1) ... identifiern(valuen) }]

где identifier1 ... identifiern являются необязательными идентификаторами, а value1 ... valuen целые значения. Например, Version является целым типом со значением 0:

Version ::= INTEGER { v1988(0) }

Идентификатору v1988 поставлено в соответствие значение 0. Тип Certificate использует идентификатор v1988 для присвоения значения по умолчанию компоненту version:

Certificate version Version DEFAULT v1988, ...





Идентификаторы объектов


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

Нотация OBJECT IDENTIFIER имеет формат:

OBJECT IDENTIFIER

Нотация значения OBJECT IDENTIFIER имеет вид:

{ [identifier] component1 ... componentn} componenti = identifieri | identifieri (valuei) | valuei

где identifier, identifier1, ... identifiern являются идентификаторами, а value1 ..., valuen –целые числа.

Например, приведенные ниже величины идентификаторов объектов присвоены RSA DATA Security, Inc.

{ iso(1) member-body(2) 840 113549 } { 1 2 840 113549 }

Ниже приведены некоторые идентификаторы объектов и их значения.

Таблица 13.1. Идентификаторы объектов и их значения

Величина идентификатора объектаНазначение
{ 1 2 }Члены ISO
{ 1 2 840 }US (ANSI)
{ 1 2 840 113549}RSA Data Security, Inc.



NULL


Тип NULL обозначает нулевую величину и предназначен для использования в качестве параметра алгоритмов. Нотация для типа NULL имеет формат:

NULL




Тип IA5String представляет любые последовательности IA5-символов (международный алфавит 5 – эквивалентно ASCII). Длина строки может быть любой, включая нуль. Этот тип используется для адресов электронной почты и неструктурированных имен. Нотация типа IA5String имеет простой формат.

IA5String


Строки октетов


Тип OCTET STRING служит для представления произвольных последовательностей октетов. Значение OCTET STRING может иметь любую длину, включая нуль. OCTET STRING используется для представления сообщений. Нотация типа OCTET STRING имеет формат.

OCTET STRING [SIZE ({size | size1..size2})]

где size, size1 и size2 – необязательные ограничения размера. В формате OCTET STRING SIZE (size) строка октетов должна иметь size октетов. В формате OCTET STRING SIZE (size1 .. size2) строка должна содержать число октетов между size1 и size2. Например, тип PBEParameter имеет компоненту типа OCTET STRING:

PBEParameter ::= SEQUENCE { salt OCTET STRING SIZE (8), iterationCount INTEGER }

Здесь размер компоненты salt всегда равен 8 октетам.



Строки печатных символов


Тип PrintableString предназначен для описания произвольных последовательностей печатных символов из набора:

A,B,...,Z a,b,...,z 0,1,...,9 (пробел) ‘ () +, – . / : = ?

Этот тип используется для представления атрибутов имен. Нотация типа PrintableString имеет вид:

PrintableString



Терминология PKI


Мы будем использовать следующие термины и понятия.

Public Key Infrastructure (PKI) – инфраструктура открытого ключа – это множество аппаратуры, ПО, людей, политик и процедур, необходимых для создания, управления, хранения, распределения и отмены сертификатов, основанных на криптографии с открытым ключом. End-entity (ЕЕ) – конечный участник, для которого выпущен данный сертификат. Важно заметить, что здесь под конечными участниками подразумеваются не только люди и используемые ими приложения, но также и исключительно сами приложения (например, для безопасности уровня IP). Этот фактор влияет на протоколы, которые используют операции управления PKI; например, ПО приложения следует более точно знать требуемые расширения сертификата, чем человеку. Certificate Authority (CA) – удостоверяющий (сертификационный) центр – это уполномоченный орган, который создает и подписывает сертификаты открытого ключа. Дополнительно СА может создавать пары закрытый/открытый ключ конечного участника. Важно заметить, что СА отвечает за сертификаты открытого ключа в течение всего времени их жизни, а не только в момент выпуска. Public Key Certificate (PKC) – сертификат открытого ключа или просто сертификат – это структура данных, содержащая открытый ключ конечного участника и другую информацию, которая подписана закрытым ключом СА, выпустившим данный сертификат.

Registration Authority (RA) – регистрационный центр – необязательный участник, ответственный за выполнение некоторых административных задач, необходимых для регистрации конечных участников. Такими задачами могут быть: подтверждение идентификации конечного участника; проверка значений, которые будут указаны в создаваемом сертификате; проверка, знает ли конечный участник закрытый ключ, соответствующий открытому ключу, указанному в сертификате. Заметим, что RA сам также является конечным участником.

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


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

Некоторые организационные причины для использования RA могут быть следующие:

Может оказаться более эффективным сконцентрировать некоторую функциональность в оборудовании RA, чем иметь данную функциональность для всех конечных участников (особенно если используется специальное оборудование для инициализации токена). Установление RАs в организации может уменьшить число необходимых СAs. RAs могут быть лучше размещены для идентификации людей с их "электронными" именами, особенно если СА физически удален от конечного участника. Для многих приложений уже существуют определенные административные структуры, которые могут играть роль RA.

Выпускающий CRL - необязательный компонент, которому СА делегирует функции опубликования списков отмененных сертификатов. Certificate Policy (CP) – политика сертификата – поименованное множество правил, которое определяет применимость сертификата открытого ключа для конкретного сообщества или класса приложений с общими требованиями безопасности. Например, конкретная политика сертификата может указывать применимость типа сертификата открытого ключа для аутентификации транзакций данных при торговле товарами в данном ценовом диапазоне. Certificate Practice Statement (CPS) – регламент сертификационной практики, в соответствии с которой сотрудники удостоверяющего центра выпускают сертификаты открытого ключа. Relying party (RP) – проверяющая сторона – пользователь или агент (например, клиент или сервер), который использует сертификат для надежного получения открытого ключа субъекта и, быть может, некоторой дополнительной информации. Root CA – СА, которому непосредственно доверяет ЕЕ; это означает безопасное приобретение значения открытого ключа корневого СА, требующее некоторых внешних шагов.



Этот термин не означает, что корневой СА обязательно должен быть вершиной иерархии, просто показывает, что СА является непосредственно доверенным. Заметим, что термин "доверенный якорь" имеет то же значение, что и корневой СА в данном документе. Subordinate CA – "подчиненный СА" представляет собой СА, который не является корневым СА для ЕЕ. Часто подчиненный СА не является корневым СА для любого участника, но это не обязательно. Top CA – вершина иерархии PKI. Замечание: часто он также называется корневым СА, так как в терминах структур данных и в теории графов узел на вершине дерева называется корнем. Однако во избежание путаницы в данном документе будем называть данный узел "вершиной СА", а "корневой СА" зарезервируем за СА, непосредственно тем, кому доверяет ЕЕ. Данный термин не является общепринятым во всех документах PKIX и профилях PKI. Репозиторий - система или набор распределенных систем, которые хранят сертификаты и CRLs и предназначены для распределения этих сертификатов и CRLs между конечными участниками.


Тип ANY


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

ANY [DEFINED BY identifier]

где identifier – необязательный идентификатор. Форма ANY DEFINED BY identifier может появиться только в компоненте типа SEQUNCE или SET, для которого identifier определяет какой-то другой компонент и этот компонент имеет тип INTEGER или OBJECT IDENTIFIER. В этой форме настоящий тип задается значением этого компонента. Например, тип AlgorithmIdentifier имеет компонент типа ANY:

AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameter ANY DEFINED BY algorithm OPTIONAL }

Здесь настоящий тип компонента parameter зависит от значения компонента algorithm. Настоящий тип будет определен при регистрации идентификатора объекта для компонента algorithm.



Тип CHOICE


Этот тип служит для объединения одной или более альтернатив. Нотация типа CHOICE имеет формат

CHOICE { [identifier1] Type1, ..., [identifiern] Typen

}

где identifier1, ..., identifiern являются необязательными идентификаторами альтернатив, а типы Type1, ..., Typen – альтернативы. Идентификаторы нужны для документирования и не играют какой-либо роли при представлении. Рассмотрим пример типа ExtendedCertificateOrCertificate, который относится к типу CHOICE.

ExtendedCertificateOrCertificate ::= CHOICE { certificate Certificate, extendedCertificate [0] IMPLICIT ExtendedCertificate }

Здесь идентификаторами для альтернатив являются certificate и extendedCertificate, а сами альтернативы представлены типами Certificate и [0] IMPLICIT ExtendedCertificate.



Тип SEQUENCE


Тип SEQUENCE обозначает упорядоченную последовательность одного или более типов. Нотация типа SEQUENCE имеет вид:

SEQUENCE { [identifier1] Type1 [{OPTIONAL | DEFAULT value1}], ..., [identifiern] Typen [{OPTIONAL | DEFAULT valuen}], }

где identifier1 , ..., identifiern являются необязательными идентификаторами компонентов, Type1 , ..., Typen – типы компонентов, а value1 ,..., valuen – необязательные значения компонентов по умолчанию. Квалификатор OPTIONAL указывает на то, что компонент является необязательным. Квалификатор DEFAULT говорит о том, что компонент является необязательным и ему присваивается определенное значение, если компонент отсутствует. Например, тип Validity относится к типу SEQUENCE и имеет два компонента.

Validity ::= SEQUENCE { start UTCTime, end UTCTime }

Здесь start и end являются идентификаторами компонентов, а типом компонентов служит UTCTime.



Тип SEQUENCE OF


Тип SEQUENCE OF обозначает упорядоченную последовательность из нуля или более значений компонентов данного типа. Нотация SEQUENCE OF имеет вид:

SEQUENCE OF Type

Так, например, тип RNDSequence состоит из нуля или более значений компонентов типа RelativeDistinguishedName.

RNDSequence ::= SEQUENCE OF RelativeDistinguishedName



Тип SET


Тип SET представляет собой неупорядоченное объединение из одного или более типов. Нотация типа SET имеет вид.

SET { [identifier1] Type1

[{OPTIONAL | DEFAULT value1}], ..., [identifiern] Typen

[{OPTIONAL | DEFAULT valuen}], }

где identifier1 , ..., identifiern являются необязательными идентификаторами компонентов, Type1 , ..., Typen – типы компонентов, а value1 ,..., valuen – необязательные значения компонентов по умолчанию. Квалификатор OPTIONAL указывает на то, что значения компонентов являются необязательными. Квалификатор DEFAULT говорит о том, что наличие компонента является необязательным, и ему присваивается определенное значение, если компонент отсутствует.



Тип SET OF


Тип SET OF является неупорядоченным набором, состоящим из нуля или более значений компонентов заданного типа. Нотация типа SET OF имеет вид:

SET OF Type

где Type – тип. Так, тип RelativeDistinguishedName состоит из нуля или более компонентов типа AttributeValueAssertion.

RelativeDistinguishedName ::= SET OF AttributeValueAssertion



Тип UTCTime


Тип UTCTime служит для обозначения универсального местного времени с привязкой по Гринвичу (GMT). Значение UTCTime определяет местное время с точностью минут или секунд и временной сдвиг по отношению к GMT. Оно может иметь следующие формы:

YYMMDDhhmmZ YYMMDDhhmm+hh`mm` YYMMDDhhmm-hh`mm` YYMMDDhhmmssZ YYMMDDhhmmss+ hh`mm` YYMMDDhhmmss- hh`mm`

где

YY – младшие две цифры года

ММ – код месяца (01 – 12)

DD – код дня (01 – 31)

hh – код часа (00 – 23)

mm – код минут (00 – 59)

ss – код секунд (00 – 59)

Z – означает местное время по Гринвичу, + указывает на то, что местное время отстает от GMT, а – указывает на то, что местное время опережает GMT.

hh` – абсолютное значение смещения по отношению к GMT в часах

mm` – абсолютное смещение по отношению к GMT в минутах.



В этой лекции мы кратко


В этой лекции мы кратко рассмотрим стандартную нотацию для определения типов и значений данных – Abstract Syntax Notation One (ASN.1). Значение данных является экземпляром определенного типа. Стандарт ASN.1 определяет несколько базовых типов и синтаксис соответствующих им значений, а также правила для получения составных типов и значений.
При описании протоколов взаимодействия или систем, которые совместно используют определенные структуры данных, требуется определить типы данных, передаваемые этими протоколами или совместно используемые различными системами. Для того чтобы определить эти типы данных, требуется специальная нотация. Такой нотацией является ASN.1.
Данная нотация, с одной стороны, интуитивно понятна, а с другой стороны, может использоваться как протоколами, так и программными системами. Неотъемлемой частью ASN.1 являются базовые правила представления BER (Basic Encoding Rules). BER описывает принцип представления любой величины в рамках стандарта ASN.1. Практически все величины представляются в виде последовательности 8-битных октетов. Восьмой бит октета считается самым старшим. BER позволяет представить величину в виде последовательности 8-битных октетов несколькими способами. Имеется также поднабор правил представления DER (Distinguished Encoding Rules), который определяют однозначные способы представления величин в ASN.1.
Ниже приведены базовые правила обозначений в ASN.1. Все нотации ASN.1 будут печататься шрифтом Courier New.
В ASN.1 типы и значения выражаются в нотации, близкой к используемой в языках программирования. Множественные пробелы и разрывы строк рассматриваются как один пробел. Комментарий может располагаться как на одной строке (в этом случае он начинается с пары символов -- и заканчивается концом строки), так и на нескольких строках (в этом случае он начинается с /* и заканчивается */). Идентификаторы (имена значений и полей) и имена типов состоят из букв, цифр и пробелов. Идентификаторы начинаются со строчной буквы, а имена типов – с прописной.


В ASN.1 используются следующие обозначения:
[] – квадратные скобки указывают на то, что терм является необязательным;
{} – фигурные скобки группируют родственные термы;
| – вертикальная черта выделяет альтернативные значения;
... – многоточие обозначает повторения;
= – знак равенства описывает терм как подтерм.
ASN.1 определяет следующие разновидности типов: простые типы, не имеющие компонентов, структурные типы, имеющие компоненты, помеченные (тегированные – tagged) типы, которые получаются из других типов добавлением метки (тега), а также такие типы, как CHOICE, ANY и некоторые другие. Типам и значениям могут присваиваться имена с помощью оператора присваивания "::=". Эти имена в дальнейшем могут использоваться для определения других типов и значений.
Определены следующие простые типы:
INTEGER – любое целое число;
BIT STRING – произвольная строка бит;
OCTET STRING – произвольная последовательность октетов;
NULL – 0;
OBJECT IDENTIFIER – последовательность компонентов, однозначно идентифицирующих объект;
PrintableString – последовательность печатных символов;
IA5String – произвольная строка символов IA5 (ASCII);
UTCTime – универсальное время (по Гринвичу; GMT).
Для строчных типов может быть введено ограничение на максимальный размер.
В ASN.1 определено четыре структурных типа:
SEQUENCE – упорядоченный набор из одного или более типов, некоторые из которых могут быть объявлены как необязательные.
SEQUENCE OF – упорядоченный набор из нуля или более значений данного типа.
SET – неупорядоченный набор из одного или более типов, некоторые из которых могут быть объявлены как необязательные.
SET OF – неупорядоченный набор из нуля или более значений данного типа.
Структурные типы могут иметь необязательные компоненты, в том числе со значениями по умолчанию.
Типы могут быть помечены явно или неявно. Неявно помеченные типы получаются из других типов путем изменения метки. Для неявной пометки используется ключевое слово IMPLICIT. Явно помеченные типы получаются из других типов путем добавления внешней метки.Для явной пометки используется ключевое слово EXPLICIT. Помеченный явно тип – это структурный тип, состоящий из одного существующего типа и тега. Пометка (тегирование) весьма удобна, чтобы различать типы в пределах одного приложения.
Тегированный тип является новым типом, который изоморфен старому, но имеет отличный от него тег.
TaggedType ::= Tag Type | Tag IMPLICIT Type | Tag EXPLICIT Type Tag ::= [ Class ClassNumber ] ClassNumber ::= Number | DefinedValue Class ::= UNIVERSAL | APPLICATION | PRIVATE | empty
DefinedValue должно быть типом целого и иметь неотрицательное значение.

Введение в PKI


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

Сначала определим ключевые термины, используемые в Инфраструктуре Открытого Ключа (Public Key Infrastructure – PKI) и основные исторические моменты разработки PKI. Затем рассмотрим архитектуру PKI, определим основные форматы данных и протоколы взаимодействия участников PKI.

Одним из требований к алгоритмам цифровой подписи является требование, чтобы было вычислительно невозможно, зная открытый ключ KU, определить закрытый ключ KR. Казалось бы, открытый ключ KU можно распространять по небезопасным сетям и хранить в небезопасных репозиторях. Но при этом следует помнить, что при использовании цифровой подписи необходимо быть уверенным, что субъект, с которым осуществляется взаимодействие с использованием алгоритма открытого ключа, является собственником соответствующего закрытого ключа. В противном случае возможна атака, когда оппонент заменяет открытый ключ законного участника своим открытым ключом, оставив при этом идентификатор законного участника без изменения. Это позволит ему создавать подписи от имени законного участника и читать зашифрованные сообщения, посланные законному участнику, используя для этого свой закрытый ключ, соответствующий подмененному открытому ключу. Для предотвращения такой ситуации следует использовать сертификаты, которые являются структурами данных, связывающими значения открытого ключа с субъектом. Для связывания необходимо наличие доверенного удостоверяющего (или сертификационного) центра (Certification Authority – СА), который проверяет идентификацию субъекта и подписывает его открытый ключ и некоторую дополнительную информацию своим закрытым ключом.

Целью PKI является предоставление доверенного и действительного открытого ключа участника, а также управление всем жизненным циклом сертификата открытого ключа.


Основным понятием Инфраструктуры Открытого Ключа является понятие сертификата.
Сертификат участника, созданный СА, имеет следующие характеристики:
Любой участник, имеющий открытый ключ СА, может восстановить открытый ключ участника, для которого СА создал сертификат. Никто другой, кроме данного удостоверяющего центра, не может модифицировать сертификат без обнаружения этого проверяющей стороной.
Мы будем рассматривать сертификаты Х.509, хотя существует достаточно много сертификатов других форматов.
CCITT (Consultative Committee for International Telegraphy and Telephony) разработал серию рекомендаций для создания так называемого сервиса Директории. Директория является сервером или распределенным набором серверов, которые поддерживают распределенную базу данных, содержащую информацию о пользователях и других объектах, которая называется Информационной Базой Директории (Directory Information Base – DIB). Данная информация может включать имя пользователя или объекта, а также другие атрибуты. Эти рекомендации носят название стандарта Х.500.
Стандарт Х.509 первоначально являлся частью стандарта Х.500 и описывал основные требования к аутентификации в Х.500 Директории. Но Х.509 используется не только в контексте сервиса Директории Х.500. Сертификаты, определяемые данным стандартом, используются практически всеми программными продуктами, относящимися к обеспечению сетевой безопасности.
Стандарты ITU-T X.509 и ISO/IEC 9594-8, которые впервые были опубликованы в 1988 году как часть рекомендаций Х.500 Директории, определили формат сертификата Х.509. Формат сертификата в стандарте 1988 года называется форматом версии 1 (v1). Стандарт Х.500 был пересмотрен в 1993 году, в результате чего было добавлено несколько новых полей в формат сертификата Х.509, который был назван форматом версии 2 (v2).
Опыт реализации первой и второй версий говорит о том, что форматы сертификата v1 и v2 имеют ряд недостатков. Самое важное, что для хранения различной информации требуется больше полей.


В результате ISO/IEC, ITU-T и ANSI X9 разработали формат сертификата Х.509 версии 3 (v3). Формат v3 расширяет формат v2 путем добавления заготовок для дополнительных полей расширения. Конкретные типы полей расширения могут быть определены в стандартах или определены и зарегистрированы любой организацией или сообществом. В июне 1996 года стандартизация базового формата v3 была завершена.
Однако расширения стандарта ISO/IEC, ITU-T и ANSI X9 являются очень общими, чтобы применять их на практике. Для того чтобы разрабатывать интероперабельные реализации систем, взаимно использующие сертификаты Х.509 v3, необходимо четко специфицировать формат сертификата Х.509 v3. Специалисты IETF разработали профиль сертификата X.509 v3 и опубликовали его в RFC 3280.
В табл. 13.2 рассмотрены основные элементы сертификата.

Таблица 13.2. Основные элементы сертификатаПояснениеПараметры сертификатаВерсия
Целое число, идентифицирующее данный сертификат, которое должно быть уникальным среди всех сертификатов, выпущенных данным САСерийный номерv1v2v3
СА, который создал и подписал сертификатИмя СА, выпустившего сертификат
Период действительности состоит из двух временных значений, в промежутке между которыми сертификат считается действительнымНе раньше
Не позже
Конечный участник, для которого создан данный сертификатИмя субъекта (конечного участника)
Открытый ключ субъекта и алгоритм, для которого этот ключ был созданАлгоритм
Параметры
Открытый ключ субъекта
Уникальный идентификатор СА
Уникальный идентификатор субъекта
Расширения
Подпись охватывает все остальные поля сертификата и состоит из хэш-кода других полей, зашифрованного закрытым ключом САПодпись, созданная закрытым ключом СА для всех полей сертификатаВсе версии

Часто используется следующая нотация для обозначения сертификата:
СА << A >>
– сертификат пользователя А, выданный сертификационным центром СА.
СА подписывает сертификат своим закрытым ключом. Если соответствующий открытый ключ известен пользователю, то пользователь может проверить, что сертификат, подписанный СА, действителен.


Так как сертификаты не могут быть изменены без обнаружения этого, их можно разместить в общедоступной директории и пересылать по открытым каналам связи без опасения, что кто-то может их изменить.
В любом случае если В имеет сертификат А, В уверен, что сообщение, которое он расшифровывает открытым ключом А, никто не мог просмотреть, и что сообщение, подписанное закрытым ключом А, не изменялось.
При большом количестве пользователей неразумно подписывать сертификаты всех пользователей у одного СА. Кроме того, если существует единственный СА, который подписывает сертификаты, каждый пользователь должен иметь копию открытого ключа СА, чтобы проверять подписи. Этот открытый ключ должен быть передан каждому пользователю абсолютно безопасным способом (с обеспечением целостности и аутентификации), чтобы пользователь был уверен в подписанных им сертификатах. Таким образом, в случае большого количества пользователей лучше иметь несколько САs, каждый из которых безопасно предоставляет свой открытый ключ некоторому подмножеству пользователей.
Теперь предположим, что А получил сертификат от уполномоченного органа Х1, и В получил сертификат от уполномоченного органа Х2. Если А не знает безопасным способом открытый ключ Х2, то сертификат В, полученный от Х2, для него бесполезен. А может прочитать сертификат В, но не в состоянии проверить подпись. Тем не менее, если два САs могут безопасно обмениваться своими открытыми ключами, возможна следующая процедура для получения А открытого ключа В.
А получает из директории сертификат Х2, подписанный Х1. Так как А знает открытый ключ Х1 надежным способом, А может получить открытый ключ Х2 из данного сертификата и проверить его с помощью подписи Х1 в сертификате. Затем А возвращается обратно в директорию и получает сертификат В, подписанный Х2. Так как А теперь имеет открытый ключ Х2 надежным способом, А может проверить подпись и безопасно получить открытый ключ В.
Для получения открытого ключа В А использует цепочку сертификатов. В приведенной выше нотации эта цепочка выглядит следующим образом:
Х1 << Х2 >> Х2 << B >>
Аналогично В может получить открытый ключ А с помощью такой же цепочки:
Х2 << Х1 >> Х1 << А >>
Данная схема не обязательно ограничена цепочкой из двух сертификатов. Для получения цепочки может использоваться путь CАs произвольной длины. Цепочка, содержащая N элементов, выглядит следующим образом:
Х1 << Х2 >> Х2 << Х3 >> . . . ХN << B >>
В этом случае каждая пара САs в цепочке (Хi , Хi+1) должна создать сертификаты друг для друга.
Все эти сертификаты CAs необходимо разместить в директории, и пользователи должны иметь информацию о том, как они связаны друг с другом, чтобы получить путь к сертификату открытого ключа другого пользователя. Это определяет Инфраструктуру Открытого Ключа, изучению которой и посвящены следующие лекции.

Абстрактные классы объектов


Абстрактный (Abstract) класс объекта, как следует из его названия, предоставляет основу для характеристик, с помощью которой другие классы объектов могут быть определены как наследуемые. Запись не может принадлежать абстрактному классу объекта, если она не принадлежит структурному или вспомогательному классу, который наследуется от данного абстрактного класса.

Абстрактные классы объектов не могут происходить от структурных или вспомогательных классов объектов.

Все структурные классы объектов получены (прямо или косвенно) от top абстрактного класса объекта. Вспомогательные классы объектов необязательно получены от top.



Административная и функциональная информация Каталога


Рассмотрим некоторые аспекты Административной и Функциональной Информационной модели LDAP. Некоторые реализации LDAP могут поддерживать и другие аспекты данной модели.



Aliases


Записи аliases имеют следующие свойства:

Используются для ссылки одной записи на другую. Позволяют иметь структуру, которая не является иерархической. Аналогичны использованию символьных ссылок в файловой системе UNIX. Не все серверы LDAP поддерживают aliases. Создаются с помощью: записи с классом объекта alias'а; атрибут, называемый aliasedObjectName, который указывает на DN alias'а.



Атрибут objectClass


Каждая запись имеет атрибут objectClass. Атрибут objectClass определяет классы объекта записи, которые (наравне с другой информацией) используются вместе со схемой пользователя и системы для определения разрешенных атрибутов записи. Значения данного атрибута могут модифицироваться клиентами, но атрибут objectClass не может быть удален.



Атрибуты


Атрибут состоит из описания атрибута и одного или более значений данного атрибута.

Attribute ::= SEQUENCE { type AttributeDescription, vals SET OF AttributeValue }

Каждое значение атрибута должно быть уникальным, т.е. дублирование не допускается. Присваивание атрибутам значений не приводит к упорядоченности этих значений.



Атрибуты функционирования


Атрибуты функционирования имеют следующие характеристики:

Атрибуты используются сервером и пользователю обычно недоступны. Множество атрибутов функционирования зависит от разработчиков Каталога. Обычно это отметки времени, управление доступом сервера, административная информация, дата последнего изменения и т.д.



Что такое LDAP


LDAP (Lightweight Directory Access Protocol) – это протокол, который используется для доступа к информации, хранящейся на распределенных в сети серверах.

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

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

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

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

Запись идентифицируется глобально уникальным именем (Distinguished Name – DN) – подобно имени домена в структуре DNS.

Каталог является специализированной базой данных, которая может использоваться в повседневной жизни – телефонная книга, программа передач и т.п. Предполагается, что данные Каталога достаточно статичны. Классическим примером подобной специализированной базы данных является сервис DNS.



Функциональные атрибуты


Некоторые атрибуты, называемые функциональными, используются или поддерживаются серверами для административных и функциональных целей.

К функциональным относятся атрибуты, поддерживаемые сервером (например, createTimeStamp), а также функциональные атрибуты, которые хранят значения, администрируемые пользователем (например, ditContentRules).

Функциональные атрибуты обычно невидимы. Они не возвращаются в качестве результатов поиска, если явно не запрошены по имени.

Записи могут содержать, помимо прочего, следующие функциональные атрибуты.

creatorsName: DN пользователя, добавившего данную запись в Каталог. createTimestamp: время, когда данная запись была добавлена в Каталог. modifiersName: DN пользователя, который последним модифицировал данную запись. modifiersTimestamp: время, когда данная запись была последний раз изменена.

Серверы должны поддерживать creatorsName, createTimestamp, modifiersName и modifiersTimestamp для всех записей в DIT.



Информационная модель


Рассмотрим информационную модель Каталога LDAP.

Каталог, как определено в стандарте Х.500, есть набор открытых систем, взаимодействующих для предоставления сервисов Каталога. Информация, хранящаяся в Каталоге, называется Информационной Базой Каталога (Directory Information Base – DIB). Пользователь Каталога, который может быть как человеком, так и машиной, получает доступ к Каталогу посредством клиента. Клиент от имени пользователя Каталога взаимодействует с одним или более серверами. Сервер хранит фрагмент DIB.

DIB содержит два типа информации:

Пользовательская информация – информация, предоставляемая пользователям и, быть может, изменяемая ими. Административная и функциональная информация – информация, используемая для администрирования и/или функционирования Каталога.

Функция Каталога состоит в том, чтобы хранить информацию об объектах и предоставлять к ней доступ. Объектом может быть все, что может быть идентифицировано (поименовано).

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

Запись Каталога – это поименованный набор информации. Она является основной единицей информации, хранящейся в Каталоге. Существует несколько видов записей Каталога.

Запись объекта представляет конкретный объект. Запись alias обеспечивает альтернативное именование того же самого объекта.

Множество записей, представленных в DIT, организовано иерархически в структуру дерева, известную как Информационное Дерево Каталога – Directory Information Tree (DIT).

Сначала мы рассмотрим DIT, затем обсудим именование записей, структуру записей, классы объектов, описания атрибутов и записи alias’ов.



Информационное дерево Каталога


DIB является композицией множества записей, организованных иерархически в структуру дерева, известную как информационное дерево Каталога (Directory Information Tree – DIT). Вершинами дерева являются записи.

Дуги между вершинами определяют отношения между записями. Если существует дуга от Х к Y, то запись Х является родителем Y, и Y непосредственно подчиняется Х. Вышестоящими записями являются записи непосредственного родителя и его родителей. Подчиненными записями являются все записи, непосредственно подчиненные данной, и все их подчиненные.

В данном случае dc=msu и cn=oit – примеры записей. Запись dc=msu является родителем для записи dc=cmc, запись dc=cmc является подчиненной для записи dc=msu.


Рис. 14.1.  Пример дерева Каталога



История LDAP


CCITT (Consultative Committee for International Telegraphy and Telephony) разработал серию рекомендаций для создания так называемого сервиса Директории или Каталога. Каталог является сервером или распределенным набором серверов, которые поддерживают распределенную базу данных, содержащую информации о различных субъектах, таких как пользователи, устройства и т.п. Эта распределенная база данных называется Информационной Базой Каталога (Directory Information Base – DIB). Информация включает имя субъекта, а также различные атрибуты, характеризующие этот субъект. Данные рекомендации носят название стандарта Х.500. Первоначально LDAP начал развиваться как программный продукт переднего плана (front end) для Каталога Х.500.

LDAP предоставляет большинство возможностей Х.500 при существенно меньшей стоимости реализации. Например, удалены избыточные и редко используемые операции. LDAP, в отличие от Х.500, использует стек ТСР, а не OSI.

Следует заметить, что базовые операции протокола могут быть отображены на подмножество сервисов Каталога Х.500. Однако не существует отображения один-к-одному между операциями протокола LDAP и операциями протокола DAP (Directory Access Protocol) стандарта Х.500.

Первая реализация LDAP написана в Мичиганском университете. Большинство ранних реализаций LDAP основано на ней.



Класс объекта


Класс объекта есть идентифицированное семейство объектов, которые имеют общие характеристики.

Основные свойства классов объектов:

Классы используются для группирования информации.

Классы обеспечивают следующие возможности: определяют необходимые атрибуты; определяют допустимые атрибуты; обеспечивают легкий способ группирования информации. Записи могут иметь несколько классов объектов. Необходимые и допустимые атрибуты при этом являются объединением атрибутов каждого класса. Классы также предназначены для управления функционированием Каталога.

Класс объекта (подкласс) может быть получен из другого класса объекта (суперкласса), который в свою очередь может быть получен из более общего класса объекта. Для структурных классов объектов данный процесс завершается на самом общем классе объекта, называемом top. Упорядоченное множество суперклассов от наиболее общего класса объекта до данного класса объекта называется цепочкой суперклассов.

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

Каждый класс объекта определяется как один из трех видов классов объектов: Abstract, Structural или Auxiliary.

Каждый класс объекта идентифицируется своим идентификатором объекта (OID) и (необязательно) одним или более короткими именами (дескрипторами).



Класс объекта "extensibleObject"


Вспомогательный класс объекта extensibleObject позволяет записям иметь любой тип атрибута. Множество допустимых атрибутов данного класса неявно является множеством всех пользовательских атрибутов.

Обязательные атрибуты других классов объектов данной записи также должны присутствовать, а запрещенные атрибуты присутствовать не должны.

Заметим, что не все серверы реализуют данный класс объекта, но и не все отвергают запросы на добавление записей, которые содержат данный класс объекта, или на модификацию записи по добавлению данного класса объекта.



Контекст корневого именования и данные сервера


Контекст корневого именования является записью верхнего уровня для серверов. Некоторые серверы могут иметь несколько контекстов корневого именования.

Сервер LDAP должен предоставлять информацию о самом себе, а также информацию, специфичную для каждого сервера. Это представлено как группа атрибутов, размещенная в корневом DSE (DSA-специфичная запись), которая поименована LDAPDN нулевой длины. Эти атрибуты восстанавливаемы, являются предметом управления доступа и различных ограничений, если клиент выполнил поиск базового объекта для корня с фильтром (objectClass=*), запрашивая возвращаемые атрибуты. Следует заметить, что корневые атрибуты DSE являются функциональными, и, подобно другим функциональным атрибутам, не возвращаются для запросов поиска, пока не будут запрошены по имени.

Корневой DSE не должен включаться, если клиент выполнил поиск по поддереву, начиная с корня.

Серверы могут позволять клиентам модифицировать соответствующие атрибуты корневого DSE.

Определены следующие атрибуты корневого DSE.

altServer: атрибут перечисляет URLs, указывающие на альтернативные серверы, с которыми можно соединяться, когда данный сервер недоступен. Если сервер не знает никаких других серверов, которые можно использовать, данный атрибут должен отсутствовать. Клиенты могут кэшировать данную информацию в случае, если их сервер в дальнейшем может оказаться недоступным. namingContexts: атрибут перечисляет префиксы контекста сервера. Если сервер является сервером первого уровня, он должен указать пустую строку (корень DIT). Данный атрибут позволяет клиенту выбрать соответствующие базовые объекты для поиска, когда он соединяется с сервером. supportedControl: атрибут перечисляет идентификаторы объектов, определяющие способы управления запросом, поддерживаемые сервером. Если сервер не поддерживает никаких управлений запросом, данный атрибут отсутствует. supportedExtension: атрибут перечисляет идентификаторы объектов, определяющих расширенные операции, поддерживаемые сервером. Если сервер не поддерживает никаких расширенных операций, данный атрибут отсутствует.


Расширенная операция включает в себя ExtendedRequest, возможно, и другие блоки данных, определенные расширением, и ExtendedResponse. supportedLDAPVersion: атрибут перечисляет версии LDAP, которые поддерживает сервер. supportedSASLMechanisms: атрибут перечисляет механизмы SASL, которые распознает сервер. Содержимое данного атрибута может зависеть от текущего состояния сессии. Если сервер не поддерживает никаких механизмов SASL, то данный атрибут не должен присутствовать.

Значения этих атрибутов могут зависеть от конкретной сессии и от других факторов. Например, сервер, поддерживающий механизм SASL EXTERNAL, когда идентификация клиента установлена на нижнем уровне, должен перечислить только EXTERNAL.

Корневой DSE может также включать атрибут subschemaSubentry. Если это так, то он указывает на запись подсхемы, управляющую атрибутами корневого DSE. Клиент не должен предполагать, что запись подсхемы, управляющая корневым DSE, управляет также и любой записью, хранящейся на сервере.


LDAP vs базы данных


Сравним два наиболее популярных на сегодня способа хранения информации, реляционные базы данных и серверы LDAP, по следующим характеристикам:

Соотношение чтение-запись – LDAP, в отличие от реляционных баз данных, оптимизирован для чтения. Расширяемость – схемы LDAP легче изменить в процессе функционирования, чем схемы баз данных. Распределенность – данные LDAP могут располагаться на нескольких серверах, поиск на которых может осуществляться с использованием одной команды. В результате можно создавать конфигурации серверов LDAP, оптимально расположенные в зависимости от того, где требуется та или иная информация, одновременно обеспечивая возможность поиска всей информации, хранящейся на всех серверах LDAP. Тем самым достигается более высокая степень распределенности по сравнению с реляционными базами данных. Репликация – данные LDAP могут храниться на нескольких серверах, при этом существует возможность использования различных способов синхронизации информации. Применение данных – LDAP разработан для возможности использования хранимых данных разными приложениями, базы данных разрабатываются для одного приложения. Сложность взаимосвязей между объектами – объекты баз данных имеют более сложные взаимосвязи, чем записи LDAP. Транзакции – в LDAP транзакции проще, обычно изменяется одна запись, транзакции в базах данных более сложные. Тип хранимой информации – LDAP хранит информацию в атрибутах. Способ именования – LDAP представляет собой иерархию. Имя объекта определяется путем в дереве иерархии, аналогично именованию файлов в обычных файловых системах. Схемы – схемы реляционных баз данных полностью определяются разработчиком соответствующей базы данных, LDAP имеет стандартные схемы, включая схему ядра (core), общую для любого Каталога. Этим достигается большая интероперабельность по сравнению с базами данных. Стандарты – использование стандартных схем хранения информации и стандартного протокола доступа является преимуществом LDAP по сравнению с базами данных, так как в этом случае клиенты LDAP могут общаться с любым сервером LDAP, а клиенты баз данных могут взаимодействовать только с базой данных, для которой они разработаны. Возможность отката при неудачных операциях – реляционные базы данных имеют более гибкие возможности отката, следовательно, они больше подходят для модификации информации, чем LDAP. Для динамических объектов возможностей LDAP недостаточно.



LDIF


LDIF является форматом обмена данными и обладает следующими свойствами:

Представляет записи LDAP в виде текста. Имеет читаемый формат. Обеспечивает возможность легкой модификации данных. Используется для изменений большого количества данных по следующему принципу: – сделать дамп БД, выполнить скрипт, импортировать обратно. обеспечивает возможность архивации данных и передачи данных в другие системы.

Пример LDIF:

dn: uid=olga, ou=people, dc=cmc, dc=msu uid: olga



Модель именования


LDAP определяет иерархическую структуру данных, называемую DIT. Дерево Каталога в чем-то подобно файловой системе. Отличие от файловой системы состоит в следующем:

Каждая запись в LDAP может как содержать данные, так и служить контейнером, т.е. содержать поддерево. В файловой системе каждая запись является либо файлом, либо Каталогом, но не тем и другим одновременно. Уникальные имена LDAP читаются от данной точки к корневой точке, в файловой системе наоборот, от корневой точки к данной.



Модели LDAP


Основными моделями LDAP, которые определяют характеристики сервиса, являются:

Информационная модель – определяет типы данных, хранящихся в Каталоге, их взаимосвязи и способы обращения к ним (именование). Функциональная модель – определяет операции в протоколе LDAP. Модель безопасности – определяет способы и методы защиты хранящейся в Каталоге информации. Распределенное множество серверов LDAP – определяет способы взаимодействия серверов LDAP и возможность поиска информации на нескольких серверах LDAP.



Наследование классов объектов


Наследование классов объектов обладает следующими свойствами:

Классы объектов могут быть получены из других классов объектов. В случае наследования происходит расширение атрибутов из других классов объектов. Для структурных и абстрактных классов множественного наследования нет. Для классов объектов нельзя перекрывать правила. Существует специальный класс, называемый top – все структурные и абстрактные классы являются его расширением. Для данного класса необходимым атрибутом является только objectClass. Это гарантирует, что все записи имеют атрибут objectClass.



Опции атрибутов


Спецификация LDAP определяет один вид опций атрибутов: тегированные опции. Атрибуты, хранящиеся в Каталоге, могут иметь описания атрибутов с любым числом тегированных опций.

Описание атрибута с N тегированными опциями считается непосредственным подтипом всех описаний атрибута того же самого типа атрибута. Если тип атрибута имеет супертип, то описание атрибута также считается непосредственным подтипом (описания) атрибута супертипа и N тегированных опций. Это означает, что cn; lang-de; lang-en считается непосредственным подтипом cn; lang-de и cn; lang-en и name; lang-de; lang-en (cn является подтипом name).



Описания атрибута


Описание атрибута состоит из типа атрибута и множества из нуля или более опций атрибута.

attributedescription = attributetype options attributetype = oid options = *( SEMI option ) option = 1*keychar

где <attributetype> определяет тип атрибута, и каждая <option> определяет опцию атрибута. И <attributetype>, и <option> нечувствительны к регистру. Порядок, в котором появляются <option>s, несущественен. Это означает, что любые два <attributedescription>s, которые состоят из одного и того же <attributetype> и одного и того же множества <option>s, являются эквивалентными.

Примеры допустимых описаний атрибутов:

2.5.4.0 cn;lang-de;lang-en owner

Все атрибуты записи должны иметь различные описания атрибутов.



Относительные уникальные имена


Каждая запись поименована относительно своей непосредственной вышестоящей записи. Данное относительное имя, известное как ее Relative Distinguished Name (RDN) является композицией неупорядоченного множества одного или более выражений значений атрибутов – attribute value assertions (AVA) – состоящих из описания атрибута и его значения. Эти AVAs выбраны из атрибутов записи.

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

Приведем примеры RDNs:

UID=12345 OU=Engineering CN=Kurt Zeilenga+L=Redwood Shores

Последний вариант является примером RDN с несколькими значениями. Это означает, что RDN составлено из нескольких AVAs.

Принципы именования следующие:

Все записи должны иметь имена. Имена не должны допускать конфликтов, т.е. все потомки некоторого родителя должны иметь уникальные имена (желательно, чтобы имена были информативными, хотя, естественно, понятие информативности является неформальным, и стандартом не определяется).



Полные уникальные имена


Полное имя записи, известное как Distinguished Name (DN), является конкатенацией ее RDN и DN ее родителя. DN уникально определяет запись в дереве.

Приведем примеры DNs:

UID=nobody@example.com, DC=example,DC=com cn=oit,ou=laboratories, dc=cmc,dc=msu,c=ru

В LDAPv3 для представления уникального имени (DN) используется строка UTF-8.

Построение начинается с последнего элемента путем присоединения с помощью запятой каждого следующего уровня.

Уникальные имена имеют две части.

Левая часть называется относительным уникальным именем (RDN). Оставшаяся часть является базовым уникальным именем.

В приведенном выше примере RDN есть cn=oit.

Базовое уникальное имя есть ou=laboratories,dc=cmc,c=msu.

Для каждого базового DN каждый RDN является уникальным. Это гарантирует, что никакие две записи не имеют один и тот же DN.



Правила содержимого DIT


Правило содержимого DIT есть правило управления содержимым записей конкретного структурного класса объекта.

Для записей DIT конкретного структурного класса объекта правило содержимого DIT определяет, какие вспомогательные классы объектов для записей допустимы и какие дополнительные атрибуты (по типу) требуются, допустимы или недопустимы в записях.

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

Каждое правило содержимого идентифицируется OID, а также любыми короткими именами (дескрипторами) структурного класса объекта, к которому оно применено.

Запись может принадлежать только вспомогательным классам объектов, перечисленным в правиле управления содержимым.

Запись должна содержать все атрибуты, необходимые классам объектов, которым принадлежит запись, а также все атрибуты, которых требует правило управления содержимым.

Запись может содержать любые незапрещенные атрибуты, допустимые классами объектов, которым принадлежит запись, а также все атрибуты, допустимые правилом управления содержимым.

Запись не может включать никакие атрибуты, запрещенные правилом управления содержимым.

Запись управляется (если присутствует и активна в подсхеме) правилом содержимого DIT, которое применяется к структурному классу объекта записи. Если неактивное правило присутствует для структурного класса объекта записи, содержимое записи управляется структурным классом объекта (и, возможно, другими аспектами схемы пользователя и системы).



Правила соответствия


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

Далее будут рассмотрены правила соответствия, необходимые для операции Каталога, или те, которые требуются для общего использования.

Правило соответствия применяется к значениям атрибута посредством AttributeValueAssertion или MatchingRuleAssertion. Могут существовать определенные условия, при которых AttributeValueAssertion или MatchingRuleAssertion вычисляются как Undefined. Если утверждение не является Undefined, то результат утверждения есть результат применения выбранного правила соответствия. Правило соответствия вычисляется в TRUE и в некоторых случаях Undefined, как определено в описании правила соответствия, в противном случае оно вычисляется в FALSE.

Каждое утверждение имеет определенное значение. Определение каждого правила соответствия специфицирует синтаксис для значения утверждения. Синтаксис значения утверждения обычно, но не обязательно, бывает тот же, что и синтаксис значений атрибутов, к которым правило соответствия может применяться.

Определение каждого правила соответствия указывает синтаксисы атрибутов, к которым правило применяется, и условия, которым должны удовлетворять соответствующие типы атрибута.

Описание каждого правила соответствия указывает, применимо ли правило в качестве правила эквивалентности (EQUALITY), правила упорядоченности (ORDERING) или правила подстрок (SUBSTR) в определении типа атрибута.

Каждое правило соответствия уникально определяется идентификатором объекта. Определение правила соответствия в дальнейшем не должно изменяться. Если изменение все же необходимо, то определяется новое правило соответствия с другим идентификатором объекта.

Серверы, которые реализуют extensibleMatch-фильтр, должны допускать использование перечисленных здесь правил соответствия в extensibleMatch-фильтре и применение правил соответствия со всеми известными серверу типами атрибутов, в которых синтаксис утверждения для правила соответствия является тем же самым, что и синтаксис значения атрибута.

Серверы должны публиковать в атрибуте matchingRules определения правил соответствия, ссылаясь на значения атрибутов attributeTypes и matchingRuleUse в той же записи подсхемы. Могут быть опубликованы и другие правила соответствия в атрибуте matchingRules.

Если сервер поддерживает extensibleMatch-фильтр, сервер может использовать атрибут matchingRuleUse для указания применимости (в extensibleMatch фильтре) выбранных правил соответствия к упомянутым типам атрибутов.



Правила структуры DIT и формы имени


Следует определить, где записи объекта могут размещаться в DIT и как они могут именоваться, основываясь на структурном классе объекта.

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

Форма имени специфицирует допустимые RDN для записей конкретного структурного класса объекта. Форма имени идентифицирует именованный класс объекта и один или более типов атрибута, используемых для именования. Формы имени являются элементарными частями спецификации, используемой в определении правил структуры DIT.

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

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

Каждая форма имени идентифицируется OID и (необязательно) одним или более короткими именами (дескрипторами).



Правило присваивания значения атрибута


Определение типа AttrubuteValueAssertion содержит описание атрибута и соответствующее правило присваивания значения для данного типа.

AttributeValueAssertion ::= SEQUENCE { attributeDesc AttributeDescription, assertionValue AssertionValue } AssertionValue ::= OCTET STRING

Синтаксис AssertionValue зависит от контекста выполняемой операции LDAP. Например, синтаксис EQUALITY, соответствующий правилу для атрибута, используемого при выполнении операции Compare. Часто тот же самый синтаксис используется для значений типов атрибутов, но в некоторых случаях синтаксис присваивания отличается от синтаксиса значения.



Преимущества LDAP


Основные причины роста популярности LDAP связаны с тем, что:

LDAP имеет стандартную схему хранения информации в отличие от реляционных баз данных, когда в каждом случае определяется своя схема хранения в терминах таблиц и столбцов. Поэтому в LDAP нет специфичного для каждого Каталога и для каждого приложения управления – нет так называемой "проблемы N+1 Каталога". Для всех серверов LDAP используется единая схема хранения, единый способ именования хранимых объектов и единый протокол доступа. LDAP позволяет быстро отыскивать необходимые данные, поскольку ориентирован в большей степени на чтение и поиск информации, чем на модификацию. LDAP не обязательно должен быть ограничен конкретным сервером, есть возможность организовывать распределенные системы из нескольких серверов. В LDAP предусмотрена возможность создавать ссылки между различными серверами LDAP, что обеспечивает возможность поиска сразу на нескольких серверах LDAP. Как протокол LDAP, так и структура Каталога LDAP организованы в соответствии со стандартами, в результате чего можно единообразно использовать реализации LDAP различных производителей. Еще одно важное назначение LDAP – хранение всей информации, относящейся к PKI, а именно сертификатов, CRL и т.п.



Принципы развертывания серверов LDAP


При развертывании серверов LDAP необходимо выполнить следующие задачи:

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



Распределенное множество серверов LDAP


Протокол LDAP предполагает, что существует один или несколько серверов, которые сообща предоставляют доступ к Информационному Дереву Каталога (DIT).



Расширение схемы


Расширение схем выполняется в определенной последовательности:

Получить идентификатор объекта (OID). Выбрать префикс имени. Создать файл локальной схемы. Определить типы атрибутов пользователя (если необходимо). Определить классы объектов пользователя.



Разработка топологии


Дерево Каталога может быть распределено по нескольким физическим серверам.

При определении топологии важно учитывать:

Возрастание выполнения. Возрастание доступности. Лучшее управление Каталогом. Возможность хранения большего числа записей, чем на одном сервере.

При использовании подобной топологии пользователи видят один большой Каталог, а каждому серверу делегируется некоторая его часть.

Данная структура во многом аналогична DNS.



Referrals


Сервер LDAP может содержать ссылки (referral) на другие серверы LDAP. Эти ссылки используются в операциях поиска, что обеспечивает клиенту возможность получения информации от нескольких серверов.

Клиент запрашивает информацию. Сервер 1 возвращает referral на сервер 2. Клиент повторно посылает запрос на сервер 2. Сервер 2 возвращает информацию клиенту.

Код результата поиска referral указывает, что сервер, с которым осуществляется соединение, не содержит целевой записи для запроса. Поле referral представлено в LDAPResult, если значение поля LDAPResult.resultCode есть referral, и отсутствует с остальными кодами результата. Оно содержит одну или более ссылок на один или более серверов или сервисов, которые могут быть доступны посредством LDAP или других протоколов. Referrals могут быть возвращены в ответе для любого запроса операции (исключая unbind и abandon, которые не имеют ответа). По крайней мере, один URL должен быть представлен в Referral.

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

Referral ::= SEQUENCE OF LDAPURL -- один или более LDAPURL ::= LDAPString /* ограничено символами, которые допустимы в URLs */

Если клиент продолжает выполнение операции, он должен следовать по referral для соединения с серверами. Если присутствует несколько URLs, клиент предполагает, что для дальнейшего выполнения операции может использоваться любой URL.

URLs для серверов, реализующих протокол LDAP, написаны в соответствии с определением DN. Если на alias ссылок нет, то часть <dn> URL должна присутствовать с новым именем целевого объекта. Если часть <dn> присутствует, клиент должен использовать данное имя в своих следующих запросах для продолжения операции, и если оно не представлено, клиент будет задействовать то же самое имя, что и в начальном запросе.


Некоторые серверы (например, участвующие в распределенном индексировании) могут предоставить различные фильтры в referral для операции поиска. Если часть фильтра в URL присутствует в LDAPURL, клиент должен использовать этот фильтр в своем следующем запросе при продолжении поиска, и если он не присутствует, клиент должен применять тот же фильтр, что использовал для данного запроса. Другие аспекты нового запроса могут быть теми же самыми или отличаться от запроса, в котором был создан referral.


Рис. 14.2.  Каждый сервер должен содержать определенное поддерево


Рис. 14.3.  Поиск с использованием Referrals


Заметим, что символы UTF-8, появляющиеся в DN или фильтре поиска, могут быть не разрешены для URLs (например, пробелы) и должны быть вырезаны с использованием метода, определенного для преобразования URLs.


Репликация


Репликация является методом, обеспечивающим хранение копии данных Каталога на нескольких серверах.

При использовании репликации происходит увеличение:

Надежности – если с одной копией что-то случилось. Доступности – легче найти доступный сервер. Выполнения – можно использовать ближайший сервер. Скорости – можно сделать больше запросов в качестве добавленных репликаций.

При использовании репликации может появиться временная несогласованность, но при этом уничтожается единственная точка сбоя.



Схема


Схема Каталога обладает следующими свойствами:

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

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

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

Таким образом, Схема обеспечивает следующие возможности Каталога:

Предотвращение создания подчиненных записей от неправильного класса объекта (например, country как подчиненная person). Предотвращение добавления типов атрибута к записи, не соответствующей классу объекта (например, serial number к записи person). Предотвращение добавления значения атрибута, синтаксис которого не соответствует тому, который определен для типа атрибута (например, printable string к bit string).

Формально Схема Каталога состоит из множества:

Определений форм имени, которые характеризуют взаимоотношения именования для структурных классов объектов. Определений Правил Структуры DIT, описывающих имена, которые могут иметь записи, и способы взаимоотношений записей в DIT. Определений Правил Содержания DIT, которые расширяют спецификацию возможных принадлежащих записям атрибутов указанием структурных классов объектов для записей. Определений Классов Объектов, описывающих базовое множество обязательных и необязательных атрибутов, которые должны и могут присутствовать в записи данного класса, и которые указывают род определяемого класса объекта. Определений Типов Атрибутов, указывающих идентификатор объекта для атрибута, его синтаксис, связанные с ним правила соответствия, является он функциональным или пользовательским атрибутом, может ли он иметь несколько значений и происходит ли от другого атрибута. Определений Правил Соответствия. Определений синтаксиса LDAP, которые определяют правила представления, используемые в LDAP.



в Каталоге LDAP, имеет определенный


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

Структурные классы объектов


Каждый структурный класс (Structural) объекта является (прямым или косвенным) подклассом top абстрактного класса объекта.

Структурные классы объектов не могут быть подклассом вспомогательных классов объектов.

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



Типы атрибутов


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

Тип атрибута указывает, является атрибут пользовательским или функциональным. Если атрибут является функциональным, тип атрибута определяет его функциональное использование и указывает, может ли данный атрибут модифицироваться пользователем.

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

Каждый тип атрибута определяется идентификатором объекта (OID) и (необязательно) одним или более короткими именами (дескрипторами).



Вспомогательные классы объектов


Вспомогательные классы (Auxiliary) объектов используются как дополнение характеристик записей. Обычно они применяются для расширения множества необходимых и допустимых атрибутов записи, а также могут использоваться для описания записей или классов записей.

Вспомогательные классы объектов не могут быть подклассом структурных классов объектов.

Запись может принадлежать любому подмножеству множества вспомогательных классов объектов.

Множество вспомогательных классов объектов, которым принадлежит запись, может со временем изменяться.



Запись LDAP


Основные свойства записи:

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

Запись состоит из множества атрибутов, хранящих информацию об объекте. Некоторые атрибуты хранят пользовательскую информацию и называются пользовательскими атрибутами. Другие атрибуты хранят функциональную и/или административную информацию и называются функциональными атрибутами.

Атрибут состоит из описания атрибута (тип атрибута и ноль или более опций) и одного или более связанных с ним значений. На атрибут часто ссылаются с помощью его описания. Например, атрибут givenName является атрибутом, состоящим из описания атрибута givenName (тип атрибута givenName и ноль опций) и одного или более связанных с ним значений.

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

Два значения считаются эквивалентными, если эквивалентность выполняется в соответствии с правилами эквивалентности данного типа атрибута. Если тип атрибута определяется без правила эквивалентности, два значения являются эквивалентными тогда и только тогда, когда они идентичны.

Например, атрибут givenName может иметь более одного значения, эти значения должны быть Directory Strings и они нечувствительны к регистру. Поэтому атрибут givenName не может иметь одновременно значения John и JOHN, так как согласно правилу эквивалентности данного типа атрибута это эквивалентные значения.



Записи подсхемы


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

Серверы должны предоставлять атрибуты createTimestamp и modifyTimestamp в записях подсхемы, чтобы разрешить клиентам поддерживать кэши информации схемы.

Далее перечислены описания типов атрибутов для каждого типа атрибута определения схемы.

objectClasses – атрибут содержит определения классов объекта. attributeTypes – атрибут содержит определения типов атрибутов. matchingRules – атрибут содержит определения правил соответствия. matchingRuleUse – атрибут содержит определения используемых правил соответствия. ldapSyntaxes – атрибут содержит определения синтаксисов LDAP. dITContentRules – атрибут перечисляет применяемые правила содержимого DIT. dItStructureRules – атрибут перечисляет применяемые правила структуры DIT. nameForms – атрибут перечисляет используемые формы имени.



Значение атрибута


Значения атрибута соответствуют синтаксису, определенному для атрибута.

Когда атрибут используется для именования записи, одно и только одно значение выбранного атрибута присутствует в RDN. Это значение определяется как уникальное.

Поле типа AttributeValue является OCTET STRING, содержащей тип данных значения атрибута. Значение представлено в соответствии с определением представления для LDAP. Определение представления для LDAP для различных синтаксисов и атрибутов определяется при определении Синтаксиса.

AttributeValue ::= OCTET STRING

Заметим, что ограничение на размер данного представления не определено; таким образом, значения могут включать мегабайтные атрибуты (например, фотографии).

Атрибуты могут быть определены как имеющие произвольный и непечатный синтаксис. Реализации не должны показывать или пытаться представить как ASN.1 значение, если его синтаксис неизвестен. Реализация может попытаться восстановить подсхему исходного участника или восстановить из него значения attributeTypes.

Таким образом, атрибуты имеют:

Имя – уникальный идентификатор, нечувcтвительный к регистру. Идентификатор объекта (OID) – последовательность целых, разделенных точками.

Синтаксис атрибута, который определяет:

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

Примеры имен атрибутов:

uid – User id

cn – Common Name

sn – Surname

l – Location

ou – Организационная единица

o – Организация

dc – Domain Component

st – Штат

c – Страна