Em setores como finanças, saúde e varejo, o uso do Apache Kafka inclui cada vez mais o streaming de informações de identificação pessoal (PII) e outros dados confidenciais dentro e fora da rede. Os dados dos clientes em Kafka sinalizam uma adoção mais profunda do streaming, o que é uma ótima notícia, mas também levanta a questão: a infraestrutura de Kafka está adequadamente protegida?
Kafka não está seguro imediatamente, infelizmente. Existem listas de controle de acesso (ACLs) adequadas para usar o Kafka com um pequeno número de aplicativos. No entanto, pode ser complicado e demorado para organizações maiores com requisitos complexos de controle de acesso gerenciar ACLs. Não existe uma maneira integrada de lidar com informações confidenciais, que precisam ser ocultadas por motivos de privacidade, mas ainda acessíveis o suficiente para que a equipe de desenvolvimento depure os problemas. As empresas também precisam cada vez mais de partilhar dados com terceiros em Kafka, o que introduz preocupações adicionais de segurança.
Se você tiver a tarefa de implementar o roteiro de segurança Kafka em sua organização, deverá considerar seus requisitos de segurança atuais e como eles mudarão à medida que você escalar. A seguir estão algumas coisas a serem consideradas ao estabelecer sua postura de segurança Kafka, como controle de acesso, mascaramento de PII e práticas recomendadas de compartilhamento de dados.
As ACLs Kafka são adequadas para desenvolvimento, testes e implantações menores, mas podem se tornar muito complexas para gerenciar quando usadas em produção em grandes organizações com muitos usuários, tópicos e aplicativos. Isso ocorre principalmente porque as ACLs são detalhadas e exigem especificidade ao escrever regras de acesso: sempre que um usuário ou grupo é adicionado ou alterado, você deve adicionar ou remover uma entrada ACL, e as listas de acesso se tornam cada vez mais difíceis de manter.
Outro ponto fraco das ACLs é que elas não cobrem todos os recursos do ecossistema Kafka. Embora possam controlar o acesso a tópicos e grupos de consumidores do Kafka, não podem controlar o acesso a outros componentes do ecossistema, como o Kafka Connect e o Schema Registry.
As ACLs também são bastante rígidas, acrescentando atrito aos processos de segurança em casos de uso corporativo. Muitas vezes, as empresas precisam conceder e revogar acesso de forma dinâmica com base em regras de usuários, grupos e outras informações contextuais. Este é um processo manual demorado ao trabalhar diretamente com ACLs. Quando a implementação de permissões granulares é inconveniente, é tentador conceder permissões gerais a um usuário para reduzir o número de solicitações de acesso, o que abre a porta para um possível uso indevido de dados.
Embora o controle de acesso seja um fator de segurança significativo, não é o apenas considerações para planejar e implementar segurança de dados em Kafka. Você também deve considerar a configuração de sua implantação, métodos de restrição, mascaramento de PII, criptografia de dados e como e onde seus dados são compartilhados.
Fonte: Maestro
Kafka é um sistema complexo com configurações complexas e, por mais cuidadoso que você seja, erros acontecem. A melhor maneira de mitigar isso é dificultar a bagunça adicionando grades de proteção. Colocar uma camada de abstração entre você, a configuração e as ACLs ajuda a garantir que a configuração funcione conforme planejado e destaca possíveis problemas.
Essa abordagem também é benéfica para ambientes de produtores Kafka. Embora ter um grande número de configurações de produtor proporcione flexibilidade, apresenta riscos como configuração incorreta de tamanhos de lote, criação de gargalos de desempenho e introdução de problemas de compatibilidade. Por outro lado, ter um conjunto de regras que garanta configurações aceitáveis do produtor simplifica o processo de configuração do produtor, o que reduz bastante as chances de cometer erros.
Fonte: Maestro
Os desenvolvedores que criam ou mantêm produtores e consumidores Kafka muitas vezes precisam de visibilidade sobre o que está acontecendo dentro do cluster Kafka para fins de desenvolvimento e depuração.
Por exemplo, se um desenvolvedor estiver trabalhando em um aplicativo de streaming para a equipe de checkout de uma empresa de varejo e algo estiver quebrado, ele poderá precisar inspecionar o estado de um tópico ou examinar os detalhes de uma mensagem de falha na compra para entender e corrigir o problema. Em tais situações, fazer com que os desenvolvedores se precipitem no preenchimento de tickets de acesso causará frustração e atrasará a resolução do problema.
No entanto, conceder acesso ilimitado aos desenvolvedores pode produzir consequências indesejadas; os desenvolvedores cometem erros, e a melhor maneira de mitigar seu impacto é reduzir o intervalo de tempo para que esses erros aconteçam. Isto, juntamente com a implementação do acesso com privilégios mínimos aos principais recursos, evita que um desenvolvedor execute acidentalmente uma ação fora de sua competência atual que poderia impactar negativamente a saúde de um cluster Kafka.
Fonte: Maestro
ACLs e contas de serviço geralmente são suficientes para gerenciar o acesso de um aplicativo ao Kafka (exceto pela complexidade de gerenciamento que introduzem com um grande número de tópicos e aplicativos). O acesso ao aplicativo pode ter um escopo restrito e permanecer o mesmo ao longo do tempo, portanto, não há necessidade de ajustar frequentemente as configurações e potencialmente introduzir um novo problema.
Contudo, o acesso humano é diferente e deve ser tratado com um conjunto diferente de ferramentas. O controlo do acesso humano deve centrar-se na acção específica que as pessoas estão autorizadas a realizar e no tempo que levará para o fazer. As permissões humanas provavelmente mudarão com mais frequência, portanto, ferramentas como o Conductor Console podem agilizar o gerenciamento de permissões e reduzir a chance de erros.
Embora conceder aos desenvolvedores acesso total aos dados de produção acelere a depuração e a resolução de problemas, também cria riscos potenciais de conformidade. Se houver PII em um tópico de produção, conceder acesso aos dados brutos a qualquer pessoa – incluindo desenvolvedores que precisam corrigir um problema – pode violar as leis de privacidade do usuário.
A solução para isso é o mascaramento de PII. Mascarar os campos confidenciais em um conjunto de dados permite que seus desenvolvedores vejam as informações necessárias para resolver um problema, ao mesmo tempo que protegem informações pessoais confidenciais. Isso ajuda a garantir que o desenvolvimento e a depuração não sejam prejudicados enquanto você permanece em conformidade com a lei.
Fonte: Maestro
Depois que você começa a lidar com os dados do cliente, a criptografia de ponta a ponta dos seus dados à medida que eles se movem pela infraestrutura se torna um requisito. À medida que suas implantações do Kafka — e o número e variedade de clientes que as acessam — aumentam, o gerenciamento do ciclo de vida dos certificados pode ficar complicado. Ferramentas escritas em diferentes linguagens de programação ou usando diferentes serviços de gerenciamento de chaves (KMSs) podem levar a uma maior complexidade de integração e resultar em dívida técnica.
Uma maneira comum de resolver questões de compatibilidade ao criptografar dados é usar uma biblioteca padronizada (ou conjunto de bibliotecas) para acesso ao Kafka em toda a organização e implementar as opções corretas de criptografia nessa biblioteca, tornando-a transparente para o desenvolvedor. É aqui que muitas equipes iniciam sua jornada de criptografia, mas essa abordagem pode criar dívidas técnicas à medida que a adoção de bibliotecas (ou bibliotecas) crescer.
Outra maneira de lidar com a criptografia é permitir qualquer biblioteca de criptografia, mas exigir o uso de middleware, como um proxy Kafka, para conectar-se ao cluster Kafka. Esse proxy é uma peça de arquitetura adicional que você precisa manter, mas os membros da sua equipe podem usar qualquer biblioteca de conexão que desejarem sem enfrentar problemas de compatibilidade.
É cada vez mais comum usar o Kafka para compartilhar dados fora da sua organização, mas isso apresenta novos pontos problemáticos para arquitetos e equipes de DevOps encarregados de proteger sua infraestrutura e evitar que os dados sejam compartilhados incorretamente.
Por exemplo, uma marca de comércio eletrónico pode querer dar aos parceiros afiliados acesso em tempo real a partes específicas dos dados de vendas, ao mesmo tempo que protege as PII sensíveis que não podem partilhar legalmente e os dados comerciais sensíveis que não querem divulgar.
Em vez de conceder acesso a terceiros à infraestrutura interna do Kafka, você pode fornecer uma implantação separada do Kafka fora da sua rede, replicando apenas os dados a serem compartilhados.
Fonte: Maestro
No entanto, isso traz sobrecarga adicional de infraestrutura (incluindo outro conjunto de ACLs para monitorar e gerenciar), e a replicação pode causar incerteza sobre uma única fonte de verdade.
Em vez de usar uma réplica, o acesso por proxy ao(s) cluster(s) principal(is) do Kafka é uma abordagem mais robusta e flexível. O proxy pode realizar controles de acesso e permitir acesso apenas a um subconjunto de dados conforme necessário, que é sempre mantido atualizado.
Nos estágios iniciais de desenvolvimento de seu aplicativo e de sua infraestrutura de suporte, você geralmente se concentra na facilidade de adoção e na conveniência. Diferentes equipes precisarão de acesso imediato a esses aspectos ao desenvolver e testar seus aplicativos e construir suas cadeias de ferramentas de suporte. Geralmente, somente à medida que você avança para a produção com dados reais é que a segurança se torna uma prioridade.
Isto pode levar a grandes problemas nas fases finais de desenvolvimento e implementação: o código deixa de funcionar conforme esperado à medida que são introduzidas políticas de segurança, falhas de segurança imprevistas são descobertas durante testes de penetração e os processos devem ser retrabalhados para incluir pedidos de acesso a dados e atualizações de ACL. Esse efeito se amplifica à medida que seus casos de uso aumentam e outros departamentos ou partes solicitam acesso aos dados.
Fonte: Maestro
Por estas razões, é muito melhor implementar as suas políticas de segurança Kafka o mais cedo possível. Proteger seus dados em movimento e em repouso agiliza esse processo e, junto com a implementação das práticas recomendadas de segurança do Kafka detalhadas acima, ajuda a proteger contra configurações incorretas comuns e problemas de acesso que levam a vazamentos de dados, divulgação acidental e invasões.
Se você está preocupado com a segurança de suas implantações Kafka e deseja aprender como gerenciá-las centralmente, agende hoje mesmo uma demonstração do Conductor.
YOUTUBE.COM/THENEWSTACK
A tecnologia avança rápido, não perca um episódio. Inscreva-se em nosso canal no YouTube para transmitir todos os nossos podcasts, entrevistas, demonstrações e muito mais.
SE INSCREVER
