Сделайте безопасность простой: Упорядочивание политик в Unified SASEBalancing Configuration and Control is critical for reducing security risks and management complexity

Сервис Secure Access Service Edge (SASE) и связанная с ним архитектура представляют собой мощное объединение множества компонентов безопасности. К ним относятся брандмауэр с инспекцией по состоянию, система обнаружения и предотвращения вторжений (IDPS), защита DNS, защита от DoS/DDoS, безопасный веб-шлюз (SWG), Zero Trust Network Architecture (ZTNA), Cloud Access Security Broker (CASB) и многие другие. Эти компоненты дают администраторам возможность настраивать их с помощью политик, предлагая надежный щит для защиты активов организации от угроз при соблюдении определенных требований к доступу.

Роль конфигурации политики

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

1. Подход, основанный на единой таблице: Консолидированная таблица политик, содержащая огромное количество политик, которые охватывают управление угрозами и различные сценарии контроля доступа во всех компонентах SASE.
2. Многотабличный подход: Несколько таблиц политик, в каждой из которых рассматриваются такие специфические аспекты, как защита от угроз, контроль доступа, различные приложения и группы пользователей.

Соблюдение баланса в управлении политикой

Ожидания от SASE очевидны: он должен предлагать легко управляемые политики безопасности и упрощенные процедуры устранения неполадок. Для достижения этой цели необходим сбалансированный подход. Одна из эффективных стратегий, позволяющих снизить сложность политики в зависимости от требований организации. Более крупным организациям может потребоваться разделение с помощью многотабличного подхода, при котором гранулярность таблиц политики определяется на основе функций безопасности, ресурсов приложений и субъектов (пользователей/групп). Небольшие организации могут предпочесть разделение с меньшим количеством таблиц политик, сочетающих несколько типов контроля доступа или даже объединяющих защиту от угроз с контролем доступа. Такой гибкий подход минимизирует количество политик, требующих одновременного управления, делая их более управляемыми.

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

Понимание ключевых требований

Прежде чем углубиться в тонкости управления политиками, важно понять специфические требования, которые организации должны соблюдать в рамках системы SASE. Ключевые области включают:

Необходимость управления конфигурацией безопасности на основе ролей в средах SASE

Компоненты Secure Access Service Edge (SASE) обеспечивают комплексную безопасность, включающую защиту от угроз и контроль доступа к широкому спектру ресурсов различных организаций, включая их сотрудников, партнеров и гостей. В рамках этой системы безопасности организации часто имеют отдельные категории администраторов, отвечающих за различные аспекты безопасности.

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

Роли защиты от угроз:

• Конфигурация обнаружения вторжений и брандмауэра: Администраторы с ролью “threat-protection-ngfw-role” получают доступ к настройке параметров обнаружения вторжений и брандмауэра в среде SASE.
• Контроль репутации: Администраторы с ролью “threat-protection-reputation-role” могут управлять настройками, связанными с контролем IP-репутации, контролем репутации на основе URL, контролем репутации на основе домена, контролем репутации файлов, а также контролем репутации облачных сервисов и облачных организаций.
• Защита от вредоносного ПО: Администраторы с ролью “threat-protection-malware-protection-role” имеют право настраивать параметры, относящиеся именно к контролю защиты от вредоносного ПО.

Роли управления доступом:

• Конфигурация SWG: Администраторы, назначенные на роль “access-control-Internet-role”, отвечают за управление конфигурацией Secure Web Gateway (SWG).
• Контроль доступа для конкретных приложений SaaS: Такие роли, как “access-control-saas1app-role” и “access-control-saasNapp-role”, нацелены на настройку политик контроля доступа для конкретных приложений (SaaS Service 1 и SaaS Service N), обеспечивая тонкий контроль.
• Управление корпоративными приложениями: Такие роли, как “access-control-hostedapp1-role” и “access-control-hostedappM-role”, предназначены для работы с конфигурациями управления доступом для приложений корпоративного уровня, app1 и appM.

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

• Безопасность рабочей силы владельца: Администраторы с ролями “access-control-hostedappX-role” и “access-control-owner-workforce-role” совместно управляют конфигурациями контроля доступа к приложению “X” для рабочей силы владельца.
• Рабочий персонал для конкретного арендатора приложения: Такие роли, как “access-control-hostedAppX-role” и “access-control-owner-tenantA-workforce-role”, позволяют администраторам настраивать параметры контроля доступа для сотрудников арендатора A.
• Прикладная рабочая сила для арендатора B: Для многопользовательского приложения “X” различные роли, такие как “access-control-hostedAppX-role” и “access-control-owner-tenantB-workforce-role”, облегчают управление конфигурациями контроля доступа для сотрудников арендатора B.

Кроме того, даже многопользовательские корпоративные приложения могут потребовать отдельных администраторов для разных сегментов персонала. Например:

• Инженерный отдел: Администраторы с ролями “access-control-hostedappY-role” и “access-control-eng-role” занимаются управлением конфигурациями контроля доступа для приложения “Y” в инженерном отделе.
• Продажи и маркетинг: Такие роли, как “access-control-hostedappY-role” и “access-control-sales-role”, предназначены для настройки параметров контроля доступа для отделов продаж и маркетинга.
• Отдел информационных технологий: Администраторы с ролями “access-control-hostedappY-role” и “access-control-it-role” отвечают за конфигурации контроля доступа, относящиеся к отделу ИТ.

Значительным преимуществом управления конфигурацией безопасности на основе ролей является его способность обеспечить гранулярный контроль с учетом конкретных обязанностей. Сравните этот подход с проблемами, которые могут возникнуть при использовании единственной, всеобъемлющей таблицы политик:

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

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

Работайте вместе с Управлением контроля изменений конфигурации

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

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

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

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

Не все организации предъявляют одинаковые требования:

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

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

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

Избегайте запутанных конфигураций:

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

Однако важно понимать, что во время обработки трафика не все его атрибуты легко узнать. Например, в случае брандмауэров с функцией проверки состояния трафика можно извлечь только ограниченный набор значений трафика, например, информацию из 5 кортежей (IP-адрес источника, IP-адрес назначения, порт источника, порт назначения и IP-протокол). Между тем, для компонентов безопасности на основе прокси, таких как SWG, ZTNA и CASB, извлечение значений атрибутов может варьироваться и включать в себя различные этапы, в частности, этапы предварительной проверки TLS и последующей проверки TLS.

До проверки/расшифровки TLS многие атрибуты HTTP остаются неизвестными. Только после расшифровки TLS дополнительные атрибуты, такие как путь URI доступа, метод HTTP и заголовки запроса, становятся доступными для оценки.

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

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

Оптимизация таблиц запрещающих и разрешающих политик:

Некоторые решения по безопасности используют структуру, в которой они ведут отдельные таблицы политик “Запретить” и “Разрешить”. При такой настройке политики, определенные в списке “Запретить”, имеют приоритет и оцениваются в первую очередь. Если в таблице “Deny” не найдено ни одной подходящей политики, оценка переходит к таблице политик “Allow”. Однако такое разделение политик на две разные таблицы может создать проблемы для администраторов.

Мы решительно выступаем за более рациональный подход, при котором любая таблица политик представлена в виде упорядоченного списка политик. При такой схеме каждая политика явно указывает свое действие – будь то “Запретить”, “Разрешить” или любое другое желаемое действие. Во время обработки трафика оценка политики происходит в логической последовательности от политики с наивысшим приоритетом к политике с наименьшим приоритетом, пока не будет найдено совпадение. Как только будет определена соответствующая политика, к трафику будет применено соответствующее действие. В случаях, когда политика не совпадает, срабатывает действие по умолчанию, например, “fail open” или “fail close”, в соответствии с политикой безопасности организации.

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

Создание гибких и выразительных политик:

Как Вы уже поняли, администраторы разрабатывают политики, определяя наборы значений для соответствующих атрибутов. Традиционно существует общее понимание того, как работает согласование политик при оценке трафика: политика считается согласованной только тогда, когда все значения атрибутов, указанные в политике, полностью совпадают со значениями входящей сессии трафика. Эти значения могут быть получены непосредственно из трафика или выведены из контекстной информации, такой как контекст аутентифицированного пользователя и контекст устройства, ответственного за инициирование трафика. По сути, этот процесс сопоставления включает в себя операцию “И” по всем атрибутам политики.

Однако с развитием технологий безопасности многие устройства безопасности стали применять более гибкий подход, предоставляя администраторам возможность присваивать атрибутам несколько значений. В этой развитой парадигме соответствие устанавливается, если информация о контексте выполнения совпадает с любым из значений, указанных для атрибутов политики. По сути, процесс подбора теперь сочетает в себе операцию “И” для атрибутов и операцию “ИЛИ” для значений, связанных с этими атрибутами.

Организации могут извлечь значительную выгоду из такой гибкости при создании комплексной политики. Это уменьшает общее количество необходимых политик, сохраняя при этом читабельность. Однако эти многозначные атрибуты – лишь один шаг в правильном направлении, и для удовлетворения уникальных требований организаций часто требуются дополнительные усовершенствования:

Поддержка украшения “НЕ”: Администраторам требуется возможность определять значения атрибутов политики с оформлением “NOT”. Например, должно быть возможно указать значение атрибута ‘source IP’ как ‘NOT 10.1.5.0/24’, указывая, что политика будет успешно соответствовать, если IP-адрес источника трафика не принадлежит подсети 10.1.5.0/24.

Поддержка нескольких экземпляров атрибута: Многие традиционные устройства безопасности поддерживают только один экземпляр данного атрибута в рамках политики. Для создания комплексных политик очень важна возможность включать несколько экземпляров одного и того же атрибута в одну политику. Например, администратор может захотеть разрешить сеансы с любого IP-адреса в подсети 10.0.0.0/8 и одновременно запретить сеансы трафика из подсети 10.1.5.0/24. Этого можно достичь в рамках одной политики, возможно, указав значения ‘source IP’ дважды: “source IP == 10.0.0.0/8” и “source IP == NOT 10.1.5.0/24”. Это избавляет от необходимости создавать две отдельные политики и позволяет управлять политикой более интуитивно.

Поддержка украшений для значений строкового типа: Атрибуты, принимающие строковые значения, такие как пути URI, имена доменов и многие заголовки HTTP-запросов, выигрывают от использования таких украшений, как ‘exact’, ‘starts_with’ и ‘ends_with’. Эти украшения способствуют созданию экспрессивной политики.

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

Поддержка динамических атрибутов: В то время как традиционные атрибуты в политиках фиксированы и предопределены, в средах SASE иногда требуются динамические атрибуты. Рассмотрим заголовки запросов и ответов или требования JWT, где стандарты сосуществуют с многочисленными пользовательскими заголовками и требованиями. SASE должен предоставить администраторам возможность создавать политики, учитывающие пользовательские заголовки и утверждения. Например, SASE должна позволять создавать политики с заголовком запроса ‘X-custom-header’ в качестве атрибута и значением ‘matchme’. Во время трафика все HTTP-сессии с ‘X-custom-header’ в качестве одного из заголовков запроса и ‘matchme’ в качестве значения должны соответствовать этой политике.

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

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

Улучшение интеграции политики с помощью модификаций трафика

Определенные функции безопасности требуют изменения трафика, причем наиболее распространенные случаи включают добавление, удаление или изменение заголовков HTTP-запросов/ответов и их значений, параметров запроса и их значений, и даже тела запроса/ответа. Эти модификации могут значительно отличаться в зависимости от конфигурации администратора. Часто конкретные модификации зависят от параметров трафика, таких как целевое приложение/сервис сайта, а также от контекстной информации, доступной во время выполнения трафика.

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

Одним из основных сценариев, в котором модификация трафика имеет большое значение, является использование решений Cloud Access Security Broker (CASB), особенно когда организации требуют ограничения многопользовательского доступа. Эти ограничения часто включают в себя добавление специальных заголовков запросов и значений, чтобы обеспечить соблюдение специфических для сотрудничества политик. Кроме того, есть и другие случаи, например, добавление пользовательских заголовков для сквозного поиска неисправностей и анализа производительности, когда модификация трафика играет решающую роль.

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

Улучшение наблюдаемости:

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

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

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

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

SASE-подход к управлению политикой:

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

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

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

1. Модульное управление политиками: Решения SASE включают в себя множество функций безопасности, каждая из которых имеет свой собственный набор настроек политики. Эти конфигурации должны включать в себя опции включения/выключения, установки действий по умолчанию в случае отсутствия совпадения политик, управления коллекцией нескольких таблиц политик, определения нескольких политик в каждой таблице политик, создания упорядоченного списка политик, а также установки параметров действий, объектов модификации, атрибутов совпадения и значений для каждой политики.
2. Цепочка политик: Чтобы обеспечить более конкретные и детализированные политики, решения SASE должны поддерживать цепочки политик. Это означает возможность расположения политик в нескольких таблицах политик в коллекции. Например, организации могут иметь отдельные таблицы политик для различных приложений, при этом политики главной таблицы будут использовать имена приложений/доменов в качестве критериев соответствия для выбора соответствующих таблиц политик. Обычно это достигается с помощью политик с действием ‘Jump’, которое перенаправляет оценку политики в таблицу политик, на которую ссылаются. Концепция цепочки политик приобрела популярность в Linux IPTables, и многие решения по безопасности впоследствии включили в себя эту функциональность.

Функции безопасности в рамках SASE могут быть самыми разнообразными и включать в себя:

• NGFW (межсетевой экран следующего поколения): Обеспечение контроля доступа L3/L4, защита от DDoS, IP-репутация, репутация домена и система обнаружения и предотвращения вторжений (IDPS).
• SWG (Secure Web Gateway): Предлагает проверку TLS, контроль веб-доступа до TLS, контроль веб-доступа после TLS, репутацию URL, репутацию файлов и защиту от вредоносного ПО.
• ZTNA (Zero Trust Network Access): Похоже на SWG, но сфокусировано на защите размещенных приложений.
• CASB (Cloud Access Security Broker): Охватывает репутацию облачных сервисов и контроль доступа к облачным сервисам.
• DLP (Data Loss Prevention): Реализация контроля доступа на основе персонально идентифицируемой информации (PII), стандартных конфиденциальных документов и конфиденциальных документов, специфичных для предприятия.

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

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

• Консолидация всех настроек функций безопасности до TLS в единую коллекцию таблиц политик в нескольких компонентах SWG/ZTNA.
• Консолидация всех настроек функций безопасности после TLS в единую коллекцию таблиц политик в нескольких компонентах SWG/ZTNA.
• Сохраните функции CASB, защиты от вредоносного ПО и DLP как отдельные подразделения, поскольку они требуют сложных определений политик.
• Выбор одной таблицы политик в коллекции таблиц политик, что позволяет избежать цепочки политик.

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

Баланс между удобством использования и гибкостью, ориентированной на будущее

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

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

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

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

• Блог CTO Insights

  Серия блогов Aryaka CTO Insights предлагает идейное лидерство по темам сети, безопасности и SASE. Технические характеристики продуктов Aryaka см. в “Листах данных Aryaka”.

The post Сделайте безопасность простой: Упорядочивание политик в Unified SASE<h5><i>Balancing Configuration and Control is critical for reducing security risks and management complexity</i></h5> appeared first on Aryaka.

*** This is a Security Bloggers Network syndicated blog from Srini Addepalli, Author at Aryaka authored by Srini Addepalli. Read the original post at: https://www.aryaka.com/blog/%D1%81%D0%B4%D0%B5%D0%BB%D0%B0%D0%B9%D1%82%D0%B5-%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D1%8C-%D0%BF%D1%80%D0%BE%D1%81%D1%82%D0%BE%D0%B9-%D1%83%D0%BF%D0%BE%D1%80%D1%8F/