WikiDer > Программно определяемый периметр

Software Defined Perimeter

Программно определяемый периметр (SDP), также называемый "Черное облако", это подход к компьютерная безопасность которые возникли в результате работы, проделанной на Агентство оборонных информационных систем (DISA) под Глобальная информационная сеть (GIG) Инициатива Black Core Network примерно в 2007 году.[1] Фреймворк программно определяемого периметра (SDP) был разработан Альянс облачной безопасности (CSA) для управления доступом к ресурсам на основе идентичности. Связь в программно определяемом периметре основана на нужно знать модель, в которой состояние и идентичность устройства проверяются перед предоставлением доступа к инфраструктуре приложения.[2] Инфраструктура приложений фактически «черная» (термин DoD означает, что инфраструктура не может быть обнаружена), без видимых DNS информация или IP-адреса.[сомнительный – обсуждать] Создатели этих систем утверждают, что программно определяемый периметр смягчает наиболее распространенные сетевые атаки, в том числе: сканирование сервера, отказ в обслуживании, SQL-инъекция, уязвимость операционной системы и приложения подвиги, человек посередине, передать хеш, проходной билет, и другие атаки неавторизованных пользователей.[3]

Фон

Предпосылка традиционной архитектуры корпоративной сети состоит в создании внутренней сети, отделенной от внешнего мира фиксированным периметром, который состоит из ряда функций межсетевого экрана, которые блокируют вход внешних пользователей, но позволяют внутренним пользователям выйти.[4] Традиционные фиксированные периметры помогают защитить внутренние службы от внешних угроз с помощью простых методов блокировки видимости и доступности внутренних приложений и инфраструктуры за пределами периметра. Но слабые места этой традиционной модели фиксированного периметра становятся все более проблематичными из-за популярности управляемые пользователем устройства и фишинг атаки, обеспечивающие ненадежный доступ внутри периметра, и SaaS и IaaS расширение периметра в Интернет.[5] Программно определяемые периметры решают эти проблемы, предоставляя владельцам приложений возможность развертывать периметры, которые сохраняют ценность традиционной модели, заключающуюся в невидимости и недоступности для посторонних, но могут быть развернуты где угодно - в Интернете, в облаке, в центре хостинга, в частном секторе. корпоративной сети или в некоторых или во всех этих местах.[2]

Архитектура

В простейшем виде архитектура SDP состоит из двух компонентов: SDP Хосты и контроллеры SDP. [6] Хосты SDP могут либо инициировать соединения, либо принимать соединения. Эти действия управляются посредством взаимодействия с контроллерами SDP через канал управления (см. Рисунок 1). Таким образом, в программно определяемом периметре плоскость управления отделена от плоскости данных для обеспечения большей масштабируемости. Кроме того, все компоненты могут быть избыточными для повышения доступности.

Рисунок 1. Архитектура программно определяемого периметра состоит из двух компонентов: хостов SDP и контроллеров SDP.

Структура SDP имеет следующий рабочий процесс (см. Рисунок 2).

  1. Один или несколько контроллеров SDP переводятся в оперативный режим и подключаются к соответствующим дополнительным службам аутентификации и авторизации (например, PKI, идентификация устройства, геолокация, SAML, OpenID, OAuth, LDAP, Kerberos, многофакторная аутентификация и другие подобные службы).
  2. Один или несколько принимающих хостов SDP переведены в онлайн. Эти хосты подключаются к контроллерам и проходят аутентификацию. Однако они не подтверждают связь с каким-либо другим Хостом и не будут отвечать ни на какие не предоставленные запросы.
  3. Каждый инициирующий хост SDP, подключенный к сети, подключается к контроллерам SDP и аутентифицируется с ними.
  4. После аутентификации инициирующего хоста SDP контроллеры SDP определяют список принимающих хостов, с которыми инициирующий хост авторизован для связи.
  5. Контроллер SDP инструктирует принимающие хосты SDP принимать сообщения от инициирующего хоста, а также любые дополнительные политики, необходимые для зашифрованной связи.
  6. Контроллер SDP предоставляет инициирующему хосту SDP список принимающих хостов, а также любые дополнительные политики, необходимые для зашифрованной связи.
  7. Инициирующий хост SDP инициирует взаимное VPN-соединение со всеми авторизованными принимающими хостами.
Рисунок 2: Рабочий процесс архитектуры программно определяемого периметра
Модели развертывания SDP

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

Клиент-шлюз

В реализации «клиент-шлюз» один или несколько серверов защищены за принимающим хостом SDP, так что принимающий хост SDP действует как шлюз между клиентами и защищенными серверами. Эта реализация может использоваться внутри корпоративной сети для смягчения распространенных атак с боковым перемещением, таких как сканирование серверов, эксплойты уязвимостей ОС и приложений, взлом паролей, «человек посередине», Pass-the-Hash (PtH) и другие.[6][7][8] В качестве альтернативы он может быть реализован в Интернете для изоляции защищенных серверов от неавторизованных пользователей и смягчения атак, таких как отказ в обслуживании, эксплойты уязвимостей ОС и приложений, взлом паролей, человек посередине и другие.[9][10]

Клиент-сервер

Реализация клиент-сервер аналогична по функциям и преимуществам реализации клиент-шлюз, описанной выше. Однако в этом случае на защищаемом сервере будет работать программа Accepting SDP Host, а не шлюз, расположенный перед сервером, на котором запущено это программное обеспечение. Выбор между реализацией «клиент-шлюз» и реализацией «клиент-сервер» обычно основывается на количестве защищаемых серверов, методологии балансировки нагрузки, эластичности серверов и других подобных топологических факторах. [13]

Сервер-сервер

В реализации сервер-сервер серверы, предлагающие службу передачи репрезентативного состояния (REST), службу протокола простого доступа к объектам (SOAP), удаленный вызов процедуры (RPC) или любой интерфейс прикладного программирования (API) через Интернет может быть защищен от неавторизованных хостов в сети. Например, в этом случае сервер, инициирующий вызов REST, будет инициирующим хостом SDP, а сервер, предлагающий службу REST, будет принимающим хостом SDP. Реализация SDP для этого варианта использования может снизить нагрузку на эти службы и смягчить атаки, аналогичные тем, которые смягчаются реализацией «клиент-шлюз».

Клиент-сервер-клиент

Реализация клиент-сервер-клиент приводит к одноранговым отношениям между двумя клиентами и может использоваться для таких приложений, как IP-телефон, чат и видеоконференцсвязь. В этих случаях SDP скрывает IP-адреса подключающихся клиентов. В качестве незначительного изменения, пользователь может также иметь конфигурацию «клиент-шлюз-клиент», если пользователь также хочет скрыть сервер приложений.

Приложения SDP

Изоляция корпоративных приложений

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

Частное облако и гибридное облако

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

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

Поставщики инфраструктуры как услуги (IaaS) могут предлагать своим клиентам услугу SDP как услугу в качестве защищенного перехода. Это позволяет их клиентам воспользоваться преимуществами гибкости и экономии средств IaaS, уменьшая при этом широкий спектр потенциальных атак.

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

К Интернету подключается огромное количество новых устройств.[12] Внутренние приложения, которые управляют этими устройствами и / или извлекают информацию с этих устройств, могут быть критически важными и могут выступать в качестве хранителя личных или конфиденциальных данных. SDP можно использовать для сокрытия этих серверов и взаимодействия с ними через Интернет, чтобы обеспечить повышенную безопасность и время безотказной работы. [13]

Смотрите также

Рекомендации

  1. ^ Архитектурное видение глобальной информационной сети Министерства обороны США. 2007. С. 28–30.
  2. ^ а б «Программно определяемый периметр». Альянс облачной безопасности. Получено 29 января 2014.
  3. ^ Gartner, Market Guide for Zero Trust Access. «Руководство Gartner SDP». gartner.com.
  4. ^ Барри, Сосинский (май 2004 г.). «Периметральные сети». Поисковая сеть. Получено 30 января 2014.
  5. ^ Вагнер, Рэй; Рэй Вагнер; Келли М. Кавана; Марк Николетт; Антон Чувакин; Эндрю Уоллс; Иосиф Фейман; Лоуренс Оранс; Ян Кин (25 ноября 2013 г.). «Прогнозы на 2014 год: защита инфраструктуры». Gartner. Получено 19 февраля 2014.
  6. ^ МакКлюр, Стюарт (11 июля 2012 г.). Взлом раскрыл 7 секретов сетевой безопасности и решений. Макгроу Хилл. ISBN 0071780289.
  7. ^ Micro, Trend. «ПОБОЧНОЕ ДВИЖЕНИЕ: как субъекты угроз проникают глубже в вашу сеть?». Trend Micro. Получено 19 февраля 2014.
  8. ^ «Отчет о расследовании утечки данных». Verizon. Получено 19 февраля 2014.
  9. ^ «Полугодовой отчет о тенденциях и рисках IBM X-Force 2012». IBM X-Force Исследования и разработки. Получено 19 февраля 2014.
  10. ^ «Отчет о глобальной информации об угрозах». Решение. Получено 19 февраля 2014.
  11. ^ Мубайед, Абдаллах; Рефей, Ахмед; Шами, Абдалла (октябрь 2019 г.). «Программно-определяемый периметр (SDP): современное безопасное решение для современной сети». Сеть IEEE.
  12. ^ Миддлтон, Питер; Кьельдсен, Питер; Талли, Джим (18 ноября 2013 г.). «Прогноз: Интернет вещей во всем мире, 2013 г.». Gartner (G00259115). Получено 29 января 2014.
  13. ^ Рефей, Ахмед; Саллам, Ахмед; Шами, Абдалла (октябрь 2019 г.). «В приложениях IoT: предлагаемая структура SDP для MQTT». Письма об электронике.

внешняя ссылка