IDM как система мониторинга

В целом, достаточно занимательное занятие логгировать пролетающие через фаервол пакеты - обычно, почему-то, логгируют deny-и, хотя, наверно, любопытнее было бы смотреть на permit-ы. Также прикольно смотреть логи IDS\IPS... Но с точки зрения контроля доступа (а вся безопасность так или иначе может свестись к контролю доступа к защищаемым данным) куда более интересны события добавления\удаления роли\группы\полномочия. Безусловно любая продвинутая система умеет писать такие события в свои логи безопасности, соответстенно, их можно собрать в какой-нибудь SIEM и повесить на них какое-нибудь реагирование.
Однако тут есть некая философская проблема - такой инцидент не поднимется на бизнес-уровень самостоятельно и оператору мониторинга SIEM придется переводить технический отчет на язык понятный менеджерам. Делать такое "уточнение у бизнеса" скорее всего придется, поскольку далеко не всегда у оператора SIEM есть понимание насколько легитимно то или иное присвоение\удаление. 
Другим вариантом является - возложение вопроса аудита полномочий пользователей в системах на предмет соответствия поданным заявкам на подразделение контроля доступа, которое если и делает такие проверки то нечасто, что создает возможность преднамеренной атаки НСД остаться вообще не замеченной: несанкционированные добавления с последующим удалением полномочий проводятся между процедурмаи аудита прав.
Поэтому, обычно, на практике все-таки делают автоматическое оповещение об изменении полномочий, но для каких-то особых случаев, когда таких пользователей\ролей\полномочий не так много - как правило, какие-нибудь администраторы (Domain Admins, Enterprise Admins, Administrators, ....), казначеи и операторы систем ДБО и т.п.

Но все становится по-другому с появлением решений IDM\IAG (не буду тут много лить воды об их функционале и различиях - можно ознакомиться в Интернете). Практически все современные их представители имеют функционал аудита настроенных прав доступа в управляемой системе (системы, доступ к которым регулируется через IDM) на соответствие согласованным доступам в системе IDM. Найденные несоответствия могут обрабатываться по-разному, как правило, это настраиваемо. Мне нравится реакция в виде запуска workflow согласовния. Это позволяет автоматически вывести техническую проблему появления членства в лишней группе AD на бизнес-уровень - согласующие получат автоматически сгенеренные заявки по этому поводу на согласование. Если такой доступ был предоставлен в связи с реальной бизнес-потребностью, доступ останется и легализуется. Если такой доступ появился в результате каких-то неправильных позывов - он будет отобран IDM на основании отклоения поданной на этот доступ заявки. И вот тут уже прилетает оповещение в Безопасность, что был обнаружен и испрвлен факт НСД (так как заявка была отклонена Бизнесом). Принципиально здесь то, что решение об отъеме доступа принимается не оператором SIEM, у которого, безусловно, есть чем заняться (его любимые фаерволы и IDS\IPS генерят гигабайты логов в день, с которыми, раз уж собираем, надо хотя бы что-то делать), а бизес-согласующие по результатам отработки формального процесса согласования\отклонения доступа.

 

Наследование

Наследование - прекрасная возможность, предоставляемая ООП. Как и во многих вещах, здесь тоже лень была двигателем прогресса, и скрытый смысл этого изобретения - многократное использование одного и того же кода без необходимости переписывать: в потомках можно использовать код родителей, докручивая при необходимости. Утверждается, что такое многократное использование способствует снижению количества ошибок. Тут тоже все логично: чем меньше кода мы пишем, тем меньше ошибок делает. Однако, проблема начинается когда сам код базового класса содержит ошибки, а многократное наследование это тиражирует. Дальше хуже - если в каждом потомке мы что-то докручиваем, также делая ошибки, это приводит к совсем загадочным последствиям...

Проектирование и внедрение

Не понимаю почему, но в последнее время с удивлением наблюдаю тренд, когда сложные системы сначала проектируются одними, затем внедряются другими. Я в таком подходе вижу только минусы, о чем и расскажу здесь.

Этапность, когда одни проектируют, а другие внедряют размывает ответственность за результат. Как заказчик я предъявляю требования к конечному продукту, поэтому качество сделанной первыми работы я могу проверить весьма посредственно. Это дает возможность первым (проектантам) в прямом смысле сделать халтуру, ибо качество нельзя проверить, а результат (который я в состоянии принять) далеко не налицо (более того, - в ответственности других), а бумага вытерпит все.
Нет никакой гарантии, что первые, понимая, что есть риск не выиграть конкурс на внедрение не заложат некоторые "особенности", в которых только сами и могут разобраться. Поход известен еще со времен да Винчи, когда сам Леонардо вносил в чертежи своих изобретений ошибки, не позволяющие ими воспользоваться неавторизованным образом.
Кроме того, первые могут факт разработки ими проекта (а, следовательно, проведенные предпроектные исследования) использовать как свое конкурентное преимущество, что вообще ставит под сомнение всю идею такой этапности с двумя конкурсами.
Вторые, по правилам этапности, вынуждены полагаться на проект, разработанный своими предшественниками (причем, конкурентами :) ). При этом, у них нет возможности поисследовать ситуацию самостоятельно или потестировать какие-либо варианты, и надо быть готовым, что написанное в проекте вовсе не будет работать (*).... И что вы думаете они делают с этими всеми своими непреимуществами по сравнению с первыми? Правильно, компенсируют деньгами. Поэтому, по логике вещей, у вторых в принципе не может получиться дешевле сделать внедрение, чем у первых, кто проектировал. Вторые другие выигрывают конкурс на внедрение, только если только первые совсем потеряли совесть, что не делает такой двухэтапный подход снижающим совокупную стоимости проекта.

Мне можно возразить, что в итоге (когда внедрять будут первые, проектанты) получается самая очевидная и рабочая схема, когда один проектирует и внедряет. Вот он один - на нем вся ответственность за результат, логично, поскольку проектирование, по большому счету, ему самому нужно, а мне, как заказчику, важнее результат (то, что будет после внедрения), а не то, как решение было спроектировано. Однако, подход с такой этапностью дает возможность на втором этапе победить некомпетентному исполнителю. Зачем самостоятельно создавать такой риск? Зачем все эти накладные расходы на двухэтапность, столько потерянного времени?..



(*) То, что я тут пишу - не просто ловкословие. Мне не раз приходилось доделывать красиво спроектированные проекты, чтобы все-таки получить не бумагу, а решение. При этом проект далеко не всегда коррелировал с тем, что написано в проекте, цитата Эйнштейна работает всегда.