МЕХАНИЗМЫ ОБНАРУЖИВАЕМОСТИ И ПЕРЕЧИСЛЕНИЯ В ИЕРАРХИЧЕСКИ ЗАЩИЩЕННОЙ СИСТЕМЕ ХРАНЕНИЯ ДАННЫХ Российский патент 2010 года по МПК G06F21/22 G06F12/14 

Перекрестная ссылка на родственные заявки

По этой заявке испрашивается приоритет предварительной заявки на патент США с номером 60/657536, озаглавленной “DISCOVERABILITY AND ENUMERATION MECHANISMS IN A HIERARCHICALLY SECURE STORAGE SYSTEM” и поданной 28 февраля 2005. Данная заявка полностью включена в материалы настоящей заявки по ссылке.

Предшествующий уровень техники

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

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

Другое ограничение традиционных систем состоит в том, что принципал не может выполнять операции в отношении всех данных за раз. Например, ограничение в отношении операции “предоставить доступ к FABRIKAM\alice для всех данных в древовидной структуре с корнем в заданном узле” не будет возможным, поскольку действительными могут быть ограничения, которые ограничивают доступ к некоторым из данных в древовидной структуре. В некоторых традиционных системах такая операция реализуется скорее в пользовательском контексте, чем в системном контексте.

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

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

Сущность изобретения

Далее представлено упрощенное изложение сущности изобретения для обеспечения базового понимания некоторых аспектов изобретения. Это изложение сущности изобретения не является исчерпывающим обзором изобретения. Оно не предназначено для определения ключевых/критических элементов изобретения или очерчивания объема изобретения. Его предназначение полностью заключается в том, чтобы представить некоторые концепции изобретения в качестве введения к более подробному описанию, которое приведено далее.

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

Согласно еще одному аспекту обеспечивается составляющая искусственного интеллекта (AI), которая задействует вероятностный и/или основанный на статистике анализ для прогнозирования или логического выведения действия, автоматическое выполнение которого желательно для пользователя.

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

Перечень чертежей

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

Фиг. 2 - иллюстрация блок-схемы системы, которая включает в себя таблицу единственных экземпляров и таблицу дескрипторов безопасности в соответствии с аспектом изобретения.

Фиг. 3 - иллюстрация системы, которая классифицирует компоненты в системе типов как экземпляры типов общего контейнера и типов составного компонента в соответствии с аспектом изобретения.

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

Фиг. 5 - иллюстрация методики инициализации в соответствии с аспектом изобретения.

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

Фиг. 7 - блок-схема системы, которая использует основывающиеся на искусственном интеллекте механизмы в соответствии с аспектом изобретения.

Фиг. 8 - иллюстрация блок-схемы компьютера, выполненного с возможностью исполнения раскрытой архитектуры.

Фиг. 9 - иллюстрация блок-схемы иллюстративной вычислительной среды в соответствии с изобретением.

Подробное описание изобретения

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

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

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

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

В настоящем изобретении принимается во внимание иерархическое представление данных. Более конкретно, в данном изобретении принимается во внимание тот факт, что данные могут быть сгруппированы в разные папки и после этого помещены в разные контейнеры. Пользователи могут использовать эти контейнеры для организации своих данных. Например, данные могут быть организованы (например, сгруппированы) в категории, такие как картинки, музыка, документы и т.п. Кроме того, эти категории могут быть дополнительно организованы в контейнеры, тем самым устанавливая иерархическое представление данных. В качестве примера, среди картинок могут быть картинки “Моя семья”, “Мой отпуск”, “Моя свадьба” и т.д. Также могут существовать подкатегории в соответствии с иерархией.

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

Согласно аспекту изобретения дескриптор безопасности может обеспечить предоставление этих объектов для доступа к данным. В качестве примера, в соответствии с аспектом настоящего изобретения политика безопасности может обеспечить задание для папки “Мой отпуск” разрешения на доступ всем в группе “Моя семья”. Также внутри “Мой отпуск” пользователь может дополнительно ограничить доступ некоторым членам “Моей семьи” доступом к некоторой подпапке (например, “Моя поездка в Сиэтл”).

В соответствии с известными системами доступное исследование хранилища данных заканчивается в любой точке, когда достигается папка, для которой пользователь не имеет доступа на перечисление. Рассмотрим иерархию, в которой F1 содержит F2, которая содержит F3 в момент, когда пользователь достигает F2, в отношении которой не дано разрешение, у пользователя не будет возможности видеть данные внутри F3. Даже если пользователь может иметь доступ к F3, известные системы заблокируют обнаруживаемость, поскольку F3 содержится в F2, для которой не имеется разрешения - это ограничение. Согласно настоящему изобретению пользователю обеспечивается возможность иметь однородный доступ для исследования (например, обнаружения) и/или воспроизведения, тем самым позволяя использовать все данные в хранилище данных, посредством чего даются и реализуются разрешения. В соответствии с вышесказанным этот однородный доступ может быть обеспечен посредством политики безопасности, ассоциированной с каждым объектом в хранилище данных. Как должно быть понятно, каждая политика безопасности может быть ассоциирована с компонентом уровня строки.

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

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

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

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

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

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

Согласно настоящему изобретению разрешения можно распространять в “системном контексте”. Таким образом, даже если пользователь не имеет разрешения на промежуточную папку, если имеются разрешения для подчиненной, подподчиненной и т. д. древовидной структуры, эти разрешения могут быть распространены согласно настоящему изобретению. Этот аспект будет понятен лучше при рассмотрении вышеизложенного примера с F1, F2 и F3.

Продолжая с данным примером, даже если разрешений нет для F2, если разрешения имеются для F3, разрешения могут быть распространены от F1 к F3. В отличие от более ранних файловых систем, где проведено различие между атрибутами (например, именем файла, размером, датой создания) и данными (например, содержимым файла), в расширенных системах данных трудно провести различие между атрибутом и данными. Как таковые “компоненты” были созданы и используются для предоставления разрешений на доступ на “покомпонентной” основе независимо от элемента данных, являющегося атрибутом данных. Соответственно, согласно настоящему изобретению управление модели безопасности может быть конкретным образом упрощено, поскольку система не должна отслеживать два отдельных разрешения безопасности. Напротив, согласно одному аспекту только одно разрешение на “чтение” или одно разрешение на “запись” используется для каждого компонента вместо использования двух разрешений на “чтение” и двух разрешений на “запись” на каждый компонент.

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

Обратимся сначала к Фиг.1, на которой показана система 100, которая обеспечивает визуализацию представления содержимого хранилища файлов. В общем, система 100 может включать в себя составляющую 102 запроса и составляющую 104 безопасности уровня строки. При функционировании составляющая 102 запроса совместно с составляющей 104 безопасности уровня строки может идентифицировать компоненты в составляющей 106 данных, которые удовлетворяют политике безопасности или разрешению. После идентификации результирующий набор данных может быть визуализирован для пользователя и/или приложения. Например, в соответствии с вышеприведенным описанием согласно изобретению результирующий набор может быть визуализирован для пользователя посредством дисплея.

Со ссылкой на Фиг.2 приводится более подробная блок-схема составляющей 104 безопасности уровня строки. В частности, составляющая 104 безопасности уровня строки может включать в себя таблицу 202 дескрипторов безопасности и таблицу 204 единственных экземпляров. Каждая из этих таблиц будет пояснена более подробно ниже.

Составляющая 104 безопасности может обеспечить реализацию безопасности уровня строки. Когда пользователь подсоединяется к совместно используемому ресурсу (например, составляющей 106 данных), неявные определения представлений для каждого из типов данных могут быть определены в пределах соединения. Для добавления контекста к изобретению ниже приведено иллюстративное определение представления для типа “Contact” (“Контакт”).

CREATE VIEW [System.Storage.Contacts.Store].[Contact] AS

SELECT ItemId, TypeId, NamespaceName, ContainerId,

ItemSyncMetadata,

TREAT(Item AS [System.Storage.Contacts.Store].[Contact] AS Item, PathHandle,

EntityState, ObjectSize, ChangeInformation, PromotionStatus

FROM [System.Storage.Store].[Table!Item]

WHERE Item IS OF ([System.Storage.Contacts.Store].[Contact])

AND (@@ITEM_DOMAIN_IS_ROOT = 1

OR (PathHandle >= @@ITEM_DOMAIN AND PathHandle <

@@ITEM_DOMAIN_LIMIT))

Каждый компонент хранится в качестве строки и таблицах (202, 204) объектных сущностей. Вышеприведенное иллюстративное выражение может обеспечить отфильтровывание типов Contact из глобальной совокупности компонентов в хранилище. Неявным по отношению к данному отфильтровыванию является аспект, соответствующий управлению доступом, где пользователь будет видеть только те компоненты, которые являются читаемыми согласно дескрипторам безопасности в соответствующей строке.

Согласно данному примеру определение представления (VIEW) может включать в себя идентифицированный выше оператор “WHERE”, который ограничивает представление компонентами, которые являются контактами. Оставшаяся часть рассматриваемого примера может ограничивать доступ к компонентам от точки соединения. Следует понимать, что данное выше определение представления не включает в себя определение безопасности.

В соответствии с вышесказанным механизм безопасности представляет собой функцию безопасности уровня строки, хранящейся в таблицах (202, 204). Этот механизм применяется в качестве лежащего в основе табличного уровня представления и характеризуется эффектами распространения в отношении представления. Когда безопасность обеспечивается на построчной основе, строки, для которых пользователь не имеет доступа на чтение, не появляются в результирующем наборе, предоставляемом составляющей 102 запроса.

В модели файловой системы каждый “компонент” находится в строке и каждая строка имеет ассоциированную с ней безопасность. Механизм 104 безопасности уровня строки блокирует появление строк в результатах для тех строк, к которым пользователь не имеет доступа на чтение. Представление, при условии, что определение предоставлено для составляющей 102 запроса (как в приведенном выше примере), может ограничить визуализацию (например, просмотр) на основе, по меньшей мере частично, точки соединения. Таким образом, результирующий набор может быть пересечением этих двух ограничений. Следует понимать, что эти механизмы безопасности могут иметь место неявно в отношении определения запроса. В результате пользователь может быть отгорожен от выполнения каких-либо операций.

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

При функционировании поддерживаются две таблицы (202, 204) - таблица 202 дескрипторов безопасности и таблица 204 единственных экземпляров, относящаяся к соответствию между результатом хеширования (хеш-значением) (например, SHA-1) дескриптора безопасности и идентификатором дескриптора безопасности (SDID). Следует понимать, что этот SDID представляет собой уникальное значение. Согласно изобретению создание единственных экземпляров относится к механизму, согласно которому для каждого уникального дескриптора безопасности в хранилище система поддерживает соответствие между SDID и результатом хеширования дескриптора безопасности.

Таким образом, для каждой строки, вместо хранения дескриптора безопасности, хранится SDID, который ему соответствует. Согласно одному аспекту, когда пользователь создает компонент, он имеет выбор, обеспечить ли дескриптор безопасности или оставить его пустым. Если дескриптор безопасности оставлен пустым, дескриптор безопасности может быть наследован от родителя из создаваемого компонента. Когда же пользователь выбирает явным образом обеспечить дескриптор безопасности, система может объединить явно определенный дескриптор с дескриптором безопасности родителя для создания одного дескриптора.

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

Для определения того, существует ли дескриптор безопасности, согласно изобретению обращаются к таблице 204 единственных экземпляров, которая включает в себя отображение дескриптора безопасности на результат хеширования (например, хеширования по алгоритму SHA-1) дескриптора безопасности. Таким образом, для определения того, существует ли еще один компонент с тем же самым дескриптором безопасности, вычисляют результат хеширования рассматриваемого дескриптора безопасности. Система затем опрашивает таблицу 204 единственных экземпляров в отношении строки, чтобы определить, содержат ли какие-либо строки тот же результат хеширования (например, SHA-1) дескриптора безопасности. Если обнаружено совпадение, имеется высокая вероятность того, что он существует.

Далее, выполняется сравнение фактического дескриптора безопасности в целях верификации того, существует ли дескриптор безопасности. Если фактический дескриптор безопасности не является таким же, система сохраняет дескриптор безопасности независимо. Следует понимать, что система полагается только на алгоритм хеширования (например, SHA-1) для гарантирования неуникальности. Иными словами, если хешированное значение не совпадает с хешированным значением в таблице 204 единственных экземпляров, результатом определения будет то, что дескриптора безопасности не существует.

Имеются три свойства дескриптора безопасности - результат хеширования (значение, вычисленное математически на основе двоичного кода дескриптора безопасности), сам дескриптор безопасности (двоичный код) и SDID (целочисленное значение, которое указывает на дескриптор безопасности). Для каждой строки система хранит идентификатор (ID) этой конкретной строки, для которой дескриптор безопасности является соответствующим. Далее, в таблице 204 единственных экземпляров система задает соответствие между результатом хеширования (например, SHA-1) и SDID. В таблице 202 дескрипторов безопасности система задает соответствие между SDID и двоичным кодом.

Таким образом, таблица 204 единственных экземпляров и таблица 202 дескрипторов безопасности совместно задают полное отображение из результатов хеширования SHA-1 на SDID и на двоичный код. В плане эффективности эти две таблицы (202, 204) могут использоваться для выполнения проверки создания единственных экземпляров.

Дескриптор безопасности может иметь следующую логическую форму:

O:owner_sid

O:group_sid

D:dacl_flags(ace1)(ace2)… (acen)

S:sacl_flags(ace1)(ace2)… (acen)

В вышеприведенном примере О: идентифицирует владельца, G: идентифицирует группу, D: идентифицирует список разграничительного контроля доступа (DACL) (раздел дескриптора безопасности в канве данного раскрытия) и S: идентифицирует системный список контроля доступа (SACL). DACL представляет собой коллекцию объектных сущностей контроля доступа (АСЕ), каждая из которых может иметь следующий вид:

ace_type; ace_flags; rights; account_sid

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

Две внутренние таблицы (202, 204) могут использоваться для обеспечения хранения и управления доступом в системе. Согласно иллюстративному аспекту система может использовать таблицу 204 [System.Storage.Store].[Table!SecurityDescriptorSingleInstance] (например, таблицу единственных экземпляров) и таблицу 202 Sys.security_descriptors (например, таблицу дескрипторов безопасности). Таблица 202 Sys.security_descriptors представляет собой каталожное представление дескрипторов безопасности. Эти дескрипторы могут быть созданы или удалены, используя примитивы языка определения данных (DDL), обеспечиваемые сервером SQL (структурированного языка запросов). Таблица 204 единственных экземпляров может быть в соответствии с оптимизациями центрального процессорного устройства (CPU) и памяти в системе.

В соответствии с аспектом изобретения может быть обычным явлением, что значительное количество компонентов совместно используют одну и ту же политику безопасности или один и тот же дескриптор безопасности. Согласно одному примеру максимальный размер списка контроля доступа (ACL) составляет 64 кбайта, таким образом, размер заданного дескриптора безопасности по порядку величины составляет 128 кбайт. Следует понимать, что может быть неэффективным хранить величину такого размера с каждым компонентом при ее потенциально высокой степени общности. Следовательно, каждый уникальный дескриптор безопасности может храниться в таблице 202 Sys.security_descriptors, и соответствие между дескриптором и результатом его хеширования SHA-1 может поддерживаться в таблице 204 единственных экземпляров. В соответствии с вышесказанным SHA-1 должен гарантировать не уникальность выходных данных, а то, что вероятность конфликта фактически невероятна при наличии его большого диапазона выходных данных (например, 2¹⁶⁰). Поскольку таблица 204 единственных экземпляров может иметь самовосстанавливающуюся природу, может быть гарантировано, что система может автоматически восстанавливаться от повреждений или несоответствий.

Таблицы Item/Extension/Fragment/Link (Компонент/Расширение/Фрагмент/Связь) имеют вход для SDID, который может быть помечен атрибутом SECURITY (БЕЗОПАСНОСТЬ). Это может гарантировать, что весь доступ на чтение к этим таблицам и любые представления, построенные поверх этих представлений, проходят запрашивание проверки доступа (FILE_READ_DATA | FILE_READ_ATTRIBUTES). Строки в таблицах ItemExtension, Link и ItemFragment имеют тот же самый дескриптор безопасности, что и соответствующая строка в таблице Item.

Вышеописанный механизм можно считать составляющим ядро модели авторизации на пути чтения для современных файловых систем. Любая модель авторизации может наследуемым образом основываться на модели аутентификации. Согласно одному примеру, когда пользователь подсоединяется к хранилищу, этот пользователь может быть аутентифицирован (т.е. может быть подтверждено, что он заслуживает доверия) с использованием предпочтительных механизмов аутентификации операционной системы (например, NTLM (средство управления (менеджер) локальной сетью (LAN) NT, Kerberos). Совокупным результатом аутентификации может быть маркер безопасности, представляющий пользователя, который осуществляет доступ к файловой системе. Этот маркер может использоваться впоследствии для принятия решений при авторизации в отношении принципала.

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

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

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

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

Обратимся сперва к модели безопасности файловой системы, при этом согласно одному аспекту данные могут быть организованы в хранилище в качестве “компонента”, который может соответствовать наименьшей единице непротиворечивости в файловой системе. В отношении “компонента” можно независимым образом выполнять защиту, представление в линейную последовательность байтов, синхронизацию, копирование, резервное архивирование/восстановление и т.п. Следует понимать, что компонент файловой системы может быть описан как экземпляр типа, предком которого является тип System.Storage.Item (Система.Хранилище.Компонент), который является типом объектной сущности. Все компоненты в файловой системе могут храниться в едином глобальном экстенте (непрерывной области, резервируемой для определенного набора данных) компонентов. Также каждый компонент может иметь уникальный идентификатор, который является гарантированно уникальным для всех компонентов в заданном хранилище файловой системы.

Обратимся теперь к Фиг. 3, на которой изображена система 300. Система 300 соответствует контексту настоящего описания безопасности, а компоненты в системе 302 типов могут быть классифицированы как экземпляры типов общего контейнера и типов 306 составного компонента. Общие контейнеры 304 могут использоваться для моделирования папок или каких-либо других областей хранения иерархических коллекций данных. Типы 306 составных компонентов могут использоваться для моделирования единого логического модуля данных для приложения. Экземпляры этого типа могут обеспечивать семантику “все или ничего” для типичных операций с данными, таких как копирование, перемещение, синхронизация и т.п. Примеры этого включают в себя, но не в ограничительном смысле, почтовые сообщения, картинки, контакты и т.п. Экземпляры типов 306 составного компонента (обозначенные штриховыми линиями) могут быть дополнительно классифицированы как отображаемые в файл компоненты 308 (FBI) и неотображаемые в файл компоненты 308 (nFBI). Следует понимать, что доступ согласно Win32 семантически ограничен до компонентов FBI и общих контейнеров.

Нижеследующая иерархия контейнеров (например, древовидная структура) применяется к компонентам. Общие контейнеры 304 и составные компоненты 306 могут содержать любые другие типы компонентов, включая общие контейнеры. Для компонентов внутри этих дополнительных общих контейнеров также может независимым образом обеспечиваться защита. Компоненты FBI 308 не могут содержать других компонентов и таким образом образуют концевые узлы (листья) в иерархии.

Обратимся теперь к Фиг. 4, при этом следует понимать, что файловая система 400 может включать в себя две главные составляющие по обе стороны границы 402 доверия: составляющую 404 хранения и клиентскую составляющую 406. Согласно иллюстрации составляющая 404 хранения может включать в себя от одной до N объектных составляющих, где N - целое число. Объектные составляющие в количестве от 1 до N могут по отдельности или совместно упоминаться как объектные составляющие 408. Составляющая 404 хранения, которая выполняет хранение и извлечение объекта 408, может образовывать доверенную подсистему файловой системы между составляющей 404 хранения и клиентской составляющей 406.

Клиентская составляющая 406, которая может обеспечивать семантику программирования для платформы, обычно исполняется в пользовательских процессах. Следует понимать, что пользователи могут быть аутентифицированы во время соединения. Извлеченные объекты 408 (например, компоненты) могут материализоваться в клиентском пространстве. Согласно одному аспекту в отношении этих объектов 408 клиентом не задействуются никакие проверки безопасности или ограничения доступа. Согласно изобретению составляющая 404 хранилища может задействовать управление доступом (посредством составляющей 410 управления доступом), когда контекст программирования существует для составляющей 404 хранения. Ниже следует обсуждение аутентификации пользователя.

Файловая система 400 может предоставлять понятие принципала безопасности, который может выполнять действия в отношении компонентов 408, содержащихся в хранилище 404 файловой системы. Согласно аспектам настоящего изобретения принципалом безопасности может быть пользователь или группа безопасности. Соответственно, принципал безопасности может быть представлен идентификатором безопасности (SID).

Как показано на Фиг. 4, соединение со службой файловой системы находится в контексте принципала безопасности, который успешно аутентифицирован составляющей 410 управления доступом. Следует понимать, что аутентификация файловой системы (например, посредством составляющей 410 управления доступом) может быть производной механизма аутентификации операционной системы. Например, аутентификация файловой системы может быть производной аутентификации Windows, доступной в модели безопасности SQL (структурированного языка запросов). Например, следует понимать, что SQL предлагает еще один встроенный механизм аутентификации, называемый аутентификацией SQL, который может не поддерживаться в файловой системе.

Продолжая с данным примером, предпринятая попытка соединения со стороны пользователя Windows может быть аутентифицирована файловой системой 400 при использовании преимуществ предоставляемых Windows служб аутентификации, таких как Kerberos, NTLM и т.п. В рассматриваемом примере аутентифицированному пользователю ставится в соответствие “публичная” роль в SQL, которая используется для принятия решений при авторизации в хранилище 404. Согласно одному аспекту встроенный администратор (ВА) будет поставлен в соответствие администраторам SQL, предоставляющим административные привилегии SQL для ВА. Согласно альтернативному аспекту администрирование файловой системы может быть построено исключительно на основе использования примитивов файловой системы. Как таковой, ВА не будет членом группы администраторов SQL в этом альтернативном аспекте.

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

Обратимся теперь к обсуждению авторизации, при этом в соответствии с вышесказанным авторизация файловой системы может быть построена на основе безопасности уровня совместно используемого ресурса и безопасности уровня компонента. Термин “совместно используемый ресурс”, как он используется в настоящем описании, может относиться к псевдониму для компонента 408 в хранилище 410. Когда хранилище 410 создано, создается совместно используемый ресурс по умолчанию, который служит в качестве псевдонима для корневого компонента. Пользователи с достаточными привилегиями могут создавать совместно используемые ресурсы, служащие в качестве псевдонима для любого общего контейнера (например, компонента 408) в хранилище 410.

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

В качестве примера предположим, что пользователь подсоединяется к корневому совместно используемому ресурсу для доступа к foo (метасинтаксической переменной, которая может обозначать все, что угодно). Соответственно, доступ будет иметь следующий вид \\MachineName\StoreName\RootShare\…\foo (\\ИмяМашины \ИмяХранилища\КорневойСовместноИспользуемыйРесурс\…\foo). Аналогично, пользователь, подсоединенный к совместно используемому ресурсу, называемому AliceShare (Совместно Используемый Ресурс Алисы), будет осуществлять доступ к тому же самому объекту, как \\MachineName\AliceShare\…\foo. В этом примере эффективное разрешение в отношении компонента может быть функцией дескриптора безопасности на подсоединенном совместно используемом ресурсе и компоненте. Следует понимать, что первый из них определяет безопасность уровня совместно используемого ресурса, а второй из них определяет безопасность уровня компонента. Подробности в отношении каждого из этих механизмов безопасности, а также правил для компонования эффективных дескрипторов безопасности изложены ниже.

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

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

Подобно совместно используемым ресурсам Windows, значения по умолчанию для дескриптора безопасности совместно используемого ресурса допускают конфигурирование, используя установку реестра в LanManServer\DefaultSecurity\SrvsvcDefaultShareInfo.

Механизмы безопасности компонентов могут использовать дескрипторы безопасности для обеспечения управления доступом. Соответственно, согласно одному аспекту дескриптор безопасности может быть передан посредством интерфейсов прикладного программирования (API) в формате строки языка определения дескрипторов безопасности и сохранен в базе данных в упакованном бинарном формате под столбцом VARBINARY Sys.Security_Descriptors, таблицы дескрипторов безопасности (202 по Фиг. 2).

Новая таблица дескрипторов безопасности Sys.Security_Descriptors, 202 по Фиг.2, в соответствии с приведенным выше описанием, предназначена для содержания каждого уникального дескриптора безопасности (SecurityDescriptor), хранимого как упакованный бинарный дескриптор безопасности с уникальным ID (SDID) для использования в качестве внешнего ключа в базовых таблицах файловой системы. Например, таблица дескрипторов безопасности может иметь следующий вид:

SDID SecurityDescriptor VARBINARY 55 XXXXXXXXXX 56 XXXXXXXXXX

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

Обращаясь теперь к обсуждению представления и хранения дескрипторов безопасности и связанных с ними данных, следует отметить, что в соответствии с вышеприведенным описанием согласно изобретению используются две внутренние таблицы, которые могут содержать относящуюся к дескрипторам безопасности информацию, таблица дескрипторов безопасности (например, sys.security_descriptors) и таблица единственных экземпляров (например, [System.Storage.Store].[Table!SecurityDescriptorSingleInstance]).

Продолжая описание рассматриваемого примера, Sys.security_descriptors является каталожным представлением, поддерживаемым SQL. Этот двоичный код хранится в соответствующей строке с SDID.

Таблица единственных экземпляров может поддерживаться файловой системой. Она содержит отображение результата хеширования бинарного дескриптора безопасности в SDID, идентифицированный в вышеупомянутом представлении или таблице Sys.security_descriptors. В одном примере может использоваться алгоритм хеширования SHA-1. Согласно одному аспекту, если создано множество компонентов с одинаковыми дескрипторами безопасности, единый вход может существовать в обеих таблицах.

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

Согласно аспекту изобретения таблицы Item/Extension/Fragment/Link могут иметь запись для SDID, которая помечена атрибутом “безопасность”. Следует понимать, что это может гарантировать, что любой доступ на чтение к этим таблицам и любые представления, построенные поверх этих представлений, могут быть подвергнуты проверке доступа, запрашивающей (FILE_READ_DATA | FILE_READ_ATTRIBUTES). Следует также понимать, что таблица ItemExtension, Link и ItemFragment должна иметь ту же таблицу дескрипторов безопасности, что и таблица Item.

Фиг.5 иллюстрирует методику инициализации согласно аспекту настоящего изобретения. Хотя в целях простоты изложения одна или более иллюстрируемых здесь методик, например в форме блок-схемы последовательности операций, показаны и описаны как последовательность действий, следует понимать, что настоящее изобретение не ограничивается порядком действий, поскольку некоторые действия могут согласно изобретению происходить в другом порядке и/или одновременно с другими из показанных и описанных здесь действий. Например, для специалистов в данной области техники должно быть понятно, что методика может быть альтернативным образом представлена как последовательность взаимосвязанных состояний или событий, как, например, на диаграмме состояний. Помимо этого, не все из проиллюстрированных действий могут потребоваться для реализации методики согласно изобретению.

При построении базы данных модели во время процесса построения инициализируются структуры данных безопасности. На этапе 502 устанавливают таблицы. Согласно одному примеру установка таблиц может включать в себя установку Sys.server_principals, Sys.database_principals, Sys.server_role_members и Sys.database_role_members. На этапе 504 создают таблицу единственных экземпляров. В соответствии с нашим примером на этапе 504 может быть создана [System.Storage.Store].[Table!SecurityDescriptorSingleInstance].

На этапе 506 создают корневой дескриптор безопасности. Этот корневой дескриптор безопасности соответствует корню хранилища (например, администраторы имеют полный контроль). На этапе 508 создают дескрипторы безопасности уровня компонента. Например, на этапе 508 могут быть созданы дескрипторы безопасности для основных компонентов, так чтобы администраторы имели полный контроль и аутентифицированные пользователи имели доступ на чтение. На этапе 510 эти входы добавляют в таблицу единственных экземпляров.

Файловая система может поддерживать наследование списков контроля доступа (ACL). Например, от момента времени создания компонента (например, CreateItem или CreateComplexItems) дескриптор для компонента может быть вычислен, используя предоставленный дескриптор безопасности (если таковой вообще имеется), дескриптор безопасности родительского узла, тип компонента и маркер (например, маркер NT) вызывающей стороны.

Обращаясь теперь к обсуждению проверок доступа, следует отметить, что все интерфейсы прикладного программирования (API) обновления выполняют надлежащие проверки доступа посредством вызова [System.Storage.Store].[HasSecurityAccess]. API гарантирует, что вызывающей стороне предоставляется бит разрешения запроса на уровне совместно используемого ресурса, а также уровня дескриптора безопасности (например, компонента, записи). Согласно одному специфическому аспекту проверка доступа, выполняемая в отношении дескриптора безопасности (родительского узла), отличается (FILE_DELETE_CHILD) от оной (DELETE), выполняемой в отношении совместно используемого ресурса. Для других случаев упомянутые две проверки доступа могут быть согласованными.

Продолжая с данным примером, распространение ACL по древовидной структуре может выполняться, когда вызывается SetItemSecurity (с новым DACL или SACL) или MoveItem с новым родительским узлом. После выполнения надлежащих проверок доступа для гарантии того, что вызывающей стороне разрешено выполнить операцию, распространение ACL может быть реализовано в контексте файловой системы. Никаких проверок не выполняется в отношении субдревовидной структуры, для которой обновляются списки ACL.

Следует понимать, что изобретение может использовать асинхронное и/или синхронное распространение. Далее следует обсуждение синхронного распространения. Следует понимать, что корень субдревовидной структуры не имеет ничего общего с составными компонентами. Напротив, корень субдревовидной структуры является общим термином для описания узла, в котором вызывается SetItemSecurity или MoveItem.

В соответствии с синхронным распространением вычисляется новый дескриптор безопасности для корневого компонента. Если DACL или SACL не обновлены, возвращается SDID, если он обновлен для таблиц компонентов, расширений и связей и для системы. Вся субдревовидная структура компонентов блокируется, начиная с компонента. В данном примере нет необходимости блокировать какую-либо другую таблицу (Extension, Fragment, Link).

Далее, может быть создана временная таблица, которая содержит все компоненты в вышеупомянутом действии. Эта временная таблица может иметь следующие характеристики. Временная таблица может иметь ContainerId, ItemId и NewSdId. Также изначально NewSdId может быть NULL (нулем) для всей субдревовидной структуры, кроме ее корня.

Для каждого входа во временной таблице может быть вычислен новый SD, используя новый родительский SD, тип компонента и существующий SD компонента. В рассматриваемом примере может использоваться CreatePrivateObjectSecurityEx(SEF_AVOID_PRIVILEGE_CHECK | SEF_AVOID_OWNER_CHECK). Соответственно, временную таблицу можно обойти уровень за уровнем, каждый раз обрабатывая те строки, для которых вычислен новый родительский SD, и новый SDID для компонента является NULL. Согласно рассматриваемому примеру при таком подходе в таблице проходится один уровень за раз.

Количество итераций равно О (например, глубине древовидной структуры). Можно рассмотреть два аспекта. Во-первых, можно рассмотреть вычисление новых дескрипторов безопасности. Во-вторых, можно рассмотреть обновление дескрипторов безопасности для всех дочерних узлов. Согласно второму сценарию теоретическим пределом является О (например, количество дочерних узлов). Согласно первому сценарию, хотя и необязательно, он обычно равен О (глубине дерева). При необходимости можно создать новый дескриптор безопасности (например, в таблице единственных экземпляров и таблице Sys.security_descriptors). Далее, временная таблица SDID обновляется во временной таблице. Наконец, может быть обновлена таблица Item, Extension, Link и Fragment, используя данные, вычисленные во временной таблице.

Фиг. 6 иллюстрирует, что операции T/SQL, которые запрашивают представления главной таблицы, выполняются в пользовательском контексте, где управление доступом для операторов SELECT задействуется посредством безопасности уровня строки. Кроме того, вызовы API обновления хранилища файловой системы делаются в пользовательском контексте, но исполняются в системном контексте. Таким образом, реализация может задействовать проверки разрешений для вызывающей стороны.

Фиг.7 иллюстрирует систему 700, которая задействует искусственный интеллект (AI), что обеспечивает автоматизацию одной или более функциональных возможностей согласно настоящему изобретению. Настоящее изобретение (например, в связи с реализацией политик безопасности) может задействовать основывающиеся на AI схемы для выполнения различных его аспектов. Например, процесс для определения того, должен ли быть задан дескриптор безопасности и, если это так, какой уровень безопасности должен использоваться, может быть обеспечен посредством системы и процесса автоматического классификатора. Кроме того, если таблица единственных экземпляров и таблица дескрипторов безопасности (202, 204 по Фиг.2) расположены удаленно во множестве местоположений, классификатор может быть использован для определения того, какое местоположение будет выбрано для сравнения.

Классификатор является функцией, которая отображает входной вектор атрибутов, х = (х1, х2, х3, х4, xn), на степень уверенности в том, что эти входные данные принадлежат классу, то есть f(x) = степень_уверенности(класс). Такая классификация может использовать вероятностный или статистический анализ (например, разложение на анализ полезности и затрат) для прогнозирования или логического выведения действия, автоматическое выполнение которого желательно пользователю.

Метод опорных векторов (SVM) представляет собой пример классификатора, который может быть использован. Функционирование SVM основывается на нахождении гиперповерхности в пространстве возможных входных данных, которая пытается выделить инициирующий критерий из неинициирующих событий. Интуитивно, это делает классификацию корректной для тестирования данных, которые близки, но не идентичны обучающим данным. Могут использоваться другие подходы к классификации на основе прямых и непрямых моделей, которые включают в себя, например, простую схему Байеса, байесовские сети, деревья решений, нейронные сети, модели нечеткой логики и модели вероятностной классификации, обеспечивающие различные шаблоны независимости. Понятие “классификация”, как оно используется здесь, является включающим по отношению к статистической регрессии, которая используется для развития моделей приоритета.

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

На Фиг.8 изображена блок-схема компьютера, выполненного с возможностью исполнения раскрытой архитектуры. Для обеспечения дополнительного контекста для различных аспектов настоящего изобретения Фиг.8 и последующее описание предназначены для предоставления краткого общего изложения подходящего вычислительного окружения 800, в котором могут быть реализованы различные аспекты настоящего изобретения. Хотя изобретение было описано выше в общем контексте машиноисполняемых команд, которые могут выполняться на одном или более компьютерах, специалистам в данной области техники должно быть понятно, что изобретение также может быть реализовано в комбинации с другими программными модулями и/или как комбинация аппаратного и программного обеспечения.

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

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

Компьютер в типичном случае включает в себя разнообразие машиночитаемых носителей. Машиночитаемые носители могут представлять собой любые доступные носители, к которым компьютер может осуществить доступ, и включают в себя как энергозависимые, так и энергонезависимые, как сменные, так и несменные носители. В качестве примера, но не ограничения, машиночитаемые носители могут содержать компьютерные носители данных и коммуникационные среды. Компьютерные носители данных включают в себя как энергозависимые, так и энергонезависимые, как сменные, так и несменные носители, реализованные по любому способу или технологии для хранения информации, такой как машиночитаемые команды, структуры данных, программные модули или другие данные. Компьютерные носители данных включают в себя, но не в ограничительном смысле, оперативное запоминающее устройство (ОЗУ), постоянное запоминающее устройство (ПЗУ), электрически стираемое программируемое ПЗУ (EEPROM), флэш-память или память другой технологии, ПЗУ на компакт-диске (CD-ROM), цифровой универсальный диск (DVD) или другое оптическое дисковое хранилище, магнитные кассеты, магнитную ленту, магнитное дисковое хранилище или другие магнитные запоминающие устройства либо любой другой носитель, который может использоваться для хранения необходимой информации и к которому компьютер может осуществить доступ.

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

Согласно Фиг.8 иллюстративное окружение для реализации различных аспектов настоящего изобретения включает в себя компьютер 802, включающий в себя модуль 804 обработки данных, системную память 806 и системную шину 808. Системная шина 808 связывает составляющие системы, включая, но не в ограничительном смысле, системную память 806, с модулем 804 обработки данных. Модуль 804 обработки данных может представлять собой любой из разнообразных коммерчески доступных процессоров. Сдвоенные процессоры и другие многопроцессорные архитектуры могут использоваться в качестве модуля 804 обработки данных.

Системная шина 808 может относиться к любому из нескольких типов шинных структур, которые могут быть дополнительно подсоединены к шине памяти (с контроллером памяти или без него), периферийной шине и локальной шине с использованием любой из разнообразия коммерчески доступных шинных архитектур. Системная память 806 включает в себя постоянное запоминающее устройство (ПЗУ) 810 и оперативное запоминающее устройство (ОЗУ) 812. Базовая система ввода/вывода (BIOS) хранится в энергонезависимой памяти 810, такой как ПЗУ, электрически программируемое ПЗУ (EPROM), EEPROM, при этом BIOS содержит базовые процедуры, которые помогают переносить информацию между элементами внутри компьютера 802, например, во время запуска. ОЗУ 812 может также включать в себя высокоскоростное ОЗУ, такое как статическое ОЗУ, для кэширования данных.

Компьютер 802 дополнительно включает в себя внутренний накопитель на жестких дисках (HDD) 814 (например, соответствующий интерфейсам EIDE, SATA), который может быть также сконфигурирован для внешнего использования в подходящем корпусе (не показан), магнитный дисковод 816 для гибких дисков (FDD) (например, для считывания и записи в отношении сменной дискеты 818) и оптический дисковод (например, для считывания с диска 822 CD-ROM либо считывания или записи в отношении другого оптического носителя высокой емкости, такого как DVD). Накопитель 814 на жестких дисках, магнитный дисковод 816 и оптический дисковод 820 могут быть подсоединены к системной шине 808 посредством интерфейса 824 накопителя на жестких дисках, интерфейса 826 магнитного дисковода и интерфейса 828 оптического дисковода соответственно. Интерфейс 824 для реализаций с внешним накопителем включает в себя по меньшей мере одну или обе из интерфейсных технологий универсальной последовательной шины (USB) и IEEE 1394. Другие технологии подсоединения внешних накопителей также охватываются настоящим изобретением.

Накопители и дисководы и ассоциированные с ними машиночитаемые носители обеспечивают энергонезависимое хранение данных, структур данных, машиноисполняемых команд и т.п. Для компьютера 802 дисководы, накопители и носители приспосабливают хранение любых данных к подходящему цифровому формату. Хотя в вышеприведенном описании машиночитаемых носителей делается ссылка на HDD, сменную магнитную дискету и сменные оптические носители, такие как CD или DVD, специалистам в данной области техники должно быть понятно, что другие типы носителей, которые могут быть считаны компьютером, такие как накопители ZIP, магнитные кассеты, карты флэш-памяти, картриджи и т.п., могут также использоваться в иллюстративном вычислительном окружении и, кроме того, что любые такие носители могут содержать машиноисполняемые команды для выполнения способов согласно настоящему изобретению.

Некоторое количество программных модулей может храниться в накопителях и в ОЗУ 812, включая операционную систему 830, одну или более прикладных программ 832, другие программные модули 834 и данные 836 программ. Операционная система, прикладные программы, модули и/или данные могут быть кэшированы в ОЗУ 812 полностью или частично. Следует понимать, что изобретение может быть реализовано с разнообразными коммерчески доступными операционными системами или комбинациями операционных систем.

Пользователь может вводить команды или информацию в компьютер 802 посредством одного или более проводных/беспроводных устройств ввода, например клавиатуры 838 и координатно-указательного устройства, такого как мышь 840. Другие устройства ввода (не показаны) могут включать в себя микрофон, инфракрасный пульт дистанционного управления, джойстик, игровую панель, перо, сенсорный экран или т.п. Эти и другие устройства ввода зачастую подсоединяются к модулю 804 обработки данных через интерфейс 842 устройств ввода, который подключен к системной шине 808, но они также могут быть подсоединены посредством других интерфейсов, таких как параллельный порт, последовательный порт IEEE 1394, игровой порт, порт USB, инфракрасный порт и т.п.

Монитор 844 или другой тип дисплейного устройства также подсоединен к системной шине 808 через интерфейс, такой как видеоадаптер 846. В дополнение к монитору 844 компьютер в типичном случае включает в себя другие периферийные устройства вывода (не показаны), такие как громкоговорители, принтеры и т.п.

Компьютер 802 может функционировать в сетевом окружении, включающем в себя логические соединения с одним или более удаленными компьютерами, таком как удаленный компьютер(ы) 848, на основе проводной и/или беспроводной связи. Удаленный компьютер(ы) 848 может представлять собой рабочую станцию, компьютер-сервер, маршрутизатор, персональный компьютер, портативный компьютер, основывающееся на микропроцессоре развлекательное устройство, одноранговое устройство или другой общий сетевой узел и в типичном случае включает в себя многие или все из элементов, описанных относительно компьютера 802, хотя, в целях краткости, проиллюстрировано только запоминающее устройство/память 850. Изображенные логические соединения включают в себя возможность проводного/беспроводного соединения с локальной сетью (LAN) 852 и/или сетями большего масштаба, например глобальной сетью (WAN) 854. Такие сетевые окружения LAN и WAN являются обычными в офисах и компаниях и обеспечивают компьютерные сети масштаба предприятия, такие как интарсети, все из которых соединены с глобальной сетью связи, такой как Интернет.

При использовании в сетевом окружении LAN компьютер 802 соединяется с локальной сетью 852 через проводной и/или беспроводной коммуникационный сетевой интерфейс или адаптер 856. Адаптер 856 может обеспечивать проводную или беспроводную связь с LAN 852, которая может также включать в себя беспроводную точку доступа для осуществления связи с беспроводным адаптером 856.

При использовании в сетевом окружении WAN компьютер может включать в себя модем 858 или может быть подсоединен к коммуникационному серверу в WAN 854, или имеет другие средства для установления связи через WAN 854, например, через Интернет. Модем 858, который может быть внутренним или внешним и проводным или беспроводным устройством, подсоединяется к системной шине 808 через интерфейс 842 последовательного порта. В сетевом окружении программные модули, изображенные относительно компьютера 802 или их части, могут храниться в удаленном запоминающем устройстве/памяти 850. Следует понимать, что показанные сетевые соединения являются иллюстративными, и могут быть использованы другие средства установления линии связи между компьютерами.

Компьютер 802 выполнен с возможностью осуществления связи с любыми беспроводными устройствами или объектными сущностями, расположенными при работе в зоне покрытия беспроводной связи, такими как принтер, сканер, настольный и/или переносной компьютер, персональное цифровое информационное устройство, спутник связи, любая часть оборудования или местоположение, ассоциированное с обнаруживаемым беспроводным образом ярлыком (например, киоск, новостной стенд, комната отдыха) и телефон. Это включает в себя, по меньшей мере, беспроводные технологии Wi-Fi и Bluetooth^TM. Таким образом, связь может иметь заранее заданную структуру, как в случае с обычной сетью или простым прямым соединением между, по меньшей мере, двумя устройствами.

Wi-Fi, или верность беспроводной передачи информации, допускает соединение с Интернет с дивана дома, кровати в гостиничном номере или из конференц-зала на работе без использования проводов. Wi-Fi представляет собой беспроводную технологию, аналогичную используемой в сотовом телефоне, которая обеспечивает таким устройствам, например компьютерам, возможность посылать и принимать данные как в пределах помещения, так и за его пределы, в любом случае в пределах зоны покрытия базовой станции. Сети Wi-Fi используют радиотехнологии, называемые IEEE 802.11 (a, b, g и т. д.), для обеспечения возможности защищенного, надежного, быстрого беспроводного соединения. Сеть Wi-Fi может использоваться для соединения компьютеров друг с другом, с Интернет или проводными сетями (которые используют IEEE 802.3 или Ethernet). Сети Wi-Fi функционируют в нелицензируемых полосах радиочастот 2,4 и 5 ГГц при скоростях передачи данных 11 Мбит/с (802.11а) или 54 Мбит/с (802.11b), например, или с продуктами, которые содержат обе полосы частот (двухполосными), так чтобы сети могли обеспечивать рабочие характеристики реального мира, аналогичные характеристикам проводных сетей Ethernet стандарта 10BaseT, используемым во многих офисах.

На Фиг.9 схематически показана блок-схема иллюстративного вычислительного окружения 900 согласно настоящему изобретению. Система 900 включает в себя один или более клиентов 902. Клиент(ы) 902 может представлять собой аппаратное и/или программное обеспечение (например, потоки, процессы, вычислительные устройства). Клиент(ы) 902 может вмещать cookies (небольшие фрагменты данных о предыстории обращений пользователя к серверу(ам), автоматически создаваемые сервером(ами) на машине данного пользователя) и/или ассоциированную контекстную информацию посредством использования настоящего изобретения, например.

Система 900 также включает в себя один или более серверов 904. Сервер(ы) 904 также может представлять собой аппаратное и/или программное обеспечение (например, потоки, процессы, вычислительные устройства). Сервер(ы) 904 может вмещать потоки для выполнения преобразований посредством использования настоящего изобретения, например. Один из возможных видов связи между клиентом 902 и сервером 904 может быть реализован в форме пакетов данных, приспособленных для передачи между двумя или более компьютерными процессами. Пакет данных может включать в себя cookies и/или ассоциированную контекстную информацию, например. Система 900 включает в себя коммуникационную инфраструктуру 906 (например, глобальную сеть связи, такую как Интернет), которая может использоваться для обеспечения связи между клиентом(ами) 902 и сервером(ами) 904.

Связь может быть обеспечена посредством проводной (включая оптическое волокно) или беспроводной технологии. Клиент(ы) 902 в рабочем состоянии подсоединен к одному или более хранилищам 908 данных клиентов, которые могут использоваться для хранения информации, являющейся локальной по отношению к клиенту(ам) 902 (например, cookies и/или ассоциированной контекстной информации). Аналогично, сервер(ы) 904 в рабочем состоянии подсоединен к одному или более хранилищам 910 данных серверов, которые могут использоваться для хранения информации, являющейся локальной по отношению к серверу(ам) 904.

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

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

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

2. Система по п.1, в которой составляющая запроса обходит упомянутую иерархическую организацию данных.

3. Система по п.1, дополнительно содержащая составляющую, которая обеспечивает доверенную систему установления подлинности, используемую в связи с политикой реализации управления доступом.

4. Система по п.1, дополнительно содержащая составляющую визуализации, которая визуализирует ограниченную абстракцию.

5. Система по п.1, в которой каждая строка в хранилище данных содержит отдельный объект.

6. Система по п.5, в которой политика безопасности представляет собой по меньшей мере одно из списка контроля доступа (ACL) и дескриптора безопасности.

7. Система по п.6, в которой объект представляет собой по меньшей мере одно из элемента данных и контейнера, организованного в виде иерархической организации.

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

9. Система по п.1, в которой SDID представляет собой целочисленное значение, которое указывает на дескриптор безопасности.

10. Система по п.1, в которой результат хеширования генерируется посредством алгоритма хеширования SHA-1.

11. Система по п.1, дополнительно содержащая составляющую искусственного интеллекта (AI), которая использует вероятностный и/или статистический анализ для прогнозирования или логического выведения действия, автоматическое выполнение которого желательно пользователю.

12. Способ обеспечения управления доступом в отношении данных в хранилище данных, содержащий этапы, на которых
организуют данные в хранилище данных в соответствии с иерархической организацией;
обходят иерархическую организацию;
устанавливают политику безопасности в корне иерархической организации;
распространяют политику безопасности, используя основывающиеся на правилах логические средства и/или искусственный интеллект, на по меньшей мере один дочерний узел в иерархической организации на основе, по меньшей мере частично, дескриптора безопасности родительского узла;
формируют соответствующую точке соединения абстракцию хранилища данных;
применяют политику безопасности уровня строки для ограничения упомянутой абстракции поднабором данных на основе, по меньшей мере частично, политики безопасности уровня строки, причем данная политика безопасности уровня строки ассоциирует по меньшей мере одно из списка контроля доступа (ACL) и дескриптора безопасности с по меньшей мере одной строкой в хранилище данных;
ставят в соответствие представляющему собой двоичный код дескриптору безопасности идентификатор дескриптора безопасности (SDID) и ставят в соответствие идентификатору SDID результат хеширования этого SDID, так что полное отображение из результата хеширования на SDID и на двоичный код обеспечивается и используется для выполнения проверки создания единственных экземпляров; и
сохраняют SDID для каждой строки хранилища данных, так что, когда пользователем создается компонент, дескриптор безопасности наследуется от родительского узла создаваемого компонента в иерархической организации; и
визуализируют ограниченную абстракцию посредством дисплея для пользователя.

13. Способ по п.12, дополнительно содержащий этап, на котором устанавливают доверенную систему установления подлинности, используемую в связи с применением политики безопасности уровня строки.

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

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