Мандатная модель управления доступом (mac): обзор и применение в прикладных системах

Проверка ограничения доступа

Динамически определенные атрибуты позволяют вызвать у менеджера доступа методы и , где — любое допустимое имя. Это имя служит именем способности — ability — которая запрашивается у системы. Например, для получения прав на просмотр (способность ), запрашиваются методы и .

Метод получает модель и определяет ограничение способности в ее отношении, а методу передается и метод определяет ограничения нашей способности относительно списка объектов в этом запросе.

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

Ограничение доступа к модели в целом

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

Ограничение доступа к отдельным объектам

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

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

Шаг 5. Создаем бизнес-ориентированное описание полномочий

  • наименование полномочия, включая объект, к которому применяется право доступа;
  • действие, которое разрешается делать с объектом (просмотр, изменение и т.п., возможность ограничения, например, по территориальному признаку или по группе клиентов);
  • код полномочия (код и имя функции/запроса системы, которые можно выполнить с использованием полномочия);
  • описание полномочия (подробное описание действий в ИС при применении полномочия и их последствий для процесса;
  • статус полномочия: «Активно» (если полномочие назначено хотя бы одному пользователю) или «Не активно» (если полномочие не используется).

Принцип работы

На основе сравнения различных идентификационных признаков человека или транспортного средства с параметрами в памяти СКУД. У каждого имеется персональный идентификатор – код или пароль. Также может использоваться биометрия – изображение лица, отпечатки пальцев, геометрия кисти, динамика подписи.

Рядом со входом в закрытую зону устанавливаются устройства для ввода данных или считывания информации. Затем материал передаётся в контроллеры доступа для анализа и соответствующей реакции – открыть или заблокировать дверь, включить сигнализацию тревоги или зарегистрировать там нахождение сотрудника.

3.2 Фундаментальное различие

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

1.       Настройка
политики безопасности системы.

2.       Определение
прав доступа для субъектов и объектов в системе.

В то время как для первых двух моделей политика безопасности
системы уже предопределена.

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

4 Заключение

В этой статье мы рассмотрели различные методы управления
доступом:

  • Модель дискреционного контроля за доступом
  • Модель обязательного контроля за доступом
  • Ролевая модель контроля за доступом

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

5 Список
литературы

.   Ravi S. Sandhu, Pierangela Samarati: Access Control: Principles and Practice. IEEE
Comunication Magazine 1994

.   Osborn, S., Sandhu, R., and Nunawer, Q. Configuring Role-Based
Access Control To Enforce Mandatory And Discretionary Access Control Policies.
ACM Trans. Info. Syst. Security, 3, 2, 2000.

.   Steve Demurjian: Implementation of Mandatory Access Control in
Role-based Security System. 2001

.   Sandhu, R.S., Coyne, E.J., Feinstein, H.L., and Youman, C.E.
Role-based access control models. Computer, 29:38-47, Feb. 1996.

Управление доступом на основе ролей

Ключевой особенностью ролевой модели является то, что весь доступ к информационным системам и ресурсам предоставляется только через роли. Роль – это набор прав доступа. Пользователи получают доступ только через присвоенные им роли.

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

Универсальную модель ролевого управления доступом впервые предложили Дэвид Феррайоло и Ричард Кун из Национального Института Стандартов и Технологий США (NIST) в 1992 году. Документ давал определения основным понятиям, их отношениям и зависимостям, и представлял ролевое управление доступом (RBAC – Role Based Access Control) как альтернативу мандатному управлению (MAC – Mandatory Access Control) и избирательному управлению (DAC – Discretionary Access Control) доступом. Об этих и других моделях можно прочитать здесь. Сегодня этот документ вырос в полноценный международный стандарт INCITS 359-2012, о нём, я думаю, мы ещё расскажем подробнее. 

Иерархическая ролевая модель[править]

Это наиболее распространенный тип ролевой модели, в которой роли упорядочиваются по уровню предоставленных полномочий. Иерархия ролей подразумевает то, что если U{\displaystyle U} присвоена некоторая роль, то ему автоматически назначаются и все подчиненные ей по иерархии роли.

RH⊆R×R{\displaystyle RH\subseteq R\times R}
Частичное отношение порядка на множестве R{\displaystyle R}, которе определяет иерархию ролей и задает на множестве R{\displaystyle R} оператор доминирования ≥{\displaystyle \geq }

UA⊆U×R{\displaystyle UA\subseteq U\times R}
Назначают каждому U{\displaystyle U} набор ролей, причем вместе с каждой ролью в него включаются и все роли, подчиненные ей по иерархии.
∀r,r′∈R,u∈U r≥r′∧(u,r)∈UAn⇒(u,r′)∈UAn{\displaystyle \forall r,r’\in R,u\in U:~r\geq r’\land (u,r)\in UA^{n}\Rightarrow (u,r’)\in UA^{n}}

Функция rolesh S→P(R){\displaystyle roles^{h}:~S\rightarrow P(R)} назначает каждому сеансу S{\displaystyle S} набор ролей их иерархии ролей пользователя, работающих в этом сеансе.
rolesh(S)⊆{r|∃r′≥r (user(s),r′)∈UAh}{\displaystyle roles^{h}(S)\subseteq \{r|\exists r’\geq r~(user(s),r’)\in UA^{h}\}}

permissionsh S→P{\displaystyle permissions^{h}:~S\rightarrow P}
Urolesh(S){pi|∃r′≤r (pi,ri)∈PA}{\displaystyle U_{roles^{h}(S)}\{p_{i}|\exists r’\leq r~(p_{i},r_{i})\in PA\}}

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

Индивидуальный доступ

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

При применении ролевой модели доступа, количество индивидуальных прав обычно составляет 5-10% от общего количества привилегий.

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

Рисунок 7. Процесс предоставления индивидуальных прав доступа

  

Какие права нужно распределять

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

Такое разделение работало до определенного момента вполне приемлемо, однако когда потребовалось распределять доступ «перекрестно», обнаружилось, что наша система слишком груба. Действительно. Пусть мы распределяем доступ к объектам пользователей. Пользователь — админ своей группы, вполне может отредактировать и даже удалить запись о пользователе из этой группы. С другой стороны, мы бы хотели, чтобы пользователи, которые являются админами своих групп, могли быть рядовыми пользователями других групп

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

Таким образом, стало ясно, что «по горизонтали» нужно управлять не только видимостью объектов, но и всем спектром операций, производимых над ними. Традиционно, определено 4 вида наиболее популярных и общеупотребительных действий над объектами, объединенных иногда аббревиатурой CRUD (Create, Read, Update, Delete):

  • создавать
  • видеть
  • изменять
  • удалять

Критерии выбора

Каждая система разрабатывается с учётом следующих факторов:

  1. Задачи, возлагаемые на СКУД – на будущие параметры влияет их количество и особенности.
  2. Необходимость дополнительных функций и сопряжения с другими средствами – подключение камер видеонаблюдения, биометрических датчиков, турникетов, считывателей, идентификаторов.
  3. Тип СКУД по размерам объекта – в небольшом магазине достаточно автономного оборудования, а при обслуживании бизнес-центра или корпорации надо разворачивать многоуровневый сетевой комплекс.

Специалисты советуют – на что обратить внимание, чтобы избежать ошибки при выборе:

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

Работа с несоответствиями

Как правило, в IDM-решении присутствуют механизмы отслеживания, так называемых, несоответствий. Несоответствие – это изменение прав доступа сотрудников, изменение атрибутов ресурсов и информационных систем в обход процедуры согласования и без уведомления сотрудников службы ИБ.

Рисунок 9. Отслеживание несоответствий в правах доступа

 

IDM-решения производят мониторинг информационных систем на предмет изменения состояний, после чего соотносят эти изменения с заявками, созданными в IDM.

Рисунок 10. Мониторинг изменений доступа в информационных системах

  

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

Рисунок 11. Несоответствие прав доступа фиксируются системой

  

Шаг 1. Создаем функциональную модель

Начать стоит с создания функциональной модели – верхнеуровневого документа, в котором подробно описан функционал каждого подразделения и каждой должности. Как правило, информация в него попадает из различных документов: должностных инструкций и положений по отдельным подразделениям – отделам, управлениям, департаментам. Функциональная модель должна быть согласована со всеми заинтересованными подразделениями (бизнес, внутренний контроль, безопасность) и утверждена руководством компании. Для чего нужен этот документ? Для того, чтобы ролевая модель могла на него ссылаться. Например, вы собираетесь строить ролевую модель на основе уже имеющихся прав сотрудников – выгруженных из системы и «приведённых к единому знаменателю». Тогда при согласовании полученных ролей с бизнес-владельцем системы можно сослаться на конкретный пункт функциональной модели, на основании которого в роль включается то или иное право.

Учет и использование стандартов и нормативов при построении СУИД

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

СУИД в данном смысле не является исключением. Все опрошенные в ходе подготовки обзора эксперты единодушно высказались за то, что эти системы должны опираться на стандарты, причем только открытые. В качестве основных называются общие стандарты по управлению ИТ и организации информбезопасности, такие как COBIT, ISO 17799:2005 (BS 7799), ISO 27001:2005. К ним эксперты добавляют требования, направленные на борьбу со злоупотреблениями в бизнесе, которые были выработаны на основе практики последних лет: HIPAA (Health Insurance Portability and Accountability Act), SOX 2002 (Sarbanes — Oxley Act, определяющий требования к системе внутреннего контроля и аудита для предотвращения мошенничества), BASEL II (управление рисками в финансовых учреждениях) и стандарт Банка России СТО БР ИББС для организаций банковской системы РФ.

Из технологических стандартов, как считают эксперты, создатели СУИД прежде всего должны придерживаться следующих:

  • общие стандарты по информационной безопасности — XKMS, PKI, XML-SIG, XML-ENC, SSL/TLS, PKCS, S/MIME, LDAP, Kerberos, X.509 и др.;
  • стандарты по обмену идентификационными данными пользователей — SAML, WS-Fed, XACML, SPML и др.;
  • стандарты интеграции — WSDL, WSRP, JSR-115, JCP, SOAP и др.;
  • стандарты Web-сервисов — WS-Security, WS-Fed, WS-Policy, WS-Trust и др.;
  • стандарты служб каталогов — X.500, DSML, LDAP, JDBC и др.

Шаг 6 Выгружаем из систем данные о пользователях и правах и сопоставляем с кадровым источником

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

Какие данные необходимо выгрузить:

  • Наименование учётной записи
  • ФИО работника, за которым она закреплена
  • Статус (активна или заблокирована)
  • Дата создания учётной записи
  • Дата последнего использования
  • Список доступных прав/групп/ролей

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

Затем, если у вас в компании нет автоматизированных средств закрытия доступа уволенным сотрудникам (такое нередко встречается) или есть лоскутная автоматизация, которая не всегда корректно срабатывает, нужно выявить все «мёртвые души». Речь об учётных записях уже уволенных сотрудников, права которых по какой-то причине не заблокированы, – их нужно заблокировать. Для этого сопоставляем выгруженные данные с кадровым источником. Кадровую выгрузку тоже нужно предварительно получить у подразделения, ведущего кадровую базу.

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

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

Особенности

При проектировании, внедрении и использовании ролевой модели управления доступом нужно принимать в расчёт факторы, которые могут привести к серьезным потерям времени и средств.

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

  • В таком случае трудно определить «разумно малый» набор ролей, которые отвечают за права доступа основной массы пользователей.
  • Непрактично создавать столько же ролей сколько пользователей – это равносильно ручному управлению доступом.

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

В-третьих, «изменение обязанностей пользователей и реорганизация бизнеса»: даже если ролевая модель отражает текущую ситуацию в организации, ее необходимо поддерживать в актуальном состоянии, отслеживать изменения обязанностей пользователей и оперативно вносить изменения в ролевую модель.

В-четвёртых, «стоимость»: необходимо учитывать, что разработка и поддержка ролевой модели в итоге может стоить дороже ручного администрирования. Кроме того, управление ролевой моделью требует более квалифицированных специалистов, чем администратор, который предоставляет права.

Что это такое и для чего нужны

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

Основные функции

  1. Санкционирование – присваиваются идентификаторы, определяются биометрические признаки; их регистрация с заданием временных интервалов и уровня доступа (когда, куда, кто допускается).
  2. Идентификация – опознание по считанным идентификаторам или признакам.
  3. Авторизация – проверка соответствия заданным полномочиям.
  4. Аутентификация – определение достоверности по идентификационным признакам.
  5. Реализация – разрешение или запрет по результатам анализа.
  6. Регистрация – фиксация действий.
  7. Реакция – меры в случае попытки несанкционированного доступа: сигналы предупреждения и тревоги, блокирование зоны и пр.

Задачи

  1. Постановка или снятие охраны по установленному регламенту, при нештатных ситуациях – запись и хранение информации.
  2. Дистанционное онлайн управление.
  3. Разграничение доступа в соответствии со служебными полномочиями.
  4. Идентификация и контроль перемещения сотрудников на объекте, предотвращение повторного входа по одинаковым идентификаторам.
  5. Учёт рабочего времени. Фиксация времени и даты прибытия сотрудника на конкретное место с записью длительности его нахождения там.
  6. Интеграция с другими элементами безопасности – охранной, пожарной, видеонаблюдения.

Сертификация доступа

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

С помощью IDM-системы, например, «КУБ» эту процедуру можно автоматизировать. Руководитель будет периодически получать уведомления со списком индивидуальных привилегий его подчиненных, которые он может продлить на расчетный период или отобрать.

Есть другой вид переаттестации, когда доступ подтверждается не руководителем, а согласующими лицами, которые утверждали первоначальный доступ.

Рисунок 8. Утверждение индивидуальных прав доступа

  

Учетные записи. Ролевая модель доступа

Для управления шлюзом безопасности реализована ролевая
модель доступа.

В консоли разграничения доступа
выделены роли – пользователя и администратора. В свою очередь допустимые
действия администратора зависят от установленного уровня привилегий.

Пользователь имеет право на просмотр версии продукта,
аппаратной и программной платформ, текущей конфигурации, состояния соединений,
информации о текущем пользователе, настройке терминала.

Администратор консоли разграничения доступа с уровнем
привилегий 15 имеет право на запуск и останов сервиса безопасности, запуск
процедуры инициализации, создание учетных записей пользователей с однофакторной
или двухфакторной аутентификацией для консоли разграничения доступа, работу
с файлами, запуск утилит для регистрации лицензии, сертификатов, просмотр
любой информации, доступ к ОС. Может перейти в cisco-like консоль.

Администратор консоли разграничения доступа с уровнем
привилегий 1 имеет право перейти в cisco-like консоль, а также выполнить
все действия, доступные пользователю.

В Cisco-like
консоли может быть две роли – администратор
с уровнем привилегий 0-14 и администратор с уровнем привилегий 15.

Администратор с уровнем привилегий 15 имеет право выполнять
любые настройки политики безопасности шлюза, создавать учетные записи
администраторов для cisco-like консоли, все команды просмотра.

Администратору с уровней привилегий 0-14 доступны только
команды просмотра версии продукта и уровня привилегий администратора.
Но зная пароль доступа к привилегированному режиму, администратор получает
право на управление шлюзом безопасности. В привилегированном режиме текущий
уровень привилегий всегда максимальный (15).

В таблице ниже приведена информация о двух консолях,
режимах консолей, команды для перехода в режимы и доступность команд для
ролей.

Таблица 1

Режим,
приглашение

Команда
для перехода в режим, заводская настройка доступа администратора

Возможности
администратора

Возможности
пользователя

Консоль разграничения
доступа

administrator@sterragate]

Доступ к консоли:

Логин – administrator Пароль – s-terra

Команды просмотра, создание пользователей для
консоли разграничения доступа, изменение паролей, работа с файлами,
терминалом, запуск инициализации, утилит, доступ к ОС.

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

Режим
операционной системы

root@sterragate:~#

system

Логин – root
Пароль – пустой

Переход к ОС для начальной настройки и в аварийных
ситуациях.

administrator@sterragate]

configure

Переход к cisco-like консоли.

Cisco-like консоль

Режим
пользователя

sterragate>

configure (переход из консоли разграничения
доступа администратора с уровнем привилегий 0-14).

Enable (переход в привилег.режим при знании пароля).

Администратор с уровнем привилегий 0-14.

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

Привилегированный
режим

sterragate#

configure (переход из консоли разграничения
доступа администратора. с уровнем привилегий15):

Логин – cscons
Пароль – csp.

enable (переход из режима пользователя администратора с уровнем
привилегий 0-14 при знании пароля, при этом происходит повышения
уровня привилегий до 15):
Пароль – csp.

Администратор с уровнем привилегий 15.

Все команды просмотра, работа с файлами, терминалом, запуск
команд ОС и утилит (регистрация лицензий, сертификатов, др.),
работа с текущей конфигурацией -очистка, загрузка, копирование
в файл, без возможности изменения.

Режим
конфигурирования

sterragate(config)#

configure terminal (переход из привилегированного
режима)

Администратор с уровнем привилегий 15.

Все настройки шлюза, создание пользователей для cisco-like консоли.

Выход из режимов выполняется с использованием команды
exit.

Ролевое управление

По мере роста размеров информационной системы и количества сотрудников компании решение задачи организации дискреционного управления доступом к данным для сотрудников разного уровня становится все более сложным. Число связей на уровне «пользователь – файл» возрастает практически в геометрической прогрессии, это создает нагрузку на систему и персонал. Решить задачу призвана модель ролевого управления доступом (РУД). Основа этой системы является создание промежуточной сущности – роли, при администрировании она занимает место между пользователем и объектом. Роль прямо не связана с пользователем, но она предоставляет права доступа к определенному классу объектов. Для одного пользователя одновременно может быть открыто несколько ролей с различными правами доступа, это позволяет управлять доступом к информационным ресурсам более гибко.

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

Заключение

По статистике около 70% утечек конфиденциальной информации происходит по вине сотрудников организации. Любые меры по противодействию утечкам информации делятся на два типа: превентивные меры и защитные.

Защитные меры – использование:

  • DLP
  • SIEM
  • СЗИ

Превентивные меры – инвентаризация, ресертификация и мониторинг прав доступа сотрудника. Основная задача — обеспечение сотрудникам необходимых и достаточных прав доступа для работы. Это позволяет минимизировать риски по утечке информации.

  • Контроль существующих прав доступа
  • Построение матрицы доступа
  • Мониторинг изменений ИС

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