Dados são o novo ouro para grandes empresas e organizações São considerados a força vital da maioria dos negócios modernos e há uma abundância de oportunidades para vender ou comercializar para o grande público da internet. Para as grandes empresas de comércio eletrônico ou de mídia social, os dados impulsionam sua capacidade de gerar grandes receitas e ganhos para os quais os dados são fortemente protegidos e possuem proteção sofisticada contra quaisquer ataques maliciosos e de intrusão online.
Assim, dados como ouro, seu estado valioso começa assim que são processados. Seu valor bruto está cheio de uma bagunça como se fosse uma mordida gigantesca e não classificada. Uma vez que sua essência é estruturada, o valor dos dados se multiplica. Imagine se você tiver um site de educação que permita que os usuários paguem. Depois de ter várias palestras e módulos que seu público-alvo pode aprender, desenvolver e obter um grau de produtividade, você entendeu o sabor da oportunidade e do sucesso, pois tem a porta para regular as taxas antes que eles possam obter os dados estruturados que desejam . Embora isso pareça o sonho de sucesso de todos, quando se trata de big data e sua essência subjacente, há muitas complicações para processá-lo e uma preocupação importante são as ameaças ao seu banco de dados.
As ameaças de banco de dados em geral têm vários e extensos setores para serem observados e examinados. Embora, as causas mais comuns sejam roubo de dados e violações de dados. Outra ameaça comum são privilégios extensivos ou acesso a bancos de dados atribuídos e/ou fornecidos incorretamente a um usuário. Proteger todo o host do servidor é uma preocupação para quem gerencia um banco de dados. Aprimorou sua segurança e lide com todos os tipos de ataques aplicáveis, como espionagem, alteração, reprodução e negação de serviço (DDoS), não apenas para o banco de dados, mas também para toda a pilha subjacente que tem acesso ou faz interface com seu armazenamento de dados.
Neste blog, discutiremos a extensão da necessidade do motivo pelo qual você precisa entender e ter privilégios de acesso ao banco de dados.
Perigos de privilégios de acesso incorretos
Nós inevitavelmente temos que compartilhar ou pelo menos criar um usuário tanto em nível físico quanto técnico. No entanto, fornecer acesso a outra pessoa significa que você confia na pessoa. Isso também significa que a pessoa autorizada precisa entender o perigo e o perigo de compartilhar acesso e dados do mundo exterior.
O ponto mais importante para proteger seus privilégios de acesso é o nível de entendimento sobre segurança entre seus engenheiros, como administrador de banco de dados, engenheiro de segurança ou administrador de servidor. Se a compreensão for ruim ou não tiver conhecimento e experiência, especialmente das vulnerabilidades e exposições mais atualizadas, isso pode ser um problema para a organização ou a empresa.
Existem coisas básicas que devem ser compreendidas e levadas em consideração para que tenha o mínimo ou pelo menos não possa ser invadida ou exposta. Caso contrário, isso pode colocar seus dados em risco do mundo exterior ou, pelo menos, para a pessoa ou pessoas erradas. Possivelmente para roubar seus dados e usá-los para obter ganhos financeiros ou eles podem resgatá-los de você e pedir dinheiro em troca de sua implementação de segurança ruim.
Nesta seção, vamos ver algumas causas comuns dessas ameaças à segurança.
Compartilhando privilégio de acesso root
Para um ambiente no local, um caso comum de violação de banco de dados depende principalmente do perigo de fornecer acesso root no nível do sistema operacional ou no nível do software do banco de dados. Há casos em que a senha de root é distribuída e exposta a várias pessoas, o que deve ser limitado apenas aos administradores que trabalham exclusivamente no sistema. Isso pode acontecer devido à falta de uma lista de verificação de segurança ou medidas no protocolo antes de implementar os privilégios de acesso. Ter uma lista de verificação de segurança ajuda a rastrear qualquer acesso e privilégios que possam expor riscos e perigos, especialmente quando um usuário específico do sistema operacional é exposto a um intruso. A lista de verificação também o ajuda a discutir ou ter uma visão geral das medidas de segurança em vigor e implementadas como um protocolo para sua organização.
Por exemplo, um usuário com acesso root pode causar muitos danos, como remover todos os seus dados de sua unidade de armazenamento físico, redefinir a senha de root, criar seu próprio usuário/senha que parece como um usuário legítimo (pode ser usado por muito tempo para coletar dados, a menos que seja detectado cedo), sudo para um usuário de sistema operacional diferente, como o usuário postgres, e muito mais coisas assustadoras para o intruso.
Se você estiver usando o MongoDB, um usuário com acesso root pode fazer login no seu servidor de banco de dados. Contanto que o intruso possa localizar seu /etc/mongod.conf ou seu arquivo de configuração mongodb e localizar o caminho de sua chave, é fácil fazer o login. Por exemplo, usar este comando permite que você faça login,
[[email protected] ~]# mongo -u __system -p "$(tr -d '\011-\015\040' < /etc/mongo-cluster.key)" --authenticationDatabase local --eval "db.adminCommand( { listDatabases: 1, nameOnly:1 } )"Considere uma configuração de instalação normal do MySQL, um acesso root pode ser deixado sem uma senha para acesso localhost. É fácil obter acesso uma vez que você é root. O acesso a arquivos como $HOME/.my.cnf ou a visualização do conteúdo de /etc/my.cnf o levará a obter acesso facilmente.
Recomenda-se fortemente limitar ou apenas dar seu acesso root y ao menor número de pessoas que estão trabalhando diretamente com o servidor para atualizar os pacotes, atualizações de segurança e aplicar patches que são exigidos pelo a equipe de desenvolvimento.
Usando sudoers corretamente
Os principais softwares de banco de dados de código aberto, como PostgreSQL, MySQL/MariaDB, MongoDB, exigem a criação de um usuário de sistema operacional específico. O usuário do SO requer uma função específica limitada para permitir o gerenciamento de seus recursos dentro da funcionalidade do banco de dados. As permissões adequadas de leitura e gravação precisam ser definidas para o caminho do dispositivo de armazenamento subjacente. No entanto, há casos em que alguns que estão usando esses usuários específicos para software de banco de dados têm privilégios sudo que também são capazes de acessar o usuário designado exclusivamente para acesso ao banco de dados. Os privilégios do usuário no sistema operacional devem ser limitados e é melhor limitar seu acesso com base na função. Por exemplo, para o Percona Server CVE-2016-6664, embora isso tenha sido corrigido, esse tipo de vulnerabilidade é um exemplo de um possível ataque de um usuário específico que tem acesso à conta MySQL e obtém acesso root. Os usuários do Sudo precisam ser revisados e entendidos que a função é limitada apenas a um trabalho específico.
Ativar o Linux Auditing System, como auditd, pode ajudar a melhorar a segurança, pois aumenta os privilégios de acesso negligenciados no nível do SO que podem levar a vulnerabilidades de segurança do seu banco de dados. SELinux e AppArmor são bons exemplos de módulos de segurança para seu ambiente Linux que hospedam seu sistema de banco de dados para ajudar a melhorar sua segurança contra intrusos ou violações que poderiam colocar seus dados em risco.
Conceder privilégios de acesso ao banco de dados
Os principais bancos de dados de código aberto oferecem uma lista granular de privilégios que podem ser personalizados para serem atribuídos apenas a uma ação específica para um usuário específico. Essa é uma maneira abrangente de ajudar os administradores de banco de dados a separar os dados com segurança e direcionar a ação com base em privilégios específicos.
Privilégios de acesso comuns
Seus privilégios mais usados devem ser baseados nestas três categorias:
-
Capaz de Ler/Localizar como SELECT, SHOW VIEW, FIND
-
Capaz de inserir/atualizar/excluir como INSERT, UPDATE, DELETE, REMOVE
-
Capaz de executar ações administrativas como CREATE USER, CREATE ROLE, ALTER, REPLICATION, DROP USER/TABLES/ SCHEMA's, operações de eliminação, etc.
Essas categorias podem ser estendidas para privilégios mais refinados com base em sua lista de verificação de segurança. É bom definir um usuário específico a ser criado com privilégios específicos para uma tarefa específica. Por exemplo, um aplicativo pode ter vários usuários com seus próprios privilégios designados atribuídos. Embora o aplicativo possa ser tão complexo com esse tipo de implementação. Há casos em que a conectividade por usuário pode consumir muitos recursos, como o uso de ORM como o Hibernate, por exemplo. Por outro lado, depende do projeto arquitetônico de sua aplicação. O propósito de uma base por usuário em um aplicativo pode ajudar a manter um privilégio de acesso ao banco de dados mais refinado e evitar danos aos seus dados por exclusões indesejadas, atualizações ou uma injeção de SQL atacando seu banco de dados.
Na maioria dos casos, um aplicativo usa um usuário para se conectar ao banco de dados que é limitado apenas às suas ações específicas para a execução do aplicativo. É melhor que você crie o privilégio de usuário do aplicativo para apenas acesso de leitura e gravação. Considerando que, se as ações administrativas forem necessárias, um script, daemon ou módulo específico em seu acesso ao aplicativo deve ser separado dos usuários normais.-.
Acesso ao banco de dados deve ser evitado
PostgreSQL e MySQL/MariaDB têm esta opção para conceder privilégios a um usuário usando TODOS. Para o PostgreSQL, também é melhor ter seu usuário com NOSUPERUSER. Se possível, isso deve ser evitado a todo custo. Esse privilégio pode fazer quase todas as ações que podem destruir ou prejudicar seus dados valiosos. Você pode usar TODOS os privilégios para seu acesso de administrador ou root, mas está limitado apenas a usuários que exigem os superprivilégios para realizar tarefas administrativas e gerenciar os dados.
Acesso por tabela ou por esquema
É uma boa prática fornecer acesso a um usuário apenas para as tabelas necessárias. . Portanto, mesmo que o usuário tenha alguns privilégios administrativos, qualquer dano é apenas a um conjunto limitado de tabelas. Ou você pode definir em todo o esquema; fornecer acesso a uma tabela limitada fornece um tipo granular de privilégios e ajuda a manter seus dados protegidos.
Acesso limitado apenas ao host
A conexão por meio de seu endereço IP de recurso ajuda a limitar o acesso aos seus dados. Evite usar '%' de tal forma que no MySQL, por exemplo,
GRANT SELECT, INSERT, DELETE ON mydb TO [email protected]'%' IDENTIFIED BY 'password';A extensão do dano é exposta a qualquer host para se conectar e isso não é o que você queria que acontecesse. Ele impõe vulnerabilidade e o desafio de invadir seu banco de dados é muito baixo.
Para PostgreSQL, certifique-se de ter configurado seu pg_hba.conf e o usuário somente para seu limite específico de host. Isso se aplica também ao MongoDB para o qual você pode configurá-lo em seu arquivo de configuração do MongoDB ou /etc/mongodb.conf. No MongoDB, você pode brincar com as restrições de autenticação e definir clientSource ou serverAddress respectivamente, mas apenas para os quais você está exigindo que o cliente ou usuário se conecte ou seja validado.
Controle de acesso baseado em função
O controle de acesso baseado em função (RBAC) em bancos de dados fornece uma maneira conveniente de gerenciar o usuário ou uma maneira fácil de agrupar um usuário com seu privilégio designado vinculado a uma lista de usuários ou grupo de usuários.
Embora você tenha que observar que as funções são tratadas de forma diferente em qualquer banco de dados de código aberto. Por exemplo, o MySQL definiu as funções da seguinte forma,
Uma função MySQL é uma coleção nomeada de privilégios. Assim como as contas de usuário, as funções podem ter privilégios concedidos e revogados.
Uma conta de usuário pode receber funções, o que concede à conta os privilégios associados a cada função. Isso permite a atribuição de conjuntos de privilégios a contas e fornece uma alternativa conveniente para conceder privilégios individuais, tanto para conceituar as atribuições de privilégios desejadas quanto para implementá-las.
MongoDB define função com RBAC como,
O MongoDB emprega o Controle de Acesso Baseado em Função (RBAC) para controlar o acesso a um sistema MongoDB. Um usuário recebe uma ou mais funções que determinam o acesso do usuário aos recursos e operações do banco de dados. Fora das atribuições de função, o usuário não tem acesso ao sistema.
Enquanto no PostgreSQL,
O PostgreSQL gerencia as permissões de acesso ao banco de dados usando o conceito de papéis. Uma função pode ser considerada um usuário de banco de dados ou um grupo de usuários de banco de dados, dependendo de como a função está configurada. As funções podem possuir objetos de banco de dados (por exemplo, tabelas e funções) e podem atribuir privilégios nesses objetos a outras funções para controlar quem tem acesso a quais objetos. Além disso, é possível conceder a associação de uma função a outra função, permitindo assim que a função de membro use privilégios atribuídos a outra função.
O conceito de papéis engloba os conceitos de “usuários” e “grupos”. Nas versões do PostgreSQL anteriores à 8.1, usuários e grupos eram tipos distintos de entidades, mas agora existem apenas papéis. Qualquer função pode atuar como usuário, grupo ou ambos.
Embora esses bancos de dados implementem as funções específicas de seu uso, eles compartilham o conceito de atribuir funções ao usuário para atribuir privilégios de forma conveniente. O uso de funções permite que os administradores de bancos de dados gerenciem os usuários necessários para efetuar login ou acessar o banco de dados.
Imagine se você tem uma lista de usuários que precisa gerenciar ou uma lista de usuários que podem ser descartados ou revogados quando não forem mais necessários. Em alguns casos específicos, se uma determinada tarefa precisar de trabalho, os administradores de banco de dados podem criar usuários com funções já definidas. Esses usuários criados podem ser atribuídos a uma função específica por apenas um curto período e, em seguida, revogados quando não forem necessários.
As auditorias também ajudam a segregar usuários com suspeita de vulnerabilidades ou exposição de dados, portanto, nesse caso, ajuda a gerenciar os usuários com funções com muita facilidade.
Sistema de gerenciamento de usuários
Se a segurança de seus dados for tratada e implementada de forma adequada, ela abrirá caminho para o sucesso. Embora não exista uma solução perfeita, vulnerabilidades e intrusões sempre evoluem também. É como um worm que tenta espreitar o tempo todo até conseguir atingir seu objetivo de violar sua segurança e obter acesso aos seus dados. Sem ferramentas adequadas, como sistemas de alerta ou avisos para quaisquer inseguranças e vulnerabilidades, seria difícil proteger seus dados.
ClusterControl ajuda você a gerenciar seus usuários e verificar ou verificar os privilégios de seus usuários de balanceadores de carga para os principais usuários do banco de dados. Também oferece conselheiros e alertas para notificá-lo sobre possíveis vulnerabilidades ou intrusões.
Por exemplo, usando um MySQL/MariaDB com um ProxySQL inicial, importa e adiciona usuários. Para importar usuários, ele coleta a lista de usuários que estão presentes em seu cluster MySQL/MariaDB atual e oferece a você a revisão de seus privilégios atuais. Ver abaixo,
Também neste caso, um usuário ProxySQL pode ser desativado rapidamente se tal vulnerabilidade foi conhecido para o usuário específico.
ClusterControl também oferece a você gerenciar usuários diretamente de seu banco de dados, como MySQL/MariaDB ou PostgreSQL. Para MySQL/MariaDB, você pode ir para
