Русский
Русский
English
Статистика
Реклама

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

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

09.07.2020 10:15:09 | Автор: admin
Сейчас я работаю в компании-вендоре программного обеспечения, в частности решений по управлению доступом. А мой опыт из прошлой жизни связан со стороной заказчика крупной финансовой организацией. Тогда наша группа по контролю доступа в ИБ-департаменте не могла похвастаться большими компетенциями в 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, чтобы автоматизировать управление доступом.

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

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

В своей финансовой компании мы провели аудит так. Руководство разработало процедуру аудита 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
Подробнее..

Какие проблемы может выявить аудит прав доступа и что с этим делать

21.01.2021 10:23:56 | Автор: admin
Управление доступом один из самых непростых моментов в любой немаленькой компании. Для того чтобы все было по уму, должна быть налажена совместная работа между ИТ-отделами, подразделениями безопасности, кадровиками и руководителями групп и подразделений. И без аудита прав доступа здесь не обойтись. Он может быть как внутренним, так и внешним. Очевидно, что проблемы лучше выявить и устранить на этапе собственной проверки, чем потом получить по голове от регулятора или доиграться до утечки информации либо другого крупного инцидента.

В этой статье я расскажу о том, какие проблемы можно выявить при аудите прав доступа в компании и как можно упростить себе жизнь с помощью современных IdM/IGA-решений (Identity Management/Identity Governance and Administration).



Нарушения есть? А если найду?


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

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



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

Со временем термин проник и в другие сферы, в том числе в ИТ в целом и информационную безопасность в частности; есть специально разработанные стандарты для отделов информационных технологий в любой организации. COBIT пакет международных и национальных стандартов и руководств в области управления IT и аудита IT-безопасности. Европейский стандарт GDPR, охватывающий широкий спектр вопросов безопасности и защиты данных. Международный стандарт безопасности данных индустрии платежных карт PCI DSS и т. д. Уровень соответствия таким стандартам можно установить с помощью аудита.

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

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

Зачем нужен аудит прав доступа


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

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

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

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

Какие проблемы можно выявить с помощью аудита


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

Незаблокированные учетные записи


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

Накопление прав


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

Бесхозные учетные записи


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

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

Слабые пароли и их ненадежное хранение


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

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

Небезопасное хранение данных на сетевых ресурсах


Каждая организация за годы эксплуатации систем генерирует огромные объемы информации, которые с течением времени только увеличиваются. По оценкам аналитической компании Gartner, как минимум 80% корпоративных данных являются неструктурированными. 7 из 10 пользователей имеют доступ к данным, которого у них быть не должно. Аудиторские проверки во многих компаниях выявляют следующее: конфиденциальная информация, которая хранится на файловых серверах, в облачных хранилищах, на корпоративных порталах, в общих ящиках электронной почты и т. д., не защищена и доступна множеству сотрудников. А это может привести к серьезным инцидентам ИБ: личные данные клиентов и сотрудников, коммерческие предложения, закрытые исследования и прочие секретные сведения могут быть украдены. Кроме того, в некоторых случаях хранение данных должно соответствовать законодательству (например, персональные данные) или стандартам (например, PCI DSS).

Несанкционированный доступ


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

Используем решения класса IdM/IGA


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

Проблема с незаблокированными учетками решается автоматической блокировкой. Она происходит моментально, как только увольнение зафиксировано в отделе кадров. Кстати, для ряда компаний, особенно финансовых, это одно из требований регуляторов, например, в части соблюдения стандарта PSI DSS (немедленный отзыв доступа для уволенных работников и необходимость деактивации неактивных пользовательских аккаунтов по истечении 90 дней).



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

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

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



Подключая дополнительные модули, мы можем вообще отказаться от кучи паролей, на радость сотрудникам. Например, служба аутентификации SSO (Single Sign-On) позволяет использовать один набор учетных данных для входа в несколько приложений. Система сама автоматически подставит сложные и безопасные пароли в нужное время и будет хранить их в секрете даже от самого пользователя. Если применять альтернативные средства аутентификации (смарт-карты, биометрию и т. п.), можно полностью отказаться от использования паролей самим сотрудником. А безопасность при этом не пострадает.

Решение класса IdM/IGA в комплексе с системами класса DAG (Data Access Governance) помогут разобраться с небезопасным хранением больших объемов неструктурированных данных, точнее, упорядочат сами данные и контроль за ними. Комплексные решения позволят выявить и категоризировать данные, обнаружить конфиденциальные и наиболее ценные для компании активы, а автоматизированные средства позволят проводить регулярный пересмотр прав доступа к ресурсам и отзыв прав у тех, кто в таком доступе не нуждается. Благодаря постоянному мониторингу пользователей, получающих доступ к критичным данным, мы сможем на ранней стадии выявлять угрозы, обнаруживать утечки и реагировать на них.

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

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

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



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

Выводы


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

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

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

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru