A nuvem híbrida pode ser uma ótima maneira de adicionar flexibilidade às suas implantações locais existentes. Conforme discutimos em vários blogs, a nuvem pública pode ser um ótimo complemento para seu próprio datacenter, garantindo que você possa dimensionar facilmente para lidar com a carga, reduzir seu capex e ser usado para implementar procedimentos de recuperação de desastres. A segurança é outro aspecto que você deve pensar quando planeja construir tais sistemas. Nesta postagem do blog, falaremos sobre algumas das considerações de segurança para implantações MariaDB de nuvem híbrida.
Conectividade
VPN
A maior parte de toda infraestrutura híbrida é a rede. Afinal, estamos falando de dois ambientes, local, on-premise e nuvem pública, que precisam estar conectados e formar uma única entidade. A conexão deve ser criptografada. Como abordá-lo, existem inúmeras maneiras de fazê-lo.
Uma delas seria usar uma solução disponibilizada pelo provedor de nuvem - a maioria deles tem algum tipo de opção de conectividade disponível. Pode ser o AWS Direct Connect se você se integrar ao Amazon Web Services. Se você planeja usar o Google Cloud, as soluções são discutidas no seguinte site:https://cloud.google.com/hybrid-connectivity. Em resumo, há um número significativo de opções diferentes que variam desde a integração de VPN de hardware até a configuração do emparelhamento de BGP.
No outro lado do espectro, temos soluções VPN de software. OpenVPN ou software similar pode ser usado para configurar uma conexão de rede segura e criptografada entre seu próprio datacenter e a nuvem pública. Nesse caso, você precisaria de uma instância separada em execução na nuvem pública que será usada para o servidor VPN. A utilização de VPNs de software permite que você escolha a solução que melhor atende às suas necessidades e se adapta melhor ao seu ambiente.
Firewall
Bancos de dados nunca devem ser acessíveis a partir de redes externas. É fundamental construir seu ambiente de forma que a camada de banco de dados seja acessível apenas a partir do conjunto limitado de hosts. Exatamente o que é necessário e como fazer isso, cabe a você decidir. Uma configuração típica consistiria em uma camada de banco de dados segura que pode ser acessada apenas a partir da camada de proxy e, se necessário, algum tipo de host de salto deve ser implementado, se necessário, para tarefas de automação e administração.
Os servidores de aplicativos não devem ter acesso direto ao banco de dados - eles não precisam. Tudo o que o aplicativo deve fazer é se conectar ao balanceador de carga. Os balanceadores de carga devem ser capazes de se conectar ao banco de dados. Um balanceador de carga como o ProxySQL é perfeitamente capaz de realizar a divisão de leitura/gravação e enviar as leituras e gravações para os nós de banco de dados corretos. O aplicativo deve ser capaz de se conectar ao ProxySQL e o resto será tratado pelo proxy - autenticação de banco de dados, modelagem de tráfego, distribuição do tráfego por várias réplicas que você possa ter. Todo acesso desnecessário deve ser restrito. Grupos de segurança, firewalls - essas são as ferramentas que você deseja usar para proteger seu ambiente.
Em resumo, o acesso aos hosts do banco de dados deve ser permitido apenas nas portas necessárias. Para o MariaDB será, obviamente, uma porta usada para o banco de dados, mas também outras portas, se necessário - você pode ter algum tipo de exportador ou agente instalado. Para Galera, você precisaria abrir portas para comunicação intra-cluster. Você também pode querer ter uma porta aberta para conexões SSH. Idealmente, limite o acesso por host; apenas um conjunto limitado de hosts pode acessar uma determinada porta. Por exemplo, a porta do banco de dados pode ser acessível a partir de outros nós do banco de dados, localhost e camada proxy. Não há necessidade de mantê-lo aberto para outros nós. Seus nós de banco de dados podem até estar localizados em uma sub-rede separada, garantindo que a segurança seja ainda mais rígida.
Quanto às portas, as melhores práticas seriam alterá-las das configurações padrão para outra coisa. Idealmente, algo aleatório. Alterar a porta SSH de 22 para 2222 ou a porta MariaDB de 3306 para 33306 pode ajudar a evitar alguns dos ataques automatizados, mas ainda pode ser descoberto se alguém estiver procurando ativamente entrar em sua rede. Se você quiser uma segurança melhor, você pode simplesmente ir em frente com alguns valores aleatórios. Defina SSH para 5762 e MariaDB para 24359. É bem provável que ninguém consiga adivinhar. Defina seus tempos limite de TCP para que as varreduras de porta sejam muito longas e caras e isso certamente aumentará suas chances.
SSL
Além da VPN e do firewall, você deve garantir que o tráfego do banco de dados seja criptografado usando SSL.
Idealmente, você protegerá as conexões front-end (dos balanceadores de carga) e a comunicação entre seus nós de banco de dados (seja replicação ou transferência intra-cluster em clusters Galera). O ClusterControl pode ajudá-lo a habilitar essas opções com apenas alguns cliques.
Tudo o que você precisa fazer é permitir que o ClusterControl crie novos certificados ou use um dos existentes - você pode importar seu próprio certificado, se desejar. Ter o SSL habilitado garante que o tráfego do banco de dados não seja legível, mesmo por alguém que obteve acesso à sua rede.
Segurança do banco de dados
É claro que a rede não é o único aspecto importante da segurança. Sim, é fundamental, especialmente no ambiente de nuvem híbrida, mas também há outros aspectos muito importantes. Um deles é o controle de acesso embutido no MariaDB.
Controle de acesso baseado em função para MariaDB
MariaDB vem com um conjunto de instrumentos para garantir que o acesso ao banco de dados seja devidamente gerenciado e restrito onde for necessário. A primeira linha de autenticação são os usuários. Todos e tudo que tem permissão para acessar o MariaDB deve usar um usuário atribuído para se conectar ao banco de dados. Esses usuários terão uma senha adequada - você pode ativar a validação de senha no MariaDB para garantir que as senhas sejam fortes o suficiente. Idealmente, você limitaria o host de acesso do usuário apenas a nomes de host ou IPs de balanceadores de carga - essa deve ser sempre a maneira como os usuários se conectam ao banco de dados. Para alguns usuários administrativos, você pode querer manter o acesso localhost, se necessário. Além de impor a força de senha adequada, você pode configurar a senha para expirar em algum período de tempo ou impor a rotação de senhas aos usuários. Como você pode imaginar, uma política de rotação de senha adequada é algo que você deseja implementar.
Todo usuário no MariaDB pode ter vários privilégios atribuídos. Os privilégios podem ser atribuídos em vários níveis - nível global, nível de banco de dados, nível de tabela ou até mesmo nível de coluna. A melhor prática é conceder um conjunto limitado de privilégios aos usuários possível. Se o usuário precisar apenas de acesso a uma determinada tabela, apenas conceda isso a ele. Não há necessidade de esse usuário acessar outras tabelas e nem mencionar outros esquemas. Você pode definir direitos de acesso bastante detalhados usando um grande conjunto de privilégios que você pode conceder aos usuários. Ele varia de direitos para ler, atualizar ou excluir dados por meio de privilégios de gerenciamento de banco de dados até o privilégio “super” que permite ao usuário executar ações como gerenciar os threads de replicação e ignorar a configuração read_only.
Além disso, o MariaDB vem com funções - para facilitar o gerenciamento de usuários, é possível definir funções com um determinado conjunto de privilégios concedidos e depois atribuir essas funções aos usuários. Esses usuários herdarão concessões relacionadas à função para a qual foram atribuídos, facilitando o gerenciamento de concessões em larga escala:em vez de alterar as concessões para vários usuários, você pode atribuí-los a uma função específica e gerenciar todos os seus privilégios por alterando os privilégios concedidos à função para a qual foram atribuídos.
Você também deve garantir que não tenha nenhum usuário pré-existente sem uma senha atribuída ou com um conjunto muito grande de privilégios. Essa auditoria de segurança deve ser realizada de tempos em tempos, garantindo que você esteja ciente dos possíveis riscos de segurança e possa planejar agir sobre eles.
Registro de auditoria
Se seu banco de dados vier com log de auditoria, assim como o MariaDB, você deve considerar usá-lo para rastrear as ações que estão acontecendo no banco de dados. O log de auditoria o ajudará a fazer isso. Com ele ativado, você poderá rastrear até mesmo os detalhes como qual usuário executou qual consulta. Se você usar o ClusterControl, poderá habilitar o log de auditoria com apenas alguns cliques:
Para resumir este blog, há algumas coisas que você deve considerar ao projetar uma implantação do MariaDB no ambiente de nuvem híbrida. Alguns deles estão estritamente relacionados à forma como o ambiente é projetado, alguns estão relacionados ao tipo de banco de dados que você usa e o fato de você usar a nuvem híbrida não muda muito. O que é realmente importante é garantir que seu banco de dados esteja devidamente protegido - esse é o objetivo final, não importa qual seja o ambiente.
