Игорь, несмотря на то, что я буду стараться быть кратким, все-таки я решил воспользоваться своей возможностью писать постом, а не комментом :-)
1. Разные оргдокументы, требующие живых подписей, полагаю писались до нового закона о ЭП, откуда читаем в Статье 4:
"3) недопустимость признания электронной подписи и (или) подписанного ею электронного документа не имеющими юридической силы только на основании того, что такая электронная подпись создана не собственноручно, а с использованием средств электронной подписи для автоматического создания и (или) автоматической проверки электронных подписей в информационной системе."
+ по новому закону не обязательно использовать ГОСТовый.
Т.е., в целом, ничего не мешает двигаться в сторону электронного согласования.
Далее по рискам.
2.То, что Администратор царь и Бог - согласен. Но можно это компенсировать аудитом на отчуждаемое хранилище. Никто не собирается играть с админом в кошки-мышки, и риск его нелояльности не стоит пытаться компенсировать исключительно техническими мерами. Но можно:
а) Построить отчет соответствия фактических доступов в системе согласованным. Здесь уже многое зависит от реализации отчета, но технически практически все можно предусмотреть: предоставление доступа непосредственно аккаунтам, а не через согласованные группы, предоставление доступа через несогласованные группы, нелегитимное включение групп в группы, и т.п. б) вести аудит использования административных прав и критичных операций и забирать лог "к себе" (в SIEM) в, практически, реальном времени.
3. Фильтр твой - ужасен: "Если человеку действительно надо - он упорствует и получает доступ".
4. "Риски, связанные с использованием Избирательной модели управления доступом" - вообще, я тут о том, что есть принципиальная проблема в том, что некоторая сущность, Владелец ресурса, на свое усмотрение принимает решение о присвоении\неприсвоении доступа. Вообще-то такое доверие Владельцу небезопасно: он может ошибаться как по доброте душевной, так и по злому умыслу. Ролевая модель в этом плане предпочтительнее, поскольку ее можно привязать к штатке или каким-либо другим функциональным образованиям, тогда присвоение роли будет происходить при назначении пользователя на позицию (штатную или функциональную, например, роль в проекте), что уже выполняется более или менее коллегиально, а не по решению какого-то там Владельца ресурса.
5. С устареванием прав можно бороться:
- принудительной инициализацией пересмотра прав пользователей при его движении по штатке,
- предоставление доступа на время Проекта или просто на время (в случае необходимости, пользователи будут продливать - тоже сродни твоему "фильтру", но менее цинично :-)).
6. Про SOD-ы. Не все так просто: "есть доступ" и "нет доступа". Есть роли, которые нельзя совмещать и тебе это известно: Разработчик и Тестировщих, Разработчик и Пользователь, Бухгалтер и Казначей, пр. При проектировании бизнес-процесса необходимо выделять критичные операции, которые недопустимо совершить кому-то единолично. Тут и наши любимые админы: да они могут все, но от их действий должен остаться аудиторский след, причем в месте, где они не смогут "потереть логи" => администратор системы и администратор безопасности должны быть разными людьми. Аудит, традиционно, должен быть независим. В общем, роли, которые недопустимо совмещать, найдутся. Так вот, при присвоении ролей, следует проверять SOD-ы, т.е. есть пользователю присваивается Роль2, а у него, скажем, уже есть Роль1, дающая с Ролью2 конфликт высокого риска, такое присвоение не должно свершиться. Очевидно, что недопустимость совмещения Роли1 с Ролью2, разумнее проверять автоматически. Это сможет сделать IDM.
7. Избыточность полномочий частично компенсируется мерами изложенными в 5. Но твой пост на эту тему крайне интересен - пиши.
Далее пост твой сводится к извечному выбору между разработкой и коробочным решением. Тебе же известно, что я тоже наколеночник со стажем :-) и со времен работы в РосНИИРОС свято верю, что gcc и perl достаточно для реализации чего угодно :-) Но, я на личном опыте знаю чего стоит разобраться в коде талантливого программиста (а вы часто делаете комментарии? Вот я с тех пор часто, хотя не уверен, что это поможет тем, кому достанутся мои труды), поэтому все эти скрипты и "программки" имеют достаточно высокую вероятность умереть с уходом разработчика. Попробую систематизировать выбор тезисами (не буду их расшифровывать, если будут спорные моменты, лучше напрягусь и сделаю отдельный пост):
1. надо стараться выбирать коробочное решение. Стоимость его поддержки в будущем - ниже.
2. надо стараться настройку выполнять силами будущей поддержки. Либо, если уж настройка выполняется в проекте, будущая поддержка должна плотно участвовать в настройке.
3. если коробочное решение в своей типовой\рекомендуемой конфигурации не удовлетворяет потребностям, следует посмотреть в сторону изменения бизнес-процессов в соответствие с тем, что запрограммировано в коробочном решении.
4. должно быть нормальное описание конфигурации и Configuration Management.
5. если коробочное решение не удовлетворяет и требуется более 30% доработки - выбираем разработку. Тут поясню. Коробочные решения предлагают некие встроенные языки: Sun Java IDM - x-press, SAP - ABAP, у 1С - свой, русскоязычный, и т.п. Все эти языки создают иллюзию бесконечной гибкости (иллюзию? Я вас уверяю, что писать на C# куда приятнее, чем на X-Press + практически никаких ограничений!). Так вот, если предстоит "допиливать" более 30% коробочной бизнес-логики, и обойти это никак - берите Visual Studio, Java NetBeans, perl+vi или что вы там любите - это будет лучше.
6. если вы уж взялись за разработку, то тут уже надо хорошенько подумать о том, как потом не похоронить творение с уходом разработчика, чтобы "человечек с хорошими штанами" мог как-то поддерживать, а еще лучше и развивать, эту разработку. Тут можно предложить - документировать код по формальным правилам (ох, только правила надо придумать....).
а) Построить отчет соответствия фактических доступов в системе согласованным. Здесь уже многое зависит от реализации отчета, но технически практически все можно предусмотреть: предоставление доступа непосредственно аккаунтам, а не через согласованные группы, предоставление доступа через несогласованные группы, нелегитимное включение групп в группы, и т.п. б) вести аудит использования административных прав и критичных операций и забирать лог "к себе" (в SIEM) в, практически, реальном времени.
3. Фильтр твой - ужасен: "Если человеку действительно надо - он упорствует и получает доступ".
4. "Риски, связанные с использованием Избирательной модели управления доступом" - вообще, я тут о том, что есть принципиальная проблема в том, что некоторая сущность, Владелец ресурса, на свое усмотрение принимает решение о присвоении\неприсвоении доступа. Вообще-то такое доверие Владельцу небезопасно: он может ошибаться как по доброте душевной, так и по злому умыслу. Ролевая модель в этом плане предпочтительнее, поскольку ее можно привязать к штатке или каким-либо другим функциональным образованиям, тогда присвоение роли будет происходить при назначении пользователя на позицию (штатную или функциональную, например, роль в проекте), что уже выполняется более или менее коллегиально, а не по решению какого-то там Владельца ресурса.
5. С устареванием прав можно бороться:
- принудительной инициализацией пересмотра прав пользователей при его движении по штатке,
- предоставление доступа на время Проекта или просто на время (в случае необходимости, пользователи будут продливать - тоже сродни твоему "фильтру", но менее цинично :-)).
6. Про SOD-ы. Не все так просто: "есть доступ" и "нет доступа". Есть роли, которые нельзя совмещать и тебе это известно: Разработчик и Тестировщих, Разработчик и Пользователь, Бухгалтер и Казначей, пр. При проектировании бизнес-процесса необходимо выделять критичные операции, которые недопустимо совершить кому-то единолично. Тут и наши любимые админы: да они могут все, но от их действий должен остаться аудиторский след, причем в месте, где они не смогут "потереть логи" => администратор системы и администратор безопасности должны быть разными людьми. Аудит, традиционно, должен быть независим. В общем, роли, которые недопустимо совмещать, найдутся. Так вот, при присвоении ролей, следует проверять SOD-ы, т.е. есть пользователю присваивается Роль2, а у него, скажем, уже есть Роль1, дающая с Ролью2 конфликт высокого риска, такое присвоение не должно свершиться. Очевидно, что недопустимость совмещения Роли1 с Ролью2, разумнее проверять автоматически. Это сможет сделать IDM.
7. Избыточность полномочий частично компенсируется мерами изложенными в 5. Но твой пост на эту тему крайне интересен - пиши.
Далее пост твой сводится к извечному выбору между разработкой и коробочным решением. Тебе же известно, что я тоже наколеночник со стажем :-) и со времен работы в РосНИИРОС свято верю, что gcc и perl достаточно для реализации чего угодно :-) Но, я на личном опыте знаю чего стоит разобраться в коде талантливого программиста (а вы часто делаете комментарии? Вот я с тех пор часто, хотя не уверен, что это поможет тем, кому достанутся мои труды), поэтому все эти скрипты и "программки" имеют достаточно высокую вероятность умереть с уходом разработчика. Попробую систематизировать выбор тезисами (не буду их расшифровывать, если будут спорные моменты, лучше напрягусь и сделаю отдельный пост):
1. надо стараться выбирать коробочное решение. Стоимость его поддержки в будущем - ниже.
2. надо стараться настройку выполнять силами будущей поддержки. Либо, если уж настройка выполняется в проекте, будущая поддержка должна плотно участвовать в настройке.
3. если коробочное решение в своей типовой\рекомендуемой конфигурации не удовлетворяет потребностям, следует посмотреть в сторону изменения бизнес-процессов в соответствие с тем, что запрограммировано в коробочном решении.
4. должно быть нормальное описание конфигурации и Configuration Management.
5. если коробочное решение не удовлетворяет и требуется более 30% доработки - выбираем разработку. Тут поясню. Коробочные решения предлагают некие встроенные языки: Sun Java IDM - x-press, SAP - ABAP, у 1С - свой, русскоязычный, и т.п. Все эти языки создают иллюзию бесконечной гибкости (иллюзию? Я вас уверяю, что писать на C# куда приятнее, чем на X-Press + практически никаких ограничений!). Так вот, если предстоит "допиливать" более 30% коробочной бизнес-логики, и обойти это никак - берите Visual Studio, Java NetBeans, perl+vi или что вы там любите - это будет лучше.
6. если вы уж взялись за разработку, то тут уже надо хорошенько подумать о том, как потом не похоронить творение с уходом разработчика, чтобы "человечек с хорошими штанами" мог как-то поддерживать, а еще лучше и развивать, эту разработку. Тут можно предложить - документировать код по формальным правилам (ох, только правила надо придумать....).
1 comment:
По порядку:
1. Уверен, что существует множество других оговорок, позволяющих не признать "произвольно подписанный" документ юридически валидным. Кроме того, внутри ИС соблюдение требований законодательства считаю зачастую избыточным. Нужно ли мудрить с исполнением закона, когда большинство вопросов можно решить административно.
2. Но ведь речь не о штатной работе администратора, а об устном указании высшего лица (или близкого к нему сотрудника) на выполнение определенных мероприятий. Ну и потом, г-н Евтеев не устает выдумывать разные способы сокрытия своего присутствия в домене (http://devteev.blogspot.com/2012/03/backdoor-active-directory-iii.html).
3. Я понимаю, что с точки зрения науки мой фильтр неприятен :) Но опустись на землю. Есть ресурс для ограниченного пользования. Ты не можешь знать того, кому из нескольких тысяч сотрудников действительно нужен доступ к нему. Как защитить себя от ошибки? Этот фильтр хоть и грубый, но первый фильтр очистки.
4. Ну я и предложил, на основании уже собранных заявок формировать шаблон для инцициирования прав доступа нового сотрудника. Просто его пересматривать нужно периодически.
5. Как ты заставишь начальника буровиков, 2х метрового амбала с косой саженью в плечах, пересматривать профили? Его проблема - план по сверлению дырок в земле, ему начхать на твои хотелки и руководство его в этом поддержит.
6. СОздание ролей и определение из совместимости - адский труд, в большой компании. Кроме того, этот труд устареет очень быстро из-за постоянно меняющейся организационной структуры.
По поводу наколенности решения. Сергей, за мкадом нет миллионов на внедрение того же IDM. Если на рынке операционых систем от нашего любимого производителя мы видим решения для различных масштабов бизнеса, то в случае с IDM этого не наблюдается. Полагаю это связано с сложностью построения такой системы, но все-равно требуются решения-конструкторы для малого бизнеса, которые позволят не используя труд программиста собрать IDM своими силами.
Для справки, вне столицы, зачастую решения класса SMB пользуются в достаточно крупных сетях из-за ограничений финансирования.
Post a Comment