Как составить матрицу доступа

Строим ролевую модель управления доступом. Часть первая, подготовительная

Сейчас я работаю в компании-вендоре программного обеспечения, в частности решений по управлению доступом. А мой опыт «из прошлой жизни» связан со стороной заказчика – крупной финансовой организацией. Тогда наша группа по контролю доступа в ИБ-департаменте не могла похвастаться большими компетенциями в IdM. Мы многому обучались в процессе, пришлось набить кучу шишек, чтобы выстроить в компании работающий механизм управления правами пользователей в информационных системах.

Объединив свой выстраданный в заказчике опыт с вендорскими знаниями и компетенциями, я хочу поделиться с вами по сути пошаговой инструкцией: как создать в крупной компании ролевую модель управления доступом, и что это даст на выходе. Моя инструкция состоит из двух частей: первая – готовимся строить модель, вторая – собственно строим. Перед вами часть первая, подготовительная.

N.B. Построение ролевой модели – это, к сожалению, не результат, а процесс. А точнее даже часть процесса созидания в компании экосистемы управления доступом. Так что настройтесь на игру вдолгую.

Сначала определимся – а что же такое управление доступом на основе ролей? Предположим, есть у вас крупный банк с десятками, а то и сотнями тысяч сотрудников (субъектов), у каждого из которых есть десятки прав доступа в сотни внутрибанковских информационных систем (объектов). А теперь умножьте число объектов на число субъектов – именно столько связей минимум вам нужно сначала выстроить, а потом контролировать. Реально это сделать вручную? Конечно нет – для решения этой задачи и появились роли.

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

Роли обычно создаются из отдельных полномочий сотрудника в каждой информационной системе. Потом из ролей каждой системы формируются глобальные бизнес-роли. Например, бизнес-роль «кредитный менеджер» будет включать в себя несколько отдельных ролей в информационных системах, которые используются в клиентском офисе банка. Скажем, в таких, как основная автоматизированная банковская система, кассовый модуль, система электронного документооборота, сервис-менеджер и других. Бизнес-роли, как правило, привязываются к организационно-штатной структуре – проще говоря, к набору подразделений компании и должностей в них. Так формируется глобальная ролевая матрица (пример привожу в табличке ниже).

Стоит отметить, что построить 100% ролевую модель, обеспечив всеми необходимыми правами сотрудников каждой должности в коммерческой структуре просто невозможно. Да это и не нужно. Ведь ролевая модель не может быть статичной, потому, что она зависит от постоянно меняющегося окружения. И от изменения бизнес-деятельности компании, которое, соответственно, влияет на изменение оргструктуры и функционала. И от отсутствия полного обеспечения ресурсами, и от несоблюдения должностных инструкций, и от стремления к прибыли в ущерб безопасности, и от многих других факторов. Поэтому нужно строить ролевую модель, которая сможет закрыть до 80% потребностей пользователей в необходимых базовых правах при назначении на должность. А остальные 20% они смогут, если нужно, дозапрашивать позже по отдельным заявкам.

Конечно, вы можете спросить: «А что, вообще не бывает 100% ролевых моделей?» Ну почему же, такое встречается, например, в некоммерческих структурах, которые не подвержены частым изменениям, – в каком-нибудь НИИ. Или в организациях ВПК с высоким уровнем защищённости, где безопасность стоит на первом месте. Бывает, и в коммерческой структуре, но в рамках отдельно-взятого подразделения, работа которого является достаточно статичным и предсказуемым процессом.

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

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

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

Все, кому интересно, как вообще появилось ролевое управление доступом, могут

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

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

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

Шаг 2. Аудируем ИТ-системы и составляем план приоритизации

На втором этапе следует провести аудит ИТ-систем, чтобы разобраться, как организован доступ в них. Например, в моей финансовой компании эксплуатировалось несколько сотен информационных систем. Во всех системах были некоторые зачатки ролевого управления, в большинстве – какие-то роли, но в основном на бумаге или в справочнике системы – они давно устарели, и доступ в них раздавался по фактическим запросам пользователей. Естественно, построить ролевую модель сразу в нескольких сотнях систем просто невозможно, надо с чего-то начинать. Мы провели углубленный анализ процесса управления доступом, чтобы определить уровень его зрелости. В процессе анализа выработали критерии приоритизации информационных систем – критичность, готовность, планы по выводу из эксплуатации и т.п. С их помощью выстроили очерёдность по разработке/актуализации ролевых моделей для этих систем. А затем – включили ролевые модели в план по интеграции с решением Identity Management, чтобы автоматизировать управление доступом.

Итак, как же определить критичность системы? Ответьте себе на следующие вопросы:

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

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

N.B. Крупные компании с развитыми ИТ-процессами наверняка знакомы с процедурой ИТ-аудита – IT general controls (ITGС), который позволяет выявить недостатки в ИТ-процессах и наладить контроль так, чтобы улучшить процессы в соответствии с best practice (ITIL, COBIT, IT Governance и др.) Такой аудит позволяет ИТ и бизнесу лучше понять друг друга и выработать совместную стратегию развития, проанализировать риски, оптимизировать затраты, выработать более эффективные подходы в работе.

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

Шаг 3 Создаем методологию

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

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

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

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

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

Шаг 4. Фиксируем параметры существующей модели управления доступом

Составляем так называемый «паспорт системы» в части управления доступом. По сути, это опросник по конкретной информационной системе, в котором зафиксированы все алгоритмы управления доступом к ней. Компании, которые уже внедряли у себя решения класса IdM, наверняка знакомы с подобным опросником, так как именно с него начинается исследование систем.

Часть параметров о системе и владельцах перетекла в опросник из реестра ИТ (см. шаг 2, аудит), но добавились и новые:

• как осуществляется управление учётными записями (напрямую в БД или через программные интерфейсы);
• как пользователи выполняют вход в систему (с помощью отдельной учётной записи или с использованием учётки AD, LDAP или др.);
• какие уровни доступа к системе используются (уровень приложения, системный уровень, использование системой сетевых файловых ресурсов);
• описание и параметры серверов, на которых работает система;
• какие операции по управлению учётными записями поддерживаются (блокировка, переименование и т.п.);
• по каким алгоритмам или правилам формируется идентификатор пользователя системы;
• по какому атрибуту можно установить связь с записью о сотруднике в кадровой системе (ФИО, табельный номер или др.);
• все возможные атрибуты учётной записи и правила их заполнения;
• какие права доступа существуют в системе (роли, группы, атомарные права и др., есть ли вложенные или иерархические права);
• механизмы разделения прав доступа (по должностям, подразделениям, функционалу и др.);
• есть ли в системе правила разграничения прав (SOD – Segregation of Duties), и как они работают;
• как обрабатываются в системе события отсутствия, перевода, увольнения, обновления данных о сотрудниках и т.п.

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

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

Ещё один документ, который нам понадобится при построении ролевой модели, – это справочник по всем возможным полномочиям (правам), которые можно предоставить пользователям в информационной системе с подробным описанием бизнес-функции, которая за этим стоит. Часто полномочия в системе зашифрованы определёнными наименованиями, состоящими из букв и цифр, и сотрудники бизнеса не могут разобраться, что кроется за этими символами. Тогда они идут в ИТ-службу, а там… тоже не могут ответить на вопрос, например, по редко используемым правам. Тогда приходится проводить дополнительное тестирование.

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

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

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

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

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

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

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

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

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

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

Автор: Людмила Севастьянова, менеджер по продвижению Solar inRights

Матрица доступа.

Основой дискреционной
политики безопасности является
избирательное управление доступом,
которое подразумевает, что:

■ все
субъекты и объекты системы должны быть
идентифицированы; –
права доступа субъекта к объекту
системы определяются на основании
некоторого правила (свойство
избирательности).

Для
описания свойств избирательного
управления доступом применяется модель
системы на основе матрицы доступа (МД),
иногда ее называют матрицей контроля
доступа. Матрица
доступа представляет собой прямоугольную
матрицу, в которой объекту
системы соответствует строка, а субъекту
столбец. На пересечении столбца
и строки матрицы указывается тип
разрешенного доступа субъекта к объекту.
Обычно выделяют такие типы доступа
субъекта к объекту, как “доступ на
чтение”, “доступ на запись”,
“доступ на исполнение” и др.

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

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

R
– чтение из объекта;

W
– запись в объект;

CR
– создание объекта;

D
– удаление объекта;

“+” – определяет
права доступа для данного субъекта;

“–” – не определяет
права доступа для данного субъекта.

Состояние
системы считается безопасным, если в
соответствии с политикой безопасности
субъектам разрешены только определённые
типы доступа к объектам
(в том числе отсутствие доступа)

Объектами защиты
на предприятии являются:

О1– Технические
средства приема, передачи и обработки
информации;

О2–Коммерческая
тайна

O3–Персональные
данные клиентов;

O4–Персональные
данные работников;

О5–Документированная
информация;

О6–Личные
дела работников, клиентов;

О7–Электронные
базы данных работников и клиентов;

О8–Бумажные
носители и электронные варианты приказов,
постановлений планов, договоров, отчетов,
составляющих коммерческую тайну;

О9–Средства защиты
информации (Антивирусные программы,
система сигнализации, система
противопожарной охраны и др.);

О10–Личные
дела бывших клиентов.

Субъектами доступа
к ресурсам предприятия являются:

S1–Директор;

S2-Главный
бухгалтер;

S3–Специалист

Табл.2. Матрица
доступа

	О1	О2	О3	О4	О5	О6	О7	О8	О9	О10
S1	R	R,W	R	R,W,CR,D+	R,W	R,W,CR,D+	R,W,CR,D	R,W	R,CR,W	R
S2	R,W	R	–	R	R+	R	–	R	R	–
S3	R	R	R,W	–	–	R	R,W,CR,D	R	R	R,W

Схема распределения
прав доступа к информации на предприятии:

Директор

Сервер

Гл.бухгалтер

Специалист

Классификация испд

Персональный
данные

В целях
дифференцированного подхода к обеспечению
безопасности ПДн в зависимости от объема
обрабатываемых ПДн и угроз безопасности
жизненно важным интересам личности,
общества и государства оператором ИСПДн
проводится классификация ИСПДн в
соответствии с «Порядком проведения
классификации информационных систем
персональных данных», утвержденным
приказом ФСТЭК России, ФСБ России и
Мининформсвязи России от 13 февраля
2008г. № 55/86/20. 
Порядок определяет
проведение классификации информационных
систем персональных данных, представляющих
собой совокупность персональных данных,
содержащихся в базах данных, а также
информационных технологий и технических
средств, позволяющих осуществлять
обработку таких персональных данных с
использованием средств автоматизации
(далее – информационные системы). 
При
проведении классификации информационной
системы учитываются следующие исходные
данные:

• категория
  обрабатываемых в информационной системе
  персональных данных – X пд:

	Табл.3. Категории персональных данных, обрабатываемых в ИС
категория 1	персональные данные, касающиеся расовой, национальной принадлежности, политических взглядов, религиозных и философских убеждений, состояния здоровья, интимной жизни
категория 2	персональные данные, позволяющие идентифицировать субъекта персональных данных и получить о нем дополнительную информацию, за исключением персональных данных, относящихся к категории 1
категория 3	персональные данные, позволяющие идентифицировать субъекта персональных данных
категория 4	обезличенные и (или) общедоступные персональные данные

• объем обрабатываемых
  персональных данных (количество
  субъектов персональных данных,
  персональные данные которых обрабатываются
  в информационной системе) – X нпд:

• 1 – в информационной
  системе одновременно обрабатываются
  персональные данные более чем 100 000
  субъектов персональных данных или
  персональные данные субъектов
  персональных данных в пределах субъекта
  Российской Федерации или Российской
  Федерации в целом;

• 2 – в информационной
  системе одновременно обрабатываются
  персональные данные от 1000 до 100 000
  субъектов персональных данных или
  персональные данные субъектов
  персональных данных, работающих в
  отрасли экономики Российской Федерации,
  в органе государственной власти,
  проживающих в пределах муниципального
  образования;

• 3 – в информационной
  системе одновременно обрабатываются
  данные менее чем 1000 субъектов персональных
  данных или персональные данные субъектов
  персональных данных в пределах конкретной
  организации.

• заданные
  оператором характеристики безопасности
  персональных данных, обрабатываемых
  в информационной системе:

• Типовые информационные
  системы – информационные системы, в
  которых требуется обеспечение только
  конфиденциальности персональных
  данных.

• Специальные
  информационные системы – информационные
  системы, в которых вне зависимости от
  необходимости обеспечения конфиденциальности
  персональных данных требуется обеспечить
  хотя бы одну из характеристик безопасности
  персональных данных, отличную от
  конфиденциальности (защищенность от
  уничтожения, изменения, блокирования,
  а также иных несанкционированных
  действий).

• структура
  информационной системы:

• автономные (не
  подключенные к иным информационным
  системам) комплексы технических и
  программных средств, предназначенные
  для обработки персональных данных
  (автоматизированные рабочие места);

• комплексы
  автоматизированных рабочих мест,
  объединенных в единую информационную
  систему средствами связи без использования
  технологии удаленного доступа (локальные
  информационные системы);

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

• наличие подключений
  информационной системы к сетям связи
  общего пользования и (или) сетям
  международного информационного обмена
  (имеющие подключения / не имеющие
  подключений);

• режим обработки
  персональных данных (однопользовательские
  / многопользовательские);

• режим разграничения
  прав доступа пользователей информационной
  системы (без разграничения прав доступа
  / с разграничением прав доступа);

• местонахождение
  технических средств информационной
  системы (в пределах Российской Федерации
  / за пределами Российской Федерации).

	Табл.4. Классы ИСПДн
Класс 1 (К1)	ИСПДн, для которых нарушение заданной характеристики безопасности ПДн, обрабатываемых в них, может привести к значительным негативным последствиям для субъектов персональных данных
Класс 2 (К2)	ИСПДн, для которых нарушение заданной характеристики безопасности ПДн, обрабатываемых в них, может привести к негативным последствиям для субъектов персональных данных
Класс 3 (К3)	ИСПДн, для. которых нарушение заданной характеристики безопасности ПДн, обрабатываемых в них, может привести к незначительным негативным последствиям для субъектов персональных данных
Класс 4 (К4)	ИСПДн, для которых нарушение заданной характеристики безопасности ПДн, обрабатываемых в них, не приводит к негативным последствиям для субъектов персональных данных

Класс информационной
системы определяется в соответствии с
таблицей 4.

Табл.5.
Определение класса ИС

Х пд   Х нпд	3	2	1
категория 4	К4	К4	К4
категория 3	К3	К3	К2
категория 2	К3	К2	К1
категория 1	К1	К1	К1

Соответственно,
категория персональных данных – 2, объем
обрабатываемых данных – от 1000 до 10 000
субъектов, и класс ИС – К3, т.е. ИСПДн,
для. которых нарушение заданной
характеристики безопасности ПДн,
обрабатываемых в них, может привести к
незначительным негативным последствиям
для субъектов персональных данных.

Исходя
из приказа ФСТЭК РФ
от 05.02.2010 г. № 58 «Об утверждении Положения
о методах и способах защиты информации
в информационных системах персональных
данных», и особенностей предприятия
можно сделать следующий вывод:

Для
информационных систем 3 класса при
многопользовательском режиме обработки
персональных данных и разных правах
доступа к ним пользователей применяются
следующие основные методы и способы
защиты информации:

а)
управление доступом:

идентификация
и проверка подлинности пользователя
при входе в систему по паролю
условно-постоянного действия длинной
не менее шести буквенно-цифровых
символов;

б)
регистрация и учет:

регистрация
входа (выхода) пользователя в систему
(из системы) либо регистрация загрузки
и инициализации операционной системы
и ее программного останова. Регистрация
выхода из системы или останова не
проводится в моменты аппаратурного
отключения информационной системы. В
параметрах регистрации указываются
дата и время входа (выхода) пользователя
в систему (из системы) или загрузки
(останова) системы, результат попытки
входа (успешная или неуспешная),
идентификатор (код или фамилия)
пользователя, предъявленный при попытке
доступа;

учет
всех защищаемых носителей информации
с помощью их маркировки и занесение
учетных данных в журнал учета с отметкой
об их выдаче (приеме);

в)
обеспечение целостности:

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

г)
физическая охрана информационной
системы (устройств и носителей информации),
предусматривающая контроль доступа в
помещения информационной системы
посторонних лиц, наличие надежных
препятствий для несанкционированного
проникновения в помещения информационной
системы и хранилище носителей информации;

д)
периодическое тестирование функций
системы защиты персональных данных при
изменении программной среды и пользователей
информационной системы с помощью
тест-программ, имитирующих попытки
несанкционированного доступа;

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

Соседние файлы в папке курсовая docx200

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Использование систем и принципов разграничения доступа к информации в организациях стало одной из ключевых мер для обеспечения информационной безопасности. Неконтролируемые права персонала, наличие большого числа пользователей с привилегированными правами доступа способны привести к дополнительным рискам. Для ограничения доступа и получения наглядной картины прав можно использовать матрицу доступа к информационным ресурсам (МД). Она реализуется как в качестве отдельного бумажного документа, так и цифрового решения, интегрированного в информационную структуру организации.

Что такое матрица доступа (МД)?

Матрица доступа (МД) – это готовая модель, позволяющая регламентировать доступ к информационным ресурсам компании, но основании которой можно оценить состояние и структуру защиты данных в информационных системах. В матрице четко устанавливаются права для каждого субъекта по отношению ко всем объектам информации. Визуально это можно представить в качестве некого массива данных со множеством ячеек, которые формируются пересечением строки, указывающей на субъект и столбика, указывающего на объект. Получается, что при таком подходе к управлению доступом ячейка содержит определенную запись, характерную для пары субъект-объект и указывает на режим доступа, разрешенный или запрещенный, или его характеристику для каждого конкретного случая. В матрице доступа к информационным ресурсам столбец отождествляется с перечнем контроля доступа, строка выполняет роль профиля доступа присущего объекту.

Примеры использования матрицы доступа

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

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

• Производство – доступ к технической и инженерной информации, запрет на доступ к ПДн сотрудников, финансовой, коммерческой, кадровой информации.

• Бухгалтерия – доступ к финансовой, кадровой информации, ПДн сотрудников, запрет на доступ к технической и инженерной информации.

• Отдел продаж – доступ к технической, коммерческой информации, запрет на доступ к инженерной, финансовой, кадровой информации, ПДн сотрудников.

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

IDM/IGA Solar inRights в качестве инструмента управления доступом: преимущества использования

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

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

2. Удобство и эффективность. Система работает в автоматическом режиме, исключает человеческий фактор. Заявки на смену, расширение, удаление прав обрабатываются быстро, что помогает избежать простоев в работе и возникновения нарушений.

3. Разгрузка IT-отдела, сокращение трудозатрат. Большая часть рутинной работы, связанной с назначением прав и управления ими автоматизирована, исполняется по готовым шаблонам. Достаточно создать группы и добавить им общие права по матрице доступов.

4. Строгий контроль за внешними и временными работниками. Сотрудники других компаний и временно работающие лица могут представлять дополнительную угрозу безопасности. Установление такому персоналу прав на основе наименьших привилегий и только на определённое время снижает вероятность возникновения инцидентов.

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

Пост, который вы сейчас читаете, – продолжение статьи о том, как правильно выстроить в крупной компании ролевую модель управления доступом пользователей к различным системам. Напомним: построение ролевой модели – это скорее процесс, чем результат, и первую часть нашей дилогии мы посвятили подготовке к «строительству» . В ней мы рассказали, как создать функциональную модель каждого подразделения и должности, провести аудит ИТ-систем и расставить их по приоритетам, создать бизнес-ориентированное описание прав пользователей и о других важных подготовительных шагах. Сегодня же поговорим о способах построения ролевой модели, ролевых матрицах, чем здесь поможет внедрение автоматизированных систем управления доступом (IdM/IGA), и что вы получите на выходе.

Для построения ролевой модели в информационной системе есть два способа.

Первый подход

Роли разрабатываются на основании функциональной модели. Этот подход возможен, когда в организации есть специальное подразделение технологов, назовём его «Организационно технологический отдел (ОТО)». У нас в банке такой отдел был в составе ИТ-департамента. Отдел будет переводить потребности бизнеса, описанные в функциональной модели, на язык ИТ: язык прав/опций/полномочий, которые нужно предоставить в системе для выполнения конкретного функционала.

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

Второй подход

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

Если система не очень большая и в ней немного разнообразных прав, то выделить общие совпадающие права у сотрудников одной должности несложно. Из них можно составить роль, а затем направить её на согласование и утверждение руководителю, владельцу ресурса и далее по цепочке, как в первом случае. Если же в системе очень много прав (полномочий), и ее использует большое число сотрудников из разных подразделений, то задача усложняется. В этом случае на помощь приходят специализированные утилиты, именуемые Role mining, которые облегчают задачу. Они собирают совпадающие права для определённой должности в стандартную роль, которая анализируется и утверждается заинтересованными сторонами.

Строим ролевую модель по второму подходу

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

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

Пример шаблона для заполнения ролевых матриц

Наш шаблон выглядел так. На первом листе слева (по вертикали) были перечислены должности и подразделения, а сверху (по горизонтали) – роли. На пересечении необходимо было установить маркер, указав, для какого подразделения необходима какая роль/роли. Цветной заливкой мы отмечали: зелёным – роли, которые должны быть предоставлены по умолчанию, при назначении на должность; жёлтым – роли, которые могут быть запрошены для конкретной должности или подразделения по отдельной дополнительной заявке.

На втором листе мы разместили справочник, который показывал наполнение ролей отдельными правами (полномочиями).

На третьем листе – матрицу SOD-конфликтов (запрета на возможное сочетание ролей).

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

Для тех систем, в которых много пользователей и структура прав довольно разнообразная, составить матрицу в ручном режиме очень непросто. Мы использовали для этих целей специализированные инструменты построения ролевой модели Role mining. Инструменты эти могут сильно отличаться логикой работы, стоимостью, удобством использования и другими характеристиками. Но принцип работы и цели у них общие — это сбор информации о текущих правах сотрудника в информационных системах, анализ повторяемости этих прав для сотрудников с одинаковыми атрибутами, объединение этих прав в роли и, в конечном итоге, построение некой базовой ролевой модели, которая отражает текущее положение дел.

Сейчас, по прошествии времени и работая в компании, которая разрабатывает ПО для управления доступом, я понимаю, что есть и более эффективные методы построения ролевых моделей в крупных системах. Чем раньше организация придет к использованию автоматизированных средств для наведения порядка, тем более гладко и безболезненно пройдёт процесс построения ролевых моделей. В этом случае автоматизированная система будет помощником или подспорьем в построении ролей. Внедрение автоматизированных систем управления доступом (IdM/IGA) нужно начинать с подключения кадровых источников и целевых систем для выгрузки данных и их мапинга и анализа. Используя специализированные инструменты, встроенные в решения по управлению доступом, можно с самого начала достаточно эффективно выстроить нужные процессы на основе автоматизации. Это значительно сократит трудозатраты и исключит шоковую терапию в будущем. Например, гораздо быстрее и эффективнее пройдёт процесс работы с учётными записями, а именно на первом этапе:

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

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

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

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

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

• Права доступа определяются наличием / отсутствием ролевой модели по конкретной информационной системе. Как говорилось выше, выстроить ролевые матрицы сразу по всем ИС просто невозможно, нужно действовать постепенно, в соответствии с утверждённым планом.
• Если утверждённой ролевой модели пока в системе нет, то права, как минимум, должны быть согласованы с руководителем подразделения и владельцем ресурса.
• Если ролевая модель разработана и утверждена, то права назначаются/изменяются на её основе.
• Должен быть определён порядок согласования, предоставления и аннулирования нестандартных прав.
  В любом процессе есть исключения и ограничения. Поэтому необходимо учесть взаимозаменяемость сотрудников в период отсутствия, незаполненные вакансии, а также отдельные функциональные роли, которые предоставляются по запросам.
  Однако и в случае с исключениями необходим строгий порядок и контроль персональной авторизации. Во-первых, она должна быть обоснована и согласована в соответствии с утверждённым регламентом.
  Во-вторых, по тем правам, которые предоставляются на время, должна быть разработана процедура их своевременного отзыва. Здесь также очень помогут IdM/IGA-системы, которые позволяют заложить и автоматизировать маршруты согласования нестандартных прав, реализовать процедуру автоматического прекращения доступа по истечение заданного срока. А отчётность, которую можно настроить в системе, позволит регулярно анализировать и оценивать ситуацию с персональными правами. Если таких прав становится слишком много, то есть повод пересмотреть подход совместно с владельцем ресурса и доработать стандартные роли. Ведь судя по всему, они перестали обеспечивать потребности сотрудников, и их необходимо дополнить нужными правами для выполнения функционала в полном объеме.
• В регламенте нужно закрепить порядок предоставления и аннулирования доступа к информационным системам внешним сотрудникам. По таким категориям сотрудников надо вести отдельный контроль, т.к. они отсутствуют в кадровом источнике и информация о них, как правило, фиксируется в отдельных списках чуть ли не вручную или не фиксируется вообще. Если же в компании уже применяется автоматизированная система управления доступом, то она является общим справочником по всем работникам, использующим ресурсы компании. В этом случае внешние сотрудники просто не смогут получить доступ к ресурсам компании в обход нее. Кроме того, по истечении договора подряда доступ будет своевременно заблокирован в автоматическом режиме.

Актуализация ролевой модели

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

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

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

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

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

Помимо изменений в ролевой модели на основании вышеописанных причин нужен систематический плановый пересмотр прав. В частности, для финансовых компаний таких регулярных пересмотров требуют надзорные органы. Пересмотры позволяют выявлять недочёты в существующей модели прав и повышать контроль за полномочиями пользователей. Решение этой задачи значительно упрощают IGA/IdM-системы, которые позволяют автоматизировать процесс пересмотра (ресертификации) с заданной периодичностью.

Подведём итоги

Управление доступом с использованием ролевой модели повышает уровень информационной безопасности компании, т.к. доступ становится более прозрачным, управляемым и контролируемым. А также снижает нагрузку на подразделение ИТ в части его администрирования. Что станет делать проще с помощью ролевого управления доступом?

• Вы сможете предоставлять одинаковые права многим сотрудникам, занимающим одинаковую должность или работающим в одном подразделении. Достаточно предоставить им одну и туже роль.
• Вы сможете менять права для сотрудников одной должности быстро, в несколько кликов. Достаточно добавить или удалить права в составе общей роли.
• Вы сможете строить иерархию ролей и устанавливать правила наследования полномочий, что упрощает структуру доступа.
• Вы сможете вводить разграничения полномочий (SOD) – запрет на сочетание одной роли с другой.

Однако одним лишь построением ролевой модели не решить вопрос качественного и эффективного управления доступом в большой компании – это только один из шагов. Если построить ролевую модель и на этом успокоиться, через какое-то время она устареет, и грандиозная проделанная работа окажется абсолютно бесполезной. Почему?

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

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

Автор: Людмила Севастьянова, менеджер по продвижению Solar inRights

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

Введение

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

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

Ресурсы и мандаты

То, к чему тот или иной пользователь может получить доступ, мы назовём ресурсом. Ресурсом может являться как область хранилища (например, каталог или файл на сервере), так и некая совокупность ресурсов в сети Интернет (например, «социальные сети», «видеохостинги»). Отдельным видом ресурсов является также право полного доступа к областям хранилища или ресурсам сети. В матрице доступа в рамках этой статьи ресурсы будут представлять собой столбцы таблицы.

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

Мандат — понятие разрешительного типа, то есть он не может являться запретом на доступ, а только лишь в некоторых случаях частичным разрешением (например, разрешение на чтение файла). Я знаю, что, например, в системе безопасности Windows возможна реализация запретительных мандатов. Однако я не буду их рассматривать, так как это решение платформно-зависимо и, на мой взгляд, только вносит путаницу.

Матрица доступа

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

В рамках данной статьи условимся о следующих знаках:

•+ — наличие доступа, если бессмысленно говорить о его типе (например, в случае доступа в Интернет), а также полный доступ (чтение, запись, создание файла)

•R — доступ только на чтение

•M — доступ на чтение и запись, без возможности создания нового файла

Выстроив таким образом таблицу, мы сопоставляем мандаты с ресурсами и получаем эскиз политики безопасности.

Следующий этап — внедрение. Для этого следует мандаты интерпретировать в сущности используемой вами платформы — то есть расставить соответствующие права группам, настроить объекты групповых политик (если речь идет об Active Directory), создать списки доступа на маршрутизаторах, разнести пользователей по группам, присвоить им IP-адреса из соответствующих диапазонов и так далее. Конкретные шаги зависят от используемых платформ, оборудования, опыта системного администратора и т.п. Этот этап невозможно рассмотреть детально в этой статье — для этого потребовалась бы книга немалых объёмов.

Примеры

Я предвижу возглас читателя: «хватит умных слов, покажи на пальцах!» Извольте.

Краткое ТЗ в вольном стиле (как обычно излагает заказчик)

В компании имеются отделы:

•продаж

•сметный

•производственный

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

Руководству надо видеть всё. И опять же — своя папочка на сервере, чтоб никто не видел.

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

Анализ и рассуждения

О мандатах. Мы можем явно выделить мандаты отделов, а также явно добавляется руководство. С бухгалтерией сложнее — там есть стажёр и не стажёры. Впрочем, для инженера в производственном отделе тоже надо предусмотреть мандат. Ещё неявно объявляется сам системный администратор. Для ограниченного доступа лучше выбирать низший общий уровень, а потом избирательно повышать. Таким образом для бухгалтерии у нас образуется три мандата: «бухгалтерия», «доступ к соцсетям» и «доступ к видео». Для производственников — «производство» и опять же «доступ к видео». Для кассы (относящейся к бухгалтерии) придётся снова сделать понижение уровня мандатов: бухгалтерии вообще отключаем интернет и вводим отдельный мандат «интернет». Руководству и системному администратору разделение доступа не нужно, для оптимизации мы можем ввести в матрицу отдельный ресурс.

О ресурсах. Хранилища отделов — очевидны. О доступе к интернету — у нас есть практически 5 вариантов: без интернета, интернет без соцсетей и видео, интернет без соцсетей, интернет без видео, и полный интернет. 5 вариантов можно уложить в 3 бита. Логично таким образом сделать интернет с ограничениями плюс два отдельных ресурса: соцсети и видео. В общем-то, некоторые ресурсы в данном примере выродились в отдельные мандаты, но зато мы их видим в общей картине.

Матрица доступа

Пример реализации: Active Directory + MikroTik

Создание доменных групп «Руководители», «Бухгалтерия», «Продажники» и «Сметчики» очевидно. Создание общих ресурсов на сервере или сетевом хранилище — тоже. Благодаря матрице мы сможем правильно расставить права доступа к общим ресурсам. Таким образом, главный бухгалтер будет иметь мандаты «Бухгалтерия», «Интернет», «Видео», а стажёр — только «Бухгалтерия» и «Интернет». «Исключительный» инженер на производстве — «Производство» и «Видео». При определённых обстоятельствах можно вообще напрямую отобразить мандаты на группы, и тогда понятие «имеет мандат» будет тождественно понятию «является членом группы».

На маршрутизаторе MikroTik можно пойти разными путями.

Можно использовать встроенный прокси-сервер (со своей системой контроля доступа) и сделать его принудительным для тех, у кого в мандате нет доступа к ресурсу «Неограниченный интернет». Можно использовать policy routing. Можно использовать фильтр пакетов 7-го уровня ISO/OSI. Можно просто заблокировать диапазоны IP-адресов вручную. Простор для фантазии неограничен.

Как определить, есть ли в мандате пользователя тот или иной доступ? Можно использовать DHCP-сервер для выдачи разным группам пользователей разных IP-адресов. Можно настроить IAS (в Windows Server 2008 — NPS) и авторизовывать пользователей для доступа в интернет через RADIUS. Опять многое зависит от того, каким путём вы будете решать эту задачу, что вам привычней, какие нюансы организационного устройства и оборудования придётся учесть. Но теперь у вас перед глазами схема: вот сюда надо дать доступ этим, а вот этим надо дать вот такие-то мандаты.

Пример реализации: Linux + MikroTik

Этот случай мало чем отличается от предыдущего, разве что использовать надо будет LDAP как таковой или при помощи 389 Directory Server. На уровне файловой системы в хранилище нужна поддержка ACL. Далее матрица подскажет, кому и что разрешить.

Впрочем, тут очень неплохим решением была бы ферма терминальных серверов и парк тонких клиентов, работающих по «голому» X11 (в локалке) или NX (если есть пользователи вне локальной сети). Хотя вот и Wayland на подходе…

Заключение

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

Даже если предприятие достаточно велико и запросы по системе безопасности высоки, построение матрицы доступа позволяет лучше понять и уложить в сознании задачу. А правильно и наглядно сформулированная задача — это зачастую более половины её решения.

Автор: m0Ray