Что такое матрица доступа к информационным ресурсам
Строим ролевую модель управления доступом. Часть первая, подготовительная
Сейчас я работаю в компании-вендоре программного обеспечения, в частности решений по управлению доступом. А мой опыт «из прошлой жизни» связан со стороной заказчика – крупной финансовой организацией. Тогда наша группа по контролю доступа в ИБ-департаменте не могла похвастаться большими компетенциями в IdM. Мы многому обучались в процессе, пришлось набить кучу шишек, чтобы выстроить в компании работающий механизм управления правами пользователей в информационных системах. 
Объединив свой выстраданный в заказчике опыт с вендорскими знаниями и компетенциями, я хочу поделиться с вами по сути пошаговой инструкцией: как создать в крупной компании ролевую модель управления доступом, и что это даст на выходе. Моя инструкция состоит из двух частей: первая – готовимся строить модель, вторая – собственно строим. Перед вами часть первая, подготовительная.
N.B. Построение ролевой модели – это, к сожалению, не результат, а процесс. А точнее даже часть процесса созидания в компании экосистемы управления доступом. Так что настройтесь на игру вдолгую.
Сначала определимся – а что же такое управление доступом на основе ролей? Предположим, есть у вас крупный банк с десятками, а то и сотнями тысяч сотрудников (субъектов), у каждого из которых есть десятки прав доступа в сотни внутрибанковских информационных систем (объектов). А теперь умножьте число объектов на число субъектов – именно столько связей минимум вам нужно сначала выстроить, а потом контролировать. Реально это сделать вручную? Конечно нет – для решения этой задачи и появились роли.
Роль – это набор полномочий, который необходим пользователю или группе пользователей для выполнения определённых рабочих задач. Каждый сотрудник может иметь одну или несколько ролей, а каждая роль может содержать от одного до множества полномочий, которые разрешены пользователю в рамках этой роли. Роли могут быть привязаны к определённым должностям, подразделениям или функциональным задачам работников.
Роли обычно создаются из отдельных полномочий сотрудника в каждой информационной системе. Потом из ролей каждой системы формируются глобальные бизнес-роли. Например, бизнес-роль «кредитный менеджер» будет включать в себя несколько отдельных ролей в информационных системах, которые используются в клиентском офисе банка. Скажем, в таких, как основная автоматизированная банковская система, кассовый модуль, система электронного документооборота, сервис-менеджер и других. Бизнес-роли, как правило, привязываются к организационно-штатной структуре – проще говоря, к набору подразделений компании и должностей в них. Так формируется глобальная ролевая матрица (пример привожу в табличке ниже).
Стоит отметить, что построить 100% ролевую модель, обеспечив всеми необходимыми правами сотрудников каждой должности в коммерческой структуре просто невозможно. Да это и не нужно. Ведь ролевая модель не может быть статичной, потому, что она зависит от постоянно меняющегося окружения. И от изменения бизнес-деятельности компании, которое, соответственно, влияет на изменение оргструктуры и функционала. И от отсутствия полного обеспечения ресурсами, и от несоблюдения должностных инструкций, и от стремления к прибыли в ущерб безопасности, и от многих других факторов. Поэтому нужно строить ролевую модель, которая сможет закрыть до 80% потребностей пользователей в необходимых базовых правах при назначении на должность. А остальные 20% они смогут, если нужно, дозапрашивать позже по отдельным заявкам.
Конечно, вы можете спросить: «А что, вообще не бывает 100% ролевых моделей?» Ну почему же, такое встречается, например, в некоммерческих структурах, которые не подвержены частым изменениям, – в каком-нибудь НИИ. Или в организациях ВПК с высоким уровнем защищённости, где безопасность стоит на первом месте. Бывает, и в коммерческой структуре, но в рамках отдельно-взятого подразделения, работа которого является достаточно статичным и предсказуемым процессом.
Главный плюс ролевого управления – это упрощение выдачи прав, потому что количество ролей существенно меньше, чем пользователей информационной системы. Причем это справедливо для любой отрасли.
Возьмем ритейловую компанию: в ней трудятся тысячи продавцов, но набор прав в системе N у них одинаковый, и для них будет создана всего одна роль. Пришёл в компанию новый продавец – ему автоматически назначена нужная роль в системе, в которой уже есть все необходимые полномочия. Так же в один клик можно поменять права для тысячи продавцов разом, например, добавить новую опцию по формированию отчёта. Не нужно делать тысячу операций, привязывая новое право к каждой учётной записи – достаточно внести эту опцию в роль, и она появится у всех продавцов одновременно.
Еще одно преимущество ролевого управления – исключение выдачи несовместимых полномочий. То есть сотрудник, имеющий определённую роль в системе, не может одновременно иметь другую роль, права которой не должны сочетаться с правами в первой. Яркий пример – запрет на совмещение функций ввода и контроля финансовой операции.
Все, кому интересно, как вообще появилось ролевое управление доступом, могут
Если обратиться к истории, то впервые ИТ-сообщество задумалось о методах управления доступом ещё в 70-х годах XX века. Хотя приложения были тогда достаточно простыми, но, как и сейчас, всем очень хотелось удобно управлять доступом к ним. Предоставлять, менять и контролировать права пользователей – просто чтобы легче было понимать, какой доступ есть у каждого из них. Но в то время не существовало никаких общих стандартов, разрабатывались первые системы по управлению доступом, и каждая компания основывалась на свих собственных представлениях и правилах.
Сейчас уже известно много разных моделей управления доступом, но появились они не сразу. Остановимся на тех, которые внесли ощутимый вклад в развитие этого направления.
Первая и, наверное, самая простая модель – Дискреционное (избирательное) управление доступом (DAC – Discretionary access control). Эта модель подразумевает совместное использование прав всеми участниками процесса доступа. Каждый пользователь получает доступ к конкретным объектам или операциям. По сути здесь множество субъектов прав соответствует множеству объектов. Такая модель была признана слишком гибкой и слишком сложной для сопровождения: списки доступа со временем становятся огромными и трудно контролируемыми.
Вторая модель – это Мандатное управление доступом (MAC — Mandatory access control). По этой модели каждый пользователь получает доступ к объекту в соответствии с оформленным допуском к тому или иному уровню конфиденциальности данных. Соответственно объекты должны быть категорированы по уровню конфиденциальности. В отличие от первой гибкой модели, эта, наоборот, оказалась слишком строгой и ограничительной. Её применение не оправдывает себя, когда в компании множество разнообразных информационных ресурсов: чтобы разграничить доступ к разным ресурсам, придётся вводить множество категорий, которые не будут пересекаться.
В связи с очевидным несовершенством этих двух методов ИТ-сообщество продолжило разработку моделей, более гибких и при этом более-менее универсальных для поддержки разных типов организационных политик контроля доступа. И вот тогда появилась третья модель управления доступом на основе ролей! Этот подход оказался самым перспективным, поскольку он требует не только авторизации личности пользователя, но и его рабочих функций в системах.
Первую чётко описанную структуру ролевой модели предложили американские учёные Девид Феррайло и Ричард Кун из Национального института стандартов и технологий США в 1992 году. Тогда впервые появился термин RBAC (Role-based access control). Эти исследования и описания основных компонентов, а также их взаимосвязи легли в основу действующего по сей день стандарта INCITS 359-2012, утвержденного Международным комитетом по стандартам информационных технологий (INCITS).
Стандарт определяет роль как «должностную функцию в контексте организации с некоторой связанной семантикой в отношении полномочий и ответственности, возложенных на пользователя, назначенного на роль». Документ устанавливает основные элементы RBAC – пользователи, сессии, роли, разрешения, операции и объекты, а также отношения и взаимосвязи между ними.
В стандарте дана минимально необходимая структура для построения ролевой модели – объединение прав в роли и затем выдача доступа пользователям через эти роли. Обозначены механизмы составления ролей из объектов и операций, описаны иерархия ролей и наследование полномочий. Ведь в любой компании есть роли, объединяющие элементарные полномочия, которые необходимы всем сотрудникам компании. Это может быть доступ к электронной почте, к СЭД, к корпоративному порталу и т.п. Эти полномочия можно включить в одну общую роль под названием «сотрудник», и не нужно будет в каждой из ролей более высокого уровня перечислять все элементарные права раз за разом. Достаточно просто указать признак наследования роли «сотрудник».
Позже стандарт был дополнен новыми атрибутами доступа, связанными с постоянно меняющимся окружением. Добавилась возможность введения статических и динамических ограничений. Статические подразумевают невозможность совмещения ролей (тот самый ввод и контроль операций, упоминавшийся выше). Динамические ограничения могут определяться меняющимися параметрами, например, временем (рабочие/нерабочие часы или дни), местоположением (офис/дом) и т.п.
Отдельно стоит сказать про управление доступом на основе атрибутов (ABAC — Attribute-based access control). Подход строится на предоставлении доступа с помощью правил совместного использования атрибутов. Эта модель может использоваться отдельно, но довольно часто она активно дополняет классическую ролевую: к определённой роли можно добавлять атрибуты пользователей, ресурсов и устройств, а также времени или местоположения. Это позволяет использовать меньше ролей, вводить дополнительные ограничения и сделать доступ минимально достаточным, а, следовательно, повысить безопасность.
Например, бухгалтеру можно разрешить доступ к счетам, если он работает в определённом регионе. Тогда местоположение специалиста будет сравниваться с определённым эталонным значением. Или можно дать доступ к счетам, только если пользователь авторизуется с устройства, внесённого в реестр разрешённых. Хорошее дополнение к ролевой модели, но самостоятельно используется нечасто из-за необходимости создавать много правил и таблиц разрешений или ограничений.
Приведу пример применения ABAC из моей «прошлой жизни». В нашем банке было несколько филиалов. Сотрудники клиентских офисов в этих филиалах выполняли абсолютно одинаковые операции, но должны были работать в основной системе только со счетами своего региона. Сначала мы начали создавать отдельные роли для каждого региона – и таких ролей с повторяющимся функционалом, но с доступом к разным счетам получилось ну ооочень много! Тогда, использовав атрибут местоположения для пользователя и связав его с конкретным диапазоном счетов для проверки, мы значительно уменьшили количество ролей в системе. В результате остались роли только для одного филиала, которые тиражировались на соответствующие должности во всех остальных территориальных подразделениях банка.
А теперь поговорим о необходимых подготовительных шагах, без которых просто невозможно построить работающую ролевую модель.
Шаг 1. Создаем функциональную модель
Начать стоит с создания функциональной модели – верхнеуровневого документа, в котором подробно описан функционал каждого подразделения и каждой должности. Как правило, информация в него попадает из различных документов: должностных инструкций и положений по отдельным подразделениям – отделам, управлениям, департаментам. Функциональная модель должна быть согласована со всеми заинтересованными подразделениями (бизнес, внутренний контроль, безопасность) и утверждена руководством компании. Для чего нужен этот документ? Для того, чтобы ролевая модель могла на него ссылаться. Например, вы собираетесь строить ролевую модель на основе уже имеющихся прав сотрудников – выгруженных из системы и «приведённых к единому знаменателю». Тогда при согласовании полученных ролей с бизнес-владельцем системы можно сослаться на конкретный пункт функциональной модели, на основании которого в роль включается то или иное право.
Шаг 2. Аудируем ИТ-системы и составляем план приоритизации
На втором этапе следует провести аудит ИТ-систем, чтобы разобраться, как организован доступ в них. Например, в моей финансовой компании эксплуатировалось несколько сотен информационных систем. Во всех системах были некоторые зачатки ролевого управления, в большинстве – какие-то роли, но в основном на бумаге или в справочнике системы – они давно устарели, и доступ в них раздавался по фактическим запросам пользователей. Естественно, построить ролевую модель сразу в нескольких сотнях систем просто невозможно, надо с чего-то начинать. Мы провели углубленный анализ процесса управления доступом, чтобы определить уровень его зрелости. В процессе анализа выработали критерии приоритизации информационных систем – критичность, готовность, планы по выводу из эксплуатации и т.п. С их помощью выстроили очерёдность по разработке/актуализации ролевых моделей для этих систем. А затем – включили ролевые модели в план по интеграции с решением Identity Management, чтобы автоматизировать управление доступом.
Итак, как же определить критичность системы? Ответьте себе на следующие вопросы:
N.B. Крупные компании с развитыми ИТ-процессами наверняка знакомы с процедурой ИТ-аудита – IT general controls (ITGС), который позволяет выявить недостатки в ИТ-процессах и наладить контроль так, чтобы улучшить процессы в соответствии с best practice (ITIL, COBIT, IT Governance и др.) Такой аудит позволяет ИТ и бизнесу лучше понять друг друга и выработать совместную стратегию развития, проанализировать риски, оптимизировать затраты, выработать более эффективные подходы в работе.
Одним из направлений аудита является определение параметров логического и физического доступа к информационным системам. Полученные данные мы взяли за основу для дальнейшего использования при построении ролевой модели. В результате такого аудита у нас появился реестр ИТ-систем, в котором были определены их технические параметры и даны описания. Кроме того, для каждой системы был определён владелец от бизнес-направления, в интересах которого она эксплуатировалась: именно он отвечал за бизнес-процессы, которые эта система обслуживала. Также был назначен менеджер ИТ-службы, ответственный за техническую реализацию потребностей бизнеса в конкретной ИС. Были зафиксированы самые критичные для компании системы и их технические параметры, сроки ввода и вывода из эксплуатации и др. Эти параметры очень помогли в процессе подготовки к построению ролевой модели.
Шаг 3 Создаем методологию
Залог успеха любого дела – правильно выбранный метод. Поэтому и для построения ролевой модели, и для проведения аудита нам нужно создать методологию, в которой мы опишем взаимодействие между подразделениями, закрепим ответственность в регламентах компании и т.п.
Для начала нужно исследовать все имеющиеся документы, которые устанавливают порядок предоставления доступа и прав. По-хорошему, процессы должны быть документированы на нескольких уровнях:
По приказу руководства была создана рабочая группа, в которую вошли представители направлений безопасности, ИТ, бизнеса и внутреннего контроля. В приказе были обозначены цели создания группы, направление деятельности, срок существования и ответственные от каждой стороны. Кроме того, мы разработали методику проведения аудита и порядок построения ролевой модели: их согласовали все ответственные представители направлений и утвердило руководство компании.
Документы, описывающие порядок проведения работ, сроки, ответственность и т.д. – залог того, что на пути к заветной цели, которая вначале не всем очевидна, ни у кого не возникнет вопросов «а для чего мы это делаем, а зачем нам это надо и т.п.» и не будет возможности «соскочить» или затормозить процесс.
Шаг 4. Фиксируем параметры существующей модели управления доступом
Составляем так называемый «паспорт системы» в части управления доступом. По сути, это опросник по конкретной информационной системе, в котором зафиксированы все алгоритмы управления доступом к ней. Компании, которые уже внедряли у себя решения класса IdM, наверняка знакомы с подобным опросником, так как именно с него начинается исследование систем.
Часть параметров о системе и владельцах перетекла в опросник из реестра ИТ (см. шаг 2, аудит), но добавились и новые:
Шаг 5. Создаем бизнес-ориентированное описание полномочий
Ещё один документ, который нам понадобится при построении ролевой модели, – это справочник по всем возможным полномочиям (правам), которые можно предоставить пользователям в информационной системе с подробным описанием бизнес-функции, которая за этим стоит. Часто полномочия в системе зашифрованы определёнными наименованиями, состоящими из букв и цифр, и сотрудники бизнеса не могут разобраться, что кроется за этими символами. Тогда они идут в ИТ-службу, а там… тоже не могут ответить на вопрос, например, по редко используемым правам. Тогда приходится проводить дополнительное тестирование.
Хорошо, если бизнес-описание уже есть или даже есть объединение этих прав в группы и роли. Для некоторых приложений лучшей практикой является создание подобного справочника ещё на этапе их разработки. Но такое встречается нечасто, поэтому опять идём в ИТ-подразделение, чтобы собрать информацию обо всех возможных правах и их описать. Наш справочник в итоге будет содержать следующее:
Шаг 6 Выгружаем из систем данные о пользователях и правах и сопоставляем с кадровым источником
На заключительном этапе подготовки нужно выгрузить данные из информационных систем обо всех пользователях и правах, которые они имеют на текущий момент. Здесь возможны два сценария. Первый: у подразделения безопасности есть доступ напрямую в систему и есть средства выгрузки соответствующих отчётов, что бывает нечасто, но очень удобно. Второй: отправляем запрос в ИТ на получение отчётов в нужном формате. Практика показывает: договориться с ИТ и получить необходимые данные с первого раза не удаётся. Нужно сделать несколько подходов, пока информация будет получена в нужном виде и формате.
Какие данные необходимо выгрузить:
Затем, если у вас в компании нет автоматизированных средств закрытия доступа уволенным сотрудникам (такое нередко встречается) или есть лоскутная автоматизация, которая не всегда корректно срабатывает, нужно выявить все «мёртвые души». Речь об учётных записях уже уволенных сотрудников, права которых по какой-то причине не заблокированы, – их нужно заблокировать. Для этого сопоставляем выгруженные данные с кадровым источником. Кадровую выгрузку тоже нужно предварительно получить у подразделения, ведущего кадровую базу.
Отдельно необходимо отложить учётки, владельцы которых не нашлись в кадровой базе, не закреплённые ни за кем, – то есть бесхозные. По этому списку нам понадобится дата последнего использования: если она довольно свежая, то всё же придётся поискать владельцев. Сюда могут относиться аккаунты внешних подрядчиков или служебные учётки, ни за кем не закреплённые, но связанные с какими-либо процессами. Для выяснения принадлежности учёток можно разослать по всем подразделениям письма с просьбой отозваться. Когда владельцы найдутся, вносим данные о них в систему: таким образом все действующие учётки опознаны, а остальные блокируем.
Как только наши выгрузки очищены от лишних записей и остались одни активные учетки, можно приступать к построению ролевой модели по конкретной информационной системе. Но об этом я расскажу уже в следующей статье.
Автор: Людмила Севастьянова, менеджер по продвижению Solar inRights
Ролевая модель доступа. Инвентаризация прав доступа
Утечки информации по вине сотрудников являются одной из важнейших угроз, с которыми приходится бороться службам информационной безопасности любой компании. Любые избыточные права доступа сотрудников ведут к увеличению риска утечки информации. В статье рассказывается о ролевой модели прав доступа, процессе инвентаризации выданных прав доступа и выявлении несоответствий на примере системы управления и контроля доступа «КУБ».
Введение
Рост компании = ужесточение контроля
Недопущение утечек информации является одной из важнейших задач службы информационной безопасности любой компании. Если есть конфиденциальная информация (государственная, коммерческая тайна, персональные данные), то существует задача ее защиты. С ростом организации, увеличивается опасность хищения информации, в том числе сотрудниками, возрастают финансовые и репутационные риски, это приводит к ужесточению политик и систем контроля.
Одним из первых этапов по упорядочиванию процесса выдачи прав к информационным системам – ввод системы согласования заявок.
Рисунок 1. Ввод системы согласования заявок
Далее обычно принимаются меры по уменьшению полномочий сотрудников, такие как запрет создания ресурсов и изменения прав доступа к тем ресурсам, где пользователь владелец, блокировка прав локального администратора и так далее.
Следующим этапом, как правило, вводится периодическая инвентаризация и ресертификация существующих прав доступа, то есть пересмотр прав пользователей к информационным ресурсам компании.
Инвентаризация прав доступа
Давайте остановимся подробнее на последних операциях.
Представьте, что нужно узнать, к каким ресурсам имеет доступ сотрудник, работающий в организации пять лет. Сколько это займет времени? 15-20 минут? А если необходимо провести проверку 50 сотрудников?
Информационные системы:
Рисунок 2. Типовой доступ сотрудника к информационным системам предприятия
Для чего же необходимо производить инвентаризацию доступа? Основная задача – обеспечение сотрудникам необходимых и достаточных прав доступа для работы. Это права доступа строго необходимые для выполнения должностных обязанностей на текущий момент. Инвентаризация позволяет выявить привилегии, которые на данный момент исполнения обязанностей сотрудника не являются необходимыми.
Чтобы понять всю сложность инвентаризации, давайте посмотрим как обычно осуществляется предоставление доступа в организации?
Чаще всего запрос и согласование доступа осуществляется в системе электронного документооборота, с помощью корпоративной почты или веб-портала, либо просто по телефону. После того, как запрос согласован, доступ выдан, заявка отправляется в архив, если таковой существует. При этом механизме оперативного отслеживания существующих полномочий сотрудника чаще всего нет. В таких ситуациях единственная возможность выявить текущие права доступа сотрудников – проведение оперативной или плановой инвентаризации.
Рисунок 3. Пример отчета «Инвентаризация прав доступа», предоставляемый системой управления и контроля доступа «КУБ»
Наиболее оптимальным решением проблемы инвентаризации существующих прав доступа – использование ролевой модели и типового доступа. Давайте рассмотрим подробнее эти понятия.
Типовой доступ
Типовой доступ – это использование шаблонных групп, профилей, ролей в информационных системах для предоставления доступа. Например, в 1С 8.2 – использование профиля «Менеджер», который включает в себя определенный набор элементарных ролей и прав доступа к таблицам. Или управление членством группы в Active Directory «Доступ к папке «Текущие проекты» чтение» для предоставления прав доступа к разделяемому каталогу. Использование шаблонов позволяет сократить время на аудит прав пользователя и формализует процедуру их предоставления.
Рисунок 4. Использование шаблонных групп, ролей и профилей
Ролевая модель
Ролевая модель (RBAC) – использование формализованных шаблонов на предприятии, которые содержат необходимые полномочия для осуществления определенной деятельности. Для решения большинства задач организации существуют ролевые полномочия, присваиваемые сотрудникам. Например:
В рамках ролевой модели доступа на основе матрицы доступа в разрезе подразделений и должностей используется такие сущности, как: бизнес-роли, должностной доступ и, в исключительных случаях, индивидуальный доступ
Должностной доступ представляет собой набор базовых прав, которые имеют сотрудники одного отдела на одной должности. Зачастую, это минимально необходимые привилегии для выполнения рабочих обязанностей.
Рисунок 5. Использование шаблонов должностного доступа
Например: создание учетной записи в AD для входа в домен, создание корпоративного почтового ящика, выделения доступа к корпоративной папке отдела на файлообменнике и регистрация в профильной информационной системе с базовыми правами (ERP, CRM, СЭД).
Бизнес-роль
Бизнес-роли включают в себя типовой доступ, который сотрудник запрашивает (либо ему выдается) для выполнения определенных функций – участия в проекте, выполнения поручений руководства, командировка.
Рисунок 6. Использование шаблонов бизнес-ролей
Индивидуальный доступ
Индивидуальный доступ необходим для решения конкретных задач, поставленных руководителем, это дополнительные права, которые сотрудник запрашивает с помощью интерфейса самообслуживания: веб-портала, ITSM-системы и пр.
При применении ролевой модели доступа, количество индивидуальных прав обычно составляет 5-10% от общего количества привилегий.
Данная схема позволяет значительно снизить объем производимой инвентаризации, так как есть права, характерные для должностей, которые априори присутствуют у сотрудника и в большинстве случаев достаточны для работы. Так же есть типовые права, если сотрудник участвует в проекте на определенной роли.
Рисунок 7. Процесс предоставления индивидуальных прав доступа
Сертификация доступа
Для контроля за состоянием индивидуальных прав доступа сотрудников многие организации ввели процедуру сертификации доступа, в процессе которой непосредственные руководители или ответственные лица проводят периодическую переаттестацию индивидуальных привилегий сотрудника.
С помощью IDM-системы, например, «КУБ» эту процедуру можно автоматизировать. Руководитель будет периодически получать уведомления со списком индивидуальных привилегий его подчиненных, которые он может продлить на расчетный период или отобрать.
Есть другой вид переаттестации, когда доступ подтверждается не руководителем, а согласующими лицами, которые утверждали первоначальный доступ.
Рисунок 8. Утверждение индивидуальных прав доступа
Работа с несоответствиями
Как правило, в IDM-решении присутствуют механизмы отслеживания, так называемых, несоответствий. Несоответствие – это изменение прав доступа сотрудников, изменение атрибутов ресурсов и информационных систем в обход процедуры согласования и без уведомления сотрудников службы ИБ.
Рисунок 9. Отслеживание несоответствий в правах доступа
IDM-решения производят мониторинг информационных систем на предмет изменения состояний, после чего соотносят эти изменения с заявками, созданными в IDM.
Рисунок 10. Мониторинг изменений доступа в информационных системах
Если соответствующих запросов на доступ нет, то событие считается нелегитимным. По данному факту оповещается ответственный за информационную систему. По результатам расследования инцидента может приниматься решение об отклонении изменений (тогда IDM автоматически «откатывает» состояние системы) либо об их утверждении.
Рисунок 11. Несоответствие прав доступа фиксируются системой
Заключение
По статистике около 70% утечек конфиденциальной информации происходит по вине сотрудников организации. Любые меры по противодействию утечкам информации делятся на два типа: превентивные меры и защитные.
Защитные меры – использование:
Использование матрицы доступа, ролевой модели и механизмов работы с несоответствиями позволит реализовать политики информационной безопасности, направленные на предотвращение утечек информации в организации.