Ir para o conteúdo principal

O Poder da Composição em Cima de uma Plataforma de Dados Unificada - Acelerando a Inovação em Segurança na Nuvem

Power of Compounding on Top of a Unified Data Platform - Accelerating Innovation in Cloud Security

Published: March 25, 2025

Clientes15 min de leitura

Summary

  • Evolução Estratégica: Prisma Cloud passou de uma solução AWS caseira para Databricks para lidar com uma escala massiva e suportar capacidades avançadas de IA.
  • Impacto Mensurável: Os resultados do primeiro ano mostraram um tempo de desenvolvimento 3x mais rápido, redução de custos de 20% e triplicou a velocidade na iteração de recursos de IA.
  • Arquitetura Pronta para o Futuro: Uma nova estrutura de dados de três camadas (Raw, Processed, Correlated) estabeleceu a base para uma malha de dados de segurança flexível em todos os módulos.

Prisma Cloud é a principal plataforma de Segurança na Nuvem que oferece visibilidade abrangente de código para nuvem sobre seus riscos e incidentes, oferecendo capacidades-chave de remediação para gerenciar e monitorar sua jornada de código para nuvem. A plataforma hoje protege mais de 1B+ de ativos ou cargas de trabalho em todo o mundo, do código à nuvem. Ele garante alguns dos ambientes mais exigentes com clientes que possuem dezenas de milhares de contas na nuvem que veem constantes mutações e alterações de configuração na escala de trilhões a cada hora.

Ao longo deste blog, revisaremos a abordagem histórica da Prisma Cloud para incorporar dados e IA em nossos produtos, os desafios que encontramos com nossa plataforma de dados existente e como, com a Plataforma de Inteligência de Dados da Databricks, a Prisma Cloud alcançou um impacto transformador em toda a empresa que beneficia diretamente nossos clientes e equipes internas.

O foco do Prisma Cloud era oferecer as melhores soluções em cada segmento/módulo e, em seguida, fornecer recursos de segurança adicionais que ajudam a conectar sinais de diferentes módulos para oferecer capacidades mais profundas como uma oferta de plataforma. Alguns exemplos incluem:

  • Abordando problemas de postura relacionados à configuração e gerenciamento de infraestrutura. Corrigir esses problemas no código e fomentar uma mentalidade de automação ajuda a preveni-los na produção. Combinar nossa oferta de Gerenciamento de Postura com nossa oferta de Segurança de Código foi essencial para garantir rastreabilidade e resolver problemas diretamente no código.
  • Visualizando e gerenciando controles através de um ‘gráfico de conhecimento’ da plataforma ajuda os clientes a entenderem como os recursos e as cargas de trabalho estão conectados. Esta abordagem permite que eles avaliem descobertas e identifiquem caminhos que representam maiores preocupações para um administrador de SOC. Agregar todos os sinais em um único lugar é crucial para esse processo.

O Prisma Cloud é configurado com mais de 10 módulos, cada um sendo o melhor em suas características de segurança e gerando sinais para a plataforma. Os clientes podem optar por aproveitar a plataforma para suas necessidades verticais (por exemplo, para gerenciamento de vulnerabilidades) ou para todo o conjunto. A abordagem da plataforma incentiva o cliente a explorar áreas adjacentes, aumentando o valor geral e promovendo maior aderência.

O desafio técnico da Prisma Cloud é fundamentalmente um desafio de dados. Com nossa rápida expansão de módulos - impulsionada tanto pela inovação orgânica quanto por M&As - desenvolver uma estratégia de dados unificada do zero foi uma tarefa exigente. No entanto, a visão era clara: sem uma solução para consolidar todos os dados em um único lugar, não poderíamos entregar totalmente as capacidades que nossos clientes precisam enquanto aproveitamos o poder dos melhores módulos.

Como um dos maiores adotantes do GenAI, a Palo Alto Networks construiu sua estratégia de IA em torno de três pilares principais: aproveitar a IA para aprimorar as ofertas de segurança, proteger a IA para ajudar os clientes a protegerem seu uso de IA e otimizar a experiência do usuário por meio de copilotos e automação orientados por IA. Veja PrecisionAI para mais detalhes.

Palo Alto Networks e Prisma Cloud tiveram um forte histórico de uso profundo de IA/ML em vários produtos e recursos muito antes da onda GenAI remodelar a indústria. No entanto, a rápida evolução das capacidades de IA acelerou a necessidade de uma estratégia de dados abrangente e de longo prazo.

Ecossistema Databricks na Arquitetura Prisma Cloud

Escolhemos a Plataforma de Inteligência de Dados Databricks como a melhor opção para nossa direção estratégica e requisitos, pois englobava todos os aspectos críticos necessários para apoiar nossa visão. Com o Databricks, aceleramos significativamente nossos esforços de consolidação de dados e escalamos casos de uso inovadores - entregando benefícios mensuráveis para os clientes em apenas seis meses após a implementação.

Apenas no primeiro ano de integração com Databricks, a Palo Alto Networks alcançou um impacto transformador em toda a empresa, que beneficia diretamente tanto nossos clientes quanto as equipes internas. Ao centralizar os fluxos de trabalho de dados na Plataforma Databricks, reduzimos significativamente a complexidade e aceleramos a inovação, permitindo-nos iterar sobre os recursos de IA/ML três vezes mais rápido do que antes. Junto com este aumento de velocidade, percebemos uma redução de 20% no custo dos produtos vendidos e uma diminuição de 3x no tempo de desenvolvimento de engenharia.

Aproveitando a colaboração aprimorada - impulsionada pelos Workflows da Databricks, pelo Catálogo Unity da Databricks para governança unificada e pelo Auto Loader da Databricks, conseguimos entregar soluções de segurança em uma velocidade e escala sem precedentes. Isso acelerou dramaticamente o processamento de dados da Prisma Cloud e nos permitiu trazer recursos impactantes para o mercado mais rápido do que nunca.

Os desafios das soluções caseiras

O Prisma Cloud executa a maior parte de sua infraestrutura na AWS com uma pilha de tecnologia de engenharia madura construída em torno dos serviços nativos da AWS. Nossa equipe tinha vasta experiência em aproveitar o Apache Spark para processamento ETL e analítico, executando nossa infraestrutura no AWS Glue e EMR.

Reconhecendo a necessidade de uma plataforma de dados dedicada, inicialmente desenvolvemos uma solução caseira utilizando EMR, Glue e S3 como a base para nossa versão inicial. Embora essa abordagem tenha funcionado bem com uma equipe pequena, escalá-la para suportar uma estratégia de dados mais ampla e adoção em várias equipes rapidamente se tornou um desafio. Nos encontramos gerenciando milhares de trabalhos do Glue e vários clusters EMR - todos exigindo capacidades de nível empresarial, como monitoramento, alertas, verificações de confiabilidade e proteções de governança/segurança.

À medida que nossas necessidades aumentavam, o overhead operacional também aumentava. Uma parte significativa de nosso esforço de engenharia foi desviada para manter o que efetivamente se tornou um "Sistema Operacional" para nossa plataforma de dados, em vez de se concentrar em inovação e casos de uso orientados para o valor.

Embora esse esforço tenha atendido às nossas necessidades estratégicas, logo começamos a enfrentar vários desafios na manutenção desta versão. Alguns deles estão listados abaixo

  • Ferramentas personalizadas e transformações de dados - As equipes gastaram um tempo considerável em várias reuniões apenas para identificar atributos de dados, localizá-los e projetar pipelines personalizados para cada caso de uso, retardando o desenvolvimento e a colaboração.
  • Gestão de infraestrutura demorada - Com vários parâmetros de ajuste no núcleo de nossos trabalhos Spark, tivemos dificuldades para desenvolver um processo de gerenciamento de mudanças escalável e genérico. Isso adicionou uma carga cognitiva significativa para as equipes de infraestrutura responsáveis pela gestão de clusters.
  • Gerenciamento de custos e orçamento - Gerenciar o EMR e o Glue diretamente exigia a configuração manual de várias proteções, incluindo observabilidade centralizada em todas as pilhas. À medida que nossos projetos cresciam, também aumentavam as exigências de pessoal para manter uma plataforma de dados mais madura.
  • Gerenciamento de Spark - Também nos deparamos com desafios em torno de algumas das atualizações das bibliotecas principais do Spark não serem suportadas na AWS, o que fez com que alguns de nossos trabalhos fossem ineficientes em comparação com o que seria o estado da arte. Limites internos da AWS no gerenciamento de executores nos forçaram a um extenso processo de solução de problemas e reuniões recorrentes para determinar as causas raiz.

Apesar desses desafios, nossa solução interna continua a escalar, processando dezenas de milhões de mutações de dados por hora para casos de uso críticos. Olhando para o futuro, vemos uma clara necessidade de migrar para uma plataforma mais madura - uma que nos permita aposentar ferramentas internas e redirecionar esforços de engenharia para proteger os ambientes de nuvem de nossos clientes, em vez de gerenciar infraestrutura.

Arquitetura de dados e sua evolução na Prisma Cloud

Na Prisma Cloud, seguimos a regra dos 8 fatores para qualquer avaliação técnica para avaliar suas vantagens e desvantagens. Esses fatores são analisados por nosso comitê de liderança técnica interna, onde participamos de discussões para chegar a um consenso. Em casos onde um fator não pode ser adequadamente avaliado, coletamos dados adicionais por meio de prototipagem relevante para o negócio para garantir uma decisão bem informada.

Os principais fatores estão listados abaixo:

  • Adequação funcional - Isso resolve nossas necessidades de negócios?
  • Adequação da Arquitetura/Design - Está alinhado com nossa visão técnica de longo prazo?
  • Adoção por desenvolvedores - Quão popular é entre os desenvolvedores hoje?
  • Estabilidade/Ecossistema - Existem grandes empresas usando essa tecnologia?
  • Complexidade de implantação - Quanto esforço estamos falando sobre sua implantação e gerenciamento de mudanças?
  • Custo - Como os COGs se comparam ao valor dos recursos que planejamos oferecer para aproveitar essa tecnologia?
  • Benchmarks comparativos - Existem benchmarks existentes que provam escala comparável?

Um de nossos principais objetivos a longo prazo era a capacidade de mover-se em direção a um modelo de malha de dados de segurança. Dado nossa abordagem de plataforma, categorizamos os dados em 3 tipos fundamentais:

  • Dados brutos - Isso inclui dados ingeridos diretamente dos produtores ou módulos à medida que entram na plataforma. Na terminologia do lakehouse do Databricks - isso corresponde a dados Bronze.
  • Dados processados - A Plataforma Prisma Cloud é uma plataforma opinativa, transforma dados brutos em objetos de plataforma normalizados. Isso é chamado de dados processados, que se alinham com a camada de dados Silver na terminologia do lakehouse.
  • Dados correlacionados - Esta categoria desbloqueia valor líquido ao correlacionar diferentes conjuntos de dados, permitindo insights e análises avançadas. Isso corresponde à camada Ouro na terminologia de lakehouse.

Ao contrário dos tradicionais lagos de dados, onde os dados Bronze são frequentemente descartados, a amplitude e profundidade de nossa plataforma exigem uma abordagem mais evolutiva. Em vez de simplesmente transformar dados em conjuntos de dados Gold, imaginamos nosso data lake evoluindo para uma malha de dados, permitindo maior flexibilidade, acessibilidade e insights entre domínios. O diagrama abaixo reflete a capacidade de longo prazo que buscamos extrair de nossos investimentos em lago de dados.

Todas as nossas avaliações foram centradas na filosofia acima.

Resultados da avaliação

Além de marcar todas as caixas em nossa nova estrutura de avaliação de tecnologia, os seguintes insights chave consolidaram ainda mais o Databricks como nossa plataforma de dados preferida.

  1. Simplificação da pilha de tecnologia existente - Nossa infraestrutura dependia de vários trabalhos de Glue e EMR, muitos dos quais exigiam ferramentas ad-hoc e manutenção repetitiva. Com o Databricks, identificamos uma oportunidade de reduzir 30%-40% de nossos trabalhos, permitindo que nossos engenheiros se concentrem em recursos de negócios principais em vez de manutenção.
  2. Redução de custos - Vimos pelo menos uma queda de 20% nos gastos existentes, mesmo antes de considerar a amortização com a adoção acelerada em vários casos de uso.
  3. Recursos da plataforma e ecossistema - O Databricks forneceu valor imediato por meio de recursos como exposição de URL JDBC para consumo de dados, infraestrutura ML/AI integrada, hospedagem de modelo automatizada, governança aprimorada e controle de acesso, e avançada ocultação e mascaramento de dados. Essas capacidades foram críticas quando atualizamos nossas estratégias de manipulação de dados para necessidades táticas e estratégicas.
  4. Treinamento e facilidade de adoção - Integrar novos engenheiros ao Databricks provou ser significativamente mais fácil do que fazê-los construir pipelines ETL escaláveis do zero na AWS. Isso reduziu a barreira de entrada e acelerou a adoção de tecnologias baseadas em Spark, que são essenciais em nossa escala.

Detalhes da avaliação

Critérios EMR/GLUE (ou tecnologia nativa do Provedor de Nuvem) Databricks
Facilidade de Implantação Cada equipe precisa trabalhar em seu código de implantação. Geralmente um sprint de trabalho. Integração única e as equipes adotarão. O trabalho do SRE foi reduzido para alguns dias.
Facilidade de Administração Manutenção de versões e patches de segurança. SREs geralmente levam alguns dias. O trabalho de SRE não é mais necessário.
Integrações SRE precisa configurar o Airflow e o ksql (geralmente um sprint de trabalho para novas equipes) Pronto para Uso
MLflow Precisa comprar uma ferramenta ou adotar código aberto. Cada equipe precisa se integrar. (Alguns meses pela primeira vez, um sprint de trabalho para cada equipe). Pronto para Uso
Catálogo de Dados (Requer linhagem de dados, segurança, controle de acesso baseado em funções, dados pesquisáveis e marcação de dados.) Precisa comprar ferramentas e integrar com o Prisma. Pronto para Uso
Aproveite as Bibliotecas ML e Auto ML Necessidade de comprar e integrar com o Prisma. Pronto para Uso
SPOG para Desenvolvedores e SRE Não disponível com EMR/GLUE. Pronto para Uso
DB sql(SQL em dados s3) Athena, Presto. É necessário a ajuda de SRE para integrar com o Prisma. Pronto para Uso

Estudo de caso de aplicação

Dado nossos primeiros pilotos, ficamos convencidos a começar a planejar um caminho de migração de nosso data lake baseado em S3 existente para a Plataforma Databricks. Uma oportunidade perfeita surgiu com um projeto de insights chave que exigia acesso a dados tanto das camadas Raw quanto Correlated para descobrir novos insights de segurança e otimizar a resolução de problemas de segurança.

Antes de adotar o Databricks, a execução deste tipo de projeto envolvia várias etapas complexas e demoradas:

  • Identificando necessidades de dados - Surgiu um problema de ovo e galinha: enquanto precisávamos definir nossas necessidades de dados antecipadamente, a maioria dos insights exigia exploração em vários conjuntos de dados antes de determinar seu valor.
  • Complexidade de integração - Uma vez que as necessidades de dados foram definidas, tivemos que coordenar os dados com os proprietários para estabelecer caminhos de integração - muitas vezes levando a pipelines únicos e personalizados.
  • Governança e controle de acesso - Uma vez que todos os dados estão disponíveis, então tivemos que garantir a segurança e governança adequadas. Isso exigiu configurações manuais, com diferentes implementações dependendo de onde os dados residem.
  • Observabilidade e solução de problemas - Com o monitoramento do pipeline de dados dividido entre várias equipes, a resolução de problemas exigia uma coordenação significativa entre as equipes, tornando a depuração altamente específica para cada caso de uso.

Testamos o impacto da Plataforma de Inteligência de Dados da Databricks neste projeto crítico através das seguintes etapas:

  • Etapa 1: Planejamento de Infraestrutura e Migração

    Iniciamos o Databricks em nossos ambientes de desenvolvimento e começamos a planejar a migração de nosso data lake interno no S3 para o Databricks. Utilizamos os Pacotes de Ativos da Databricks e o Terraform para a migração e o deployment de nossa infraestrutura e recursos.

    Antes de adotar o Databricks, os engenheiros passavam a maior parte do tempo gerenciando a infraestrutura da AWS em várias ferramentas. Com a Databricks, temos uma plataforma centralizada para gerenciar configurações de cluster de usuários e grupos.

    O Databricks oferece um ambiente Spark aprimorado através do Photon, fornecendo uma plataforma totalmente gerenciada com desempenho otimizado, enquanto a AWS entrega principalmente o Spark através de seu serviço EMR, que requer mais configuração manual e não atinge o mesmo nível de otimização de desempenho que o Databricks. Além disso, a capacidade de construir, implantar e servir modelos na Databricks nos permitiu escalar mais rapidamente.
  • Passo 2: Estruturando Fluxos de Trabalho para Escala

    Dividimos o projeto em quatro fluxos de trabalho na plataforma Databricks: Gerenciamento de Catálogo de Dados, Hidratação do Data Lake, Governança e Controle de Acesso, e Ferramentas de Desenvolvimento/Automação.

    O Catálogo Unity foi essencial para a construção de nossa plataforma, fornecendo governança unificada e controles de acesso em um único espaço. Ao utilizar o controle de acesso baseado em atributos (ABAC) e a mascaramento de dados, conseguimos ofuscar os dados conforme necessário sem diminuir o tempo de desenvolvimento.
  • Etapa 3: Acelerando a Integração de Dados e Governança

    O registro no catálogo e a integração dos nossos dados existentes no nosso data lake levaram apenas algumas horas, enquanto a configuração da governança e controle de acesso foi um esforço único.

    O Unity Catalog forneceu uma plataforma centralizada para gerenciar todas as permissões, simplificando a segurança de todo o nosso conjunto de dados, incluindo dados estruturados e não estruturados. Isso englobou governança para dados, modelos, painéis, cadernos e mais.
  • Etapa 4: Escalando a Hidratação de Dados e Observabilidade

    Integramos sem problemas dados brutos anteriormente indisponíveis ao nosso data lake existente e priorizamos sua hidratação na Plataforma Databricks. Capitalizando nas integrações abrangentes com Kafka, banco de dados e S3, desenvolvemos com sucesso trabalhos de hidratação em nível de produção, escalando para trilhões de linhas em apenas algumas sprints.

    Em produção, dependemos extensivamente dos Workflows Databricks, enquanto clusters interativos suportam ambientes de desenvolvimento, teste e performance dedicados à construção de recursos inovadores para o nosso produto Prisma Cloud. O Databricks Serverless SQL sustenta nossos painéis, garantindo um monitoramento eficiente da deriva do modelo e das métricas de desempenho. Além disso, as tabelas do sistema nos permitem identificar e analisar trabalhos e execuções de alto custo ao longo do tempo, acompanhar flutuações significativas de orçamento e promover uma otimização de custos e gerenciamento de recursos eficazes.

    Esta abordagem holística concede aos executivos uma visibilidade clara do uso e consumo da plataforma, simplificando a observabilidade e o orçamento sem depender de insights fragmentados de várias ferramentas da AWS, como EMR, Glue, SageMaker e Neptune.

O resultado?

Essa consolidação provou ser transformadora. Em uma única semana de prototipagem, descobrimos insights valiosos combinando conjuntos de dados brutos, processados e correlacionados, permitindo uma avaliação mais produtiva do ajuste do produto ao mercado. Como resultado, obtivemos uma direção clara sobre quais desafios do cliente perseguir e uma compreensão mais forte do impacto que poderíamos entregar.

Em apenas seis meses de parceria com a Databricks, introduzimos uma inovação de segurança crucial para nossos clientes - uma conquista que teria sido praticamente impossível dado nossa antiga pilha de tecnologia, base de clientes expansiva e a necessidade de priorizar os recursos de segurança essenciais.

Estatísticas de utilização da Databricks

  • ~3 Trilhões de registros processados por dia.
  • Tempo de processamento P50: < 30 mins.
  • Paralelismo máximo: 24
  • A utilização do Auto Loader reduz as latências de ingestão para segundos, oferecendo processamento quase em tempo real.
  • Recursos prontos para uso, como painéis de AI/BI com tabelas de sistema, ajudaram as equipes de desenvolvimento a identificar e analisar trabalhos e execuções de alto custo ao longo do tempo, monitorar mudanças significativas de orçamento e apoiar a otimização eficaz de custos e o gerenciamento de recursos.

Conclusão

Como o estudo de caso da aplicação acima mostrou, o momento de nosso crescimento alinhou-se com o Databricks emergindo como a plataforma de dados líder de escolha. Nosso compromisso compartilhado com a inovação rápida e a escalabilidade tornou essa parceria um ajuste natural.

Ao reformular o desafio técnico da segurança na nuvem como um problema de dados, conseguimos buscar fornecedores de tecnologia que são especialistas nesta área. Essa mudança estratégica nos permitiu focar na profundidade, aproveitando a poderosa plataforma da Databricks enquanto aplicamos nossa inteligência de domínio para adaptá-la à nossa escala e necessidades de negócios. Em última análise, essa colaboração nos permitiu acelerar a inovação, aprimorar os insights de segurança e entregar maior valor aos nossos clientes.

Leia mais sobre a colaboração entre Databricks e Palo Alto Networks aqui.

 

(This blog post has been translated using AI-powered tools) Original Post

Nunca perca uma postagem da Databricks

Inscreva-se nas categorias de seu interesse e receba as últimas postagens na sua caixa de entrada

O que vem a seguir?