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. если вы уж взялись за разработку, то тут уже надо хорошенько подумать о том, как потом не похоронить творение с уходом разработчика, чтобы "человечек с хорошими штанами" мог как-то поддерживать, а еще лучше и развивать, эту разработку. Тут можно предложить - документировать код по формальным правилам (ох, только правила надо придумать....).
