Primeiro passos na segurança do Atlas Stream Processing
Robert Walters9 min read • Published May 02, 2024 • Updated May 17, 2024
Avalie esse Tutorial
A segurança é fundamental no domínio dos bancos de dados, e a proteção de dados de streaming não é exceção. Serviços de processamento de stream, como o Atlas Stream Processing lidam com dados confidenciais de uma variedade de fontes, o que os torna os principais alvos de atividades maliciosas. Medidas robustas de segurança, incluindo criptografia, controles de acesso e mecanismos de autenticação, são essenciais para mitigar riscos e manter a confiabilidade das informações que fluem por meio de pipelines de dados de streaming.
Além disso, a conformidade regulatória pode impor protocolos e configurações de segurança abrangentes, como impor auditorias e separação de tarefas. Neste artigo, abordaremos os recursos de segurança do Atlas Stream Processing, incluindo o controle de acesso e como configurar seu ambiente para suportar o acesso com mínimos privilégios. A auditoria e o monitoramento de atividades serão abordados em um artigo futuro.
Lembre-se que, no MongoDB Atlas, organizações, projetos e clusters são componentes hierárquicos que facilitam a organização e o gerenciamento dos recursos do MongoDB. Uma organização é uma entidade de nível superior que representa uma implantação independente do MongoDB Atlas e contém um ou mais projetos.
Um projeto é um contêiner lógico dentro de uma organização, agrupando recursos relacionados e servindo como uma unidade para controle de acesso e cobrança. Dentro de um projeto, os clusters MongoDB são distribuídos. Clusters são instâncias de bancos de dados MongoDB, cada um com suas próprias configurações, características de desempenho e dados. Os clusters podem abranger várias regiões de nuvem e zonas de disponibilidade para alta disponibilidade e recuperação de desastres.
Essa hierarquia permite o gerenciamento eficiente de implementações do MongoDB, controle de acesso e isolamento de recursos dentro do MongoDB Atlas.
Com relação à segurança, o Atlas tem duas entidades de usuário separadas: Atlas users e Atlas database users. Eles são definidos em escopos diferentes, com Atlas users sendo usados em organizações e projetos do Atlas, e Atlas database users sendo usados em Atlas clusters. É importante entender as diferenças e como seus usuários finais se autenticarão no Atlas Stream Processing. Vamos nos afundar nesses dois tipos de usuários.
Os usuários do Atlas autenticam apenas com UI do Atlas, API ou CLI (também conhecido como plano de controle). A autorização inclui acesso a uma organização Atlas e aos projetos Atlas dentro da organização.
O acesso dos usuários do Atlas aos clusters do Atlas é determinado pela associação em uma ou mais funções fixas da organização ou do projeto. Aqui está um exemplo de algumas dessas funções e seus recursos permissivos associados:
- Proprietário da organização - acesso raiz a toda a organização e projetos contidos dentro dela
- Proprietário do projeto da organização — pode criar projetos do Atlas
- ** Organização somente leitura ** — acesso somente leitura às configurações, usuários e projetos na organização
- Proprietário do projeto — tem acesso administrativo total
- Project Cluster Manager - pode atualizar clusters
- Administrador de Acesso a Dados do Project — pode acessar e modificar os dados e índices de um cluster e encerrar operações
- Leitura/gravação de acesso a dados do projeto — pode acessar os dados e índices de um cluster e modificardados
- Somente leitura de acesso a dados do projeto - pode acessar os dados e os índices de um cluster
- Projeto Somente leitura — só pode modificar preferências pessoais
Embora os Atlas users possam ter acesso a um Atlas cluster por meio de permissões de alto nível, como o Proprietário do projeto, eles só podem acessar o Atlas cluster por meio da UI do Atlas, da API do Atlas ou do Atlas CLI. Os usuários que desejam se conectar ao Atlas cluster por meio de um driver cliente como Java ou de uma ferramenta como o mongosh não podem, pois esses usuários do Atlas não existem no banco de dados do Atlas. É aqui que os usuários do banco de dados do Atlas entram em jogo.
Os utilizadores de banco de dados do Atlas autenticam-se com um Atlas cluster diretamente e não têm acesso à UI do Atlas, à API do Atlas ou ao Atlas CLI. Esses usuários se autenticam usando uma ferramenta cliente, como o mongosh , ou por meio de um driver do MongoDB, como o driver Java do MongoDB. Se você já usou um servidor MongoDB auto-hospedado, os usuários do banco de dados do Atlas serão equivalentes ao usuário MongoDB. O MongoDB Atlas suporta uma variedade de métodos de autenticação, como SCRAM (nome de usuário e senha), Autenticação de Proxy LDAP, OpenID Connect, Kerberos e x.509 Certificados. Enquanto os clientes usam qualquer um desses métodos para autenticar, os serviços do Atlas, como o Atlas Data Federation, acessam outros serviços do Atlas, como clusters do Atlas, por meio de x temporário.509 certificados. Esse mesmo conceito é usado no Atlas Stream Processing e será discutido mais tarde nesta publicação.
Observação: A menos que especificado de outra forma, um "user " neste artigo refere-se a um usuário do banco de dados Atlas.
A compreensão dos conceitos de plano de dados e plano de controle facilitará a compreensão e a configuração do Atlas Stream Processing. Em resumo, você cria a Instância de Processamento de Fluxo (SPI) e define as entradas do Registro de Conexão usando o plano de controle Atlas e um Atlas user, e se conecta a um SPI e cria processadores de fluxo usando uma conta deusuário de banco de dados Atlas. Se você ainda não estiver familiarizado com os componentes que compõem o Atlas Stream Processing, entraremos em mais detalhes na próxima seção.
O Atlas Stream Processing não existe dentro de um Atlas cluster. Em vez disso, ele está contido dentro de um projeto Atlas e não depende de um cluster Atlas. Considere o diagrama da arquitetura do Atlas Stream Processing abaixo:
Uma instância de processamento de fluxo é um agrupamento lógico de zero ou mais processadores de fluxo (SP). Esses processadores são criados dentro do SPI e operam dentro do provedor de nuvem e da região especificada no SPI. Os SPs aproveitam fontes de dados definidas no Connection Registry. Cada registro de conexão é mapeado diretamente para um SPI e contém definições de conexão, como conexões com outros clusters Atlas, dentro do mesmo projeto Atlas ou para sistemas Apache Kafka externos, como Confluent Cloud, AWS MSK ou uma implantação Kafka auto-hospedada, para cite alguns.
Agora que você tem uma compreensão básica da segurança do Atlas e da arquitetura do Atlas Stream Processing, vamos dar uma olhada em alguns recursos de segurança específicos e percorrer um exemplo de implementação de mínimos privilégios.
O Atlas Stream Processing está introduzindo uma nova função em nível de projeto chamada Project Stream Processing Owner (PSPO). Essa função pode executar o seguinte:
- Crie, modifique e exclua quaisquer Atlas Stream Processing dentro do projeto Atlas.
- Inicie e pare qualquer processador de stream dentro do projeto Atlas.
- Criar, atualizar e excluir todos os Registros de Conexão dentro do projeto Atlas.
- Visualizar/baixar registros do sistema para todos os SPIs no projeto Atlas.
- Exibir/baixar logs de auditoria para todos os SPIs no projeto Atlas.
- Gerencie todos os usuários e funções do banco de dados no projeto Atlas.
- Acesso de leitura/gravação aos Atlas clusters dentro do projeto.
O PSPO e qualquer outra função elevada, como Proprietário do Projeto ou Proprietário da Organização, podem executar as funções listadas acima. Embora a introdução da função PSPO reduza os privilégios do projeto em comparação com a função Proprietário do Projeto, ela ainda é uma função elevada e só difere de um Proprietário do Projeto em algumas áreas.Para obter mais informações, consulte adocumentaçãodo MongoDB.
A autenticação para SPIs opera de forma semelhante aos clusters do Atlas, onde somente os usuários definidos no plano de dados do Atlas (por exemplo, usuários do banco de dados do Atlas) têm permissão para se conectar e criar SPIs. É crucial entender esse conceito porque os SPIs e os Atlas clusters são entidades distintas dentro de um projeto do Atlas, mas compartilham o mesmo processo de autenticação por meio dos usuários do banco de dados do Atlas.
Por padrão, somente os usuários do Atlas que são proprietários de projeto ou proprietários do Atlas Stream Processing podem criar instâncias do Atlas Stream Processing. Esses usuários também têm a capacidade de criar, atualizar e excluir conexões de registro de conexão associadas a SPIs.
Depois que o SPI é criado, os usuários do banco de dados do Atlas podem se conectar a ele da mesma forma que fariam com um Atlas cluster por meio de uma ferramenta cliente como o mongosh. Qualquer usuário do banco de dados do Atlas com o "readWriteAnyDatabase " ou "atlasAdmin " integrado conectar a qualquer SPIs dentro do projeto.
Para usuários sem uma dessas permissões incorporadas ou para cenários em que os administradores desejam seguir o princípio do menor privilégio, os administradores podem criar uma função de banco de dados personalizada composta de ações específicas.
O Atlas Stream Processing introduz uma série de ações personalizadas que podem ser atribuídas a uma função de banco de dados personalizada. Por exemplo, se os administradores quisessem criar uma função de nível operacional que só pudesse iniciar, interromper e visualizar estatísticas de stream, eles poderiam criar uma função de usuário de banco de dados, “ASPOps,”, e adicionar as ações StartStreamProcessor, StopStreamProcessor e ListStreamProcessors. O administrador então concederia essa função ao usuário.
A seguir está uma lista de ações do Atlas Stream Processing:
- createStreamProcessor
- processStreamProcessor
- startStreamProcessor
- stopStreamProcessor
- dropStreamProcessor
- sampleStreamProcessor
- listStreamProcessors
- listConnections
- streamProcessorStats
Um problema que você pode perceber é se um usuário de banco de dados com o "readWriteAnyDatabase " integrado todas essas ações concedidas por padrão ou, se uma função personalizada tiver essas ações, ele tiver essas permissões de ação para todas as Instâncias de Atlas Stream Processing no projeto Atlas! Se sua organização quiser bloquear isso e restringir o acesso a SPIs específicos, ela pode fazer isso navegando até a seção "Restrict Access " e selecionando os SPIs desejados.
Suponha que haja dois usuários: um administrador e um desenvolvedor (que não é administrador). O administrador gostaria de fornecer ao desenvolvedor acesso a uma Atlas Stream Processing para uso com dados de streaming de um tópico do Kafka em um cluster do MongoDB Atlas. O administrador é um proprietário do projeto.
Um fluxo de trabalho de alto nível é o seguinte:
Etapa 1: o administrador cria a Instância de Processamento de Fluxo, "Stocks. "
Etapa 2: O administrador cria as entradas do Registro de Conexão, uma para a conexão com o Apache Kafka e outra para o Atlas cluster. O usuário seleciona "Read and Write to any database " em Executar como*.
Veja o comentário abaixo sobre "execute as. "
Etapa 3: O administrador cria uma nova função personalizada do banco de dados, "SPIAccess, ", e atribui as ações personalizadas do Atlas Stream Processing.
Etapa 4: O administrador cria uma nova conta de usuário do banco de dados (ou modifica o usuário desenvolvedor, se ele já existir) e atribui ao usuário a função personalizada “SPIAccess.”
Etapa 5: O administrador edita o usuário do banco de dados e especifica os SPIs exatos aos quais deseja que o usuário forneça acesso.
Nesse ponto, o desenvolvedor pode se conectar somente à Atlas Stream Processing, “Stocks,”, e criar novos processadores de stream usando uma ferramenta de desenvolvimento de cliente, como o mongosh, ou a extensão Visual Studio Code para MongoDB. Quando desenvolvem seus processadores de stream, eles gravam dados no cluster Atlas sob a função integrada “read and write any database”.
No cenário descrito acima, suponha que o desenvolvedor crie um processador de fluxo que use a conexão Kafka como origem e um cluster MongoDB Atlas como destino. Quando o administrador definiu a fonte Kafka, ele forneceu as credenciais de conexão. Embora o desenvolvedor não possa ver as credenciais ao executar comandos de processamento de fluxo (como arquivos .process ou .sample) ou ao executar processadores de fluxo, eles estão sendo executados no contexto de segurança dessas credenciais. No caso de um Atlas cluster, o administrador pode definir o contexto de segurança (por exemplo, qual usuário ou função) o Stream Processor usa ao se conectar ao Atlas cluster. Isso é importante porque, embora o desenvolvedor possa não ter acesso ao cluster especificado no registro de conexão, ele obteria acesso indiretamente por meio da execução do Processador de Stream. Para mitigar isso, os administradores devem executar como um usuário do banco de dados ou função com acesso de mínimo privilégio ao Atlas cluster.
Todas as três funções de usuário internas e quaisquer usuários com funções personalizadas aparecerão como opções em Executar como. Os administradores devem criar uma função personalizada que tenha apenas permissões suficientes no Atlas cluster de destino para executar as ações desejadas.
Lembre-se de que qualquer usuário do banco de dados Atlas com a função “readWriteAnyDatabase” tem acesso total a qualquer SPIs dentro do projeto. Se um administrador quiser negar acesso aos SPIs para esses usuários, ele deve revisar as configurações “Restrict Access” e garantir que nenhum SPIs seja selecionado.
Configurar a segurança para o Atlas Stream Processing envolve tanto os usuários do Atlas (plano de controle) quanto os usuários do banco de dados do Atlas (plano de dados). Embora o Atlas user role do Projeto seja a mais alta disponível, a nova função Proprietário do Projeto Atlas Stream Processing destina-se a conceder aos administradores do Atlas Stream Processing privilégios suficientes para criar Instâncias de Processamento de Stream e gerenciar os usuários do banco de dados do Atlas que precisam de acesso.
Depois que os administradores criam Atlas Stream Processing Instances, qualquer usuário do Atlas com o “readWriteAnyDatabase” ou “atlasAdmin” integrado pode se conectar a qualquer SPIs dentro do projeto. Para oferecer suporte a uma segurança mais refinada, o Atlas Stream Processing introduziu uma série de ações personalizadas que podem ser agrupadas para criar uma função de usuário de banco de dados personalizada. Essa função pode ser concedida aos usuários do banco de dados Atlas, permitindo que se conectem a uma Atlas Stream Processing sem qualquer permissão elevada, como atlasAdmin.
Embora um usuário de banco de dados tenha acesso a um SPI, ele só pode fazer referência às conexões definidas no registro de conexão para esse SPI. Esse usuário não pode criar, modificar ou excluir conexões, pois somente os usuários do Atlas que são membros da função Proprietário do Projeto ou Proprietários do Atlas Stream Processing podem gerenciar as conexões do registro de conexões. Existem algumas razões principais para essa restrição.
Primeiro, é importante não expor credenciais nem permitir que não administradores visualizem ou modifiquem informações confidenciais de conexão. Em segundo lugar, quando as conexões são usadas no pipeline de processamento de fluxo, essas conexões são executadas em um contexto de execução específico. Permitir que um não administrador seja executado em um contexto diferente pode dar a ele uma elevação de privilégio. Portanto, é melhor que as conexões do registro de conexões sejam executadas como uma função que tenha a quantidade mínima de permissões necessárias para realizar as operações das instâncias de processamento de fluxo.
Essa capacidade do Atlas Stream Processing de "execute as" uma função específica se aplica quando as conexões são para bancos de dados do Atlas. Se estiver usando o Kafka como fonte, forneça apenas a quantidade mínima de permissões necessárias para acessar o (s) tópico (s) usado (s) na instância de Atlas Stream Processing.
Com esses recursos de permissão granulares implementados, o Atlas Stream Processing permite que você obtenha o menor privilégio de acesso às instâncias e pipelines do seu processador de stream. Estamos entusiasmados em saber sobre sua experiência e nos avise se você tiver algum comentário.
Principais comentários nos fóruns
Ainda não há comentários sobre este artigo.