VII Уральский форум
Информационная безопасность банков
ТЕМАТИЧЕСКОЕ ЗАСЕДАНИЕ № 4
Обеспечение безопасности банковских приложений
на различных этапах жизненного цикла
Качалин Алексей Игоревич, заместитель генерального директора, ГК «Инфотекс»
Источник: http://ural.ib-bank.ru/materials_2015
Лекция по безопасной разработке приложений защиты информации в РФ. Читается на 4 курсе ФРТК МФТИ. Рассмотрен процесс создания криптографических и технических средств защиты информации.
Хакеры, скандальные утечки данных, целые отделы, занимающиеся вопросами ИБ в компании - все это больше из области теле-новостей про фирмы-гиганты. Но, "плачут не только богатые". У обычных небольших организаций, и у обычных людей - вопросы ИБ занимают все более важное место.
В докладе будут даны рекомендации по ИБ для самых обычных организаций - небольших фирм от 10 сотрудников. Как хоть немного защититься в этом сложном информационном мире. Поговорим об ИБ - без фанатизма, без сертификации ИСО 27001 и без консультантов от "большой четверки".
Автоматизация выполнения задач в проектах Business Continuity Management (BCM...КРОК
Вебинар «Бизнес в режиме нон-стоп: автоматизация DRP и BCP процессов» http://www.croc.ru/action/detail/20808/
Презентация Сергея Верчёнова, ведущего инженера департамента вычислительных систем КРОК
Исследование безопасности создаваемых информационных систем и разрабатываемых приложений становится распространенной практикой. Безопасники получили наконец заслуженное признание и «включены в цикл» разработки, их вписывают в нормативку, создают базы знаний для хранения результатов исследований. Чего ждут разработчики и владельцы информационных систем от исследователей? Поговорим о задачах, которые предстоит решать, и о качестве исследований, проводимых на регулярной основе.
VII Уральский форум
Информационная безопасность банков
ТЕМАТИЧЕСКОЕ ЗАСЕДАНИЕ № 4
Обеспечение безопасности банковских приложений
на различных этапах жизненного цикла
Качалин Алексей Игоревич, заместитель генерального директора, ГК «Инфотекс»
Источник: http://ural.ib-bank.ru/materials_2015
Лекция по безопасной разработке приложений защиты информации в РФ. Читается на 4 курсе ФРТК МФТИ. Рассмотрен процесс создания криптографических и технических средств защиты информации.
Хакеры, скандальные утечки данных, целые отделы, занимающиеся вопросами ИБ в компании - все это больше из области теле-новостей про фирмы-гиганты. Но, "плачут не только богатые". У обычных небольших организаций, и у обычных людей - вопросы ИБ занимают все более важное место.
В докладе будут даны рекомендации по ИБ для самых обычных организаций - небольших фирм от 10 сотрудников. Как хоть немного защититься в этом сложном информационном мире. Поговорим об ИБ - без фанатизма, без сертификации ИСО 27001 и без консультантов от "большой четверки".
Автоматизация выполнения задач в проектах Business Continuity Management (BCM...КРОК
Вебинар «Бизнес в режиме нон-стоп: автоматизация DRP и BCP процессов» http://www.croc.ru/action/detail/20808/
Презентация Сергея Верчёнова, ведущего инженера департамента вычислительных систем КРОК
Исследование безопасности создаваемых информационных систем и разрабатываемых приложений становится распространенной практикой. Безопасники получили наконец заслуженное признание и «включены в цикл» разработки, их вписывают в нормативку, создают базы знаний для хранения результатов исследований. Чего ждут разработчики и владельцы информационных систем от исследователей? Поговорим о задачах, которые предстоит решать, и о качестве исследований, проводимых на регулярной основе.
Система управления учетными записями (IDM). Информационная безопасность. Softline
Информационная безопасность. Система управления учетными записями.
IDM – ЕДИНЫЙ ЦЕНТР КОМПЕТЕНЦИЙ В ЧАСТИ
ПРЕДОСТАВЛЕНИЯ ДОСТУПА К РЕСУРСАМ
И СИСТЕМАМ.
Введение в системы управления идентификационными данными и доступом (IAM)КРОК
Семинар Центра компетенции «Управление идентификационными данными и доступом к информации».
Подробнее о мероприятии http://www.croc.ru/action/detail/1639/
Презентация Дениса Мурунова, эксперта группы системных инженеров компании КРОК
SAP Identity Management helps companies centrally manage their user accounts (identities) in a complex system landscape, including both SAP and non-SAP systems. More information: http://scn.sap.com/community/idm.
Описание нескольких кейсов, в которых возможно продемонстрировать обоснование финансовых инвестиций в ИБ на примере типичных банковских процессов - кредитование, повышение продуктивности, удержание персонала, private banking, борьба с криптолокерами, отражение DDoS и т.п.
#itSMFru2014 - Патрик Болджер в секции Мирный КосмосCleverics
Мост в космосе: как правильно использовать SLM
Управление уровнем услуг (SLM) позволяет связать ИТ и бизнес. Связь совершенно необходимая, и тем не менее этого процесса нет более чем в половине внутренних ИТ-служб. В итоге задачи управления ожиданиями, предоставления услуг должного качества за приемлемые деньги решаются нестабильно, бессистемно и не слишком успешно. Реализация процесса SLM может стать основой для существенного улучшения ИТ-услуг в глазах бизнеса и изменить к лучшему отношения Ит-службы с внутренними заказчиками. Патрик расскажет о том, как наладить диалог о качестве услуг, избежать непродуктивного взаимодействия и сосредоточить усилия ИТ-службы на формировании ценности для бизнеса
Problems of implementation of end-to-end business processes in distributed architectures (including micro-service). Theses - "The widespread introduction of architecture based on microservices made us take a critical look at the basic tools and dogmas of enterprise Architecture. The situation was aggravated by a significant decrease in the "entry threshold" to the new tool stack, which flooded the industry with developers and designers with incomplete and sometimes eclectic ideas about the theoretical basis for building complex distributed information systems. They prefer to experiment rather than "theorize", believing that since absolute knowledge does not exist, then let the market or the consumer evaluate the ready-made solution "more honestly" than listening to the criticism of technologists and fellow workers. This led to the emergence of projects in the style of "Fast fail", which in the developed theoretical base
Презентация показывает значимость процесса Инициирования Проекта (Project Initiation), а также его основного артефакта - Устава Проекта (Project Charter). Устав Проекта описывает Правила взаимодействия с заказчиком и решает многие проблемы на ранних стадиях. Но к сожалению Устав не всегда делают качественно, или вообще не делают, что и приводит ко множеству разочарований, взаимных претензий и т.п.
Как сделать командные встречи более эффективными? У меня нет одного волшебного рецепта для решения этого комплексного вопроса, но я буду рада поделится с вами набором техник с примерами, которые помогут вам:
Быть лучше подготовленным к встречам;
Фокусировать участников на теме обсуждения;
Уменьшать количество разговоров не относящихся к основной теме дискуссии;
Научить участников быстро принимать решения;
Митигировать конфликтные ситуации;
Описывать механизм реализации договоренностей, принятых на встрече.
Из моего доклады вы узнаете, что такое фасилитации и кто такой фасилитатор, а так же изучите ряд фасилитационных техник, которые применяются для работы с определенными проблемными ситуациями.
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]Alex V. Petrov
Приступая к реализации проектов разработки информационных систем, заказчик и исполнитель, как правило, в большей степени нацелены на подготовку технического задания. Однако, в действительности техническое задание — это финальный документ, в подготовке которого участвуют представители аналитического блока команды. Создание технического задания должно предваряться формированием ряда не менее важных документов, относящихся к более ранним этапам жизненного цикла системы. Одним из этих документов являются «Бизнес-требования» (англ. Business Requirements Document, BRD).
Ключевая миссия этого документа — исчерпывающее определение рамок, или объема, проекта. Какие объемы проекта существуют, как определяются и из чего складываются? Включать ли в BRD перечень заинтересованных сторон и предварительно идентифицированные риски проекта? Какую еще информацию следует включать в BRD, а какую — нет? Как провести границу между BRD и документом «Функциональные требования» (англ. Functional Requirements Document, FRD)? Как взаимодействовать с заказчиком для эффективного определения бизнес-требований? Ответы на эти и другие вопросы — в презентации с выступления в Парке высоких технологий (Минск, 03 декабря 2015 г.).встрече
Все нормально, падаем! / Дмитрий Смоляров (Стройгазконсалтинг)Ontico
РИТ++ 2017, Web-scale IT Сonference
Зал Владивосток, 6 июня, 12:00
Тезисы:
http://webscaleconf.ru/2017/abstracts/2743.html
Для кого-то Agile - рутина со своим местом в системах управления. Для кого-то - модный тренд, который теперь во что бы то ни стало надо применить, даже если в этом нет необходимости.
Мы - группа компаний с традиционным производственным укладом, со штатом в более 28 тысяч человек и парком техники более 14 тысяч единиц. Проблема таких компаний в том, что несмотря на стек перспективных начинаний, как только настает момент практической реализации, все затухает, сталкиваясь с инерционностью, непониманием необходимости что-то менять, культурой организации. Очевидно, что здесь все и всегда шло по водопаду и все инициативы, в том числе инновации в IT проходили долго, теряя темп и актуальность.
...
Talk on Kaspersky lab's CoLaboratory: Industrial Cybersecurity Meetup #5 with @HeirhabarovT about several ATT&CK practical use cases.
Video (in Russian): https://www.youtube.com/watch?v=ulUF9Sw2T7s&t=3078
Many thanks to Teymur for great tech dive
Reducing cyber risks in the era of digital transformationSergey Soldatov
The session record is available here: https://www.youtube.com/watch?v=5-CoJNjtAmY
Link to all sessions from Sberbank ICC: https://icc.moscow/translyatsii.html
PHDays '14 Cracking java pseudo random sequences by egorov & soldatovSergey Soldatov
This presentation was delivered at Positive Hack Days '14 in Moscow along with the following demos available on Youtube:
Demo#1: http://www.youtube.com/watch?v=mdOfZMsj4hA
Demo#2: http://www.youtube.com/watch?v=BwXhpjiCTyA
Demo#3: http://www.youtube.com/watch?v=B3EkrmNWeJs
Demo#4: http://www.youtube.com/watch?v=--ZuBUc2F2Y
1. IDM – это непросто
Как можно решать эту задачу, о чем не
надо забывать
2. Преамбула
• Не претендую на истину, возможны альтернативы
• Мое личное мнение
• Буду пытаться обосновывать
• Надеюсь, будет полезно…
…ну, по крайней мере, смотивирует задуматься
CISO Forum 2015 2
4. Общие напутствия
• Ищите бизнес-цели, которую можно выразить в ₽
• Сокращение времени простоя новых сотрудников, сокращение времени
предоставления доступа, сокращение трудоемкости(==₽) присвоения,
сокращение ошибок присвоения, ….
• Определите заинтересованных лиц
• ИТ, ИБ, ДВК, HR, …
• Не нужен «функционал впрок»
• Тяжело угадать будущее, усилия на синхронизацию понимания, трудно
показать выгоду
• Работайте быстро
• Однако за время пути собака могла подрасти! (С. Маршак)
CISO Forum 2015 4
5. Бизнес-обоснования (идеи)
• Сокращение стоимости Контроля доступа: ~0,5млн заявок в год *
30мин. совок. трудоемкость * ~100т.р.мес стоимость
исполнителя = ₽156,25 млн
• Простой корп. бизнес-процессов: ~5 рд для при приеме (в год
приняли ~300 работников со средней стоимостью ~100т.р. =
₽7млн.), ~3рд – изменение доступа
• Накладные: расходные материалы копировальнойпечатной
техники, перегрузка систем общего назначения (почта, сетевые
папки), курьерская служба, ….
• Риски ИБ (поздний отъем доступа уволенных, «человеческий
фактор» при исполнении заявок, история присвоения)
CISO Forum 2015 5
6. Функциональная и географическая этапность
CISO Forum 2015
6
География
Функционал
Центр Ключевые Остальные
Первостепенный
функционал
Второстепенный
функционал
Остальной
функционал
I II
III
III
IV
IV
V
I. Внедрение функционала первого приоритета
в Центре компетенции.
II. Тираж функционала первого приоритета на
ключевые регионыДОподразделения (СП).
III. Внедрение функционала второго приоритета
там где, внедрен первичный. В остальных СП –
внедрение функционала первого приоритета.
IV. В центре – внедрение остального
функционала. В остальных СП – внедрение
функционала второго приоритета.
V. Внедрение остального функционала во всех
оставшихся СП.
«Первостепенный функционал»:
то, что вас подвигло заняться внедрением;
те самые 20%, дающие 80% эффекта;
то, что можно сделать относительно быстро
(quick win)
7. Выбор с полки
• Опросите всех заинтересованных => Критерии выбора (SMART!)
• Оцените вклад критерия в достижение целей (₽) => Вес по каждому
• Формализуйте оценку по каждому критерию => снизим субъективизм
и «интерференцию»
• Стендированиепилотированиереференс => из теории в практику
• Открытая формальная ПиМИ => известно что проверяют, как
проверяют и как оценивают (просто сэкономите время)
• Оценка большой группой экспертов => компенсация однобокости
CISO Forum 2015 7
8. Импортозамещение….
• Дополнительная перспектива – «срочность»
• Смотрите команду: их девелоперский потенциал, организацию
разработки, план ближайших релизов, степень понимания задач
• Архитектура с т.з. функционального расширения (API, уровни
абстракции, модульность, стандартизация компонент,
конфигурируемость...)
• СУБД, ОС – сервисы IDM => рекомендация производителя
• Внутренние процессы разработки и тестирования: виды
тестирования, продуктовая безопасность…
• Степень «рыночности» - небольшая защита от эксклюзивности
CISO Forum 2015 8
9. «Каша из топора»
CISO Forum 2015 9
• Лицензия на готовый
• Проект – внедрение, интеграция; наша только конфигурация
• Функциональная этапность совпадает с планом релизов производителя
• Партнерство: нам – продукт, производителю – слава + план развития + площадка
обкатки
• Заказная разработка
• Проект – разработка под ТТ; результат полностью наш.
• Функциональная этапность – наша.
• Партнерство только на этапе проекта, дальнейшее развитие – наше.
• Нечто среднее – Каша из топора
• Мы платим за лицензии и инвестируем в продукт вендора
• Мы неявно инвестируем ресурсы своей проектной команды
• Результат – заказная разработка со всеми последствиями
Почитать: http://reply-to-all.blogspot.ru/2010/04/blog-post.html
11. Синхронизуемся по терминологии
• Мы управляем доступом к Ресурсам
• Ресурсы размещаются в Системе
• Техническая роль – совокупность
технических настроек прав и правил
доступа к ресурсам, реализуемая ИС
• Бизнес-роль – совокупность технических и
бизнес-ролей, отражающая к-либо роль в
бизнес-процессе Компании
• SOD-конфликт – небезопасное совмещение
CISO Forum 2015 11
Техническая роль 1
Техническая роль 2
Техническая роль 3
Бизнес роль 1
Бизнес роль 2
Бизнес
роль
ИР1
ИР2 ИС
• Функциональная роль – роль в самом IDM (согласующий, например)
• Ресертификация (по «кнопке», по расписанию, на основании «риска») –
повторная проверка присвоения на актуальностьбезопасностьчто угодно
12. Следствия (для холдингов из множества ЮЛ)
• Техническая роль привязана к ИС (это то, что может быть присвоено
средствами ИС внутри ИС), ИС принадлежит Предприятию.
• Бизнес-роль является отражением бизнес-процесса, может быть в
рамках нескольких предприятий => может включать технические
и бизнес-роли из разных предприятий. Владельцем такой бизнес
роли должен быть ответственный за бизнес-процесс (например,
руководитель БНБФ в ЦА).
• Линейный руководитель – работник (руководитель)
подразделения Пользователя согласно оргструктуре.
• Линейный руководитель и Владелец роли (технической или
бизнес-) не обязательно работают на одном предприятии
CISO Forum 2015 12
13. Основные действующие лица
CISO Forum 2015 13
Линейный
руководитель
«Владелец»
Технической роли
«Владелец» Бизнес-
роли
Отвечает за
Эффективное
обеспечение БП
ресурсами его
подразделения
Правильное и
эффективное
использование его ИР
Правильное исполнение
своей роли участником
БП с учетом его
технологической
оснащенности
Управляет Людьми
Технологическим
обеспечением
Бизнес-процессом или
его частью
Контролирует
Свои
производственные
ресурсы
Пользование
технологическим
обеспечением
Обеспечение БП
людскими и
технологическими
ресурсами
14. Дополнительные действующие лица
CISO Forum 2015 14
Безопасность Внутренний контроль
Информационные
технологии
Подтверждает соблюдение
требований корп. политик.
Обеспечивает расследование
и оперативное реагирование
на инциденты
Отвечает за SOD-конфликты:
ведет [в IDM] их учет и
конфигурацию. При
возникновении SOD-конфликтов
в процессах КД – расследование
их и принятие решения о
предоставлении или отклонении
доступа.
Подтверждает возможность
исполнения заявки (для
заявок, исполняемых
вручную / для систем,
имеющих ограничения,
например, по лицензиям
или мощностям)
Заявитель
Инициатор
ЛР Владелец ВК ИБ ИТ
Пример маршрута согласования (бизнес-процесса)
15. На что похожа матрица SоD-конфликтов?
(offtopic на примере из SAP)
CISO Forum 2015 15
1
2
3
16. Заместители, Делегаты и Группы согласования
• Делегаты
• Может быть несколько у одного Согласующего
• Включаются сразу
• Отвечают за согласование набора ролей («функциональные заместители»)
• Заместители
• Один у одного Согласующего
• Включается по таймауту
• Полностью замещает Согласующего
• Вычисляется по штатной структуре
• Группа согласования
• Единая очередь доступная всем членам группы
• Каждый может взять в работу заявку, она пропадает из видимой очереди
остальных CISO Forum 2015 16
17. Требование к маршруту (бизнес-процессу)
• Могут быть разные для разных типов заявок (по ИС, например)
• Параллельное и последовательное согласование
• Динамическое вычисление фактических согласующих
• Функционал ДелегатовЗаместителейГрупп согласования
• Поддержка включения подпроцессов
• Оповещение об изменении статуса (позиции на маршруте):
• Исполнение – инициатору и пользователю
• Отклонение – инициатору, пользователю и всем, кто согласовал
CISO Forum 2015 17
18. Бизнес-процессы
Сотрудники
• Прием на работу
• Перемещение по
должности
• Увольнение
• Изменение личных
(некадровых)
данных
• Изменение ФИО
• Изменение срока
трудовой
деятельности
Роли
• Назначение/продле
ние срока действия
ролей
пользователю/долж
ности
• Лишение ролей
• Создание бизнес-
роли
• Изменение бизнес-
роли
• Удаление бизнес-
роли
Ресурсы
• Создание ресурса
• Изменение ресурса
• Удаление ресурса
Оргструктуры
• Создание
виртуальной
оргструктуры
• Удаление
виртуальной
оргструктуры
• Продление срока
действия
виртуальной
оргструктуры
Аудит
• Соответствие
доступа заявкам
• Обнаружение
неиспользуемых УЗ
CISO Forum 2015 18
19. Электронная заявка – не аналог бумажной!
CISO Forum 2015 19
Пользователь 1
Пользователь 2
Пользователь 3
Роль 1
Роль 2
Роль 3
Роль 4
Заявка
Пользователь 1
Роль 1
Пользователь 1
Роль 2
Пользователь 1
Роль 3
Пользователь 1
Роль 4
Пользователь 2
Пользователь 2
Пользователь 2
Пользователь 2
Роль 1
Роль 2
Роль 3
Роль 4
Пользователь 3
Пользователь 3
Пользователь 3
Пользователь 3
Роль 1
Роль 2
Роль 3
Роль 4
20. Организационная структура и Ролевая модель
• Определяет распределение ответственности и полномочий внутри организации
• Оргструктуры могут приходить из HR и могут быть и заведены вручную (виртуальные)
• Должно поддерживаться множество организационных структур, например, для
• реализации совместительства должностей одним работником,
• для удобного управления распределением полномочий в условиях разноплановых задач,
решаемых одними и теми же работниками (матричная структура)
• Позиция в любой оргструктуре используется для присвоения ролей. Роли, привязанные к
позициям в оргструктуре – Основные роли.
• Основные роли – привязываются пользователю автоматически (без дополнительного
процесса согласования присвоения*).
• Привязка конкретного пользователя к позиции в оргструктуре – Контекст пользователя.
• Пользователю может соответствовать несколько контекстов (~ может выполнять разные
функции на разных должностях).
• Роли пользователю присваиваются и отнимаются в рамках контекстов. Роли, запрошенные по
заявкам в том или ином контексте – Дополнительные роли.
• SOD-конфликты не берут во внимание контексты и анализируются по всем ролям,
присваиваемым пользователю (в рамках всего профиля пользователя).CISO Forum 2015
20
21. Ресертификация
• «Мягкая»
• Доступ сохраняется пока явно не подтвердили изъятие
• «Жесткая»
• Доступ сохраняется только если явно подтвердили сохранение
• «Параметрическая»
• Задан период сохранения доступа – «жесткая с отсрочкой»
CISO Forum 2015 21
22. ОсновныеДополнительные роли и Контексты
CISO Forum 2015
22
Компания К1
Департамент Д1
Управление У1
Отдел О1
Группа Г1
К1.Р1*
К1.Д1.Р1
К1.Д1.Р2
К1.Д1.У1.Р1
К1.Д1.У1.О1.Р1
К1.Д1.У1.О1.Р2
К1.Д1.У1.О1.Г1.Р1
К1.Д1.У1.О1.Г1.Р2
К1.Д1.У1.О1.Г1.Р3
К1.Д1.У1.О1.Г1.Р4
Позиция П1
К1.Д1.У1.О1.Г1.П1.Р1
Пользователь С1
K1:С1.Р1
K1:С1.Р2
K1:С1.Р3
K1:С1.Р4
Основные роли для позиции
К1.Д1.У1.О1.Г1.П1
Контекст К1.Д1.У1.О1.Г1.П1:С1 пользователя С1
Дополнительные роли для
контекста К1.Д1.У1.О1.Г1.П1:С1
Организационная
группа К2
Организационная
подгруппа Д2
Роль в группе П2
К2.Р1
К2.Р2
К2.Р3
Д2.Р1
Д2.Р2
П2.Р1
П2.Р2
П2.Р3
Контекст К2.Д2.П2:С1 пользователя С1
K2:С1.Р1
K2:С1.Р2
Ролевая модель для К1
* Любая роль IDM может быть и Дополнительной и Основной
одновременно, поэтому данный признак не является
свойством самой роли.
Ролевая модель для К2
Основные роли для позиции
К2.Д2.П2
Дополнительные роли для
контекста К2.Д2.П2:С1
23. Работа с Основными ролями
CISO Forum 2015 23
Компания К1
Департамент Д1
Управление У1
Отдел О1
Группа Г1
К1.Р1
К1.Д1.Р1
К1.Д1.Р2
К1.Д1.У1.Р1
К1.Д1.У1.О1.Р1
К1.Д1.У1.О1.Р2
К1.Д1.У1.О1.Г1.Р1
К1.Д1.У1.О1.Г1.Р2
К1.Д1.У1.О1.Г1.Р3
К1.Д1.У1.О1.Г1.Р4
Позиция П1
К1.Д1.У1.О1.Г1.П1.Р1
Ролевая модель для К1
• Основные роли (ОР) назначаются Пользователю
при официальном назначении в позицию П1.
• ОР могут проходить процедуру согласования или
присваиваться автоматически (по решению ИБ).
• При уходе пользователя с П1 происходит
«параметрическая ресертификация» || «жесткая»
• Ресертификация согласуется новым линейным
руководителем.
• Согласованные по ресертфикации роли
превращаются в дополнительные на новой
позиции.
Основные роли для позиции
К1.Д1.У1.О1.Г1.П1
24. Работа с Дополнительными ролями
CISO Forum 2015 24
Компания К1
Департамент Д1
Управление У1
Отдел О1
Группа Г1
Позиция П1
Пользователь С1
K1:С1.Р1
K1:С1.Р2
K1:С1.Р3
K1:С1.Р4
• Дополнительные роли (ДР) «набираются» пользователем по
заявкам через IDM. Контекст указывается при формировании
заявки.
• ДР всегда проходят процедуру согласования.
• При уходе пользователя с П1 для всех ДР происходит «мягкая
ресертификация» || «Параметрическая».
• Ресертификация согласуется новым линейным руководителем.
Контекст К1.Д1.У1.О1.Г1.П1:С1 пользователя С1
Дополнительные роли для
контекста К1.Д1.У1.О1.Г1.П1:С1
25. Путь в светлое будущее
• Первой оргструктурой будет пришедшая из HR.
• Первые Основные роли - «Работник предприятия» (почта, Интранет-
портал), «Работник Департамента» (папка департамента) и т.п.
• Первым контекстом будет «работник на определенной должности».
• Основная масса присвоенных ролей через IDM – Дополнительные.
• По мере анализа корпоративных бизнес-процессов – формирование
Ролевой модели, появление Базовых ролей.
• Необходимо выделение ресурсов на управление исключительно
Ролевой моделью, поскольку она нестатична во времени, а ее
адекватность полностью определяет эффективность IDM.
CISO Forum 2015 25
26. CISO Forum 2015 26
Сергей Солдатов, CISA, CISSP
@svsoldatov
reply-to-all.blogspot.com
Спасибо за Ваше внимание!
Вопросывозраженияпредложения?