RFC2148 — Развертывание службы белых страниц Интернета

RFC 2148 описывает наилучшее, по состоянию на 1997 год, применение Internet White Pages Service (IWPS) для публикации публичной адресной информации о людях и организациях. Организациям рекомендуется публиковать такие данные, соблюдать национальные нормы приватности и рекомендации по защите данных, использовать X.500 как структуру данных и схему именования, а также предоставлять доступ LDAP-клиентам. Документ рекомендует не взимать плату за простые обращения к данным и поощряет поставщиков услуг Интернета помогать небольшим организациям с размещением и эксплуатацией каталогов. Рассматриваются управление данными, глобальное пространство имен X.500, репликация, LDAP и риски безопасности каталогов.

Полный перевод

Идентификатор и границы: RFC2148/part-001, страницы 1–6; SHA-256=783ebd6394ccf10d612faa395bbff548c21eb7b4183b0851295f336758f303f8

Network Working Group                                   H. Alvestrand
Request for Comments: 2148                                    UNINETT
BCP: 15                                                       P. Jurg
Category: Лучшая современная практика                         SURFnet
                                                       Сентябрь 1997

             Развертывание Internet White Pages Service

Статус этого меморандума

   Этот документ определяет Лучшую современную практику Интернета для
   интернет-сообщества и запрашивает обсуждение и предложения по
   улучшению. Распространение этого меморандума не ограничено.

1.  Резюме и рекомендации

   Этот документ формулирует следующие рекомендации для организаций
   в Интернете:

     (1)   Организации СЛЕДУЕТ (SHOULD) публиковать открытые адреса
           электронной почты и другую открытую адресную информацию о
           пользователях Интернета в пределах своей площадки.

     (2)   В большинстве стран действуют законы, касающиеся публикации
           информации о людях. Помимо этих законов организации СЛЕДУЕТ
           (SHOULD) соблюдать рекомендации [1].

     (3)   В настоящее время предпочтительный способ публикации этой
           информации — использовать X.500 в качестве её структуры
           данных и схемы именования (определённой в [4] и обсуждаемой
           в [3], хотя в некоторых странах применяется национальное
           уточнение, например [15] для США). Организация МОЖЕТ (MAY)
           дополнительно публиковать её с использованием дополнительных
           структур данных, таких как whois++.

     (4)   Организации СЛЕДУЕТ (SHOULD) сделать опубликованную
           информацию доступной клиентам LDAP, предоставив серверам LDAP
           доступ к своим данным".

     (5)   Организации НЕ СЛЕДУЕТ (SHOULD NOT) пытаться взимать плату
           за простой доступ к данным.

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

     (1)   Поставщикам программного обеспечения электронной почты
           СЛЕДУЕТ (SHOULD) включать в свои продукты функцию поиска LDAP
           либо как встроенную функцию, либо предоставляя средства
           преобразования.



Alvestrand & Jurg        Лучшая современная практика           [Страница 1]

RFC 2148              Internet White Pages Service        Сентябрь 1997


     (2)   Поставщикам интернет-услуг СЛЕДУЕТ (SHOULD) помогать
           небольшим организациям соблюдать эту рекомендацию: либо
           предоставляя услуги по размещению их данных, либо помогая им
           найти другие стороны, которые сделают это, либо помогая им
           ввести в действие собственную службу.

     (3)   Всем заинтересованным сторонам СЛЕДУЕТ (SHOULD) обеспечить
           существование в мире базового пространства имён X.500 и то,
           чтобы все имена в этом пространстве имён разрешались.
           (Национальные пространства имён могут развивать базовое
           пространство имён.)

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

   Слова "SHOULD", "MUST" и "MAY", написанные В ВЕРХНЕМ РЕГИСТРЕ,
   имеют значение, определённое в RFC 2119 [17].

2.  Введение

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

   Этот документ описывает, каким образом Internet White Pages Service
   (далее сокращённо IWPS) наилучшим образом используется с опорой на
   сегодняшний опыт, сегодняшние протоколы, сегодняшние продукты и
   сегодняшние процедуры.

   Опыт [2] показал, что служба White Pages, основанная на
   самостоятельной регистрации пользователей или на централизованных
   серверах, склонна собирать данные бессистемно и, кроме того, собирает
   данные, которые быстро устаревают и не поддерживаются в актуальном
   состоянии.

   Наиболее значимые попытки создать IWPS основаны на моделях с
   распределёнными (локальными) базами данных, каждая из которых хранит
   управляемую часть информации IWPS. Такая часть преимущественно
   состоит из всей относящейся к IWPS информации из конкретной
   организации либо от поставщика интернет-услуг и его пользователей.
   Над базами данных располагается протокол служб каталогов, который
   соединяет их и предоставляет доступ пользователям. Сегодня X.500 —
   самый популярный в Интернете протокол служб каталогов, объединяющий
   адресную информацию примерно о 1,5 миллиона человек и 3 000
   организаций. Вторым по популярности протоколом является Whois++.
   X.500 и Whois++ также могут использоваться для взаимного соединения
   иной информации, не только информации IWPS, но здесь обсуждаются
   лишь возможности IWPS.



Alvestrand & Jurg        Лучшая современная практика           [Страница 2]

RFC 2148              Internet White Pages Service        Сентябрь 1997


   Примечание: в Интернете существуют и другие, не соединённые между
   собой базы адресов, также весьма популярные для хранения адресной
   информации о людях. "Ph" — популярный протокол для использования с
   автономной базой данных. В Интернете зарегистрировано более 300 баз
   данных Ph. Однако для IWPS настоятельно рекомендуется взаимное
   соединение баз данных, поскольку оно обеспечивает возможность найти
   данные. Поэтому Ph в его нынешнем виде не считается хорошим
   кандидатом для IWPS, но будущие разработки могут изменить эту
   ситуацию (см. раздел 12).

   В настоящее время в качестве протокола служб каталогов для IWPS
   необходимо рекомендовать X.500. Однако будущая технология может
   сделать возможным использование также других протоколов или их
   использование вместо него.

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

   Сводку по продуктам X.500 можно найти в [14] (документе, который
   будет регулярно обновляться).

   Разделы 3–7 ниже содержат рекомендации, относящиеся к публикации
   информации в IWPS и не зависящие от протокола служб каталогов.
   Разделы 8–11 обсуждают вопросы, специфичные для X.500. В разделе 12
   обсуждаются некоторые будущие разработки в той мере, в которой их
   можно предвидеть на момент написания этого документа.

3.  Кому следует публиковать информацию IWPS и как?

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

   -    Лицо работает в организации, поддерживающей информацию.

   -    Лицо обучается в университете/школе, поддерживающем данные.

   -    Лицо является (персональным) абонентом интернет-службы
        организации, поддерживающей информацию.





Alvestrand & Jurg        Лучшая современная практика           [Страница 3]

RFC 2148              Internet White Pages Service        Сентябрь 1997


   Организация, поддерживающая данные, не обязана хранить данные в
   собственной локальной базе данных. Хотя ведение локальной базы
   данных в службе X.500 или Whois++ не является слишком сложной
   задачей, поставщикам интернет-услуг рекомендуется предоставлять
   средства баз данных тем организациям среди своих клиентов, которые
   поддерживают лишь небольшую часть информации IWPS или не имеют
   достаточных ресурсов системного администрирования. Это побудит такие
   организации присоединиться к IWPS. Сбор информации IWPS и поддержание
   её актуальности следует всегда оставлять в ведении организации, к
   которой относится эта информация.

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

4.  Какую информацию следует публиковать?

   В публикуемую информацию о физическом лице следует как минимум
   включать:

   -    Имя физического лица.

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

   -    Некоторое указание на отношение физического лица к стороне,
        поддерживающей информацию.

   Если в качестве протокола служб каталогов используется X.500,
   последнее требование может быть выполнено использованием атрибута
   "organizationalStatus" (см. [3]) или добавлением в локальное
   пространство имён X.500 специальной организационной единицы,
   отражающей отношение (например, ou=students или ou=employees).

   Кроме того, в IWPS может быть включена иная открытая адресная
   информация о физических лицах:

       -    Номер телефона физического лица.

       -    Номер факса физического лица.

       -    Почтовый адрес физического лица.


Alvestrand & Jurg        Лучшая современная практика           [Страница 4]

RFC 2148              Internet White Pages Service        Сентябрь 1997


       -    URL домашней страницы физического лица в Web.

   В ближайшем будущем хорошей идеей будет также хранить информацию об
   открытом ключе.

   Дополнительные сведения о рекомендуемой схеме Internet White Pages
   приведены в The Internet White Pages Schema [16].

   Организациям следует публиковать в IWPS следующую информацию о себе:

    -    URL домашней страницы организации в Web.

    -    Почтовый адрес.

    -    Номера факсов.

    -    Интернет-домен.

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

   Организации также могут публиковать номера телефонов и представление
   о себе.

5.  Управление данными

   Управление данными, то есть сбор информации IWPS и поддержание её
   актуальности, — задача, которую крупным организациям нельзя
   недооценивать. В отношении этих вопросов можно сформулировать
   следующие рекомендации:

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

   -    Организации следует определить, какого рода информацию следует
        включать в базу данных и как её следует структурировать.
        Ей следует соблюдать интернет-рекомендации по структурированию
        информации. Помимо критериев предыдущего раздела, при
        использовании X.500 в качестве протокола служб каталогов
        следует соблюдать [3] и [4].





Alvestrand & Jurg        Лучшая современная практика           [Страница 5]

RFC 2148              Internet White Pages Service        Сентябрь 1997


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

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

   -    Лучшая мотивация организации присоединиться к IWPS состоит в
        том, что одновременно у неё появится локальная база данных для
        локальных целей. Локальная база данных может содержать больше
        информации, не обязательно открытой, и выполнять больше задач,
        чем требуется для IWPS. При подключении к IWPS организация
        должна "отфильтровать" дополнительную локальную информацию и
        службы, не предназначенные для открытой IWPS, с использованием
        протокола служб каталогов.

6.  Правовые вопросы

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

   Некоторые из них документированы в [5] и [1].

   Стороне, поддерживающей информацию IWPS, следует также соблюдать
   некоторые общие правила, даже если они не установлены законом:

   -    Публикуйте только корректную информацию.

   -    Предоставляйте людям возможность просматривать хранящуюся о них
        информацию и право не предоставлять информацию либо добиваться
        её изменения.

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



Alvestrand & Jurg        Лучшая современная практика           [Страница 6]

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

7.  Не взимайте плату за поиск

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

-    Технология микроплатежей в настоящее время недоступна.

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

-    Текущие протоколы служб каталогов не поддерживают аутентификацию на уровне, который представлялся бы подходящим для платного сервиса.

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

8.  Используйте X.500

IWPS, основанная на протоколе X.500, имеет сравнительно широкое распространение. Текущий сервис содержит около 1,5 миллиона записей о физических лицах и 3 000 записей об организациях. Он координируется Dante, поставщиком интернет-услуг в Великобритании, и известен как «NameFLOW-Paradise».

Хотя X.500 иногда критикуют за то, что его функциональность ограничена навязываемой им иерархической структурой именования, он обеспечивает достаточно хорошую функциональность, что было показано в нескольких пилотных проектах организаций [5], [2], [6], [7], которые сейчас эксплуатируют производственную IWPS на основе X.500. Пользовательские интерфейсы также определяют функциональность, предлагаемую IWPS на X.500. Обычно они предлагают поиск в IWPS на основе следующих вводимых пользователем данных:

-    Имя человека

-    Имя организации, с которой этот человек может быть связан



Alvestrand & Jurg        Best Current Practice                  [Page 7]

RFC 2148              Internet White Pages Service        September 1997


-    Название страны

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

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

Схема именования X.500 предъявляет к взаимосвязанной IWPS требование, чтобы все хранящиеся в ней записи имели уникальные имена («схема именования»). Проще всего это выполняется регистрацией всех записей в «дереве именования» с единым корнем; именно поэтому совокупность информации в IWPS на X.500 иногда называется «деревом информации каталога» (Directory Information Tree), или DIT.

Организациям настоятельно рекомендуется использовать протокол X.500 для присоединения к IWPS. Текущий сервис основан на стандарте X.500 1988 года [8] и некоторых специфичных для Интернета дополнениях к протоколу, соединяющему локальные базы данных [10], и к протоколу доступа [9]. Организациям следует использовать программное обеспечение X.500, основанное на этих спецификациях и дополнительно поддерживающее [11] для передачи протоколов OSI через Интернет.

Организации могут подключаться к инфраструктуре NameFLOW-Paradise с помощью DSA 1988 года, не реализующих [10], но у них не будет автоматической репликации ссылок на знания. Это будет неудобно, но не станет большой проблемой. Стандарт X.500 1993 года включает функциональность из [10], но использует другой протокол. Поэтому организации, подключающиеся к инфраструктуре с помощью DSA 1993 года, также столкнутся с этим недостатком. В разделе 12 «Будущие разработки» объясняется, почему инфраструктура пока не использует стандарт 1993 года.

За рекомендациями о том, какие атрибуты использовать в X.500 и как их использовать (либо для общедоступной информации IWPS, либо для дополнительной локальной информации), читатель отсылается к [3] и [4]. Для специальных непубличных локальных целей также могут быть определены новые атрибуты (и классы объектов). В целом следует рекомендовать как можно шире использовать многозначность атрибутов в X.500, поскольку это значительно улучшит поисковую функциональность сервиса. Например, атрибут organizationalName, содержащий название организации, или атрибут commonName, содержащий имя человека, следует включать все известные псевдонимы организации или человека. В частности, важно добавлять «читаемые» варианты всех атрибутов, по которым, как ожидается, будут выполнять поиск люди, если они содержат национальные символы.

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

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

Рекомендации по эксплуатации базы данных в инфраструктуре X.500 можно найти в [12].

X.500 не рекомендуется использовать для:

 -    сервиса «Желтые страницы» большого масштаба. См. [5].

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

 -    публикации информации в наборах символов, отличных от ASCII, некоторых европейских письменностей на основе латиницы и японского языка (наборы символов T.61). Хотя поддержка этих наборов символов доступна в переработанных версиях X.500, продукты, поддерживающие эту переработанную версию, пока еще не получили широкого распространения.

9.  Используйте глобальное пространство имен

Некоторые люди, например при использовании серверов Novell 4, решили использовать X.500 или X.500-подобные сервисы в качестве внутреннего механизма именования без координации с внешним источником.

Это страдает от многих тех же проблем, что и частные IP-адреса, только в большей степени: после решения открыть свои данные внешнему миру вам может потребоваться значительно реструктурировать их.




Alvestrand & Jurg        Best Current Practice                  [Page 9]

RFC 2148              Internet White Pages Service        September 1997


Глобально доступный сервис X.500 требует глобально связанного пространства имен X.500. Рекомендации о том, как создать локальную часть глобального пространства имен, см. в [3] и [4].

Хотя стандарт не очень ясен в этом отношении и его последняя версия (93), по-видимому, не поддерживает это, на практике пространство имен X.500 управляемо только при наличии единого корневого контекста, эксплуатируемого по соглашению о сотрудничестве. Однако можно быть уверенным, что за контроль над ним будут вестись территориальные споры.

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

Этот документ призывает всех участников данной области оставить существующую практику без изменений, пока не будет согласована и готова к внедрению лучшая система; в настоящее время корневой контекст эксплуатируется сервисом Dante NameFLOW-Paradise.

Дополнительную информацию о сервисе Dante NameFLOW-Paradise можно найти по URL

http://www.dante.net/nameflow.html

10.  Используйте LDAP

В настоящее время LDAP, документированный в [9], является протоколом, который предлагает наибольшую функциональность X.500 там, где невозможно реализовать полный стек OSI.

Он реализован на множестве платформ, включая несколько платформ типа PC, и популярен во множестве коммерческих предложений.

Согласованные усилия по обеспечению доступности LDAP являются способом публикации, который обеспечивает наиболее широкий доступ к данным.

Кроме того, DSA X.500 должны реализовывать необходимые связи, чтобы гарантировать их надлежащую интеграцию в дерево именования/ссылок; в большинстве случаев это будет означать, что им следует реализовывать как минимум протокол X.500 DSP.

(В данном контексте несущественен вопрос, выполняется ли шлюзование LDAP в DAP или DAP в LDAP; может быть вполне уместно хранить данные на сервере только с LDAP и предоставлять их миру, использующему DAP/DSP, через шлюз, если все основные пользователи используют LDAP.)





Alvestrand & Jurg        Best Current Practice                 [Page 10]

RFC 2148              Internet White Pages Service        September 1997


11.  Сделайте сервисы доступными

Технические вложения в эксплуатацию сервиса X.500 не являются огромными, см., например, [5].

12.  Будущие разработки

Сегодня [октябрь 1996 года] ожидается несколько усовершенствований технологии IWPS.

Наиболее важным из упоминаемых здесь является создание «Common Indexing Protocol», который должен обеспечить интеграцию X.500, Whois++ и протоколов, использующих автономные базы данных. Такой протокол не только обеспечил бы интеграцию, но одновременно предоставил бы возможность исследовать сервисы «Желтые страницы» и расширенный поиск, даже если использовать его только для X.500.

В контексте Common Indexing Protocol следует упомянуть автономные серверы LDAP, о которых объявили несколько разработчиков программного обеспечения. Это автономные адресные базы данных, к которым можно обращаться через LDAP. В настоящее время также доступна версия из public domain от University of Michigan. Также объявлен шлюз LDAP-to-DAP, который может интегрировать автономный сервер LDAP в инфраструктуру X.500.

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

Версия стандарта X.500 1993 года уже реализована в нескольких продуктах. В нескольких отношениях она является улучшением по сравнению со стандартом 1988 года, но в инфраструктуре NameFLOW-Paradise пока не реализована. Основная причина состоит в том, что стандарт не признает существование единого корневого DSA, а предполагает, что управляющие DSA первого уровня (DSA стран) заключают двусторонние договоры о взаимосоединении. В случае NameFLOW-Paradise такая ситуация была бы неуправляемой. В [13] предложено усовершенствование стандарта 1993 года, позволяющее иметь единый корень. Как только появятся реализации [13], NameFLOW-Paradise будет экспериментировать с DSA 1993 года. Это ожидается в 1997 году.

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






Alvestrand & Jurg        Best Current Practice                 [Page 11]

RFC 2148              Internet White Pages Service        September 1997


13.  Соображения безопасности

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

-    У людей появится стандартный способ доступа к опубликованной информации.

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

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

-    Если возможно изменение через Сеть, люди будут пытаться изменять вашу информацию непредусмотренными способами. Иногда пользователи будут изменять данные и по ошибке; не всякое нежелательное изменение является злонамеренным.

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

Вторая защита предполагает попытку установить контроль доступа. LDAP поддерживает несколько методов контроля доступа, включая использование паролей в открытом тексте. Пароли в открытом тексте не являются безопасным механизмом при наличии подслушивающих; этот документ поощряет использование более сильных механизмов, если возможность изменения предоставляется через открытый Интернет. В противном случае права на изменение следует ограничить локальной интрасетью.

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

RFC2148 — Развертывание службы белых страниц Интернета

Выжимка

Полный перевод