Monday, March 19, 2012

На IDM or not IDM

Игорь, несмотря на то, что я буду стараться быть кратким, все-таки я решил воспользоваться своей возможностью писать постом, а не комментом :-)


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

Thursday, March 15, 2012

Linux - не все так плохо


Читал книжку, Linux глазами хакера, 3-е издание. Прочитал странную вещь:
Прошу прощения, что криво, но хотелось именно процитировать.
Еще с дремучего издания Андрея Робачевского известно, что символьная ссылка ссылается на имя файла (у нее даже размер равен имени файла с путем :-)), т.е. несмотря на то, что символьная ссылка имеет права 0777, это не значит, что будет полный доступ к файлу. Тем не менее, не поленился проверить. Думаю, комментарии излишни:

root@daczcsvst60pde:/# ln -s /etc/shadow /etc/shadow.lnk
root@daczcsvst60pde:/# ll /etc/shadow*
-rw-r----- 1 root shadow 1218 Feb 6 17:50 /etc/shadow
-rw------- 1 root root 1218 Feb 6 17:50 /etc/shadow-
lrwxrwxrwx 1 root root 11 Mar 14 22:04 /etc/shadow.lnk -> /etc/shadow

svsoldatov@daczcsvst60pde:/$ cat /etc/shadow
cannot read /etc/shadow: Permission denied
svsoldatov@daczcsvst60pde:/$ cat /etc/shadow.lnk
cannot read /etc/shadow.lnk : Permission denied

Может, я что неправильно понял?

IDM or not IDM

Не говорите, что эфир не существует! Только начал упорядочивать на бумаге порядок оформления заявок на доступ к информационным ресурсам, как Сергей затрагивает тему IDM!

Когда пришел на нынешнее рабочее место 3 года назад, здесь для согласования доступа к информационным ресурсам во всю использовались бумажные заявки. Заявки согласовывались около недели, терялись и не поддавались учету.

На первом этапе, в пику разным оргдокументам, требующим живых подписей и печатей, сделали учет и ввод заявок в табличку шарепоинта. Процесс ускорился.

Следующим этапом перестали согласовывать заявки для ресурсов, которые не прошли процедуру регистрации (на которые не оформлена заявка на создание ресурса и не определен бизнесадминистратор).

Затем попытались категорировать ресурсы. Пара недель работы с администраторами толку не дали - результаты валяются в виде файла и не находят применения в реальной жизни (об этом нужно писать отдельно).

Потом появились заявки на блокировку учетных записей. Сделали их для борьбы с мертвыми душами. Но такой способ блокировки не был принят пользователями.

Тогда перешли к этапу, на котором при создании учетных записей требуем от пользователей указывать, кто работал до них на этом рабочем месте. Ох и тяжело, порой объяснить человеку, что от него хотят и что нужно сделать...

Что имеем сейчас:

  • почти 20000 заявок собранных за 3 года.
  • категорированный перечень из более чем 150 информационных ресурсов
  • дикие трудозатраты на оформление и сопровождение заявок
  • историю доступа пользователей к ресурсам
  • некое подобие шаблона прав для пользователей, когда вновь принятому сотруднику высылается список заявок оформленных его предшественником
  • випов, получающих доступ куда хочется посредством движения бровью

А теперь давайте посмотрим, как мы подвержены рискам указанным тут:

  • Предоставление группой эксплуатации (ИТ) доступа, отличного от согласованного - какая ни была бы ИС - с IDM или без него, администратор всегда сможет дать доступ по высшему повелению или внутреннему позыву.
  • Предоставление доступа на основании «некорректного» согласования (доступ не согласован в установленном порядке) - ну для этого мы имеем историю заявок для определенной позиции. Кстати говоря, нельзя не упомнить здесь следующее - 90% сотрудников пишут заявку на доступ в Интернет, к внешней электронной почте и сменным носителям. Рассматривать все эти заявки - долго, поэтому на первую заявку мы с вероятностью 98% отвечаем отказом. Если человеку действительно надо - он упорствует и получает доступ. Вот такой фильтр.
  • Риски, связанные с использованием Избирательной модели управления доступом - решаем на коленке, через просмотр истории заявок для новых сотрудников
  • невозможность выявления некорректных прав пользователей - центральный сервер syslog собирает и хранит записи об изменениях в структуре АД, планируем делать ежедневный diff для АД и максимально автоматизировано сравнивать его с табличкой в шарепоинте
  • устаревание прав ввиду изменения бизнес-процессов Компании - почему мне не верится, что IDM может помочь "бороться" с любовью людей "переставлять мебель" спонтанно и быстро
  • некорректное совмещение критичных полномочий в информационных системах - но ведь мы не военное ведомство. У нас по сути групп доступа 2 - сотрудники имеющие доступ к коммерческой тайне и сотрудники не имеющие к тайне доступа... Неужели без IDM-ма не справимся с этими 2-мя группами?
  • избыточные полномочия пользователей в случае изменения их статуса в бизнес-процессах Компании - а вот этому посвятим следующий пост.

Что мы видим? Наняв человечка с минимальной квалификацией и хорошими штанами, выплачивая ему 7-15 т.р. в месяц мы можем получить естественно-интеллектуальную систему управления учетными записями. С больничными и отпуском есть проблема, но размер зарплаты позволяет нам организовать холодный или даже горячий резерв!

Wednesday, March 14, 2012

IDM для Информационной безопасности

Возможно, очевидные вещи будут здесь написаны, но, надеюсь, кому-то будет полезно.

Преимущества от внедрения IDM получат все: ИТ, так как повысят свою efficiency - многие работы будут автоматизированы, Бизнес, так как использование бизнес-ролей и ролевой модели доступа с привязкой к корпоративной оргструктуре и/или бизнес-процессам Компании позволят им понимать к чему сотрудники имеют доступ, Безопасность, так как будут адресованы ряд ключевых рисков, связанных с контролем доступа.

На безопасности хочется остановиться подробнее, отметив основное, что на мой взгляд должно объективно стимулировать движение в сторону подобных решений. Все-таки 21ый век на дворе и ручно-бумажно-пешконосный контроль доступа выглядит несовременно :-)

Риск: Предоставление группой эксплуатации (ИТ) доступа, отличного от согласованного.
Контроль: IDM автоматизирует процесс наделения учетных записей техническими правами, доступ предоставляется без участия администратора.

Риск: Предоставление доступа на основании «некорректного» согласования (доступ не согласован в установленном порядке).
Контроль: Процесс согласования доступа жестко запрограммирован в IDM: правильность маршрута согласования обеспечена конфигурацией IDM.

Риск: Риски, связанные с использованием Избирательной модели управления доступом (discretionary access control, DAC)
Контроль: IDM позволяет построить Ролевую модель управления доступом, при которой успешность предоставления доступа не будет полностью основываться на решении согласующих (Владельце ресурса, например), а будет зависеть от позиции пользователя в бизнес-процессах компании (должности, подразделении, функциональных обязанностях).

Риск: невозможность выявления некорректных прав пользователей (некорректно присвоенных ранее или устаревших ввиду различного рода изменений в компании).
Контроль: IDM позволяет проводить сравнение своей базы доступов (корректно согласованных) с фактическим состоянием технических прав в обслуживаемых информационных системах. Таким образом, обеспечивается проведение периодического технического аудита полномочий пользователей, что позволит выявлять ошибки и злоупотребления.

Риск: устаревание прав ввиду изменения бизнес-процессов Компании.
Контроль: IDM предоставляет ответственным от бизнеса удобный интерфейс просмотра и корректирования бизнес-ролей пользователей. IDM позволяет этот процесс инициировать принудительно по расписанию, что позволит обеспечить выполнение требований безопасности. Подобный аудит безнес-ролей пользователей позволит в большей степени соблюдать принцип Минимума полномочий (Least Privilege) – не нужные, устаревшие права будут отобраны по инициативе бизнеса.

Риск: некорректное совмещение критичных полномочий в информационных системах.
Контроль: IDM позволяет автоматизировать соблюдение принципа Разделения ответственности (Segregation of Duties, SOD): Роли которые нельзя совмещать у одного пользователя не смогут быть запрошены и/или присвоены.

Риск: избыточные полномочия пользователей в случае изменения их статуса в бизнес-процессах Компании.
Контроль: IDM интегрируется с системами кадрового учета, таким образом, любое кадровое изменение пользователя будет инициировать процесс пересмотра прав пользователя в информационных системах.

Перечисленное - первое, что пришло в голову. Если что забыл - комментарии приветствуются.