Портал №1 по управлению цифровымии информационными технологиями. Зачем нужны права доступа в it системах

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

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

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

Структура ролей в SimpleOne состоит из трех уровней, каждый из которых предоставляет владельцу определенные права

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

Специалисты (пользователи, работающие с системой ITSM) — примеры включают агентов ITSM (пользователей решения ITSM) с определенной операционной ролью. Сотрудники в роли агента ITSM выполняют конкретные задачи в системе, такие как обработка инцидентов или работа с CMDB. Поскольку некоторые задачи требуют больше полномочий, пользователям назначаются различные роли ITSM-агентов. Для удобства в SimpleOne включены ключевые предопределенные роли, такие как ITSM_agent, change_manager, CMDB_manager, incident_manager и service_catalogue_manager. Из названия каждой роли уже понятно, какую силу она дает своему владельцу.

Подробнее о ключевых ролях вы можете прочитать в технической документации решения ITSM SimpleOne.

Администратор находится на вершине иерархии SimpleOne и предоставляет владельцу доступ ко всем функциям платформы, включая администрирование. Существует два типа ролей администратора: формальный и специалист. Стандартная роль включает в себя подразделы admin и security_admin. Первый обеспечивает все административные функции платформы, кроме назначения прав доступа, а второй позволяет управлять правами доступа, но не позволяет изменять параметры. Специальные роли администраторов предоставляют ограниченные привилегии: import_admin — управление импортом; notification_admin — управление уведомлениями; impersonation — возможность «видеть систему глазами другого пользователя» (подробнее см. ниже).

Администраторы SimpleOne не ограничиваются перечисленными выше ролями, но могут создавать свои собственные пользовательские роли и назначать необходимые привилегии. Это требует создания собственных правил ACL (Access Control List).

Наследование

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

Андрей является специалистом технической поддержки и занимается изменениями и инцидентами. Для выполнения своих обязанностей его руководитель вручную назначил ему роль incident_manager. Далее процесс развивается в соответствии с принципами марионетки: поскольку Эндрю является членом команды ITSM_admins, он наследует роль ITSM_admin, роли problem_manager и change_manager наследуются ITSM_ команда менеджеров, а роль ITSM_agent наследуется ITSM_agent Команда. Затем он унаследовал роль impersonators от команды Impersonators, которая является частью команды security_admin.

Защита «от дурака»

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

Включение этой опции для роли пользователя отключает ее по умолчанию и включает только по запросу. Например, на схеме выше показано, что пользователю Admin назначена роль security_admin, но для ее использования требуется дополнительная активация из меню пользователя. Таким образом, дополнительные роли активируются только при необходимости. Масштабирование привилегий возможно только между уровнями базовых ролей. Это означает, что пользователи с ролью incident_manager не могут добавить масштабируемую роль problem_manager, поскольку обе они относятся к одному уровню агентов ITSM, но могут быть расширены до администратора, что сразу же дает пользователю полные привилегии.. После активации опции.

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

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

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

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

Модель универсального управления доступом на основе ролей была впервые предложена Дэвидом Феррайоло и Ричардом Куном из Национального института стандартов и технологий (NIST) в 1992 году. В нем определены основные понятия, взаимосвязи и зависимости, а также представлена роль контроля (RBAC) как альтернатива обязательному контролю доступа (MAC) и проверке доступа к функциям (DAC). О них и других моделях вы можете прочитать здесь. Сегодня этот документ превратился в полноценный международный стандарт Inset 359-2012. Об этом будет рассказано более подробно.

Преимущества ролевого управления доступом

По сравнению с вышеперечисленными моделями, контроль доступа на основе ролей имеет несколько важных преимуществ. Например:.

• Возможность построения иерархии ролей с наследованием набора прав. Это позволяет упростить ролевую модель, особенно в организациях с разнородной инфраструктурой, где используется много информационных систем. С использованием иерархии нет необходимости повторно указывать права в нескольких подобных ролях, достаточно поместить их в одну большую роль, как дочерние, указав лишь уникальные права для каждой роли.
• Просто и эффективно осуществляется предоставление одинаковых прав большому количеству пользователей – достаточно назначить пользователям одну роль.
• При необходимости изменения набора прав большому количеству пользователей достаточно изменить набор прав в роли.
• Возможность реализации принципа разделения полномочий (SoD – Segregation of Duties). Это значительно снижает риск предоставления пользователям избыточных полномочий, например, когда две роли не могут быть в один момент времени назначены одному пользователю.

Особенности

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

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

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

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

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

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

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

IdM/IGA система: что это такое, как работает и зачем нужно

Решения IDM (Identity Management) или IGA (Identity Governance and Administration) обеспечивают централизованное управление правами доступа и учетными записями пользователей в различных информационных системах/приложениях, которые компания использует в своей деятельности. С его помощью:.

— Снижается нагрузка на системного менеджера. Работа с учетными записями (создание новых учетных записей, временные обязательства, изменение прав, удаление) занимает важную часть времени системного менеджера. Чем больше решений приобретает компания, имеющая счет, тем дольше срок. Организация централизованного управления с помощью IDM может значительно снизить нагрузку на системного менеджера.

— Риски информационной безопасности сведены к минимуму. Автоматизированное централизованное управление правами доступа со своевременными уведомлениями значительно снижает вероятность превышения прав доступа.

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

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

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

Кроме того, управление идентификацией позволяет компании соответствовать ряду требований и рекомендаций государственных документов/регулятивных органов. Например, BR IBBS, PCI DSS или ISO 27001.

Как и в каких системах организуется централизованное управление учетными записями с помощью IdM/IGA

Категория Identity Management или Identity Governance and Management может управлять учетными данными для различных информационных систем и программ. Например, IDM/IGA Solar INRTS совместим с.

-C Популярные системы и инфраструктуры, в том числе на базе SAP и 1С.

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

— Программное обеспечение для электронного документооборота, CRM, ERP, почтовые системы, управление кадровыми файлами и другие решения с API или без него.

При отсутствии API интеграция целевой системы возможна через загрузку файлов (например, Solar Inrights поддерживает файлы Excel, CSV или XML).

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

Работа IdM/IGA в комплексе с другими системами обеспечения информационный безопасности

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

Интеграция IGA с ACS может повысить защиту целевой системы и предотвратить такие ситуации, как, например, несанкционированное использование чужой учетной записи в отсутствие владельца. Это относительно просто. Пока сотрудник не находится в пределах периметра, защищенного АСУ, его «учетная запись» остается заблокированной и недоступной.

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

Кроме того, современные решения IDM/IGA могут быть интегрированы в другие элементы ИС. Например, использование ISM, инфраструктуры открытых ключей (PKI) и решений SSO (технология единого подключения).

Взаимодействие с целевыми информационными системами (CRM, ERP, HR и т.д.) и другой информацией, обеспечивающей безопасность компании, организуется посредством связей. Это специальные программные элементы, включенные в IDM «из коробки». В зависимости от взаимодействия с решением, ссылками могут быть API целевой системы, вопросы, хранимые процедуры, файлы или другие средства. Это не проблема, если ваша компания использует специфический программный продукт, для которого нет готовой ссылки. Например, Solar Inrights может адаптировать предлагаемое решение к потребностям клиента, при необходимости улучшив существующие связи или создав конкретный продукт с нуля в течение двух недель. Все подлежит обсуждению. Поддержка Identity Connector Framework (ICF) без необходимости использования дополнительных адаптеров значительно упрощает процесс разработки связей и сокращает время и ресурсы, необходимые для интеграции с системой.

Кому стоит подумать об использовании IdM/IGA

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

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

— Существуют условия инцидента, связанные с чрезмерным доступом и привилегиями.

— Наблюдается смена персонала и высокая ротация кадров.

— Используется ряд различных ИТ-решений с правами доступа.

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