Comments 5
Если возможно, осветите основные вехи «типового» проекта на 3 месяца — что есть на входе, что будете делать и что получит заказчик на выходе?
Со своей стороны скажу, что 3 месяца на проект — это очень оптимистично. Я бы назвал скорее 6 месяцев как среднее. Т.е. внедрить систему за 3 месяца как продукт поставить/настроить это да, но внедрить со всеми процессами это фантастика. Необходимо перевести процессы заказчика на IDM, учитывая российские реалии это не так быстро.
Не раскрыта тема подключения систем к которым нет коннекторов из коробки, как с ними?
Насколько гибкие настройки коннекторов из коробки? Например если целевая система — БД, то пользователи могут быть от схемы, храниться в сложной структуре таблиц, или управление пользователями выполняется посредством хранимых процедур. Какие возможности по тонкой настройке коннекторов есть у внедренцев?
С какими решениями ITSM из коробки позволяет взаимодействовать ваше решение?
Про PKI — возможно ошибка, но судя по схеме у вас из кадровой службы информация о сотрудниках выгружается в УЦ КриптоПро.
Про PKI — чем отличаются «встроеные механизмы» в вашей системе от коннекторов которые могут реализовать этот функционал у других вендоров (через API КриптоПро). Поскольку УЦ является внешней системой по отношению к «КУБу», то не очень понятно в чем отличие от других вендоров в техническом плане. Или подразумевается, что из коробки умеет работать с УЦ Криптопро? Тогда да, факт, из коробки остальные не умеют.
Проводите ли техно-демо для заказчиков и интеграторов? Или возможно есть демостенд который можно потрогать руками?
Со своей стороны скажу, что 3 месяца на проект — это очень оптимистично. Я бы назвал скорее 6 месяцев как среднее. Т.е. внедрить систему за 3 месяца как продукт поставить/настроить это да, но внедрить со всеми процессами это фантастика. Необходимо перевести процессы заказчика на IDM, учитывая российские реалии это не так быстро.
Не раскрыта тема подключения систем к которым нет коннекторов из коробки, как с ними?
Насколько гибкие настройки коннекторов из коробки? Например если целевая система — БД, то пользователи могут быть от схемы, храниться в сложной структуре таблиц, или управление пользователями выполняется посредством хранимых процедур. Какие возможности по тонкой настройке коннекторов есть у внедренцев?
С какими решениями ITSM из коробки позволяет взаимодействовать ваше решение?
Про PKI — возможно ошибка, но судя по схеме у вас из кадровой службы информация о сотрудниках выгружается в УЦ КриптоПро.
Про PKI — чем отличаются «встроеные механизмы» в вашей системе от коннекторов которые могут реализовать этот функционал у других вендоров (через API КриптоПро). Поскольку УЦ является внешней системой по отношению к «КУБу», то не очень понятно в чем отличие от других вендоров в техническом плане. Или подразумевается, что из коробки умеет работать с УЦ Криптопро? Тогда да, факт, из коробки остальные не умеют.
Проводите ли техно-демо для заказчиков и интеграторов? Или возможно есть демостенд который можно потрогать руками?
Добрый день! Спасибо большое за вопросы, постараюсь как можно более развернуто на них ответить:
По поводу 3 месяцев — это конечно, идеализированная ситуация, когда заказчик представляет, что ему нужно и как это примерно реализовать.
1. Основные допущения при реализации проекта за 3 месяца следующие:
— мы полагаем что групповой доступ используется на 70-80% в целевых системах, данные группы документированы
— у заказчика в качестве подключаемых систем используются распространенные системы: контроллер домена, файловый сервер, 1С, «самописная система», с разделением полномочий через БД, почтовый сервер на базе Exchange
— в компании внедрены «сущности» владельцев ресурсов
— используется процедура согласования, например, с помощью почты
2. Интегратор внедряет систему следующими этапами:
— проведение внедрения на «слепках боевых систем»
  — интеграция с системой кадрового учета, настройка модуля для периодической выгрузки информации (от 1 минуты до 24 часов, по желанию заказчика) и импорт орг-штатной структуры и сотрудников в IDM
  — установка выносных частей коннекторов на серверы ИС, «вытягивание» сущностей ИС, такие как учетные записи, группы, роли, профили, права доступа, ресурсов. Фактически, производится инвентаризация существующих прав доступа. Для систем, к которым нет коннекторов, интегратор разрабатывает коннекторы с помощью SDK.
  — автоматическое связывание учетных записей и сотрудников (по e-mail, табельному номеру, фамилии, названию учетки по правилам транслитерации)
  — оптимизация ролевой матрицы доступа, настройка должностного доступа, а так же настройка ответственностей для построения процесса согласования
— перенос настроек на «реальные боевые системы», развертывание IDM
при таком подходе и допущениях, что заказчик предоставляет маршруты согласования в каждом случае, а так же «быстрого» процесса выделения должностных полномочий и формирования ролей, проект по внедрению занимает 3 месяца.
Большинство людей, знакомых с IDM, ассоциируют его с Oracle IM, как наиболее популярного представителя класса. Основное отличие КУБ от Oracle — в процессе внедрения происходит настройка системы из администраторского интерфейса, а не программирование. Я думаю, большинство интеграторов, внедрявших Oracle, со всей ответственностью скажут, что коннекторы необходимо «допиливать» или переписывать заново.
Подключение систем к которым нет коннекторов «из коробки».
Разработка коннекторов может осуществляться компанией «Трастверс», как вендором, интегратором в рамках проекта или заказчиком, с помощью SDK. Сроки разработки коннекторов для систем, в среднем — 20-30 рабочих дней
Вместе с поставкой IDM КУБ идет комплект SDK, состоящий из программы PlatformEditor, с помощью которой закладывается логика работы коннектора, сущности, которыми он может управлять, а так же Java и Com Framework для реализации взаимодействий с целевой системой через ее API, так же в поставку входит документация по созданию коннекторов и примеры.
Если говорить о типовых коннекторах к базам данных, как хранилищам учетных записей и их привилегий, то в рамках проекта производится быстрая настройка под конкретное приложение.
Наибольшую сложность вызывают «сложные коннекторы» (где управление производится не на уровне членства учеток в группах, а на уровне гранулированных прав, особенно если система использует атрибутную модель доступа) для автоматизированных банковских систем.
Хочу заметить, что умение управлять доступом на уровне прав доступа присуще, насколько мне известно, только КУБ.
«Из коробки» КУБ может работать с HP OV, HP Service Manager, Инфраменеджер
Про PKI — кадровая система предоставляет информацию о сотруднике, которому надо выдать сертификат.
1. При приеме нового сотрудника на работу происходит автоматическая регистрация этого сотрудника в «КриптоПро УЦ» на основании информации, полученной из системы кадрового учета.
2. Сотрудник создает заявку через web-портал системы «КУБ».
3. На основании действующих политик происходит согласование созданной заявки всеми заинтересованными лицами.
4. После того, как заявка согласована, «КУБ» производит автоматическое выполнение необходимых действий на сервере «КриптоПро УЦ». В результате происходит создание запроса на генерацию ключей и выпуск сертификатов для пользователя.
5. Информация о результатах отработки запроса поступает в «КУБ», и пользователь получает соответствующее уведомление по электронной почте.
6. После получения уведомления пользователь обращается в УЦ и получает сгенерированные ключи и сертификат, которые могут быть установлены на компьютер пользователя или записаны на токен или смарт-карту.
КУБ может автоматически генерировать запросы на выпуск сертификатов, при постановке на должность или запросе роли в целевую систему, где необходим сертификат, а так же обеспечивать транспорт сертификатов.
По поводу техно-демо и предоставления демостенда — такая возможность есть, за дополнительной информацией можно обращаться ко мне, ниже контактная информация
Алексей Павлов, presale manager ООО «Трастверс» ГК «Информзащита»
a.pavlov@trustverse.ru
По поводу 3 месяцев — это конечно, идеализированная ситуация, когда заказчик представляет, что ему нужно и как это примерно реализовать.
1. Основные допущения при реализации проекта за 3 месяца следующие:
— мы полагаем что групповой доступ используется на 70-80% в целевых системах, данные группы документированы
— у заказчика в качестве подключаемых систем используются распространенные системы: контроллер домена, файловый сервер, 1С, «самописная система», с разделением полномочий через БД, почтовый сервер на базе Exchange
— в компании внедрены «сущности» владельцев ресурсов
— используется процедура согласования, например, с помощью почты
2. Интегратор внедряет систему следующими этапами:
— проведение внедрения на «слепках боевых систем»
  — интеграция с системой кадрового учета, настройка модуля для периодической выгрузки информации (от 1 минуты до 24 часов, по желанию заказчика) и импорт орг-штатной структуры и сотрудников в IDM
  — установка выносных частей коннекторов на серверы ИС, «вытягивание» сущностей ИС, такие как учетные записи, группы, роли, профили, права доступа, ресурсов. Фактически, производится инвентаризация существующих прав доступа. Для систем, к которым нет коннекторов, интегратор разрабатывает коннекторы с помощью SDK.
  — автоматическое связывание учетных записей и сотрудников (по e-mail, табельному номеру, фамилии, названию учетки по правилам транслитерации)
  — оптимизация ролевой матрицы доступа, настройка должностного доступа, а так же настройка ответственностей для построения процесса согласования
— перенос настроек на «реальные боевые системы», развертывание IDM
при таком подходе и допущениях, что заказчик предоставляет маршруты согласования в каждом случае, а так же «быстрого» процесса выделения должностных полномочий и формирования ролей, проект по внедрению занимает 3 месяца.
Большинство людей, знакомых с IDM, ассоциируют его с Oracle IM, как наиболее популярного представителя класса. Основное отличие КУБ от Oracle — в процессе внедрения происходит настройка системы из администраторского интерфейса, а не программирование. Я думаю, большинство интеграторов, внедрявших Oracle, со всей ответственностью скажут, что коннекторы необходимо «допиливать» или переписывать заново.
Подключение систем к которым нет коннекторов «из коробки».
Разработка коннекторов может осуществляться компанией «Трастверс», как вендором, интегратором в рамках проекта или заказчиком, с помощью SDK. Сроки разработки коннекторов для систем, в среднем — 20-30 рабочих дней
Вместе с поставкой IDM КУБ идет комплект SDK, состоящий из программы PlatformEditor, с помощью которой закладывается логика работы коннектора, сущности, которыми он может управлять, а так же Java и Com Framework для реализации взаимодействий с целевой системой через ее API, так же в поставку входит документация по созданию коннекторов и примеры.
Если говорить о типовых коннекторах к базам данных, как хранилищам учетных записей и их привилегий, то в рамках проекта производится быстрая настройка под конкретное приложение.
Наибольшую сложность вызывают «сложные коннекторы» (где управление производится не на уровне членства учеток в группах, а на уровне гранулированных прав, особенно если система использует атрибутную модель доступа) для автоматизированных банковских систем.
Хочу заметить, что умение управлять доступом на уровне прав доступа присуще, насколько мне известно, только КУБ.
«Из коробки» КУБ может работать с HP OV, HP Service Manager, Инфраменеджер
Про PKI — кадровая система предоставляет информацию о сотруднике, которому надо выдать сертификат.
1. При приеме нового сотрудника на работу происходит автоматическая регистрация этого сотрудника в «КриптоПро УЦ» на основании информации, полученной из системы кадрового учета.
2. Сотрудник создает заявку через web-портал системы «КУБ».
3. На основании действующих политик происходит согласование созданной заявки всеми заинтересованными лицами.
4. После того, как заявка согласована, «КУБ» производит автоматическое выполнение необходимых действий на сервере «КриптоПро УЦ». В результате происходит создание запроса на генерацию ключей и выпуск сертификатов для пользователя.
5. Информация о результатах отработки запроса поступает в «КУБ», и пользователь получает соответствующее уведомление по электронной почте.
6. После получения уведомления пользователь обращается в УЦ и получает сгенерированные ключи и сертификат, которые могут быть установлены на компьютер пользователя или записаны на токен или смарт-карту.
КУБ может автоматически генерировать запросы на выпуск сертификатов, при постановке на должность или запросе роли в целевую систему, где необходим сертификат, а так же обеспечивать транспорт сертификатов.
По поводу техно-демо и предоставления демостенда — такая возможность есть, за дополнительной информацией можно обращаться ко мне, ниже контактная информация
Алексей Павлов, presale manager ООО «Трастверс» ГК «Информзащита»
a.pavlov@trustverse.ru
Алексей, спасибо за ответы.
Не соглашусь, пожалуй, с 2мя вещами:
1) Если говорить про OIM в вашем примере — то доработка и переработка коннекторов обычно используется по незнанию или при действительных проблемах с производительностью, а проблемы с производительностью встречаются при 20к+ учеток. В остальном стандартного функционала коннекторов даже у Oracle хватает для большинства задач. Про другие решения как Quest/NetIQ/Sailpoint — аналогично и даже лучше. + Разработка коннектора к «нестандартной системе» в среднем 10-15 рабочих дней для этих решений.
2) Большинство вендоров и так рекомендуют использовать конфигурацию, а не разработку, это в старых версиях приходилось все разрабатывать. Многие сейчас продолжают делать это по привычке.
К сожалению, такие простые вещи как: транслитерация, формирование логинов, создание паролей — как правило в решении «из коробки» не предусмотрено, и тут приходится прибегнуть к разработке. Как кстати обстоят с этим дела в КУБе?
Опять же, разработка разработке рознь. В том же Oracle набор стандартных методов, уже реализованных в системе, позволяет выполнять многие операции с данными без написания своего кода на Java.
А, например, в Sailpoint все можно сделать из веб-интерфейса. У Quest есть Design и Configuration консоли, которые позволяют как использовать существующие «кубики» с логикой, так и разрабатывать свои (без использования сторонних IDE).
Во всех решениях есть плюсы и минусы. На данный момент с системой КУБ мне сталкиваться не доводилось, поэтому я с удовольствием с ней ознакомлюсь, если такая возможность действительно есть.
Отписал вам на почту.
Не соглашусь, пожалуй, с 2мя вещами:
1) Если говорить про OIM в вашем примере — то доработка и переработка коннекторов обычно используется по незнанию или при действительных проблемах с производительностью, а проблемы с производительностью встречаются при 20к+ учеток. В остальном стандартного функционала коннекторов даже у Oracle хватает для большинства задач. Про другие решения как Quest/NetIQ/Sailpoint — аналогично и даже лучше. + Разработка коннектора к «нестандартной системе» в среднем 10-15 рабочих дней для этих решений.
2) Большинство вендоров и так рекомендуют использовать конфигурацию, а не разработку, это в старых версиях приходилось все разрабатывать. Многие сейчас продолжают делать это по привычке.
К сожалению, такие простые вещи как: транслитерация, формирование логинов, создание паролей — как правило в решении «из коробки» не предусмотрено, и тут приходится прибегнуть к разработке. Как кстати обстоят с этим дела в КУБе?
Опять же, разработка разработке рознь. В том же Oracle набор стандартных методов, уже реализованных в системе, позволяет выполнять многие операции с данными без написания своего кода на Java.
А, например, в Sailpoint все можно сделать из веб-интерфейса. У Quest есть Design и Configuration консоли, которые позволяют как использовать существующие «кубики» с логикой, так и разрабатывать свои (без использования сторонних IDE).
Во всех решениях есть плюсы и минусы. На данный момент с системой КУБ мне сталкиваться не доводилось, поэтому я с удовольствием с ней ознакомлюсь, если такая возможность действительно есть.
Отписал вам на почту.
Добрый день! IDM — это интересное решение для крупного бизнеса, без сомнения оно выгодно экономически. Не подскажете, как внедрение IDM отразится на информационной безопасности предприятия и на какие риски воздействует?
Добрый день! Спасибо за Ваш вопрос.
В последнее время, в силу роста количества информационных систем и сложности ИТ-инфраструктуры, IDM-решения широко распространяются не только в крупном бизнесе, но и в компаниях среднего и даже малого бизнеса. Для статистики в США 3 из 5 компаний свыше 500 человек используют IDM. Поэтому мы создали продукт для среднего бизнеса, который отвечает требованиям данного сектора экономики по стоимости и значительно проще во внедрении.
Что касается информационной безопасности организации, то внедрение IDM отразится, в первую очередь, на уменьшении рисков утечки информации и ликвидации возможности использования «мертвых душ». IDM является платформой по консолидации информации о привилегиях пользователей, разделяемых ресурсах и учетных записях.
Две наиболее популярные проблемы информационной безопасности, решаемые IDM:
— Накопление привилегий сотрудниками в процессе работы, что ведет к повышению рисков утечки информации. Заявки на доступ пользователей создаются часто (в среднем дважды в год для каждого сотрудника предприятия), особенно в проектных отделах. При этом изъятие привилегий производится администраторами значительно реже. Сотрудник получает бессрочный доступ к ресурсу и информации, хранимой в нем. IDM-решение позволяет создавать заявки на время и автоматически изымать доступ у сотрудника по истечении срока. Так же существует возможность периодической ресертификации доступа сотрудников ответственным лицом (например, руководителем отдела).
— Хищение информации посредством «мертвых душ». При наличии большого парка информационных систем отследить удаление учетных записей при увольнении сотрудников достаточно сложно, не говоря про изъятие прав к разделяемым каталогам, например. Это значительно повышает риски использования учетных записей уволенными сотрудниками. IDM-решение исключает данную возможность, так как получает информацию о сотруднике автоматически из кадровой системы. При приеме на работу сотрудника учетные записи создаются, при увольнении — блокируются или удаляются (по выбору)
За дополнительной информацией, в том числе калькулятором ROI, Вы можете обратится ко мне.
Алексей Павлов,
ООО «Трастверс»
+7 (495) 980-2345, доб. 732
+7 (916) 178-98-90
a.pavlov@trustverse.ru
В последнее время, в силу роста количества информационных систем и сложности ИТ-инфраструктуры, IDM-решения широко распространяются не только в крупном бизнесе, но и в компаниях среднего и даже малого бизнеса. Для статистики в США 3 из 5 компаний свыше 500 человек используют IDM. Поэтому мы создали продукт для среднего бизнеса, который отвечает требованиям данного сектора экономики по стоимости и значительно проще во внедрении.
Что касается информационной безопасности организации, то внедрение IDM отразится, в первую очередь, на уменьшении рисков утечки информации и ликвидации возможности использования «мертвых душ». IDM является платформой по консолидации информации о привилегиях пользователей, разделяемых ресурсах и учетных записях.
Две наиболее популярные проблемы информационной безопасности, решаемые IDM:
— Накопление привилегий сотрудниками в процессе работы, что ведет к повышению рисков утечки информации. Заявки на доступ пользователей создаются часто (в среднем дважды в год для каждого сотрудника предприятия), особенно в проектных отделах. При этом изъятие привилегий производится администраторами значительно реже. Сотрудник получает бессрочный доступ к ресурсу и информации, хранимой в нем. IDM-решение позволяет создавать заявки на время и автоматически изымать доступ у сотрудника по истечении срока. Так же существует возможность периодической ресертификации доступа сотрудников ответственным лицом (например, руководителем отдела).
— Хищение информации посредством «мертвых душ». При наличии большого парка информационных систем отследить удаление учетных записей при увольнении сотрудников достаточно сложно, не говоря про изъятие прав к разделяемым каталогам, например. Это значительно повышает риски использования учетных записей уволенными сотрудниками. IDM-решение исключает данную возможность, так как получает информацию о сотруднике автоматически из кадровой системы. При приеме на работу сотрудника учетные записи создаются, при увольнении — блокируются или удаляются (по выбору)
За дополнительной информацией, в том числе калькулятором ROI, Вы можете обратится ко мне.
Алексей Павлов,
ООО «Трастверс»
+7 (495) 980-2345, доб. 732
+7 (916) 178-98-90
a.pavlov@trustverse.ru
Sign up to leave a comment.
Принципы успешного внедрения IDM. Бизнес-кейсы