Leia sobre dicas e funcionalidades da GoCache CDN para melhorar a seguranca do seu site, loja virtual ou app mobile.

Como funciona o monitoramento de segurança via SIEM

Parece que a imagem clichê de um especialista em segurança é ele sentado em uma sala escura com mais de quatro monitores brilhantes exibindo diferentes tarefas complexas. Independentemente de quantos monitores eles usam, sabemos que as equipes de segurança estão usando o mesmo número, senão mais, de ferramentas complexas. De acordo com o Security Megatrend Report da empresa de análises EMA, 75% dos entrevistados usam mais de seis consoles para fazer o seu trabalho. Embora o estereótipo do especialista em segurança cibernética em ação possa parecer emocionante, a realidade é que ter tantas ferramentas para monitorar pode ser opressor e virtualmente impossível.

As soluções de gerenciamento de eventos e informações de segurança (SIEM – Security Information and Event Management) fornecem alívio e percepções da equipe de segurança com uma análise centralizada dos dados de segurança extraídos de uma variedade de sistemas. Continue lendo para aprender sobre a grande variedade de informações que um SIEM pode consolidar, tornando-se a principal ferramenta de monitoramento de segurança da sua organização.

Informação Típica

Universalmente, os SIEMs monitoram fontes de dados padrão, que incluem sistemas operacionais como Windows e Linux, roteadores e switches, firewalls, bancos de dados e servidores. Os SIEMs monitoram esses ativos não apenas quanto a comportamentos incomuns, mas também podem garantir que as atividades planejadas, como adição ou exclusão de usuários ou dados, ocorram sem incidentes. Ter todas essas fontes monitoradas em um só lugar também permite a correlação de eventos. A correlação de eventos mostra como um único evento pode ser relacionado a outros eventos registrados, auxiliando na análise forense e fornecendo uma trilha de auditoria. Isso pode fornecer insights poderosos sobre o seu ambiente. Por exemplo, se um usuário se envolver em um comportamento incomum no seu servidor, você pode abrir todas as atividades desse usuário, capturando eventos de segurança mais rapidamente e ver se há um padrão em outros dispositivos, garantindo suspeita.

Fluxos de dados diversos

Embora as fontes de dados padrão sejam essenciais para serem monitoradas, cada organização traz fontes exclusivas que também precisam de monitoramento, como um banco de dados local ou aplicativos de terceiros. Conectar coisas como um CRM otimiza ainda mais o seu ambiente, reduzindo o número de consoles que a sua equipe de segurança precisa examinar.

Isso é particularmente importante para coisas como aplicativos financeiros, nos quais capturar eventos em tempo real pode ser especialmente crucial. Por exemplo, se um usuário credenciado foi criado, realizou várias ações e foi excluído, esse comportamento suspeito pode significar que dados confidenciais e dinheiro podem estar em risco. Sem um SIEM monitorando eventos e enviando um alerta em tempo real, essa atividade pode não ser detectada até que seja tarde demais para fazer algo a respeito. Além disso, se um usuário não autorizado tentar ou conseguir baixar dados confidenciais, um SIEM pode desabilitar imediatamente o acesso desse usuário, evitando qualquer risco adicional enquanto o evento é investigado. Os tipos de ações realizadas dependem do evento e podem ser configuradas de acordo com as necessidades de cada organização.

Mais importante, habilitar a segurança do aplicativo pode trazer mais informações sobre os relacionamentos de eventos. Quanto mais um SIEM monitora, mais fácil é localizar eventos correlacionados, fornecendo um novo ângulo para visualizar a sua imagem de segurança. Por exemplo, integrar uma solução antivírus pode permitir que você não apenas receba alertas sobre violações impedidas, mas também pode permitir que você isole a origem da tentativa de infecção, fornecendo mais informações.

Expandindo a rede SIEM

Um SIEM é tão bom quanto os fluxos de dados que ele pode avaliar. Conforme mencionado acima, embora existam fontes típicas que a maioria dos ambientes possui, muitas organizações têm necessidades fora do escopo normal. Simplificando, um SIEM não pode gerar alertas para um aplicativo que não está monitorando. Em vez disso, uma fonte de dados não filtrada por um SIEM exigirá atenção especial, aumentando não apenas a carga de trabalho da sua equipe de segurança, mas também a probabilidade de atividades suspeitas escapando pelas rachaduras. Quanto mais fontes você conectar, mais insights poderá obter.

O Event Manager fornece uma visão holística de todo o seu ambiente. Ele não apenas fornece modelos prontos para fácil implementação para fontes de dados padrão, mas também pode ser usado com aplicativos internos, software de terceiros ou dispositivos conectados, fornecendo uma trilha de auditoria completa e monitoramento em tempo real para aplicativos principais não convencionais que ainda fornecem acesso aos seus sistemas críticos. Nossos especialistas estarão prontamente disponíveis para trabalhar com a sua equipe de segurança para desenvolver um plano para conectar quaisquer fluxos de dados necessários e fornecer suporte contínuo.

Referencia: https://www.coresecurity.com/blog/monitoring-application-security-siem

O que é TLS? Vantagens do TLS 1.3

TLS (Transport Layer Security) é o protocolo criptográfico que fornece segurança de comunicação para todos os sites modernos. Lançado pela primeira vez em 1999 como uma atualização para o SSL 3.0, agora obsoleto, o TLS 1.0 evoluiu para o TLS 1.1 e, em 2008, para a versão atual do TLS 1.2. Embora o TLS 1.2 tenha sido um enorme sucesso nos últimos dez anos, o cenário de segurança da web em constante mudança e as ameaças cibernéticas emergentes há muito exigem uma melhoria. Depois de uma década em construção e 28 rascunhos para ser definido, o TLS 1.3 foi finalmente lançado em agosto de 2018. Nesta visão geral rápida, mostraremos o que há de novo no TLS 1.3.

Como funciona o TLS?

O TLS usa uma combinação de criptografia simétrica e assimétrica, pois oferece um bom compromisso entre desempenho e segurança ao transmitir dados com segurança.

Com a criptografia simétrica, os dados são criptografados e descriptografados com uma chave secreta conhecida pelo remetente e pelo destinatário, tipicamente 128, mas preferencialmente 256 bits de comprimento (qualquer coisa menor que 80 bits agora é considerada insegura). A criptografia simétrica é eficiente em termos de computação, mas ter uma chave secreta comum significa que ela precisa ser compartilhada de maneira segura.

A criptografia assimétrica usa pares de chaves – uma chave pública e uma chave privada. A chave pública está matematicamente relacionada à chave privada, mas dado o comprimento de chave suficiente, é computacionalmente impraticável derivar a chave privada da chave pública. Isso permite que a chave pública do destinatário seja usada pelo remetente para criptografar os dados que deseja enviar, mas esses dados só podem ser descriptografados com a chave privada do destinatário.

A vantagem da criptografia assimétrica é que o processo de compartilhamento de chaves de criptografia não precisa ser seguro, mas a relação matemática entre as chaves públicas e privadas significa que tamanhos de chave muito maiores são necessários. O comprimento mínimo de chave recomendado é de 1.024 bits, com preferência de 2.048 bits, mas isso é até mil vezes mais intensivo em termos de computação do que as chaves simétricas de força equivalente (por exemplo, uma chave assimétrica de 2048 bits é aproximadamente equivalente a uma chave simétrica de 112 bits) e torna a criptografia assimétrica muito lenta para muitos propósitos.

Por esse motivo, o TLS usa criptografia assimétrica para gerar e trocar com segurança uma chave de sessão. A chave de sessão é então usada para criptografar os dados transmitidos por uma parte e para descriptografar os dados recebidos na outra extremidade. Assim que a sessão termina, a chave da sessão é descartada.

Uma variedade de diferentes métodos de geração e troca de chaves pode ser usada, incluindo RSA, Diffie-Hellman (DH), Diffie-Hellman efêmero (DHE), Curva elíptica Diffie-Hellman (ECDH) e Curva elíptica efêmera Diffie-Hellman (ECDHE). DHE e ECDHE também oferecem sigilo direto em que uma chave de sessão não será comprometida se uma das chaves privadas for obtida no futuro, embora a geração fraca de números aleatórios e/ou o uso de um intervalo limitado de números primos tenham sido postulados para permitir o cracking de até mesmo chaves DH de 1024 bits com recursos de computação de nível de estado. No entanto, eles podem ser considerados problemas de implementação, em vez de problemas de protocolo, e existem ferramentas disponíveis para testar os conjuntos de criptografia mais fracos.

Com o TLS, também é desejável que um cliente conectado a um servidor seja capaz de validar a propriedade da chave pública do servidor. Isso normalmente é realizado usando um certificado digital X.509 emitido por um terceiro confiável conhecido como Autoridade de Certificação (CA), que afirma a autenticidade da chave pública. Em alguns casos, um servidor pode usar um certificado auto assinado que precisa ser explicitamente confiável pelo cliente (os navegadores devem exibir um aviso quando um certificado não confiável é encontrado), mas isso pode ser aceitável em redes privadas e/ou onde a distribuição segura de certificados é possível. No entanto, é altamente recomendável usar certificados emitidos por CAs publicamente confiáveis.

TLS 1.3 é mais rápido que o TLS 1.2

O TLS 1.3 apresenta um novo handshake que reduz o tempo que leva para criptografar uma conexão. Anteriormente, o TLS 1.2 exigia duas viagens de ida e volta para concluir o handshake do TLS, mas agora a versão 1.3 precisa de apenas uma viagem de ida e volta. Essa alteração diminui a latência de criptografia pela metade. Mesmo que a diferença seja em milissegundos, ela aumenta em escala e ajuda as empresas a melhorar o desempenho da rede.

Outro novo recurso que reduz o tempo de criptografia é o Zero Round Trip Time Resumption (0-RTT). Quando um usuário visita novamente o seu site em um curto espaço de tempo, o 0-RTT torna a conexão quase instantânea.

Quais navegadores suportam TLS 1.3?

No momento em que este artigo foi escrito, Chrome (67+), Firefox (61+), Opera (57+), Edge (76) e Safari (12.3), todos suportam a versão mais recente do TLS. O Chrome e o Firefox foram os primeiros a implantar o suporte para TLS 1.3. Use este link para verificar quais versões de navegador são compatíveis com TLS 1.3.

TLS 1.2 vs TLS 1.3: Quais são as principais diferenças?

O TLS 1.3 oferece várias melhorias em relação às versões anteriores, principalmente um handshake de TLS mais rápido e conjuntos de criptografia mais simples e seguros. As trocas de chaves do Zero Round-Trip Time (0-RTT) otimizam ainda mais o handshake TLS. Juntas, essas mudanças fornecem melhor desempenho e segurança mais forte.

Handshake TLS mais rápido

A criptografia TLS e a descriptografia SSL requerem tempo de CPU e adicionam latência às comunicações de rede, degradando um pouco o desempenho. No TLS 1.2, o handshake inicial era realizado em texto não criptografado, o que significa que mesmo ele precisava ser criptografado e descriptografado. Dado que um handshake típico envolvia de 5 a 7 pacotes trocados entre o cliente e o servidor, isso adicionava uma sobrecarga considerável à conexão. Na versão 1.3, a criptografia do certificado do servidor foi adotada por padrão, possibilitando que um handshake TLS fosse realizado com 0 – 3 pacotes, reduzindo ou eliminando esta sobrecarga e permitindo conexões mais rápidas e responsivas.

TLS 1.3 na GoCache

O protocolo TLS 1.3 já é nativamente integrado a ferramenta da GoCache, permitindo que sua aplicação usufrua de todos os benefícios em nível de segurança e performance fornecido por essa versão.

Referencia: https://www.a10networks.com/blog/key-differences-between-tls-1-2-and-tls-1-3/

 

Ataque DDoS? Don’t Worry! Aplique o Rate Limit

Ataques DDoS acabam por se tornar cada vez mais uma ameaça constante à aplicações web, devido a facilidade de se encomendar e/ou aplicar o mesmo utilizando a computação em nuvem, com isso é importante sempre estar preparado para mitigar e se proteger dos danos de um ataque DDoS. Caso você não saiba o que é um ataque DDoS, clique AQUI.

O Rate Limit é conhecido por ser uma ferramenta de alta eficiência quando bem configurado contra ataques DDoS e DoS, já que ambos são baseados em volumetria, que visam por padrão gerar indisponibilidade em alguma aplicação web.

Neste artigo traremos alguns possíveis cenários de ataques, ilustrando como poderíamos mitigá-los utilizando o recurso de Rate Limit da GoCache

Primeiramente, é importante compreender o padrão de acessos de sua aplicação em um momento sem ataque para assim definir limitações seguras que não bloqueiem usuários legítimos. No exemplo a seguir, que é uma aplicação WordPress, começaremos avaliando:

  • Quantidade de requests por IP que acessaram a hospedagem por minuto;
  • Quantidade de requests por IP em áreas sensíveis do site, como um arquivo PHP.

Com essas informações em mãos, podemos destacar alguns destes dados, dispostos nos gráficos abaixo:

Feita a análise, já podemos preparar regras e formular ideias para uma política de segurança, com o objetivo de mitigar algum ataque que venha acontecer.

Considerando que o público-alvo deste site é o Brasil, uma primeira abordagem seria a criação de regras mais restritivas para os acessos provenientes de outros países.

A primeira e mais delicada ação, é a definição de limites seguros para cada perfil de acesso, em que serão utilizados como base os picos de acessos com o acréscimo de uma margem. No nosso caso, adicionaremos 10 acessos, acima do pico de tráfego do dia.

Os acessos a home e ademais (/*) recursos têm um pico de 120 acessos por minuto, provenientes do mesmo IP no Brasil. Dessa forma, iremos criar uma regra para 130 acessos neste período de tempo, limitado ao “País de Origem” Brasil.

Limitação de 130 requisições / minuto de um IP proveniente do Brasil

Agora, podemos nos direcionar para as regras de áreas mais sensíveis do site, como as requests para arquivos .php, veja o exemplo criado:

Limitação de 50 requisições / min em requisições .php

Pelo fato da aplicação ser um WordPress, é preciso ter cuidado com a área logada, esta que por padrão faz muitas requisições de conteúdo dinâmico, seja num /wp-json, /plugin-install.php, /admin-ajax.php, e que poderiam acabar bloqueando um usuário legítimo.

Neste caso, seria possível excluir alguns paths do Rate Limit, e também criar regras mais brandas para acessos feitos pelos administradores do site.

Veja um exemplo:

Regra com uma limitação mais abrangente para usuários logados.

Assim aqueles que estiverem logados e tiverem o cookie que comece com wordpress_logged_in*, poderão ter uma margem maior de requests antes de ativar o Rate Limit.

Com as principais regras criadas, temos uma certa segurança para ataques locais do Brasil. Agora, podemos criar regras mais rígidas para acessos estrangeiros, que possuem um padrão de 30 acessos por minuto, conforme exemplo abaixo:

Limitação de 30 requisições / minuto de um IP de fora do Brasil

Essas regras foram construídas em um cenário fora de ataque, mas supondo que um atacante resolveu fazer um DDoS na aplicação após as regras serem criadas, é possível notar no Analytics (Ferramenta da GoCache que mostra métricas da CDN) que a ferramenta foi bastante eficiente no bloqueio:

Analytics GoCache: Requisições bloqueadas pelo rate-limit em timeline

Neste momento, podemos criar regras para mitigar um ataque que já está ocorrendo, como por exemplo, um ataque de Brute Force de senha.

Supondo um cenário em que o atacante queira fazer um Brute Force no wp-login, e para tentar fazer o bypass de eventuais controles de Rate Limit, crie variações no User Agent, utilizando strings de até 5 caracteres aleatórios ( js321, ksfg, las, 0w324, 99097, 2456d , 4k).

Ao analisar o padrão dos acessos, foi possível identificar que o mesmo fazia requisições de diferentes lugares de fora do Brasil, tentando 20 vezes de cada IP.

Sendo assim, poderíamos mitigar esse ataque usando o Rate Limit com uma regra específica para esse padrão. Vejamos a regra criada:

Customização de rate-limiting utilizando critérios de user-agent e geolocalização

Com essa última regra, podemos bloquear apenas User Agents menores que 5 caracteres, com métodos POSTs, podendo assim bloquear essa tentativa de Brute Force.

Todas as regras em conjunto são ilustrativas para o contexto. O nível de customização da GoCache permite criar limitações combinando uma série de critérios e fazendo uso de expressões regulares.

O que é um ataque de força bruta? Brute Force

Um ataque de força bruta (também conhecido como quebra de força bruta) é um ataque cibernético equivalente a tentar todas as chaves do seu chaveiro e, por fim, encontrar a correta. 5% dos incidentes de violação de dados confirmados em 2017 resultaram de ataques de força bruta.

Os ataques de força bruta são simples e confiáveis. Os invasores permitem que um computador faça o trabalho – tentando diferentes combinações de nomes de usuário e senhas, por exemplo – até encontrarem um que funcione. Capturar e neutralizar um ataque de força bruta em andamento é o melhor contra-ataque: depois que os invasores têm acesso à rede, eles são muito mais difíceis de serem capturados.

Tipos de ataques de força bruta

O ataque de força bruta mais básico é um ataque de dicionário, em que o invasor trabalha por meio de um dicionário de senhas possíveis e tenta todas elas. Ataques de dicionário começam com algumas suposições sobre senhas comuns para tentar adivinhar a partir da lista no dicionário. Esses ataques tendem a ser um tanto desatualizados, devido a técnicas mais novas e eficazes.

Computadores recentes fabricados nos últimos 10 anos podem quebrar com força bruta uma senha alfanumérica de 8 caracteres – letras maiúsculas e minúsculas, números e caracteres especiais – em cerca de duas horas. Os computadores são tão rápidos que podem descriptografar por força bruta um hash de criptografia fraco em poucos meses. Esses tipos de ataques de força bruta são conhecidos como uma busca exaustiva de teclas, em que o computador tenta todas as combinações possíveis de todos os caracteres possíveis para encontrar a combinação certa.

A reciclagem de credenciais é outro tipo de ataque de força bruta que reutiliza nomes de usuário e senhas de outras violações de dados para tentar invadir outros sistemas.

O ataque de força bruta reverso usa uma senha comum como “password” e, subsequentemente, tenta forçar um nome de usuário a acompanhar essa senha. Como “password” é uma das senhas mais comuns em 2017, essa técnica é mais bem-sucedida do que você imagina.

Como se defender contra ataques de força bruta

Ataques de força bruta precisam de tempo para funcionar. Alguns ataques podem levar semanas ou até meses para fornecer algo utilizável. A maioria das defesas contra ataques de força bruta envolve aumentar o tempo necessário para o sucesso além do que é tecnicamente possível, mas essa não é a única defesa.

• Aumentar o comprimento da senha: Mais caracteres equivalem a mais tempo para a quebra de força bruta
• Aumentar a complexidade da senha: Mais opções para cada caracter também aumentam o tempo para quebrar a força bruta
• Limitar as tentativas de login: Ataques de força bruta incrementam um contador de tentativas de login malsucedidas na maioria dos serviços de diretório – uma boa defesa contra ataques de força bruta é bloquear os usuários após algumas tentativas fracassadas, anulando assim um ataque de força bruta em andamento
• Implementar Captcha: Captcha é um sistema comum para verificar se um humano é humano em sites e pode impedir ataques de força bruta em andamento
• Use autenticação multi-fator: A autenticação multi-fator adiciona uma segunda camada de segurança a cada tentativa de login que requer intervenção humana, isso pode impedir o sucesso de um ataque de força bruta

A maneira proativa de impedir ataques de força bruta começa com o monitoramento. Varonis monitora a atividade Active Directory e Tráfego VPN para detectar ataques de força bruta em andamento. Temos modelos de ameaças que monitoram comportamentos de bloqueio (geralmente um sinal de que há um ataque de força bruta em andamento), modelos de ameaças que detectam o potencial de preenchimento de credenciais e muito mais – todos projetados para detectar e prevenir ataques de força bruta antes que o ataque se intensifique.

É melhor detectar um ataque em andamento e interromper ativamente o ataque do que esperar que as suas senhas não possam ser quebradas. Depois de detectar e interromper o ataque, você pode até mesmo colocar endereços IP na lista negra e evitar outros ataques do mesmo computador.

O que é um ataque de força bruta?

Um ataque de força bruta, ou pesquisa exaustiva, é um hack criptográfico que usa tentativa e erro para adivinhar possíveis combinações de senhas usadas para logins, chaves de criptografia ou páginas da web ocultas.

Referencia: https://www.varonis.com/blog/brute-force-attack/

Cross-site Scripting – O que é?

O que é cross-site scripting (XSS)?

Cross-site scripting (também conhecido como XSS) é uma vulnerabilidade de segurança da web que permite que um invasor comprometa as interações que os usuários têm com um aplicativo vulnerável. Ele permite que um invasor contorne a política de mesma origem, que é projetada para separar sites diferentes uns dos outros. As vulnerabilidades de script entre sites normalmente permitem que um invasor se disfarce de usuário vítima, execute quaisquer ações que o usuário possa realizar e acesse qualquer um dos dados do usuário. Se o usuário vítima tiver acesso privilegiado ao aplicativo, o invasor poderá obter controle total sobre todas as funcionalidades e dados do aplicativo.

Como funciona o XSS?

O script entre sites funciona manipulando um site vulnerável para que ele retorne JavaScript malicioso para os usuários. Quando o código malicioso é executado dentro do navegador da vítima, o invasor pode comprometer totalmente a interação com o aplicativo.

Prova de conceito XSS

Você pode confirmar a maioria dos tipos de vulnerabilidade XSS injetando uma carga que faz com que o seu próprio navegador execute algum JavaScript arbitrário. Há muito tempo é uma prática comum usar a função alert()para esse propósito, porque é curta, inofensiva e muito difícil de perder quando é chamada com sucesso. Na verdade, você resolve a maioria de nossos laboratórios de XSS invocando alert() no navegador de uma vítima simulada.
Infelizmente, há um pequeno problema se você usar o Chrome. A partir da versão 92 (20 de julho de 2021), iframes de origem cruzada são impedidos de chamar alert(). Como eles são usados ​​para construir alguns dos ataques XSS mais avançados, às vezes você precisará usar uma carga útil PoC alternativa. Neste cenário, recomendamos a função print().

Como a vítima simulada em nossos laboratórios usa o Chrome, alteramos os laboratórios afetados para que eles também possam ser resolvidos usando print(). Indicamos isso nas instruções sempre que for relevante.
Quais são os tipos de ataques XSS?

Existem três tipos principais de ataques XSS. Estes são:

• XSS refletido, em que o script malicioso vem da solicitação HTTP atual.
• XSS armazenado, onde o script malicioso vem do banco de dados do site.
• XSS baseado em DOM, onde a vulnerabilidade existe no código do lado do cliente em vez de no código do lado do servidor.

Perguntas comuns sobre cross-site scripting

Quão comuns são as vulnerabilidades XSS? Vulnerabilidades XSS são muito comuns e XSS é provavelmente a vulnerabilidade de segurança da web que ocorre com mais frequência.

Quão comuns são os ataques XSS? É difícil obter dados confiáveis ​​sobre ataques XSS do mundo real, mas provavelmente são explorados com menos frequência do que outras vulnerabilidades.

Qual é a diferença entre XSS e CSRF? XSS envolve fazer com que um site retorne JavaScript malicioso, enquanto CSRF envolve induzir um usuário vítima a executar ações que não pretende fazer.

Qual é a diferença entre XSS e injeção SQL? XSS é uma vulnerabilidade do lado do cliente que visa outros usuários do aplicativo, enquanto a injeção de SQL é uma vulnerabilidade do lado do servidor que visa o banco de dados do aplicativo.

Como posso prevenir XSS em PHP? Filtre as suas entradas com uma lista de permissões de caracteres permitidos e use dicas de tipo ou conversão de tipo. Fuja das suas saídas com htmlentities e ENT_QUOTES para contextos HTML ou escapes Unicode JavaScript para contextos JavaScript.

Como faço para evitar XSS em Java? Filtre as suas entradas com uma lista de permissões de caracteres permitidos e use uma biblioteca como o Google Guava para codificar em HTML a sua saída para contextos HTML ou use escapes Unicode JavaScript para contextos JavaScript.

Referencia: https://portswigger.net/web-security/cross-site-scripting

Mais transparência e flexibilidade para o WAF

Sabemos que assertividade é palavra chave quando se trata de proteger aplicações contra ameaças com o mínimo impacto possível sobre a audiência legítima. Por isso, avançamos mais um passo nessa direção, trazendo mais transparência e flexibilidade para nossa solução de WAF.

Clientes da GoCache agora podem alterar o comportamento das regras de WAF para ajustá-lo ao comportamento de sua aplicação. Cada regra de WAF pode se comportar de maneira diferente em aplicações diferentes, sendo que algumas regras nem fazem sentido para determinadas aplicações, enquanto outras podem ser mais assertivas, ou até mesmo menos assertivas, mas não menos importantes.

Essa customização toma proveito de toda a flexibilidade das smart rules, de forma que, caso seja necessário desativar uma regra para minimizar falsos positivos, você pode limitar esse contexto da forma mais estreita possível para evitar brechas de segurança.

No exemplo a seguir, temos um site cujas páginas do caminho /blog são servidas por WordPress, enquanto o resto do site não. O grupo de regras gocache-v1/90* protege contra ameaças específicas ao WordPress, portanto, não é necessário aplicá-lo em todo o site. Esta configuração desativa esse grupo de regras em todo o site, habilitando com o comportamento padrão apenas em caminhos que comecem com /blog. Você pode entender melhor o funcionamento através da documentação disponível em https://docs.gocache.com.br/waf_custom/.

Ainda temos muitas novidades a divulgar, que permitirão um maior nível de assertividade das soluções de segurança, com menos necessidade de gerenciamento por parte do usuário. Fique atento ao nosso blog. Se não for cliente, faça sua conta, com 7 dias de teste gratuito, em https://painel.gocache.com.br/trial, para conhecer essa e outras soluções.

TOP 10 OWASP – Conheça as principais vulnerabilidades

O OWASP Top 10 é um documento padrão de conscientização para desenvolvedores e segurança de aplicativos da web. Ele representa um amplo consenso sobre os riscos de segurança mais críticos para aplicativos da web.

10 riscos de segurança de aplicativos da Web

A1: 2017-Injeção: Falhas de injeção, como SQL, NoSQL, OS e injeção de LDAP, ocorrem quando dados não confiáveis ​​são enviados a um intérprete como parte de um comando ou consulta. Os dados hostis do invasor podem induzir o intérprete a executar comandos indesejados ou acessar dados sem a autorização adequada.

A2: 2017-Quebra de Autenticação: As funções do aplicativo relacionadas à autenticação e gerenciamento de sessão são frequentemente implementadas incorretamente, permitindo que invasores comprometam senhas, chaves ou tokens de sessão ou explorem outras falhas de implementação para assumir as identidades de outros usuários temporária ou permanentemente.

A3: 2017-Exposição de dados confidenciais: Muitos aplicativos da web e APIs não protegem adequadamente os dados confidenciais, como finanças, saúde e PII. Os invasores podem roubar ou modificar esses dados fracamente protegidos para conduzir fraude de cartão de crédito, roubo de identidade ou outros crimes. Os dados confidenciais podem ser comprometidos sem proteção extra, como criptografia em repouso ou em trânsito, e requerem precauções especiais quando trocados com o navegador.

A4: 2017-XML Entidades externas (XXE): Muitos processadores XML mais antigos ou mal configurados avaliam referências de entidades externas em documentos XML. Entidades externas podem ser usadas para divulgar arquivos internos usando o manipulador de URI de arquivo, compartilhamentos de arquivos internos, varredura de porta interna, execução remota de código e ataques de negação de serviço.

A5: 2017-Quebra de Controle de Acesso: as restrições sobre o que os usuários autenticados têm permissão para fazer, muitas vezes não são aplicadas de forma adequada. Os invasores podem explorar essas falhas para acessar funcionalidades e/ou dados não autorizados, como acessar contas de outros usuários, visualizar arquivos confidenciais, modificar dados de outros usuários, alterar direitos de acesso, etc.

A6: 2017-Configuração incorreta de segurança: a configuração incorreta de segurança é o problema mais comum. Isso geralmente é o resultado de configurações padrão inseguras, configurações incompletas ou ad hoc, armazenamento em nuvem aberta, cabeçalhos HTTP configurados incorretamente e mensagens de erro detalhadas contendo informações confidenciais. Não apenas todos os sistemas operacionais, estruturas, bibliotecas e aplicativos devem ser configurados com segurança, mas também devem ser corrigidos/atualizados em tempo hábil.

A7: 2017-Cross-Site Scripting XSS: As falhas de XSS ocorrem sempre que um aplicativo inclui dados não confiáveis ​​em uma nova página da web sem validação ou escape adequado, ou atualiza uma página da web existente com dados fornecidos pelo usuário usando uma API do navegador que pode criar HTML ou JavaScript. O XSS permite que os invasores executem scripts no navegador da vítima, que podem sequestrar as sessões do usuário, desfigurar sites ou redirecionar o usuário para sites maliciosos.

A8: 2017-Desserialização Insegura: a desserialização insegura geralmente leva à execução remota de código. Mesmo que as falhas de desserialização não resultem na execução remota de código, elas podem ser usadas para realizar ataques, incluindo ataques de repetição, ataques de injeção e ataques de escalonamento de privilégios.

A9: 2017 – Usando Componentes Com Vulnerabilidades Conhecidas: componentes, como bibliotecas, frameworks e outros módulos de software, são executados com os mesmos privilégios do aplicativo. Se um componente vulnerável for explorado, tal ataque pode facilitar a perda de dados sérios ou o controle do servidor. Aplicativos e APIs que usam componentes com vulnerabilidades conhecidas podem minar as defesas do aplicativo e permitir vários ataques e impactos.

A10: 2017-Registro e monitoramento insuficientes: registro e monitoramento insuficientes, juntamente com a integração ausente ou ineficaz com a resposta a incidentes, permite que os invasores ataquem ainda mais os sistemas, mantenham a persistência, pivotem para mais sistemas e adulterem, extraiam ou destruam dados. A maioria dos estudos de violação mostra que o tempo para detectar uma violação é de mais de 200 dias, sendo normalmente detectada por partes externas em vez de processos internos ou monitoramento.

> Leia mais sobre o que é OWASP. 

Referencia: https://owasp.org/www-project-top-ten/

SSL Handshake: Como funciona

SSL / TLS são protocolos usados ​​para criptografar informações entre dois pontos. Geralmente é entre o servidor e o cliente, mas há momentos em que a criptografia de servidor para servidor e cliente para cliente é necessária. Este artigo se concentrará apenas na negociação entre servidor e cliente.

Para que a negociação SSL / TLS ocorra, o administrador do sistema deve preparar no mínimo 2 arquivos: Chave Privada e Certificado. Ao solicitar de uma Autoridade de Certificação, como DigiCert Trust Services, um arquivo adicional deve ser criado. Este arquivo é chamado de Solicitação de Assinatura de Certificado, gerado a partir da Chave Privada. O processo de geração dos arquivos depende do software que usará os arquivos para criptografia.

Observe que, embora os certificados solicitados de autoridades de certificação sejam inerentemente confiáveis ​​para a maioria dos clientes, certificados adicionais chamados Certificados de autoridade de certificação intermediários e Certificados de raiz de autoridade de certificação, podem precisar ser instalados no servidor. Novamente, isso depende do software do servidor. Geralmente, não há necessidade de instalar os arquivos de CA intermediário e raiz nos aplicativos cliente ou navegadores.

Assim que os arquivos estiverem prontos e corretamente instalados, basta iniciar a negociação SSL / TLS usando o protocolo seguro. Em aplicativos de navegador, geralmente é https://www.domain.com. Lembre-se de usar o endereço do seu site seguro. Acima é apenas um exemplo de endereço.

O handshake SSL padrão

A seguir está um handshake SSL padrão quando o algoritmo de troca de chave RSA é usado:

1. Olá Cliente

Informações de que o servidor precisa para se comunicar com o cliente usando SSL. Isso inclui o número da versão SSL, configurações de criptografia e dados específicos da sessão.

2. Olá Servidor

Informações de que o servidor precisa para se comunicar com o cliente usando SSL. Isso inclui o número da versão SSL, configurações de criptografia e dados específicos da sessão.

3. Autenticação e segredo pré-mestre

O cliente autentica o certificado do servidor. (por exemplo, nome comum / data / emissor) O cliente (dependendo da cifra) cria o segredo pré-mestre para a sessão, criptografa com a chave pública do servidor e envia o segredo pré-mestre criptografado para o servidor.

4. Descriptografia e segredo mestre

O servidor usa sua chave privada para descriptografar o segredo pré-mestre. Tanto o servidor quanto o cliente executam etapas para gerar o segredo mestre com a cifra acordada.

5. Criptografia com chave de sessão

O cliente e o servidor trocam mensagens para informar que as mensagens futuras serão criptografadas.

Referência: https://www.websecurity.digicert.com/security-topics/how-does-ssl-handshake-work

O que é SSL e como ele protege um site

SSL (Secure Sockets Layer) e seu sucessor, TLS (Transport Layer Security), são protocolos para estabelecer links autenticados e criptografados entre computadores em rede. Embora o protocolo SSL tenha sido descontinuado com o lançamento do TLS 1.0 em 1999, ainda é comum se referir a essas tecnologias relacionadas como “SSL” ou “SSL / TLS”. A versão mais atual é o TLS 1.3, definido no RFC 8446 (agosto de 2018).

Chaves, certificados e Handshakes

SSL / TLS funciona vinculando as identidades de entidades, como sites e empresas, a pares de chaves criptográficas por meio de documentos digitais conhecidos como certificados X.509. Cada par de chaves consiste em uma chave privada e uma chave pública. A chave privada é mantida segura e a chave pública pode ser amplamente distribuída por meio de um certificado.

A relação matemática especial entre as chaves privadas e públicas em um par significa que é possível usar a chave pública para criptografar uma mensagem que só pode ser descriptografada com a chave privada. Além disso, o detentor da chave privada pode usá-la para assinar outros documentos digitais (como páginas da web) e qualquer pessoa com a chave pública pode verificar essa assinatura.

Se o próprio certificado SSL / TLS for assinado por uma autoridade de certificação (CA – certificate authority) publicamente confiável, como SSL.com, o certificado será implicitamente confiável para o software cliente, como navegadores da web e sistemas operacionais. CAs publicamente confiáveis ​​foram aprovadas pelos principais fornecedores de software para validar identidades que serão confiáveis ​​em suas plataformas. Os procedimentos de validação e emissão de certificados de uma CA pública estão sujeitos a auditorias regulares e rigorosas para manter esse status confiável.

Por meio do handshake SSL / TLS, as chaves privadas e públicas podem ser usadas com um certificado de confiança pública para negociar uma sessão de comunicação criptografada e autenticada pela Internet, mesmo entre duas partes que nunca se encontraram. Esse simples fato é a base da navegação segura na web e do comércio eletrônico como é conhecido hoje.

SSL / TLS e navegação segura na Web

O uso mais comum e conhecido de SSL / TLS é a navegação segura na web por meio do protocolo HTTPS. Um site HTTPS público configurado corretamente inclui um certificado SSL / TLS que é assinado por uma CA publicamente confiável. Os usuários que visitam um site HTTPS podem ter a certeza de:

Autenticidade: O servidor que apresenta o certificado possui a chave privada que corresponde à chave pública no certificado.

Integridade: Os documentos assinados pelo certificado (por exemplo, páginas da web) não foram alterados durante o trânsito por um intermediário.

Criptografia: As comunicações entre o cliente e o servidor são criptografadas.

Por causa dessas propriedades, SSL / TLS e HTTPS permitem que os usuários transmitam com segurança informações confidenciais, como números de cartão de crédito, números de previdência social e credenciais de login pela Internet, e garantam que o site para o qual eles estão enviando é autêntico. Com um site HTTP inseguro, esses dados são enviados como texto simples, prontamente disponível para qualquer bisbilhoteiro com acesso ao fluxo de dados. Além disso, os usuários desses sites desprotegidos não têm garantia confiável de terceiros de que o site que estão visitando é o que ele afirma ser.

Procure os seguintes indicadores na barra de endereço do seu navegador para ter certeza de que um site que você está visitando está protegido com um certificado SSL / TLS confiável:

  • Um ícone de cadeado fechado à esquerda do URL. Dependendo do seu navegador e do tipo de certificado instalado no site, o cadeado pode ser verde e / ou acompanhado de informações de identificação da empresa que o administra.
  • Se mostrado, o protocolo no início do URL deve ser https: //, não http: //. Observe que nem todos os navegadores exibem o protocolo.

Os navegadores de desktop modernos também alertam os visitantes sobre sites inseguros que não possuem um certificado SSL / TLS.

O que é SSL?

SSL (Secure Sockets Layer) e seu sucessor, TLS (Transport Layer Security), são protocolos para estabelecer links autenticados e criptografados entre computadores em rede. Embora o protocolo SSL tenha sido descontinuado com o lançamento do TLS 1.0 em 1999, ainda é comum se referir a essas tecnologias relacionadas como “SSL” ou “SSL / TLS”.

O que é um certificado SSL?

Um certificado SSL (também conhecido como certificado TLS ou SSL / TLS) é um documento digital que vincula a identidade de um site a um par de chaves criptográficas que consiste em uma chave pública e uma chave privada. A chave pública, incluída no certificado, permite que um navegador da web inicie uma sessão de comunicação criptografada com um servidor da web por meio dos protocolos TLS e HTTPS. A chave privada é mantida em segurança no servidor e é usada para assinar digitalmente páginas da web e outros documentos (como imagens e arquivos JavaScript).

Um certificado SSL também inclui informações de identificação sobre um site, incluindo seu nome de domínio e, opcionalmente, informações de identificação sobre o proprietário do site. Se o certificado SSL do servidor da web for assinado por uma autoridade de certificação (CA) publicamente confiável, como SSL.com, o conteúdo assinado digitalmente do servidor será considerado autêntico pelos navegadores da web e sistemas operacionais dos usuários finais.

O que é TLS?

TLS (Transport Layer Security), lançado em 1999, é o sucessor do protocolo SSL (Secure Sockets Layer) para autenticação e criptografia. O TLS 1.3 é definido na RFC 8446 (agosto de 2018).

Preciso de um endereço IP dedicado para usar SSL / TLS?

Antes, era um requisito obrigatório ter um IP dedicado para cada certificado SSL em um servidor web. Este não é mais o caso devido a uma tecnologia chamada Server Name Indication (SNI). Especificamente, sua plataforma de hospedagem terá que oferecer suporte a SNI.

Qual porta é recomendada para usar SSL / TLS?

Para compatibilidade máxima, a porta 443 é a porta padrão, portanto recomendada, usada para comunicações SSL / TLS seguras. No entanto, qualquer porta pode ser usada.

Qual é a versão atual do SSL / TLS?

TLS 1.3, definido em agosto de 2018 pela RFC 8446, é a versão mais recente de SSL / TLS. O TLS 1.2 (RFC 5246) foi definido em agosto de 2018 e também continua em amplo uso. As versões do SSL / TLS anteriores ao TLS 1.2 são consideradas inseguras e não devem mais ser usadas.

Quais são os problemas de segurança com as versões mais antigas do TLS?

As versões 1.0 e 1.1 do TLS são afetadas por um grande número de vulnerabilidades de protocolo e implementação que foram publicadas por pesquisadores de segurança nas últimas duas décadas. Ataques como ROBOT afetaram o algoritmo de troca de chave RSA, enquanto LogJam e WeakDH mostraram que muitos servidores TLS podem ser enganados em usar parâmetros incorretos para outros métodos de troca de chave. O comprometimento de uma troca de chaves permite que os invasores comprometam completamente a segurança da rede e descriptografem as conversas.

Ataques a cifras simétricas, como BEAST ou Lucky13, demonstraram que várias cifras suportadas em TLS 1.2 e anteriores, com exemplos incluindo cifras RC4 ou modo CBC, não são seguras.

Até as assinaturas foram afetadas, com o ataque de falsificação de assinatura RSA de Bleichenbacher e outros ataques de preenchimento semelhantes.

A maioria desses ataques foi mitigada no TLS 1.2 (desde que as instâncias do TLS estejam configuradas corretamente), embora o TLS 1.2 ainda seja vulnerável a ataques de downgrade, como POODLE, FREAK ou CurveSwap. Isso se deve ao fato de que todas as versões do protocolo TLS anteriores a 1.3 não protegem a negociação de handshake (que decide a versão do protocolo que será usada durante a troca).

RBAC: o começo de uma nova era para a GoCache

Depois de alguns meses de dedicação da equipe, temos orgulho em anunciar o lançamento de nosso painel multiusuário com gerenciamento de acesso via RBAC (Role Based Access Control). Pode parecer algo pouco significativo, mas o contexto e as premissas usadas no desenvolvimento são um marco para a evolução do posicionamento da GoCache.

TL:DR

  • O multiusuário e o RBAC são os primeiros passos de uma evolução do posicionamento da GoCache
  • O foco de nosso trabalho são empresas de tecnologia em crescimento, em processo de amadurecimento de suas práticas em DevOps e SRE, apoiadas ou não por MSPs e consultorias
  • Buscamos um modelo que pudesse ser flexível e versátil, mas sem complicar a vida de quem gerencia os controles de acesso

Novo posicionamento

Tem sido nítida a mudança no mercado de tecnologia nos últimos anos. Aplicações web e mobile têm cada vez mais protagonismo na estratégia de entrega de valor de empresas de diferentes verticais. Isso tem pressionado bastante os limites aceitáveis de performance, disponibilidade e, principalmente, segurança dessas aplicações. Por sua vez, novas práticas de desenvolvimento e operação vem emergindo para suportar este aumento de escala demandado, sem sair dos limites de qualidade aceitáveis mencionados anteriormente.

Porém, essas mudanças organizacionais não costumam vir sem um preço. Conceitos emergentes como microsserviços costumam não ser tão compatíveis com aplicações mais legadas, ou até mesmo com aplicações de empresas mais novas, mas que acabaram de encontrar seu fit com o mercado, uma vez que sua missão recente era provar valor e ainda era muito cedo para gastar recursos com preparação para escala.

É nessa hora que hora que a organização é posta em cheque. A implantação de mudanças de arquitetura, de processos e culturais, que elevariam a produtividade, concorrem com os mesmos recursos empregados nas antigas rotinas mais onerosas, em um ambiente com mais pressão por entregas e com uma expansão de equipe demorada e trabalhosa. Mesmo com a importante ajuda de MSPs e consultorias auxiliando na modernização da plataforma, o período de instabilidade demora meses, gerando mais riscos para a resiliência e principalmente, para a segurança das aplicações.

Por isso, a GoCache resolveu entrar também nessa batalha. Já estava no DNA usar nossa tecnologia para resolver problemas mais amplos de nossos clientes, como por exemplo, elaborar estratégias de cache dinâmico para reduzir o consumo do servidor de origem dos mesmos. Ampliaremos nossa capacidade de solução de problemas de resiliência e segurança para além do proporcionado por CDN/WAF, mas, especialmente dentro de um contexto: empresas digitais com pressões por escala, reestruturando suas equipes e processos. Nesse momento, o gerenciamento de infra e segurança da aplicação precisa ser compartilhado entre diferentes pessoas, times e até mesmo com outras organizações, como MSPs e consultorias. É aí que o multiusuário e o RBAC tornam-se um passo importante.

Por que RBAC

Tendo em vista segurança em primeiro lugar, é fundamental seguir o princípio do menor privilégio em uma ferramenta de infraestrutura e segurança gerida por pessoas em diferentes papéis. Dessa forma, o modelo de controle de acesso baseado em papéis (Role-based Access Control ou RBAC) veio de forma natural.

Alguém pode estar se perguntando por que não usar um modelo mais simples, como por exemplo, definir as permissões individualmente para cada usuário (conhecido tecnicamente como DAC ou Discretionary Access Control). O que parece mais simples quando você tem poucos usuários pode se tornar um inferno à medida que sua equipe cresce, e ainda pode piorar ambientes dinâmicos e/ou com rotatividade, como costuma ser o caso de empresas ganhando escala. A cada nova pessoa, você teria que definir cada permissão que ela pode ter. A cada mudança de posição dela, você precisaria rever cada um desses itens. A cada revisão de políticas de acesso da empresa, você teria que mapear cada usuário afetado e fazer a correção um por um.

Por outro lado, existem modelos mais flexíveis e modernos, como o ABAC (Attribute-based Access Control), em que as políticas de acesso são implementadas de acordo com atributos do usuário, dos recursos e do contexto. O problema desta abordagem, é que traria uma complexidade desnecessária em toda a experiência de uso da GoCache, uma vez que o administrador seria obrigado a definir atributos para cada usuário, como cargo e squad, e também dos recursos, como por exemplo, qual squad é dono do recurso. E também teria que desenvolver um processo para garantir que essas informações estivessem sempre corretamente atualizadas. Desenvolvemos o controle de acesso no formato RBAC, mas buscando trazer o melhor compromisso entre simplicidade e flexibilidade em seu design, como mostraremos a seguir.

Como o RBAC da GoCache se diferencia de outras CDNs?

Poderíamos adotar uma abordagem mais minimalista como a da Cloudflare, em que os papéis já são pré-definidos em agrupamentos genéricos de privilégios para todos os domínios da conta, como “Somente Leitura”, “Analytics” e “Cache Purge”. Mas logo na fase de pesquisa, percebemos que as políticas de acesso para cada papel podem variar muito de empresa para empresa. Ex.: em algumas empresas o suporte pode fazer limpeza de cache, em outras não. Em outras, um analista jr de segurança pode apenas gerenciar os IPs bloqueados pelo Firewall, mas não pode desativar o WAF. Daí podem derivar dois problemas: o privilégio de um papel pode ser permissivo demais e a cada novo usuário, ou mudança na organização, o administrador precisaria fazer match entre as políticas de sua empresa e quais papéis predefinidos ele deveria escolher para um usuário.

Outro problema, é o acesso a todos os domínios da conta. Temos clientes, como MSPs e consultorias de ecommerce, que fazem o gerenciamento da GoCache para seus clientes. E uma das demandas que aparecem com certa frequência, é a necessidade de compartilhar alguns recursos para seus clientes, como limpeza de cache, mas sem o mesmo ter acesso a todos os domínios dos outros clientes. Uma outra necessidade que pode surgir está relacionada a empresas que se compõe de múltiplos squads. O uso da GoCache como um gateway de entrada da aplicação, a partir das smart rules, em que são criadas regras de roteamento para diferentes serviços de acordo com o padrão de URL, vem se tornando mais comum. E uma tendência atual, é que a gestão de cada serviço seja delegada ao seu respectivo squad, portanto, a configuração de um squad não pode conflitar com o squad vizinho.

A Fastly tem uma abordagem para contornar esse problema, mas ainda tem suas limitações. Nela, cada usuário deve ter um papel e apenas um. Todos dão acesso a todas as propriedades da conta, com exceção de apenas um, o “Engineer”. Quando você configura este papel, você define em quais serviços o usuário pode limpar cache e/ou visualizar as configurações, ou fazer tudo. Além de faltar granularidade, essa configuração trabalhosa tem que ser feita em cada usuário com papel de engineer, mesmo que exista mais de um com o mesmo tipo de papel na empresa. Buscamos uma abordagem mais granular, mas procurando combater a complexidade por meio de duas características, como você verá a seguir: reuso e contexto de negócio.

Como funciona o RBAC da GoCache?

O painel multiusuário e controle de acesso RBAC da GoCache é dividido em 4 elementos: Usuários, Grupos de Usuários, Listas de Domínios e Modelos de Permissões. O grupo de usuários basicamente tem a mesma função dos “Papéis” no modelo RBAC. O que diferencia o modelo da GoCache é que ao definir um papel, no caso, um grupo de usuários, você já define o escopo onde um conjunto de privilégios será aplicado, sendo o escopo uma lista dos domínios em que você quer dar algum privilégio, e o conjunto de privilégios em si, é definido no que chamamos modelo de permissões. Abaixo, você pode ver um diagrama para entender melhor como funciona.

Diagrama do funcionamento do RBAC da GoCache

Exemplo da implementação de um grupo de usuários

Como o próprio nome diz, a granularidade mínima do escopo é por domínio. Optamos por isso em um primeiro momento, para evitar problemas de usabilidade, principalmente por haver configurações que podem afetar um domínio inteiro e gerar conflitos de interpretação. Mas estamos pesquisando formas de permitir mais granularidade, portanto, se for algo que faça sentido para sua empresa, entre em contato conosco, pois seu feedback pode ser importante para criarmos uma experiência incrível na resolução deste problema.

No modelo de permissões, você pode definir as ações (criar, atualizar, excluir, ler e ordenar) pertinentes em cada recurso de nosso painel/API. Por exemplo: você pode criar um modelo em que o usuário pode apenas atualizar entradas de DNS existentes, mas não pode criar ou excluir. Em um primeiro momento, pode parecer complexo, mas a intenção é que você configure isso apenas uma vez e possa reusá-lo em diferentes grupos de usuários. Além disso, trazer modelos já prontos de casos de uso comuns, como Todas as Permissões, Apenas Leitura, Apenas Limpeza de Cache e Permissões para Financeiro.

Exemplo de um modelo de Permissões.

Exemplo de Uso

Suponha que sua empresa seja uma plataforma de e-commerce com milhares de clientes. Ela acabou de se fundir com outra plataforma, e, por causa disso, metade dos domínios apontam para uma aplicação, metade para outra, sendo cada uma gerida por times diferentes. Os domínios de sua própria empresa também estão presentes na mesma conta, sendo alguns usados para o site institucional e landing pages, geridos pela equipe de marketing, e outros para abrigar seus painéis de controle, geridos por outros times específicos. Uma empresa desse perfil provavelmente ainda teria outros papéis, mas vamos parar por aqui para não ficar extenso. Como ficaria a configuração?

Podemos primeiro, criar os grupos de usuários “Time Aplicação A” e “Time Aplicação B”. De acordo com as políticas de sua empresa, esses times têm permissão somente para configurar Smart Rules, Cache e ver Analytics, apenas dos domínios das aplicações que eles gerem. O primeiro passo é criar um modelo de permissões com o nome “Times de aplicações” e ativar os privilégios que condizem com essa política, dentro desse modelo. Depois, você agrupa os domínios de cada aplicação nas listas “Aplicação A” e “Aplicação B”. São milhares de domínios? Não tem problema! Você pode gerir essas listas de domínios, assim como todos os recursos do multiusuário e RBAC, via API, podendo integrar com seus pipelines de automação, assim, sempre que um domínio de seus novos clientes entrar na GoCache, você já atualiza ele em sua devida lista de domínios. Por fim, é só vincular a lista de domínios “Aplicação A” e o modelo de permissões “Times de aplicações” no grupo de domínios “Time Aplicação A”, e fazer o mesmo de forma análoga com o time B.

Para dar privilégio ao time de marketing, o processo é o mesmo. Vamos supor que o marketing pode fazer exatamente o mesmo que os times de aplicação, mas apenas nos domínios da empresa. Você reaproveita o modelo de permissões já criado “Times de aplicações”, cria a lista de domínios “Marketing”, contendo apenas os domínios da empresa voltados a marketing, e vincula ambos ao grupo de usuários “Marketing”. Agora sobraram apenas os times responsáveis pelos dashboards. Se sua política for a mesma que a dos times de desenvolvimento, mas com a adição de gestão de DNS, você pode copiar o modelo de permissões times de desenvolvimento, adicionar as opções de DNS e renomeá-lo como “Times de dashboards”. Em seguida, você cria as listas de domínios de cada dashboard, e as vincula junto com o modelo de permissões aos seus respectivos grupos de usuários. Por último, você adiciona cada usuário ao seu respectivo grupo de usuários.

Visão final do exemplo de uso do RBAC

Esse é apenas o começo

Nossos clientes evoluíram, e estamos evoluindo junto para apoiá-los ainda mais neste momento difícil, mas recompensador. O multiusuário e RBAC são passos importantes para suportar essa evolução organizacional, mas apenas a base do que está por vir. O que estiver ao nosso alcance em termos de tratamento de tráfego web para trazer muito mais resiliência e segurança para aplicações, faremos, mas sempre de olho abordagem mais descomplicada que conseguirmos.