Пример 11.2. Структура инода файловой системы ext2fs 3 страница

Сессии в Unix
Например, в системах семейства Unix пользователь идентифицируется целочисленным значением uid (user identifier). С каждой задачей (процессом) связано два идентификатора пользователя: реальный и эффективный. В большинстве случаев эти идентификаторы совпадают (ситуации, когда они не совпадают, подробно обсуждаются в разд. Изменение идентификатора пользователя). Таким образом, каждая задача обязательно исполняется от имени того или иного пользователя, имеющего учетную запись в системе.
Пользователь может иметь также символьное имя. В старых Unix системах соответствие между символьным и числовым идентификаторами устанавливалось на основе содержимого текстового файла /etc/passwd. Каждая строка этого файла описывает одного пользователя и состоит из семнадцати полей, разделенных символом ':'. В первом поле содержится символьное имя пользователя, во втором — числовой идентификатор в десятичной записи. Остальные поля содержат другие сведения о пользователе, например, его полное имя.
Пользовательские программы могут устанавливать соответствие между числовым и символьным идентификаторами самостоятельно, путем просмотра файла /etc/passwd, или использовать библиотечные функции, определенные стандартом POSIX. Во многих реализациях эти функции используют вместо /etc/passwd индексированную базу данных, а сам файл /etc/passwd сохраняется лишь для совместимости со старыми программами.
В современных системах семейства Unix библиотеки работы со списком пользователей имеют модульную архитектуру и могут использовать различные, в том числе и распределенные по сети базы данных. Интерфейс модуля работы с конкретным типом БД называется РАМ (Person Autentification Module -модуль аутентификации людей) (рис. 12.1).
Нужно отметить, что соответствие между символьным и числовым идентификаторами в Unix не является взаимно однозначным. Одному и тому же числовому идентификатору может соответствовать несколько имен. Кроме того, в Unix разрешено создать объекты с числовым uid, которому не соответствует никакое символьное имя.

Рис. 12.1. РАМ и различные базы учетных записей

Большинство современных ОС позволяют также запускать задания без входа систему и создания сессии. Так, практически все системы разделения времени (Unix, VMS, MVS-OS/390-z/OS) предоставляют возможность пользователям запускать задачи в заданные моменты астрономического времени периодически, например, в час ночи в пятницу каждой недели. Каждая такая задача исполняется от имени определенного пользователя — того, кто запросил запуск задачи. Для управления правами доступа в таких ситуациях идентификатор пользователя ассоциируется не с сессией, а с отдельными заданиями, а обычно даже с отдельными задачами. В Windows NT/2000/XP задачи, которые могут запускаться и работать без входа пользователя в систему, называются сервисами. По умолчанию, сервисы запускаются от имени специального [псевдо|пользователя System, но в свойствах сервиса можно указать, от чьего имени он будет запускаться. Кроме того, некоторые комплектации системы (Terminal Server Edition, Citrix ICA) допускают одновременную интерактивную работу нескольких пользователей. Чтобы обеспечить разделение доступа во всех этих случаях, каждый процесс в системе имеет контекст доступа (security context), соответствующий той или иной учетной записи.

Аутентификация

Петли дверные Многим скрипят, многим поют: "Кто вы такие, Вас здесь не ждут!" В. Высоцкий

Понятно, что если права доступа выделяются на основе машинного идентификатора пользователя, то возникает отдельная проблема установления соответствия между этим машинным идентификатором и реальным человеком. Такое соответствие не обязано быть взаимно однозначным: один человек может иметь несколько идентификаторов или наоборот, несколько человек могут пользоваться одним идентификатором. Тем не менее, способ установления такого соответствия необходим.
По-английски процесс входа в систему называется login (log in) и происходит от слова log, которое обозначает регистрационный журнал или процесс записи в такой журнал. В обычном английском языке такого слова нет, но в компьютерной лексике слова login и logout прижились очень прочно.
Наиболее точным переводом слова login является регистрация. Соответственно, процесс выхода называется logout. Его точная русскоязычная калька — разрегистрация — к сожалению, очень неблагозвучна.
Теоретически можно придумать много разных способов идентификации, например, с использованием механических или электронных ключей или даже тех или иных биологических параметров, например, рисунка глазного дна. Однако подобные способы требуют специальной и зачастую довольно дорогой аппаратуры. Наиболее широкое распространение получил более простой метод, основанный на символьных паролях.
Пароль представляет собой последовательность символов. Предполагается, что пользователь запоминает ее и никому не сообщает. Этот метод хорош тем, что для его применения не нужно никакого дополнительного оборудования — только клавиатура, которая может использоваться и для других целей. Но этот метод имеет и ряд недостатков.
Использование паролей основано на следующих трех предположениях:

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

Последнее предположение кажется разумным: если человек может добровольно кому-то сообщить свой пароль, с примерно той же вероятностью этот человек может сам сделать пакость. Впрочем, человека можно заставить "выдать" пароль. Однако зашита от таких ситуаций требует мер, которые не могут быть обеспечены на уровне операционной системы.
Если вдуматься, первые два требования отчасти противоречат друг другу. Количество легко запоминаемых паролей ограничено и перебрать все такие пароли оказывается не так уж сложно. Этот вид атаки на систему безопасности известен как словарная атака (dictionary attack) и при небрежном отношении пользователей к выбору паролей и в ряде других ситуаций, которые будут обсуждаться далее, представляет большую опасность.

Словарная атака в исполнении червя Морриса
Возможности словарной атаки впервые были продемонстрированы в 1987 году молодым тогда студентом Робертом Моррисом [КомпьютерПресс 1991]. Разработанная им программа — "червь Морриса" — использовала словарную атаку и последующий вход в систему с подобранным паролем как один из основных способов размножения. Червь использовал для распространения и другие приемы, продемонстрировавшие не только специфические изъяны тогдашних ОС семейства Unix, но и несколько фундаментальных проблем компьютерной безопасности, поэтому мы еще несколько раз будем возвращаться к обсуждению этой программы.

Червь Морриса использовал при подборе паролей следующие варианты:

• входное имя пользователя;
• входное имя с символами в обратном порядке — "задом наперед";
• компоненты полного имени пользователя — имя (first name), фамилию (last name) и другие элементы, если они есть;
• те же компоненты, но задом наперед;
• слова из заранее определенной таблицы, содержащей 400 элементов.

Большая часть успешно подобранных паролей была взята из таблицы. После поимки червя таблица была опубликована с тем, чтобы пользователи не повторяли старых ошибок. Эта таблица приводится в [КомпьютерПресс 1991]. По мнению автора, включение ее в данное издание нецелесообразно, поскольку она рассчитана на англоязычных пользователей и не очень актуальна в России.

С первого взгляда видно, что таких "легко запоминаемых" вариантов довольно много — никак не меньше нескольких сотен. Набор их вручную занял бы очень много времени, но для компьютера несколько сотен вариантов — это доли секунды. Первый слой защиты от подбора пароля заключается именно в том, чтобы увеличить время подбора. Обнаружив неправильный пароль, наученные горьким опытом современные системы делают паузу, прежде чем позволят повторную попытку входа с того же терминального устройства. Такая пауза может длиться всего одну секунду, но даже этого достаточно, чтобы увеличить время подбора пароля от долей секунды до десятков минут.
Второй слой зашиты заключается в том, чтобы усложнить пароль и тем самым увеличить количество вариантов. Даже очень простые усложнения сильно увеличивают перебор. Так, простое требование использовать в пароле буквы и верхнего, и нижнего регистров увеличивает перебор в 2ⁿ раз где n — длина пароля. В большинстве современных систем пароль обязан иметь длину не менее шести символов, т. е. количество вариантов увеличивается в 64 раза. Требование использовать в пароле хотя бы один символ, не являющийся буквой, увеличивает число вариантов в 6x43 = 258 раз (в наборе ASCII 43 небуквенных графических символа). Вместо десятков минут подбор пароля, который содержит буквы разных регистров и хотя бы один спецсимвол, займет много дней.
Но если взломщику действительно нужно попасть в систему, он может подождать и несколько дней, поэтому необходим третий слой защиты — ограничение числа попыток. Все современные системы позволяют задать число неудачно набранных паролей, после которого имя блокируется. Это число всегда больше единицы, потому что пользователь — это человек, а людям свойственно ошибаться, но в большинстве случаев такой предел задается не очень большим — обычно 5—7 попыток. Однако, этот метод имеет и оборотную сторону — его можно использовать для блокировки пользователей.
Интересный вариант того же метода заключается в увеличении паузы между последовательными неудачными попытками хотя бы в арифметической прогрессии.
Наконец, последний слой защиты — это оповещение пользователя (а иногда и администратора системы) о неудачных попытках входа. Если пользователь сам только что нажал не ту кнопку, он при входе увидит, что была одна неудачная попытка, и не будет волноваться; однако, если есть сообщения о дополнительных неудачных попытках, время побеспокоиться и разобраться, что же происходит.
Современная техника выбора паролей обеспечивает достаточно высокую для большинства практических целей безопасность. В тех случаях, когда эта безопасность представляется недостаточной — например, если следует всерьез рассматривать опасность принуждения пользователя к раскрытию пароля — можно применять альтернативные методы идентификации, перечисленные ранее, т. е. основанные на механических или электронных ключах или биометрических параметрах. Впрочем, как уже говорилось, такие методы требуют применения специальной аппаратуры.
При использовании паролей возникает отдельная проблема безопасного хранения базы данных со значениями паролей. Как правило, даже администратор системы не может непосредственно получить значения паролей пользователей. Можно привести несколько соображений в пользу такого ограничения.

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

Для обеспечения секретности паролей обычно используют одностороннее шифрование, или хэширование, при котором по зашифрованному значению нельзя восстановить исходное слово. При этом программа аутентификации кодирует введенный пароль и сравнивает полученное значение (хэш) с хранящимся в базе данных. Существует много алгоритмов хэширования, при использовании которых узнать реальное значение пароля можно только путем полного перебора всех возможных вариантов и сравнения зашифрованной строки со значением в базе данных.
В старых системах семейства Unix пароль использовался в качестве ключа шифрования фиксированной строки алгоритмом DES (см. главу 1). Этот алгоритм ограничивает длину ключа 64 битами, соответственно пароли в таких системах могут содержать не более 8 символов. Современные системы используют алгоритм MD5 [RFC 1321], который допускает пароли практически неограниченной длины. Этот алгоритм специально разрабатывался с целью максимального усложнения задачи построения сообщения с заданным значением хэша.
Отцам-основателям Unix такой механизм обеспечения секретности показался настолько надежным, что они даже не стали ограничивать доступ обычных пользователей к хэшам чужих паролей, и выделили для их хранения поле в общедоступном для чтения файле /etc/passwd.
Однако "червь Морриса" продемонстрировал, что для подбора паролей не нужно перебирать все возможные комбинации символов, поскольку пользователи склонны выбирать лишь ограниченное подмножество из них. Процесс, имеющий возможность непосредственно читать закодированные значения паролей, может осуществлять подбор, не обращаясь к системным механизмам аутентификации, т. е. делать это очень быстро и практически незаметно для администратора.
После осознания опасности словарных атак разработчики систем семейства Unix перенесли значения паролей в недоступный для чтения файл /etc/shadow, где пароли также хранятся в односторонне зашифрованном виде. Это значительно усложняет реализацию словарной атаки, поскольку перед тем, как начать атаку, взломщик должен получить доступ к системе с привилегиями администратора. В наше время все способы получения не санкционированного доступа к парольной базе данных считаются "дырами" в системе безопасности.
Практически все современные системы хранят данные о паролях в односторонне зашифрованном виде в файле, недоступном для чтения обычным пользователям. Поставщики некоторых систем, например Windows NT/2000/XP, даже отказываются публиковать информацию о формате этой базы данных, хотя это само по себе вряд ли способно помешать квалифицированному взломщику.

Аутентификация в сети

Когда пользователь работает с консоли компьютера или с терминала, физически прикрепленного к терминальному порту, модель сессий является вполне приемлемой. При регистрации пользователя создается сессия, ассоциированная с данным терминалом, и далее проблем нет. Аналогично нет никаких проблем при подключении через сеть с коммутацией каналов, например, при "дозвоне" через модем, подключенный к телефонной сети (конечно же, при условии, что мы доверяем связистам). Когда соединение разрывается, сессия считается оконченной.
В сетях с коммутацией пакетов, к которым относится большинство современных сетевых протоколов (TCP/IP, IPX/SPX, ISO/OSI и т. д.), вообще нет физического понятия соединения. В лучшем случае сетевой протокол предоставляет возможность создавать виртуальные соединения с "надежной" связью, в которых гарантируется отсутствие потерь пакетов и сохраняется порядок их поступления. С таким виртуальным соединением вполне можно ассоциировать сессию, как это сделано в протоколах telnet, rlogin/rsh и ftp.

Протокол telnet
Протокол telnet используется для эмуляции алфавитно-цифрового терминала через сеть. Пользователь устанавливает соединение и регистрируется в удаленной системе таким же образом, как он регистрировался бы с физически подключенного терминала. Например, в системах семейства Unix создается виртуальное устройство, псевдотерминал (pseudotermina/) /dev/ptyXX, полностью эмулирующее работу физического терминала, и система запускает ту же программу идентификации пользователя /bin/login, которая используется для физических терминалов. При окончании сессии соединение разрывается и псевдотерминальное устройство освобождается.

Виртуальные сессии вынуждены полагаться на то, что сетевой протокол обеспечивает действительно гарантированное соединение, т. е. что никакая посторонняя машина не может вклиниться в соединение и прослушать его идИ послать свои поддельные пакеты. Обеспечение безопасности на этом уровне либо требует доверия к сетевой инфраструктуре физического, канального и сетевого уровней (линиям связи, коммутаторам и маршрутизаторам), либо сводится к использованию шифрования и/или криптографической подписи пакетов.
В протоколах, использующих датаграммные соединения, средствами протокола виртуальную сессию создать невозможно. Обычно в этом случае каждый пакет содержит идентификатор пользователя или сессии, от имени которого (в рамках которой) этот пакет послан. Такой подход применяется в протоколах работы с файловыми серверами NFS и NCP (Netware Core Protocol, используемый файловыми серверами Novell Netware). Датаграммные протоколы оказываются несколько более уязвимы для подделки пакетов и прочих вредоносных воздействий.

Подпись пакетов в NCP
Например, NCP, работающий через датаграммный протокол IPX, реализует свой собственный механизм поддержки сессий: все пакеты данной сессии имеют 8-битный номер, и пакеты с неправильными номерами просто игнорируются. Одна из техник взлома Netware 3.11 (так называемая "Голландская атака") состоит в посылке в течение короткого времени 256 пакетов с различными номерами — хотя бы один пакет окажется удачным. Для борьбы с такими действиями в Netware 3.12 была введена криптографическая подпись пакетов в пределах сессии.

Проблема дополнительно усложняется тем обстоятельством, что в сети зачастую взаимодействие происходит между системами, каждая из которых позволяет одновременную работу нескольких пользователей. Часто возникает желание требовать от пользователя регистрации только в одной из систем, а доступ в остальные системы предоставлять автоматически.
Обычно для автоматической регистрации используется модель доверяемых систем (trusted hosts). Если система В доверяет системе А, то все пользователи, зарегистрированные на системе А, автоматически получают доступ к системе В под теми же именами (рис. 12.2). Иногда аналогичную возможность можно предоставлять каждому пользователю отдельно — он сообщает, что при регистрации входа из системы А пароля запрашивать не надо. Разновидностью модели доверяемых систем можно считать единую базу учетных записей, разделяемую между машинами.

Рис. 12.2. Доверяемые системы

Межмашинное доверие в rlogin/rsh
Протоколы rlogin/rsh, обеспечивающие запуск отдельных команд или командного процессора на удаленной системе, используют файл /etc/hosts.equiv или.rhosts в домашнем каталоге пользователя на удаленной системе. Файл /etc/hosts.equiv содержит имена всех машин, которым наша система полностью доверяет. Файл.rhosts состоит из строк формата
имя.удаленной.машины имя пользователя
При этом имя.удаленной.машины не может быть произвольным, оно обязано содержаться в файле /etc/hosts, в котором собраны имена и адреса всех удаленных машин, "известных" системе. То же требование обязательно и для машин, перечисленных в /etc/hosts.equiv.
Например, пользователь fat на машине iceman.cnit.nsu.ru набирает команду
rlogin -I fat Indy.cnit.nsu.ru
— войти в систему lndy.cnit.nsu.ru под именем fat. Если домашний каталог пользователя fat на целевой машине содержит файл.rhosts, в котором есть строка iceman.cnit.nsu.ru fat, то пользователь fat получит доступ к системе Indy без набора пароля. Того же эффекта можно добиться для всех одноименных пользователей, если /etc/hosts.equiv содержит строку ice man.cnit.nsu.ru
Если же fat наберет команду
rlogin -1 root Indy.cnit.nsu.ru,
а в домашнем каталоге пользователя root файла.rhosts нет или он не содержит вышеприведенной строки, команда rlogin потребует ввода пароля, независимо от содержимого файла /etc/hosts.equiv. Нужно отметить, что администраторы обычно вообще не разрешают использовать rlogin для входа под именем root, потому что этот пользователь является администратором системы и обладает очень большими привилегиями.

Модель доверяемых систем обеспечивает большое удобство для пользователей и администраторов и в различных формах предоставляется многими сетевыми ОС. Например, в протоколе разделения файлов SMB. применяемом в системах семейства СР/М, Linux и др., используется своеобразная модель аутентификации, которую можно рассматривать как специфический случай доверяемых систем.

Аутентификация SMB
Аутентификация в SMB основана на понятии домена (domain). Каждый разделяемый ресурс (каталог, принтер и т. д.) принадлежит к определенному домену, хотя и может быть защищен собственным паролем. При доступе к каждому новому ресурсу необходимо подтвердить имя пользователя и пароль, после чего создается сессия, связанная с этим ресурсом. Для создания сессии используется надежное соединение, предоставляемое транспортным протоколом, — именованная труба NetBEUI или сокет TCP. Ввод пароля при каждом доступе неудобен для пользователя, поэтому большинство клиентов— просто запоминают пароль, введенный при регистрации в домене, и при подключении к ресурсу первым делом пробуют его. Благодаря этому удается создать у пользователя иллюзию однократной регистрации. Кроме того, если сессия по каким-то причинам оказалась разорвана, например из-за перезагрузки сервера, то можно реализовать прозрачное для пользователя восстановление этой сессии.
С точки зрения клиента нет смысла говорить о межмашинном доверии — клиенту в среде SMB никто не доверяет и вполне справедливо: обычно это система класса ДОС, не заслуживающая доверия. Однако серверы обычно передоверяют проверку пароля и идентификацию пользователя выделенной машине, называемой контроллером домена (domain controller). Домен обязан иметь один основной (primary) контроллер и может иметь несколько резервных (backup), каждый из которых хранит реплики (периодически синхронизуемые копии) базы учетных записей. При поступлении запроса на соединение сервер получает у клиента имя пользователя и пароль, но вместо сверки с собственной базой данных он пересылает их контроллеру домена и принимает решение о принятии или отказе в аутентификации на основании вердикта, вынесенного контроллером.
Только контроллеры домена хранят у себя базу данных о пользователях и паролях. При этом основной контроллер хранит основную копию базы, а резервные серверы — ее дубликаты, используемые лишь в тех случаях, когда основной сервер выключен или потерян. Благодаря тому, что все данные собраны в одном месте, можно централизованно управлять доступом ко многим серверам, поэтому домены представляют неоценимые преимущества при организации больших многосерверных сетей.

С точки зрения безопасности доверяемые системы имеют два серьезных недостатка.

1. 1. Прорыв безопасности на одной из систем означает, по существу, прорыв на всех системах, которые доверяют первой (рис. 12.3).
2. 2. Возникает дополнительный тип атаки на систему безопасности: машина, которая выдает себя за доверяемую, но не является таковой (рис. 12.4).

Рис. 12.3. Прорыв безопасности в сети с доверяемыми системами

12.4. Имитация доверяемой системы

Первая проблема является практически неизбежной платой за разрешение автоматической регистрации. Наиболее ярко эта проблема была проиллюстрирована упомянутым выше "Червем Морриса" (КомпьютерПресс 1991], который, проникнув в одну из систем, использовал содержимое файлов.rhosts и /etc/hosts.equiv для проникновения в доверяющие системы, полагаясь на то, что межсистемное доверие обычно делают взаимным. Поэтому в средах с высокими требованиями к безопасности часто стремятся ограничить число доверяемых систем, подобно тому, как отсеки кораблей разделяют водонепроницаемыми переборками.
Вторая проблема может быть отчасти решена использованием средств, пре-достаапяемых сетевыми протоколами, например, привязкой всех логических имен доверяемых систем к их сетевым адресам канального уровня. В протоколах TCP/IP это может быть сделано с использованием протокола аrр (Address Resolution Protocol — протокол разрешения адресов), однако надежда на это слаба: многие сетевые карты имеют настраиваемые адреса, а многие реализации сетевых протоколов допускают отправку пакетов с поддельным адресом отправителя.
Более изощренный и намного более надежный метод основан на использовании алгоритма двухключевого шифрования RSA или родственных ему механизмов.

Криптографические методы аутентификации

Многие системы аутентификации используют для самой аутентификации или представления контекста доступа алгоритм шифрования с открытым ключом RSA. Способы аутентификации, основанные на RSA, сводятся к следующему алгоритму.

• Система А генерирует последовательность байтов, обычно случайную, кодирует ее своим ключом и посылает системе В.
• Система В раскодирует ее своим ключом. Это возможно, только если системы владеют парными ключами.
• Системы тем или иным способом обмениваются "правильными" значениями зашифрованной посылки.

Аутентификация SSH
Для примера рассмотрим принцип RSA-аутентификации в пакетеssh [www.cs.hut.fi SSH] — Secure Shell. Пакет представляет собой функциональную замену программ rlogin/rsh и соответствующего этим программам демона rshd. В пакет входят программы ssh (клиент) и sshd (сервер), а также утилиты для генерации ключей RSA и управления ими. ssh использует RSA для прозрачной аутентификации пользователя при входе в удаленную систему. Кроме того, ssh/sshd могут осуществлять шифрование данных, передаваемых по линии во время сеанса связи и выполнять ряд других полезных функций.
Сервер хранит список известных общедоступных ключей для каждого из пользователей в файле SHOME/.ssh/authorized_keys, где $НОМЕ обозначает домашний каталог пользователя. Файл состоит из строк формата host_name: key— по строке для каждого из разрешенных клиентов. В свою очередь, каждый клиент хранит в файле $HOME/.ssh/private_key свой приватный ключ.
Когда из удаленной системы-клиента приходит запрос на аутентификацию, sshd запрашивает публичный ключ. Если полученный ключ совпадает с хранящимся в файле значением для этой системы, сервер генерирует случайную последовательность из 256 бит, шифрует ее публичным ключом и посылает клиенту. Клиент расшифровывает посылку своим личным ключом, вычисляет 128-битовую контрольную сумму и возвращают ее серверу. Сервер сравнивает полученную последовательность с правильной контрольной суммой и принимает аутентификацию в случае совпадения (рис. 12.5). Теоретически контрольные суммы могут совпасть и в случае несовпадения ключей, но вероятность такого события крайне мала.

Рис. 12.5. Аутентификация SSH

Аутентификация Lotus Notes
Система групповой работы Lotus Notes также использует для аутентификации открытый ключ. При создании учетной записи пользователя генерируются 621-битный приватный и соответствующий ему публичный ключи. Публичный ключ размещается в доменной адресной книге (рис. 12.6). Приватный ключ подвергается шифрованию закрытым ключом, который потом запрашивается у пользователя в качестве пароля, и сохраняется в идентификационном файле.

Рис. 12.6. Аутентификация в Lotus Notes

Чтобы аутентифицироваться в системе, пользователь должен указать идентификационный файл и набрать пароль, который позволит расшифровать хранящийся в файле приватный ключ. После этого все пакеты, которыми пользователь обменивается с сервером Notes, снабжаются цифровой подписью на основе этого ключа. Сервер может проверить аутентичность подписи, используя хранящийся в его адресной книге публичный ключ.
Более сложная ситуация возникает, когда пользователь должен аутентифицироваться в другом домене, в адресных книгах которого он не числится. Чтобы сделать такую авторизацию возможной, Notes вводит еще одно понятие: сертификат домена. Этот сертификат также представляет собой пару ключей, пароль к приватному ключу которой известен только администраторам домена. Каждый идентификационный файл, создаваемый в домене, подписывается приватным ключом этого сертификата (рис. 12.7).
Регистрируясь в чужом домене, пользователь предъявляет свои имя и публичный ключ, подписанные сертификатом своего домена. Если принимающий домен не знает такого сертификата, аутентификация отвергается. Чтобы домен мог признать чужой сертификат, его администратор должен провести кросс-сертификацию, а попросту говоря создать в доменной адресной книге документ, в котором хранится публичный ключ сертификата домена [redbooks.ibm.com sg245341] (рис. 12.8).

Рис. 12.7. Сертификат домена Lotus Notes

Рис. 12.8. Кросс-сертификация между доменами Lotus Notes

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