Механизмы обнаруживаемости и перечисления в иерархически защищенной системе хранения данных

Механизмы обнаруживаемости и перечисления в иерархически защищенной системе хранения данных

Иллюстрации

Показать все

Реферат

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

По этой заявке испрашивается приоритет предварительной заявки на патент США с номером 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 составных компонентов могут ис