Qual ferramenta pode ser usada para explorar uma vulnerabilidade e conceder acesso a um sistema?

Veja neste documento como identificar produtos do Google Cloud e estratégias de mitigação para se proteger contra ataques comuns no nível do aplicativo descritos nos As 10 principais da OWASP 2017 (em inglês). As 10 principais da OWASP é uma lista da Open Web Application Security (OWASP) Foundation (em inglês) com os 10 principais riscos de segurança que todo proprietário de aplicativo precisa conhecer. Ainda que nenhum produto de segurança possa garantir proteção total contra esses riscos, aplicar esses produtos e serviços quando faz sentido na sua arquitetura pode contribuir para uma solução de segurança de várias camadas.

Para 2021, veja As 10 principais opções de mitigação da OWASP para 2021 no Google Cloud.

A infraestrutura do Google foi projetada para ajudar você a criar, implantar e operar serviços de maneira segura. A segurança física e operacional, a detecção de ameaças internas, a criptografia de dados em repouso e em trânsito, e muitos outros atributos importantes de uma infraestrutura segura são gerenciados pelo Google. Você herda esses benefícios implantando seus aplicativos no Google Cloud, mas talvez seja necessário tomar outras medidas para proteger seu aplicativo contra ataques específicos.

As estratégias de mitigação listadas neste documento são classificadas pelo risco de segurança do aplicativo e pelo produto do Google Cloud. Muitos produtos desempenham um papel na criação de uma estratégia de defesa em profundidade contra riscos de segurança na Web. Neste documento, fornecemos informações sobre como outros produtos podem reduzir os 10 principais riscos da OWASP, mas fornecemos mais detalhes sobre como o Google Cloud Armor e a Apigee podem reduzir uma grande variedade desses riscos. O Google Cloud Armor, atuando como um firewall de aplicativos da Web (WAF, na sigla em inglês), e a Apigee, como um gateway de API, pode ser especialmente útil no bloqueio de diferentes tipos de ataques. Esses produtos estão no caminho de tráfego da Internet e podem bloquear o tráfego externo antes de chegar aos seus aplicativos no Google Cloud.

Visão geral do produto

Os produtos do Google Cloud listados na tabela a seguir podem ajudar na proteção contra os 10 principais riscos de segurança:

A1: injeção

Falhas de injeção, como injeção de SQL, NoSQL, SO e LDAP, ocorrem quando dados não confiáveis são enviados para 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. Recomendamos que os dados do usuário sejam limpos ou filtrados pelo aplicativo antes de serem enviados a um intérprete.

As seções a seguir discutem os produtos do Google Cloud que podem ajudar a reduzir esse risco.

Apigee

Caso de uso:

• Bloqueio de injeção SQL
• Bloqueio de injeção NoSQL
• Bloqueio de injeção LDAP
• Bloqueio de injeção de JavaScript

A Apigee fornece várias políticas de validação de entradas para verificar se os valores fornecidos por um cliente correspondem às suas expectativas configuradas antes de permitir um processamento adicional das políticas ou regras. A Apigee, como um gateway para as solicitações de API recebidas, executa uma verificação de limite para garantir que a estrutura do payload esteja dentro de um intervalo aceitável. É possível configurar um proxy de API para que a rotina de validação de entrada transforme a entrada para remover sequências de caracteres arriscadas e, em seguida, substituí-las por valores seguros.

Há várias abordagens para validar a entrada com a plataforma Apigee:

• JSONThreatProtection verifica o payload JSON quanto a ameaças.
• XMLThreatProtection verifica o payload XML para ameaças.
• O JavaScript valida parâmetros e cabeçalhos.
• A política RegularExpressionProtection manipula injeções de código SQL.
• A política OASValidation valida uma mensagem recebida ou uma solicitação em uma especificação OpenAPI (JSON ou YAML).
• A política SOAPMessageValidation valida qualquer mensagem XML nos esquemas XSD e também pode validar mensagens SOAP em uma definição WSDL.

Container Threat Detection

Caso de uso:

• Detecção de script malicioso
• Detecção de shell reverso
• Detecção de instalação de malware

O detector Malicious Script Executed da Container Threat Detection analisa cada script de shell executado no sistema e informa aqueles que parecem maliciosos. de dados. Isso fornece um veículo para detectar ataques de injeção de comando do shell. Após a injeção de comando do shell, um invasor pode gerar um shell reverso, o que aciona o detector Reverse Shell. Como alternativa, é possível instalar malware, o que aciona os detectores Added Binary Executed e Added Library Loaded.

Google Cloud Armor

Caso de uso:

• Filtragem de injeção de SQL
• Filtragem de injeção de PHP

O Google Cloud Armor pode bloquear ataques comuns de injeção antes que eles cheguem ao seu aplicativo. Para injeção de SQL (SQLi), o Google Cloud Armor tem um grupo de regras predefinido que é baseado no Conjunto de regras principais do OWASP Modsecurity (versão 3.0.2 no momento da redação). É possível criar políticas de segurança que bloqueiam ataques SQLi definidas no grupo de regras principais usando a regra evaluatePreconfiguredExpr('sqli-stable') por si só ou em conjunto com outras regras personalizadas. Por exemplo, é possível limitar o bloqueio de SQLi a aplicativos específicos usando um filtro de caminho do URL.

Para injeção por PHP, existe outro conjunto de regras pré-configuradas. É possível usar a regra evaluatePreconfiguredExpr('php-stable') para bloquear ataques comuns de injeção de PHP.

Dependendo do seu aplicativo, ativar as expressões pré-configuradas pode levar a alguns falsos positivos, porque algumas das regras no conjunto de regras são bastante confidenciais. Para mais informações, consulte Solução de problemas com falsos positivos e Como ajustar o conjunto de regras para diferentes níveis de sensibilidade.

Para ataques de injeção diferentes de SQL ou PHP, crie regras personalizadas para bloquear solicitações quando palavras-chave ou padrões de escape específicos nesses protocolos forem usados no caminho da solicitação ou consulta. Verifique se esses padrões não aparecem em solicitações válidas. Também é possível limitar essas regras apenas para uso em endpoints ou caminhos específicos que possam interpretar os dados transmitidos a elas.

Além disso, alguns ataques de injeção podem ser atenuados usando as regras pré-configuradas para execução de código remoto e injeção de arquivo remota.

Web Security Scanner

Caso de uso:

• Monitoramento para injeção de SQL

O Web Security Scanner verifica vulnerabilidades nos aplicativos da Web e fornece detectores que monitoram ataques de injeção de SQL.

A2: autenticação inválida

A autenticação inválida é uma vulnerabilidade comum porque a autenticação de aplicativos e o gerenciamento de sessão geralmente são implementados incorretamente. Os invasores podem explorar falhas de implementação, como senhas comprometidas, chaves e tokens de sessão, para assumir as identidades de outros usuários temporária ou permanentemente.

Transparência no acesso

Caso de uso:

• Monitoramento do provedor de serviços
• Justificativas de acesso

Normalmente, para ter suporte prático de fornecedores externos, você precisaria conceder e compartilhar credenciais temporárias, o que cria o potencial para credenciais órfãs ou vazadas. O Access Approval é um serviço integrado que permite aprovar ou descartar as solicitações de acesso de funcionários do Google que trabalham para oferecer suporte à sua conta. Cada solicitação de acesso inclui uma justificativa de acesso para que você veja o motivo de cada acesso, incluindo referências a tíquetes de suporte.

Apigee

Caso de uso:

• Validação de chaves
• Validação de token
• Políticas do OAuth

A Apigee fornece políticas VerifyApiKey, OAuth e JSON Web Token (JWT), que ajudam a proteger contra essa vulnerabilidade.

A validação de chave de API é a forma mais simples de segurança baseada em aplicativo que pode ser configurada para uma API. Um aplicativo cliente apresenta uma chave de API com a solicitação. O Apigee Edge, por meio de uma política anexada a um proxy de API, verifica se a chave de API está em um estado aprovado para o recurso que está sendo solicitado.

O framework de autorização OAuth 2.0 permite que um aplicativo de terceiros tenha acesso limitado a um serviço HTTP, seja em nome de um proprietário de recursos, orquestrando uma interação de aprovação entre o proprietário do recurso e o serviço HTTP, ou em seu próprio nome, permitindo que o aplicativo de terceiros tenha acesso.

JSON Web Tokens, ou JWTs, geralmente são usados para compartilhar declarações ou asserções entre aplicativos conectados. A Apigee é compatível com JWT usando três políticas.

Event Threat Detection

Caso de uso:

• Detecção de força bruta
• Detecção de abuso de IAM

O Event Threat Detection monitora seu stream do Cloud Logging e aplica a lógica de detecção e a inteligência contra ameaças em um nível granular. Quando o Event Threat Detection detecta uma ameaça, ele grava uma descoberta no Security Command Center e no Cloud Logging no projeto de sua escolha. Os tipos de evento a seguir são úteis para identificar a autenticação inválida:

• Ataques de força bruta contra SSH. Detecte forças brutas bem-sucedidas do SSH em um host.
• Concessão anômala. Detecte privilégios concedidos a usuários do Gerenciamento de identidade e acesso (IAM, na sigla em inglês) fora da organização do Google Cloud.

Google Cloud Armor

Caso de uso:

• Limitar o acesso ao endpoint de autenticação
• Restringir o uso de token não autorizado

Os ataques contra vulnerabilidades classificadas com o risco de autenticação corrompido são mais bem reduzidos no nível do aplicativo ou por outros controles. No entanto, o Google Cloud Armor pode ajudar a limitar a superfície de ataque ou bloquear vetores de ataque conhecidos.

Por exemplo, se o aplicativo tiver uma base de usuários limitada e esses usuários vierem de um conjunto conhecido de endereços IP ou países, crie uma política de segurança que limite o acesso ao seu aplicativo para usuários desses blocos de endereços IP ou países. Essa política pode ajudar a reduzir a verificação automatizada de endpoints fora dessas áreas.

Se outros mecanismos de segurança detectarem que senhas, chaves ou tokens de sessão foram comprometidos, é possível bloquear o acesso a solicitações que contenham esses parâmetros em uma string de consulta usando uma regra personalizada. É possível atualizar de maneira programática as regras definidas anteriormente usando o método securityPolicy.patchRule. É possível identificar possíveis tokens roubados usando mecanismos de detecção de anomalias em registros de balanceamento de carga HTTP. Também é possível detectar possíveis adversários por meio da verificação de senhas comuns nesses registros.

Para bloquear ataques comuns de correção de sessão, use o conjunto de regras pré-configuradas do ModSecurity. É possível usar o conjunto de regras adicionando a regra evaluatePreconfiguredExpr('sessionfixation-stable') predefinida à sua política de segurança.

Se o aplicativo incluir alterações de senha na string de consulta, também será possível bloquear o uso de senhas comuns usando uma regra personalizada que corresponda ao atributo request.query. No entanto, se possível, essas verificações são muito melhores implementadas no lado do aplicativo.

Identity-Aware Proxy (IAP)

Caso de uso:

• Controle de acesso centralizado
• Funciona na nuvem e no local
• Proteja as conexões HTTP e TCP
• Acesso baseado no contexto

O IAP se integra ao balanceamento de carga HTTP(S) para que seja possível usar identidade e contexto para formar um muro de autenticação e autorização seguro em torno do aplicativo. Impeça a autenticação inválida no aplicativo voltado ao público provisionando usuários externos no Identity Platform (mais informações na seção a seguir).

Também é possível impedir a falha da autenticação para interfaces administrativas protegendo-as com o Identity-Aware Proxy e autenticando os usuários provisionados com o Identity and Access Management ou Cloud Identity Qualquer tentativa de acessar a ferramenta resulta em uma tentativa de autenticação registrada, seguida por uma verificação de autorização para garantir que o usuário autenticado tenha permissão para acessar o recurso solicitado.

Identity Platform

Caso de uso:

• Autenticação como serviço
• Autenticação multifator
• SLA corporativo
• Amplo suporte ao protocolo
• Inteligência de proteção da Conta do Google

O Identity Platform é a plataforma de gerenciamento de identidade e acesso do cliente (CIAM, na sigla em inglês) do Google Cloud que fornece autenticação segura como serviço com suporte para vários protocolos usando SDKs e APIs. Ele oferece autenticação multifator, integração com serviços de autenticação de terceiros e rastreamento de atividades auditáveis.

reCAPTCHA Enterprise

Caso de uso:

• Tentativas de login automáticas
• Exclusão de conteúdo
• Excesso de credenciais
• Transações fraudulentas
• Aquisições de contas
• Contas falsas
• Lavagem de dinheiro

O reCAPTCHA Enterprise fornece filtragem altamente eficaz contra bots e outras formas de automação e tráfego em massa pontuando o nível de risco das tentativas de acesso. É possível ajustar o modelo específico do site com feedback automatizado. O reCAPTCHA adapta as pontuações futuras ao seu site.

Security Health Analytics

Caso de uso:

• Aplicação de MFA/2FA
• Proteção de chave de API
• Aplicação de rotação de chaves de API

O Security Command Center ajuda a evitar falhas na autenticação, monitorando a conformidade da autenticação multifator e a integridade das suas chaves de API. É possível identificar solicitações suspeitas e bloqueá-las ou marcá-las para processamento especial.

Chaves de segurança Titan

Caso de uso:

• 2FA resistente a phishing
• Autenticação em dispositivos móveis e computadores

As chaves de segurança Titan usam a criptografia de chaves públicas para verificar a identidade do usuário e o URL da página de login para garantir que os invasores não possam acessar sua conta, mesmo que você seja induzido a fornecer seu nome de usuário e senha.

Web Security Scanner

Caso de uso:

• Vazamentos no identificador da sessão

O Web Security Scanner verifica seus aplicativos da Web em busca de vulnerabilidades, como vazamentos de ID de sessão, que permitem que outras partes personifiquem ou identifiquem um usuário de maneira exclusiva.

A3: exposição de dados confidenciais

A exposição de dados confidenciais pode acontecer devido à falta de criptografia ou à criptografia fraca em trânsito ou à exposição acidental de dados confidenciais. Os ataques a essas vulnerabilidades geralmente são específicos do aplicativo. Portanto, ele precisa de uma abordagem de defesa profunda para mitigar.

Apigee

Caso de uso:

• Proteja os dados confidenciais

Use o TLS unidirecional e bidirecional para proteger informações confidenciais no nível do protocolo.

Use políticas como Política de atribuição de mensagem e Política de JavaScript para remover os dados confidenciais antes que eles sejam retornados ao cliente.

Use técnicas padrão do OAuth e considere adicionar HMAC, hash, estado, nonce, PKCE ou outras técnicas para melhorar o nível de autenticação de cada solicitação.

Mascare dados confidenciais na ferramenta Edge Trace.

Criptografe dados confidenciais em repouso em mapas de chave-valor.

Inventário de recursos do Cloud

Caso de uso:

• SearchService
• Analisador de acesso

Um dos vetores mais comuns para exposição de dados é a infraestrutura de TI órfã ou não autorizada. Para identificar os servidores que ninguém está mantendo e os buckets com regras de compartilhamento excessivamente amplas, analise os dados de série temporal do recurso da nuvem.

Configure notificações em tempo real para alertar você sobre provisionamento inesperado de recursos que podem ser protegidos ou não autorizados de maneira inadequada.

API Cloud Data Loss Prevention

Caso de uso:

• Descoberta e classificação de dados confidenciais
• Mascaramento automático de dados

A API Cloud Data Loss Prevention (API DLP) permite verificar dados confidenciais em buckets ou bancos de dados para evitar vazamentos indesejados. Se os dados não permitidos forem identificados, eles poderão ser sinalizados ou editados automaticamente.

Cloud Key Management Service (Cloud KMS)

Caso de uso:

• Gerenciamento seguro de chaves criptográficas

Evite a exposição potencial das suas chaves criptográficas usando um serviço gerenciado e auditado. Um serviço de gerenciamento de chaves armazenado na nuvem que permite que você gerencie chaves de criptografia simétricas e assimétricas nos seus serviços em nuvem da mesma forma que faz nos locais. É possível gerar, usar, alternar e destruir chaves criptográficas AES256, RSA 2048, RSA 3072, RSA 4096, EC P256 e EC P384.

Cloud Load Balancing

Caso de uso:

• Controle de criptografia SSL/TLS detalhado

As políticas de SSL podem ajudar a evitar a exposição de dados confidenciais, dando a você controle sobre os recursos e criptografias SSL/TLS permitidos em um balanceador de carga. Bloqueie criptografias não aprovadas ou não seguras, conforme necessário.

Google Cloud Armor

Caso de uso:

• Filtrar URLs de ataques conhecidos
• Restringir o acesso a endpoints confidenciais

Em geral, a exposição de dados confidenciais precisa ser interrompida na origem, mas como todo ataque é específico do aplicativo, os firewalls de aplicativos da Web só podem ser usados de maneira limitada para impedir amplamente a exposição dos dados. No entanto, se não for possível aplicar patches ao aplicativo imediatamente, restrinja o acesso a endpoints vulneráveis ou padrões de solicitação usando as regras personalizadas do Google Cloud Armor.

Por exemplo, vários desafios do Juice Shop sobre exposição a dados confidenciais podem ser explorados devido à travessia de diretórios insegura e ataques de injeção de bytes nulos. É possível mitigar essas injeções verificando as strings no URL com a seguinte expressão personalizada:

request.path.contains("%00") || request.path.contains("%2500")

É possível resolver o desafio das métricas expostas acessando o subdiretório /metrics que é usado pelo Prometheus. Se você tiver um endpoint confidencial como esse exposto e não puder remover imediatamente o acesso, é possível restringir o acesso a ele, exceto para determinados intervalos de endereço IP. Use uma regra semelhante à seguinte expressão personalizada:

request.path.contains("/metrics") && !(inIpRange(origin.ip, '1.2.3.4/32')

Substitua 1.2.3.4/32 pelo intervalo de endereços IP que precisa ter acesso à interface das métricas.

Os arquivos de registros expostos acidentalmente são usados para resolver um dos desafios do Juice Shop. Para evitar a exposição dos registros, defina uma regra que não permita o acesso aos arquivos de registros completamente: request.path.endsWith(".log").

Identity-Aware Proxy e acesso baseado no contexto

Caso de uso:

• Acesso remoto seguro a serviços confidenciais
• Controle de acesso centralizado
• Acesso baseado no contexto

Use identidade e contexto para formar uma autenticação e autorização seguras em torno de seu aplicativo. Implante ferramentas, como relatórios internos de bugs, base de conhecimento corporativa ou e-mail por trás do IAP, para permitir o acesso baseado no contexto somente a pessoas autorizadas em qualquer lugar da Internet.

Com o acesso baseado no contexto, é possível aplicar controles de acesso granulares a aplicativos da Web, máquinas virtuais (VMs), APIs do Google Cloud e aplicativos do Google Workspace com base na identidade de um usuário e no contexto da solicitação sem uma VPN tradicional. Com base no modelo de segurança de confiança zero e na implementação do BeyondCorp do Google, o acesso baseado no contexto permite que você forneça acesso aos usuários, aplique controles granulares e use uma única plataforma para sua nuvem e nos aplicativos locais e recursos de infraestrutura.

Secret Manager

Caso de uso:

• Chaves de criptografia
• Chaves de API
• Outras credenciais do sistema

O Secret Manager é um serviço de armazenamento seguro para os dados mais valiosos, como chaves de API, senhas de contas de serviço e recursos criptográficos. O armazenamento central desses secrets permite que você confie nos sistemas de autenticação e autorização do Google Cloud, incluindo o IAM, para determinar se alguma solicitação de acesso é válida.

O Secret Manager não foi projetado para operações em grande escala, como tokenização de cartões de crédito ou armazenamento de senha de usuário individual. Esses aplicativos precisam depender do Identity Platform para o CIAM, do Cloud Identity para os membros da organização ou de um software de tokenização dedicado.

Security Health Analytics

Caso de uso:

• Aplicação de MFA/2FA
• Proteção de chave de API
• Aplicação de rotação de chaves de API
• Privacidade de imagem do Compute
• Aplicação da regra de chave SSH
• Monitoramento da inicialização segura
• Segurança de acesso à API
• Monitoramento de políticas de SSL
• Geração de registros desativada
• Alertas de ACL de bucket público

Evite a exposição de dados confidenciais monitorando a conformidade com a autenticação multifator e a integridade das chaves de API. Receba alertas de configurações não seguras no armazenamento de imagens de contêiner, Cloud Storage, política de SSL, política de chave SSH, geração de registros, acesso à API, entre outros.

VirusTotal

Caso de uso:

• Prevenção contra phishing

O VirusTotal permite que você verifique URLs de conteúdo malicioso antes de apresentá-los aos seus usuários ou funcionários, sejam eles encontrados na entrada do usuário, e-mails, bate-papo, registros ou outros locais.

VPC Service Controls

Caso de uso:

• Firewall para serviços gerenciados

Encapsule serviços gerenciados em um firewall para controlar quem pode chamar o serviço e a quem ele pode responder. Bloqueie a saída não autorizada e a exfiltração de dados com regras de perímetro de saída em serviços como o Cloud Functions. Impeça solicitações de usuários e locais não autorizados para armazenamentos e bancos de dados gerenciados. Crie perímetros seguros em torno de APIs avançadas ou potencialmente caras.

Scanner de aplicativos da Web

Caso de uso:

• Leitor de risco de segurança para aplicativos da Web
• Leitor de disponibilidade do repositório de origem

Para impedir que seu aplicativo da Web exponha dados confidenciais, certifique-se de que as senhas não sejam enviadas em texto simples. Evite vazar código-fonte bruto potencialmente destrutivo verificando repositórios de código-fonte expostos do git e do Apache Subversion. Essas verificações são projetadas para abranger os 10 principais controles da OWASP.

Web Security Scanner

Caso de uso:

• Senhas não criptografadas transmitidas pela rede
• Vulnerabilidades de segurança identificadas

O Web Security Scanner verifica seus aplicativos da Web e relata os resultados de erros e vulnerabilidades. Ele segue links e tenta acionar o máximo possível de entradas do usuário e manipuladores de eventos.

Se o aplicativo transmitir senhas em texto não criptografado, o Web Security Scanner vai gerar uma descoberta CLEAR_TEXT_PASSWORD. Se as senhas inseridas no aplicativo da Web puderem ser armazenadas em cache em um navegador normal em vez de um armazenamento de senhas seguro, o Web Security Scanner gerará uma descoberta CACHEABLE_PASSWORD_INPUT.

A4: entidades XML externas (XXE)

Os ataques a entidades externas XML exploram vulnerabilidades em processadores XML ao se referir a entidades externas. É possível atenuar esses ataques evitando o uso de transferências de dados XML de e para clientes externos e desativando o processamento de XXE em analisadores XML.

Este conceito é ampliado para incluir documentos e configurações não XML que podem referenciar ou incluir entidades externas, por exemplo, uma configuração JSON com uma referência de esquema externo ou uma configuração de contêiner que extrai em bibliotecas externas ou binários não agrupados na imagem.

Apigee

Caso de uso:

• Bloquear ataques XXE usando LFI/RFI (inclusão de arquivos locais, inclusão de arquivos remotos)

A Apigee tem um analisador XML integrado que usa XPath para extrair dados. Ele tem uma política XMLThreatProtection para proteger contra payloads XML maliciosos.

A política ExtractVariables da Apigee permite extrair o conteúdo de uma solicitação ou resposta e atribuí-lo a uma variável. É possível extrair qualquer parte da mensagem, incluindo cabeçalhos, caminhos de URI, payloads JSON/XML, parâmetros de formulário e parâmetros de consulta. A política funciona aplicando um padrão de texto ao conteúdo da mensagem e, quando encontra uma correspondência, define uma variável com o conteúdo da mensagem especificada.

Google Cloud Armor

Caso de uso:

• Filtrar ataques XXE usando LFI/RFI (inclusão de arquivo local, inclusão de arquivos remotos)

Como os XXEs podem ser complexos e ter diferentes formatos, as possibilidades de mitigação por firewalls de aplicativos da Web são limitadas. Os ataques são melhor minimizados com a aplicação de patches em analisadores XML, com a proibição de entidades externas e a limitação mínima das transferências de dados XML em servidores da Web públicos. No entanto, dependendo do aplicativo e do tipo de ataque, o Google Cloud Armor ainda pode ajudar na defesa contra a exfiltração de dados e outros impactos.

Embora nenhuma regra no Conjunto de regras principais do OWASP ModeSecurity se proteja especificamente contra ataques XXE, as regras de inclusão de arquivo local (LFI, na sigla em inglês) e inclusão de arquivo remoto (RFI, na sigla em inglês) podem ajudar a combater alguns desses ataques. Por exemplo, o desafio de acesso a dados do Juice Shop XXE exige que o invasor recupere arquivos locais no servidor. A solução desse desafio deixará de funcionar se você usar a regra evaluatePreconfiguredExpr('lfi-stable') em uma política de segurança do Google Cloud Armor.

Web Security Scanner

Caso de uso:

• Entidade externa XML (XXE)

O Web Security Scanner monitora vulnerabilidades, como vulnerabilidades do XXE.

Para mais informações, consulte Visão geral do Web Security Scanner.

A5: controle de acesso corrompido

Controle de acesso corrompido refere-se a controles de acesso que são apenas parcialmente aplicados no lado do cliente ou fracamente implementados. A mitigação desses controles geralmente requer uma regravação no lado do aplicativo para garantir que os recursos sejam acessados corretamente por usuários autorizados.

Apigee

Caso de uso:

• Aplicação do controle de acesso
• Limitar a manipulação de dados

A Apigee é compatível com uma abordagem em camadas para implementar controles de acesso e evitar que os usuários mal-intencionados façam alterações não autorizadas ou acessem o sistema.

Configure o controle de acesso baseado em papéis (RBAC) para permitir que os usuários só acessem a funcionalidade e a configuração necessárias. Crie mapas de chave-valor criptografados para armazenar pares de chave-valor confidenciais, que aparecem mascarados na IU do Edge e nas chamadas da API de gerenciamento. Configure o Logon único com o provedor de identidade da sua empresa.

Configure portais do desenvolvedor para mostrar produtos de API específicos de acordo com o papel do usuário. Configure o portal para mostrar ou ocultar conteúdo com base no papel do usuário.

Inventário de recursos do Cloud

Caso de uso:

• Monitorar a shadow IT
• Instâncias de computação desatualizadas

Um dos vetores mais comuns para exposição de dados é a infraestrutura de TI órfã ou não autorizada. Configure notificações em tempo real para alertar você sobre recursos em execução inesperados, que podem ser protegidos incorretamente ou usar software desatualizado.

Cloud Load Balancing

Caso de uso:

• Controle de criptografia SSL/TLS detalhado

Impeça o uso de criptografias SSL/TLS fracas, atribuindo um grupo predefinido ou uma lista personalizada de criptografias que o Cloud Load Balancing possa usar.

Forseti Scanner

Caso de uso:

• Monitoramento da configuração de controle de acesso

Monitore sistematicamente os recursos do Google Cloud com o objetivo de garantir que os controles de acesso sejam definidos conforme o esperado. Crie políticas baseadas em regras para codificar sua posição de segurança. Se a configuração for alterada inesperadamente, o Forseti Scanner notificará você para que seja possível reverter automaticamente para um estado conhecido.

Google Cloud Armor

Caso de uso:

• Filtrar solicitações de origem cruzada
• Filtrar ataques de inclusão de arquivo local/remoto
• Filtrar ataques de poluição do parâmetro HTTP

Muitos casos de controle de acesso corrompido não podem ser atenuados com o uso de um firewall de aplicativos da Web, porque os aplicativos não exigem ou não verificam corretamente os tokens de acesso a cada solicitação, e os dados podem ser manipulados no lado do cliente. Vários desafios do Juice Shop relacionados ao controle de acesso interrompido, por exemplo, postagem de feedback no nome de outro usuário, use o fato de que algumas solicitações não são autenticadas no servidor. Como é possível ver na solução de desafio, a exploração dessa vulnerabilidade é completamente do lado do cliente e, portanto, não pode ser atenuada com o Google Cloud Armor.

Alguns desafios podem ser parcialmente mitigados no lado do servidor se o aplicativo não puder ser corrigido imediatamente.

Por exemplo, se ataques de falsificação de solicitação entre sites (CSRF, na sigla em inglês) forem possíveis porque seu servidor da Web implementa o compartilhamento de recursos entre origens (CORS, na sigla em inglês) mal, como demonstrado no desafio da CSRF Juice Shop, é possível atenuar isso bloqueando solicitações de origens inesperadas com uma regra personalizada. A regra a seguir corresponde a todas as solicitações com origens diferentes de example.com e google.com:

has(request.headers['origin']) &&
!((request.headers['origin'] == 'https://example.com')||
(request.headers['origin'] == 'https://google.com') )

Quando o tráfego que corresponde a essa regra é negado, a solução do desafio CSRF deixa de funcionar.

No caso de ataques de falsificação de solicitação do lado do servidor (SSRF), como o desafio do Juice Shop SSRF, usando os conjuntos de regras de inclusão remota de arquivos (RFI, na sigla em inglês) ou de arquivos locais pré-configurados podem ajudar a atenuar alguns desses ataques, porque eles bloqueiam a inclusão de URLs ou a passagem de caminhos. Por exemplo, a regra a seguir ativa os dois conjuntos de regras:

evaluatePreconfiguredExpr('lfi-stable') ||
evaluatePreconfiguredExpr('rfi-stable')

Quando essa regra é implementada, a solução do desafio SSRF também para de funcionar.

O desafio da manipulação da cesta de compras usa poluição do parâmetro HTTP como é possível ver ao seguir como atacar a loja seguindo a solução de desafio. A poluição do parâmetro é detectada como parte do conjunto de regras de ataque ao protocolo. Para ajudar a bloquear esse tipo de ataque, use a seguinte regra: evaluatePreconfiguredExpr('protocolattack-stable').

Identity-Aware Proxy e acesso baseado no contexto

Caso de uso:

• Controle de acesso centralizado
• Funciona na nuvem e no local
• Protege conexões HTTP e TCP
• Acesso baseado no contexto

Com o IAP, é possível usar identidade e contexto para formar um bloqueio de autenticação e autorização seguros para seu aplicativo. Evite autorização inválida ou controle de acesso ao aplicativo voltado ao público com um sistema de autenticação e autorização gerenciado centralmente criado no Cloud Identity e no IAM.

Aplique controles de acesso granulares a aplicativos da Web, VMs, APIs do Google Cloud e aplicativos do Google Workspace com base na identidade do usuário e no contexto da solicitação sem a necessidade de uma VPN tradicional. Use uma única plataforma para aplicativos de nuvem e aplicativos locais e recursos de infraestrutura.

Security Health Analytics

Caso de uso:

• Aplicação de MFA/2FA
• Proteção de chave de API
• Monitoramento de políticas de SSL

Impeça o controle de acesso corrompido monitorando a conformidade da autenticação multifator, a política de SSL e a integridade das suas chaves de API.

Web Security Scanner

Caso de uso:

• Repositórios expostos ao público
• Validação não segura de cabeçalho de solicitação

O Web Security Scanner verifica seus aplicativos da Web em busca de vulnerabilidades, como repositórios de códigos visíveis publicamente e validação incorreta dos cabeçalhos da solicitação.

A6: configuração incorreta de segurança

Configuração incorreta de segurança refere-se a falhas de aplicativo não corrigidas, contas padrão abertas e arquivos e diretórios desprotegidos que normalmente podem ser evitados com o aumento da proteção do aplicativo. A configuração incorreta de segurança pode acontecer de várias maneiras, como confiar em configurações padrão, criar configurações parciais que podem ser inseguras, permitir que mensagens de erro contenham detalhes confidenciais, armazenar dados na nuvem sem controles de segurança adequados ou configurar incorretamente. cabeçalhos HTTP.

Apigee

Caso de uso:

• Gerenciar configurações de segurança
• Monitorar configurações de segurança

Um fluxo compartilhado permite que os desenvolvedores de API combinem políticas e recursos em um grupo reutilizável. Ao capturar funcionalidades reutilizáveis em um só lugar, um fluxo compartilhado ajuda a garantir consistência, reduzir o tempo de desenvolvimento e gerenciar o código com mais facilidade. É possível incluir um fluxo compartilhado dentro de proxies de API individuais usando uma Política FlowCallout ou inserir fluxos compartilhados em ganchos de fluxo para executar automaticamente a lógica de fluxo compartilhado para cada proxy de API implantado no mesmo ambiente.

Inventário de recursos do Cloud

Caso de uso:

• Serviço de notificação em tempo real

As notificações em tempo real podem alertar você sobre o provisionamento inesperado de recursos que podem estar protegidos de forma inadequada ou não autorizados.

Cloud Load Balancing

Caso de uso:

• Controle de criptografia SSL/TLS detalhado

Impeça o uso de criptografias SSL/TLS vulneráveis e conhecidas atribuindo um grupo predefinido ou uma lista personalizada de criptografias utilizáveis por um balanceador de carga.

Google Cloud Armor

Caso de uso:

• Filtrar endpoints não seguros
• Filtrar ataques de inclusão de arquivo local/remoto
• Filtrar ataques de protocolo

Como a configuração incorreta de segurança pode ocorrer no nível do aplicativo, a OWASP Foundation recomenda que você proteja e corrija seu aplicativo diretamente e remova todos os recursos desnecessários.

Um firewall de aplicativos da Web (WAF), como o Google Cloud Armor, não pode ajudar a corrigir a configuração incorreta, mas é possível bloquear o acesso a partes do aplicativo totalmente ou para todos, exceto para endereços IP específicos ou países. Restringir o acesso pode reduzir o risco de exploração incorreta dessas configurações.

Por exemplo, se o aplicativo expõe uma interface administrativa usando um URL comum, como /admin, é possível restringir o acesso a essa interface mesmo que ela esteja autenticada. É possível fazer isso com uma regra de negação, por exemplo:

request.path.contains("/admin") && !(inIpRange(origin.ip,
'1.2.3.4/32')

Substitua 1.2.3.4/32 pelo intervalo de endereços IP que deve ter acesso à interface do administrador.

Algumas configurações incorretas podem ser parcialmente atenuadas usando os conjuntos de regras de inclusão de arquivos local ou inclusão de arquivos remota (RFI, na sigla em inglês) predefinidos. Por exemplo, a exploração do desafio de imagiologia entre sites do Juice Shop não é bem-sucedida quando o conjunto de regras LFI é aplicado. Use a regra evaluatePreconfiguredExpr('lfi-stable') || evaluatePreconfiguredExpr('rfi-stable') para bloquear solicitações usando os conjuntos de regras de LFI e RF e ajuste as regras conforme necessário. É possível verificar se a solução de desafio não será mais bem-sucedida.

Alguns ataques HTTP também podem ser reduzidos com o uso de conjuntos de regras pré-configurados:

• Para evitar violação de verbo HTTP, use o conjunto de regras de aplicação do método (na visualização). Use a regra evaluatePreconfiguredExpr('methodenforcement-stable') para proibir métodos de solicitação HTTP diferentes dos métodos GET, HEAD, POST e OPTIONS.
• Para bloquear ataques comuns de análise e proxies HTTP, como tráfego de solicitação HTTP, divisão de resposta HTTP e Injeção de cabeçalho HTTP, use o conjunto de regras de ataque do protocolo usando a regra evaluatePreconfiguredExpr('protocolattack-stable').

Security Health Analytics

Caso de uso:

• Monitoramento e alertas de controle de segurança

Monitore dúzias de sinais por meio de uma única interface para garantir que o aplicativo mantenha as práticas recomendadas de segurança.

Web Security Scanner

Caso de uso:

• Scanner de aplicativos da Web personalizado para os 10 principais da OWASP
• Configuração do servidor HTTP
• Conteúdo HTTP/HTTPS misto

O Web Security Scanner monitora erros comuns de segurança, como incompatibilidades de tipo de conteúdo, cabeçalhos de segurança inválidos e exibição de conteúdo misto. Essas verificações são projetadas para abranger os 10 principais controles da OWASP.

Os seguintes detectores verificam configurações incorretas de segurança:

• INVALID_CONTENT_TYPE
• INVALID_HEADER
• MISMATCHING_SECURITY_HEADER_VALUES
• MISSPELLED_SECURITY_HEADER_NAME
• MIXED_CONTENT

Para mais informações sobre esses e outros detectores, consulte a Visão geral do Web Security Scanner.

A7: scripting em vários locais (XSS)

O scripting em vários locais (XSS) permite que invasores executem scripts em navegadores da Web para controlar sessões do usuário, manipular sites ou afetar usuários de maneira mal-intencionada de outras maneiras.

Apigee

Caso de uso:

• Detecção de XSS

A Apigee fornece políticas de proteção contra ameaças que podem proteger contra XSS na API.

O compartilhamento de recursos entre origens (CORS, na sigla em inglês) é uma das implementações comuns da política de mesma origem aplicada por todos os navegadores. É possível implementar o CORS usando a política AttributionMessage (links em inglês). Usando expressões regulares, com a política RegularExpressionProtection ou política JavaScript verifique os valores de payload e parâmetro para JavaScript e outros ataques por tipos de injeção.

Google Cloud Armor

Caso de uso:

• Filtrar padrões XSS
• Filtrar ataques de protocolo

É possível bloquear ataques XSS comuns usando o conjunto de regras predefinido para ataques XSS. É possível inserir a regra evaluatePreconfiguredExpr('xss-stable') sozinha ou combiná-la a outras expressões usando a linguagem de regras personalizadas. Siga as orientações sobre solução de problemas de falsos positivos e ajuste o conjunto de regras para diferentes níveis de sensibilidade.

O uso desse conjunto de regras predefinidas pode bloquear a maioria dos ataques XSS definidos por meio dos desafios de XSS na OWASP Juice Shop, por exemplo, a API - Apenas o desafio XSS que usa o payload de XSS dentro do corpo POST das solicitações HTTP.

No entanto, não é possível bloquear todos os ataques de XSS dessa maneira. Alguns ataques XSS usam apenas a funcionalidade do lado do cliente, por exemplo, o desafio XSS do DOM. Como é possível ver na solução de desafio do desafio XSS do DOM, não é necessário ter uma interação com o servidor para que o ataque seja concluído. Esses tipos de ataques não podem ser atenuados com qualquer firewall de aplicativos da Web (WAF), porque nenhuma chamada do lado do servidor está envolvida. Em vez disso, você precisa corrigir o aplicativo do lado do cliente.

Alguns outros ataques não podem ser atenuados com o conjunto de regras predefinido do Google Cloud Armor porque não são capturados pelo conjunto de regras principais do OWASP Modsecurity. Esses são ataques incomuns. Por exemplo, o desafio de XSS refletido exige que você ataque o aplicativo com consultas que tenham o payload de XSS no caminho do URL, não a consulta ou o corpo POST, conforme detalhado na solução de desafios para o desafio XSS refletido. Ter o caminho do URL analisado sem refletir não é uma vulnerabilidade comum. O desafio do XSS do cabeçalho HTTP exige que você envie o payload do XSS em um cabeçalho HTTP proprietário, conforme descrito na solução de desafio XSS do cabeçalho HTTP. Se você estiver ciente das vulnerabilidades do seu aplicativo, esses tipos de ataques poderão ser atenuados com as regras personalizadas do Google Cloud Armor.

Alguns ataques XSS também são ativados por configurações incorretas do servidor HTTP subjacente, como ataques de Divisão de resposta HTTP e Injeção de cabeçalho HTTP. Use o conjunto de regras de ataque ao protocolo usando a regra evaluatePreconfiguredExpr('protocolattack-stable') para bloquear ataques detectados por esse conjunto de regras.

Security Command Center Web Application Scanner

Caso de uso:

• Detecção de XSS

Monitore para erros comuns de segurança, como vulnerabilidades de XSS e configurações incorretas do AngularJS específicas.

Web Security Scanner

Caso de uso:

• Monitoramento para scripting em vários locais

O Web Security Scanner verifica se há vulnerabilidades nos aplicativos da Web e fornece detectores para monitorar ataques de scripting em vários locais.

A8: desserialização não segura

Os invasores podem usar falhas na desserialização para diferentes tipos de ataques, como repetição, escalonamento de privilégios e injeção. A desserialização insegura também pode ativar a execução remota de código (RCE).

Google Cloud Armor

Caso de uso:

• Bloquear execução de código remoto

Como a maioria dos ataques contra a desserialização insegura é específica de um aplicativo, há apenas algumas maneiras de atenuar esses ataques. Por exemplo, usando um firewall de aplicativos da Web (WAF, na sigla em inglês), como o Google Cloud Armor. O OWASP recomenda que você não aceite objetos serializados de fontes não confiáveis. Se possível, restrinja os endpoints que aceitam esses objetos a um conjunto de endereços IP confiáveis com uma regra de negação semelhante à seguinte:

request.path.contains("/endpoint") && !(inIpRange(origin.ip,
'1.2.3.4/32')

Substitua:

• /endpoint: o caminho do endpoint que aceita objetos serializados
• 1.2.3.4/32: o intervalo de endereços IP que precisa manter o acesso à interface.

Para reduzir os ataques típicos contra desserialização insegura que usam a execução de código remoto (RCE, na sigla em inglês), use o conjunto de regras predefinido contra ataques RCE. É possível usar a regra evaluatePreconfiguredExpr('rce-stable') para bloquear ataques comuns do RCE nos shells do UNIX e do Windows.

Os ataques RCE descritos nos desafios do Juice Shop para desserialização não segura executam funções e expressões regulares no Node.js no servidor. Esses tipos de ataques não são bloqueados pelo conjunto de regras RCE predefinido e pela regra correspondente OWASP Modsecurity e precisam ser atenuados com o uso de patches no lado do servidor ou regras personalizadas.

VirusTotal

Caso de uso:

• Verificação de dados não confiável

A API do VirusTotal permite que você faça upload e verifique arquivos em busca de malware. É possível verificar imagens, documentos, binários e outros dados não confiáveis antes que eles sejam processados para eliminar determinadas categorias de entradas mal-intencionadas.

Web Security Scanner

Caso de uso:

• Desserialização não segura

O Web Security Scanner verifica os aplicativos da Web em busca de vulnerabilidades. Por exemplo, se você estiver usando uma versão do Apache Struts que torna seu aplicativo vulnerável a ataques de injeção de comando remoto, o Web Security Scanner gera uma descoberta de STRUTS_INSECURE_DESERIALIZATION.

A9: como usar componentes com vulnerabilidades conhecidas

Componentes com vulnerabilidades conhecidas (em inglês) é uma categoria para vetores de ataque genéricos, e essas vulnerabilidades são melhor reduzidas com o monitoramento e o upgrade rápido de todos os componentes do aplicativo.

Caso de uso:

• Restrinja clusters do GKE a contêineres confiáveis

A autorização binária é um controle de segurança no momento da implantação que ajuda a garantir que apenas imagens de contêiner confiáveis sejam implantadas no Google Kubernetes Engine (GKE). Com a autorização binária, é possível exigir que as imagens sejam assinadas por autoridades confiáveis durante o processo de desenvolvimento e, em seguida, aplicar a validação de assinatura ao implantar. Ao aplicar a validação, é possível ter certeza de que o processo de criação e lançamento usa apenas imagens verificadas.

Cloud Load Balancing

Caso de uso:

• Controle de criptografia SSL/TLS detalhado

Para impedir o uso de criptografias SSL/TLS conhecidas, atribua um grupo predefinido ou uma lista personalizada de criptografias que o Cloud Load Balancing pode usar.

Container Threat Detection

Caso de uso:

• Detecção de script malicioso
• Detecção de shell reverso
• Detecção de instalação de malware

Se um invasor se aproveitar de um componente vulnerável e executar um script malicioso, o detector Malicious Script Executed do Container Threat Detection vai gerar uma descoberta. Se um invasor gerar um shell reverso, o detector Reverse Shell gerará uma descoberta. Se um invasor instalar malware, os detectores Added Binary Executed e Added Library Loaded vão gerar descobertas.

Event Threat Detection

Caso de uso:

• Detecção de criptomineração
• Detecção de malware
• Exfiltração de dados
• DoS de saída

O Event Threat Detection monitora seu stream do Cloud Logging e aplica a lógica de detecção e a inteligência contra ameaças em um nível granular. Quando o Event Threat Detection detecta uma ameaça, ele grava o que encontra no Security Command Center e em um projeto do Cloud Logging. As regras de detecção a seguir são úteis para detectar os efeitos do uso de componentes com vulnerabilidades conhecidas:

• Criptomineração. Detectar criptomineração com base em solicitações de DNS ou conexão com endereços de mineração conhecidos
• Malware. Detecte solicitações de DNS baseadas em malware ou conexão com endereços inválidos conhecidos.
• Exfiltração para tabela externa. Detecte recursos salvos fora da organização, como operações de cópia ou transferência.
• DoS de saída. Detecte vulnerabilidades exploradas que tentam ataques de negação de serviço.

Google Cloud Armor

Caso de uso:

• Bloquear o acesso a endpoints de apps não utilizados
• Bloquear vetores de ataque comuns

Um firewall de aplicativos da Web (WAF), como o Google Cloud Armor, não deve ser usado como uma única estratégia de mitigação para bloquear ataques contra essa categoria, porque os ataques geralmente são específicos da biblioteca e não podem ser bloqueados por conjuntos de regra pré-configurada ou não pode receber patches do lado do servidor. Monitorar e fazer upgrade regularmente de todos os componentes do aplicativo é a única opção para reduzir esse tipo de vulnerabilidade.

No entanto, o Google Cloud Armor pode ajudar a reduzir alguns ataques comuns contra aplicativos vulneráveis por meio de regras pré-configuradas para execução de código remoto, inclusão de arquivo local ou inclusão de arquivo remoto.

Se você estiver ciente de componentes vulneráveis no seu aplicativo, mas não puder corrigi-lo imediatamente, bloqueie o acesso a essas partes do aplicativo para reduzir temporariamente o risco de uma exploração desses componentes. Crie uma regra personalizada que corresponda ao caminho do URL ou às consultas que acessam esses componentes vulneráveis e negam o acesso. Se você precisar acessar esses componentes de usuários ou locais específicos, ainda poderá permitir que determinados endereços IP de origem confiáveis acessem esses componentes. Uma regra que usa o caminho do URL é semelhante a esta:

`request.path.contains("/component") && !(inIpRange(origin.ip,
'1.2.3.4/32')

Substitua:

• /component: o caminho do componente com vulnerabilidades conhecidas
• 1.2.3.4/32: o intervalo de endereços IP que precisa manter o acesso à interface.

Se houver partes do aplicativo (por exemplo, determinados diretórios ou tipos de arquivo que nunca precisam ser acessados pelos usuários finais), também é possível bloquear ou restringir o acesso a estes recursos com uma regra personalizada, reduzindo proativamente o risco se esses componentes se tornarem vulneráveis no futuro.

Boletins de segurança do Google Cloud

Caso de uso:

• Monitoramento do boletim de segurança
• CVEs de produtos do Google Cloud

Os boletins de segurança do Google Cloud são uma fonte autoritativa para boletins de segurança que afetam o Google Cloud. As postagens incluem informações básicas, links da CVE e recomendações para outras ações.

Web Security Scanner

Caso de uso:

• Bibliotecas desatualizadas
• Painéis de vulnerabilidades e descobertas

Monitore bibliotecas desatualizadas incluídas no aplicativo da Web. Monitore essas descobertas no painel do Security Command Center.

A10: geração de registros e monitoramento insuficientes

Se você não registrar adequadamente, monitorar ou gerenciar incidentes nos seus sistemas, os invasores poderão realizar ataques mais profundos e prolongados aos dados e ao software.

Transparência no acesso

Caso de uso:

• Monitoramento e auditoria de acesso a provedores de serviços
• Justificativas de acesso
• Identificação de recursos e métodos

Não poder auditar o acesso do provedor de nuvem pode ser uma barreira à migração do local para a nuvem. Com a transparência no acesso, essa verificação é possível, e você conta com controles de auditoria parecidos com os disponíveis tradicionalmente no local. É possível registrar o motivo de cada acesso, incluindo referências a tíquetes de suporte relevantes. Nomes de identificação de recurso e método que recursos são acessados e quais métodos foram executados por qual administrador. Com a aprovação de acesso, é possível aprovar ou denegar as solicitações de acesso feitas pelos funcionários do Google que dão suporte ao serviço.

Apigee

Caso de uso:

• Exportar registros da Apigee para SIEM
• Usar a IU de monitoramento da Apigee
• Siga as práticas recomendadas de monitoramento

A Apigee tem várias maneiras de executar a geração de registros, o monitoramento, o tratamento de erros e a geração de registros de auditoria:

• Logging
  • As mensagens de registro podem ser enviadas para o Splunk ou outros endpoints do syslog usando a política MessageLogging.
  • É possível extrair dados de análise da API por meio da API Analytics e importá-los ou exportá-los para outros sistemas.
  • No Edge for Private Cloud, é possível usar a política MessageLogging para gravar em arquivos de registros locais. Os arquivos de registros de cada um dos componentes em execução também estão disponíveis.
  • A política JavaScript pode ser usada para enviar mensagens de registro a um endpoint de geração de registros REST de maneira síncrona ou assíncrona.
• Monitoramento
  • Use a IU ou a API da API Monitoring para monitorar regularmente APIs e back-ends e acionar alertas.
  • Use o monitoramento de integridade para monitorar regularmente os back-ends do servidor de destino.
  • A Apigee fornece recomendações para monitorar o Edge para nuvem privada.
  • A Apigee também fornece práticas recomendadas que sua equipe pode aproveitar para monitorar seu programa de API.
• Como lidar com erros
  • A Apigee oferece um mecanismo de tratamento de falhas eficiente e versátil para proxies de API. Assim como um programa Java captura exceções, os proxies de API podem identificar falhas e determinar como retornar respostas apropriadas aos clientes.
  • O tratamento de falhas personalizado da Apigee permite que você adicione funcionalidades, como a geração de registros de mensagens, sempre que ocorrer um erro.
• Registros de auditoria
  • A plataforma Apigee mantém um registro de auditoria que rastreia as alterações em proxies de API, produtos e histórico da organização.
  • Esse registro está disponível por meio da IU ou da API Management.

Detecção de Chronicle

Caso de uso:

• Detecção de ameaças
• Alerta antecipado

As equipes de segurança podem enviar a telemetria de segurança para o Chronicle para que seja possível aplicar regras avançadas de detecção a um conjunto unificado de dados.

Cloud Data Loss Prevention (Cloud DLP)

Caso de uso:

• Mascaramento automático de dados confidenciais

Identifique informações confidenciais de conformidade nos streams de registros e mascare ou transforme-as adequadamente antes de arquivá-las nos registros. Por exemplo, uma mensagem de erro ou despejo de núcleo pode conter informações confidenciais, como números de cartão de crédito ou informações de identificação pessoal que precisam ser mascarados.

Cloud Key Management Service (Cloud KMS)

Caso de uso:

• Registro de eventos de solicitação de chave criptográfica
• Justificativas de acesso

As justificações de acesso às chaves dão a você visibilidade histórica de todas as solicitações de uma chave de criptografia, registrando a justificativa declarada e um registro de aprovação ou negação dessa solicitação.

Cloud Logging

Caso de uso:

• Agregação de registros
• Armazenamento de registro
• Pesquisa de registros
• Análise de registros

O Cloud Logging permite armazenar, pesquisar, analisar, monitorar e alertar sobre dados e eventos de registro do Google Cloud e do Amazon Web Services. Ele inclui acesso ao serviço BindPlane, que pode ser usado para coletar dados de geração de registros de mais de 150 componentes comuns de aplicativos, sistemas locais e sistemas de nuvem híbrida.

Cloud Monitoring

Caso de uso:

• Monitoramento de registros
• Alertas de evento

O Cloud Monitoring mostra o desempenho, o tempo de atividade e a integridade geral de aplicativos com tecnologia de nuvem. Ele oferece um painel de monitoramento, monitores de eventos e alertas por meio de vários canais.

Cloud Source Repositories

Caso de uso:

• Atribuição de alteração de código
• Acessar a geração de registros de auditoria

Receba insights sobre as ações que foram realizadas no seu repositório, incluindo onde e quando, com os registros de auditoria do Cloud gerados pelo Cloud Source Repositories.

Error Reporting

Caso de uso:

• Capturar erros internos de aplicativos no Cloud Logging
• Coletar relatórios de falha fora da instância de computação com falha

Os erros internos do aplicativo podem ser um indicador de problema de segurança, funcionalidade incorreta ou tentativas de burlar a segurança. O Error Reporting conta, analisa e agrega falhas de serviços executados na nuvem. Uma interface centralizada de gerenciamento de erros exibe resultados que podem ser classificados e filtrados. Veja todos os detalhes do erro em uma visualização dedicada: gráfico de horas, ocorrências, total de usuários afetados, data da primeira e da última visualização e um rastreamento limpo da pilha de exceção. Ative a opção para receber, por e-mail e em dispositivos móveis, alertas sobre novos erros.

Event Threat Detection

Caso de uso:

• Força bruta
• Criptomineração
• Abuso do IAM
• Malware
• Phishing

O Event Threat Detection monitora seu stream do Cloud Logging e aplica a lógica de detecção e a inteligência contra ameaças em um nível granular. O Event Threat Detection identifica as entradas notáveis nos registros e as eleva para análise. Quando o Event Threat Detection detecta uma ameaça, ele grava o que encontra no Security Command Center e em um projeto do Cloud Logging.

Forseti Inventory

Caso de uso:

• Monitoramento e alertas de alterações de inventário

O Forseti Inventory salva um snapshot do inventário dos recursos do Google Cloud em um banco de dados para que você tenha um registro histórico dos recursos. Com essas informações, é possível entender todos os recursos que você tem no Google Cloud e tomar medidas para economizar recursos, reduzir custos e minimizar a exposição de segurança. O inventário pode ser configurado para ser executado com a frequência que você quiser e enviar notificações por e-mail quando ele atualizar o snapshot do recurso.

Google Cloud Armor

Caso de uso:

• Geração de registros de política de segurança
• Monitoramento de painéis
• Alertas sobre anomalias de tráfego

Os registros de solicitação do Google Cloud Armor fazem parte do Cloud Logging para balanceamento de carga HTTP(S). Para ter acesso às informações de registro, como a regra de política de segurança que corresponde ao tráfego, ative geração de registros em todos os serviços de back-end que tiverem políticas de segurança anexadas. Use regras no modo de visualização para testá-las e registrar os resultados sem impor os efeitos.

O Google Cloud Armor também oferece painéis de monitoramento para políticas de segurança que permitem ter uma visão geral da quantidade de tráfego que passou ou foi negada por qualquer uma das políticas de segurança. O Google Cloud Armor publica descobertas sobre anomalias de tráfego, como picos no tráfego permitido ou aumento de tráfego negado, no Security Command Center.

O Google Cloud Armor grava registros de auditoria de atividades do administrador, que armazenam operações que modificam a configuração ou os metadados de um recurso. Também é possível configurar esse serviço para gravar registros de auditoria de acesso a dados, que contêm chamadas de API que leem a configuração ou os metadados de recursos, bem como chamadas de API orientadas pelo usuário que criam, modificam ou leem dados de recursos fornecidos pelo usuário.

Identity Platform

Caso de uso:

• Registros de auditoria de atividades de administração
• Registros de auditoria de acesso a dados
• Registros de auditoria de evento do sistema
• Registros de auditoria de política negada
• Registros de atividade de autenticação

O Identity Platform é a plataforma de gerenciamento de identidade e acesso do usuário do Google Cloud que registra a atividade de autenticação por padrão.

Ative vários registros de auditoria avançados, incluindo atividade do administrador, acesso a dados, eventos do sistema e tentativas de autenticação negadas.

Security Command Center

Caso de uso:

• Monitoramento de alertas
• Gerenciamento de ameaças
• Relatório de verificação de vulnerabilidades
• Monitoramento de conformidade
• Monitoramento de recursos
• Descobertas da verificação de segurança

Veja o número total de descobertas na sua organização por nível de gravidade no painel de visão geral. Use o painel de ameaças para analisar eventos potencialmente prejudiciais nos recursos do Google Cloud da sua organização. Veja as descobertas e recomendações do Security Health Analytics na guia de vulnerabilidades.

O painel de conformidade permite monitorar continuamente a conformidade com controles do PCI-DSS, CIS Google Cloud Computing Foundations Benchmark e muito mais. A visualização "Recursos" oferece uma exibição detalhada de todos os recursos do Google Cloud, chamados de recursos da sua organização. A guia "Recursos" permite visualizar recursos de toda a organização ou filtrar recursos em um projeto específico, por tipo de recurso ou por tipo de alteração. Por fim, a guia "Descobertas" exibe um inventário detalhado de descobertas para todos os recursos da sua organização para que seja possível visualizar possíveis riscos de segurança.

A seguir

• Proteção de APIs e aplicativos da Web no Google Cloud
• 10 principais OWASP
• Boletins de segurança do Google Cloud
• Central de práticas recomendadas de segurança para o Google Cloud
• Ofertas de conformidade
• Comparativo de mercado do CIS para Google Cloud
• Security Command Center
• Apigee
• Google Cloud Armor
• Todos os produtos de segurança do Google Cloud
• Confira o conteúdo de migração de dados do Google Cloud. Confira o Centro de arquitetura do Cloud.

Qual ferramenta pode ser utilizada para realizar as varreduras de vulnerabilidades?

Quais ferramentas podemos utilizar para encontrar vulnerabilidade na rede?

O que é teste de vulnerabilidade?

Que ferramenta você pode usar para encontrar vulnerabilidades ou configurações incorretas perigosas nos seus sistemas e redes?