В наше время пользователям редко предоставляется неограниченная свобода действий, поэтому представляется заманчивым получить возможность строить запросы по ключевым словам для обнаружения данных без вмешательства со стороны Exchange или SharePoint. Возможно, разработчики считают, что все администраторы прекрасно владеют языком запросов по ключевым словам. А может быть, это тонкий способ отпугнуть несведущих.
Возможность запускать операции поиска по разнообразным коллекциям почтовых ящиков Exchange и сайтов SharePoint, чтобы проникнуть в глубоко запрятанные секреты тех, кто предпочитает действовать незаметно, — в определенной степени цель технологии eDiscovery. В последнее десятилетие компания Microsoft приложила огромные усилия, чтобы обеспечить соответствие нормативным требованиям, и результаты в Exchange 2010 и SharePoint 2010 налицо. У первой реализации много достоинств, особенно в Exchange 2010, в основном потому, что действия по представлению данных для юридических разбирательств так часто сосредоточены на электронной почте. Со временем пространство eDiscovery совершенствуется, поэтому, разумеется, любой цифровой контент должен быть доступен по первому требованию судебных приставов.
Первым признаком кооперации были общие для Exchange 2013 и SharePoint 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.
Запросы для поиска находятся в центре всей этой работы, в том числе одноименная команда Search-Mailbox (http://thoughtsofanidlemind.com/2014/10/17/using-search-mailbox-to-look-for-items-with-a-specific-date/), до сих пор используемая для обнаружения и удаления вредного содержимого из почтовых ящиков. С ее помощью можно строить оптимальные индексы из баз данных почтовых ящиков, но они бесполезны, если нельзя создавать эффективные запросы для опроса индексов.
Поэтому иногда кажется странным, что Microsoft, не жалеющая средств для встраивания функций eDiscovery в Exchange и SharePoint, удовольствовалась элементарным графическим интерфейсом для построения запросов.
SharePoint Online и Exchange Online свойственна та же проблема, что и локальным версиям. Она заключается в следующем. Когда приходит время составить запрос для поиска, пользователь оказывается предоставленным самому себе. Целеустремленному исследователю приходится начинать с нуля, составляя запрос для проверки десятков миллионов сообщений и документов. Вследствие таких факторов, как увеличенные квоты почтового ящика, меньшая стоимость хранения данных и желание пользователей избегать рутинной работы по очистке цифрового контента, число элементов, индексируемых 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 должен хорошо разбираться в этом вопросе.