Como mover dados criptografados de ponta a ponta por meio do Kafka

O complemento Confluent para Ockam Orchestrator permite fluxos de mensagens criptografadas de ponta a ponta e invioláveis ​​por meio do Confluent Cloud, sem alterações de código. A solução drop-in permite que as empresas excedam os requisitos comuns de segurança e conformidade sem a necessidade de rearquitetura ou trabalho de desenvolvimento dispendiosos.

As implantações do Kafka geralmente combinam tokens de autenticação e Transport Layer Security (TLS) para proteger os dados que entram e saem dos tópicos do Kafka. Embora isso proteja os dados em trânsito pela Internet, não fornece uma solução completa para proteger os dados enquanto eles trafegam pelo Kafka. O corretor Kafka poderá ver temporariamente os dados de texto sem formatação.

A criptografia de comunicação dentro e fora do seu agente Kafka combinada com a criptografia de dados em repouso, dentro do Kafka, não será proteção suficiente contra uma violação de dados se o agente Kafka ou a infraestrutura em que está sendo executado estiver comprometido, pois os dados de texto simples e as chaves para descriptografar os dados estão disponíveis na memória. A Ockam resolve esses problemas, ao mesmo tempo em que oferece benefícios adicionais de mitigação de risco e garantias de integridade de dados, por meio do complemento Confluent para Ockam Orchestrator.

Confie nos seus dados em movimento

Sua equipe decidiu que integrar uma plataforma de processamento de fluxo em seus sistemas é a melhor maneira de atender às necessidades de escala e agilidade de seus negócios, e o Apache Kafka foi a escolha óbvia para a plataforma a ser usada. Você também decidiu aproveitar o uso de uma plataforma gerenciada experiente no Confluent Cloud para que sua equipe possa se concentrar em agregar valor em vez de executar a infraestrutura. O desenvolvimento está completo, a equipe tem uma solução funcional onde os produtores podem enviar dados para o Confluent Cloud e os consumidores podem recebê-los do outro lado. A comunicação entre seus produtores, consumidores e o Confluent Cloud é criptografada e segura usando o Transport Layer Security (TLS), então você está prestes a mover as coisas para o uso de produção.

Uma análise de segurança e conformidade revelou um problema. Embora você confie na Confluent Cloud, o foco maior na redução do risco da cadeia de suprimentos significa que a movimentação de dados pelos sistemas sem criptografia não atende mais aos seus requisitos de segurança. Como você reduz o risco para o seu negócio caso algum outro fornecedor em sua cadeia de suprimentos tenha uma violação de segurança? Você precisa ser capaz de garantir que:

1. Não há possibilidade de terceiros lerem os dados enquanto estão em trânsito
2. Um terceiro não pode modificar os dados enquanto estão em trânsito
3. Somente partes autenticadas e autorizadas podem produzir dados

Sem soluções para ambos, existe o risco de que uma violação de segurança em sua própria cadeia de suprimentos possa não apenas expor seus dados confidenciais, mas também causar escalações descendentes inesperadas.

Integre sem alterações de código

Deixe-me levá-lo através de um exemplo de trabalho completo de como, em apenas alguns minutos, você pode configurar e integrar uma solução completa de ponta a ponta que garante que seus dados sejam sempre criptografados e à prova de adulteração durante o movimento por meio de Kafka e Confluent .

Observação: os exemplos de código abaixo podem mudar à medida que continuamos a melhorar a experiência do desenvolvedor. Verifique https://docs.ockam.io/ para obter a documentação mais atualizada.

Configuração inicial de Ockam

Se você já configurou o Ockam anteriormente, pode pular esta seção e ir direto para os dois exemplos abaixo.

 brew install build-trust/ockam/ockam

(se você não estiver usando o brew para gerenciamento de pacotes, temos instruções de instalação para outros sistemas em nossa documentação)

Depois de instalado, você precisa registrar sua identidade local no Ockam Orchestrator, execute o comando abaixo e siga as instruções fornecidas:

 ockam enroll

Configurar o complemento Confluent

Estamos assumindo aqui que você já tem um cluster de trabalho no Confluent Cloud (e as ferramentas de linha de comando Kafka que vêm com o distribuição Kafka mais recente ), portanto, a primeira etapa é configurar seu projeto Ockam para usar o complemento Confluent, apontando-o para o endereço do servidor de bootstrap:

 ockam project addon configure confluent \ --bootstrap-server YOUR_CONFLUENT_CLOUD_BOOTSTRAP_SERVER_ADDRESS

Em seguida, precisaremos salvar nossa configuração do projeto Ockam para que possamos usá-la posteriormente para registrar nossos produtores e consumidores, portanto, salve a saída em um arquivo com o nome project.json :

 ockam project information default --output json > project.json

Como administrador do projeto Ockam, você pode controlar quais outras identidades podem se inscrever em seu projeto, emitindo tokens de registro de uso único exclusivos. Vamos começar criando um para o nosso consumidor:​

 ockam project enroll --project-path project.json --attribute role=member > consumer.token

... e depois um para o primeiro produtor:

 ockam project enroll --project-path project.json --attribute role=member > producer1.token

O último arquivo de configuração que precisamos gerar é kafka.config , que será onde você armazena o nome de usuário e a senha que você usa para acessar seu cluster no Confluent Cloud:

 cat > kafka.config <<EOF request.timeout.ms=30000 security.protocol=SASL_PLAINTEXT sasl.mechanism=PLAIN sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \ username="YOUR_CONFLUENT_CLOUD_USER_NAME" \ password="YOUR_CONFLUENT_CLOUD_PASSWORD"; EOF

Configurar consumidores para receber mensagens criptografadas

Em seu nó consumidor, você começará criando uma nova identidade (você precisará do Ockam Command instalado, então repita as instruções de instalação se estiver fazendo isso em um host separado):

 ockam identity create consumer

Copie os arquivos project.json e consumer.token da seção anterior e use-os para autenticar e registrar essa identidade em seu projeto Ockam:

 ockam project authenticate \ --project-path project.json \ --identity consumer \ --token $(cat consumer.token)

Um nó Ockam é uma maneira de conectar com segurança diferentes serviços entre si, então vamos criar um aqui que usaremos para nos comunicarmos através do cluster Confluent Cloud usando a identidade que acabamos de criar:

 ockam node create consumer \ --project project.json --identity consumer

Uma vez concluído, agora podemos expor nosso servidor de inicialização Kafka. É como se o servidor de bootstrap Kafka remoto e os corretores se tornassem virtualmente adjacentes em localhost:4000 :

 ockam service start kafka-consumer \ --node consumer \ --project-route /project/default \ --bootstrap-server-ip 127.0.0.1 \ --bootstrap-server-port 4000 \ --brokers-port-range 4001-4100

Copie o arquivo kafka.config e use-o para criar um novo tópico que usaremos para enviar mensagens entre o produtor e o consumidor nesta demonstração (neste caso, chamamos o tópico demo-topic )

 kafka-topics.sh \ --bootstrap-server localhost:4000 \ --command-config kafka.config \ --create \ --topic demo-topic \ --partitions 3

A etapa final é iniciar nosso script de consumo, apontando-o para localhost:4000 como nosso servidor de inicialização:

 kafka-console-consumer.sh \ --topic demo-topic \ --bootstrap-server localhost:4000 \ --consumer.config kafka.config

O código do consumidor enviará toda a comunicação para o processo do nó Ockam que está sendo executado no host local. Esse processo Ockam local gerenciará automaticamente a geração de chaves criptográficas, estabelecendo um canal seguro para comunicação com quaisquer nós produtores e, posteriormente, recebendo, descriptografando e encaminhando quaisquer mensagens recebidas do corretor em execução em nosso cluster Confluent Cloud.

Envie mensagens criptografadas de vários produtores

Para ter mensagens para nosso consumidor processar, precisamos ter algo que as produza. Passaremos por um processo muito semelhante agora, mas criaremos as peças necessárias para um produtor. Começamos mais uma vez criando uma identidade no host do produtor (novamente, instale o comando Ockam nesse host, se necessário):

 ockam identity create producer1

Copie os arquivos project.json e producer1.token da seção anterior e use-os para autenticar e se inscrever em nosso projeto Ockam:

 ockam project authenticate \ --project-path project.json \ --identity producer1 \ --token $(cat producer1.token)

Crie um nó e vincule-o ao projeto e à identidade que criamos:

 ockam node create producer1 \ --project project.json \ --identity producer1

E exponha nosso servidor de inicialização Kafka na porta 5000 para que possamos começar a enviar mensagens por meio do Confluent Cloud:

 ockam service start kafka-producer \ --node producer1 \ --project-route /project/default \ --bootstrap-server-ip 127.0.0.1 \ --bootstrap-server-port 5000 \ --brokers-port-range 5001-5100

Certifique-se de copiar o arquivo kafka.config e iniciar seu produtor:

 kafka-console-producer.sh \ --topic demo-topic \ --bootstrap-server localhost:5000 \ --producer.config kafka.config

Seu código de produtor existente agora estará em execução, comunicando-se com o agente por meio do portal seguro que criamos que expôs o servidor de inicialização Kafka e os agentes Kafka em portas locais e enviando mensagens para o consumidor que foi configurado na etapa anterior. No entanto, todas as cargas de mensagem serão criptografadas de forma transparente quando entrarem no nó do produtor e não serão descriptografadas até que saiam do nó do consumidor. Em nenhum ponto do trânsito, o intermediário pode ver a carga útil da mensagem de texto sem formatação que foi inicialmente enviada pelo produtor.

Para aprofundar este exemplo, você pode repetir esta etapa para o número N de produtores, gerando um novo token de inscrição para cada um e, em seguida, repetindo as etapas desta seção.

Se você observar as mensagens criptografadas dentro do Confluent Cloud, elas serão processadas como caracteres irreconhecíveis, como na captura de tela a seguir:

Fluxos de mensagens criptografadas de ponta a ponta

Um exemplo que leva apenas alguns minutos para ser implementado significa que pode ser fácil perder uma série de importantes melhorias de segurança e integridade que vêm dessa abordagem:

• Chaves exclusivas por identidade : cada consumidor e produtor gera suas próprias chaves criptográficas e recebe suas próprias credenciais exclusivas. Eles então os usam para estabelecer um canal seguro mutuamente confiável entre si. Ao remover a dependência de um serviço de terceiros para armazenar ou distribuir chaves, você pode reduzir sua área de superfície de vulnerabilidade e eliminar pontos únicos de falha.

  
  

• Transferência de dados à prova de adulteração : ao empurrar o controle das chaves para as bordas do sistema, onde ocorre a criptografia e descriptografia autenticada, nenhuma outra parte na cadeia de suprimentos é capaz de modificar os dados em trânsito. Você pode ter certeza de que os dados que você recebe no consumidor são exatamente os que foram enviados por seus produtores. Você também pode ter certeza de que apenas produtores autorizados podem gravar em um tópico, garantindo que os dados em seu tópico sejam altamente confiáveis. Se você tiver requisitos ainda mais rigorosos, poderá assumir o controle de sua autoridade de credencial e aplicar políticas de autorização granulares.

  
  

• Janela de exposição reduzida : os canais seguros da Ockam alternam regularmente chaves de autenticação e segredos de sessão. Essa abordagem significa que, se um desses segredos de sessão for exposto, sua janela total de exposição de dados será limitada à pequena duração em que o segredo estava em uso. A rotação das chaves de autenticação significa que, mesmo quando as chaves de identidade de um produtor são comprometidas, nenhum dado histórico é comprometido. Você pode remover seletivamente o produtor comprometido e seus dados. Com abordagens centralizadas de distribuição de chaves compartilhadas, existe o risco de que todos os dados atuais e históricos não sejam confiáveis ​​após uma violação porque podem ter sido adulterados ou roubados. A abordagem da Ockam elimina o risco de dados históricos comprometidos e minimiza o risco de dados futuros usando chaves de rotação automática.

  
  

Todos esses benefícios são possíveis, hoje, sem alterações de código e alteração mínima de configuração nas implantações existentes.

Próximos passos

• Se você ainda não seguiu o exemplo deste guia, você pode começar a usar Ockam gratuitamente seguindo as instruções em nossa documentação.
• Se você quiser falar especificamente sobre este ou outros possíveis casos de uso para Ockam, a equipe ficará feliz em Conversar com você .
• Como alternativa, você pode se juntar a nós e a uma comunidade cada vez maior de desenvolvedores que desejam criar confiança criando aplicativos seguros por design, no Construa um servidor Trust Discord ou em GithubGenericName .