СИСТЕМА И СПОСОБЫ ОБЕСПЕЧЕНИЯ УЛУЧШЕННОЙ МОДЕЛИ БЕЗОПАСНОСТИ Российский патент 2015 года по МПК G06F21/62 

ПЕРЕКРЕСТНЫЕ ССЫЛКИ

Настоящая заявка на патент притязает на приоритет заявки на патент США №10/691999 озаглавленной "SYSTEM AND METHOD PROVIDING ENHANCED SECURITY MODEL", поданной 23 октября 2003 г., которая включена в настоящее описание во всей своей полноте в качестве ссылки.

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

УРОВЕНЬ ТЕХНИКИ

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

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

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

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

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

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

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

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

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

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

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

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

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

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

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

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

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

Обратимся к Фиг. 1, на которой показана система и модель 100 безопасности базы данных согласно аспекту настоящего изобретения. Система 100 включает в себя базу данных 110, имеющую компонент (или компоненты) 120 безопасности, который управляется из глобального или регионального местоположения в базе данных (управление также может осуществляться из удаленных местоположений вне базы данных). База данных 110 включает в себя одну или несколько иерархических структур 130 и 140. Такие иерархии могут включать в себя по существу любой тип иерархически организованных элементов данных (показанных в виде эллиптических узлов) такие, как древовидные структуры общего вида в 130 или более сложные структуры данных, например, как контейнерная иерархия 140, которая в общем случае моделируется в виде направленного циклического графа DAG. Хотя показаны дерево 130 и контейнерная иерархия 140 (также обозначаемая как DAG) очевидно, что модель безопасности настоящего изобретения может применяться по существу к любому типу иерархических структур данных. Как будет описано более подробно ниже, для управления политиками безопасности из компонента 120 безопасности в соответствующих иерархиях 130 и 140 используются различные процессы и компоненты.

В одном из аспектов настоящего изобретения компонент 120 безопасности позволяет применение политик безопасности более глобальным способ таким, как из одной или нескольких областей 150 безопасности, которые отображаются внутри/из базы данных 110. Эти политики могут включать в себя явно определенные политики или свойства в 160 и/или более генерализованные политики или свойства в 170, которые могут наследоваться от различных частей пути или области, связанных с используемым типом структуры данных. Например, политики безопасности могут применяться одним способом для структуры 130 дерево и другим способом для DAG 140, если это необходимо.

Как указывалось выше, предоставлены различные компоненты и процессы, позволяющие автоматическую ассоциацию политик безопасности с элементами базы данных. Эти компоненты определяют модель безопасности, которая отображает политику безопасности из компонента 120 безопасности на соответствующий элемент в иерархиях 130 и 140 в зависимости от используемого типа структуры данных. Например, в случае одного из типов структуры контейнерная иерархия может включать в себя различные типы отношений включения между элементами, присутствующими в данной иерархии. Отношения включения могут быть использованы для распространения политики безопасности для соответствующих элементов, причем политика может включать в себя явную часть 160 (например, определяемую системным администратором) и/или наследуемую часть 170, получаемую от родительского и/или других компонентов, ассоциированных с данным элементом. Таким образом, может быть обеспечено правило, которое позволяет элементу наследовать политику безопасности вместе с ветвями пути от корневого узла иерархии до соответствующего элемента в соответствии со структурой иерархии. Также в случае использования более традиционной древовидной организации, например, как в случае, если существует один путь между корневым узлом дерева и соответствующим элементом данных, может применяться альтернативное отображение политик безопасности.

Как указывалось, база данных 110 и/или иерархии 130/140 могут моделироваться как хранилище элементов (например, область памяти в базе данных). Гранулярность, с которой политика безопасности может быть определена и реализована в общем случае, соответствует уровню различных операций с элементом в данном хранилище. В общем случае, компонент (или модель) 120 безопасности определяет набор принципалов, которым может быть предоставлен доступ или которым может быть отказано в доступе, для выполнения этих операций над элементом, например, через списки управления доступом (ALC). Соответствующие ALC обычно представляют собой упорядоченный набор записей управления доступом (АСЕ), которые описаны более подробно ниже.

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

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

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

Теперь обратимся к Фиг. 2, на которой показаны список 200 управления доступом и компонент 210 упорядочивания в соответствии с аспектом настоящего изобретения. Как указывалось выше, политики безопасности, в общем случае, распространяются через отношения включения в контейнерной иерархии. Поскольку политика безопасности распространяется через отношение включения и может быть переписана для элемента, ниже описывается, каким образом определяют эффективную политику безопасности для элемента. Например, элемент в контейнерной иерархии наследует ACL вместе с путями от корневого узла хранилища элементов к элементу. В наследуемом ACL данного пути упорядочивание различных записей управления доступом (АСЕ) в ACL 200, в общем случае, определяет конечную проводимую политику безопасности. Ниже описано упорядочивание АСЕ в ACL посредством компонента 210 упорядочивания.

Упорядочивание АСЕ в ACL, который наследуется элементом, может быть описано следующими правилами:

Правило 1

Для унаследованных ACL (L) элемента (I)

для элементов I1, I2

для АСЕ А1 и А2 в L,

I1 является предком I2 и

I2 является предком I3 и

А1 является АСЕ, унаследованным от I1, и

А2 является АСЕ, унаследованным от I2,

влечет за собой,

А2 предшествует А1 в L.

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

Нижеследующее правило вызывает АСЕ, которые запрещают доступ к элементу, расположенному ниже АСЕ, которые предоставляют доступ к элементу.

Правило 2

для унаследованных ACL (L) в элементе (I)

для элементов I1

для АСЕ для А1 и А2 в L,

I1 является предком I2 и

А1 представляет собой ACCESS_DENIED_ACE, унаследованный от I1, и

А2 представляет собой ACCESS_GRANTED_ACE, унаследованный от I1,

влечет за собой,

А1 предшествует A2 в L.

Обратимся к Фиг. 3, на которой система 300 иллюстрирует распределение политики безопасности в соответствии с аспектом настоящего изобретения. Система 300 разворачивает одну или несколько политик 310 безопасности на структуре дерева 320 и/или DAG 330. В случае если контейнерная иерархия является деревом 320, существует один путь от корневого узла дерева до данного элемента, и элемент, таким образом, имеет один ACL, унаследованный в 340. В такой ситуации ACL, унаследованный элементом, соответствует ACL, унаследованному файлом (элементом) в существующих моделях безопасности в терминах относительного упорядочивания ACL в них. Однако, если контейнерная иерархия представляет собой направленный ациклический граф (DAG) 330, для элементов существует множество отношений включения. При этом существует множество путей к данному элементу от корневого узла контейнерной иерархии. Поскольку элемент наследует ACL вместе с путями, с которыми ассоциирован элемент, в 350 используется не один, а набор ACL.

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

Обычно существует два аспекта, которые должны быть учтены если контейнерная иерархия представляет собой DAG 330, а не дерево 320. В одном из аспектов модель обеспечивает описание того, как вычисляется эффективная политика безопасности для элемента если он наследует больше одного ACL от своих родителей и как элементы организованы и представляют влияние администрирования модели безопасности для хранилища элементов.

Приведенный ниже алгоритм оценивает права доступа для данного принципала к данному элементу. Перед выполнением алгоритма приведенная ниже нотация описывает ACL, ассоциированные с элементом.

Inherited_ACL(ItemId) - набор ACL, унаследованных элементом с идентификатором ItemId от его родителей в хранилище.

Explicit_ACL(ItemId) - ACL, явно определенный для элемента с идентификатором ItemId.

Вышеприведенная процедура возвращает STATUS_SUCCESS если в требуемом доступе не было отказано явно, и pGrantedAccess определяет, какие из прав, затребованных пользователем, были предоставлены заданным ACL. Если в требуемом доступе было отказано в явном виде, процедура возвращает STATUS_ACCESS_DENIED.

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

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

Для контейнерных иерархий, которые представляют собой DAG точки контейнерной иерархии, в которой изменяется эффективная политика безопасности, в общем случае определяются двумя типами элементов:

элементы, для которых определен явный ACL. Обычно такими являются точки в контейнерной иерархии, для которых администратор явно определил ACL; и

элементы, которые имеют более чем одного родителя, и родители имеют различные политики безопасности, связанные с ними. Обычно такими являются элементы, которые представляют собой точки слияния политики безопасности, определенной для тома элементов, и указывают на начало новой политики безопасности.

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

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

В общем случае дескриптор безопасности включает в себя информацию безопасности, ассоциированную с защищаемым объектом. Дескриптор безопасности включает в себя структуру SECURITY_DESCRIPTOR и ассоциированную с ней информацию безопасности:

SID владельца и главной группы объекта.

DACL, который определяет права доступа, предоставляемые или не предоставляемые конкретным пользователям или группам.

SACL, который определяет типы попыток доступа, которые генерируют записи аудита для данного объекта.

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

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

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

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

идентификатор безопасности (SID), который идентифицирует доверяемую сущность, к которой применяют АСЕ;

маску доступа, которая определяет права доступа, управляемые АСЕ;

флаг, указывающий тип АСЕ.

Набор битовых флагов, которые определяют, могут ли дочерние контейнеры или объекты наследовать АСЕ от главного объекта, которому присвоен ACL.

В нижеследующей таблице перечислены возможные типы АСЕ, поддерживаемые защищаемыми объектами.

В одном из аспектов защищаемые объекты могут определить свои права доступа при помощи формата маски доступа (также возможны другие форматы), показанного в виде маски 400 на Фиг. 4. В этом формате младшие 16 битов предназначены для специфичных для данного объекта прав доступа, следующие 7 битов предназначены для стандартных прав доступа, которые применяются к большинству типов объектов, и 4 старших бита используются для определения общих прав доступа, которые могут отображаться типами объектов на множество стандартных и специфических для объекта прав. Бит ACCESS_SYSTEM_SECURITY (As бит) соответствует праву доступа SACL объекта.

Общие права определены в 4 старших битах в маске 400. В общем случае каждый тип защищаемого объекта отображает эти биты на множество своих стандартных и специфических для объекта прав доступа. Например, один тип файлового объекта может отображать бит GENERIC_READ на READ_CONTROL и SYNCHRONIZE стандартные права доступа и на FILE_READ_DATA, FILE_READ_EA, FILE_READ_ATTRIBUTES специфические для объекта права доступа.

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

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

На Фиг. 5 показан пример структуры 500 данных для одинаково защищенных областей безопасности в соответствии с аспектом настоящего изобретения. Элементы, которые определяют одинаково защищенные области, имеют ассоциированную с ними запись в таблице безопасности, как показано на 500. Таблица безопасности определена следующим образом:

Идентификатор элемента - Идентификатор элемента корневого узла одинаково защищенной области безопасности.

ORDPATH элемента - ORDPATH, ассоциированный с корневым узлом одинаково защищенной области безопасности.

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

ACL пути - Набор ACL, унаследованных данным элементом.

ACL области - Набор ACL, определенных для одинаково защищенной области безопасности, ассоциированной с данным элементом. Отличается от столбца Унаследованные ACL если столбец явного ACL имеет значение, отличное от NULL.

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

Создание нового элемента в контейнере

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

Добавление явного ACL для элемента

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

На Фиг. 6 показана новая одинаково защищенная область безопасности, созданная вне существующей области безопасности при введении нового явного ACL. Это указано узлом, обозначенным 2 под ссылочной позицией 600. Однако введение новой области приводит к созданию дополнительной области 3 под ссылочной позицией 610 вследствие того, что элемент имеет множество связей включения. Приведенная ниже последовательность обновлений таблиц безопасности отражает создание одинаково защищенных областей безопасности.

Добавление связи включения для элемента

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

Удаление связи включения из элемента

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

если удаление связи включения приводит к тому, что элемент, который имел только один родительский элемент и для этого элемента не определен явный ACL;

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

Удаление явного ACL из элемента

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

Модификация ACL, ассоциированного с элементом

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

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

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

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

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

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

Компьютер 812 также включает в себя съемный/несъемный, энергозависимый/энергонезависимый компьютерный носитель данных. На Фиг. 8 показан, например, дисковый носитель 824. Дисковый носитель 824 включает в себя, без ограничения, устройства такие, как привод магнитного диска, привод гибкого диска, привод магнитной ленты, привод Jaz, привод Zip, привод LS-100, карта флэш-памяти или "Memory stick". Дополнительно, дисковый носитель 824 может включать в себя носитель данных отдельно или в комбинации с другим носителем данных, включающим в себя, без ограничения, привод оптического диска такой, как компакт-диск (CD-ROM), привод записываемого CD (привод CD-R), привод перезаписываемого CD (привод CD-RW) или привод универсального цифрового диска (DVD-ROM). Для обеспечения соединения устройства 824 дисковых носителей с системной шиной 812 в качестве интерфейса 950 обычно используются интерфейсы сменных или несменных носителей.

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

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

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

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

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

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

Изобретение относится к вычислительной технике. Технический результат заключается в обеспечении надежной модели безопасности элементов данных за счет повышения производительности и обеспечения стабильности системы. Способ обеспечения безопасности элемента данных, в котором определяют по меньшей мере одну политику безопасности для иерархической структуры данных; определяют по меньшей мере одну область безопасности для иерархической структуры данных; устанавливают, является ли структура иерархических данных структурой дерева или направленным ациклическим графом (DAG); устанавливают, как по меньшей мере одна политика безопасности должна быть применена к элементу в области безопасности, когда элемент наследует более чем один список управления доступом (ACL). 2 н. и 6 з.п. ф-лы, 9 ил., 3 табл.

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

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

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

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

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

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

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

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