вторник, 14 февраля 2017 г.

6 способов контроля доступа устройств к ресурсам сети

С контролем доступа к ресурсам сети (например, файловым) все просто - есть пользователи, есть ресурсы, устанавливаем права доступа на уровне ресурса и готово. Но как обстоят дела с контролем доступа на уровне устройств? Как сделать так, чтобы доступ определялся и на уровне пользователя, и на уровне устройства, с которого осуществляется подключение? Далее опишу подходы, позволяющие снизить вероятность подключения к ресурсам организации с не доверенных узлов.

Прежде конкретизируем задачу: внутри локальной сети сервера с ресурсами и рабочие места пользователей. Важно, чтобы доступ к ресурсам пользователи получали только с доменных компьютеров (части компьютеров), на которые установлены средства защиты и контроля. Речь о внутренней инфраструктуре и средства межсетевого экранирования уровня сети не рассматриваем.

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

Итак, как контролировать доступ 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
Схема контроля доступа на базе IPSec
Настройка осуществляется через групповые политики, которые применяются на сервера и рабочие станции, с которых нужен доступ. В результате только компьютеры, на которых политика была применена (а это могут быть не все доменные компьютеры, а только группа компьютеров) будут иметь доступ к ключевым серверам, остальные же узлы просто не смогут установить соединение с сервером.

Если мы защищаем конкретный сервис (например, файловую шару, БД, Web-сервис) то и переводить на IPSec будем только порты защищаемого протокола, а не все соединения с сервером, что снизит нагрузку на сеть и оборудование.

Так же, если защита от перехвата трафика в задачах не стоит, то IPSec достаточно настроить в режиме контроля целостности по MD5, а шифрование отключить, что еще больше снизит нагрузку.

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

Без взаимодействия с инфраструктурой:


5. Скрипты

Если вносить изменения в сетевую или северную инфраструктуру нет возможности, то можно решить задачу путем анализа успешных подключений к серверам скриптом со следующим алгоритмом:
  • Проверка логов контроллера домена (или файлового сервера) на предмет событий авторизации пользователя;
  • Выделение из событий авторизации имени компьютера, с которого подключился пользователь;
  • Попытка подключиться к этому компьютеру по протоколам SMB (CIFS) или WMI. Если подключение не удалось - значит узел не входит в домен (или у него проблемы с доступом, что тоже не порядок).
  • Реагирование на нарушение: занесение информации о проблемных узлах в лог скрипта, уведомление администратора безопасности, отключение учетной записи
Подобное решение удобно с точки зрения кастомизации и объединения с другими скриптами, например с автоматизированной матрицей доступа или автоматическими поэтажными планами. При этом, как и любое собственное решение оно требует значительного времени на разработку и наладку.


 6 Сканирование

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

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

Резюме


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

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

Комментариев нет:

Отправить комментарий