Red hat identity management что это
Red hat identity management что это
Технология многопользовательского доступа, требующего разграничения прав, появилась в эпоху мейнфреймов. В те времена все основные вычислительные функции, включая управление доступом к информационным ресурсам, были сосредоточены на уровне мейнфрейма. Однако в начале 1990–х с распространением персональных компьютеров и клиент-серверных приложений ситуация изменилась. Централизованная обработка данных стала более распределённой. Возникла потребность, чтобы доступом к ресурсам, расположенным теперь уже на нескольких машинах, управляли самые разные пользователи, подключающиеся к сети с различных компьютеров. Иначе говоря, между сущностями «ресурс», «пользователь» и «рабочая станция» появились связи «много-ко-многим» (см. Рисунок 1), что серьёзно усложнило управление.
Рисунок 1. Управление доступом в современной среде
В середине 1990–х компания Microsoft в рамках Windows NT предложила технологию управления доступом под названием «контроллер домена». Контроллер домена — это сервер, обеспечивающий централизованную идентификацию и авторизацию пользователей и компьютеров в домене Windows. В начале 2000–х для хранения учётных данных Microsoft ввела в действие службу каталогов Active Directory, благодаря которой технология контроллера доменов претерпела значительные изменения и в этом виде — без какой–либо значительной модернизации — дошла до наших дней.
В среде Linux до недавнего времени не было технологии централизованного управления доступом, которая бы решала задачу в комплексе. Вместо этого применялись различные протоколы и приложения, решающие частные задачи. Одни средства (например, NIS или Kerberos) определяли домены, другие — обеспечивали хранение идентификационных данных, третьи (например, Sudo) — задавали права доступа. Эти приложения с трудом взаимодействовали друг с другом, и каждое из них нужно было администрировать отдельно и локально. Например, чтобы задать единые политики доступа, нужно было вручную синхронизировать конфигурационные файлы по всем серверам сети или писать для этого своё собственное приложение. А это — затраты и ещё раз затраты.
Чтобы сделать управление доступом в большой корпоративной сети простым, понятным, а главное — недорогим, разработчики компании Red Hat создали набор средств, объединённых под названием Red Hat Enterprise Linux Identity Management (IdM). Благодаря IdM управление всеми субъектами и объектами доступа теперь происходит в одном месте с помощью одних и тех же программных средств. Пользователи, компьютеры, информационные сервисы и политики доступа определяются единообразно. Новые рабочие станции без дополнительных хлопот получают доступ к заданным ресурсам путём включения в соответствующий домен. Пользователю системы достаточно авторизоваться один раз, чтобы получить доступ ко всем сервисам, на которые он имеет право.
В части архитектуры IdM представляет собой многокомпонентный сервис (см. Рисунок 2).
Рисунок 2. Компоненты Red Hat Identification Management
Рассмотрим ситуацию, когда каждый из этих сервисов размещается на отдельном сервере. До появления IdM администратору пришлось бы настраивать сервер LDAP, сервер KDC, сервер DNS и т. д. по отдельности, используя самые разные локальные инструменты. В IdM же разработан единый набор инструментов, который даёт возможность администратору управлять всеми параметрами домена централизованно как с помощью консоли, так и через web-интерфейс.
Представляем интеграцию единого входа через веб (Web SSO) и объединения удостоверений (identity federation)
Недавно компания Red Hat выпустила новый сервер единой идентификации на основе технологий Keycloak. Теперь вы можете пользоваться готовым и полностью поддерживаемым поставщиком удостоверений на основе SAML 2.0 или OpenID Connect, который связывает корпоративный каталог пользователей или стороннего поставщика удостоверений с вашими приложениями при помощи стандартных маркеров. Keycloak — это система нового поколения, которая заменяет технологию PicketLink связующего программного обеспечения JBoss. В будущем Keycloak обеспечит единый вход в Red Hat Cloud Suite и такие системы управления, как Red Hat Satellite.
Обзор возможностей
По сути, Keycloak — это поставщик удостоверений на основе SAML 2.0 или OpenID Connect; его возможности и настройка подробно описаны на портале для пользователей.
Поддержка клиентов
В состав Keycloak входит центральный сервер идентификации, к которому клиенты, имеющие соответствующий адаптер или модуль, подключаются с помощью конфигурации управления удостоверениями.
Keycloak поддерживает множество различных клиентов, в числе которых:
● Red Hat JBoss Enterprise Application Platform версий 6.4 и 7.0;
● Red Hat JBoss Fuse 6.2 (в виде ознакомительной технической версии);
● Red Hat Enterprise Linux 7.2 (с помощью модуля mod_auth_mellon для SAML 2.0).
Интеграция удостоверений
Keycloak можно использовать для интеграции пользователей с помощью служб каталогов на основе LDAP, в числе которых:
● Microsoft Active Directory;
● RHEL Identity Management.
Keybloak также поддерживает Kerberos на основе SPNEGO при использовании Microsoft Active Directory и RHEL Identity Management.
Работа с посредниками по авторизации
Keycloak интегрируется с поставщиками входа в системы через социальные сети, в том числе:
● Facebook;
● Google;
● Twitter.
Интерфейсы администрирования
Управлять сервером Keycloak, областями идентификации и клиентами можно с помощью веб-интерфейса или набора REST API. Это позволяет решать весь комплекс задач при проектировании среды идентификации, в том числе назначать роли пользователям, регистрировать клиентов, интегрировать пользователей и обеспечивать авторизацию через посредников.
Цикл подписки и поддержки
На текущий момент единая идентификация пользователей доступна в составе пакета JBoss Core Services Collection с 3-летним циклом поддержки. Мы планируем предлагать систему единой идентификации пользователей на основе Keycloak в виде службы платформы контейнеров Red Hat OpenShift Container Platform и платформы приложений Red Hat Mobile Application Platform, а также в виде интегрированного поставщика удостоверений для платформы Red Hat OpenStack Platform.
В долгосрочной перспективе Keycloak станет центральным компонентом идентификации пользователей и клиентов, а также интеграции поставщиков удостоверений. Он охватит существующую инфраструктуру, в том числе внутренние каталоги пользователей или внешних облачных поставщиков удостоверений (например, социальные сети) и обеспечит единый вход в продукты Red Hat и интеграцию удостоверений.
Identity Management or Red Hat Directory Server – Which One Should I Use?
In the identity management server space Red Hat has two offerings: Identity Management (IdM) in Red Hat Enterprise Linux and Red Hat Directory Server (RHDS). This article is dedicated to helping you understand why there are two solutions and how to chose the best one for your environment.
Before diving in too deep
it might be wise to more formally define IdM and RHDS. IdM is a domain controller, its main purpose is to manage identities within the enterprise. It is a component of Red Hat Enterprise Linux and is made available at no extra charge (i.e. it’s included with all Red Hat Enterprise Linux server subscriptions). RHDS, on the other hand, is a fully functional directory server. It is a tool for building your business applications and, unlike IdM, it is its own product and has its own price tag.
Management of enterprise identities aside, another major area where identity management is of great importance is business applications. For example, let’s pretend your company provides an online service that customers pay for. For applications of this nature you usually need a place to store customer account information and authentication credentials. Traditionally, Directory Servers were the best technology for this task. Choosing RHDS as a back-end for your business application is thus a logical choice.
Could IdM be used in such cases (i.e. for identity management of business applications)? Probably. but maybe not. Business applications usually require a lot of customization of the directory server structure called schema. While changing schema for a DS is normal / fully expected, changing schema for IdM should be done carefully and following the specific rules. Why the caution? The reason is that IdM includes different components that are expected to work together. These components make a series of assumptions about data structures. so changes to IdM schema might inadvertently cause one or more of these components to fail. IdM was built with flexibility in mind and is not totally locked down. One can safely make changes to the IdM schema but only following specific rules as described/outlined in the FreeIPA project.
The considerations above lead to the following summary:
Stay tuned as I plan to explore certificates in my next entry. Until then – feel free to reach out using the comments section below.
4.9. Управление идентификацией (машинный перевод)
Проверка нового синтаксиса пароля на сервере каталогов
Это усовершенствование добавляет новые проверки синтаксиса паролей на сервер каталогов. Администраторы теперь могут, например, включить проверку словаря, разрешить или запретить использование последовательностей символов и палиндромов. В результате, если этот параметр включен, проверка синтаксиса политики паролей на сервере каталогов обеспечивает более безопасные пароли.
Сервер каталогов теперь обеспечивает улучшенную поддержку ведения журнала внутренних операций
Дополнительные сведения о ведении журнала внутренних операций см. По ссылке: https: //access.redhat.com/documentation/en-us/red_hat_directory_server/11/html-single/administration_guide/#logging_internal_operations.
tomcatjss библиотека поддерживает проверку OCSP с использованием респондента из расширения AIA
С этим улучшением tomcatjss библиотека поддерживает проверку протокола состояния сертификата в сети (OCSP) с использованием ответчика из расширения сертификата доступа к информации (AIA). В результате администраторы Red Hat Certificate System теперь могут настроить проверку OCSP, которая использует URL-адрес из расширения AIA.
Сервер каталогов представляет новые утилиты командной строки для управления экземплярами
Ниже приведен обзор назначения каждой утилиты:
Использовать dsconf утилита для управления экземплярами сервера каталогов во время выполнения. Например, используйте dsconf чтобы:
Использовать dsctl утилита для управления экземплярами сервера каталогов, когда они в автономном режиме. Например, используйте dsctl чтобы:
Эти утилиты заменяют сценарии Perl и оболочки, помеченные как устаревшие в Directory Server 10. Скрипты все еще доступны в неподдерживаемых 389-ds-base-legacy-tools пакет, однако Red Hat поддерживает управление сервером каталогов только с помощью новых утилит.
Обратите внимание, что настройка сервера каталогов с помощью инструкций LDIF все еще поддерживается, но Red Hat рекомендует использовать утилиты.
Для получения дополнительной информации об использовании утилит см. Red Hat Directory Server 11 Documentation
pki subsystem-cert-find а также pki subsystem-cert-show Команды теперь показывают серийный номер сертификатов
С этим улучшением pki subsystem-cert-find а также pki subsystem-cert-show Команды в Системе сертификатов показывают серийный номер сертификатов в их выходных данных. Серийный номер является важной частью информации и часто требуется для нескольких других команд. В результате определить серийный номер сертификата теперь проще.
pki user а также pki group Команды устарели в системе сертификатов
Система сертификатов теперь поддерживает автономное обновление системных сертификатов.
Благодаря этому усовершенствованию администраторы могут использовать функцию автономного обновления для обновления системных сертификатов, настроенных в системе сертификатов. Когда срок действия системного сертификата истекает, система сертификатов не запускается. В результате усовершенствования администраторам больше не нужны обходные пути для замены устаревшего системного сертификата.
Система сертификатов теперь может создавать CSR с расширением SKI для подписи внешнего CA
Благодаря этому усовершенствованию Система сертификатов поддерживает создание запроса на подпись сертификата (CSR) с расширением Subject Key Identifier (SKI) для подписи внешнего центра сертификации (CA). Некоторым ЦС требуется это расширение либо с определенным значением, либо из открытого ключа ЦС. В результате администраторы теперь могут использовать pki_req_ski параметр в файле конфигурации передается в pkispawn утилита для создания CSR с расширением SKI.
Локальные пользователи кэшируются SSSD и обслуживаются через nss_sss модуль
В RHEL 8 демон служб безопасности системы (SSSD) обслуживает пользователей и группы из /etc/passwd а также /etc/groups файлы по умолчанию. sss Модуль nsswitch предшествует файлам в /etc/nsswitch.conf файл.
Преимущество обслуживания локальных пользователей через SSSD состоит в том, что nss_sss модуль имеет быстрый memory-mapped cache это ускоряет поиск NSS по сравнению с доступом к диску и открытием файлов при каждом запросе NSS. Ранее демон кэширования службы имен ( nscd ) помог ускорить процесс доступа к диску. Однако, используя nscd параллельно с SSSD является громоздким, так как и SSSD, и nscd использовать собственное независимое кеширование. Следовательно, используя nscd в установках, где SSSD также обслуживает пользователей из удаленного домена, например LDAP или Active Directory, может вызвать непредсказуемое поведение.
С этим обновлением разрешение локальных пользователей и групп в RHEL 8 стало быстрее. Обратите внимание, что root пользователь никогда не обрабатывается SSSD, поэтому root На разрешение не может повлиять потенциальная ошибка в SSSD. Также обратите внимание, что если SSSD не работает, nss_sss модуль корректно обрабатывает ситуацию, возвращаясь к nss_files чтобы избежать проблем. Вам не нужно настраивать SSSD каким-либо образом, домен файлов добавляется автоматически.
KCM заменяет KEYRING в качестве хранилища кэша учетных данных по умолчанию
В RHEL 8 хранилищем кэша учетных данных по умолчанию является диспетчер учетных данных Kerberos (KCM), который поддерживается sssd-kcm Deamon. KCM преодолевает ограничения ранее использовавшегося KEYRING, такие как его сложность в использовании в контейнерах, поскольку он не имеет пространства имен, а также для просмотра и управления квотами.
В этом обновлении RHEL 8 содержит кэш учетных данных, который лучше подходит для контейнерных сред и обеспечивает основу для создания дополнительных функций в будущих выпусках.
Пользователи Active Directory теперь могут администрировать Identity Management
Пользователи AD теперь могут использовать функции самообслуживания IdM UI, например, для загрузки своих ключей SSH или изменения своих личных данных. Администратор AD может полностью администрировать IdM, не имея двух разных учетных записей и паролей. Обратите внимание, что в настоящее время выбранные функции в IdM могут быть недоступны для пользователей AD.
sssctl печатает отчет по правилам HBAC для домена IdM
С этим обновлением sssctl утилита System Security Services Daemon (SSSD) может распечатать отчет об управлении доступом для домена Identity Management (IdM). Эта функция отвечает требованиям определенных сред для просмотра по нормативным причинам списка пользователей и групп, которые могут получить доступ к конкретному клиентскому компьютеру. Бег sssctl access-report domain_name на клиенте IdM печатает проанализированное подмножество правил управления доступом на основе хоста (HBAC) в домене IdM, которые применяются к клиентскому компьютеру.
Обратите внимание, что никакие другие поставщики, кроме IdM, не поддерживают эту функцию.
Пакеты Identity Management доступны в виде модуля
В RHEL 8 пакеты, необходимые для установки сервера и клиента Identity Management (IdM), поставляются в виде модуля. client поток является потоком по умолчанию idm модуль, и вы можете скачать пакеты, необходимые для установки клиента, не включая поток.
Добавлено решение для записи сессии для RHEL 8
Решение для записи сеансов было добавлено в Red Hat Enterprise Linux 8 (RHEL 8). Новый tlog Пакет и связанный с ним проигрыватель сеансов веб-консоли позволяют записывать и воспроизводить сеансы пользовательского терминала. Запись может быть настроена для каждого пользователя или группы пользователей с помощью службы System Security Services Daemon (SSSD). Весь ввод и вывод терминала фиксируется и сохраняется в текстовом формате в системном журнале. Ввод неактивен по умолчанию из соображений безопасности, чтобы не перехватывать необработанные пароли и другую конфиденциальную информацию.
Решение может быть использовано для аудита пользовательских сессий в системах, чувствительных к безопасности. В случае нарушения безопасности записанные сеансы могут быть рассмотрены как часть криминалистического анализа. Системные администраторы теперь могут настраивать запись сеанса локально и просматривать результат через интерфейс веб-консоли RHEL 8 или через интерфейс командной строки, используя tlog-play полезность.
authselect упрощает настройку аутентификации пользователя
Это обновление представляет authselect утилита, которая упрощает настройку аутентификации пользователя на хостах RHEL 8, заменяя authconfig полезность. authselect поставляется с более безопасным подходом к управлению стеком PAM, который упрощает изменения конфигурации PAM для системных администраторов. authselect может использоваться для настройки методов аутентификации, таких как пароли, сертификаты, смарт-карты и отпечатки пальцев. Обратите внимание, что authselect не настраивает службы, необходимые для подключения к удаленным доменам. Эта задача выполняется специализированными инструментами, такими как realmd или же ipa-client-install
SSSD теперь позволяет вам выбрать одно из нескольких устройств аутентификации Smartcard
Это обновление позволяет настроить URI PKCS # 11 для выбора устройств проверки подлинности с помощью смарт-карты.
По умолчанию SSSD пытается автоматически определить устройство для проверки подлинности с помощью смарт-карты. Если подключено несколько устройств, SSSD выберет первое найденное, и вы не сможете выбрать конкретное устройство. Это может привести к сбоям.
Таким образом, теперь вы можете настроить новый p11_uri вариант для [pam] раздел sssd.conf Эта опция позволяет вам определить, какое устройство будет использоваться для аутентификации по смарт-карте.
Например, чтобы выбрать считыватель с идентификатором слота ‘2’, обнаруженным модулем OpenSC PKCS # 11, добавьте
к [pam] раздел sssd.conf
Посмотри пожалуйста man sssd-conf для деталей.
Identity Management — основы управления учетными записями
Сегодня мы начнем разговор о системах класса Identity Management. Как многие из вас знают, 1 июля закончился срок действия отсрочки вступления в силу федерального закона РФ от 27 июля 2006 года № 152-ФЗ «О персональных данных»
Соответственно, для управления персональными данными в ИТ крупные компании будут вынуждены внедрять специализированные системы класса IDM для управления информацией о пользователях своих корпоративных систем. Если раньше наблюдался некоторый дефицит квалифицированных кадров в этой области, то теперь этот дефицит примет катастрофические масштабы, так как гром грянул, и мужику положено начать креститься.
Дефицит кадров в этой специализированной области обусловлен тем, что специалист по IDM должен обладать сразу несколькими навыками в ИТ – он должен хорошо разбираться в устройстве различных систем информационной безопасности, иметь практический опыт системного администрирования, быть неплохим программистом для написания адаптеров и сценариев обработки данных, уметь описывать и ставить бизнес-процессы. И при этом он не должен беситься от огромного количества рутинной работы по выверке персональных данных. Могу практически со стопроцентной уверенностью утверждать, что таких людей в природе не существует. С этим фактом связана извечная головная боль сотрудников HR, которые вообще смутно себе представляют нашу специфику, а тут еще им приходится иметь дело с такой гремучей смесью несовместимых навыков.
Единственным выходом из ситуации является разделение работы минимум на двоих. Один может программировать коннекторы к системам безопасности, настраивать внутренние workflow, писать скрипты и заниматься развертываением. Второй должен работать с пользовательскими данными, описывать бизнес-процессы, заниматься документированием и продвижением идеи IDM в ИТ массы.
Спешу разочаровать коллег-программистов. В этом цикле статей акцент будет сделан на бизнес- и постановочную часть внедрения IDM, а также на практические приемы внедрения и работы с пользовательскими данными. Потому что толковых программистов у нас хоть и мало, но найти можно. А вот людей, понимающих зачем все это делается, можно пересчитать в Москве по пальцам.
Я искренне надеюсь, что после прочтения данного материала у коллег прибавится ясности по данному вопросу, и многие программисты или системные администраторы смогут перейти в лагерь бизнес-аналитиков по IDM, чтобы составить достойную конкуренцию тем немногим работающим в этой области «звездам».
Что такое Identity Management?
Identity – это личность. Все, что составляет информацию о реальном человеке, является Identity: его имя, пол, должность, год рождения, атрибуты его учетных записей в системах. В определенных сочетаниях информация о человеке является предметом защиты федеральных законов и должна управляться. Процессы и системы управления персональными данными называются Identity Management, или IDM.
Где хранится персональная информация о сотрудниках компании? Разумеется, в кадровой системе. А еще – в каталоге Active Directory, в карточках пользователей нескольких десятков прикладных систем, в данных почтовых программ, в системах управления клиентами, в биллинговых системах, в системах сервис-деск… Зачастую эта информация не согласованна. Один и тот же человек может быть прописан в десятке систем одновременно, и никто не даст гарантии, что он прописан в них одинаково и корректно.
Одна из основных задач IDM – создание единого и актуального каталога персональной информации как основы для дальнейшего развития процессов управления.
IDM, IAM, RM — WTF?
Учетные записи пользователя и их атрибуты (например, группы доступа) являются такой же частью персональной информации, как и почтовые адреса, имена и должности. Специалисты по Active Directory подтвердят, что это все хранится в системной базе данных сходным образом. Соответственно, логично было бы включить в рамки процесса IDM заодно и управление доступом к информационным системам (Access Management). Часто под IDM как раз и понимается Identity and Access Management (IAM), просто аббревиатура IDM людям нравится больше.
Результаты успешного внедрения IDM можно разделить на «статические» и «динамические». Первые – это результаты «что же стало?». А вторые «И как же это работает?»
Права (привилегии) пользователя в различных системах зависят только и исключительно от его служебных обязанностей. И чем разнообразнее его обязанности, тем сложнее определить принципы назначения этих привилегий.
В простейшем случае права пользователя определяются его должностью, и физическим расположением его рабочего места. Это характерно для массовых взаимозаменяемых должностей – разнообразных операторов, сотрудников центров обработки звонков, работников конвейерной линии и т.п.
Задача усложняется, когда в обязанности сотрудника входит дополнительная деятельность, не характерная для его коллег. Например, сотрудник отвечает за заказ канцтоваров на весь свой отдел. Для этого ему предоставляется доступ в некую систему, куда он заходит раз в квартал, нажимает там три кнопки и забывает о ней на следующие три месяца. И такие пользователи есть в каждом отделе. Подобную головную боль представляют также бухгалтеры крупных компаний, которые, как известно, часто специализируются в разных областях и используют разные системы, будучи при этом на одной должности.
Еще более сложный случай – когда в компании действуют внутренние проекты или иная нерегулярная деятельность, требующая временных группировок сотрудников по тем или иным признакам. Например, внедряется ERP система, и все участники рабочей группы получают временный доступ к тестовой площадке. Или в компании идет работа над новым шаблоном презентации, и ключевых сотрудников допустили на портал службы маркетинга для оценки дизайнерских макетов. Да мало ли что еще может быть! Дать необходимые полномочия в подобной ситуации еще полдела. Попробуйте правильно и вовремя их отозвать! В 90% компаний полномочия никогда у пользователей не отзываются. Давно работающие сотрудники постепенно обрастают доступами, словно корабли ракушками. Через два-три года никто толком не может сказать, откуда у них такое количество привилегий. Если сами учетные записи еще хоть как-то контролируются прикладными администраторами по количеству и предполагаемым владельцам, то в рамках одной учетной записи сам черт ногу сломит.
Чтобы разобраться во всем этом, как вы понимаете, нужно проделать серьезную работу. В ручном режиме управиться можно при небольшом количестве систем и железной дисциплине. Но если сущностей становится слишком много для обычного человека, приходится думать об автоматизации процесса и о применении элементов ролевого управления доступом (Role Management). RM – это сейчас крайне модное и популярное направление в сфере middleware. Для стороннего наблюдателя стоит оно немыслимых денег и непонятно чего делает. Системы этого класса предлагают наперебой ведущие гиганты софтостроения, такие как Oracle (он же Sun), IBM, Microsoft. Множество копий сломано в бессмысленных спорах о преимуществах той или иной платформы. По опыту могу сказать, что все системы будут одинаково бестолковыми, если мы не уделим должного внимания наведению порядка в бизнес-процессах.
Вообще говоря, механика работы этих систем меня интересует мало, так как успех внедрения заключается не в фирменном движке и не в используемом языке программирования, а в правильном формировании ролевых моделей и в точной настройке бизнес-правил. Качество же конкретной системы определяется удобством формирования ролевой модели и гибкостью в настройке бизнес-правил. Все ведущие производители стараются оптимизировать именно эти параметры своих разработок наряду с расширением количества готовых коннекторов и общим повышением надежности работы движка.
В случае внедрения IDM не нужно, как у нас принято, сразу же кидаться ставить софт в надежде на то, что телега вытянет за собой лошадь. Чуда, как обычно, не произойдет, а дров наломаете на годы вперед. Ведь системы IDM внедряются в самое «наше все» системных администраторов — в аутентификацию пользователей. Упавший IDM может парализовать работу всей компании. Криво настроенный движок приведет к тому, что прежний «геморрой» с прописыванием нового пользователя вручную покажется админам доброй сказкой. Стоит ли говорить, как все вокруг воспримут после этого вас и вашу систему.
Как пример могу привести забавный глюк в алгоритме разрешения конфликтов при формировании учеток однофамильцев, который приводил к автоматической генерации сразу сотни учетных записей. Представьте себе теперь восторг заказчика, который оплачивает лицензию за каждую учетную запись в купленной им системе. Только чудом удалось тогда замять скандал. Но ложки-то нашлись, а осадочек остался.
Российские реалии таковы, что даже в самых развитых и прогрессивных компаниях бардак в пользовательских привилегиях стоит неимоверный. Несмотря на периодическую зачистку и инвентаризацию учетных записей, привилегии пользователей никто не вычесывает мелким гребнем, особенно у высокопоставленных сотрудников. Также зачастую нет порядка со служебными, гостевыми и административными учетными записями, так как они не связаны с конкретными людьми и вообще непонятно что с ними делать.
Получается, что сотрудники отделов информационной безопасности сидят на мине замедленного действия, так как они не знают ответа на элементарный вопрос аудитора: «Кто и на каком основании имеет доступ к той или иной системе?» А то, что с этим вопросом им придется встречаться все чаще и чаще, есть установленный наукой факт. Ответить же на него в любой момент времени (а не только после месяца ручной выверки привилегий) помогут системы класса IDM с дополнительной функциональностью ролевого управления доступом.
В следующих публикациях мы затронем вопросы организации проекта внедрения IDM, а также различные практические подходы к созданию ролевых моделей.