Simplifique a segurança: Simplifique as políticas no Unified SASE

O serviço Secure Access Service Edge (SASE), juntamente com sua arquitetura associada, compreende um poderoso amálgama de vários componentes de segurança.
Esses componentes incluem um firewall de inspeção com estado, um sistema de detecção e prevenção de intrusões (IDPS), segurança de DNS, proteção contra DoS/DDoS, Secure Web Gateway (SWG), Zero Trust Network Architecture (ZTNA), Cloud Access Security Broker (CASB) e muitos outros.
Esses componentes concedem aos administradores a capacidade de configurá-los por meio de políticas, oferecendo um escudo robusto para proteger os ativos de uma organização contra ameaças e, ao mesmo tempo, aderir a requisitos de acesso específicos.

O papel da configuração de políticas

A configuração de políticas desempenha um papel indispensável na aplicação da segurança dentro da estrutura do SASE.
As repercussões de políticas mal configuradas podem variar de ameaças a recursos e vazamentos de dados a acessos não intencionais e excessivamente permissivos.
No cenário atual do setor, as organizações lidam com duas abordagens predominantes para o gerenciamento de políticas de segurança:

1. A abordagem de tabela única: Uma tabela de políticas consolidada que contém uma infinidade de políticas que abrangem o gerenciamento de ameaças e vários cenários de controle de acesso em todos os componentes do SASE.
2. A abordagem de várias tabelas: Várias tabelas de políticas, cada uma abordando aspectos específicos, como proteção contra ameaças, controle de acesso, diferentes aplicativos e grupos de usuários.

Equilíbrio no gerenciamento de políticas

A expectativa da SASE é clara: ela deve oferecer políticas de segurança facilmente gerenciáveis e procedimentos simplificados de solução de problemas.
Para atingir esse objetivo, é necessária uma abordagem equilibrada.
Uma estratégia eficaz para reduzir a complexidade da política baseia-se nos requisitos da organização.
As organizações maiores podem exigir a compartimentalização com a abordagem de várias tabelas, em que a granularidade da tabela de políticas é definida com base nas funções de segurança, nos recursos do aplicativo e no assunto (usuários/grupos).
As organizações menores podem preferir a compartimentalização com um número menor de tabelas de políticas, combinando vários tipos de controles de acesso ou até mesmo combinando a proteção contra ameaças com o controle de acesso.
Essa abordagem flexível minimiza o número de políticas que exigem gerenciamento simultâneo, tornando-as mais gerenciáveis.
Entretanto, é importante ter cuidado para evitar a compartimentalização excessiva, que pode introduzir seu próprio conjunto de desafios.
Os administradores podem acabar navegando em várias tabelas de políticas para identificar e resolver problemas, o que pode causar atrasos na resolução.

Entendendo os principais requisitos

Antes de se aprofundar nas complexidades do gerenciamento de políticas, é fundamental entender os requisitos específicos que as organizações devem atender dentro da estrutura SASE.
As principais áreas incluem:

Necessidade de gerenciamento de configuração de segurança com base em função em ambientes SASE

Os componentes do Secure Access Service Edge (SASE) oferecem segurança abrangente, englobando proteção contra ameaças e controle de acesso para uma ampla gama de recursos em diversas organizações, incluindo sua força de trabalho, parceiros e convidados.
Dentro dessa estrutura de segurança, as organizações geralmente têm categorias distintas de administradores responsáveis por diferentes aspectos da segurança.
Por exemplo, uma organização pode ter um grupo de administradores dedicado a gerenciar a proteção contra ameaças, enquanto outro grupo se concentra nos controles de acesso.
Dentro dessas categorias amplas, é comum que as organizações estabeleçam várias funções administrativas adaptadas a tipos específicos de proteção contra ameaças e controle de acesso.
Vamos nos aprofundar em alguns exemplos práticos:

Funções de proteção contra ameaças:

• Configuração de detecção de intrusão e firewall: Os administradores com a função “threat-protection-ngfw-role” têm acesso para configurar as definições de detecção de intrusão e firewall no ambiente SASE.
• Controles de reputação: Os administradores com a função “threat-protection-reputation-role” podem gerenciar configurações relacionadas a controles de reputação de IP, controles de reputação baseados em URL, controles de reputação baseados em domínio, controles de reputação de arquivos, bem como controles de reputação de serviços e organizações de nuvem.
• Proteção contra malware: Os administradores com a função “threat-protection-malware-protection-role” têm autoridade para definir configurações especificamente relacionadas aos controles de proteção contra malware.

Funções de controle de acesso:

• Configuração do SWG: Os administradores designados como “access-control-Internet-role” são responsáveis por gerenciar as configurações do Secure Web Gateway (SWG).
• Controle de acesso específico a aplicativos SaaS: Funções como “access-control-saas1app-role” e “access-control-saasNapp-role” concentram-se na configuração de políticas de controle de acesso para aplicativos específicos (SaaS Service 1 e SaaS Service N), garantindo um controle refinado.
• Gerenciamento de aplicativos corporativos: Funções como “access-control-hostedapp1-role” e “access-control-hostedappM-role” são dedicadas a lidar com configurações de controle de acesso para aplicativos de nível empresarial, app1 e appM.

Nos casos em que uma organização usa aplicativos multilocatários, podem ser introduzidas funções adicionais para gerenciar as configurações de segurança de forma eficaz.
Por exemplo, podem ser estabelecidas funções para configurar políticas para a força de trabalho da organização, para a força de trabalho por locatário e até mesmo para convidados.
Considere um aplicativo “X” com configurações de segurança gerenciadas por diferentes conjuntos de administradores:

• Segurança da força de trabalho do proprietário: Os administradores com “access-control-hostedappX-role” e “access-control-owner-workforce-role” colaboram para gerenciar as configurações de controle de acesso do aplicativo “X” para a força de trabalho do proprietário.
• Força de trabalho específica do locatário do aplicativo para o locatário: Funções como “access-control-hostedAppX-role” e “access-control-owner-tenantA-workforce-role” permitem que os administradores definam as configurações de controle de acesso para a força de trabalho do locatário A.
• Força de trabalho específica do locatário do aplicativo para o locatário B: Para um aplicativo “X” de vários locatários, várias funções, como “access-control-hostedAppX-role” e “access-control-owner-tenantB-workforce-role”, facilitam o gerenciamento das configurações de controle de acesso para a força de trabalho do locatário B.

Além disso, mesmo os aplicativos corporativos não multilocatários podem exigir administradores separados para diferentes segmentos da força de trabalho.
Por exemplo:

• Departamento de engenharia: Os administradores com “access-control-hostedappY-role” e “access-control-eng-role” concentram-se em gerenciar as configurações de controle de acesso para o aplicativo “Y” no departamento de engenharia.
• Vendas e marketing: Funções como “access-control-hostedappY-role” e “access-control-sales-role” são designadas para definir as configurações de controle de acesso para as equipes de vendas e marketing.
• Departamento de TI: Os administradores com “access-control-hostedappY-role” e “access-control-it-role” são responsáveis pelas configurações de controle de acesso pertencentes ao departamento de TI.

Uma vantagem significativa do gerenciamento de configuração de segurança baseado em funções é sua capacidade de fornecer controle granular adaptado a responsabilidades específicas.
Compare essa abordagem com os desafios que podem surgir quando se usa uma tabela de políticas única e abrangente:

• Propenso a erros: Vários administradores trabalhando com a mesma tabela de políticas e com permissões sobrepostas podem inadvertidamente introduzir erros ao adicionar, excluir ou modificar políticas.
• Complexidade na solução de problemas: A resolução de problemas em uma tabela de políticas monolítica pode ser demorada e desafiadora.
• Sobrecarga de políticas: A consolidação de todas as políticas em uma única tabela, abrangendo vários aplicativos e cenários de proteção contra ameaças, pode levar a uma experiência de gerenciamento de políticas complicada e difícil de manejar, além de possíveis desafios de desempenho durante a avaliação de políticas.

Em conclusão, a adoção do gerenciamento de configuração de segurança baseado em funções em ambientes SASE permite que as organizações deleguem responsabilidades com eficiência, aumentem a segurança e simplifiquem o gerenciamento de políticas, evitando as complexidades associadas às abordagens de tabela única.

Trabalhar em conjunto com o Gerenciamento de controle de alterações de configuração

As organizações estão adotando cada vez mais o gerenciamento de controle de alterações para todas as configurações, inclusive a configuração SASE, para detectar e retificar proativamente os erros de configuração antes que eles sejam implementados.
Essa prática não serve apenas como proteção, mas também introduz uma camada secundária de escrutínio, permitindo que um segundo grupo de pessoas analise e aprove as configurações antes que elas entrem em vigor.
As configurações da política de segurança são aplicadas diretamente no fluxo de tráfego, o que faz com que qualquer erro nas políticas possa interromper os serviços e incorrer em consequências financeiras diretas.
Para lidar com a complexidade inerente à configuração da política de segurança, é prática comum serializar as alterações.
Isso significa que, ao modificar um tipo de configuração, nenhuma outra sessão de configuração do mesmo tipo é iniciada até que a anterior seja aplicada ou revogada.
No entanto, ao usar uma única tabela de políticas que engloba todas as funções de controle de acesso e ameaças, a serialização das alterações pode introduzir atrasos nos ajustes de configuração realizados por outros administradores.
Por outro lado, uma abordagem de várias tabelas pode resolver esse cenário com eficácia, permitindo que diferentes administradores trabalhem simultaneamente em tabelas distintas, agilizando assim o processo de alteração da configuração.

Nem todas as organizações têm os mesmos requisitos:

Normalmente, o SASE é oferecido como um serviço, e os provedores de SASE podem atender a várias organizações como clientes.
Essas organizações podem variar significativamente em termos de tamanho, requisitos regulamentares e diversidade de funções em suas estruturas.
Algumas organizações podem hospedar vários aplicativos, seja no local ou na nuvem, enquanto outras podem depender exclusivamente de serviços de provedores de SaaS, e algumas podem incorporar uma combinação de ambos.
Além disso, algumas organizações talvez não precisem de várias funções administrativas ou de vários usuários administrativos.
Em cenários em que as organizações têm apenas um número limitado de aplicativos e não têm a complexidade de várias funções administrativas, elas podem achar vantajoso usar menos tabelas de políticas.
Espera-se que o SASE seja projetado para oferecer a flexibilidade necessária para acomodar essas diversas necessidades, incluindo a opção de usar tabelas de políticas consolidadas para várias funções e aplicativos de segurança relevantes.

Evitar configurações confusas:

Algumas soluções SASE, em sua busca pela simplificação, conforme discutido anteriormente, optam por uma tabela de políticas única e abrangente, na qual as políticas podem ser configuradas com valores para vários atributos correspondentes.
Durante o processamento do tráfego, a seleção de políticas se baseia na correspondência dos valores do tráfego de entrada e de outras informações contextuais com os valores de atributos especificados nas políticas.
Entretanto, é fundamental reconhecer que, durante o processamento do tráfego, nem todos os atributos do tráfego são prontamente conhecidos.
Por exemplo, no caso de firewalls de inspeção com estado, somente um conjunto limitado de valores de tráfego pode ser extraído, como as informações de 5 tuplas (IP de origem, IP de destino, porta de origem, porta de destino e protocolo IP).
Enquanto isso, para componentes de segurança baseados em proxy, como SWG, ZTNA e CASB, a extração de valores de atributos pode variar e envolver estágios distintos, principalmente as fases de inspeção pré-TLS e pós-TLS.
Antes da inspeção/descriptografia TLS, muitos atributos HTTP permanecem desconhecidos.
Somente após a descriptografia do TLS é que atributos adicionais, como o caminho do URI de acesso, o método HTTP e os cabeçalhos de solicitação, ficam disponíveis para avaliação.
Como administradores responsáveis pela configuração das políticas de segurança, é impraticável esperar que os administradores controlem quais atributos são válidos em vários estágios do processamento de pacotes enquanto definem as políticas.
Embora algumas soluções de segurança afirmem que atributos irrelevantes não são considerados na avaliação da política, determinar quais atributos são pertinentes e quais não são pode ser um desafio ao inspecionar políticas complexas.
Acreditamos firmemente que a fusão de tabelas de políticas de vários estágios em uma única tabela cria complexidade e confusão para os administradores.
Essa abordagem pode ser difícil de compreender e levar a configurações potencialmente desconcertantes.
Para garantir a clareza, é aconselhável criar políticas em uma determinada tabela que inclua apenas atributos relevantes para avaliações consistentes e diretas.

Otimização das tabelas de políticas Deny e Allow:

Algumas soluções de segurança adotam uma estrutura em que mantêm tabelas de políticas “Deny” (Negar) e “Allow” (Permitir) separadas.
Nessa configuração, as políticas definidas na lista “Deny” (Negar) têm precedência e são avaliadas primeiro.
Se nenhuma política correspondente for encontrada na tabela “Deny” (Negar), a avaliação prossegue para a tabela de políticas “Allow” (Permitir).
Entretanto, essa divisão de políticas em duas tabelas distintas pode representar desafios para os administradores.
Defendemos firmemente uma abordagem mais simplificada, em que qualquer tabela de política seja apresentada como uma lista ordenada de políticas.
Nesse arranjo, cada política especifica explicitamente sua ação, seja ela “Negar”, “Permitir” ou qualquer outra ação desejada.
Durante o processamento do tráfego, a avaliação da política segue uma progressão lógica da política de prioridade mais alta para a política de prioridade mais baixa até que seja encontrada uma correspondência.
Quando uma política correspondente é identificada, a ação correspondente é aplicada ao tráfego.
Nos casos em que nenhuma política correspondente é encontrada, uma ação padrão, como “falha na abertura” ou “falha no fechamento”, é acionada conforme definido pela política de segurança da organização.
Essa abordagem simplifica o gerenciamento de políticas e aumenta a clareza para os administradores ao consolidar as políticas em uma lista única e ordenada, independentemente dos valores de ação da política, minimizando assim a complexidade e agilizando o processo de avaliação da política.
A não separação das tabelas de políticas com base nos valores de ação também permitiu que os provedores de soluções SASE introduzissem novos valores de ação no futuro com relativa facilidade.

Criando políticas flexíveis e expressivas:

Como o senhor já percebeu, os administradores criam políticas definindo conjuntos de valores para atributos correspondentes.
Tradicionalmente, há um entendimento comum de como a correspondência de políticas opera durante as avaliações de tráfego: uma política é considerada correspondente somente quando todos os valores de atributos especificados na política se alinham perfeitamente com os valores da sessão de tráfego de entrada.
Esses valores podem ser extraídos diretamente do tráfego ou inferidos a partir de informações contextuais, como o contexto do usuário autenticado e o contexto do dispositivo responsável por iniciar o tráfego.
Essencialmente, esse processo de correspondência envolve uma operação “AND” em todos os atributos da política.
No entanto, com a evolução das tecnologias de segurança, muitos dispositivos de segurança introduziram uma abordagem mais flexível, concedendo aos administradores a capacidade de atribuir vários valores aos atributos.
Nesse paradigma evoluído, uma correspondência é estabelecida se as informações do contexto de tempo de execução se alinharem a qualquer um dos valores especificados para os atributos da política.
Em essência, o processo de correspondência agora combina uma operação “AND” entre atributos com uma operação “OR” entre os valores associados a esses atributos.
As organizações podem se beneficiar significativamente dessa flexibilidade ao criar políticas abrangentes.
Ela reduz o número total de políticas necessárias, mantendo a legibilidade.
No entanto, esses atributos de vários valores são apenas um passo na direção certa, e muitas vezes são necessários outros aprimoramentos para atender aos requisitos exclusivos das organizações: Suporte para decoração “NOT”: Os administradores precisam ter a capacidade de definir valores de atributos de política com uma decoração “NOT”.
Por exemplo, deve ser possível especificar um valor de atributo “source IP” como “NOT 10.1.5.0/24”, indicando que a política corresponderá com êxito quando o IP de origem da sessão de tráfego não pertencer à sub-rede 10.1.5.0/24. Suporte a várias instâncias de um atributo: Muitos dispositivos de segurança tradicionais suportam apenas uma instância de um determinado atributo em uma política.
Para criar políticas abrangentes, a capacidade de incluir várias instâncias do mesmo atributo em uma única política é essencial.
Por exemplo, um administrador pode querer permitir sessões de qualquer endereço IP na sub-rede 10.0.0.0/8 e, ao mesmo tempo, negar sessões de tráfego da sub-rede 10.1.5.0/24.
Isso deve ser possível em uma única política, talvez especificando os valores de “IP de origem” duas vezes: “IP de origem == 10.0.0.0/8” e “IP de origem == NÃO 10.1.5.0/24”.
Isso evita a necessidade de criar duas políticas separadas e permite um gerenciamento de políticas mais intuitivo. Suporte a decorações para valores do tipo string: Os atributos que aceitam valores de cadeia de caracteres, como caminhos de URI, nomes de domínio e muitos cabeçalhos de solicitação HTTP, beneficiam-se de decorações como ‘exact’, ‘starts_with’ e ‘ends_with’.
Essas decorações aprimoram a criação de políticas expressivas. Suporte a padrões de expressão regular: Em alguns casos, as políticas exigem a correspondência de padrões nos valores de tráfego.
Por exemplo, uma política pode determinar que uma sessão de tráfego seja permitida somente se um padrão específico estiver presente em qualquer parte do valor do cabeçalho da solicitação “user agent”.
O suporte a padrões de expressão regular é essencial nesses cenários. Suporte a atributos dinâmicos: Embora os atributos tradicionais das políticas sejam fixos e predefinidos, os ambientes SASE às vezes exigem atributos dinâmicos. Considere os cabeçalhos de solicitação e resposta ou as declarações JWT, em que os padrões coexistem com vários cabeçalhos e declarações personalizados.
O SASE deve permitir que os administradores criem políticas que acomodem cabeçalhos e declarações personalizados.
Por exemplo, o SASE deve permitir a criação de políticas com o cabeçalho de solicitação “X-custom-header” como um atributo e o valor “matchme”. No momento do tráfego, todas as sessões HTTP com “X-custom-header” como um dos cabeçalhos de solicitação e “matchme” como valor devem corresponder à política. Suporte a objetos: Esse recurso permite a criação de vários tipos de objetos com valores que podem ser usados como valores de atributos em políticas, em vez de especificar valores imediatos.
Os objetos podem ser referenciados em várias políticas, e qualquer alteração futura de valor pode ser feita no nível do objeto, simplificando as modificações de políticas e garantindo a consistência.
Esses aprimoramentos contribuem para a criação de políticas de segurança flexíveis, expressivas e eficientes, permitindo que as organizações adaptem suas políticas às necessidades e aos cenários de segurança exclusivos de forma eficaz.

Aprimoramento da integração de políticas com modificações de tráfego

Certas funções de segurança exigem modificações no tráfego, sendo que os casos de uso mais comuns envolvem a adição, a exclusão ou a modificação de cabeçalhos de solicitação/resposta HTTP e seus valores, parâmetros de consulta e seus valores e até mesmo o corpo da solicitação/resposta.
Essas modificações podem variar significativamente com base nas configurações dos administradores.
Muitas vezes, as modificações específicas dependem dos valores do tráfego, como o aplicativo/serviço do site de destino, bem como das informações contextuais disponíveis durante o tempo de execução do tráfego.
Em vez de manter uma tabela de políticas separada para as modificações de tráfego, geralmente é mais eficiente incluir esses objetos de modificação nas próprias políticas de acesso.
Essa abordagem simplifica o gerenciamento de políticas e garante que as modificações estejam diretamente alinhadas com as políticas que regem o comportamento do tráfego.
Um cenário importante em que a modificação do tráfego é essencial é o contexto das soluções CASB (Cloud Access Security Broker), principalmente quando as organizações exigem restrições multitenancy.
Essas restrições geralmente envolvem a adição de cabeçalhos e valores de solicitação específicos para aplicar políticas específicas de colaboração.
Além disso, há outros casos, como a adição de cabeçalhos personalizados para solução de problemas de ponta a ponta e análise de desempenho, em que as modificações de tráfego desempenham um papel crucial.
Consequentemente, as organizações esperam que as soluções SASE ofereçam suporte a políticas que se integrem perfeitamente aos objetos de modificação.
Durante o processamento de tráfego, as modificações de tráfego são executadas quando a política correspondente é associada aos objetos de modificação apropriados, proporcionando uma abordagem unificada e eficiente para o gerenciamento de tráfego e a aplicação de políticas.

Aprimoramento da observabilidade:

É prática comum registrar cada sessão de tráfego ao final da sessão para fins de observabilidade.
Em casos que envolvem sessões substanciais ou “elefantes”, também é comum registrar periodicamente as informações de acesso.
Esses registros de sessão geralmente contêm dados valiosos, incluindo metadados de tráfego, ações realizadas durante a sessão e detalhes sobre os pacotes e bytes transferidos entre o cliente e o servidor.
Um avanço significativo oferecido pela SASE é a consolidação das funções de segurança e a adoção de arquiteturas de passagem única e de conclusão em tempo de execução, resultando em um log de sessão unificado.
Isso contrasta com as implementações de segurança não SASE, em que cada componente de segurança individual gera seu próprio log de sessão, geralmente contendo informações sobre a política que foi correspondida e os valores de atributos críticos usados no processo de correspondência.
É importante ressaltar que, embora o SASE gere um único registro, há uma expectativa de que ele não comprometa a inclusão de informações essenciais.
Quando uma sessão de tráfego é permitida devido a várias avaliações de políticas em várias funções de segurança e tabelas de políticas, o log resultante deve incluir informações sobre cada política que foi correspondida.
Além disso, se uma política for correspondida devido aos valores de atributos específicos de tráfego ou contexto, o log deve fornecer detalhes precisos sobre os valores de atributos que levaram à correspondência da política.
Como as organizações dependem de logs abrangentes para uma observabilidade eficaz, espera-se que as soluções SASE forneçam informações completas nos logs, garantindo que os administradores tenham acesso aos dados necessários para monitorar e analisar o tráfego da rede de forma eficaz.

Abordagem SASE para o gerenciamento de políticas:

É importante reconhecer que nem todas as soluções SASE são idênticas.
As organizações devem avaliar cuidadosamente se uma determinada solução SASE está alinhada com seus requisitos organizacionais específicos sem sacrificar a usabilidade.
Embora as organizações possam não possuir inicialmente todos os requisitos listados acima, é apenas uma questão de tempo até que esses requisitos se tornem cada vez mais relevantes e essenciais para suas operações.
As organizações que possuem todos os requisitos mencionados acima têm a vantagem de ter total flexibilidade para adaptar suas políticas de SASE às suas necessidades específicas.
Por outro lado, as organizações que não têm todos esses requisitos no momento geralmente buscam uma experiência de usuário mais simples e, ao mesmo tempo, ficam atentas à introdução de funcionalidades adicionais à medida que seus requisitos evoluem.
Essa abordagem permite que as organizações alcancem um equilíbrio entre suas necessidades atuais e o crescimento futuro, garantindo que sua solução SASE permaneça adaptável e responsiva às circunstâncias em constante mudança. A menos que as soluções SASE ofereçam flexibilidade total, a personalização se torna um desafio.
Portanto, acreditamos que as soluções SASE devem oferecer os seguintes recursos essenciais:

1. Gerenciamento modular de políticas: As soluções SASE abrangem várias funções de segurança, cada uma com seu próprio conjunto de configurações de políticas.
   Essas configurações devem incluir opções para ativar/desativar, definir a ação padrão no caso de não haver correspondência de políticas, gerenciar a coleção de várias tabelas de políticas, definir várias políticas em cada tabela de políticas, estabelecer uma lista ordenada de políticas e definir configurações de ação, objetos de modificação, atributos de correspondência e valores para cada política.
2. Encadeamento de políticas: Para permitir políticas mais específicas e granulares, as soluções SASE devem oferecer suporte ao encadeamento de políticas.
   Isso significa permitir a organização de políticas em várias tabelas de políticas em uma coleção.
   Por exemplo, as organizações podem ter tabelas de políticas separadas para diferentes aplicativos, com as políticas da tabela principal usando nomes de aplicativos/domínios como critérios de correspondência para selecionar as tabelas de políticas apropriadas.
   Normalmente, isso é feito por meio do uso de políticas que apresentam uma ação chamada “Jump”, que redireciona a avaliação da política para a tabela de políticas referenciada.
   O conceito de encadeamento de políticas ganhou popularidade com o Linux IPTables, e muitas soluções de segurança incorporaram essa funcionalidade posteriormente.

A abrangência das funções de segurança no SASE pode ser extensa e pode incluir:

• NGFW (Next-Generation Firewall): Fornece controle de acesso L3/L4, proteção contra DDoS, reputação de IP, reputação de domínio e sistema de detecção e prevenção de intrusões (IDPS).
• SWG (Secure Web Gateway): Oferece inspeção TLS, controle de acesso à Web pré-TLS, controle de acesso à Web pós-TLS, reputação de URL, reputação de arquivos e proteção contra malware.
• ZTNA (Zero Trust Network Access): Semelhante ao SWG, mas com foco na segurança de aplicativos hospedados.
• CASB (Cloud Access Security Broker): Abrange a reputação do serviço em nuvem e o controle de acesso ao serviço em nuvem.
• DLP (prevenção de perda de dados): Implementação do controle de acesso com base em informações de identificação pessoal (PII), documentos confidenciais padrão e documentos confidenciais específicos da empresa.

A flexibilidade do gerenciamento de políticas para cada função de segurança, juntamente com a capacidade de gerenciar políticas dentro de cada função por meio de várias tabelas de políticas com encadeamento de políticas, é um recurso poderoso.
As organizações geodistribuídas com vários requisitos regulamentares podem se beneficiar especialmente dessa flexibilidade.
Entretanto, as organizações menores podem preferir algum tipo de consolidação das tabelas de políticas.
Nesses casos, deve ser possível personalizar a configuração por meio de:

• Consolidação de todas as configurações da função de segurança pré-TLS em uma única coleção de tabelas de políticas em vários componentes SWG/ZTNA.
• Consolidação de todas as configurações da função de segurança pós-TLS em outra coleção única de tabelas de políticas em vários componentes SWG/ZTNA.
• Manter as funções de CASB, malware e DLP como entidades separadas, pois elas exigem definições de políticas complexas.
• Optar por uma única tabela de políticas dentro da coleção de tabelas de políticas, evitando assim o encadeamento de políticas.

Portanto, as organizações devem buscar serviços de SASE que ofereçam total flexibilidade e, ao mesmo tempo, controles personalizados para consolidar as configurações das funções de segurança relevantes.
Essa abordagem garante que as políticas de SASE sejam adaptadas às necessidades específicas de uma organização, mantendo a facilidade de gerenciamento e a escalabilidade à medida que os requisitos evoluem.

Equilíbrio entre a experiência do usuário e a flexibilidade preparada para o futuro

Historicamente, o gerenciamento de políticas de segurança tem sido uma tarefa complexa.
Muitos produtos são especializados no gerenciamento de políticas para dispositivos de segurança específicos, o que resulta em um cenário fragmentado.
O SASE aborda essa complexidade consolidando vários dispositivos de segurança em uma solução unificada.
Embora essa consolidação ofereça vantagens, ela também introduz complexidades próprias.
As abordagens tradicionais de gerenciamento de políticas, como uma única tabela de políticas, podem parecer atraentes no início.
No entanto, elas apresentam vários desafios e muitas vezes não atendem aos requisitos descritos neste artigo.
Por outro lado, ter um número excessivo de mecanismos de políticas também pode levar à complexidade.
É fundamental encontrar o equilíbrio certo entre flexibilidade e simplicidade.
Um desafio significativo no setor é a proliferação de políticas.
Um número excessivo de políticas não apenas degrada a experiência do usuário e da solução de problemas, mas também traz implicações para o desempenho.
A abordagem de várias tabelas e a expressividade das políticas, conforme descrito anteriormente, são estratégias essenciais para reduzir o volume de políticas nas tabelas de políticas.
As soluções SASE estão lidando cada vez mais com essas complexidades, oferecendo maior sofisticação no gerenciamento de políticas.
Acreditamos que as soluções SASE continuarão a evoluir, implementando muitos dos requisitos detalhados neste artigo em um futuro muito próximo.
Essa evolução permitirá que as organizações atinjam o equilíbrio ideal entre a experiência do usuário, a flexibilidade e o desempenho, garantindo que suas políticas de segurança permaneçam eficazes e adaptáveis em um cenário de ameaças que muda rapidamente.

• Blog CTO Insights

  A série de blogs Aryaka CTO Insights oferece liderança de pensamento para tópicos de rede, segurança e SASE.
  Para obter as especificações dos produtos Aryaka, consulte as fichas técnicas da Aryaka.