Безопасность на основе области

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

 

Область техники

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

Предшествующая область техники

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

Вообще, чтобы проектировать базу данных, информация разбивается в некотором порядке, например, отдельные темы в библиотеке, и затем программа базы данных определяет, как темы связаны. Эти программы часто содержат запрос реляционной базы данных, используя обычный язык базы данных, типа Языка структурированных запросов (SQL). Прежде чем такие языки могут быть применены к данным, обычно принимается несколько решений относительно того, какие типы данных являются важными и как такие данные должны быть организованы. Например, эти решения могут включать в себя определение области охвата базы данных, чтобы решить, какие данные хранить там. Затем - определение таблиц, необходимое для разделения информации на отдельные темы (предметы), типа "Служащих" или "Заказов". Каждая тема затем будет таблицей в базе данных. Другие аспекты содержат определение соответствующих полей, которые необходимы, чтобы решить, какую информацию хранить в каждой таблице. Каждую категорию информации в таблице называют полем и отображают в виде столбца в таблице. Например, одним полем в таблице "Служащие" может быть Фамилия; другим может быть "Дата приема" на работу. Другое соображение должно определить отношения, например, решения, как данные в одной таблице связаны с данными в других таблицах. Проектировщики часто добавляют поля к таблицам или создают новые таблицы, чтобы пояснить отношения, по мере необходимости.

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

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

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

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

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

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

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

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

Краткое описание чертежей

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

Фиг.2 является диаграммой, иллюстрирующей примерное преобразование домена безопасности, в соответствии с аспектом данного изобретения.

Фиг.3 иллюстрирует альтернативное преобразование домена безопасности в соответствии с аспектом данного изобретения.

Фиг.4 иллюстрирует примеры интерфейсов безопасности в соответствии с аспектом данного изобретения.

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

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

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

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

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

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

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

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

Обратимся вновь к фиг.1, где система 100 безопасности объекта проиллюстрирована в соответствии с аспектом данного изобретения. Система 100 включает в себя реляционную базу данных 110 (например, SQL или базу данных другого типа), которая связана с компонентом (или компонентами) области 120, который определяет одну или более зон 130 безопасности объекта. Вообще, индивидуальные узлы иерархии объекта (например, см. один объект иерархии по номеру 140 ссылки) индивидуально не обновляются, когда делаются изменения безопасности объекта. Напротив, политики безопасности назначаются компонентом 120 области на соответствующие зоны безопасности 130. Отображая объекты в зону 130 безопасности вместо того, чтобы обновлять каждый объект индивидуально, число операций чтения - записи в базе данных 110 может быть уменьшено. Таким образом, компонент 120 области преобразует отображение политики безопасности от иерархии наследования, где каждый объект обновляется, к домену безопасности объектов, где зоны объектов совместно используют сходную политику безопасности. Этим способом меньший поднабор обновлений безопасности может быть распространен, когда политика безопасности объекта изменяется, посредством простого обновления сокращенного поднабора зон 130 безопасности, в противоположность обновлению каждого индивидуального объекта в классической иерархии наследования. Отметим, что понятия наследования могут использоваться для того, чтобы распространить политику в системе 100, однако, наследование происходит между зонами безопасности 130, вместо обычного наследования между объектами в дереве. Таким образом, наследование происходит между компонентами, которые моделируются в домене безопасности, а не объектном домене. Это подразумевает, что отображения безопасности для соответствующего объекта находятся между объектом и его ассоциированной зоной 130, а не явно установлены для отдельного объекта 140. Поэтому компонент 120 области обеспечивает безопасность к области идентифицированных объектов и по существу разделяет, разъединяет, или является независимым от обычных иерархий объекта, которые распространяют изменения безопасности ко всем объектам в иерархии.

Вообще, элементам в базе данных 110 могут быть назначены (Идентификатор) ID для дескриптора безопасности. База данных включает в себя [Table!Item] таблицу, имеющую столбец SDID (ID Дескриптора Безопасности). Этот SDID является уникальным ID дескриптора безопасности, который сохранен и поддерживается в скрытой таблице системы SQL, например. Системная таблица может быть выдана через открытое представление (например, Sys.Security_Descriptor). Следующая таблица включает в себя упрощенную иллюстрацию того, как дескриптор безопасности может быть включен или связан с основной объектной моделью:

[Table!Item]: ассоциирует элемент с ID дескриптора безопасности

_ItemID	…	_SDId	…

[Sys.Security_Descriptor] Отображает ID на содержание дескриптора безопасности

Sd_id	Тип	Дескриптор безопасности

Чтобы эффективно назначать ID дескриптора безопасности (ID SD) элементу объекта, технология области SD базируется частично на том наблюдении, что большинство элементов объекта имеет тенденцию совместно использовать один и тот же дескриптор безопасности. Область SD является набором элементов (которые не должны быть непрерывными, как в обычных системах), которые совместно используют один тот же или подобный ID SD. Как правило, все элементы в [Table!Item], показанной выше, могут быть группированы в различные области SD. Отношения областей SD могут быть установлены таким образом, что SD одной области SD может унаследовать SD другой области SD в домене безопасности, описанном выше. В основном, дерево области SD установлено так, что является сопоставимым соответствующему дереву объектных элементов, но с меньшим количеством узлов, как будет показываться со ссылками на Фиг.2 и 3 ниже. Дерево области SD таким образом может использоваться для того, чтобы эффективно обновить SD элемента. Обычно, когда дерево элемента безопасности создается, три области SD создаются, чтобы назначить SD по существу всем элементам в дереве. Таким образом, одна область SD предназначена для корневого элемента (где явная SD определена), другая область SD предназначена для соответствующих контейнерных элементов, и последняя SD предназначена для неконтейнерных элементов.

Обратимся теперь к фиг.2 и 3, где примерные преобразования 200 и 300 домена безопасности иллюстрированы в соответствии с аспектом данного изобретения. В 200 на фиг.2 проиллюстрированы узлы дерева объектов, где черный узел 210 является корневым элементом; серые узлы в 220 являются контейнерными элементами, и белые узлы в 230 являются неконтейнерными элементами. Когда дескриптор безопасности элемента (SD) обновляется (например, изменяя владельца SD, группу, список управления доступом и т.д.), область SD, которой элемент принадлежит, может быть разбита на три подгруппы или поднабора, как проиллюстрировано позицией 240. Изменения безопасности обычно эффективны через данные, называемые записями управления доступом (АСЕ), которая может иметь явную или неявную форму. Когда явные АСЕ добавляются к SD элемента, новые области SD могут быть созданы вокруг этого элемента. В этом случае создаются три области SD, одна для самого элемента (где явные АСЕ добавлены), одна для его контейнерных потомков, и одна для его неконтейнерных потомков. Обратимся к фиг.3, где проиллюстрирована более сложная ситуация, когда нераспространенная явная АСЕ добавлена к SD для элемента в 310, когда пять новых областей созданы вокруг элемента, как проиллюстрировано позицией 320. В этом случае, одна область создана для самого элемента (где явная АСЕ добавлена) 330, одна область для ее прямых контейнерных потомков, одна область для ее прямых неконтейнерных потомков в 350, одна область для ее непрямых контейнерных потомков в 360 и одна область для ее непрямых неконтейнерных потомков в 370.

Суммируя Фиг.2 и 3, новые области могут быть созданы, когда SD элемента обновляется явно (не через наследование). Обычно 3 или 5 новых областей (другие возможные количества) создаются в зависимости от обновлений, сделанных к SD. Пять областей SD создаются, если нераспространения АСЕ добавляется, и три области SD создаются вообще в других случаях. Как пример, возьмем элемент, SD которого содержит ненаследственные свойства (неунаследованные АСЕ в большинстве случаев) в качестве корневого элемента. Как отмечено выше, корневой элемент контейнерного типа может иметь 3 или 5 областей SD в зависимости от типов явных АСЕ в SD. Неконтейнер может иметь свою собственную область SD, если его SD имеет явные свойства. Если все явные свойства SD корневого элемента удалены, то области SD, принадлежащие этому корневому элементу, могут быть сокращены (свернуты) в SD его родительского элемента, который тогда уменьшает индивидуальные обновления безопасности объекта. Каждая область SD может быть представлена как строка в таблице Security_Hierachy, типа следующего примера:

[Table!SecurityJHierachy]: Хранит отношения наследования SD и устанавливает элементы, чтобы совместно использовать один и тот же дескриптор безопасности.

_SDIdParent	_SDId	_RootItemID	_IsContainer	_Scope

Столбцы вышеупомянутой таблицы могут включать в себя _SDId, который является идентификатором ID области 3D, область SDIdParent, которая является ID SD, откуда исходят унаследованные свойства безопасности, область _RootItemID, которая является ID элемента, где определена явная SD, область IsContainer, которая равна 1, если SD применяется к контейнеру, или 0 для неконтейнера, и область _Scope, которая закодирована следующим образом: 0: SD применяется к корневому элементу. 1: SD только применяется к потомкам корневого элемента (RootItem). 2: SD применяется к прямым потомкам корневого элемента. 3: SD применяется к непрямым потомкам корневого элемента.

Отметим, что, когда база данных инициализируется, три дескриптора безопасности значения по умолчанию могут быть созданы, если желательно; один дескриптор для верхнего корневого элемента RootItem, один дескриптор для всех контейнерных потомков, и один дескриптор для всех неконтейнерных потомков. Следовательно, три области SD на верхнем корневом элементе могут быть также созданы. Как правило, все элементы, впоследствии созданные в томе, могут иметь одну из SD как ее значение по умолчанию SD. Когда явные АСЕ добавляются к элементу, новые области SD могут быть созданы, как описано выше.

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

Ниже дается краткое описание для интерфейсов безопасности 410-430:

public string GetSDDLSecurity() - извлекает весь дескриптор безопасности для элемента в формате строки SDDL. Включает в себя унаследованные и явные списки Access Control.

public GenericSecurityDescriptor GetSecurit() - извлекает весь дескриптор безопасности для элемента в формате Управляемого класса ACL

GenericSecurityDescriptor

public void SetSDDLSecurity(string sd, SECURITY_INFORMATION si) устанавливает дескриптор безопасности элементу. Эта функция игнорирует унаследованные АСЕ. Восстанавливает унаследованные АСЕ от его родителя и других удерживаемых (фиксированных) связей. Может быть вызвана для того, чтобы установить владельца, группу, флаг управления или явные АСЕ.

SECURITY_INFORMATION определяет, какая часть дескриптора безопасности должна быть обновлена.

public void SetSecurity (GenericSecurityDescriptor gsd,

SECURITY_INFORMATION si) - устанавливает дескриптор безопасности элементу. Принимает управляемый класс ACL как входной параметр.

public void AddHoldingLink (Guid itemId) - Обновляет дескриптор безопасности для элемента при добавлении новой удерживающей связи с элементом.

public void RemoveHoldingLink (Guid itemId) - Обновляет дескриптор безопасности элемента, при удалении новой удерживающей связи из элемента.

Public string GetUserEffectiveSecurity() - Извлекает дескриптор безопасности для элемента, который содержит АСЕ, релевантные текущему контексту безопасности.

Фиг.5 иллюстрирует компонент 500 области обработки в соответствии с аспектом данного изобретения. В 510 обеспечивается определение областей. Они содержат область дескриптора безопасности (SD), которая является набором элементов, которые совместно используют один и тот же SD. Набор элементов не должен формировать непрерывное дерево. Строка иерархии безопасности (SH) является строкой в [Table!Security Hierachy] упоминаемой ниже таблицы. Каждая область SD должна иметь строку SH в таблице.

_ParentDId	_SDId	_RootItemid	_IsContainer	_Scope
SD0	SD1	ItemId	0	3

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

В 520 описаны соображения слияния и создания области. В этом аспекте одна новая область SD может быть создана при следующих условиях:

1. Изменения SD, сделанные на неконтейнерном элементе.

Три новых области SD могут быть созданы при следующих условиях:

1. Изменения SD, сделанные на контейнерном элементе, и

2. Изменения SD не содержат нераспространенное АСЕ.

Пять новых областей SD могут создаваться при следующих условиях:

1. Изменения SD, сделанные на контейнерном элементе, и

2. Изменения SD содержат нераспространенные АСЕ.

Области SD могут быть слиты при следующих условиях:

1. Родительская SD исполняет наследование SD, исключая из работы дочернюю АСЕ или

2. Явные АСЕ удалены из SD.

В 530 предоставляются различные понятия, которые могут использоваться в следующих алгоритмах, описанных относительно фиг.6. Эти нотации содержат:

_Item или * - текущий элемент, к которому система применяет операции.

SDId (х) или SDId - sd_id дескриптора безопасности для элемента х.

SDId_NC (х) или SDId_NC - SDId применяется к неконтейнерным дочерним объектам элемента х.

SDId_C (х) или SDId_C - SDId применяется к контейнерным дочерним объектам элемента х.

SDId_NC2 (х) или SDId_NC2 - SDId применяется к прямым неконтейнерным дочерним объектам элемента х.

SDId_C2 (х) или SDId_C2 - SDId применяется к прямым контейнерным дочерним объектам элемента х.

SDId_NC3 (х) или SDId_NC3 - SDId применяется к непрямым неконтейнерным дочерним объектам элемента х.

SDId_C3 (х) или SDId_C3 - SDId применяется к непрямым контейнерным дочерним объектам элемента х.

SHRow (х, i, j) - строка в таблице [Table! Security_Hierachy], где _RootItemId=x, _IsContainer=i, _Scope=j

UpdateItemSD (OldSDId, NewSDId, Rootltem, IsContainer,

Scope) - обновляют SDId всех элементов типа (IsContainer), текущий SDId которого=OldSDId, наследователь - Rootltem в области Scope к NewSDId.

UpdateSDBlob (SDId) - Обновляют содержание дескрипторов безопасности этого SDId и его потомков, если SDId его потомков не формируют цикл с этим SDId. Например, когда удерживающая связь (с SDO) добавляется к элементу файла (с SD1), который не имеет своей собственной строки в таблице [Table!Security Hierachy], три строки будут созданы (SDO, SD1, Item, 0, 0), (SD1, SDO, Item, 0, 1), (SD1, SDO, Item, 1, 1). Здесь повторно используют SDO для дочерних элементов этого элемента, чтобы значительно уменьшить число обновлений в таблица [Table!Item].

UpdateSDId (SDId, SDId_New) - Обновляют строки текущего элемента в [Table!Security_Hierachy], где _SDId=SDId, чтобы установить _SDId=SDId New.

UpdateParentSDId (SDIdPar, SDIdParJSfew) - обновляют строки [Table!Security_Hierachy], где _ParentSDId=SDIdPar, чтобы установить _ParentSDId=SDIdPar_New.

CreateNewSD (SDId) - создают новую SD из текущего SD плюс сделанные изменения (добавить/удалить АСЕ, добавить/удалить удерживающую связь).

Фиг.6 иллюстрирует примерные алгоритмы 600 обработки области в соответствии с аспектом данного изобретения. В этом аспекте, по меньшей мере три отдельных или объединенных алгоритма 600 могут использоваться, чтобы произвести обработку области. Они содержат дескриптор безопасности набора в 610; добавление удерживающей связи 620; и алгоритм удаления удерживающей связи в 630. Относительно дескриптора безопасности набора 610, есть различные способы изменить дескриптор безопасности объекта, которые, по меньшей мере, содержат:

- добавить/удалить ненаследственные явные АСЕ.

- добавить/удалить наследственные явные АСЕ, которые применяются к этому элементу и всем его потомкам.

- добавить/удалить наследственные явные АСЕ, которые применяются только к его потомкам.

- добавить/удалить наследственные явные АСЕ, которые применяются только к этому элементу и его прямым потомкам.

- добавить/удалить наследственные явные АСЕ, которые применяются только к дочерним контейнерам.

- добавить/удалить наследственные явные АСЕ, которые применяются только к дочерним объектам.

- добавить/удалить наследственные явные АСЕ, которые применяются только к некоторому типу объектов.

- изменить владельца дескриптора безопасности.

- изменить группу дескриптора безопасности.

- изменить флаги управления дескриптором безопасности.

i. Остановить наследование АСЕ.

ii. Начать наследование АСЕ

iii. Изменить другие флаги управления, применяя только к этому элементу.

В 620, когда удерживающая связь добавляется к элементу, дескриптор безопасности в отношении этого элемента может или, возможно, не может быть изменен в зависимости от того, имеет ли удерживающая связь наследственные АСЕ и имеет ли SD на этом элементе флаг SE_DACLE_PROTECTED. Однако таблица [Table!Security_Hierachy] должна быть обновлена. Когда удерживающая связь добавлена к элементу, три новых строки для элемента должны быть добавлены в таблицу [Table!Security_Hierachy], если элемент не имеет назначенной строки. Для сокращения обновления в таблице [Table!Item], следующие форматы могут использоваться для создания этих строк: (SDO, SDl, *, 0, 0), (SDl, SDO, *, 0, 1), (SDl, SDO, *, 1, 1) то, где SDO - старый SDId целевого элемента удерживающей связи, SDl, - новый SDId целевого элемента. В соответствии с этой схемой, необходимо только обновить исходный элемент в таблице [Table!Item].

Основываясь на этой схеме, если явная ненаследственная АСЕ добавлена к этому элементу позже, не выполняют обновление в таблице [Table!Item]. В 630, можно предположить, что SDId дескриптора безопасности удерживающей связи, который должен быть удален, является SDId_HD. В случае удаления удерживающей связи, области SD могут разрушиться, и таким образом строки в [Table!Security_Hierachy] могут быть слиты.

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

Переходя к 710 из фиг.7, дескрипторы безопасности для соответствующих объектов в базе данных разъединены или не связаны с классической иерархией объекта, посредством удаления требования для каждого объекта, который должен быть обновлен (в отношении безопасности) ввиду любого потенциального обновления в иерархии. В 720 используются один или более дескрипторов безопасности для того, чтобы определить области объекта для объектов, постоянно находящихся в базе данных. Как отмечено выше, это может включать в себя сокращение или слияние данных безопасности объекта от подобных или несходных деревьев объекта, чтобы определить области безопасности или поднаборы объектов, которые подписались на аналогичные данные безопасности области. Кроме того, такие данные области могут быть определены в строке базы данных, включая получающиеся отношения к другим объектам, принадлежащим области. В 730, политиками безопасности объекта установлены для выбранных областей в базе данных. Как отмечено выше, в зависимости от типа (Подразумеваемого/Явного) записи управления доступом и местоположения изменения безопасности в иерархии объекта, различные области безопасности могут быть созданы исходя из таких параметров настройки. В 740, преобразования происходят между классическими доменами объектов и доменами безопасности согласно данному изобретению, чтобы распространить изменения безопасности в области действия базы данных. Это может включать в себя создание поднаборов области вокруг заданного объекта в то время, когда изменение безопасности требуется для объекта (например, создание трех или пяти областей в зависимости от типа изменения безопасности).

Со ссылками на фиг.8, примерная среда 810 для того, чтобы осуществить различные аспекты изобретения, включает в себя компьютер 812. Компьютер 812 включает в себя процессорный модуль 814, системную память 816 и системную шину 818. Системная шина 818 подсоединяет компоненты системы, включая в себя, но не ограничиваясь, системную память 816 к процессорному модулю 814. Процессорный модуль 814 может быть любым из различных доступных процессоров. Двойные микропроцессоры и другая многопроцессорная архитектура также могут использоваться как процессорный модуль 814.

Системная шина 818 может быть любым из нескольких типов шинной структуры, включая в себя шину памяти или контроллер памяти, периферийную шину или внешнюю шину, и/или локальную шину, используя любую из разнообразия доступной шинной архитектуры, включая в себя, но не ограничиваясь, 11-битовую шину, шину архитектуры Промышленного стандарта (ISA), шину микроканальной архитектуры (МСА), усовершенствованную ISA (EISA), встроенный интерфейс накопителей (IDE), локальную шину VESA (VLB), Стандарт PCI (PCI), универсальную последовательную шину (USB), расширенный графический порт (AGP), шину Международной ассоциации производителей плат памяти для персональных компьютеров (PCMCIA) и интерфейс малых компьютерных систем (SCSI).

Системная память 816 включает в себя энергозависимую память 820 и энергонезависимую память 822. Базовая система ввода-вывода (BIOS), содержащая основные подпрограммы для того, чтобы передавать информацию между элементами в компьютере 812, например, в течение запуска, сохранена в энергонезависимой памяти 822. Посредством иллюстрации, но не ограничения, энергонезависимая память 822 может включать в себя постоянное запоминающее устройство (ROM), программируемую ROM (PROM), электрически программируемую ROM (EPROM), электрически стираемую ROM (EEPROM), или флэш-память. Энергозависимая память 820 включает в себя оперативную память (RAM), которая действует как внешняя кэш-память. Посредством иллюстрации, но не ограничения, оперативная память доступна во многих формах, типа синхронной оперативной памяти (SRAM), динамическая оперативная память (DRAM), синхронная динамическая оперативная память (SDRAM), динамическая оперативная память двойной синхронной скорости передачи данных (DDR RAM), расширенная синхронная динамическая оперативная память (ESDRAM), динамическая оперативная память Synchlink (SLDRAM), и оперативная память Rambus прямого доступа (DRRAM).

Компьютер 812 также включает в себя сменные/несменные, энергозависимые/энергонезависимые компьютерные носители данных. Фиг.8 иллюстрирует, например, память 824 на диске. Память 824 на диске включает в себя, но не ограничена, такие устройства как магнитный дисковод, накопитель на гибких магнитных дисках, накопитель на магнитной ленте, диск Jazz, диск Zip, диск LS-100, плата флэш-памяти, или memory stick. Кроме того, память 824 на диске может включать в себя носители данных отдельно или в комбинации с другими носителями данных, включая в себя, но не ограничиваясь, оптический дисковод, типа устройства ROM на компакт-диске (CD-ROM), записываемый компакт-диск (диск CD-R), переперезаписываемый компакт-диск (диск CD-RW) или цифровой универсальный диск ROM (DVD-ROM). Чтобы облегчить подключение устройств памяти 824 на диске к системной шине 818 обычно используется интерфейс сменной или несменной памяти, типа интерфейса 826.

Необходимо оценить, что Фиг.8 описывает программное обеспечение, которое действует как посредник между пользователями и основными компьютерными ресурсами, описанными в подходящей среде 810. Такое программное обеспечение включает в себя операционную систему 828. Операционная система 828, которая может быть сохранена в памяти 824 на диске, действует, чтобы управлять и распределить ресурсы компьютерной системы 812. Системные приложения 830 используют управление ресурсами операционной системы 828 через программные модули 832 и программные данные 834, сохраненные или в системной памяти 816, или в памяти 824 на диске. Необходимо оценить, что данное изобретение может быть осуществлено с различными операционными системами или комбинациями операционных систем.

Пользователь вводит команды или информацию в компьютер 812 через устройство(а) 836 ввода данных. Устройства ввода данных 836 содержат, но не ограничены, устройство управления позицией, типа мыши, координатного шара, пера, сенсорной клавиатуры, клавиатуры, микрофона, джойстика, игровой клавиатуры, спутниковой антенны, сканера, телевизионной платы, цифровой камеры, цифровой видеокамеры, вебкамеры и т.п. Эти и другие устройства ввода данных соединяются с процессором 814 через системную шину 818 через порт(ы) интерфейса 838. Порт(ы) интерфейса 838 включает в себя, например, последовательный порт, параллельный порт, игровой порт, и универсальную последовательную шину (USB). Устройство(а) вывода 840 использований часть того же самого типа портов, как и устройство (а) ввода данных 836. Таким образом, например, порт USB может использоваться для того, чтобы обеспечить ввод в компьютер 812, и вывод информации из компьютера 812 на устройство вывода 840. Адаптер вывода 842 обеспечивается для того, чтобы иллюстрировать, что есть некоторые устройства вывода 840, типа монитора, динамиков, и принтеры, среди других устройств вывода 840, которые требуют специальных адаптеров. Адаптеры вывода 842 содержат, в качестве иллюстрации, но не ограничения, видео и звуковые платы, которые обеспечивают средство подключения между устройством вывода 840 и системной шиной 818. Необходимо отметить, что другие устройства и/или системы устройств обеспечивают обе возможности ввода и вывода типа удаленного компьютера(ов) 844.

Компьютер 812 может работать в сетевом окружении, используя логические подключения к одному или более удаленным компьютерам, типа удаленного компьютера(ов) 844. Удаленный компьютер(ы) 844 может быть персональным компьютером, сервером, маршрутизатором, сетевым PC, рабочей станцией, прибором на основе микропроцессора, одноранговым устройством или другим обычным сетевым узлом и т.п., и типично включает в себя многие или все элементы, описанные относительно компьютера 812. В целях краткости, только запоминающее устройство 846 иллюстрировано с удаленным компьютером(ами) 844. Удаленный компьютер(ы) 844 логически связан с компьютером 812 через сетевой интерфейс 848 и затем физически связан через коммуникационное подключение 850. Сетевой интерфейс 848 охватывает сети коммуникации, типа локальных сетей (LAN) и глобальные сети - (WAN). Технологии LAN содержат интерфейс передачи данных по оптоволокну (FDDI), распределенный интерфейс передачи данных (CDDI), Ethernet/IEEE 802.3, Token Ring/IEEE 802.5 и т.п. Технологии глобальной сети содержат, но не ограничены, двухточечные связи, сети с коммутацией каналов как цифровые сети с предоставлением комплексных услуг (ISDN) и изменения к ним, сети пакетной коммутации и цифровые абонентские линии (DSL).

Коммуникационное подключение(я) 850 относится к аппаратным средствам/программному обеспечению, используемым для того, чтобы соединить сетевой интерфейс 848 с шиной 818. В то время как коммуникационное подключение 850 показывают для иллюстративной ясности в компьютере 812, оно может также быть внешним к компьютеру 812. Аппаратные средства/программное обеспечение, необходимые для подключения к сетевому интерфейсу 848, содержат, только с целью примера, внутренние и внешние технологии, типа модемов, включая в себя регулярные телефонные модемы, кабельные модемы и модемы цифровой абонентской линии, адаптеры цифровой сети комплексного обслуживания и платы Ethernet.

Фиг.9 является схематической блок-схемой типовой компьютерной среды 900, с которой может взаимодействовать данное изобретение. Система 900 включает в себя одного или более клиента(ов) 910. Клиент(ы) 910 могут быть аппаратными средствами и/или программным обеспечением (например, потоками, процессами, компьютерными устройствами). Система 900 также включает в себя один или более серверов 930. Сервер(ы) 930 могут также быть аппаратными средствами и/или программным обеспечением (например, потоками, процессами, компьютерными устройствами). Серверы 930 могут размещать потоки для того, чтобы выполнить, например, преобразования, используя данное изобретение. Один возможный обмен между клиентом 910 и сервером 930 может быть в форме пакета данных, приспособленного для передачи между двумя или более компьютерными процессами. Система 900 включает в себя коммуникационную структуру 950, которая может использоваться для того, чтобы облегчить связь между клиентом(ами) 910 и сервером(ами) 930. Клиент(ы) 910 функционально связан(ны) с одним или более хранилищами клиентских данных 960, которые могут использоваться для хранения информации, локальной для клиента(ов) 910. Точно так же сервер(ы) 930 функционально связан(ны) с одним или более хранилищами серверных данных 940, которые могут использоваться для хранения информации, локальной для сервера 930.

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

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

2. Система по п.1, в которой компонент области обеспечивает преобразование из домена объектов в домен безопасности.

3. Система по п.2, в которой компонент области включает в себя по меньшей мере один дескриптор безопасности, который определяет по меньшей мере одну из зон безопасности.

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

5. Система по п.1, в которой изменения в безопасности обнаруживаются посредством записи управления доступом (АСЕ).

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

7. Система по п.1, дополнительно содержащая таблицу, которая связывает элемент объекта с идентификатором дескриптора безопасности.

8. Система по п.7, дополнительно содержащая таблицу, которая сопоставляет идентификатор дескриптора безопасности с содержанием дескриптора безопасности.

9. Система по п.1, дополнительно содержащая по меньшей мере одно из элемента корневого узла, потомка, узла, контейнерного элемента и неконтейнерного элемента.

10. Система по п.1, дополнительно содержащая компонент для распространения изменения безопасности между зонами безопасности.

11. Система по п.1, дополнительно содержащая по меньшей мере один интерфейс для взаимодействия с компонентом области или упомянутой реляционной базой данных.

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

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

14. Считываемый компьютером носитель информации, хранящий считываемые компьютером команды для реализации компонентов системы по п.1.

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