С контролем доступа к ресурсам сети (например, файловым) все
просто - есть пользователи, есть ресурсы, устанавливаем права доступа на уровне
ресурса и готово. Но как обстоят дела с контролем доступа на уровне
устройств? Как сделать так, чтобы доступ определялся и на уровне пользователя,
и на уровне устройства, с которого осуществляется подключение? Далее опишу
подходы, позволяющие снизить вероятность подключения к ресурсам организации
с не доверенных узлов.
Прежде конкретизируем задачу: внутри локальной сети сервера
с ресурсами и рабочие места пользователей. Важно, чтобы доступ к ресурсам
пользователи получали только с доменных компьютеров (части компьютеров), на
которые установлены средства защиты и контроля. Речь о внутренней
инфраструктуре и средства межсетевого экранирования уровня сети не
рассматриваем.
Хорошо если контролируешь инфраструктуру на физическом
уровне, это позволяет частично снизить вероятность появления не
доверенных устройств организационными мерами. Но доверять только
физическим и организационным мерам не стоит, да и бывают ситуации, когда
инфраструктура полностью или в какой-то части находится вне физического и
сетевого контроля. Например, совместное использование кабельной сети и
коммутационного оборудования с другими организациями в рамках инфраструктуры
бизнес-центра или использование беспроводной сети.
Итак, как контролировать доступ c
устройств техническими мерами:
Взаимодействие только с сетевой инфраструктурой:
1. Port security
Базовая защитная мера уровня коммутационного оборудования,
заключающаяся в ограничении доступа в сеть в зависимости от MAC адреса
устройства. Входит в Топ 30 мер по защите коммутационного оборудования.
Недостатки: мера малоэффективна и является скорее
защитой от дурака случайных нарушений, т.к. подделка MAC адреса задача тривиальная.
Условия внедрения: наличие контроля над коммутационным
оборудованием, наличие требуемых функций на оборудовании.
Взаимодействие с серверной и сетевой инфраструктурой:
2. 802.1x / NAC
Если все коммутационное оборудование под контролем, то
возможно развертывание инфраструктуры 802.1x на базе RADIUS сервера или
технологии Network Access Control (у Microsoft
это роль Network Policy Server c компонентом Network Access Protection (NAP).
Решение позволяет осуществлять предварительную авторизацию устройств и
назначение им IP/VLAN в зависимости от результатов проверки. В случае
успешного внедрения получаем возможность динамически размещать узлы по VLAN и
проводить разноплановые проверки подключаемых узлов, например - наличие и актуальность
антивирусного ПО или межсетевого экрана.
Недостатки: относительная сложность настройки, необходимость
развертывания отдельного сервера авторизации, отсутствие возможности настройки
специфичных проверок штатными средствами.
Взаимодействие только с серверной инфраструктурой:
3. Microsoft Dynamic Access control
Решение, полностью решающее задачу контроля доступа с
устройств к файловым ресурсам. Начиная с MS Windows Server 2012 для управления
доступом к ресурсам могут использоваться реквизиты (clames)
и пользователя, и компьютера, с которого осуществляется подключение. Достаточно
определить политику, устанавливающую одним из требований на доступ к файловым
ресурсам наличие компьютера, с которого осуществляется доступ, в нужной группе
службы каталогов. Доступ на основе клэйма компьютера это не главное
преимущество технологии динамического контроля доступа, но для
решения нашей задачи оно ключевое. Для погружения в вопрос рекомендую это
видео.
Главное ограничение, которое ставит крест на внедрении этого
решения в большинстве инфраструктур в том, что клэймы устройств работают только
если клиентом выступает ОС Windows 10 и выше.
Если исходными данными является инфраструктура, полностью
построенная на Windows 10, то это решение однозначно не стоит обходить
стороной.
Так же к недостаткам можно отнести возможность настройки
доступа только к файловым ресурсам, защитить таким образом доступ к ресурсам на
других протоколах не удастся. (Хотя тут могу и ошибаться, т.к. до промышленного
внедрения по причине первого ограничения не дошел)
4. IPSec
Есть достаточно элегантное решение, заключающееся в
настройке доступа к ключевым серверам организации по IPSec. В данном случае мы
используем IPSec не по прямому назначению для создания VPN подключений, а
применяем его для ограничения доступа между узлами одной сети.
 |
| Схема контроля доступа на базе IPSec |
Настройка осуществляется через групповые политики,
которые применяются на сервера и рабочие станции, с которых нужен доступ. В результате только компьютеры, на которых политика была
применена (а это могут быть не все доменные компьютеры, а только группа
компьютеров) будут иметь доступ к ключевым серверам, остальные же узлы просто
не смогут установить соединение с сервером.
Если мы защищаем конкретный сервис (например, файловую шару,
БД, Web-сервис) то и переводить на IPSec будем только порты защищаемого
протокола, а не все соединения с сервером, что снизит нагрузку на сеть и
оборудование.
Так же, если защита от перехвата трафика в задачах не стоит,
то IPSec достаточно настроить в режиме контроля целостности по MD5, а
шифрование отключить, что еще больше снизит нагрузку.
Применение групповой политики должно осуществляться
одномоментно на сервер и все компьютеры, которым необходимо подключение. Если
политика на компьютер не применена, доступа к серверу не будет.
Без взаимодействия с инфраструктурой:
5. Скрипты
Если вносить изменения в сетевую
или северную инфраструктуру нет возможности, то можно решить задачу
путем анализа успешных подключений к серверам скриптом со следующим алгоритмом:
- Проверка логов контроллера домена (или файлового сервера) на предмет событий авторизации пользователя;
- Выделение из событий авторизации имени компьютера, с которого подключился пользователь;
- Попытка подключиться к этому компьютеру по протоколам SMB (CIFS) или WMI. Если подключение не удалось - значит узел не входит в домен (или у него проблемы с доступом, что тоже не порядок).
- Реагирование на нарушение: занесение информации о проблемных узлах в лог скрипта, уведомление администратора безопасности, отключение учетной записи
6 Сканирование
Наиболее распространенное и простое решение, заключающееся в
использовании любого сетевого сканера. В случае использования наиболее
продвинутых вариантов возможно максимально автоматизировать процесс выявления
новых или не соответствующих требованиям устройств и снизить временные затраты.
Отсутствие необходимости интеграции с серверной и сетевой инфраструктурой
упрощает внедрение данного решения.
В качестве недостатка следует отметить время, так как любой
анализ будет ретроспективен, а также невозможность активного противодействия
доступу с не доверенных устройств.
Резюме
Выбор подходящего решения на прямую зависит от архитектуры
защищаемой инфраструктуры, от компетенции персонала, а также соотношения
затрат на внедрение к критичности защищаемых ресурсов.
Решений много, надеюсь варианты,
описанные выше, будет полезны. В свою очередь, если сталкивались с иным
решением, прошу написать в комментариях.
Комментариев нет:
Отправить комментарий