Стандартная ситуация для современных бизнес-процессов — множество привилегированных пользователей. Это администраторы организации и отдельно взятых систем, топ-менеджеры и руководители департаментов, программисты, а также продвинутые пользователи, находящиеся в поиске «лазеек» для обхода существующих политик информационной безопасности (называемые в зарубежной среде “shadow IT”).
Почему привилегированных пользователей много?
Чаще всего избыточными оказываются назначенные на различных уровнях права полного доступа: возможности предоставить или отозвать доступ для других пользователей. Это происходит из-за того, что сложно «с наскока» разобраться с ролевой моделью доступа в каждой новой системе, когда развернуть и настроить для работы её надо было «ещё час назад».
Еще одна немаловажная причина в том, что бизнес и ИТ-департамент не заботит конфиденциальность, стоящая во главе угла у ИБ. Их приоритет – доступность бизнес-пользователям данных и сервисов, которые им, хотя бы теоретически, могут понадобиться.
Причин может быть много, но есть два общих условия «избыточности». Первая — отсутствие политики безопасности, которая рассматривала бы большое количество привилегированных пользователей как риск, и заставляла с ним считаться в процессе управления изменениями. Вторая — недостаточность технических средств, способных нивелировать или исключить эти риски.
Возьмём наиболее яркий пример. У программистов может стоять среда разработки на рабочих компьютерах, и они могут иметь права локального администратора, чтобы проверять любые свои изменения на практике, устанавливая гипервизоры, развёртывая виртуальные машины, где они также будут администраторами.
Риск ли это? Безусловно. Можно ли его избежать? Можно. Для этого нужно строить системы, которые исключат необходимость работы вне общей контролируемой среды. Системы, из которых невозможно воздействовать на клиентские узлы, и наоборот, сильно ограничивающие векторы атаки на шлюз, позволяющие получить доступ к тестовому сегменту разработки.
Другой пример, весьма часто встречающийся. Группа администраторов домена включается в состав администраторов любой из внедрённых на предприятии систем. Взлом пароля, использование хэша пароля или тикета Kerberos для аутентификации могут привести как к утечке критичных данных в обход присутствующих мер противодействия, в том числе после их перенастройки, так и к нарушению работы множества систем, с последующим исключением из состава их администраторов всех УЗ, которые там присутствовали до инцидента.
Определяем необходимый уровень прав доступа
Глобальная сложность с «привилегированными» пользователями заключается в том, что сложно определить, много ли прав доступа у сотрудников, не вдаваясь в подробности настройки ролевой модели предоставления доступа каждого отдельного приложения. Зачастую выяснить это можно по утекшим к конкурентам или в СМИ конфиденциальным данным. Произойти это может и при наличии легитимного доступа. Но реже, отвечающие за конкретные данные по своим трудовым обязанностям сотрудники чаще более ответственны, чем те, кто на них просто наткнулся в поисках «лёгкой добычи».
Еще одна проблема открывается, когда шифровальщик затронул не только папки отдела, в котором работает сотрудник, открывший документ из, казалось бы, не подозрительного письма, но и большую часть всех файловых хранилищ (даже те, где этому отделу было бы достаточно только прав на чтение).
Есть и более «печальные» случаи, которые сложно связать с избыточностью прав напрямую, не проведя расследование по журналам доступа. В нашей практике были прецеденты доступа в сеть крупных корпораций и перемещения по ней между сегментами со стандартными логинами и паролями. К чему это потенциально может привести в самом плохом случае? Например, к физическому устранению лиц, на основе информации, поступающей от открытой для доступа системы видеонаблюдения или полученной из календаря в Outlook.
Определить избыточность прав сотрудников намеренно и наиболее полно можно во время проведения аудита ИБ по конкретным местам инфраструктуры. Объективных критериев масса, и для каждого сегмента среды компании они могут различаться, но в основном это либо методология по безопасной конфигурации систем, либо наборы лучших практик, либо личный обширный опыт непосредственного аудитора в узкоспециализированной области.
И боремся с избыточностью
Если удалось выяснить, что права были избыточны, можно воспользоваться методологией PDCA (известной как «цикл Деминга»). Она предполагает выполнение следующих действий: планирование, действие, проверка, корректировка. Применение этой модели по каждому из выявленных критериев риска с переключением на новые, пока не контролируемые в компании, поможет преобразовать цикл в восходящую (или «вгрызающуюся в землю) спираль. Именно она поможет развить защищённость ИТ-активов компании, включающую в себя как отсутствие компрометации инфраструктуры, так и данных.
Безусловно, когда мы начинаем урезать права доступа, то анализировать каждую привилегированную учетную запись трудозатратно. Однако можно выделить в ИТ-инфраструктуре роли. Это позволит настроить RBAC (Role-Based Access Control) в каждой отдельной системе. А в тех системах, где доступ на основе ролей не предусмотрен, можно использовать механизмы решений, автоматизирующих предоставление прав доступа на основе прописанных в них ролей.
Без сложностей, конечно, не обойдется. Ломать существующий порядок вещей и строить новое сложно. Это часто приводит к саботажу со стороны тех, кто привык к определённой организации рабочего процесса и не желает переучиваться. Потерю части прав пользователи даже не заметят: ведь большей частью данных, инструментов и функций сотрудники и так не пользуются. Однако стоит на всякий случай оставить временную возможность по запросу вернуть часть из «отобранного» в исходное состояние для конкретной роли.
Например, возьмём процесс удаления старых данных: удаляются файлы в папках, созданных в предыдущие годы, доступа к которым со стороны бизнес-пользователей не было за истекший год. Более 90% таких данных никому внутри компании уже не нужны, и могут понадобиться разве что аудиторам и сотрудникам силовых ведомств при проверках (для целей которых могут быть восстановлены по заявке из резервных копий на лентах). Но со скрупулёзностью Плюшкина такие данные собираются и оберегаются любым из сотрудников отдела, «чтобы чего не случилось» и «а вдруг срочно понадобятся». Стоит ли говорить, что в этих файлах может содержаться критичная информация, доступ к которой можно либо ограничить, введя более строгие списки доступа для папок с такими данными, либо вовсе убрав их с файлового ресурса. Тем самым модель доступа становится проще, а в файловых хранилищах экономится много дискового пространства.
Таким же образом и внедрение ролевой модели, базирующейся на принципах «нулевого доверия» (Zero Trust), или же «модели минимально необходимых привилегий» (least privilege model), по факту, не повлечёт за собой ИТ-рисков. При этом облегчит работу как сотрудникам ИТ (у которых появятся строгие инструкции по выдаче прав пользователю с конкретной ролью), так и ИБ (которые смогут контролировать корректность выдачи прав и избегать административного доступа повсюду для конкретной УЗ).
Стоит, однако, помнить, что даже после реализации вышеуказанных мер, площадь атаки не исчезнет, а лишь сократится. Поэтому необходимо продолжать обучение сотрудников основам информационной гигиены и цифровой безопасности и в рамках их новых ролей.
