Categorias
SQL Server Troubleshooting Virtual PASS BR

Transparent Data Encryption and its tricks

[bing_translator]

Transparent Data Encryption – TDE não é mais uma novidade, mas sim uma realidade que devemos usar. Um ponto importante que vale ressaltar é que esse recurso está presente apenas na edição ENTERPRISE do SQL Server.
Existem alguns passos a passos na internet de como implementar, mas eu vou deixar um script que pode ser seguido.

Master Key e Certificados

Uma forma simples de implementar o TDE é utilizar um certificado gerado pelo próprio SQL Server que é protegido pela Master Service Key.
Se você está implementando ou pretende implementar lembre-se que o mais importante de tudo é fazer backup do certificado e das keys!

PARE TUDO e faça BACKUP 

O principal aspecto para utilizar o TDE está relacionado à protecao de chaves incluindo backups separados das chaves de criptografia e a capacitade de restaurar e recuperar esse banco de dados em outro local. Assim como qualquer outro plano de DR, a restauração de bancos de dados de TDE é algo que devemos praticar antes que ocorra o desastre. Você não quer descobrir depois de um evento  que você não estava fazendo o backup da chave TDE corretamente.

Mais uma vez eu utilizei o dbatools para me ajudar a automatizar minha tarefa e quero agradecer ao Claudio Silva  (blog/twitter) por me ajudar. Algumas linhas de powershell são suficientes para isso 🙂

Agora que o background está pronto, o TDE pode ser habilitado.

A diferença quando se está utilizando AlwaysON Availability Group está na preparação dos ambientes antes de habilitar o TDE. Ou seja, você deve criar chaves e certificados em todas réplicas que pertencem ao AG.

/*
  Following steps must be executed on PRIMARY REPLICA
*/
-- Check if MASTER KEY is created
USE master; 
GO

SELECT * FROM sys.symmetric_keys; 
SELECT * FROM sys.certificates;

/*
  Step 1: On Primary Replica - Creation of the Database MASTER KEY (DMK)
  We can skype this step because we already have it
  Make sure that MASTER KEY Backup is working correctly.
        Review backup routine! This is most important step to do 
*/
-- Create a Master Key IF NOT EXISTS
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'use_a_strong_password';
GO

-- Backup the Master Key
BACKUP MASTER KEY
TO FILE = '\\PrimaryReplica\TDE\PrimaryReplica_MasterKeyBackup.key'
ENCRYPTION BY PASSWORD = 'use_a_strong_password';
GO
/*
  Step 2: On Primary Replica - Creation of the CERTIFICATE
  Certificate is named as TDECert and it will use MASTER KEY to en
*/

-- Create Certificate Protected by Master Key
CREATE CERTIFICATE TDECert
WITH
  SUBJECT = 'Transparent Data Encryption Cerficate';
GO

/*
 Backup the Certificate
 Review backup routine. We should back up it to two/three different location
 Pick up a strong password 
*/
BACKUP CERTIFICATE Cert_For_TDE TO FILE = '\\PrimaryReplica\TDE\PrimaryReplica_Cert_For_TDE_Backup.cer'
WITH PRIVATE KEY ( FILE = '\\PrimaryReplica\TDE\PrimaryReplica_Cert_For_TDE_PrivKey.pvk'
                  ,ENCRYPTION BY PASSWORD = 'use_a_strong_password' );

/*
  Step 3: On Primary Replica - Creation of Database Encryption Key (DEK)
*/

USE YourDatabase;
GO
/*
 Create a Database Encryption Key
 Choose between AES_128 and AES_256
 Your are not going to encrytp it yet! 
*/

CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128 -- AES_256 
ENCRYPTION BY SERVER CERTIFICATE Cert_For_TDE;
/*
  Following stes must be executed on SECONDARY REPLICA
*/

-- Check if MASTER KEY is created
USE master;
GO
SELECT * FROM sys.symmetric_keys;
SELECT * FROM sys.certificates;

-- Create a Master Key IF NOT EXISTS
USE master;
GO
/*	
  Step 4: On Secondary Replica - Creation of the DMK
  Make sure that MASTER KEY Backup is working correctly.
  Review backup routine.  
*/

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'use_a_strong_password';
-- Backup the Master Key on secondary in order we have this when it turns into Primary and we need not worry when recovery event occurs.
-- Review backup routine! This is most important step to do

BACKUP MASTER KEY
TO FILE = '\\SecondaryReplica\TDE\SecondaryReplica_MasterKeyBackup.key' -- You can use same folder to store keys (I just change it to make things easy)
ENCRYPTION BY PASSWORD = 'use_a_strong_password';
/*
  Step 5: On Secondary Replica - Creation of the Certificate from the Primary Certificate Backup
*/

-- Create Certificate Protected by Master Key 
CREATE CERTIFICATE Cert_For_TDE
FROM FILE = '\\PrimaryReplica\TDE\PrimaryReplica_Cert_For_TDE_Backup.cer'
WITH PRIVATE KEY ( FILE = '\\PrimaryReplica\TDE\PrimaryReplica_Cert_For_TDE_PrivKey.pvk'
                  ,DECRYPTION BY PASSWORD = 'same_strong_password_for_backup' );

-- Backup the Certificate
-- Review backup routine! This is most important step to do
BACKUP CERTIFICATE Cert_For_TDE TO FILE = '\\SecondaryReplica\TDE\SecondaryReplica_Cert_For_TDE_Backup.cer' 
WITH PRIVATE KEY ( FILE = '\\SecondaryReplica\TDE\SecondaryReplica_Cert_For_TDE_PrivKey.pvk' 
                  ,ENCRYPTION BY PASSWORD = 'use_a_strong_password' );
/*
  Step 6: On Primary Replica – Enabling TDE Encryption
  Following stes must be executed on PRIMARY REPLICA
*/

-- Now you are going to encrypt it
ALTER DATABASE YourDatabase SET ENCRYPTION ON;
GO
/*
  Step 7: On the Primary Replica and Secondary Replicas – Monitoring Encryption
  This code must be run in SQLCMD mode
*/

:CONNECT PrimaryReplica
SELECT
  @@SERVERNAME
 ,db.name
 ,db.is_encrypted
 ,dm.encryption_state
 ,dm.percent_complete
 ,dm.key_algorithm
 ,dm.key_length
FROM master.sys.databases                                db
  LEFT OUTER JOIN master.sys.dm_database_encryption_keys dm
    ON db.database_id = dm.database_id;
GO

:CONNECT SecondaryReplica
SELECT
  @@SERVERNAME
 ,db.name
 ,db.is_encrypted
 ,dm.encryption_state
 ,dm.percent_complete
 ,dm.key_algorithm
 ,dm.key_length
FROM master.sys.databases                                db
  LEFT OUTER JOIN master.sys.dm_database_encryption_keys dm
    ON db.database_id = dm.database_id;
GO

Uma vez que você efetive o recurso ele será executado silenciosamente em segundo plano, criptografando o banco de dados enquanto as atividades continuam. Enquanto a criptografia inicial está em execução, podemos verificar a coluna percent_complete na sys.dm_database_encryption_keys para ver progresso (veja o step 7).

http://www.sqlservercentral.com/articles/always+on/135432/

Esse processo seria simples, se não fosse pelo grande volume de transações que eu tenho. Um sistema de telemetria que a todo instante está recebendo e enviando informações de veículos no mundo.

O CPU foi a quase 100% e gerou um performance ruim para o sistema. O que quero dizer é que processos que executavam em 500 milissegundos passaram a executar em 1200/1500 milissegundos.

Se você procurar na documentação só exista a opção de ON e OFF para ENCRYPTION. Uma vez que eu iniciei o processo para criptografar o database eu tenho que esperar terminar. E agora? Quanto tempo isso vai demorar para finalizar no meu database?

Existe uma trace flag documentada (Thanks God Microsft) que pausa o processo e simplesmente não faz rollback! Fantástico pois não perco o que foi criptografado e meu database fica com o status de “encryption in progress”. Ou seja, as páginas que foram criptografadas continuam assim e o as páginas que não foram criptografadas serão lidas normalmente.

https://blogs.msdn.microsoft.com/markweberblog/2017/04/04/transparent-data-encryption-tde-traceflag-5004-and-interrupting-encryption-scanning/

Como qualquer outra TF basta você ativar ou desativar. Para parar o processo ative a TF:

DBCC TRACEON(5004) 
GO

Para reiniciar o processo de onde parou basta desativar a TF e executar o comando novamente para criptografar o database.

DBCC TRACEOFF(5004) 
GO 

ALTER DATABASE YourDatabase SET ENCRYPTION ON;
GO

Isso salvou minha vida, pois eu pude habilitar o processo em horários de menor utilização e mesmo assim se impactasse o sistema eu seria capaz de parar.

Backup Compression

Um fator que notamos depois de habilitar o TDE foi a compressão de backups não estava funcionando corretamente, ou seja, simplesmente ignorava a opção e gerava um backup gigantesco.

Pesquisando um pouco achei uma excelente explicação para esse comportamento.

https://blogs.msdn.microsoft.com/sql_server_team/backup-compression-for-tde-enabled-databases-important-fixes-in-sql-2016-sp1-cu4-and-sql-2016-rtm-cu7/

Depois de entender melhor esse comportamento, foi a hora de verificar o que estava ocorrendo. Para isso utilizei um extended event (backup_restore_progress_trace) que facilita e muito a interpretar o que está acontencendo no momento do backup.

O Edvaldo Castro (blog/twitter) explica muito bem esse novo XE.

https://edvaldocastro.com/benchmarking-teste-do-novo-extended-event/

Você deve querer ver uma mensagem de MaxTransferSize maior de 64 KB:

https://blogs.msdn.microsoft.com/sql_server_team/new-extended-event-to-track-backup-and-restore-progress/#.VgtLzHpVhBd

Nesse momento fizemos duas ações:

1 – Atualizamos para o service pack e cumulative update mais recente visto que estávamos com a versão inferior descrita no link (https://blogs.msdn.microsoft.com/sql_server_team/backup-compression-for-tde-enabled-databases-important-fixes-in-sql-2016-sp1-cu4-and-sql-2016-rtm-cu7/)

2 – Mudamos nossa rotina de backup para se adequar as necessidades.

E o tempdb?

A partir do primeiro database utilizando TDE o tempdb passa ser criptografado automaticamente. Um curioso caso sobre o tempdb foi desvendado pelo Bob Ward, recomendo a leitura!

https://blogs.msdn.microsoft.com/bobsql/2017/01/26/sql-server-mysteries-the-case-of-tde-and-permanent-tempdb-encryption/

Eu tenho FileStream, vai criptografar?

A documentação é clara, dados em FileStream não são criptografados. Nossa solução foi utilizar BitLocker

https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server

Como ficou a CPU?

Nossos testes mostraram um leve aumento de CPU mas nada que comprometeu  a performance. Monitoramos alguns processos críticos e vimos que o aumento foi em média de 3-5% de CPU e tempo total de duração aumentou 100-150 milissegundos.

Transaction-Log? Hummmm

Eu não vi nenhum tipo de problema com isso. Espero que continue assim 🙂

Alguns recursos que não utilizamos e ainda não testei como Buffer Pool Extention – a documentação diz que não é criptogrado e assim como FileStream uma opção seria usar BitLocker. Quero verificar o quanto isso pode afetar a área de memória ou não.

Certificado expirado

O processo de substituir com segurança o certificado é chamado rotating the encryption key. É importante fazer isso, e o SQL Server torna isso um processo simples e rápido. A substituição dos seus certificados expirados é um processo rápido e simples, e é uma parte importante da manutenção da segurança da sua criptografia

Você também pode usar ou restaurar um certificado expirado no servidor.

https://blogs.msdn.microsoft.com/sqlsecurity/2010/06/14/database-encryption-key-dek-management/

Rotação de chaves

Rotation the encryption key é o processo de passar do certificado antigo para o novo. Nesse caso, tudo o que acontece é que a chave de criptografia do banco de dados é descriptografado com o certificado antigo e criptografado novamente com o novo certificado. Esse novo valor criptografado é armazenado no banco de dados sobrescrevendo o antigo. Por ser um processo rápido, a rotação frequente não é um problema.

Novo certificado

O primeiro passo é criar um novo certificado que será usado para criptografar o banco de dados. Você pode seguir os mesmos passos acima.

Rotação do certificado

Para substituir o certificado usado para TDE, adicione o novo certificado como acima, então execute o comando

USE YourDatabase
GO

ALTER DATABASE ENCRYPTION KEY
ENCRYPTION BY SERVER CERTIFICATE TDECert_Rotate_Key;
GO

Faça backup do novo certificado e do database.

Remover TDE

Para remover o TDE é necessário executar o comando abaixo.

ALTER DATABASE yourdatabase SET ENCRYPTION OFF;
GO

Aguarde até que o processo de descriptografia esteja concluído. Use o sys.dm_database_encryption_keys DMV para determinar seu status

USE YourDatabase
GO

DROP DATABASE ENCRYPTION KEY
GO

Faça backup do novo certificado e do database.

Para finalizar, aprenda que o TDE não é apenas um recurso que liga e desliga para entrar em conformidade com órgãos regulamentadores. Você deve se preparar e entender melhor esse recurso antes de utiliza-lo em seu ambiente de producao. Este foi um dos recursos que eu mais gostei de implementar pois me aprofundei em um assunto que eu mesmo tinha deixado de lado.

Fica uma pergunta! Quando falamos de data-in-rest o TDE é suficiente para deixar meus dados seguros ou precisamos fazer um backup com criptografia? Em um próximo post falarei como utilizar backup encryption

https://blogs.msdn.microsoft.com/sqlsecurity/2010/06/14/database-encryption-key-dek-management/

https://blogs.msdn.microsoft.com/sqlsecurity/2016/10/05/feature-spotlight-transparent-data-encryption-tde/

Categorias
Azure SQL Database Virtual PASS BR

Azure SQL Database – Vulnerability Assessment

[bing_translator]

O Vulnerability Assessment (VA) primeiramente introduzido no Azure SQL Database e depois entregue na versão do SQL Server Management Server (SSMS) 17.4 é um recurso que pode ajudar a descobrir, rastrear e corrigir potencias vulnerabilidades no seu database.

“To gain the benefits of a Vulnerability Assessment on your database, all you need to do is run a Scan, which will scan your database for vulnerabilities.”

Essa simples frase resume exatamente o que você deve fazer para utilizar esse recurso, nada além disso. Na minha visão o principal motivo para isso é a grande preocupação que a Microsoft está tendo em relação a segurança da informação. O Vulnerability Assessment é de fácil interpretação e principalmente é feito para não especialistas em segurança da informação assim como eu. Com esse recurso eu posso proteger melhor o meu ambiente porem isso pode não ser o suficiente caso a sua empresa tenha uma especialista em segurança e ele te direcione para qual caminho seguir.

Eu acredito que o recurso irá evoluir e iremos ganhar mais facilidades como por exemplo automatização de scan!

Hoje o Vulnerability Assessment faz parte do Advanced Threat Protection for Azure SQL Database.

A única configuração que você precisara fazer é escolher onde irá armazenar o resultado e nesse caso será uma “storage account”

Pronto! Agora basta executar o scan e aguardar pelo resultado.

Pude notar que as validações que estavam em preview foram modificadas na versão General availability (GA). O último preview, que eu utilizei, existiam 77 validações e agora só existem 48. Não sei o motivo porque algumas foram retiradas, mas espero que a lista aumente.

Para cada verificação existem detalhes que trazem informações complementares importantíssimas como por exemplo como remediar (resolver) o problema.

É possível criar uma baseline para cada database e assim você pode customizar o que é importante para seu ambiente. No relatório, o status da regra irá mostrar como aceito por baseline customizada.

Com o GA agora é exportar o resultado para Excel através do botão: Export Scan Results. Dessa maneira você pode ter um relatório offline e distribuir dentro da sua equipe ou até mesmo enviar para outras pessoas.

Com o Scan History é possível ver como estava as vulnerabilidades em cada scan. Isso facilita a auditoria e principalmente podemos ver o progresso das correções. Também é possível exportar para Excel qualquer histórico.

Eu espero que em breve possamos criar nossas próprias validações dando assim flexibilidade para cada cliente customizar com suas necessidades.

A versão do SSMS para on-premise tem as mesmas funcionalidades e é tão simples quanto a versão do Azure SQL Database.

https://www.mssqltips.com/sqlservertip/5297/sql-server-security-vulnerability-assessment-tool-in-ssms-174/

Jan Rokicki escreveu um excelente post falando sobre VA

https://www.datasic.com/post/ssms-va-assessment/

Referencias:

https://azure.microsoft.com/en-us/blog/introducing-sql-vulnerability-assessment-for-azure-sql-database-and-on-premises-sql-server/

https://blogs.technet.microsoft.com/dataplatforminsider/2017/12/11/whats-new-in-ssms-17-4-sql-vulnerability-assessment/

https://docs.microsoft.com/en-us/azure/sql-database/sql-vulnerability-assessment

https://docs.microsoft.com/en-us/sql/relational-databases/security/sql-vulnerability-assessment?view=sql-server-2017

https://docs.microsoft.com/en-us/azure/sql-database/sql-advanced-threat-protection

https://docs.microsoft.com/en-us/azure-advanced-threat-protection/what-is-atp

Categorias
Azure SQL Database Virtual PASS BR

GDPR – Principle of least privilege

[bing_translator]

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 🙂

 

Categorias
Azure SQL Database Virtual PASS BR

Azure SQL Database – Data Discovery & Classification

[bing_translator]

“SQL Data Discovery & Classification is currently at an early phase, and the eco-system around it is expected to grow as we continue releasing new capabilities”

Gostaria de começar esse post com a frase acima que peguei de um comentário no post que anunciou esse recurso!

Atualmente esse recurso está em preview, porém já podemos saber que é apenas o início de algo maior que esta por vir.

Aqui na Europa o GDPR está fazendo com que empresas se adaptem ao novo modelo e esse recurso pode ajudar com o primeiro passo!

Eu tenho utilizado outros métodos para classificar meus dados (ferramentas de mercado e até mesmo uma ferramenta desenvolvida internamente) e posso dizer que para a primeira versão desse recurso tem me agradado.

É possível se beneficiar desse recurso em qualquer service tier quando estiver utilizando o Azure SQL Database, ou seja, mesmo que você tem um database com pouca utilização você pode utilizar esse recurso.

Para usar Data Discovery & Classification é bastante simples:

  • Acesse seu database através do portal Azure
  • Navegue até Data Discovery & Classification (preview) e uma blade aparecera com um overview
    • Caso seja a primeira vez que você acessa esse recurso, verá os gráficos vazios

Depois que você classificar seus dados essa uma possível visualização dizendo como seus dados estão classificados ou “categorizados”.

Nesse momento existem dois tipos de distribuição:

  • Information type: para simplificar o entendimento seria o que está sendo armazenado nesse dado. É informação pessoal como ID, nome ou data de nascimento ou é um dado contendo informações bancarias como credencias de acesso ou cartão de credito.
  • Label: podemos dizer que é o nível de segurança que esses dados devem ser tratados. Por exemplo: Highly confidencial – GDPR seria o nível segurança elevado onde poucas pessoas deveriam ter acesso a essa informação ou Public seria nível segurança baixo onde todos podem acessar a informação.

Obs.: Isso é apenas uma classificação e não impõe nenhum tipo de restrição de acesso! Para restringir acesso ou ofuscar os dados existem outros recursos como Dinamic Data Masking e Row-level security.

Ao acessar a classificação pela primeira vez a Microsoft recomenda para você algumas colunas para classificar.

Isso realmente é um bom começo e com certeza ira te ajudar. Porem eu compartilho da opinião de algumas pessoas como Thomas LaRock que nesse post fala sobre esse recurso, onde existem limitações nessa versão – e é assim mesmo como foi anunciado que esse recurso está em constante mudança.

O algoritmo de classificação precisa ser melhorado em alguns aspectos:

  • Apenas funciona para nomes em inglês
  • Problemas com case-sensitive collations

O que me deixou satisfeito com o algoritmo foi que no meu caso mais de 75% das colunas sugeridas faziam total sentido!

Você pode aceitar as recomendações, edita-las, ou pode classificar manualmente outras colunas.

  1. Clique em Add classification
  2. Escolha o schema e a tabela
  3. Escolha a coluna
  4. Defina o “tipo de informação” o e “rótulo de sensibilidade”

Repita esse processo para cada coluna que você deseja classificar.

Uma vez que tenha terminado de classificar as colunas, você terá uma visão parecida com a primeira imagem e podendo agora exportar seu relatório para Excel que hoje é o único método possível.

Minha primeira tentativa resultou em uma visualização não agradável. Eu estava utilizando o Office 2013 e os gráficos não estão disponíveis (não funcionam). 

Depois de atualizar para o Office 2016 tudo funcionou normalmente.

Essa funcionalidade esta disponivel para on-premise a partir do SSMS 17.5!

Podemos esperar melhorias para o próximo semestre e deixo dois links de feedbacks sobre esse recurso

https://feedback.azure.com/forums/217321-sql-database/suggestions/33772411-scripting-capabilities-to-do-ms-sql-discovery-and

https://feedback.azure.com/forums/217321-sql-database/suggestions/33870379-data-discovery-and-classification-information-ty

Referência:

https://blogs.technet.microsoft.com/dataplatforminsider/2018/02/20/whats-new-in-ssms-17-5-data-discovery-and-classification/

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-data-discovery-and-classification

https://docs.microsoft.com/en-us/azure/security/how-to-discover-classify-personal-data-azure

 

Categorias
Virtual PASS BR

Como foi minha vinda para Portugal

Eu sempre tive vontade de sair do Brasil e estava muito inclinado a fazer isso. Nos últimos anos comecei a estudar algumas possibilidades de imigração, mas nada sem destino certo. Nunca tinha pensado em Portugal como uma opção, mas aconteceu que uma empresa, Farfetch, me encontrou no LinkedIn e me mandou uma proposta de entrevista. Nunca tinha ouvido falar dessa empresa então fui pesquisar e decidi aceitar fazer a entrevista.
Após duas entrevistas me enviaram a proposta de trabalho que de imediato eu recursei, motivo: salário baixo. Eu tinha solicitado um valor (2.5x) maior do que tinham feito a proposta e foi me dito que a realidade de Portugal era outra, eu não acreditei e ao pesquisar eu tive a primeira surpresa, Portugal tem um dos menores salários da Europa. Se não bastasse isso a cidade de Porto, para qual eu fui, o valor salarial é menor! Depois de negociar e melhorar um pouco (não cheguei ao valor inicial que eu queria) decidi aceitar a proposta por dois motivos, trabalhar e viver fora do Brasil. Sabia que iria ganhar menos, o custo de vida é baixo aqui, mas “teria uma qualidade de vida” melhor.
A Farfetch contratou uma empresa para me ajudar com o visto e com a realocação em Porto e foi aonde meus problemas começaram. Essa empresa fez um péssimo trabalho onde eu tive que deixar de lado o que eles falavam para documentação e seguir o que estava no site do consulado Português. Depois de 3 meses consegui tirar meu visto e vim para Porto onde começou o meu maior problema. Aluguei um quarto por uns dias (AirBNB) e comecei a procurar um apartamento com auxílio da empresa contratada, contudo tive dificuldades para encontrar um apartamento do meu gosto (não gosto de coisa antiga) pelo simples fato de que a empresa não estava ajudando pois existem apartamentos mais novos.

Vou deixar para explicar mais daqui a pouco.

Antes de começar a trabalhar você precisa de um documento chamado NIF (Número de Identificação Fiscal) e é possível fazer em um órgão do governo chamado FINCANÇAS que está praticamente em todos os principais bairros do Porto. Fui até esse órgão para solicitar o meu documento e agora meu problema ficou sério pois para conseguir esse documento existem duas maneiras:

  1. Representante legal – Alguma pessoa com documentação legal no país deve ser responsável por você. Eu vim sozinho, sem conhecer ninguém, não tinha ninguém que pudesse fazer isso para mim. Perguntei se a empresa, Farfetch, não poderia ser o representante e eles me informaram que não. Eu tinha que conseguir porque meus colegas brasileiros conseguiram.
  2. Com um contrato de morada – Aqui volto ao problema de encontrar um apartamento. Acabei encontrando alguns que eu gostei e na hora de tentar alugar começaram as perguntas
    1. Tem um fiador? Sou novo no país e não conheço ninguém
    2. Tem NIF? Preciso do contrato de morada para tirar o NIF.
      1. Se não tem, não podemos fazer o contrato.

Nesse momento já tinham se passado 3 semanas sem trabalhar e pagando AirBNB comecei a ficar muito puto. Entrei uma situação de bloqueio, pois, precisava do documento para trabalhar e alugar o apartamento e para alugar o apartamento precisava do documento. Depois de muito pesquisar, sem ajuda da empresa, achei um apartamento e fui na imobiliária verificar e informei a minha situação. Eles aceitaram fazer um contrato de morada se eu pagasse 6 meses de aluguel adiantado e depois de 90 dias pagasse os outros 6 meses. Como eu estava puto pois a empresa (Farfetch) não me ajudou com nada, resolvei aceitar e pude começar a trabalhar.
Farfetch é uma empresa num estilo moderno (Google, Facebook entre outras) usa tecnologia de ponta, mas acaba aqui o encantamento. Uma empresa que está buscando profissionais brasileiros mas não estava preparada (não sei como estão agora), desde o RH até os times técnicos. O ponto final para mim foi quando descobri que a Farfetch mentiu para mim em alguns aspectos:

  1. Passagem aérea: eles pagaram para alguns brasileiros, mas não me pagaram
  2. Hospedagem: eles pagaram para alguns brasileiros, mas não me pagaram
  3. Custo de vida na cidade do Porto, não é tão baixo quanto falaram comparado com o salario
  4. Bônus que prometeram na proposta foi removido 1 semana depois que cheguei
  5. Cargo especificado não foi o que me disseram
  6. Entre outras

Somando tudo isso e o salário baixo, depois de 2 meses eu decidi começar a procurar outro emprego e mudei meu LinkedIn para cidade de Porto e comecei a receber muitas solicitações de contato de pessoas de RH de empresas de Portugal e Europa. Demorou apenas 10 dias para encontrar um novo trabalho que me pagasse o que eu queria (difícil achar, mas achei) e não pensei duas vezes e decidi mudar. Nessa nova empresa eles me deram todo o auxílio e documentação necessária que eu precisava para trabalhar.
Essa foi minha trajetória nessa aventura de tentar a vida fora do Brasil e isso não significa que você passara pelas mesmas coisas.

Resumindo:

Portugal é um país onde se paga pouco (salário mínimo nao chega em €580) media salariam na área de TI €2000 para um sênior. Ou seja, você está disposto a ter uma qualidade de vida diferente do Brasil? Aceita a ganhar menos? Está realmente disposto a sair do Brasil? Aceite a proposta. Mas se você está em dúvida pense bem pois Portugal não é mil maravilhas.
O mercado de trabalho aqui está agitadíssimo, existem empregos para todas as áreas em diversas empresas porem o salário é baixo.

Moradia:

Levando em consideração que eu aluguei um apartamento para mim e não queria dividir com ninguém então eu pagava tudo sozinho. Valor fora do centro do Porto para apartamentos de 1 ou 2 quartos entre €300/€650 depende da região

Internet / TV / Celular

Planos de €30/€40 por 100MB de internet, TV e incluía telefone em casa com minutos
Planos de €15 para 4G com 3GB de internet. Existe a opção de incluir tudo em único plano porem a operadora de internet que tinha vibra no apartamento era diferente da minha operadora de celular.

Agua / Luz / Gás

A luz e gás em Portugal são muito caras. Eu sozinho gasto em média €40/€50 de luz e gás (mesma companhia) e mais €20/€30 de agua.

Mercado

Se você fizer uma compra para o mês comprando marcas do mercado (sim isso é muito comum aqui, ou seja, ao invés de comprar uma marca famosa, por exemplo: Nestle, você compra a marca do mercado, onde você pagaria €2 pela Nestle pode pagar €0,80 pela marca do mercado) irá gastar em média uns €150.

Agora é só fazer as contas e ver se está disposto a encarar. Para saber qual o seu salário final liquido pode usar esse site do governo: http://www.financaspessoais.pt/ordenados-e-pensoes/calculadora-do-salario-liquido-2017

Você está disposto a tudo isso? Pense bem e decida!
Espero poder ter ajudado, pois essa foi a minha experiencia e não significa que voce passara por tudo isso. Espero poder falar em breve como foi a minha vinda para Irlanda 🙂

Categorias
Azure SQL Database How To Virtual PASS BR

Azure SQL Database – Migration tools – part 3

[bing_translator]

Um outro metodo para migração de um database para o Azure SQL Database é através do uso de replicação. Não é o meu método favorito nem o tópico que eu mais gosto, na verdade eu evito o uso de replicação, porem esse tipo de migração pode ser útil em vários cenários.

Transactional Replication

Esse processo tem algumas particularidades como por exemplo:

  • Menor downtime
  • Perfeito para databases grandes
  • Suportado a partir do SQL Server 2012
  • Processo em múltiplos passos independentes
  • Requer chaves primarias em cada tabela presente no Publisher
  • Maior complexidade
  • Custos adicionais (setup distribution database, publisher e subscriber)
  • Exige mais conhecimento do DBA

Não esquece de validar se seu database está pronto para o Azure SQL Database através do Data Migration Assistant – Assessment

Configurar a replicação transacional para o Azure SQL Server não é nem um pouco diferente de configurar qualquer outro tipo de replicação para um servidor on-premise. Primeiro passo é criar um database vazio no Azure SQL Database pois é necessário que o database já exista para configurar a replicação.

Encontrei esse vídeo no channel9 explicando o passo a passo para utilizar a replicação transacional.
Para saber mais de como criar um Publisher utilizando replicação transacional acesse esse link.
Existem considerações que devemos ter e o time de suporte do Azure SQL Database descreve muito bem essas considerações nesse post.
O time do SQLCAT – SQL Server  Custumer Advisor Team também descreve como realizar esse procedimento nesse post.
Nesse outro link você pode ler sobre as restrições.

GO-NO-GO

Por ser um método que permite menor downtime existem alguns passos que devemos realizar:

  • Pare a aplicação e qualquer acesso que o database possa receber (Pacotes SSIS, integrações e etc.)
  • Monitore a replicação para que esteja completamente sincronizada
  • Reconfigure as connections strings (Aplicação, Pacotes SSIS, integrações e etc.)
  • Verifique se a aplicação está funcionando
  • Em caso de sucesso, exclua a replicação

 

Como eu disse, esse é um método extremamente complexo e trabalhoso, mas perfeitamente plausível para aplicações com downtime curtos.

Categorias
Azure SQL Database How To Virtual PASS BR

Azure SQL Database – Migration tools – part 2

[bing_translator]

Existem algumas ferramentas que ajudam a migrar seu database para o Azure SQL Database e eu já falei de algumas:

Export e Import manualmente

Mais uma vez o SQL Server Management Studio (SSMS) é a ferramenta que pode ser usada através do Export Data-tier Application.
Esse processo tem algumas diferenças quando comparado com o Migration Wizard

  • Suporta qualquer database a partir da versão SQL Server 2005
  • Excelente para database de tamanho pequeno, médio ou grande
  • .bacpad pode ser armazenado no Azure Storage ou localmente
  • Processo em múltiplos passos independentes
  • Maior controle sobre o export e import
  • Downtime é grande

Não esquece de validar se seu database está pronto para o Azure SQL Database através do Data Migration Assistant – Assessment

Para iniciar o seu processo de migração acesse o wizard através do SSMS.

Acesse Object Explorer –> Instance –> Database –> Botão direito –> Task –> Export Data-tier Application. Uma primeira janela de introdução será mostrada, avance para a próxima.

Nesse ponto você pode escolher entre salvar o .bacpac localmente ou no Azure Storage Account

  1.  Connect a sua storage account
  2. Indique o container onde o arquivo bacpac deverá ficar
  3. Nome do arquivo
  4. Um caminho local temporário deve ser indicado para que o processo tenha sucesso

Revise as informações, principalmente o espaço temporário disponível, e inicie a exportação do database. Através da janela de progresso podemos verificar o que o wizard está fazendo.

  1. Extrai o schema
  2. Valida o schema
  3. Exporta os dados (tabela por tabela)
  4. Upload do arquivo bacpac para o Azure Storage

Uma vez que o wizard terminou com sucesso não existe mais nada para fazer no SSMS e agora você tem o controle de quando e onde realizar o import. Acesse o Azure Portal e navegue até o seu servidor logico do SQL servers.

Acesse o item Overview e a opção Import database

 

 

  1. Indique sua subscription
  2. Local onde você fez o upload do arquivo bacpac

  1. Defina o service tier do database
  2. Escolha um nome para o database
  3. Collation que deseja utilizar
  4. Método de autenticação
  5. Login do administrador do servidor logico

 

 

 

 

Após revisar as informações e confirmar, o deploy deverá iniciar e uma notificação será apresentada no portal. Uma vez que sua requisição tenha sido completada seu database estará disponível para uso. Você pode verificar através do SSMS ou do Azure Portal.

O tempo total de deploy depende de alguns fatores como tamanho do seu database e service tier escolhido. Outra possibilidade é utilizar powershell para fazer o import do bacpac ao invés de usar o portal do Azure.

O código abaixo é um exemplo estático de como utilizar powershell.

#region connect to Azure
Login-AzureRmAccount
Get-AzureRmSubscription 
Select-AzureRmSubscription -SubscriptionName 'MSDN Platforms'

#list of commands 
Get-Command -Module AzureRM.Sql
#endregion

#region getting information and set variables

# Get the resource group name 
Get-AzureRmResourceGroup 
$resourcegroupname = "SQL-Database"

# Set an admin login and password for your server
$adminlogin = "admin"
$password = "yourpassword"

# Get server name - the logical server name has to be unique in the system
Get-AzureRmSqlServer -ResourceGroupName $resourcegroupname #| Select ServerName
$servername = "balabuchsqldb"

# The sample database name
$databasename = "AdventureWorks_Bacpac_PS"

# The storage account name and storage container name
Get-AzureRmStorageAccount -ResourceGroupName $resourcegroupname #| Select StorageAccountName
$storageaccountname = "sqldatabasemigration"

Get-AzureRmStorageAccount -ResourceGroupName $resourcegroupname | Get-AzureStorageContainer #| Select Name
$storagecontainername = "migration"

# BACPAC file name
Get-AzureRmStorageAccount -ResourceGroupName $resourcegroupname | Get-AzureStorageBlob -Container $storagecontainername #| Select Name
$bacpacfilename = "AdventureWorks.bacpac"

#endregion


#region importing bacpac

# Import bacpac to database with an S3 performance level
$importRequest = New-AzureRmSqlDatabaseImport -ResourceGroupName $resourcegroupname `
    -ServerName $servername `
    -DatabaseName $databasename `
    -AdministratorLogin $adminlogin `
    -AdministratorLoginPassword  (ConvertTo-SecureString -String $password -AsPlainText -Force)`
    -DatabaseMaxSizeBytes "5000000" `
    -StorageKeyType "StorageAccessKey" `
    -StorageKey (Get-AzureRmStorageAccountKey -ResourceGroupName $resourcegroupname -StorageAccountName $storageaccountname).Value[0] `
    -StorageUri "https://$storageaccountname.blob.core.windows.net/$storagecontainername/$bacpacfilename" `
    -Edition "Standard" `
    -ServiceObjectiveName "S3"


# Check import status and wait for the import to complete
$importStatus = Get-AzureRmSqlDatabaseImportExportStatus -OperationStatusLink $importRequest.OperationStatusLink
[Console]::Write("Importing")
while ($importStatus.Status -eq "InProgress")
{
    $importStatus = Get-AzureRmSqlDatabaseImportExportStatus -OperationStatusLink $importRequest.OperationStatusLink
    [Console]::Write(".")
    Start-Sleep -s 10
}
[Console]::WriteLine("")
$importStatus

#endregion

#region scale down database

# Scale down to Basic after import is completed
Set-AzureRmSqlDatabase -ResourceGroupName $resourcegroupname `
    -ServerName $servername `
    -DatabaseName $databasename  `
    -Edition "Basic" `
    -RequestedServiceObjectiveName "Basic"

#endregion

Referências:

https://docs.microsoft.com/en-us/azure/sql-database/scripts/sql-database-import-from-bacpac-powershell

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-import

Categorias
Azure SQL Database How To Virtual PASS BR

Azure SQL Database – Migration tools – part 1

[bing_translator]

Escolher a ferramenta de migração nem sempre é uma tarefa fácil uma vez que devemos levar em conta todos os pré-requisitos estabelecidos pelo cliente. Por esse motivo temos que conhecer os principais métodos/ferramentas de migração e suas diferenças para fornecer uma melhor solução e é necessário uma preparação antes de iniciar sua migração. No post Azure SQL Database – Before you migrate você pode encontrar o que deve ser considerado para ter uma migração de sucesso.

A primeira ferramenta que podemos utilizar é o Data Migration Assistant e você pode verificar como utilizar essa ferramenta aqui!

Migration Wizard no SSMS

O SQL Server Management Studio (SSMS) é a ferramenta que pode ser usada através do Migration Wizard e é o método mais comum para migração de um database.

Por ser um método bastante comum, algumas características dessa ferramenta:

  • Suporta database a partir da versão SQL Server 2005
  • Excelente para database de tamanho pequeno e médio
  • .bacpac é criado apenas localmente
  • É um processo único – ou toda a migração é realizada com sucesso ou nada é feito
  • Manipula o export e import automaticamente
  • Downtime é grande

Não esquece de validar se seu database está pronto para o Azure SQL Database através do Data Migration Assistant – Assessment

Para iniciar o seu processo de migração acesse o wizard através do SSMS.

Acesse: Object Explorer –> Instance –> Databases –> Botão direito –> Task –> Deploy Database to Microsoft Azure SQL Database.

Uma primeira janela de introdução será mostrada, avance para a próxima.

  1. Conecte no seu servidor Azure SQL (link)
  2. Escolha um nome para o seu database, originalmente o wizard mantem o mesmo nome.
  3. Configurações do seu Azure SQL Database
    1. Escolha o nível de serviço (service tiers): Basic, Standard, Premium ou PremiumRS (no momento apenas essas estão disponíveis)
    2. Tamanho máximo do database depende de cada nível de serviço.
    3. Service Objective: Dentro de cada service tier temos diferentes níveis de performance e limite de storage, as DTU
  4. Local de armazenamento do arquivo .bacpac

 

Revise as informações, principalmente o espaço temporário disponível, e inicie a migração.

Através da janela de progresso podemos verificar o que o wizard está fazendo e posso citar alguns passos:

  1. Extrai o schema
  2. Valida o schema
  3. Exporta os dados (tabela por tabela)
  4. Cria o database no Azure
  5. Verifica e analisa o deploy do novo database
  6. Inicia o processo de importação do pacote (schema e dados)
  7. Desabilita os índices
  8. Importa os dados (tabela por tabela)
  9. Habilita os índices

Uma vez que o wizard tenha completado a tarefa seu database estará disponível para uso. Você pode verificar através do SSMS ou do Azure Portal.

Algumas configurações que eu sento falta no wizard que e que por sua vez utiliza a opção default:

  • Location
  • Resource Group
  • Subscription

Apenas a configuração da região não é possível alterar depois que o database é criado.
O tempo total de deploy depende de alguns fatores como tamanho do seu database e service tier escolhido.

Concluindo, esse é o metodo mais utilizado e mais facil porem é demorado. Recomendo que teste esse metodos assim como marque o tempo total gasto e verifique se é aceitavel para sua migração. Duvidas do que fazer antes de migrar seu database? Não deixe de ler o post Azure SQL Database – Before you migrate

Referencia:
https://docs.microsoft.com/en-us/azure/sql-database/sql-database-migrate-your-sql-server-database

Pluralsight – Azure SQL Database for the SQL Server DBA

Categorias
Azure SQL Database Virtual PASS BR

Azure SQL Database – Before you migrate

[bing_translator]

A migração para o Azure SQL Database exige um grande preparo e testes devem ser feitos para que se tenha êxito no resulto final. Esse preparo se deve ao fato de que o Azure SQL Database é um serviço na nuvem e existem limitações ou a forma que você está acostumado a utilizar um recurso muda.

Para se ter sucesso nessa migração devemos levar em conta alguns fatores:

  • Identificar os benefícios: Temos que identificar todos os benefícios e melhorias que iremos tirar proveito. Enumerar um por um e criar um roadmap para implementação de cada um deles é sempre uma boa estratégia. Nunca migre para a nuvem apenas para ser “fancy”.
  • Identificar bloqueios: O Data Migration Assistant ajuda nesse requisito. Identificar cada um deles e criar uma lista com prioridades de cada item auxiliará o processo de migração, porem existem bloqueios que impedem a migração como por exemplo SQL CLR que nesse momento ainda não é suportado.

 

  • Identificar o modelo de serviço: Se você pretende migrar um único database então Single Mode é perfeito para sua solução porem se pretende migrar mais de um database Elastic Pool deve ser avaliado.
  • Identificar o nível de serviço (service tier): Nesse ponto você irá verificar a capacidade de CPU/IO/Storage entre outros requisitos que seu database pode utilizar e lembre que quanto maior a capacidade maior será o valor pago pelo serviço.

 

 

  • Identificar Azure Region: Muitas pessoas esquecem de verificar qual a melhor região do Azure Datacenter para alocar seu database e principalmente qual a melhor região para alocar seu disaster recovey.
    Cada região tem serviços disponibilizados individualmente que outras regiões podem não contem e para saber melhor sobre o que cada região disponibiliza acesse o link.
  • Identificar a melhor ferramenta de migração: Existem algumas ferramentas que podemos utilizar para migrar um database e identificar qual é a melhor para o seu cenário pode ajudar a ter sucesso.

Algumas ferramentas de migração:

Obs.: Irei escrever sobre cada uma delas.

Cada uma delas tem suas particularidades e seus benefícios, entretanto a escolha da ferramenta é apenas mais uma etapa para ter sucesso na migração. Posso citar outros fatores como:

  • SLA – Garantir que o Service Level Agreement seja cumprido é um fato chave para o negócio e a escolha da ferramenta de migração vem de encontro com esse critério uma vez que podemos ter um downtime curto ou longo e cada uma das ferramentas proporciona um tempo necessário para completar a migração.
  • Aplicação – Garantir que sua aplicação não tem incompatibilidades, erros ou problemas com o Azure SQL Database é fundamental e isso é um fator que não podemos controlar pois dependemos dos desenvolvedores ou fornecedores.
  • Performance – Os usuários finais sempre esperam que a aplicação continue com a performance atual ou que tenham uma experiencia melhor na performance depois da migração. Nesse critério o nível de serviço escolhido é um grande potenciador ou impedidor de performance. Outro fator que deve ser revisto são as queries que consomem mais recursos e começar um trabalho otimizar seu código.
  • Documentação – Documentar cada etapa da migração é fundamental para o sucesso pois dessa forma você terá controle do que está acontecendo e principalmente estime o tempo gasto em cada etapa.
  • Testes – Antes de migrar seu database para o ambiente de produção realize testes de migração para um ambiente de teste onde você é capaz de documentar cada etapa, marcar o tempo gasto em cada etapa e verificar se a aplicação está funcionando com a performance aceitável e sem erros. Repita esse passo quantas vezes achar necessário para não ter surpresas no momento da migração para produção.

Para concluir eu acredito que o preparo é a chave fundamental para obter sucesso na migração para o Azure SQL Database. Estude, crie laboratórios, faça testes, simule erros para todas as alternativas e principalmente esteja confiante  em você mesmo!

Referencia:

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-migrate-your-sql-server-database

Pluralsight – Azure SQL Database for the SQL Server DBA