Поиск данных в Exchange и SharePoint
Главная цель сравнительной новой технологии eDiscovery - осуществлять глубокий поиск по разнообразным коллекциям почтовых ящиков Exchange и сайтов SharePoint, который будет исследовать весь массив данных, отыскивая самые потаенные секреты тех, кто предпочитает действовать максимально незаметно. И результаты подобной технологии, применяемой в Exchange 2010 и SharePoint 2010, говорят сами за себя: сегодня сих помощью все чаще, по крайней мере в США, предоставляются необходимые данные для юридических разбирательств. И в этом нет ничего удивительного: в век современных технологий люди хранят все свою информацию в цифровом виде, а почтовые ящики буквально переполнены честными данными, которые легко могут быть использованы в суде. Нужно отметить, что eDiscovery находится в самом начале своего эволюционного развития, поэтому с каждым годом будет все совершеннее и скоро у нас не останется никаких тайн от "Большого Брата" .
Первым признаком кооперации были общие для Exchange 2013 и Share Point 2013 платформа поиска Search Foundation и язык запросов Keyword Query Language (KQL) (см. материал по ссылке msdn.microsoft.com/en-us/library/office/ee558911.aspx). С их помощью вы можете построить центр обнаружения данных SharePoint (https://msdn.microsoft.com/en-us/library/office/jj163267.aspx), в котором можно управлять функциями eDiscovery, использующими источники, извлекаемые из Exchange и SharePoint. Теперь обратите внимание на центр соответствия требованиям Office 365 (https://technet.microsoft.com/en-us/library/dn876574.aspx). В сущности, таким образом Microsoft объявляет, что компании удалось удачно объединить eDiscovery с другими функциями совместимости во всех программах Office 365. Естественно, этого было бы невозможно добиться, не используя выделенные сервера (https://buy.fineproxy.org/servera-ot-fineproxy.html) под отдельные группы пользователей.
Запросы для поиска находятся в центре всей этой работы, в том числе одноименная команда Search-Mailbox (http://thoughtsofanidlemind.com/2014/10/17/using-search-mailbox-to-look-for-items-with-a-specific-date/), до сих пор используемая для обнаружения и удаления вредного содержимого из почтовых ящиков. С ее помощью можно строить оптимальные индексы из баз данных почтовых ящиков, но они бесполезны, если нельзя создавать эффективные запросы для опроса индексов.
Поэтому иногда кажется странным, что Microsoft, не жалеющая средств для встраивания функций eDiscovery в Exchange и Share Point, удовольствовалась элементарным графическим интерфейсом для построения запросов.
SharePoint Online и Exchange Online свойственна та же проблема, что и локальным версиям. Она заключается в следующем. Когда приходит время составить запрос для поиска, пользователь оказывается предоставленным самому себе. Целеустремленному исследователю приходится начинать с нуля, составляя запрос для проверки десятков миллионов сообщений и документов и настраивая прокси-сервер (https://buy.fineproxy.org/rossijskie-proksi.html (https://buy.fineproxy.org/rossijskie-proksi.html)). Вследствие таких факторов, как увеличенные квоты почтового ящика, меньшая стоимость хранения данных и желание пользователей избегать рутинной работы по очистке цифрового контента, число элементов, индексируемых Exchange и SharePoint, не сокращается. В свою очередь, это означает, что необходимость в эффективных и целенаправленных запросах для поиска становится более актуальной, чем когда-либо раньше. Десять лет назад сравнительно эффективный поиск мог обнаружить сотню элементов, и не составляло труда просмотреть такой объем данных, чтобы выбрать важную информацию и отбросить лишнее. Сегодня запрос с тем же относительным уровнем эффективности может принести несколько тысяч элементов, и одна мысль о необходимости просматривать столько «мусора», чтобы обнаружить действительно нужную информацию, кажется невыносимой.
Я выбрал Exchange в качестве иллюстрации, но такая же ситуация существует в SharePoint и свойственна как локальной, так и «облачной» платформе. Пустота поля, выделенного для ключевых слов запроса поиска, — проблема для сотрудника, ответственного за построение запроса. Конечно, легко следовать советам на всплывающей панели и получить такие запросы, как (Cat OR HAT) NEAR Seuss, но эти запросы вряд ли помогут раскрыть секреты манипулирования фондовым рынком, нарушения патентного права и решить многие другие задачи, для которых применяется процесс обследования цифровых данных.
Для Microsoft было бы полезно построить нечто вроде программного мастера, чтобы помочь неопытным пользователям создавать эффективные запросы eDiscovery. Некоторые компоненты уже на месте, например поля диапазона дат для ограничения запросов для поиска. Из этого не следует, что запросы такого вида неизвестны в Exchange, так как есть другие места, где программа помогает администраторам выбрать нужные данные, например при создании запроса получателя из динамической группы рассылки.
С другой стороны, можно утверждать, что «притупление» запросов поиска — явно неправильный шаг, поскольку исследователи лишаются возможностей запросов KQL. Действительно, любой интерфейс, представленный программным обеспечением, ограничен воображением разработчиков, но любой человек мог бы сообразить, что текущий интерфейс может существовать наряду с программным построителем запросов. По крайней мере, такое предположение было бы логичным.
Но, возможно, «чистый лист» для запросов поиска выбран намеренно. Это своеобразное предупреждение, что пользователям, плохо владеющим языком KQL, лучше оставить построение запросов профессионалам. Я не согласен с таким объяснением и рассматриваю сложившуюся ситуацию как возможность для совершенствования продукта. А пока, если вы нуждаетесь в помощи, чтобы понять, как строить запросы для поиска Exchange или SharePoint, следует обратиться к блоку Квентина Кристенсена (http://blogs.technet.com/b/quentin/archive/2014/07/30/using-search-properties-and-operators-with-ediscovery.aspx). Ведущий руководитель программы eDiscovery в компании Microsoft должен хорошо разбираться в этом вопросе.
