Categorias
Azure SQL Database How To Troubleshooting

Azure SQL Database – Transparent Data Encryption with bring your own key

[bing_translator]

Transparent Data Encryption (TDE) vem por padrão habilitado quando você cria um novo database no Azure SQL Database.  

TDE não é mais uma novidade porem eu tenho visto que é pouco explorada (minha percepção). Se predente usar TDE on-premise vale a pena a leitura no post anterior. 

Habilitar ou desabilitar TDE no Azure SQL Database é simplesmente um click para ON ou OFF e a Microsoft faz tudo para você! Simples né, porem algumas perguntas vinham em relação a esse gerenciamento, por exemplo, como é realizado o gerenciamento de chaves ou porque apenas certificado poderiam ser usados.   

Com isso em mente a Microsoft disponibilizou uma nova opção: Bring Your Own Key. Com certeza isso faz muita diferença uma vez que posso ter o controle maior sobre as minhas chaves e posso aplicar a política definida pela minha empresa. Sendo assim agora eu posso estar cumprindo as conformidades de órgãos regulamentadores com mais transparência.  

https://azure.microsoft.com/en-us/blog/transparent-data-encryption-with-customer-managed-keys-in-azure-sql-database-generally-available/

Bring Your Own Key 

A minha primeira tentativa foi utilizar o Azure Portal para criar todos os passos necessários desde a criação de um novo servidor, key vault e key. 

Key Vault 

Na blade para criar o key vault começaram meus problemas.  

Ao tentar adicionar um acesso para o meu “logical server” eu não pude encontra-lo. Mas a pergunta era, porque não?! 

Voltei a ler a documentação e tentei entender melhor como TDE suporta BYOK. 

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption-byok-azure-sql?view=azuresqldb-current 

O servidor logico precisa gerar e assinar uma identidade no Azure Active Directory, mas o Azure Portal não me dá essa opção quando estou criando o servidor.  

Não tem problema, vamos para o PowerShell. 

Set-AzureRmSqlServer `
-ResourceGroupName TDE `
-ServerName tdebalabuch `
-AssignIdentity

Eu não precisei apagar e criar novamente o servidor. 

Depois de executar o comando voltei ao Azure Portal e agora o meu servidor estava disponível para adicionar acesso.

Adicionei as permissões necessárias: GET, WRAP e UNWRAP.

Key 

Agora que a key vault está criado falta apenas a key.

3 importantes atributos que a Key deve ter: 

  • No expiration date 
  • Not disabled 
  • Permissão de get, wrap key, unwrap key  

Habilitar TDE com BYOK 

Agora seria a hora de apertar o botão salvar e tudo funcionar perfeito. Seria, mas não foi! 

Recebi o erro:  

Failed to save Transparent Data Encryption settings for server: {serverName}. Error message: The provided Key Vault uri ‘https://keyvaulttde.vault.azure.net/keys/KeyForTDE/633a6b1fad6941cb96449599df0382c0’ is not valid. Please ensure the vault has the right Recovery Level other than ‘Purgeable’. 

Ok. Fiz algo de erro, vou refazer tudo e vai dar certo! #sqn 

Boa notícia, refiz algumas vezes e pude perceber o que mesmo sem atribuir uma identidade para o servidor quando clico em salvar a etapa de atribuir uma identidade e conceder as permissões o Azure Portal está fazendo 🙂 

Mas ainda falta algo que ele não faz. Então nesse momento apenas é possível utilizar PowerShell e CLI.  

Quebrando os passos 

Aqui eu comecei a quebrar os passos da criação de todos os recursos envolvidos. 

Lendo a documentação novamente me deparo com essa informação 

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption-byok-azure-sql?view=azuresqldb-current 

Depois de ler mais documentação percebi que essa funcionalidade era o que estava me causando problema.  

https://docs.microsoft.com/en-us/azure/key-vault/key-vault-ovw-soft-delete 

https://docs.microsoft.com/en-us/azure/key-vault/key-vault-soft-delete-powershell 

Eu tive que executar um comando em PowerShell:

($resource = Get-AzureRmResource -ResourceId (Get-AzureRmKeyVault -VaultName "KeyVaultTDE").ResourceId).Properties | Add-Member -MemberType "NoteProperty" -Name "enableSoftDelete" -Value "true" 

Set-AzureRmResource -resourceid $resource.ResourceId -Properties $resource.Properties  

Get-AzureRmKeyVault -VaultName "KeyVaultTDE"

Voltei ao Azure Portal e pude finalizar o processo. 

Investigando um pouco mais, quando entrei na Key Vault me apareceu a seguinte mensagem! 

OK! Meu entendimento é que Soft Delete ainda está em “Preview” e minha pergunta é: Porque a Microsoft liberou um recurso (TDE com BYOK) que depende de outro recurso que ainda está em “Preview”? 

Enquanto o Azure Portal não tem todas as opções disponíveis o melhor jeito é utilizar o PowerShell.  

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption-byok-azure-sql 

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption-byok-azure-sql-configure

https://azure.microsoft.com/en-us/blog/transparent-data-encryption-with-customer-managed-keys-in-azure-sql-database-generally-available/ 

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption-azure-sql 

https://azure.microsoft.com/en-us/blog/preview-sql-transparent-data-encryption-tde-with-bring-your-own-key-support/ 

 

Categorias
Azure SQL Database How To

GDPR – como eu me preparei

[bing_translator]

“The General Data Protection Regulation (GDPR) will come into force on the 25th May 2018, replacing the existing data protection framework under the EU Data Protection Directive”

“The aim of the GDPR is to protect all EU citizens from privacy and data breaches in an increasingly data-driven world that is vastly different from the time in which the 1995 directive was established”

Nos últimos meses estive envolvido em muitas mudanças nas aplicações que temos por conta dessa nova regulamentação que esta entrando em vigor na Europa. Muitas empresas como Facebook, Google, Microsft e Amazon (apenas para citar algumas) também estão se adequando ao GDPR e desde o inicio do ano eu venho recebendo avisos de como eles tem mudado suas policas de segurança/privacidade.

Na minha opinião essa mudança é importante para nós usuários dessas grandes corporações e a intenção é ter mais controle sobre nossos dados pessoais.

Mas o que isso afeta o meu trabalho e o meu dia a dia? Não são apenas as empresas globais (gigantes da internet) que devem se adequar, mas sim qualquer empresa dentro da união europeia deve seguir essa regulamentacao e por isso o meu trabalho é afetado. Se você pensa que por não morar/trabalhar na Europa você não deve seguir o GDRP acredito que não é bem assim, pois em algum momento sua empresa pode fazer operações na Europa e você terá que se adequar, ou ate mesmo, quanto tempo você acha que essa regulamentacao ou alguma outra sera aplicada onde voce está? Pense bem.

O meu intuito aqui não é falar sobre o que o GDPR é ou para que ele se propõe. Para isso deixarei links onde você pode entender melhor.

Eu irei mostrar como eu utilizei ferramentas e recursos nativos do SQL Server para fazer que meu ambiente esteja de acordo com a regulamentação. E para cada item farei um post sobre como implementei e minhas impressões, por isso esse post será atualizado sempre que necessário.

A maioria dos posts terá o foco no Azure SQL Database.

Primeiramente temos que conhecer melhor nossos dados, saber o que eles representam e principalmente qual a sua valia para a empresa.

Garantir o princípio do menor privilegio foi a fase do meu projeto que mais demorou, uma vez que temos que entender quem acessa a informação, para qual finalidade e porque eles acessam.

Para ajudar a proteger seus dados, o firewall impede todo o acesso ao seu servidor de banco de dados até que você especifique quais computadores têm permissão.

  • Authentication in Azure SQL Database using Azure Active Directory

Com a autenticação do Azure AD, você pode gerenciar centralmente as identidades dos usuários do banco de dados e de outros serviços da Microsoft em um local central.

É o processo de identificar, quantificar e priorizar (ou classificar) as vulnerabilidades.

Conhecido como criptografia de dados em repouso (data at rest) e executa criptografia e descriptografia de I/O em tempo real dos dados e arquivos de log.

Transparent Data Encryption and its tricks

Limita a exposição a dados confidenciais mascarando para usuários sem privilégios. O DDM ajuda a impedir o acesso não autorizado a dados confidenciais.

  • Row-Level Security

Permite que os clientes controlem o acesso a linhas em uma tabela de banco de dados com base nas características do usuário que está executando uma consulta, em outras palavras, o RLS permite implementar restrições no acesso ao registro de dados.

  • Group Managed Service Accounts

Fornece um gerenciamento automático de senhas e de SPN, incluindo delegação de gerenciamento a outros administradores.

  • Always Encrypted

É um recurso projetado para proteger dados confidenciais, como números de cartão de crédito ou números de identificação nacional. Permite que os clientes criptografem dados confidenciais em seus aplicativos e nunca revelem as chaves de criptografia ao banco de dados.

  • Business continuity in Azure SQL technologies
    • Point-time Restore
    • Backup Long-term retention
    • Active Geo-replication
  • Auditing & Threat Detection

Pode ajudar a compreender a atividade do banco de dados e obter insights sobre discrepâncias e anomalias que possam indicar preocupações comerciais ou suspeitas de violações de segurança.

  • SQL Server Audit

Permite criar auditorias que podem conter eventos no nível do servidor e no nível do banco de dados.

  • Temporal table

Fornece informações sobre os dados armazenados na tabela em qualquer momento, em vez de apenas os dados corretos no momento atual.

  • Azure SQL Analytics

Coleta e visualiza métricas importantes de desempenho do Azure SQL Database.

 

Todos os passos que eu segui foi baseado no guia da Microsoft referente ao GDPR.

https://docs.microsoft.com/en-us/sql/relational-databases/security/microsoft-sql-and-the-gdpr-requirements

References:

https://www.eugdpr.org/the-regulation.html

https://www.dataprotection.ie/docs/GDPR/1623.htm

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 How To SQL Server Virtual PASS BR

Data Migration Assistant – Migration

[bing_translator]

A ferramenta DMA v3.3 nesse momento tem duas opções de projetos: Assessment e Migration.
No post anterior Data Migration Assistant – Assessment falei um pouco sobre a funcionalidade de Assessment para assessorar e minimizar o impacto da migração de databases. Esse é o primeiro passo que você deve tomar para realizar uma migração e após verificar todos os itens dos relatórios você está “pronto” para iniciar a migração, pelo menos por parte do database não esqueça de verificar se a aplicação está preparada para a migração.

Ao iniciar a ferramenta DMA crie um projeto do tipo Migration onde iremos definir qual tipo de servidor de origem e destino.

Nesse momento temos que indicar qual o escopo da migração, que pode ser:

  • Schema and data
  • Schema only
  • Data only

A partir dessas opções podemos criar vários cenários para migração de um database como por exemplo:

  • Criar um servidor de teste e um database apenas com os metadados (schema); realizar o apontamento da aplicação para esse servidor fazendo assim um teste também com a aplicação.
  • Se precisar de poucos dados, aquelas famosas tabelas de configurações, você pode importar apenas o que precisa.

Desse ponto de vista temos uma flexibilidade enorme para trabalhar e eu escolhi o escopo: Schema and data para demonstrar do início ao fim o processo.

De forma simples o wizard irá te ajudar e nesse processo teremos 6 etapas sendo a primeira escolher a instancia e database de origem.

Uma tarefa que o wizard não faz é criar o database no Azure e por isso você deve criar um database vazio através do portal, powershell ou CLI antes de continuar. Basta seguir os passos desse link.

Eu criei um database chamado AdventureWorksDMA através do portal e o próximo passo é escolher quais objetos serão migrados.

Uma vez que tenha escolhido os objetos que serão migrados o passo a seguir é gerar os scripts desses objetos.

Aqui você tem a opção de salvar o script para analisar posteriormente, copiar para qualquer editor de texto ou realizar o deploy diretamente através do DMA que irá fazer o deploy para o Azure SQL Database.

Uma janela com informações dos resultados irá mostrar o progresso do deploy e os comandos executados. Ao finalizar existe a opção de redeploy ou iniciar a migração dos dados e como nosso objetivo é ter uma migração completa vamos seguir com a migração dos dados.

Selecione as tabelas desejadas ou todas e inicie o seu processo de migração.

O tempo que a migração depende de alguns fatores dentre eles posso citar: quantidade de tabelas e registros em cada uma delas e a performance do seu Azure SQL Database (DTU), no meu caso utilizei S0 (10 DTU).

Uma vez que a migração dos dados terminou com sucesso você pode se conectar no Azure SQL database através do SSMS (Azure SQL Database – SQL Authentication) para verificar que sua migração está finalizada com sucesso.

Categorias
Azure SQL Database How To SQL Server Virtual PASS BR

Data Migration Assistant – Assessment

[bing_translator]

Migração de um database é uma rotina comum na vida de um DBA e essa atividade pode ser para uma versão mais atual do SQL Server ou para o Azure SQL Database. A Microsoft sempre tentou auxiliar essas migrações com ferramentas como por exemplo o Upgrade Advisor. Por muito tempo utilizei essa ferramenta para as migrações que realizei pois ela gerava um relatório com todos os possíveis “problemas” que poderia ter.

Recentemente precisei migrar um database on-premise para cloud e ao verificar a versão mais atual do Upgrade Advisor descobri que a Microsoft decidiu descontinuar essa ferramenta. Você ainda pode baixar a ferramenta atrás desse link porem eu aconselho a utilizar a nova ferramenta o Data Migration Assistant (DMA). Essa ferramenta trouxe novas capacidades e facilidades onde uma delas é centralizar na mesma ferramenta as opções de realizar a migração ou apenas realizar a validação do database para uma futura migração.

É sobre essa nova ferramenta DMA que irei falar um pouco hoje.

Após fazer o download através do link acima e instalar a ferramenta, você pode notar na tela iniciar uma facilidade que é a criação de projetos. Estou utilizando a versao 3.3

Nesse momento existem dois tipos de projetos:

  • Assessment
  • Migration

O Assessment é a funcionalidade que iremos utilizar para verificar os possíveis problemas e incompatibilidades que temos ao migrar um database.

Depois de dar um nome ao seu projeto você deve escolher o tipo de servidor de origem que no meu caso só tenho a opção de SQL Server.

Nesse momento você deve selecionar qual o seu objetivo final, ou seja, qual o tipo de servidor que o seu database será hospedado. No meu caso 3 opções são apresentadas: Azure SQL Database, SQL Server e SQL Server on Azure Virtual Machines.

Como tenho trabalho com Azure SQL Databases vou utilizar essa opção para demonstração.

Agora que você escolheu as opções e criou o projeto uma nova janela irá apresentar quais os tipos de relatórios você gostaria de gerar.

Nesse momento é possível optar por gerar relatórios separados, o que pode ser útil quando existe uma lista grande de itens que estão sendo tratados aos poucos e você pode medir quanto esforço foi realizado ou falta a ser feito.

  • Check database compatilibity – verificará problemas que podem ser bloqueadores para a migração assim como features descontinuadas.
  • Check feature parity – verificará por features que não são suportadas ou são parcialmente suportadas.

Um terceiro tipo de relatório está por vim e parece ser bem interessante uma vez que ele informará quais são as possíveis features que podem ser utilizadas no seu database uma vez que você realizar a migração e isso é um benefício que pode ser traduzido em performance, tamanho, segurança entre outros (essa é a minha opinião sobre o que esperar desse relatório)

Próximo passo é escolher a instancia SQL Server e o(s) database(s) que fará parte do projeto de migração.

 

Uma lista com os databases selecionados será apresentada e você pode adicionar ou remover servidores de origem dentro do seu projeto, ou seja, pense que uma aplicação tem mais de um database em mais de uma instancia e com isso é possível criar um projeto com múltiplas instancias SQL Server e múltiplos databases.

Após iniciar o Assessment e a ferramenta terminar de analisar, você terá seus relatórios prontos e sua análise desses é extremamente fácil uma vez que está divido em seções.

Relatório: SQL Server features parity

  1. Recomendações e informações sobre features
  2. Detalhes sobre uma das recomendações selecionadas.
  3. Nível de aplicabilidade da recomendação. (Não se aplica a todas as recomendações)

Relatório: Compatility issues

  1. Issue (problema) agrupado por categorias
  2. Detalhes sobre o issue
  3. Objetos dentro database que são impactados pelo issue.

Dessa forma fica fácil visualizar o que devemos fazer para corrigir cada um dos issues antes de migrar o database.

No campo superior direito existem duas opções: Restart Assessment e Delete Assessment. Uma forma rápida para regerar o relatório ou excluir!

Para concluir é possível exportar o relatório para dois formatos: CSV e JSON. Particularmente o formato CSV não me agradou e o JSON é a nova onda do momento de transferia de dados de forma leve!

Categorias
Azure SQL Database How To SQL Server Virtual PASS BR

Data Files no Azure – Uma outra forma de criar um database

[bing_translator]

Você já deve ter criado inúmeros databases dentro do seu ambiente on-premise ou em uma VM no Microsoft Azure utilizando IaaS e isso deve ser algo trivial para você.
Comece a pensar em uma outra forma de criar o seu database fazendo um mix entre on-premise ou VM e o Microsoft Azure Storage, é isso mesmo, você ter os dados armazenados na cloud e continuar usando seus recursos locais (memoria, CPU, Network e etc.)

Aquele velho dilema com o administrador de storage quando o DBA precisa de mais espaço pode ser minimizado com essa nova forma de criar um database.
O que seria essa forma? Isso seria armazenar seus Data Files no Microsoft Azure Blobs o que permite várias soluções híbridas, fornecendo vários benefícios para a virtualização de dados, movimento de dados, segurança e disponibilidade.

Alguns benefícios que podemos ter:

  • Migração simples e rápidos
  • Custo e armazenamento ilimitados
  • Alta disponibilidade e recuperação de desastres
  • Segurança
  • Snapshot backup

Vamos ver como isso funciona!

O que iremos precisar é de uma Storage Account:

Duas configurações são importantes: Account kind e Replication. Até nesse momento alguns tipos de replicação não suportam data files do SQL Server.
Sua storage account pode conter alguns tipos de serviços e nós iremos utilizar o BLOBs.

Acesse o serviço de Blobs e crie um novo container e acesse suas propriedades para pegar a URL. Copie a URL para o seus SSMS pois irá precisar dela em breve.

Volte a blade da sua storage account e acesse Shared Access Signature. Clique em Generate SAS para obter o token de acesso e copie o SAS token para seu SSMS.

Observe que o primeiro caractere é um ponto de interrogação “?” e deve ser removido!!!
Nesse momento já temos tudo o que precisamos do lado do Microsoft Azure e podemos criar a credencial necessária para acesso.

Para criar as credencias utilize o T-SQL abaixo

CREATE CREDENTIAL [https://sqlgeneral.blob.core.windows.net/database] 
WITH IDENTITY = N'Shared Access Signature',  --- NÃO MUDE. ISSO É MANDATORIO
SECRET = N'sv=2017-04-17&ss=bfqt&srt=sco&sp=rwdlacup&se=2017-08-23T22:14:51Z&st=2017-08-22T14:14:51Z&spr=https&sig=k1kHJoJKFKPxAJu'
GO

Nome da credencial deve ser a URL do seu container. Em SECRET insira o SAS token sem o primeiro caractere “?”

Com a credencial criada você pode criar seu database

CREATE DATABASE [FirstDB]
 CONTAINMENT = NONE
 ON  PRIMARY
( NAME = N'FirstDB', FILENAME = 'https://sqlgeneral.blob.core.windows.net/database/FirstDB.mdf' , SIZE = 8192KB , FILEGROWTH = 65536KB )
 LOG ON
( NAME = N'FirstDB_LOG', FILENAME = 'https://sqlgeneral.blob.core.windows.net/database/FirstDB_log.ldf' , SIZE = 8192KB , FILEGROWTH = 65536KB )
GO

A única diferença é que você deve apontar seus data files para a URL e não mais para um disco local.
Uma nova coluna (credential_id) na DMV sys.master_databases foi introduzida no SQL Server 2014 para fazer essa referência.

Você também pode verificar os arquivos através do portal do Azure acessando o container que criou:

https://docs.microsoft.com/en-us/sql/relational-databases/databases/sql-server-data-files-in-microsoft-azure

https://docs.microsoft.com/en-us/azure/storage/common/storage-introduction

Categorias
Azure SQL Database How To SQL Server Virtual PASS BR

Azure SQL Database – Dynamic Data Masking

[bing_translator]

O Azure SQL Database estende a funcionalidade de Dynamic Data Masking (DDM) que foi introduzido no SQL Server 2016.
A intenção desse post é ter um overview sobre o que o DDM e mostrar como utilizar essa funcionalidade no Azure SQL Database

O que é o DDM

Ofuscar dados em tempo real para impedir o acesso não autorizado
Os dados armazenados em disco não são criptografados ou alterados
Útil para ocultar dados sensíveis e confidenciais, como números de identificação pessoal, números de cartão de crédito, data de nascimento e assim por diante.

Como o DDM funciona

Ofuscamento sobre os dados nos resultados da consulta
As regras podem ser definidas em colunas particulares
Não há mudanças físicas (storage)
Os dados permanecem intactos e estão totalmente disponíveis para usuários / aplicativos autorizados.
Os dados em máscaras têm o mesmo tipo de dados que os dados originais
Múltiplas funções de máscara disponíveis para várias categorias de dados sensíveis
Flexibilidade para definir um conjunto de logins privilegiados para acesso de dados não mascarados
Por padrão, db_owner do banco de dados tem acesso aos dados sem máscara.
Pode ser aplicado sem fazer alterações nos procedimentos do banco de dados ou no código da aplicação.

Existem 5 tipos de máscaras disponíveis (espere que tem uma surpresa)

  • Default ou Full masking
  • Email
  • Custom String ou Partial masking
  • Random
  • Credit card – Até o momento somente disponível do Azure SQL Database
Função Antes da Máscara Depois da Máscara
Default () –  O valor é completamente ofuscado.

Number: 487

Text: Tiago

(FUNCTION = ‘default()’)

Number: 000

Text: XXX

Email() – Ofusca quase tudo menos a primeira letra, @ e sufixo tiago@email.com

(FUNCTION = ‘email()’)

tXX@XXXXX.com

Partial() – Personalizada em que você determina o quanto será mostrado 912-564-897

(FUNCTION = ‘partial(1,”XXXXXXX”,0)’)

9XXXXXXXXX

(FUNCTION = ‘partial(3,”XXXXXXX”,0)’)

912XXXXXXX

Random() – Usado com tipos de dados numéricos. Ofusca os dados com um valor aleatório em um determinado intervalo 487

(FUNCTION = ‘random(1,1000)’)

198, ou 633, ou 1000

Credit card – expõe os últimos quatro dígitos e adiciona uma sequência constante como um prefixo na forma de um cartão de crédito 1234-5678-9876-1234 XXXX-XXXX-XXXX-1234

Usando o portal do Azure

Para utilizar essa funcionalidade acesse seu database através do portal e procure a opção Dynamic Data Masking. Uma vez que você acessar o próprio Azure irá te sugerir tabelas e colunas.

Um simples clique em ADD MASK você terá criado a máscara para aquela coluna e uma lista com todas as mascaras irá aparecer

O Azure SQL Database tenta identificar a tipo de dados e sugere um tipo de máscara (muitas vezes acerta outras nem tanto) porém é possível mudar o tipo de máscara clicando sobre o nome do mascara uma nova blade irá abrir.  Escolha a nova máscara que melhor se aplique para o tipo de dados da coluna e atualize a máscara. Da mesma forma é possível apagar a máscara que foi criada apenas clicando no botão DELETE.

Assim você pode rever todas as colunas que deseja e é possível mudar isso de forma simples e rápido. Quando tiver pronto salve as alterações.

Uma forma de verificar as colunas e as máscaras é consultar uma DMV nova – sys.masked_columns.

E agora com PowerShell?

Tudo se torna fácil para automatizar com PS e uma surpresa (na opinião boa) apareceu quando estava criando os comandos. Um outro tipo de máscara “SocialSecureNumber” está disponível e até o momento não é possível utilizar pelo portal (o que eu posso concluir que existem outros comandos com esse mesmo comportamento e que existe muito trabalho para o time de desenvolvimento do portal)

Porém uma vez que você criou a máscara por PS a informação fica disponível para visualização com o tipo de máscara correto!

Aqui esta a lista de comandos PS:

#region connect to Azure

Login-AzureRmAccount
Get-AzureRmSubscription 
Select-AzureRmSubscription -SubscriptionName 'MSDN Platforms'

#endregion disk caching

#list of commands 
Get-Command -Module AzureRM.Sql -Noun *masking*

#region get all masking rule in all databases or masking policy

$ResoureGroup = Get-AzureRmResourceGroup | where {$_.ResourceGroupName -contains “SQL-Database”} #or $ResoureGroup = “SQL-Database”
$ServerName = Get-AzureRmSqlServer -ResourceGroupName $ResoureGroup.ResourceGroupName
$Databases = Get-AzureRmSqlDatabase -ResourceGroupName $ResoureGroup.ResourceGroupName -ServerName $ServerName.ServerName | where {$_.CurrentServiceObjectiveName -ne “System0”} 

foreach ($db in $Databases)
{
    Get-AzureRmSqlDatabaseDataMaskingRule -ResourceGroupName $ResoureGroup.ResourceGroupName -ServerName $ServerName.ServerName -DatabaseName $db.DatabaseName | Format-Table
   # Get-AzureRmSqlDatabaseDataMaskingPolicy -ResourceGroupName $ResoureGroup.ResourceGroupName -ServerName $ServerName.ServerName -DatabaseName $db.DatabaseName | Format-Table
}

#endregion

#region add new masking rule

New-AzureRmSqlDatabaseDataMaskingRule -MaskingFunction SocialSecurityNumber -SchemaName "HumanResources" -TableName "Employee" -ColumnName "NationalIDNumber" -DatabaseName "AzureAdventureWorks" -ServerName $ServerName.ServerName -ResourceGroupName $ResoureGroup.ResourceGroupName

#endregion

#region remove new masking rule

Remove-AzureRmSqlDatabaseDataMaskingRule -SchemaName "HumanResources" -TableName "Employee" -ColumnName "NationalIDNumber" -DatabaseName "AzureAdventureWorks" -ServerName $ServerName.ServerName -ResourceGroupName $ResoureGroup.ResourceGroupName

#endregion

#region update a masking rule

Set-AzureRmSqlDatabaseDataMaskingRule -MaskingFunction Text -PrefixSize 1 -SuffixSize 5 -ReplacementString "XDXDXDXD" -SchemaName "Person" -TableName "PersonPhone" -ColumnName "PhoneNumber" -DatabaseName "AzureAdventureWorks" -ServerName $ServerName.ServerName -ResourceGroupName $ResoureGroup.ResourceGroupName
#endregion

#region update a masking policy

Set-AzureRmSqlDatabaseDataMaskingPolicy -DataMaskingState Enabled -DatabaseName "AzureAdventureWorks" -ServerName $ServerName.ServerName -ResourceGroupName $ResoureGroup.ResourceGroupName 

#endregion

Links:

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-dynamic-data-masking-get-started

https://docs.microsoft.com/en-us/powershell/module/azurerm.sql/New-AzureRmSqlDatabaseDataMaskingRule?view=azurermps-4.2.0