GDPR – Principle of least privilege

Principle of least privilege – Principio do menor privilegio é a prática de limitar os direitos de acesso dos usuários às permissões mínimas necessárias para realizar seu trabalho. Apenas os direitos mínimos necessários devem ser atribuídos a um indivíduo que solicita acesso a um recurso e deve estar em vigor pelo menor tempo necessário. Esse conceito pode ser aplicado a usuários, programas ou processos que interagem de alguma forma com acesso a dados.

Algumas atribuições de privilégios podem ser baseadas em funções ou unidades de negócios como marketing, recursos humanos ou TI.

Como implementar o POLP

  • Realização de auditorias de privilégios, verificando todos os processos, programas e contas existentes para garantir que eles tenham apenas as permissões necessárias para realizar seu trabalho.
  • Iniciando todas as contas com o menor privilégio, definindo o padrão para todos os novos privilégios de conta o mais baixo possível e adicionando privilégios de nível superior somente conforme necessário para executar as tarefas.
  • Implementando a separação de privilégios, separando as contas administrativas das contas padrão e as funções do sistema de nível superior das contas inferiores.
  • Atribuir privilégios just-in-time restringindo os privilégios de nível superior apenas ao momento em que eles são realmente necessários.
  • Acompanhar e rastrear ações individuais usando credenciais de uso único, monitoramento e auditoria automática para facilitar o rastreamento das ações do usuário, permitindo que as organizações limitem os danos

Esses passos podem ser utilizados por diversas áreas além de banco de dados.

Vou mostrar como eu implementei esse processo de POLP e já adianto que foi a tarefa mais demorada de toda a implementação do GDPR (General Data Protection Rules).

Nesse processo foi fundamental o auxílio de uma ferramenta grátis, dbatools, que eu acredito que todos que trabalham com SQL Server deveriam conhecer. Eu gostaria de agradecer o Claudio Silva (blog/twitter) por me ajudar prontamente com as dúvidas!

Revisar membros da role sysadmin

$sqllist =  "sql01","sql02","sql03"
$sqllist |  Get-DbaUserLevelPermission -Database master -Verbose | Where-Object {$_.RoleSecurableClass -eq "sysadmin"} | Out-GridView #| Export-Csv "c:\temp\Audit-SQL-sysadmin-permission.csv"

Com um simples comando eu pude exportar uma lista completa de todos os sysadmin das minhas instancias.

Obs.: Esses simples exemplos são suficientes para iniciar uma análise.

Revisar permissões de CONTROL SERVER

$sqllist =  "sql01","sql02","sql03"
$sqllist |  Get-DbaUserLevelPermission -Database master -Verbose | Where-Object {$_.Permission -eq "CONTROL SERVER"} | Out-GridView #| Export-Csv "c:\temp\Audit-SQL-sysadmin-permission.csv"

http://www.sqlservercentral.com/blogs/brian_kelley/2009/03/06/control-server-vs-sysadmin-membership/

https://docs.microsoft.com/en-us/sql/t-sql/statements/grant-server-permissions-transact-sql?view=sql-server-2017

Revisar permissões a nivel de servidor

$sqllist =  "sql01","sql02","sql03"
$sqllist |  Get-DbaUserLevelPermission -Database master |Where-Object {$_.RoleSecurableClass -eq "SERVER" -and $_.Permission -inotin "CONNECT SQL","CONTROL SERVER"   } | Out-GridView #| Export-Csv "c:\temp\Audit-SQL-server-side-permission.csv"

Usar a VIEW SERVER STATE

É normalmente usado para solução de problemas ou atividades relacionadas ao desempenho e é a melhor alternativa para não conceder permissão de sysadmin, especialmente para pessoas externas

Dynamic management views (DMV) retornam informações de estado do servidor que podem ser usadas para monitorar a integridade de uma instância do servidor, diagnosticar problemas e ajustar o desempenho

https://docs.microsoft.com/en-us/sql/t-sql/statements/grant-server-permissions-transact-sql

Revisar todas as permissões para todos os usuarios

Esse comando mostra todos server logins, server level securable, database logins e database securables

$sqllist =  "sql01","sql02","sql03"
$sqllist |  Get-DbaUserLevelPermission -Database master |Where-Object {$_.RoleSecurableClass -inotin"sysadmin" -and $_.Permission -inotin "CONNECT SQL","CONTROL SERVER"   } | Out-GridView #  Export-Csv "c:\temp\Audit-SQL-server-side-permission.csv" 

Esse foi o ponto que mais gastou nosso tempo, pois rever permissões é sempre uma tarefa difícil. Não poderíamos simplesmente retirar permissões sem impactar o dia a dia dos usuários e por isso foi criado um documento para cruzar informações sobre a classificação de dados e as permissões de cada usuário.

https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql/authorization-and-permissions-in-sql-server

Remover logins desabilitados ou não utilizados

Nos monitoramos os logins de duas formas:

  • Extended Event
CREATE EVENT SESSION [XE_Getting_Login]
ON SERVER
ADD EVENT sqlserver.login
( ACTION ( sqlserver.client_app_name
,sqlserver.client_hostname
,sqlserver.database_id
,sqlserver.database_name
,sqlserver.username )
WHERE ( [sqlserver].[database_id] > ( 4 )))
ADD TARGET package0.event_file
( SET filename = N'XE_Getting_Login' )
WITH ( MAX_MEMORY = 4096KB
,EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS
,MAX_DISPATCH_LATENCY = 30 SECONDS
,MAX_EVENT_SIZE = 0KB
,MEMORY_PARTITION_MODE = NONE
,TRACK_CAUSALITY = OFF
,STARTUP_STATE = OFF );
GO
  • Audit
USE [master];
GO

CREATE SERVER AUDIT [Unused_Login]
TO FILE ( FILEPATH = N'S:\Audit\'
         ,MAXSIZE = 100MB
         ,MAX_ROLLOVER_FILES = 5
         ,RESERVE_DISK_SPACE = OFF )
WITH ( QUEUE_DELAY = 1000
      ,ON_FAILURE = CONTINUE
      ,AUDIT_GUID = '98c2b34e-aba9-4e4d-9691-dc315c057a70' );
GO

ALTER SERVER AUDIT [Unused_Login]
WITH ( STATE = ON );
GO

USE [master];
GO

CREATE SERVER AUDIT SPECIFICATION [ServerAuditSpecification_Unused_Login]
FOR SERVER AUDIT [Unused_Login]
  ADD ( AUDIT_CHANGE_GROUP )
 ,ADD ( SUCCESSFUL_LOGIN_GROUP )
WITH ( STATE = ON );
GO

Depois de 40 dias capturando as informações foi possível saber quais logins estavam sendo usados e facilmente excluímos os outros.

Criar windows group

Passamos a implantar essa pratica para facilitar a administração (inclusão e exclusão de usuário). Crie um windows group principalmente para os administradores do SQL Server. Eu fiquei espantado quando vi a resistência de algumas pessoas para criar grupos pelo simples fato que elas estavam acostumadas a apenas criar usuários.

https://www.mssqltips.com/sqlservertip/1831/using-windows-groups-for-sql-server-logins-as-a-best-practice/

Criar User-Defined Server Role e User-Defined Database Role

Uma maneira simples e fácil de gerenciar as permissões em seus bancos de dados e servidores. É possível você atribuir um conjunto de permissões a uma “role” ao invés de atribuir individualmente para cada usuário ou grupo de usuarios.

https://docs.microsoft.com/en-us/sql/relational-databases/security/authentication-access/server-level-roles

https://docs.microsoft.com/en-us/sql/relational-databases/security/authentication-access/database-level-roles

Criamos User-defined Server Role genéricas onde utilizamos a mesma estrutura (permissões) em todos as instancias, por exemplo, um grupo de usuários necessita ter a visibilidade de como está o estado na instancia. Nesse caso atribuímos a permissão de VIEW SERVER STATE.

Para cada database criamos “roles” de acordo com a necessidade deles. O que utilizamos foi a classificação dos dados que foi realizado para mandar tudo dentro do GDPR. Uma ideia que tivemos foi criar “tier” de acesso onde o “tier” mais básico tem acesso as informações públicas e o “tier” mais elevado tem acesso as informações confidencias.

Com isso tivemos um cruzamento assim: Classificação da informação X Usuário/Grupo de Usuário X Role (tier)

Forçar política de password

Nos literalmente forçamos todos os SQL Logins a utilizar essa política fazendo. E principalmente criamos auditoria para esse processo.

https://docs.microsoft.com/en-us/sql/relational-databases/security/password-policy

https://docs.microsoft.com/en-us/sql/relational-databases/security/strong-passwords

Replace user logins for databases contained

Isso de fato não foi um requerimento, mas é útil para que possamos realizar uma migração para Azure SQL Database. Achamos o momento oportuno, uma vez que estávamos revendo todas as permissões e tentamos utilizar contained database para a maioria das aplicações e usuários porem alguns sistemas “antigos”, não são legados pois ainda estão em uso, mas a manutenção é cara, não pudemos alterar.

https://docs.microsoft.com/en-us/sql/relational-databases/security/contained-database-users-making-your-database-portable?view=sql-server-2017

https://docs.microsoft.com/en-us/sql/relational-databases/databases/security-best-practices-with-contained-databases?view=sql-server-2017

https://docs.microsoft.com/en-us/sql/relational-databases/databases/migrate-to-a-partially-contained-database?view=sql-server-2017

Para finalizar todo nosso esforço criamos auditorias de acesso para saber se nosso trabalho estava correto e principalmente estar em conformidade com a nova regulamentação.

Eu irei falar de auditoria em breve 🙂

 

This is Tiago Balabuch's website, and this is a bit of copy about him. He is enthusiast, fascinated, passionate, fanatic by SQL Server and in the off-hours a Data Engineer who loves what he does and he is traveling in the cloud and surfing on the wave of the moment called Azure! Originally from Brazil and with encouragement from family and friends, Tiago moved to Europe in 2017 where lives in Ireland. In addition to being a data engineer, he is also active speaker in the SQL PASS events and keeps up to date on the key technologies and technical certifications. Tiago hold these certification MCT, MCSE - Data Management and Analystics, MCSA - SQL Server 2016/2014/2012. Simply psychedelic and manic he is just one more freak who likes SQL Server and its new features ...

Responda