Практические аспекты реализации Access Control

Георгий Гарбузов
CISSP, CISA, MCSE: Security, дирекция информационной безопасности Страховой группы "УралСиб"

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

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

Учет информационных ресурсов

Для того чтобы управлять информационными ресурсами (ИР), прежде всего, их нужно выявить (обозначить границы) и пересчитать, то есть провести инвентаризацию. Здесь можно столкнуться с рядом проблем.

Как обычно происходит инвентаризация ИР? Очень просто - работник службы ИБ берет лист бумаги и начинает обходить/обзванивать руководителей подразделений на предмет используемых подразделениями активов, причем он сам на основании собственного суждения решает, что является ИР в каждом конкретном случае, а что нет.

Случай использования одной сетевой папки отделом из двух человек является идеальной ситуацией, на практике, даже в небольшом предприятии, все сложнее. Типичной, скорее, является организация с несколькими десятками/сотнями подразделений или даже с разветвленной региональной сетью, и для инвентаризации здесь уже потребуется целая армия специалистов! Не говоря о необходимости взаимопонимания с интервьюируемыми руководителями, что с учетом загруженности и разного уровня их подготовки делает задачу чрезвычайно сложной. Но существует простое, на первый взгляд, решение проблемы, которое заключается в рассылке руководителям запроса о предоставлении перечня используемых подразделениями ИР. Решение представляется оптимальным и экономически необременительным (что особенно актуально в условиях кризиса, когда урезанные бюджеты на ИБ не позволяют расширить штат), но, используя общие формулировки ИР в запросе, мы получаем совершенно не то, что нужно, - от списка Интернет-сайтов до сведений об установленных на компьютере программах.

Правильно заданный вопрос, как известно, содержит значительную часть ответа, и в данном случае проблема заключается в неясно сформулированном запросе. Для получения требуемой информации необходимо объяснить руководителям (вовсе не обязанным разбираться в тонкостях информационных технологий), что именно от них требуется, сформулировав конкретные "правила игры".

Ресурс или не ресурс?

Определимся сначала для себя, что же такое информационный ресурс. Актуальное российское законодательство не дает четкого определения ИР, встречаются лишь частные формулировки. Например, Федеральный закон № 20-ФЗ от 10.01.2003 г. "О государственной автоматизированной системе Российской Федерации "Выборы" определяет ИР как информацию, а в предыдущей редакции Федерального закона "Об информации..." ИР был определен как документ или массив документов (напомню, что действующая редакция Закона "Об информации..." определения ИР не содержит). Но на практике организациям удобно формулировать единые правила предоставления доступа как к файловым ресурсам, так и к электронной почте и программным модулям, которые согласно данному определению ИР не являются. Кроме того, оценить угрозы ИБ по отношению к документу (не говоря уже о нематериальной информации) в отрыве от имеющейся ИТ-инфраструктуры -задача и вовсе утопическая. Понятие же "информационной системы", с другой стороны, слишком широко, так как дополнительно включает людей, процессы и технологии. Так каким образом службе ИБ помочь руководителям найти и очертить границы ИР?

Здесь могут помочь критерии для выявления и декомпозиции ИР, подобные предлагаемым ниже. Набор не претендует на абсолютную полноту и окончательность (в каждой организации может он быть своим), но общие принципы везде одинаковы. Итак:

• Размещение: в сети - используется совместно работниками одного подразделения или несколькими подразделениями (сетевая папка, программное обеспечение для совместной работы).
• Функциональное назначение: решаемые с помощью ресурса задачи (например, формирование статистической отчетности).
• Категория конфиденциальности: разделение или объединение ИР по признаку степени конфиденциальности информации (если возможно).
• Основные пользователи: схожесть функциональных обязанностей пользователей ресурса (например, "бухгалтерия").
• Самостоятельная ценность: дальнейшее разделение ресурса нецелесообразно (не существует задач, предполагающих раздельное использование ИР).
• Технические возможности: дальнейшее разделение ресурса не предусмотрено технически.
• Тип: программное обеспечение, база данных, файловый сетевой ресурс (диск, папка).

Декомпозиция выявленных ИР производится до оптимального удовлетворения критериям, которые применяются последовательно: сначала отделяем сетевые объекты от локальных, затем группируем ИР по функциональному назначению и пользователям, после чего оцениваем возможность и целесообразность дальнейшего разделения ресурсов, в том числе по типам.

Для упрощения задачи стоит также привести в запросе типичные примеры используемых в организации ИР:

• "неделимое" программное обеспечение (Консультант+);
• отдельные модули программного обеспечения (модули SAP R/3);
• сетевая папка (\\server1\fol-der1).

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

Владение и управление доступом к ИР

Дальнейшие действия выполняются для установления владения и управления доступом к учтенным ИР. Каждому ИР назначается владелец (обычно из числа руководителей подразделений), совместно с ним проводится классификация ИР по ценности (которая, например, учитывает степень конфиденциальности информации, стоимость восстановления ИР или допустимое время его простоя), затем окончательный вариант перечня (реестра, справочника) публикуется во внутренней сети. Перечень как минимум содержит унифицированные названия ИР, сведения об их классификационной категории и владельцах, а также о лицах, отвечающих за непосредственное предоставление к ним доступа. Перечень будет использоваться работниками организации при формировании запросов на доступ (правила доступа могут различаться для ИР различных категорий). Здесь можно отметить следующее: во-первых, стоит подумать об использовании ролевого принципа (role-based access control, RBAC). Суть его заключается в том, что доступ предоставляется не конкретным лицам, а некой роли или, проще говоря, - группе лиц, решающих определенные задачи или обладающих иной схожестью (например, по подразделению или территориальному размещению). В этом случае управление доступом значительно упрощается (что особенно актуально для крупных и "сложных" организаций) и сводится к предоставлению работнику определенной роли.

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

В этом случае администратор доступа при получении, например, запроса от работника бухгалтерии на доступ к 1С видит в перечне предустановленную для данного ИР роль "Бухгалтерия" и назначает работнику доступную ему роль (предоставляет доступ к ИР), не запрашивая подтверждения доступа у владельца.

Во-вторых, при определении правил предоставления доступа (в том числе при формировании ролей) владельцам необходимо помнить несколько основных принципов:

Segregation of duties - разделение ответственности (в рамках одной задачи) для минимизации возможности нанесения ущерба одним лицом;

• Rotation of duties - смена обязанностей для уменьшения вероятности сговора;
• Least privilege - предоставление наименьших привилегий, достаточных для работы;
• Need to know - предоставление доступа только к необходимым для работы объектам.

И еще одна маленькая оговорка - не следует делегировать владельцам, даже технически продвинутым, привилегии непосредственного управления правами в системе (на практике так часто делают для снижения нагрузки на подразделения ИТ-сопровождения). Это может иметь негативные последствия, например, бездумное удаление системных учетных записей ведет к сбою процесса резервного копирования (ввиду недоступности объекта).

Вместо резюме

Управление доступом - не просто элемент системы ИБ, это база, на которой в дальнейшем строится масса других процессов. Поэтому правила Access Control должны строиться "на века", а взятые единожды на вооружение практические приемы должны быть документированы и внедрены повсеместно по всей организации - пересмотр выбранных однажды критериев и правил будет чрезвычайно затруднителен. Поэтому, прежде чем утверждать регламент управления доступом, стоит проиграть весь процесс от начала и до конца, не пренебрегая "репетициями" с привлечением "дружественных" бизнес-подразделений и отдельных работников.