Списки управления доступом
Согласно первому методу, с каждым объектом ассоциируется список (упорядоченный), содержащий все домены, которым разрешен доступ к данному объекту, а также тип доступа. Такие списки называются списками управления доступом (Access Control List, ACL, рис. 5.24). На нем изображены три процесса, А, Б и С, принадлежащие разным доменам, и три файла, F1, F2 и F3. Для простоты предположим, что каждый домен соответствует ровно одному пользователю, в данном случае, А, Б и С.
В литературе, посвященной безопасности, пользователей называют субъектами, или принципалами, в отличие от объектов — вещей, которыми они обладают (например, файлов). Рис. 5.24. Использование списков управления доступом применительно к файлам |
С каждым файлом связан список управления доступом. АСЬ файла Р1 состоит из двух записей, разделенных точкой с запятой. Первая запись указывает на то, что любой процесс пользователя А может читать и писать в файл, а вторая — на то, что пользователь В может читать файл. Другие виды доступа для этих пользователей, а также все виды доступа для остальных пользователей запрещены.
Обратите внимание на то, что права назначены не процессам, а пользователям. С точки зрения системы защиты, любой процесс, владельцем которого является пользователь А, имеет право читать и писать в файл Р1. Не имеет значения, сколько таких процессов — один или сто; учитывается не идентификатор процесса, а его владелец.У файла F2 в ACL три записи: пользователи А, В и С могут читать файл, а, кроме того, В имеет право записи в него. Все прочие виды доступа запрещены. Файл F3, очевидно, является исполняемой программой, поскольку пользователи В и С могут читать и исполнять его. Процесс В также имеет разрешение на запись в F3.
Данный пример демонстрирует простейшую форму защиты посредством ACL. Механизмы, используемые на практике, более сложны. Для начала мы показали лишь три права: на чтение, на запись и на исполнение. Существуют и другие права: например, широко распространены права на копирование и уничтожение объекта. Они имеются у любого объекта независимо от его типа. Возможны права, специфичные для конкретных объектов. Например, у объекта «почтовый ящик» существует право на добавление сообщения, а у объекта «каталог» — право сортировки в алфавитном порядке.
До настоящего момента мы говорили о ACL-записях, соответствующих отдельным пользователям. Многие системы поддерживают концепцию групп пользователей. Группы имеют имена и могут включаться в ACL. Для групп поддерживаются два вида семантики. В некоторых системах у каждого процесса есть идентификатор пользователя (UID) и идентификатор группы (GID). В этом случае ACL-запись выглядит следующим образом:
UIDl, GID1: права1; UID2 , GID2: права 2; ...
При получении запроса на доступ к объекту проверяется наличие UID и GID процесса в ACL, и, если эти идентификаторы удается найти, применяются перечисленные права. В противном случае в доступе отказывается.
Подобное использование групп приводит к концепции роли. Рассмотрим систему, в которой пользователь tana является системным администратором, а следовательно, входит в группу sysadm. Пусть в компании имеется несколько клубов для сотрудников, и tana входит в сообщество любителей голубей.
Члены этого сообщества принадлежат группе pigf ап и имеют возможность управлять собственной базой данных с компьютеров компании. В табл. 5.4 приведен фрагмент списка управления доступом.Таблица 5.4. Два списка управления доступом
|
Если tana попытается получить доступ к одному из этих файлов, результат зависит от того, к какой группе этот пользователь принадлежит в текущий момент. Возможно, при входе система просит его указать группу, в которую он хотел бы войти; не исключено, что для разделения групп каждой из них даже соответствуют свои имена входа и (или) пароли. Цель такой схемы — лишить пользователя tana возможности доступа к файлу паролей, если он вошел в систему как член сообщества любителей голубей. Он может работать с файлом паролей только как системный администратор.
В некоторых случаях пользователь получает доступ к определенным файлам независимо от группы, к которой он принадлежит. Такой режим задается с помощью маски, обозначающей любую группу. Например:
tana, *: RW
Запись подобного вида дает пользователю tana доступ к файлу паролей независимо от того, в какой группе он находится в текущий момент.
Еще одна возможность заключается в предоставлении пользователю доступа к объекту при условии, что надлежащим правом обладает хотя бы одна группа, в которую он входит. В этом случае пользователю, состоящему в нескольких группах, не нужно указывать текущую группу при входе в систему. В любой момент времени учитываются все группы, членом которых он является. Недостаток такого подхода — меньшая изолированность: tana имеет возможность редактировать файл паролей во время общения с любителями голубей.
Применение групп и масок позволяет выборочно блокировать доступ пользователей к файлам. Например:
virgil, *: (none); *.*: RW
Эта запись дает возможность всем, кроме пользователя virgil, читать и писать в файл. Такой эффект достигается потому, что записи сканируются в порядке перечисления и применяется первая подходящая (остальные же записи даже не проверяются). Для virgil такой записью является первая; в ней указано отсутствие каких-либо прав (попе). На этом поиск заканчивается, и то, что все остальные пользователи имеют права доступа, остается «за кадром».
Другой способ работы с группами предполагает, что в ACL-записях задействованы не пары (UID, GID), а один из этих идентификаторов. Например, для файла pigeon_data запись может выглядеть следующим образом:
debbie: RW; phil: RW; pigfan: RW
Она означает, что пользователи debbie, phil и все члены группы pigfan имеют право чтения и записи.
Иногда владелец файла хочет отметить разрешения, назначенные пользователю или группе. Списки управления доступом позволяют относительно легко отменить назначенные ранее права. Все, что нужно сделать, — это отредактировать их. Тем не менее если список проверяется лишь при открытии файла, то изменения возымеют действие лишь при следующем вызове open. К любому открытому файлу применяются права, актуальные на момент открытия, даже если позднее доступ пользователю запрещается.
5.5.3.
Еще по теме Списки управления доступом:
- Метод Ключ – защита от стресса и доступ к управлению внутренними ресурсами
- Номер один в списке неправильных действий
- 3. Доступ к источникам информации.
- Статья 1040. Обращение взыскания на имущество, переданное в управление, по требованию кредитора установщика управления
- Прямой доступ к информации и предузнавание
- Непосредственный доступ и предсказания
- § 6. Равный доступ к государственной службе
- 2.1.4. Классификация информации по доступу к ней
- Ключ доступен каждому.
- Прямой доступ к информации (на основе книг Барбары Энн Бреннан).
- Принцип обеспечения потерпевшим права на доступ к правосудию и возмещение причиненного преступлением вреда
- § 3. Право управления предприятием как особый вид абсолютных прав. Право полного и ограниченного управления (п. 1774-1776)
- УПРАВЛЕНИЕ ВРЕМЕНЕМ VERSUS УПРАВЛЕНИЕ СОБОЙ
- Статья 200. Незаконные действия с документами на перевод, платежными карточками и иными средствами доступа к банковским счетам, оборудованием для их изготовления
- 15.6. Порядок доступа к Архивным фондам и использования архивных документов