Планирование политики безопасности: «матрица доступа»

в 17:19, , рубрики: администрирование, безопасность, информационная безопасность, планирование, системное администрирование, метки: , ,

Из серии «сисадминство для чайников», по многочисленным просьбам коллег.

Введение

Многие системные администраторы и специалисты по безопасности сталкиваются с трудностями при настройке систем ограничения доступа в своих «вотчинах». Это может быть связано со многими причинами, например: недостаток опыта у системного администратора, недостаток документации, нечёткая постановка задачи заказчиком.

В этой статье предлагается простой способ разработать, уточнить и быстро внедрить систему разграничения доступа на предприятии. Я называю оный «матрицей доступа», так как основной его инструмент представляет собой двухмерную таблицу.

Ресурсы и мандаты

То, к чему тот или иной пользователь может получить доступ, мы назовём ресурсом. Ресурсом может являться как область хранилища (например, каталог или файл на сервере), так и некая совокупность ресурсов в сети Интернет (например, «социальные сети», «видеохостинги»). Отдельным видом ресурсов является также право полного доступа к областям хранилища или ресурсам сети. В матрице доступа в рамках этой статьи ресурсы будут представлять собой столбцы таблицы.

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

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

Матрица доступа

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

В рамках данной статьи условимся о следующих знаках:

•+ — наличие доступа, если бессмысленно говорить о его типе (например, в случае доступа в Интернет), а также полный доступ (чтение, запись, создание файла)

•R — доступ только на чтение

•M — доступ на чтение и запись, без возможности создания нового файла

Выстроив таким образом таблицу, мы сопоставляем мандаты с ресурсами и получаем эскиз политики безопасности.

Следующий этап — внедрение. Для этого следует мандаты интерпретировать в сущности используемой вами платформы — то есть расставить соответствующие права группам, настроить объекты групповых политик (если речь идет об Active Directory), создать списки доступа на маршрутизаторах, разнести пользователей по группам, присвоить им IP-адреса из соответствующих диапазонов и так далее. Конкретные шаги зависят от используемых платформ, оборудования, опыта системного администратора и т.п. Этот этап невозможно рассмотреть детально в этой статье — для этого потребовалась бы книга немалых объёмов.

Примеры

Я предвижу возглас читателя: «хватит умных слов, покажи на пальцах!» Извольте.

Краткое ТЗ в вольном стиле (как обычно излагает заказчик)

В компании имеются отделы:

•продаж

•сметный

•производственный

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

Руководству надо видеть всё. И опять же — своя папочка на сервере, чтоб никто не видел.

Что касается интернета — продажникам придётся разрешить всё, кроме видео. Руководству тоже. Сметчикам и инженерам на производстве надо запретить «одноклассники», «вконтакты» и прочую дребедень, видео. Хотя вот этому инженеру видео надо разрешить — он там какие-то технологические процессы смотрит. На кассе интернета вообще быть не должно. Бухгалтерии что-то запрещать — себе дороже выйдет, но стажёру тоже зарезать всё баловство.

Анализ и рассуждения

О мандатах. Мы можем явно выделить мандаты отделов, а также явно добавляется руководство. С бухгалтерией сложнее — там есть стажёр и не стажёры. Впрочем, для инженера в производственном отделе тоже надо предусмотреть мандат. Ещё неявно объявляется сам системный администратор. Для ограниченного доступа лучше выбирать низший общий уровень, а потом избирательно повышать. Таким образом для бухгалтерии у нас образуется три мандата: «бухгалтерия», «доступ к соцсетям» и «доступ к видео». Для производственников — «производство» и опять же «доступ к видео». Для кассы (относящейся к бухгалтерии) придётся снова сделать понижение уровня мандатов: бухгалтерии вообще отключаем интернет и вводим отдельный мандат «интернет». Руководству и системному администратору разделение доступа не нужно, для оптимизации мы можем ввести в матрицу отдельный ресурс.

О ресурсах. Хранилища отделов — очевидны. О доступе к интернету — у нас есть практически 5 вариантов: без интернета, интернет без соцсетей и видео, интернет без соцсетей, интернет без видео, и полный интернет. 5 вариантов можно уложить в 3 бита. Логично таким образом сделать интернет с ограничениями плюс два отдельных ресурса: соцсети и видео. В общем-то, некоторые ресурсы в данном примере выродились в отдельные мандаты, но зато мы их видим в общей картине.

Матрица доступа

image

Пример реализации: Active Directory + MikroTik

Создание доменных групп «Руководители», «Бухгалтерия», «Продажники» и «Сметчики» очевидно. Создание общих ресурсов на сервере или сетевом хранилище — тоже. Благодаря матрице мы сможем правильно расставить права доступа к общим ресурсам. Таким образом, главный бухгалтер будет иметь мандаты «Бухгалтерия», «Интернет», «Видео», а стажёр — только «Бухгалтерия» и «Интернет». «Исключительный» инженер на производстве — «Производство» и «Видео». При определённых обстоятельствах можно вообще напрямую отобразить мандаты на группы, и тогда понятие «имеет мандат» будет тождественно понятию «является членом группы».

На маршрутизаторе MikroTik можно пойти разными путями.

Можно использовать встроенный прокси-сервер (со своей системой контроля доступа) и сделать его принудительным для тех, у кого в мандате нет доступа к ресурсу «Неограниченный интернет». Можно использовать policy routing. Можно использовать фильтр пакетов 7-го уровня ISO/OSI. Можно просто заблокировать диапазоны IP-адресов вручную. Простор для фантазии неограничен.

Как определить, есть ли в мандате пользователя тот или иной доступ? Можно использовать DHCP-сервер для выдачи разным группам пользователей разных IP-адресов. Можно настроить IAS (в Windows Server 2008 — NPS) и авторизовывать пользователей для доступа в интернет через RADIUS. Опять многое зависит от того, каким путём вы будете решать эту задачу, что вам привычней, какие нюансы организационного устройства и оборудования придётся учесть. Но теперь у вас перед глазами схема: вот сюда надо дать доступ этим, а вот этим надо дать вот такие-то мандаты.

Пример реализации: Linux + MikroTik

Этот случай мало чем отличается от предыдущего, разве что использовать надо будет LDAP как таковой или при помощи 389 Directory Server. На уровне файловой системы в хранилище нужна поддержка ACL. Далее матрица подскажет, кому и что разрешить.

Впрочем, тут очень неплохим решением была бы ферма терминальных серверов и парк тонких клиентов, работающих по «голому» X11 (в локалке) или NX (если есть пользователи вне локальной сети). Хотя вот и Wayland на подходе…

Заключение

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

Даже если предприятие достаточно велико и запросы по системе безопасности высоки, построение матрицы доступа позволяет лучше понять и уложить в сознании задачу. А правильно и наглядно сформулированная задача — это зачастую более половины её решения.

Автор: m0Ray

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js