Сакральным смыслом данного поста является телепортация знаний из сердца нашей Родины.
Итак, некоторое время над мы рассуждали об IDM и даже получили ответ .
Сделаем второй шаг и выложим свои идеи бюджетной системы управления учетными записями для небольшой компании, размером в несколько тысяч сотрудников.
Начальные условия следующие:
1. Все пользователи хранятся в Active Directory.
2. Права в системах (всех, любых) даются на основании членства в группах Active Directory.
3. Вновь внедряемые или модернизируемые системы перестраиваются с учетом условий 1 и 2.
Термины и определения:
Базовые права – доступ к внутренней электронной почте и доменная учетная запись.
Шаблон должности – набор прав, характерный для данной должности.
Информационный ресурс - сущность, к которой осуществляется доступ на основании заявки.
Варианты работы с заявками.
1. Прием на работу
При приеме на работу Система, на основании информации из кадровой базы, оформляет и согласует для пользователя автоматически (здесь и далее, действие инициируется сотрудником кадровой службы) заявку на создание почтового ящика для пересылки внутри ИС.
Первый пароль пользователя передается системотехнику, который выходит на настройку компьютера. В свойствах учетной записи должен быть установлен параметр «Обязательная смена пароля при следующем входе в систему».
Система автоматически оформляет заявки в соответствии с шаблоном должности.
2. Увольнение
На основании заявления, кадровая служба обязана в момент получения заявления на увольнение установить параметр пользователя «Подготовка к увольнению». В результате Системой автоматически должны быть оформлены и согласованы заявки на блокировку доступа к следующим информационным ресурсам:
- внешняя электронная почта;
- доступ в Интернет;
- доступ к сменным носителям.
Так же после отъема этих прав, должна быть возможность передать их (автоматически оформить и согласовать заявки) на замещающего сотрудника в момент блокировки старого или позже. Эти заявки так же согласуются автоматически.
Передача прав не может быть осуществлена от одного сотрудника более одного раза.
В начале дня увольнения, в соответствии с заявкой, учетная запись блокируется в 00:01.
3. Увольнение и прием в дочернее предприятие (ДП).
При переводе в ДП в рамках головного предприятия и ДП, действуем аналогично п.2, кроме блокировки в день увольнения.
В начале дня увольнения, на основании информации из кадровой базы, автоматически оформляются и согласуются заявки на блокировку доступа ко всем информационным ресурсам, кроме электронной почты. При этом старым руководителем сотрудника и подразделением безопасности должно быть согласовано сохранение электронного адреса, либо его замена. Эта заявка должна быть подана автоматически не позднее чем за 3 дня до перевода. Если заявка не подана вовремя (заявление поступило в кадровую службу позднее), доступ пользователя блокируется полностью до оформления заявки на перевод с сохранением адреса или оформление в соответствии с п.1. При этом система должна проконтролировать несовпадение электронных адресов.
4. Перевод в другой, независимый отдел в рамках предприятия
При переводе в другое подразделение, в рамках одного предприятия, действуем аналогично п.3
5. Перевод на вышестоящую должность, Перевод на нижестоящую должность, Перевод в рамках отдела
Система автоматически, на основании информации из кадровой базы, оформляет и согласует заявку на блокировку учетной записи в связи с переводом, с указанием вида перевода. У сотрудника отбираются все права, кроме базовых.
Система автоматически оформляет и согласует заявки на предоставление прав в соответствии с шаблоном новой должности.
6. Смена фамилии.
При смене фамилии оформляется заявка (или 2 заявки) которая видна, если поиск осуществляется по старой или новой фамилии. При этом в заявке указывается что на что поменялось.
7. Отпуск, больничный, декретный отпуск, командировка.
При оформлении отпуска, больничного, декретного отпуска и командировки, на основании информации из кадровой базы, автоматически оформляется и согласуется заявка на блокировку учетной записи. По окончании периода блокировки, если это не противоречит информации из кадровой базы, системой автоматически оформляется и согласуется заявка на разблокировку пользователя.
8. Создание удаление инфрмационных ресурсов.
После подачи и согласования заявки, информация о ресурсе добавляется в базу, для оформления заявок на доступ. Бизнес администратор информационного ресурса назначается из числа сотрудников имеющих доступ к ИС. При увольнении сотрудника являющегося бизнес-администратором системы, система должна уведомить руководителя сотрудника, о необходимости назначить нового администратора.
Вот такие мысли. Жду комментариев.
Thursday, April 12, 2012
IDM для замкадышей
Labels: Enterprise Security, IDM
Subscribe to:
Post Comments (Atom)
5 comments:
Самые интересные проблемы начинаются при попытке создания "шаблона должности" (т.е. набора прав) - что фактически есть построение ролевой модели для всей компании. Правила же, которые ты описал, хотя и могут быть довольно сложными, но вполне формализуемая и выполнимая задача.
И вопрос в тему - а кто-нибудь видел полностью внедренную и функционирующую ролевую модель в пределах целой компании?
Единую ролевую модель представить сложно, но:
1. Можно вычленить какие-то типовые наборы полномочий для:
- сотрудника Компании,
- сотрудника Подразделения (подразделений может быть иерархия,
например: Сотрудник Бизнес-функции, Сотрудник Департамента, Сотрудник
отдела, и т.п.)
2. Скорее всего придется вводить что-то типа Проектов, со своими
функциональными ролями со временем жизни - до окончания проекта. В
зависимости от роли в проекте на срок проекта пользователю будут
подтягиваться соответствующие права.
3. Как всегда, останутся какие-то останки, для которых придется
реализовывать старый добрый DAC с Владельцем ресурса и принятием
решения на основании его личного усмотрения.
Единая Ролевая модель не получится. Единая Ролевая модель - некая
идеальная картина, которой можно в какой-то степени соответствовать.
Причем эта самая степень и есть тот самый компромисс между
безопасностью и стоимостью ее реализации.
Давайте меня критиковать :-0
Игорь, теперь по тексту.
В целом, нормальные бизнес-процессы. Лишь некоторые вещи меня смутили:
а) Цитата: "5. ... Система автоматически, на основании информации из кадровой базы, оформляет и согласует заявку на блокировку учетной записи в связи с переводом, с указанием вида перевода...". Не понял, зачем при переводе блокировать учетную запись. Надо в день Х старые роли отобрать новые дать на основании позиции.
б) Цитата: "7. Отпуск, больничный, декретный отпуск, командировка.
При оформлении отпуска, больничного, декретного отпуска и командировки, на основании информации из кадровой базы, автоматически оформляется и согласуется заявка на блокировку учетной записи". При условиях наличия удаленного доступа, блокировка не нужна. Исключение, разве что, - декрет. По опыту - не надо обрабатывать ничего из перечисленного, кроме декрета, так как во-первых таких ситуаций крайне много и если там хоть что-то делается вручную, будет большая загрузка, а во-вторых, люди работают по удаленному доступу, учетка им нужна.
в) Кто такое "бизнес-администратор" из п 8? Надо бы его в термины. По смыслу - должен быть Владелец ресурса.
Что я не понял из текста.
1) Все перечисленные бизнес-процессы обеспечиваются чем? Они автоматизированы, или выполняются вручную - скажем, вменены в обязанности кадровиков, служб ИТ, пр. участников?
2) Если автоматизация есть, то хотелось бы узнать о ней поподробнее. Что используется: скрипты на VBS, Perl? Есть ли портал самообслуживания, вообще, какие интерфейсы есть? Какие отчеты есть?
3) Каков маршрут заявки? Он один на всех или каждый вид доступа имеет свой маршрут?
4) какие функции контроля используются? Т.е. как проверяется что указанный порядок не нарушается, что все доступы согласованы и согласованы правильно, и т.п.
5) как подтверждается неотрицание авторства? Используется ли ЭЦП?
В общем, с нетерпением ждем очередной серии "IDM для Замкадышей, продолжение".
Надо бы добавить предоставление доступа на основе срочных\консалтерских договоров.
Сергей, условие удаленного доступа можно проверять через наличие учетки в группе AD, и только в этом случае не блокировать учетку.. блокировка учеток на время формального отсутствия работает сразу против внешнего нарушителя (например, раз юзера нет, то кто поменяет пароль?) так и против внутреннего (например, предотвращает "колхозное" использование паролей декретчицы).
В целом модель - access-as-you-go (по аналогии с аутсорсинго-клаудовским pay-as-you-go) не только добавляет динамичности бизнесу но и уменьшает поверхность атаки (кол-во активных учеток)..
Саша, вообще не понятна идея. Соблюдение наших любимых принципов "least privilege" и "Need to know" дают твое "access-as-you-go" - все придумано до нас.
В любом случае все упирается в стандартные футентификацию и авторизацию. Если я злоумышленник и у меня получилось успешно авторизоваться - не важно как у меня подключаются права - статиечески или динамически.
Или я что-то не так понял?
Post a Comment