Neste primeiro post vamos falar a respeito da segurança do SQL tanto o modelo On-Premisses quanto no modelo Azure SQL.
A segurança dos dados é um dos fatores mais importantes no mundo moderno baseado na cultura do ‘Data Drive’ e saber configurar as permissões, acessos e quais informações estarão acessíveis dentro do banco é de extrema importância, afinal, ninguém gostaria de ter seu salário divulgado pelos corredores da empresa nem o total de vendas de uma cia no debate no almoço.
Assim sendo, vamos iniciar essa série de post falando sobre os acessos, permissões e autorizações e também como configurar tanto no SQL Server quanto no Azure SQL.
E como a segurança é baseada??
Dentro do mecanismo do banco de dados, temos alguns recursos que auxiliam na configuração e provisionamento da segurança das informações nele gravadas, são elas:
- Data encryption – ocultar as informações sensíveis do banco de dados e pode ser dividida em dois níveis: Coluna e Banco de dados;
- Authentication – validação de um usuário no banco;
- Authorization – processo de checagem das permissões que um usuário tem;
- Change Tracking – é um mecanismo de log de segurança que registra toda e qualquer ação de um usuário realiza no banco, inclusive, os comandos no grupo de DML.
E acima desses quatro pontos mencionados temos os três camadas de autenticação onde podemos englobar cada um dos pontos destacados acima, são eles:
- Principals – que são os modelos de login para acesso ao banco de dados e podem ser divididos em três tipos:
- SQL Server Authentication (login e senha);
- Nota: costuma ser criado dentro do banco por um usuário com permissão
- Windows Authentication – garantido pelo administrador de domínio (AD) e também é conhecido como o Trust Connection.
- Nota: em versões on-premisses, este modelo de login deve ser adotado sendo considerado como boa prática pela própria Microsoft
- Azure Authentication – que é criado e garantido por um administrador de domínio dentro do portal Azure.
- Securables – este recurso é o que garante o acesso do usuário que já cumpriu a etapa anterior ao banco e pode ser dividido em cinco níveis: Servidor, Banco, Schema, tabela e coluna.
- Permissions – são as permissões que o usuário terá a partir do momento que ele consegue conectar em um banco de dados. As permissões e restrições podem ser concedidas via comandos, são eles: Grant, Deny e Revoke.
Com isso, finalizamos a parte introdutória a respeito da segurança e dos níveis de acesso e no próximo post, vamos trabalhar com as autorizações e permissões dentro do SQL.
Espero que gostem!
Gostei muito o post. Um app service entraria em qual dos três grupos de autenticação? Porque ele autentica com o AD do Azure, mas é um principal também, certo?
CurtirCurtido por 1 pessoa
Olá Lucina, boa noite!
obrigado por ter gostado do post!
Sim, só uma correção que seu comentário me chamou atenção e quando escrevi não percebi. Ali, são camadas de autenticação que o banco utiliza para permitir o acesso de um usuário ou app, como é o seu caso!
O seu user app iria bater no principals, que é o AzureAD, receber a validação e ao cair no banco, iria passar pelas validações de acesso a leitura e escrita e após isso, aos comandos que o seu usuário pode executar.
Essas são as três camadas e obrigado, irei corrigir esse pequeno erro!
Qualquer dúvida, entre em contato!
CurtirCurtir
E sim, você pode agrupar ele como um principal do AzureAD se houver uma política de usuários e acessos!
CurtirCurtir