Журнал о компьютерных сетях и телекоммуникационных технологиях
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК:
    Домой
 
   
АРХИВ ЖУРНАЛА
   

2008: 1 2 3 4 5 6 7 8 9 10 11 12 13
2007: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2006: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2005: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2004: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2003: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2002: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2001: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2000: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
1999: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1998: 1 2 3 4 5 6 7 8 9 10 11 12
1997: 1 2 3 4 5 6 7 8 9 10 11 12
1996: 1 2 3 4 5 6 7 8 9 10


Rambler's Top100

  

В поисках совершенства

Бен Дюпон

Мы протестировали восемь поисковых систем масштаба предприятия и проанализировали последствия их внедрения с точки зрения информационной безопасности. Наше заключение: делать окончательные выводы пока рано.

IBM, Microsoft, Oracle, SAP... Почему в драке за рынок систем поиска эти гиганты не на шутку «сцепились» с такими поставщиками специализированного ПО, как dtSearch, Vivisimo и X1 Technologies, ведь, согласно данным аналитической компании Gartner, по результатам 2006 г. объем продаж на этом рынке во всем мире составил какие-то жалкие 370 млн долл.

Ответ простой: все дело в узнаваемости бренда. Вместо того чтобы сказать «Удалось тебе найти то-то и то-то?», сейчас говорят: «Удалось тебе “загуглить” то-то и то-то?» (от названия поискового портала Google). Популярность такого уровня за деньги не купишь, и давно работающие на рынке поставщики корпоративных приложений совсем не хотят, чтобы их средства поиска ИТ-службы потенциальных заказчиков сравнивали с прославленными инструментами компании Google.

Более того, ясно, что рентабельность в этой области падает в основном из-за того, что Google и альянс IBM–Yahoo, что называется, «играют на понижение». Мы не то чтобы жалуемся, нет. Поведение сбивающих цены конкурентов — это вполне нормальная, проверенная временем тактика, которая идет только на пользу потенциальным заказчикам. И все равно, даже при сегодняшних сравнительно привлекательных ценах данный сектор рынка не назовешь быстро развивающимся. Почему?

Протестировав в нашей лаборатории Real-World (г. Грин Бей, шт. Висконсин) поисковые продукты компаний dtSearch, Goog-le, IBM, ISYS Search Software, Mondosoft, Thunderstone Software, Vivisimo, X1, мы полагаем, что знаем ответ на поставленный вопрос: в условиях хранения больших объемов информации, характерных для современных организаций, существующие продукты не слишком хорошо справляются со своей работой в смыс-ле выдачи искомых результатов. Это относится и к «убойному» алгоритму PageRank компании Google, который трансформирует веб-страницы в действительно полезный источник информации. Дело в том, что этот алгоритм не очень хорошо адаптируется к особенностям корпоративного поиска. Веб-поиск отличается от поиска в настольной системе, а последний — от федерализированного корпоративного поиска и т. д., и ни одному разработчику пока не удалось соединить все это в одной системе.

Мы обнаружили также проблемы с информационной безопасностью. Корпоративный поисковый механизм приступает к работе тогда, когда пользователь нацеливает его на разделяемый файловый ресурс. Поисковая программа открывает все документы подряд — даже те, в которых содержится требующая защиты («чувствительная») информация. Текст и метаданные файла извлекаются и индексируются; кроме того, большинство протестированных нами продуктов кешируют текст документа или даже весь документ целиком. Надеемся, что вы понимаете, к каким проблемам это может приводить.

Полную версию данной статьи смотрите в 14-ом номере журнала за 2007 год.

Стоит ли овчинка выделки?

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

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

Кроме того, хотя недавние изменения Федеральных правил гражданского судопроизводства в США сами по себе не сделали внедрение систем корпоративного поиска приоритетной задачей, они определенно заставили понервничать многие ИТ-службы. Некоторым компаниям, вроде Bank of America Securities и Philip Morris, пришлось раскошелиться на миллиардные штрафы за то, что они оказались не в состоянии предоставить судебным органам документы, фиксирующие их деловые операции. На фоне разрастания объемов хранилищ данных, систем управления контентом (Content-Management System — CMS), баз данных, файловых и веб-серверов служащие тратят много своего ценного рабочего времени на «откапывание» файлов, которые федерализированный поисковый механизм может доставлять за доли секунды.

Что касается качества работы этих механизмов, то об этом можно сказать следующее: хотя все восемь протестированных нами продуктов используются крупными и известными заказчиками и имеют устоявшуюся репутацию, они мало чем различаются. Определенные различия вы обнаружите, если обратитесь к развитым возможностям федерализированного поиска, которые в общем случае связаны с индексирующими системами типа СУБД и CMS. Но будьте готовы к тому, что за это придется заплатить дополнительно: самый большой урон вашему кошельку нанесут индексирующие файловые и веб-серверы. При этом поставщики, предлагающие более развитые возможности, попытаются сбыть вам продукты, которые дают лишь ненамного лучшие результаты, чем «рядовые».

Как работают поисковые механизмы

В сердцевине большинства поисковых систем находятся три стержневых элемента, три механизма: просмотра/индексирования, обработки запросов и ранжирования. Разработчики поисковых систем называют их по-разному и по-разному распределяют их функции, но в конечном итоге система базовых понятий у всех одинаковая. Мы столкнулись лишь с одним исключением: компания X1 не предлагает ни развитых поисковых алгоритмов (таких, как нечеткий поиск или выделение основы слова), ни ранжирования по релевантности. Она решает проблему корпоративного поиска посредством уникальной и легче поддающейся защите архитектуры «клиент–сервер».

Механизм просмотра/индексирования отвечает за извлечение документов и данных из источника (например, базы данных, файлового сервера или CMS) и помещение информации в структуру, в которой можно организовать эффективный поиск. В большинстве случаев такой структурой является обратный указатель (inverted index). Упомянутый механизм занимается также кешированием документов. Последнее служит для создания «резюме» документов, отображаемых на страницах с результатами поиска.

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

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

Как построены поисковые продукты

Анализируя протестированные нами продукты, мы выделили три разновидности их архитектуры. Наиболее популярным является подход с применением веб-сервера, доступ к которому осуществляется исключительно посредством браузера. К этой группе относятся продукты Google, IBM, Mondosoft, Thunderstone и Vivisimo, причем продукты первой и последней компаний реализованы в виде устройств.

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

И наконец, компания X1 прислала для тестирования базирующееся на ПК решение, выполненное в архитектуре «клиент–сервер». В нем интерфейс механизма обработки запросов отделен от собственно поискового механизма. Это означает, что защита указателей осуществляется с применением более гибких и детализированных средств. Фактически интерфейс механизма обработки запросов даже не должен иметь доступа к указателю, поскольку не обращается к нему напрямую.

Какой вариант будет лучшим для вас? Если вы планируете использовать поисковый продукт в качестве интерфейса вашего файл-сервера — вместо того, чтобы пользоваться проводником — то вам лучше сделать одно из двух. Взять продукт, располагающий хорошими возможностями интеграции с ПК (в противоположность продуктам с веб-интерфейсом), или взять продукт, который располагает мощным интерфейсом программирования приложений (API) и позволяет разрабатывать специализированные поисковые программы-клиенты. Если интеграция с ПК для вас не очень важна или если вы стремитесь избавиться от поисковых клиентов на ПК, то вам больше подойдут решения, базирующиеся на веб-интерфейсе.

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

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

Законы федерализации

«Белой вороной» оказался продукт Google, но не из-за отставания в функциональном отношении и не из-за неконкурентной цены — напротив, все мы должны благодарить компанию Google за развязанную ею ценовую войну, в результате которой цена поисковых продуктов стала сравнительно приемлемой. все дело в алгорит-ме PageRank. Прелесть его заключается в том, что он привлекает миллионы людей к работе, которую программы делают плохо, т. е. к принятию субъективных решений. Поскольку этот алгоритм работает по принципу присвоения более высокого коэффициента релевантности тем веб-страницам, к которым подсоединялось наибольшее количество других страниц, он имеет дело с объективными данными. Написать программу, принимающую объективные решения очень просто, но в противоположность этому люди лучше программ принимают субъективные решения. Поэтому, если 100 человек обратилось к странице A, содержащей контент Z, но только 5 человек — к странице B, содержащей этот же контент, то, вероятно, что на странице A информация о контенте Z более точная, чем на странице B, поэтому странице А следует присвоить более высокий ранг. Если развивать этот пример глубже, то можно сказать, что на странице B ключевые слова могут встречаться чаще, чем на странице А, причем они могут чаще выделяться жирным шрифтом и чаще присутствовать в заголовках, но страница А все равно будет иметь более высокую релевантность (т. е. содержать именно то, что вы ищите).

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

HTML-документы структурированы еще и в том смысле, что в них содержатся ссылки на другие HTML-документы. Эта вторая форма структуризации, с применением анализа ссылок, т. е. по существу, со сквозным анализом, является основой алгоритма PageRank компании Google.

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

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

Не всем позволено искать

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

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

Эта проблема больше характерна для веб-продуктов, таких, как OmniFind Yahoo Edition компании IBM, где клиентом является веб-браузер. Если веб-сервер не выполняет аутентификацию пользователя или если удостоверяющая личность пользователя информация не передается этому серверу тем или иным способом, то поисковая программа будет не в состоянии проверить, имеет ли он право доступа к найденным документам. Если пользователь выбирает для просмотра какой-то документ, то в действие вступает протокол извлечения файла из сервера, и в этой точке может быть введена в действие функция защиты информации.

После аутентификации пользователя в поисковых продуктах могут применяться следующие три метода авторизации: кеширование информации ACL и/или LDAP для последующей проверки полномочий пользователя; проверка полномочий по информации LDAP или ACL, поступившей от инициировавшего запрос сервера; использование предоставленного поставщиком интерфейса API, реализующего функции защиты.

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

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

Другая возможность состоит в применении нескольких поисковых серверов. Использование одного указателя для предоставления поискового доступа сразу всем служащим — решение довольно неудачное, поскольку наличие одного-единственного указателя означает, что имеется одна учетная запись суперпользователя, которая разрешает доступ ко всему проиндексированному контенту.

Из этого мы делаем вывод: надо сделать так, чтобы ваш поисковый механизм не «работал на ухудшение» безопасности источника оригинальной информации. Никогда не забывайте о том, что поисковый продукт сохраняет контент, а, может быть, даже и полную копию всего искомого документа на другом сервере (не на сервере, содержащем исходную информацию). Это означает, что в отношении кешированного контента перестают действовать те правила, которые действуют на файловом сервере, сервере БД или CMS.

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

ПК пользователей тоже могут хранить чувствительную информацию, но главный вопрос заключается в следующем: чтобы индексировать содержимое ПК и позволять проводить поиск по этому указателю кому-нибудь, кроме владельца, на каждом таком ПК надо создать хранилища данных общего пользования. Это означает, что потенциально может создаться кошмарная ситуация с информационной безопасностью, если ваша ЛВС заполучит вирус, который прекрасно распространяется через файлы общего пользования. Для ПК лучше подходит вариант локального индексирования и поисковые программы типа Google Desktop, OmniFind Yahoo! Edition или X1 Enterprise Client..

  
14 '2007
СОДЕРЖАНИЕ

бизнес

• Как делили «последнюю милю»

• ЦОД «в комплексе»

инфраструктура

• NAC: и больше и лучше

• Администрирование в движении

• Стандарт NEA

• Будущее DVR в свете внедрения IP-систем видеонаблюдения

сети связи

• «Многоликие» фиксированные беспроводные системы

• Что такое конвергентная сеть и как к ней перейти?

информационные системы

• Ключевые параметры для управления call-центром

• BPEL4People: человеческий фактор

• Изменения в стеке Windows повышают производительность сети

защита данных

• В поисках совершенства

электронная коммерция

• Эффективность ЦОДов: все дело в метриках

• Оптоволокно меняет облик внешних кабельных инфраструктур


• Калейдоскоп


Реклама:
 Copyright © 1996-2008 ООО "Сети и Системы Связи". вверх