Mandatory access control что это
Обновлено: 05.07.2024
Реестр Windows – это иерархическая централизованная база данных, используемая для хранения сведений, необходимых для настройки операционной системы для работы с пользователями, программными продуктами и устройствами.
В реестре хранятся данные, которые необходимы для правильного функционирования Windows. К ним относятся профили всех пользователей, сведения об установленном программном обеспечении и типах документов, которые могут быть созданы каждой программой, информация о свойствах папок и значках приложений, а также установленном оборудовании и используемых портах [1].
Стабильность системного реестра и целостность его содержимого являются жизненно важными для функционирования ОС Windows.
Именно поэтому является актуальной задача исследования вопросов контроля доступа к системному реестру ОС Windows.
«СИНЕРГИЯ-БД»
В реальности встречаются ситуации, когда sepgsql недостаточно, — например, когда требуется защита на уровне строк. В поставку ОС Astra Linux входит защищенная СУБД, привязанная к мандатной системе безопасности ОС Astra Linux. При этом многие потребители нуждаются в защищенной, но платформенно-независимой СУБД. Кроме того, такую комбинацию СУБД и ОС проще сертифицировать: получить сертификат на комбинацию защищенной сертифицированной ОС и защищенной сертифицированной СУБД легче, чем на комплекс, в котором СУБД и ОС тесно взаимосвязаны. В последнем случае при изменении ОС (даже при переходе на другую версию той же ОС) придется заново начинать процесс инспекционного контроля сертифицированного продукта или процедуру сертификации.
Однако абсолютно кросс-платформенное решение невозможно — ОС, созданные даже на основе одного и того же ядра Linux, могут сильно отличаться [3]. Технически задача упростится, если исключить из набора платформ специфические ОС и взять за основу стандартные средства SELinux. Но тогда пришлось бы отказаться от поддержки платформы Astra Linux, популярной на ряде отечественных предприятий.
Возможно компромиссное решение — создать ПО связующего слоя, которое предоставит все необходимые для работы защищенной СУБД мандатные атрибуты, не требуя изменения кода ядра СУБД и исходного кода расширений ОС. Однако разработчикам придется потрудиться и над тем, чтобы универсальность не достигалась в ущерб производительности СУБД.
Мандатная СУБД «Синергия-БД», включающая в себя такое ПО промежуточного слоя, обеспечивает достаточную функциональность и приемлемую производительность (потери на уровне 15%). Эта СУБД разработана РФЯЦ-ВНИИЭФ и компанией Postgres Professional и представляет собой кросс-платформенную среду, работающую на отечественных системах «Синергия-ОС» и Astra Linux Special Edition.
Поскольку Astra Linux и «Синергия-ОС» по-разному решают проблемы доступа, то унификацию берет на себя ПО связующего слоя. Например, в Astra Linux пользователь регистрируется в системе с одним на сессию уровнем конфиденциальности, а «Синергия-ОС» предоставляет своим пользователям диапазон уровней — в этом случае «Синергия-БД» выбирает минимальный уровень из возможных. При этом, чтобы избежать деградации производительности СУБД, атрибуты безопасности пользователя кэшируются на время сессии. Пользоваться базой могут не только сотрудники с определенным уровнем доступа, заданным параметрами пользователя в ОС, но и те, кто входит в систему без метки доступа.
За основу «Синергии-БД» была взята версия СУБД PostgreSQL 9.5.5, в которой имеются штатные методы аутентификации, настраиваемые через pg_hba.conf. На рис. 1 показан порядок взаимодействия удаленных пользователей с подсистемами безопасности двух разных ОС и «Синергии-БД». Рис. 1. Политики ОС управляют правами доступа удаленного клиента
Пользователь авторизуется через механизмы СУБД, например PAM (Pluggable Authentication Modules — «подключаемые модули аутентификации») или GSS (Generic Security Services — «общий программный интерфейс сервисов безопасности», например Kerberos), после чего запускается проверка механизма мандатного доступа. Например, если таблица-контейнер «прозрачна», то для любого пользователя она открыта для чтения и записи, но увидит он в ней только те строки, уровень конфиденциальности которых равен его собственному или меньше. Это и есть разделение доступа на уровне строк, отвечающее модели Белла — Лападулы.
На рис. 2 приведена иерархия объектов «Синергии-БД» — если наследуется таблица, то она считается логически входящей в контейнер родительской таблицы. Видно, что доступ к средствам процедурных языков базы данных (и тем более к функциям) определяется на уровне базы данных, а не на глобальном уровне. Рис. 2. Объекты-контейнеры и содержимое контейнеров в «Синергии-БД»
Модульная структура провайдеров безопасности дает возможность подключать новые модули и интегрировать СУБД в состав других защищенных ОС, имеющих мандатное разграничение доступа, что существенно упрощает и ускоряет процесс сертификации. ***
Очевидно, что по разным причинам безопасные мандатные системы будут достаточно активно развиваться, а значит, будут развиваться подходы к обеспечению совместимости и кросс-платформенности ОС и СУБД. Кроме того, дополнительные исследования потребуются в области организации работы сетей в мандатной среде, обеспечения репликации, а также создания удобных интерфейсов взаимодействия с различными ОС и СУБД.
MAC В POSTGRESQL ДЛЯ SELINUX
В среде SELinux для поддержки разграничения доступа MAC для СУБД PostgreSQL имеется расширение sepgsql, которому необходима поддержка в ядре операционной системы, поэтому он может работать только в Linux 2.6.28 и выше. Это расширение работает на базе мандатной системы SELinux, используемой в Red Hat, CentOS, Fedora и др., а также в их российских собратьях: ОС «Синергия-ОС» (РФЯЦ-ВНИИЭФ), ОС «Заря» и ряде других.
При принятии решения о предоставлении доступа к объекту базы данных, sepqsql сверяется с политиками безопасности SELinux, поскольку внутри sepgsql нет самостоятельного механизма назначения, хранения и модификации меток пользователей. Расширение обеспечивает присвоение меток безопасности пользователям и объектам базы данных через внешних «провайдеров», одним из которых является SELinux. Можно назначать метки безопасности схемам, таблицам, столбцам, последовательностям, представлениям и функциям. Когда расширение sepgsql активно, метки безопасности автоматически назначаются поддерживаемым объектам базы в момент их создания в соответствии с политикой безопасности, которая учитывает метку создателя, метку, назначенную родительскому объекту создаваемого объекта, и, в некоторых случаях, имя создаваемого объекта. Для схем родительским объектом является текущая база данных; для таблиц, последовательностей, представлений и функций — схема, содержащая эти объекты; для столбцов — таблица.
Существующая реализация sepgsql имеет ряд особенностей и ограничений, которые необходимо принимать во внимание, но самое важное — это неспособность ограничения доступа на уровне строк. В версиях PostgreSQL 9.5 и 9.6 и во всех версиях Postgres Pro такая возможность предусмотрена.
Модели контроля доступа
На сегодняшний день разработано три общих модели контроля доступа:
- Принудительный контроль доступа (англ. Mandatory access control, MAC);
- Дискреционный контроль доступа (англ. Discretionary access control, DAC);
- Управление доступом на основе ролей (англ. Role-base access control, RBAC).
Принудительный контроль доступа (англ. Mandatory access control, MAC)
Данная модель изначально разрабатывалась для нужд армии и разведки США [2]. Основное предназначение – обеспечить защиту секретной информации от прочтения пользователями с недостаточным уровнем привилегий.
Принципиальным отличием данной модели от остальных является то, что права доступа определяются единым централизированным органом администрирования с правами суперпользователя и никаким образом не могут быть переопределены обычными пользователями.
Формально, любая система контроля доступа, которая обладает этим свойством, может считаться системой принудительного контроля доступа, однако де-факто, говоря о принудительном контроле доступа, подразумевается система, которая реализует модель многоуровневой безопасности (Multi-Level Security, MLS).
Согласно модели многоуровневой безопасности, заранее определяется упорядоченный набор уровней секретности (например, возможны следующие уровни: «совершенно секретно», «секретно», «для внутреннего пользования», «не секретно»). Из этого набора каждому информационному объекту присваивается классификационная метка, а субъектам системы – уровни доступа.
Общая идея заключается в том, что доступ к объекту заданного уровня секретности могут иметь только субъекты с не меньшим уровнем доступа. Однако, даже в рамках единой модели многоуровневой безопасности, детали алгоритма определения возможности доступа могут отличаться в зависимости от целей системы. И здесь возможны два почти диаметрально противоположных подхода – это модель Белла-Ла Падулы и модель Бибы.
Модель Белла-Ла Падулы (David E. Bell, Leonard J. La Padula, 1973 [3,4]) призвана обеспечить конфиденциальность данных. Модель описывает проблему контроля доступа в терминах переходов между состояниями системы. Каждое состояние описывается совокупностью имеющихся обращений субъектов к объектам. Модель формулирует правила, следование которым гарантирует, что из любого безопасного состояния система может перейти только в другое безопасное состояние.
Суть политики безопасности, определяемой моделью, сводится к двум простым правилам:
- Правило простого свойства безопасности – субъект может читать только те объекты, чей уровень секретности меньше или равен уровню доступа субъекта. Это правило гарантирует что пользователи с недостаточными полномочиями не получат доступ к конфиденциальной информации. Это свойство также иногда формулируется как «запрет чтения вверх».
- Правило *-свойства («звездочка»-свойства) – субъект может писать (дописывать) информацию только в те объекты, чей уровень секретности больше или равен уровню доступа субъекта. Это правило гарантирует, что не произойдет утечка конфиденциальной информации на нижние уровни секретности. Это свойство также иногда формулируется как «запрет записи вниз».
Эти два правила полностью гарантируют конфиденциальность в системе многоуровневой безопасности, однако в некоторых случаях приведенное правило «звездочка»-свойства оказывается неприменимым. Причина этого заключается в том, что позволяя запись (дозапись) в объекты большего уровня секретности, это правило может привести к нарушению целостности данных. В этом случае применяется строгая форма «звездочка»-свойства – запись запрещается как вниз, так и вверх; субъектам разрешено писать только в объекты равного уровня секретности.
В отличии от модели Белла-Ла Падулы, модель Бибы (Kenneth J. Biba), также известная как «модель целостности Бибы» (Biba Integrity Model), призвана обеспечить целостность важных данных [5].
В рамках модели Бибы все объекты и субъекты также классифицируются по заранее определенному упорядоченному набору уровней, однако в модели Бибы уровни имеют другое семантическое значение – здесь это уровни «целостности» или «достоверности».
В соответствии с преследуемой целью и семантикой уровней безопасности модель Бибы устанавливает правила, которые являются диаметрально противоположным тем, что устанавливаются моделью Белла-Ла Падулы:
- Правило простого свойства целостности – субъект может читать только те объекты, чей уровень достоверности больше или равен уровню доступа субъекта. Таким образом, гарантируется, что уполномоченный субъект не будет дезинформирован неполной или недостоверной информацией. Это свойство также иногда формулируется как «запрет чтения вниз».
- Правило *-свойства целостности – субъект может писать только в те объекты, чей уровень достоверности меньше или равен уровню доступа субъекта. Это гарантирует, что субъект не нарушит целостность информации более высоких уровней. Это свойство также иногда формулируется как «запрет записи вверх».
Эти два правила обеспечивают защиту системы от распространения в ней недостоверной информации, которая может нарушить функционирование системы.
Дискреционный контроль доступа (англ. Discretionary access control, DAC)
Как было сказано выше, в системах MAC-модели пользователи не имеют возможности самостоятельно определять права доступа к своим собственным файлам. Это свойство является и главным и преимуществом MAC-модели и ее же главным недостатком. Подобный тоталитарный контроль оказывается эффективным и оправданным для нужд военных ведомств и крупных корпораций, однако оказывается крайне неудобным для среднего и малого бизнеса и домашних пользователей.
Поэтому возникает необходимость в более гибкой модели контроля доступа. Такой моделью является модель дискреционного контроля доступа. Суть дискреционности заключается в том, что любой субъект может по своему усмотрению передать часть своих прав на некоторый объект любому другому субъекту [6].
Возможны несколько подходов к построению дискреционного управления доступом:
- Каждый объект системы имеет привязанного к нему субъекта, называемого владельцем. Именно владелец устанавливает права доступа к объекту.
- Система имеет одного выделенного субъекта — суперпользователя, который имеет право устанавливать права владения для всех остальных субъектов системы.
- Субъект с определенным правом доступа может передать это право любому другому субъекту.
Возможны и смешанные варианты построения, когда одновременно в системе присутствуют как владельцы, устанавливающие права доступа к своим объектам, так и суперпользователь, имеющий возможность изменения прав для любого объекта и/или изменения его владельца. Именно такой смешанный вариант реализован в большинстве операционных систем, например, в классических UNIX-системах или в системах Windows семейства NT.
Описание прав доступа должно в явном и недвусмысленном виде задавать для каждой пары субъект-объект все допустимые режимы доступа. Поскольку набор возможных режимов доступа зависит от типа объекта, а количество объектов обычно значительно превосходит количество субъектов, то описание прав доступа закрепляется за объектами.
Отдельное описание прав доступа для каждой учетной записи, имеющейся в системе, является крайне неэффективным как с точки зрения обработки прав доступа системой, так и с точки зрения вопросов администрирования. Во избежание этого, во всех популярных системах контроля доступа по DAC-модели вводятся группы пользователей как субъекты. С использованием групп права доступа могут быть описаны более компактно, а выполнение задач администрирования упрощено путем сведения необходимых изменений к манипуляциям с пользователями и группами, без необходимости в обновлении прав доступа всех защищенных объектов.
Дальнейшее развитие идея групп пользователей получила в модели управления доступом на основе ролей, которая будет рассмотрена далее.
Типичным представителем реализации DAC-модели является механизм ACL (Access Control List) применяющийся в системах Windows семейства NT [7]. В рамках этого механизма, с каждым защищенным объектом ассоциируется дескриптор безопасности (ACL-запись). В дескрипторе безопасности хранится следующая информация:
- идентификатор пользователя, который является владельцем объекта;
- идентификатор группы, которая является владельцем объекта;
- список разрешенных и явно запрещенных прав доступа к объекту для различных субъектов;
- параметры наследования данного дескриптора.
Если список прав доступа не оговаривает определенный случай доступа, то он считается запрещенным по умолчанию.
Право редактирования дескриптора безопасности как отдельное право доступа описывается самим дескриптором. По умолчанию этим правом обладают владелец, системная учетная запись и пользователи из группы «Администраторы».
Параметры наследования дескриптора определяют наследует ли данный объект свой дескриптор от родительского объекта и будет ли дескриптор унаследован дочерними объектами. По умолчанию наследование активно для большинства системных объектов и вновь созданные дочерние объекты (файл в каталоге, подключ в реестре и т.п.) наследуют дескриптор безопасности родительского объекта.
Другим примером реализации DAC-модели является система прав доступа традиционная для UNIX-подобных систем [8,9]. Эта система имеет ряд принципиальных отличий от Windows ACL:
- Все объекты, независимо от типа, имеют одинаковый набор возможных прав доступа – права чтения, записи, исполнения. Но трактовка этих прав различна для разных типов объектов, что вносит некоторую путаницу.
- Система не поддерживает список определений прав доступа для различных субъектов – вместо этого права доступа определяются в терминах трех субъектов – пользователя-владельца, группы-владельца и всех остальных.
- При создании нового объекта, он наследует права доступа не от родительского объекта, а наследует их от процесса, создавшего объект.
По первым двум пунктам система прав доступа UNIX, несомненно, проигрывает Windows ACL по гибкости и широте возможностей; однако на практике нередко оказывается более эффективной именно в силу своей простоты и предсказуемости.
Касательно третьего пункта, здесь ни один из представленных подходов не имеет явного преимущества – для обеих систем предоставляемое решение является вполне приемлемым источником значений по умолчанию. Более сложные схемы параметров безопасности в любом случае требуют явного задания прав доступа.
Управление доступом на основе ролей (англ. Role-base access control, RBAC)
Данная модель является новейшей и весьма перспективной альтернативой для MAC- и DAC-моделей. До разработки модели управления доступом на основе ролей, MAC и DAC рассматривались как два единственно возможных варианта системы контроля доступа – модель не была MAC-моделью, то она считалась DAC-моделью и наоборот. Однако исследования конца 90-х показали, что модель RBAC не является ни MAC-моделью, ни DAC-моделью [10,11].
Для определения модели RBAC используются следующие соглашения:
Привилегии не назначаются пользователям непосредственно, и приобретаются ими только через свои роли. Таким образом, управление индивидуальными правами пользователя, по сути, сводится к назначению ему ролей. Это упрощает такие операции, как добавление пользователя или смена подразделения пользователем.
При этом назначение пользователем ролей и редактирование разрешений для ролей может производиться только уполномоченными органами (пользователями с административными правами) и не доступно для рядовых пользователей. В этом смысле RBAC-модель также обладает свойством мандатности.
В отличии от DAC-модели, разрешения задаются не на режим доступа к объекту, а на транзакции с объектом. Это позволяет описывать разрешения для сложных операций с составными данными.
Нужно отметить, что в RBAC-модели операции редактирования параметров контроля доступа также являются транзакциями, а значит, могут контролироваться самой системой.
Использование механизма наследования ролей позволяет эффективно описывать разрешения для сущностей реального мира. При этом на возможность наследования разрешений от противоположных ролей может накладываться ограничительная норма, которая позволяет достичь надлежащего разделения режимов. Например, одному и тому же лицу может быть не позволено создать учетную запись для кого-то, а затем авторизоваться под этой учетной записью.
Анализ существующего контроля доступа к реестру ОС Windows
Стандартным средством контроля доступа к реестру ОС Windows является механизм ACL реализующий DAC-модель. Объектами, которые находятся под защитой, являются ключи реестра. Отдельные значения в ключе не существуют как самостоятельные объекты и соответственно не могут иметь дескриптор безопасности.
Для каждого ключа определен следующий набор возможных прав доступа:
В исходной конфигурации ключи реестра, которые являются глобальными для всей системы, имеют дескриптор безопасности, согласно которому полный доступ предоставляется учетной записи системы и пользователям в группе «Администраторы», а доступ только для чтения предоставляется пользователям в группе «Опытные пользователи».
Ключи, влияние которых распространяется только на отдельного пользователя, открыты для полного доступа со стороны этого пользователя, системы и пользователей из группы «Администраторы», а доступ только для чтения предоставляется пользователям в группе «Ограниченные».
В рамках DAC-модели такая конфигурация является оптимальной для системы общего назначения. Возложение на систему предметно-специфичных функций в общем случае требует индивидуального подхода для каждого конкретного случая, и рассмотрение подобных ситуация выходит за рамки магистерской работы.
Имеющаяся конфигурация исключает порчу важных системных ключей реестра пользователями с низким уровнем привилегий. Потенциальными опасными остаются следующие сценарии:
- Нарушение целостности конфигурации в рамках профиля отдельного пользователя в результате ошибки пользователя или действий вредоносного ПО.
- Нарушение целостности конфигурации в масштабах всей системы в результате ошибки пользователя с высоким уровнем полномочий или действий вредоносного ПО, запущенного от его учетной записи.
- Нарушение целостности конфигурации в масштабах всей системы в результате действий вредоносного ПО, нелегально получившего полномочия учетной записи системы.
Для защиты системного реестра Windows от атаки по одному из этих сценариев целесообразно внедрить механизм защиты, который бы дополнил имеющийся механизм ACL.
Реализовывать альтернативный механизм на базе DAC-модели, означает фактическое дублирование стандартного механизма защиты. Это временно снизит вероятность успешной атаки, но в конечном итоге не решает указанные проблемы уязвимости.
Таким образом, перспективным является использование MAC-модели либо RBAC-модели.
Поскольку целью защиты системного реестра является сохранение целостности его содержимого, но не обеспечение его конфиденциальности, то в рамках MAC-модели целесообразно использовать модель Бибы.
В рамках RBAC-модели особый интерес представляют описание прав доступа в терминах «умных» транзакций – т.е. контроль не только фактов доступа, но содержимого оперируемых данных.
Анимация 1. Система защиты блокирует вредоносный запрос
(7 кадров × 1500мс, 10 повторений, 52 Кб)
- Клиент обращается к реестру
- Модуль перехвата перехватывает обращение
- Модуль контроля идентифицирует клиента
- Модуль контроля просматривает базу правил на предмет правил для этого клиента
- Клиент опознается как вредоносный
- Пользователю выдается предупреждение о возникшей опасности
- Клиенту возвращается код отказа в доступе
ОС и СУБД: мандатное разграничение доступа
Разграничение прав доступа — важнейший элемент обеспечения безопасности информационной системы, однако сама по себе безопасность не самоцель, хотя об этом не всегда помнят. Если на одном компьютере разместить исключительно секретные материалы и физически отрезать его от сети, то проблемы с безопасностью будут решены. В ряде случаев так и поступают, однако выделять по компьютеру на каждую категорию секретности неразумно — иногда требуется, не покидая защищенную систему, иметь доступ ко всей информации, в том числе и несекретной. Каким образом, запуская в защищенной среде таких разных ОС, как Astra Linux Special Edition и SELinux/SEPGSQL, приложение, использующее СУБД PostgreSQL, обеспечить разграничение прав доступа и предоставить пользователю ровно тот уровень секретности, который ему положен? При этом очевидно, что ставить мандатную СУБД поверх немандатной ОС бессмысленно.
Всегда можно представить ситуацию, когда в большой базе данных лишь часть информации секретна и важно обеспечить гранулированность доступности. Например, сотрудники районных отделений полиции получают доступ к данным только о жителях своего района, а на уровне города должна быть доступна информация о любом жителе мегаполиса. Такое разграничение доступа реализуется на уровне записей, или строк таблицы (Row Level Security, RLS), однако оно поддерживается не всеми СУБД.
В современных безопасных системах может быть реализована комбинация дискреционного (избирательного) разграничения доступа (Discretionary Access Control, DAC), ролевого разграничения доступа (Role Based Access Control, RBAC) и мандатного (принудительного, обычно многоуровневого) разграничения доступа (Mandatory Access Control, MAC). Как правило, они реализуются именно в таком порядке: следующий «поверх» предыдущего. То есть ресурс, доступный по правилам мандатного доступа, заведомо доступен по правилам дискреционного доступа, но не наоборот.
Мандатное управление доступом обсуждается редко, мало того, его иногда трактуют искаженно, опираясь на опыт работы с бумажными документами, для которых установлены различные уровни секретности. Перенос представлений о работе с бумажными документами на работу с электронными, на уровни доступа ОС и тем более на СУБД, иногда дезориентирует — сходство обманчиво. Для многоуровневой политики имеется простой принцип «читай вниз, пиши вверх», который не похож на то, что подразумевается в реальном мире. Принцип «Write up, read down. No read up, no write down» (субъект, обладающий определенным уровнем доступа, не может читать информацию, относящуюся к более высокому уровню, но может читать менее секретные документы; субъект, обладающий определенным уровнем доступа, не сможет создавать объекты с более низким уровнем допуска, чем имеет сам, но при этом может писать в более высокоуровневые объекты), входящий в модель Белла — Лападулы, прописан и в отечественных документах, регламентирующих требования к безопасности информационных систем. Первая половина этого принципа очевидна, а про вторую этого сказать нельзя: невозможно представить себе ситуацию из «бумажного» мира, когда сотрудник получает доступ на запись в документ высокой секретности, не имея при этом права (и возможности) его читать. Однако именно так исключается попадание данных, доступных высокоуровневым объектам, в низкоуровневые объекты.
Мандатное разграничение доступа еще называют принудительным контролем доступа: пользователь не может управлять доступом к информации, а сами правила доступа жестко определены политикой безопасности. Наличие разграничения доступа MAC, DAC и RBAC — обязательное требование при защите информации категории «гостайна», однако для разных ОС и СУБД оно может трактоваться по-разному. Например, в мандатном управлении доступа для операционной системы Astra Linux пользователь сам может выбирать уровень секретности из тех, что разрешены ему системным администратором, и этот уровень будет сохраняться на протяжении сессии. Теоретически мандатная система доступа не обязательно должна иметь различные уровни конфиденциальности (секретности или доступа), однако в реальной жизни редко находятся причины использовать немногоуровневую политику: именно она обязательна для систем с обеспечением гостайны.
Имеется некоторый набор средств для реализации мандатных ОС, но для российской действительности актуальны две — SELinux [1] и Astra Linux Special Edition [2].
SELinux (Security-Enhanced Linux) представляет собой обычный дистрибутив Linux, скомпилированный с набором модулей (LSM, Linux Security Modules), перехватывающих системные вызовы.
Модули представляют собой «крюки» («хуки»), к которым можно «подвесить» свои обработчики. Код SELinux открыт, и мандатный доступ строится поверх обычной системы доступа Linux — то есть файл, недоступный в Linux, будет недоступен и в SELinux, но не наоборот. При определении доступности файла система сравнивает метки субъекта и объекта, а затем принимает решение о допустимости операции. Метка представляет собой набор полей, содержимое которых может по-разному задаваться в различных политиках безопасности. Для создателей и пользователей мандатных систем наиболее интересна многоуровневая политика защиты (Multi Level Security, MLS), основанная на иерархии уровней секретности (чувствительности) и набора категорий. Пользователь SELinux — это сущность, определенная в политике, отвечающая за конкретный набор ролей и других атрибутов контекста безопасности. Пользователи SELinux отличаются от пользователей Linux, поэтому необходимо сопоставление (mapping) между ними через политику SELinux, позволяющее пользователям Linux наследовать ограничения пользователей SELinux.
Версия Astra Linux Special Edition разработана компанией «РусБИТех» на основе подсистемы PARSEC, целиком реализованной в виде модулей LSM, причем разработчики не декларируют следование модели Белла — Лападулы, а предлагают собственную патентованную «мандатную сущностно-ролевую ДП-модель» (модель логического управления доступом «Д» и информационными потоками «П»). Объекты располагаются в монотонной по доступу иерархии контейнеров (каталог — это контейнер для файлов, таблица базы данных — контейнер для записей). Уровень конфиденциальности контейнера не уступает уровню содержащихся в нем объектов. По умолчанию запись «вверх» в модели безопасности Astra Linux невозможна — можно писать только на свой уровень. Однако, поскольку работать с такой жесткой системой запретов трудно, а в некоторых ситуациях просто невозможно, вводятся средства игнорирования мандатных меток контейнера или объекта. Атрибут «ehole» мандатной метки позволяет игнорировать любые мандатные правила, а бит CCR делает «прозрачными» контейнеры, непрозрачные для нижележащих уровней секретности.
Выводы
На сегодняшний день разработано три основных модели контроля доступа – MAC-модель, DAC-модель и RBAC-модель. Для контроля доступа к реестру Windows имеются стандартные средства, реализующие DAC-модель. В рамках DAC-модели конфигурация имеющихся средств контроля доступа является оптимальной для системы общего назначения и не требует модификаций. Однако остаются возможные сценарии атаки, которые в рамках DAC-модели полностью исключить невозможно. Для защиты от этих атак целесообразно разработать альтернативный механизм защиты на базе MAC-модели либо RBAC-модели, дополняющий возможности стандартного механизма контроля доступа к реестру ОС Windows.
Информационная безопасность
Эти модели встроены в ядро различных операционных систем и во многих случаях поддерживаются приложениями. Каждая операционная система имеет ядро безопасности, которое реализует концепцию монитора обращений (reference monitor), которая зависит от встроенной в систему модели управления доступом. Для каждой попытки доступа, перед тем, как субъект сможет начать взаимодействовать с объектом, ядро безопасности проверяет правила модели управления доступом, чтобы определить, является ли запрос допустимым. В следующих разделах будет рассказано про эти различные модели доступа, поддерживающие их технологии и о том, когда их следует применять.
В модели DAC ограничения доступа основываются на авторизации пользователя. Это означает, что владельцы могут определять, какой тип доступа может быть разрешен к их объектам. Если компания использует модель DAC, сетевой администратор может разрешить владельцам ресурсов управлять доступом пользователей к своим ресурсам. Чаще всего модель DAC реализуется посредством списков контроля доступа (ACL), содержимое которых определено владельцами. Работа ACL реализуются средствами операционной системы. Это может позволить пользователям использовать информацию динамически вместо более статичного мандатного или ролевого управления доступом. Большинство операционных систем основаны на модели DAC (например, системы Windows, Linux, Macintosh и большинство систем *nix).
Посредством дискреционной модели, например, Сэм может предоставить совместный доступ к диску D на своем компьютере Дэвиду, а Дэвид может скопировать с него все MP3 Сэма. При этом Сэм может заблокировать доступ к своему диску D для своего начальника, чтобы тот не знал, что Сэм тратит время и ресурсы на скачивание музыки и ее раздачу своим друзьям.
Каждый субъект и объект всегда должен иметь связанную с ним метку с атрибутами, поскольку это является частью критериев принятия решения операционной системой.
Эта модель применяется в среде, в которой классификация информации и конфиденциальность чрезвычайно важны, например, в военных организациях. На базе этой модели разработаны специализированные версии Unix-систем, например, SE Linux, Trusted Solaris. Компании не могут просто переключаться между использованием DAC и MAC. Им потребуется специально приобрести для этого операционную систему, спроектированную и реализующую правила MAC. Системы DAC не понимают меток безопасности, классификации, уровней допуска и поэтому не могут применяться в организациях, которым нужна такая структура управления доступом.
Более традиционное администрирование прав доступа основано на модели DAC, в которой управление доступом происходит на уровне объекта с использованием ACL. Этот подход более сложен, т.к. администратор должен перевести организационную политику компании в разрешения при настройке ACL. С ростом количества объектов и пользователей в компании у многих пользователей появляются (или остаются после изменения обязанностей) права доступа к некоторым ресурсам, которые им не требуются для работы. Это нарушает принцип минимальных привилегий и увеличивает риски компании. Подход RBAC позволяет избежать этого, так как разрешения управляются на уровне должностных ролей. В модели RBAC роль определяется в терминах операций и задач, которые она выполняет, тогда как в модели DAC описывается, какие субъекты могут иметь доступ к каким объектам.
ПРИМЕЧАНИЕ. Введение ролей показывает разницу между правами, назначенными явно и неявно. В явном виде права и разрешения назначаются непосредственно конкретному пользователю. В неявном виде они назначаются роли или группе, а пользователь просто наследует эти полномочия.
Это надежная модель, поскольку она может включать другие компоненты в процесс принятия решений о возможности доступа, а не просто основываться на учетных данных. Например, система RBAC может учитывать время дня, местоположение роли, день недели и т.д.
Этот компонент позволяет администратору создать организационную модель RBAC на основе организационной структуры и функциональных разграничений, требующихся в конкретной среде. Это очень полезно, поскольку в компаниях уже есть иерархические структуры персонала. Чаще всего, чем выше вы находитесь в организационной иерархии компании, тем больше прав доступа вы имеете.
MAC В POSTGRESQL ДЛЯ ASTRA LINUX
Защищенные версии СУБД PostgreSQL, поставляемые компанией «РусБИТех» вместе с Astra Linux Special Edition v.1.5, собраны со специальными патчами, позволяющими взаимодействовать с мандатной системой PARSEC. Они базируются на стандартных версиях PostgreSQL 9.2 либо PostgreSQL 9.4 и отличаются реализацией мандатного разграничения (в 9.4 более полный функционал и реализована ДП-модель управления доступом и информационными потоками, соответствующая модели безопасности в ОС Astra Linux). СУБД PostgreSQL использует механизмы ОС для того, чтобы пользователь получил те же поля метки мандатного доступа, что и пользователь ОС, вошедший с соответствующими мандатными атрибутами. В сессии возможен только один уровень конфиденциальности, а не диапазон, как в SELinux и sepgsql.
В качестве главного контейнера выбрано табличное пространство pg_global — одно на кластер базы данных. Применение мандатных прав доступа работает на уровне доступа к объектам базы данных и на уровне доступа непосредственно к данным. В отличие от sepgsql, эта реализация поддерживает разграничение на уровне записи: записи рассматриваются как объекты, а содержащие их таблицы — как контейнеры. Метки системных объектов располагаются в записях таблиц системного каталога, непосредственно описывающих защищаемый объект.
Информационная безопасность и защита информации (архив ИПМ бакалавры 2010-2021г, Богомолов)
управление доступом субъектов к объектам на основе списков управления доступом или матрицы доступа. Субъект с определенным правом доступа может передать это право любому другому субъекту.
На курсе "Операционные системы" вы работали с этой моделью доступа.
Пример: когда вы расписываете доступ к файлу, вы указываете
- имя владельца файла (субъект)
- права на чтение
- права на запись
- права на запуск на выполнение
- пользователь
- программа выполняющаяся под именем пользователя
- файлы
- каталоги
- внешние накопители (CD,DVD,USB и т.д.)
- принтер
- сетевой адаптер
Рис. Дискреционное управление доступом
- простата реализации
- гибкость (пользователь может описать доступ к своим ресурсам)
- излишняя детализированность (приводит к запутанности)
- сложность администрирования
- пользователь может допустить ошибку при назначении прав
Пример дискреционного управления доступом к файлам в LINUX.
Мандатное управление доступом ( Mandatory access control, MAC )
Разграничение доступа субъектов к объектам, основанное на назначении метки (мандата) конфиденциальности для информации, содержащейся в объектах, и выдаче официальных разрешений (допуска) субъектам на обращение к информации такого уровня конфиденциальности.
Рис. Мандатное управление доступом
- простата построения общей схемы доступа
- простата администрирования
- проблема разграничения пользователей одного уровня
- пользователь не может назначать доступ к объекту
Мандатная модель не реализована в Windows, но можно поставить дополнительные средства защиты (например: Secret Net, Аккорд и т.д.).
Ролевое управление доступом (Role Based Access Control, RBAC)
развитие политики избирательного управления доступом, при этом права доступа субъектов системы на объекты группируются с учетом специфики их применения, образуя роли.
Читайте также: