Fala MongoDB - Ep. 21: Protegendo seus Dados: Estratégias de Segurança no MongoDB Atlas

[Música] Olá, bem-vindos. O nosso série de conteúdos fala MongoDB. Eu sou Julia Comarim, responsável pelo marketing da MongoDB no Brasil. Eu sou o Lorenzo Taborda, trabalho na arquitetura de solução da MongoDB para o Brasil. E hoje, Júri, nós vamos falar sobre como mitigar riscos e proteger os dados das nossas aplicações críticas em MongoDB Atlas. Para começar, vamos falar sobre qual são as principais funcionalidades do MongoDB que podem servir para nos ajudar com a segurança. Bom, a gente tem um cardápio amplo para falar. Então, primeiro, quero estabelecer com vocês um pilar específico de segurança. Então, nós temos possibilidades de trabalhar sempre com criptografias e dentro da área de criptografia, nós vamos descobrir que temos mais três possibilidades de trabalho. Primeiro, criptografia em repouso, que é justamente quando o dado está guardado, repousado no disco de MongoDB. Depois, nós temos também criptografia entranzido, ou seja, quando os dados estão trafegando entre a aplicação e o cluster e entre os nós do nosso cluster também. E uma terceira possibilidade de aplicação da criptografia é justamente em uso criptografia, em uso, que vai nos levar a criptografia de campo, que é justamente a possibilidade da gente ter na aplicação o mascaramento de dados com uma chave específica da aplicação, que vai fazer com que os dados sejam gravados já criptografados no MongoDB. Isso na verdade é sério para a gente gravar dados e proteger dados que vão permitir identificar uma pessoa, como, por exemplo, um CPF. Além disso, nós também temos auditoria, que serve para a gente ter uma rastreabilidade e entender quem ou qual a aplicação acessou o banco de dados e fez determinada ação de leitura, escrita, atualização ou exclusão. Também temos a possibilidade de permitir que haja a integração com as chaves específicas de criptografia que os nossos clientes utilizam, nos seus expectivos provedores de nuvem, trocando isso para nomes técnicos. É a integração com AWS, KMS, com Azure, que volte, e também com o GCP, com as chaves que nós temos no GCP. Então é possível trabalhar também com as próprias chaves. Além disso, nós também temos a possibilidade de fazer integração com provedores de LDAP e isso vai nos levar ao tópico de autenticação e autorização, que é justamente a gente ter certeza de quem está acessando o banco "é", quem dizer, isso é a tenticação, e ainda tem as permissões adequadas na aplicação, que é justamente a autorização. E ainda posso comentar já de um ponto de vista de rede que sempre que possível, a gente procura ter acesso privado ao nosso cluster para que o tráfego da aplicação, que já é criptografado, a contexto, por um método local, sem sair em internet pública, que é uma rota que nós não temos controle. Acho que dentro de tudo isso que você falou, você citou diversos itens. E eu queria que você ir lá em casa, e quais são as melhores práticas dentro de MongoDB Atlas para a gente garantir a segurança? Perfeito. Vamos começar, então, do ponto de vista da aplicação. Toda aplicação vai fazer um acesso no banco de dados, utilizando um usuário. E este usuário vai ter permissões específicas que são, justamente, o que a aplicação precisa fazer. Eu, pessoalmente, costumo recomendar a gente ter as permissões exatas para o que uma aplicação necessita fazer. O que uma aplicação precisa? Ter a capacidade de ler documentos em uma coleção, que faz parte de um banco de dados, não necessariamente precisa ler todos os bancos de dados ou todas as coleções que estão dentro do nosso cluster de MongoDB. Então, a primeira é configurar qual é o escopo da aplicação, seja, no nível da coleção ou no nível do banco de dados. E estas operações, primeira operação de leitura, certamente para gente recuperar as informações, a outra operação certamente é descrita ou de inserção, porque a gente consiga gravar novas informações naquela coleção, aquele banco de dados, e ainda falta a gente pensar na atualização. Certamente, uma aplicação precisa ter a capacidade de atualizar os documentos, e ainda a capacidade de excluir. Então, de todo um universo de possibilidades de operações, quatro são fundamentais para uma aplicação. E certamente, vão endereçar a maior parte dos casos de uso. É a escrita, é a leitura, a atualização e exclusão de documentos em uma coleção. E a gente agrupa isso num papel, que dentro do atas nós vamos encontrar como "custom roll". Então, eu associaria as "custom rolls" dentro das funcionalidades do MongoDB, as desiguranças, há uma aplicação e um usuário com este papel, que representa o acesso daquela aplicação. Eu acho que esse é o primeiro passo. A gente determina qual é o escopo que uma aplicação pode fazer. E para a gente fechar esse primeiro ponto, vou dar um conto, exemplo. Será que faz sentido que uma aplicação ter a permissão de criar um índice ou de excluir um índice de uma coleção? Provavelmente a resposta dessa pergunta é não, mas com certeza essa aplicação precisa ler, escrever, atualizar e excluir documentos em coleções. É realmente um bom ponto, Lorenzo. Em retomando para o ponto que a gente estava falando antes de autenticação e autorização, como isso é gerenciado dentro do MongoDB Atlas? Nós vamos ter dois níveis de acesso em MongoDB Atlas. O primeiro nível de acesso é justamente a interface gráfica ou a console do Atlas. Então ali nós temos a possibilidade de especificar quais são os usuários que têm acesso em quais projetos e organizações. Se é a primeira vez que você está ouvindo estes termos, vamos recapitular que dentro do Atlas, nós temos o conceito de conta, que é justamente aonde aparece o nosso e-mail. Então cada pessoa tem uma conta no Atlas. Esta conta está vinculada a uma organização. Geralmente a organização representa a sua empresa ou um departamento da sua empresa. E dentro das organizações nós vamos ter projetos. E os projetos são exatamente os contenedores dos clusters, é onde o cluster reside. E aqui eu já vou avançar num conceito um pouquinho mais técnico, também relacionando o projeto a uma sub-read. Então cada projeto está relacionado a uma rede. Então se você trabalha com a AWS ou GCP, eu estou falando da VPC. Se você trabalha com as úrgios, estou falando da Venet. Então lembre-se já que para cada projeto nós temos uma rede. E é importante a gente falar sobre redes, porque geralmente ambientes distintos e aplicações distintas residen em redes diferentes. Então por consequência eu coloco ambientes diferentes em projetos diferentes. Certamente eu vou ter um projeto para o meu ambiente produtivo, outro projeto para o meu ambiente de homologação e outro projeto para o meu ambiente de desenvolvimento. Assim nós já temos uma segregação a ponto de rede, que é bem interessante de trabalhar. Agora voltando ao ponto inicial da pergunta, que é a autorização e a autenticação. Então dentro da plataforma nós vamos criar usuários e estes usuários estão relacionados a console do Atlas, que é onde reside esses elementos principais que eu acabei de comentar. Aconta a organização e o projeto. E agora você já sabe que o projeto também significa uma rede, mas eu já vou falar de conectividade. É um projeto do Atlas que nós configuramos quem enxerga estes projetos e organizações. Adicionalmente a isso nós vamos também criar usuários dentro do cluster ou os usuários de banco de dados. E estes usuários que vão ter estes permitionamentos que eu comentei e estes papéis, uma aplicação tem usuário, uma pessoa vai ter outro usuário. E aqui a gente também já chega numa boa prática fundamental, cada pessoa tem o seu próprio acesso, cada aplicação também tem o seu próprio acesso. Ninguém vai acessar a mesma base de dados com o único usuário. Imagina toda uma população de pessoas desenvolvedoras e se tem 10 aplicações em produção, vai colocar o mesmo usuário para todo mundo? Não. E isso inclusive já nos leva uma outra conceita importante quando a gente trabalha em nuvem, que é o modelo de responsabilidade compartilhada. Então a ferramenta fornece todas as possibilidades da gente aplicar boas práticas, porém a responsabilidade final desta aplicação está com você, o poder de vocês, para justamente fazer com que a segregação de acesso aconteça e que seja possível identificar quem ou qual a aplicação está acessando banco de dados. Uma pergunta que se encaixa muito com isso que você falou é como funciona a auditoria nessas casos, porque a gente sabe que muito tempo você vai fazer. muitas empresas necessitam que tenham algum papel de auditoria, e eu queria muito entender como é que isso funciona dentro do MongoDB Atlas pra garantir que tenha segurança e saber quem é que fez o acesso em que em momento então queria saber como é que isso funciona. Ótimo ponto. E aqui galera, eu já quero trazer um ponto de atenção pra você que adora MongoDB Community. E eu também faço parte desse grupo, eu gosto do Community. Não existe auditoria no MongoDB Community, então se liga. Isso é um bom preço. É importante lembrar. Nós temos dentro do MongoDB Atlas e também do MongoDB Enterprise Advance. Que temos episódio aqui na nossa playlist, a possibilidade de justamente ligar auditoria ou rastriabilidade das ações. O que acontece quando a gente liga esta função? Nós vamos estabelecer níveis de auditoria e esse nível pode ser do mais leve passando para um nível mais moderado ou até um nível total onde toda a ação vai ser registrada num log pra uma possível auditoria, pra gente justamente consultar e entender quem acessou qual elemento, qual coleção e fez qual ação de leitura, de exclusão, de atualização de um documento. Então são níveis que a gente pode e deve configurar. E pra dar um exemplo de configuração, a gente pode fazer configurações pra, por exemplo, entender quais são as tentativas com sucesso, de acesso, e também as que estão com insucesso. Significa que a gente está tentando acertar um usuário, uma senha, possivelmente. Então com esses níveis de auditoria, a gente configura isso facilmente dentro do Atlas, tanto graficamente quanto por linha de comando e com isso nós vamos ter todo um log. Pra permitir essa rasta e a habilidade de ações que nós vamos ter dentro do cluster. E também já vou comentar pra quem já está trabalhando com Atlas, se você entrar no activity feed dentro do Atlas, nas configurações da organização, você já consegue ver todo o log de ações que estão acontecendo na plataforma. E quando eu assunto esse segurança, eu já discutei e falar muito sobre VPC Pearing. E eu queria que vocês explicassem para o pessoal o que é isso e o que tem a ver com o nuvem. Aqui nós já vamos encostar naquele outro tema que eu comentei, que é a conectividade com Atlas. E isso também já nos leva pensando em segurança também em um assunto que é a superfície de ataque. Qual são as portas que a gente tem para chegar no nosso banco de dados que está no nosso cluster. Então primeiro, VPC Pearing, na verdade estamos falando de redes que fazem parte do proveedor de nuvem. Como eu comentei dois proveedores adotaram o mesmo nome, a AWS e Google chamam de VPC. E na azul, nós temos a Venet, mas na prática, técnicamente o mesmo elemento. É uma rede que faz parte da nuvem. E como nós estamos trabalhando com computação, são máquinas, computacionais, computador, memória, certamente, nós vamos precisar de rede. E essa rede, então, é configurada pela rede na nuvem que é a VPC. O Atlas também vai estar rodando dentro de uma rede específica que nós vamos configurar. Então, nada mais natural do que a gente fazer o pareamento da rede onde o Atlas está rodando com a rede ou as redes que as nossas aplicações precisam para funcionar. Qual é o benefício da gente fazer esta configuração? Eu tenho acesso privado, acesso privado significa que eu não vou para a internet para chegar no recurso do Atlas. E não ir para a internet significa rota controlada, rota controlada é uma rota segura. E é mais rápido, fica mais próximo, se eu estiver trabalhando na mesma região e fazer o pareamento de duas VPCs, eu tenho acesso rápido e seguro para o cluster. E isso a gente chama de pareamento de redes ou VPC peering. Mas a gente também tem uma outra possibilidade de acesso privado ao Atlas, que é o Private Endpoint ou ponto de entrada privado, a tradução direta desse serviço. Como funciona, você ganha uma string de conexão para acesso privado, ou seja, rota controlada dentro da mesma região do Atlas. Porém, com a abstração das configurações de rede. Então, a galera de rede que está acompanhando a gente sabe que para fazer um pareamento de rede é necessário configurar blocos de endereçamento e p. Esses blocos não podem conflitar na prática que estou falando. Isso dá mais trabalho de ser feito, exige mais conhecimento. Então, para cenários em que a gente que abstraí esse esforço, o Private Endpoint é uma ótima alternativa para isso. E também para cenários, casos de uso, em que a gente precisa ter uma rua de mão única, o Private Endpoint faz isso também para a gente. Então são duas possibilidades de acesso privado que nós temos dos nossos recursos de aplicação para o nosso cluster em MongoDB Atlas. Você mencionou o repassipir, você mencionou o Private Endpoint, e você citou um pouco sobre os IPs. Você poderia explicar um pouco sobre essa questão dos IPs, como funciona e o que são para o pessoal também, entendeu? Claro que sim. Então, todo o recurso computacional que a gente ligar no provedor de nuvem, e que estiver claramente exposto a internet, vai ter um endereço, que é o internet IP Address, o endereço IP. Este endereço caracterizaria, inclusive, o que eu chamei de superfície de ataque, porque a gente pode trabalhar com o endereço específico ou com o bloco, um range de IPs. Dentro do Atlas, nós vamos ter uma terceira configuração da parte de conectividade, que é o IP Access List, ou List de Assessos IP. E nessa lista, nós vamos dizer que a gente está autorizado a tentar fazer uma conexão ao Atlas, ou ainda, o Atlas só vai responder para quem tiver dentro daquela faixa de IP, que está autorizada. Então, essa configuração é bem importante, e simplificando bastante o que eu conceito, eu estou falando de um conceito de Firewall. O Firewall básico fala quem pode e quem não pode ser atendido por uma requisição. Então, a gente configura esses endereços IPs, e a equipe são autorizados a chegar ao Atlas e o Atlas responde. E, da mesma maneira, dentro da configuração de rede do Atlas, nós também podemos, na primeira configuração do projeto, antes de ligar o nosso cluster, dizer qual é o range de IP, que nós queremos trabalhar. Aqui, vou pegar um pouquinho pesado e vou falar o seguinte, tem uma norma que é a RFC 1918, que fala para a gente os três blocos de IP privados, que nós vamos utilizar em redes dentro do provedor de nuvem, redes que nos estarão diretamente as postas à internet. O Atlas vai trabalhar com esses três ranges dessa norma de rede, e a gente configura isso, na primeira vez, antes de ligar o cluster dentro do projeto, está a primeira configuração do projeto a essa, e você já tem o bloco de pasteabelescido, combina isso com o IP access list, restringe o máximo possível à sua superfície de ataque, e aqui, galera técnica, nada de botar em produção 0.0.0/0, que significa acesso total, né, qualquer ente. Ente na internet vai ter acesso, então, essa certamente não é uma boa prática. Agora que a gente falar um pouquinho de conectividade, eu queria entender também as opções de backup, deu alguma coisa errada, quais são as opções de backup que a gente tem acesso dentro do MongoDB Atlas? Quero começar primeiro, lembrando o seguinte, em Atlas, nós vamos trabalhar com aquele famoso SLA de 99.995% do tempo disponível. Certamente a sua pergunta vem porque você está preocupada com esse restinho, o que que acontece se a gente tiver uma disponibilidade ou um problema, como é que a gente é a interessa perda de dados que pode acontecer. Então, apesar de estarmos trabalhando no Atlas, que é justamente para mitigar isso, nós temos sim possibilidades adicionais, e aí nós vamos falar de backup, ou salva guarda de dados, em bom português. Dentro do Atlas, nós vamos ter duas funções. Primeiro, que a gente chama de Cloud backup ou backup da nuvem, que significa tirar uma foto daquele momento do nosso cluster. E, técnicamente, estou falando de um snapshot do nosso cluster, que é o snapshot, é uma cópia de tudo que você tem naquele ponto do tempo. E este ponto do tempo é configurado, sendo que ele, na sua configuração mais gano-lar, é de hora em hora. E a gente configura se eu quero fazer de hora em hora, cada seis horas, a cada 24 horas, uma vez ao mês, uma vez ao ano, não. Então, a decisão que nós temos que tomar agora é o seguinte, se o meu nível mínimo, o inicial de backup, é a cada hora, o nosso requisito de negócio sobrevive-se perder uma hora de dados. Se ele sobrevive sem problemas, nós não perdemos cliente, não perdemos dinheiro. não perdemos o nosso emprego, está tudo bem, você trabalha com o backup de Snapchat ou Cloud backup. Só que é muito comum nós ter nos requisitos de negócio mais críticos e que o objetivo de recuperação famoso RPO que a gente persegue nas operações é no minuto ou ponto a ponto na operação. Então para este cenário em que eu tenho esse requisito muito elevado e eu não posso perder menos de um minuto de informação nós vamos trabalhar com o backup contínuo ou dentro do atas a gente vai encontrar isso com o nome de Continuous Cloud backup. Galera de MongoDB que está conectado com a gente eu estou falando de fazer um backup do oplog do banco de dados o oplog é o log de operações estão tudo que o banco está realizando descrita de atualização de exclusão é logado é gravado nesta nesse diário de bordo do cluster então a gente consegue ter ali passo a passo ponto a ponto tudo que está acontecendo no no nosso cluster. Se nós temos este backup realizado nós temos a possibilidade de restaurar caso aconteça essa eventualidade então a gente usa isso combinado um snap shot mais a configuração do Continuous Cloud backup para esse requisito específico de altíssima critisidade que eu não posso perder nenhum ponto de dados e a configuração vai de um dia até sete dias então a gente combine essas duas coisas e com isso a gente minimiza o famoso rp. E quando eu uso um ou outro você tem exemplos de industrias que normalmente preferem usar um que normalmente preferem usar outro sabe o pessoal que está assistindo conseguisse enxergar mais um dia a dia. Bom aqui nós vamos falar principalmente de rp maior o ponto de recuperação se eu estou num ambiente que pode sobreviver a essa uma hora provavelmente eu não vou querer gastar com um backup adicional que é o backup contino geralmente aplicações menos críticas se são produtivas vão ter esta configuração ou ainda um ambiente de uma logação ou um ambiente de desenvolvimento então todo caso de uso que não precisa ter no minuto um ponto de recuperação vai se dar muito bem com o cloud backup e como o posto a isso nós vamos ter justamente o backup contino para todos os casos de uso que tem que ser no minuto então pensando em industrias certamente os bancos que a gente usa tem esse backup né o ponto a ponto na operação volta uma operação no passado é a indústria altamente reguladas né como forma sêutica a indústria de aviação certamente governo usa esse tipo de configuração então toda a criticidade vai estar muito mais apontada para o uso do backup contino no átolas. E como que o MongoDB aslas facilita na recuperação de dados e quais são as opções para a gente recuperar e fazer o backup e esses dados dentro da ferimenta. Perfeito acho que do ponto de vista de facilitar é clicar se você for para a interface gráfica e lembrando claro que você pode fazer sempre por linha de comando que a gente tem uma galera que nos acompanha amo vocês que gosta muito de escriptar código eu sei disso então você pode fazer por uma linha de comando simples um comando de comando a situação ou gráficamente você vai apontar qual é a imagem de backup que você deseja restaurar e interessante onde você quer fazer isso então um backup e a primeira coisa que a gente pensa é vou restaurar no próprio cluster e claro faz total sentido eu quero recuperar um ambiente que eventualmente foi danificado mas eu também posso usar essa qualidade para criar um segundo ambiente então imagina aquele caso de uso que é muito correqueiro da gente tem um ambiente produtivo e eu preciso fazer uma homologação de uma nova funcionalidade em um ambiente que seja fiel à produção então eu posso pegar uma imagem de backup da do nosso ambiente produtivo e restaurar um novo cluster que em alguns minutos talvez dezenas de minutos vai ficar disponível para ser esse ambiente de homologação é esse pré-produção então isso facilita muito na adoção aí de novas funcionalidades e uma outra coisa interessante também voltando ao ponto de indústria as críticas altamente reguladas que certamente eu tô falando de governo indústria financeira indústria farmacêutica indústria de aviação entre outras é muito comum a gente tem um requisito que fala o seguinte a imagem de backup tem que estar disponível na região que eu estou operando e além disso eu preciso ter uma cópia em outro continente ou em outra região geográfica que geralmente acaba sendo outra continente como é que a gente faz isso isso é um ponto interessante no passado quando a gente faz um backup num artefato físico que era uma fita você pegava que ela fita mandava literalmente por um meio de transporte pelo correio ponto lugar ponto dentro do atlas a gente tem uma possibilidade de criar cópias adicionais de backup que eu muito legal para esse tipo de requisito que a gente precisa ter a capacidade de se recuperar em outra região então se eu tô trabalhando a quem são Paulo no Brasil eu tenho que comprise requisito e a minha norma fala que o meu ambiente de recuperação é nos Estados Unidos e o que é o plano B e o meu plano ceta na Europa eu simplesmente configura duas cópias daquela imagem de backup e vou colocar isso na minha região de interesse nos Estados Unidos famosa a Norf Virginia que eu sei que vocês usam e vou colocar também na Europa vou colocar em Frankfurt essa outra imagem e com isso o atlas passa a gerenciar a transmissão da imagem de backup para essas regiões aconteceu uma catástrofe região de São Paulo ficou indisponível por qualquer razão que seja eu logo na região que eu tenho essa copa de backup cria um novo cluster e restauro a minha imagem lá nos Estados Unidos ou lá na Europa conforme for o requisito então dentro do atlas a gente vai encontrar isso com nome de a dish on the cap copias copias adicionais de imagens de backup então para requisitos que a gente tem que ter copias em outras regiões se faz isso com poucos cliques ou poucas linhas de comando tá e quem quiser saber mais e aplicar isso nos seus ambientes corporativos pode fazer o que pode falar comigo mande uma mensagem na minha rede social preferida você vai me encontrar facilmente no link edim me conta o que você está fazendo aí no seu ambiente produtivo o que sua aplicação faz e vai ser um prazer a gente trocar uma ideia está que você é uma a que tem a solução resiliante e segura para a sua organização isso é de lia com o marinho e as com os alvos pelo marketing da mongo db eu sou o Lorenzo da borda a que tem a solução da mongo db para o Brasil e esse aqui é o fala mongo db até a próxima tchau