Система и способы обеспечения улучшенной модели безопасности

Система и способы обеспечения улучшенной модели безопасности

Иллюстрации

Показать все

Реферат

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

Настоящая заявка на патент притязает на приоритет заявки на патент США №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, ассоциированный с этой областью, изменяется, и обычно не требуются дальнейшие модификации для таблицы безопасности. Если область безопас