[SQL Saturday 606 – Chile] Impressões Gerais

WhatsApp Image 2017-04-01 at 22.16.45

Fala Galera,

Nesse último final de semana vivi uma das experiencias mais legais da minha vida profissional. Tive a oportunidade de palestrar no meu primeiro evento internacional: SQL Saturday 606 em Santiago, Chile.
Contamos com a participação de speakers de várias partes do continente Americano
(Brasil, Uruguay, Chile, EUA, México e Argentina) e um total de 158 pessoas na audiência.

De todas as coisas que aconteceram eu resumiria em dois pontos principais:

  1. Todo meu material: PPT, demos , flyer e meu mindset estavam prontos para uma apresentação em inglês; Durante o tradicional jantar dos palestrantes, que antecede o evento, me disseram que eu conseguia me comunicar muito bem em espanhol e que eu não deveria fazer a “charla” em inglês.
    É…depois de um pouco (muito) de pânico acabei aceitando. Faltavam menos de 12 horas para minha apresentação e mudam o idioma..tá fácil. Bem, acabou que tudo se desenrolou muito bem, tive o suporte de um dos palestrantes que falava inglês-espanhol e pode me ajudar, em tempo real, se eu dissesse alguma frase sem sentido. (Thanks for that @Erwin)
  2. Poder conhecer o grande @BenjaminNevarez , autor de dois dos livros de otimização de SQL Server que uso como guia nas horas de dúvida (esse e esse). Palestrar no mesmo evento que ele foi uma experiência única.

Um agradecimento especial a: Patrício Cofre e Carlos Farias pela oportunidade  😉

Grande Abraço e que venham as próximas!

Piroto

SQL Saturday #606 – Santiago Chile

Pessoas,

No dia 1 de abril (não, não é pegadinha rs) farei minha primeira palestra internacional para o PASS.

Quem estiver de férias ou a trabalho no Chile nesse período, se inscreve ae 🙂

 

El capítulo Chileno de PASS, te invita a participar en el PASS SQL Saturday Santiago-Chile 2017que se llevará a cabo el 1 de Abril del 2017 en Duoc Antonio Varas.
PASS SQL Saturday es un evento de entrenamiento para profesionales que trabajan con SQL Server y para aquellos que desean aprender sobre SQL Server. Contaremos con speakers de toda Latinoamerica, Expertos de Microsoft, Expertos en SQL Server y Microsoft MVPs.

http://www.sqlsaturday.com/606/Sessions/Schedule.aspx 

No automatic alt text available.

 

[]’s

Piroto

[AlwaysOn]Porta do endpoint em uso

Fala Galera,
Dica rápida da madruga

Problema

Estava configurando um AlwaysOn Availability Groups em um servidor e, durante a fase de instalação do wizard a seguinte mensagem era apresentada:Capturar.PNG

Solução
Achei um pouco estranho e fui buscar quem estava usando, via powershell, a porta


Get-NetTCPConnection| where LocalPort -eq "5022"| Format-Table -AutoSize

capturar

O IP que ele estava listado era do VIP do Cluster FailOver que também roda nessa máquina; Claro, em uma instância separada.

Bom, no meu caso, por algum motivo habilitaram a opção de alta disponibilidade nas instâncias do cluster.
Eu poderia apenas mudar a porta e daria tudo certo; mas, como não havia a necessidade da instância do cluster fazer uso desse endpoint, foi melhor excluí-lo. (Até por questão de burocracia para pedir liberação de portas no firewall)

capturar

Feito isso, tudo seguiu como esperado …

capturar

Por hora é isso.

Piroto

Always Encrypted Basics

Fala Galera,

Continuando falando um pouco sobre as features de segurança do SQL Server, hoje vou abordar o Always Encrypted.
Espero que gostem 🙂

A Microsoft introduziu o Always Encrypted no SQL Server 2016 – Enterprise Edition. Essa feature foi desenhada para proteger dados sensíveis que sejam armazenados na base de dados (Azure ou on-premise) até mesmo do próprio DBA.

É importante ter em mente que o Always Encrypted é uma criptografia Client-side, ou seja, o driver de comunicação da sua aplicação com o SQL Server faz todo o trabalho.
Na imagem 1 temos essa explicação de maneira visual.

  1. A aplicação dispara uma consulta para o SQL Server pedindo dados, que podem ou não estar criptografados. Caso estejam, o proprio driver (parte vermelha) criptografa as informações antes de enviar para o SQL.
  2. O SQL Server atende a query e envia as informações solicitadas, tal qual está armazenado no DB.
  3. O driver (parte vermelha) faz a descriptografia, se for o caso, e apresenta os dados para a aplicação em um texto legível.
capturar

Imagem 1 – Data Encryption

A chave que a aplicação vai usar para criptografar/descriptografar os dados não são armazenadas no SQL Server. Elas podem estar em:

  • Windows Certificate Store
  • Azure Key Volume
  • Hardware security modules

A criptografia é realizada a nível de coluna da tabela (se precisa de algo mais granular, consulte: Cell Level Encryption );
Sua implementação é simples e envolve pouquíssimas alterações na camada de aplicação. (falaremos delas no final do post)

Encryption Type

Quando escolhemos quais colunas devem ser criptografadas, precisamos escolher qual o tipo de criptografia será utilizada. Há duas opções:

  • Determinístico: “um algoritmo determinístico é um algoritmo em que, dada uma certa entrada, ela produzirá sempre a mesma saída, com a máquina responsável sempre passando pela mesma seqüência de estados”.
    Dito isso, fica fácil entender esse tipo de encriptação. Quando ela é últil? Bem, pense que o SQL Server vai poder usar o valor da sua chave em uma B-Tree. Dependendo do que você precise armazenar, isso vai fazer uma boa diferença na performance das consultas.
  • Randômico: Cada hash gerado será único, não importando o valor do dado original.

 

Keys

Além do tipo de criptografia, também é necessário definir as chaves que serão usadas:

Column Encrypted Key
Usada como base para criptografar uma coluna. Quando olhamos para um exemplo de seu código de criação, notamos a referência para:

  1. Master Key
  2. Algoritmo da criptografia
  3. Valor que é usado para gerar o blob criptografado.

CREATE COLUMN ENCRYPTION KEY [CEK_Auto1]
WITH VALUES
(
 COLUMN_MASTER_KEY = [CMK_Auto1], --1
 ALGORITHM = 'RSA_OAEP', --2
 ENCRYPTED_VALUE = 0x016E000001630075007200720065006E00740075007300650072002F006D007<...> --3
)

Se subirmos mais um nível e analisarmos o código de criação da master key, vamos notar que o local que ela está armazenada é em um endereço fora do SQL Server.


CREATE COLUMN MASTER KEY [CMK_Auto1]
WITH
(
 KEY_STORE_PROVIDER_NAME = N'MSSQL_CERTIFICATE_STORE',
 KEY_PATH = N'CurrentUser/my/373FA26F3BB2BBDB7181A37EF4FA1B4264239E5D'
)

Se o certificado não está no SQL Server, ele só pode estar em um lugar: na máquina que faz o acesso ao SQL Server.
Lembra-se que eu disse que o Always Encrypted é uma criptografia Client-Side ? Pois é…

 

Hands On

Para essa demo, vamos criar uma nova tabela e popula-la com alguns dados fictícios.

 

 

 


CREATE DATABASE BLOG_PIROTO
GO
USE BLOG_PIROTO
GO
CREATE TABLE DBO.ALWAYS_ENCRYPTED_DEMO(
 ID INT IDENTITY(1,1),
 TEXTO1 VARCHAR(10),
 TEXTO2 VARCHAR(10)
)
GO
--Vamos fazer um insert com dados fictícios e depois comparar os
--tipos de encriptação usado para cada coluna
DECLARE @I INT = 0
WHILE @I <= 100 BEGIN
 DECLARE @TEXTO VARCHAR(10) = REPLICATE('X',RAND()*10)
 INSERT INTO DBO.ALWAYS_ENCRYPTED_DEMO (TEXTO1,TEXTO2)
 VALUES (@TEXTO,@TEXTO)
 SET @I += 1
END

 

 

Para deixar o processo de simulação mais simples, vamos seguir usando o Always Encrypted Wizard. Ele pode ser encontrado em:

sem-titulo

O primeiro passo é definirmos quais as colunas que queremos que seja criptografas, qual o tipo de criptografia (Determinístico ou randômico) e qual a chave de criptografia; Como ainda não temos uma, o assistente vai cria-la.

capturar

Clique em next e defina as opções de armazenamento para sua Master key. Next > Next e Finish.

capturar

O que o SQL Server está fazendo agora é criando, armazenando e aplicando as chaves de criptografia na nossa tabela.
Agora, no SSMS, vamos gerar o DDL da nossa tabela e ver quais as alterações

sem-titulo

O resultado é:

capturar

O tipo do dado continua o mesmo mas a cláusula “Encrypted With” foi adicionada na definição das colunas. Nessa cláusula todas as opções da nossa criptografia são explicitadas.
Chama a atenção é que o collation da coluna também foi alterado para: Latin1_General_BIN2; Isso é uma premissa.

E como estão os dados da tabela?

SELECT * FROM DBO.ALWAYS_ENCRYPTED_DEMO

Capturar.PNG

Nada do valor real dos campos. Só temos um hash.
Vamos fazer uma consulta contar quantas ocorrências há de cada uma dos hashs, para entender a diferença entre os tipos de criptografia.

SELECT TEXTO1, COUNT(*) FROM [ALWAYS_ENCRYPTED_DEMO] GROUP BY TEXTO1

capturar

Bem, o campo “Texto1” nós configuramos como “Determinístico”. Então, cada cada campo que o valor for, por exemplo, “XXX” o mesmo hash vai ser gerado.

Como ficaram os dados na coluna que os hash foram gerados randomicamente?

SELECT TEXTO2, COUNT(*) FROM [ALWAYS_ENCRYPTED_DEMO] GROUP BY TEXTO2

capturar

Ooops! Mesmo a forma randômica sendo mais segura, ela tem uma série de limitações.

Precisamos ter em mente qual o tipo de dados e como ele é consultado na hora de escolher um tipo de criptografia.
Por exemplo, se escolhêssemos a criptografia randômica para um campo que armazene a senha de um usuário, não haveria problema…já se fosse para o campo CEP, poderíamos limitar as consultas que poderíamos fazer.

DMVs – Colunas Criptografadas

Quando for necessário consultar quais colunas da sua base de dados são criptografadas pelo Always Encrypted, basta executar a query abaixo:


SELECT
 OBJECT_NAME(OBJECT_ID),
 NAME,
 COLLATION_NAME,
 ENCRYPTION_TYPE_DESC,
 ENCRYPTION_ALGORITHM_NAME
FROM SYS.COLUMNS
WHERE ENCRYPTION_TYPE_DESC IS NOT NULL

 

Certificado

O tema “certificado” é bem extenso e, aborda-lo a fundo, não faz parte do escopo deste artigo.
O que você precisa saber é:

  • O Certificado está na minha máquina?

Para isso o Powershell vai te dar uma mão:

$chave="373FA26F3BB2BBDB7181A37EF4FA1B4264239E5D"
Get-ChildItem -Recurse Cert:| where Thumbprint -eq $chave

O parâmetro “$chave” precisa ser preenchido com o mesmo valor do campo KEY_PATH da sua Master Key.

capturar

  • Não tenho o certificado

https://blogs.msdn.microsoft.com/sqlsecurity/2016/07/05/developing-databases-using-always-encrypted-with-sql-server-data-tools/

 

Alterar minha aplicação?

No início deste post eu havia dito que a implementação do Always Encrypted era simples e necessitava “pouquíssimas alterações na camada da aplicação”.
Pois bem, a alteração é simples e rápida.
Se você estiver usando .NET, basta abrir seu web.config e adicionar a sua string de conexão o parâmetro “column encrypton setting=enable” e voilà.

E o SSMS?

Tudo muito bacana, tudo muito bom mas, e se você quiser ver os dados sem criptografia direto pelo SQL Server Management Studio?
Bom, aí você pode consultar esse post aqui  (em construção)
Por hoje é isso 🙂

[]’s

Piroto

 

[T-SQL] Dynamic Data Mask

Fala Galera,

Mascaramento de dados vem se tornando uma necessidade cada vez maior para empresas que armazenam informações sensíveis;(CPF, CNH, Número de Passaporte etc). Exibir estas informações para todos os usuários da sua aplicação pode levar a implicações jurídicas e muita dor de cabeça.

Para nos apoiar com esta demanda, o  SQL Server 2016 introduziu uma nova feature a “Dynamic Data Masking” que tem como objetivo mascarar dados para usuários que não tenham direto de vê-los, limitando a quantidade de dados sensíveis expostos.
Por ser uma configuração realizada somente a nível de banco de dados, ou seja, totalmente transparente para a cada da aplicação, o Data Masking pode, além de ser efetivo, economizar muito esforço do time de desenvolvimento.

Existem quatro tipos de mascaras disponíveis:

  1. Default: Máscara aplicada para todo o valor contido no campo.
  2. E-mail: Preparado para que apenas a primeira letra do endereço de e-mail e o sulfixo “.com” sejam exibidos.
  3. Random: Exibe um valor  inteiro randomico
  4. Custom String: Definido pelo usuário

Hands On

Para nossa demo vamos usar a base de dados de exemplo da Microsoft. Se você ainda não tem o AdventureWorks2016: Click Aqui

Você precisará estar logado como sysadmin do SQL para os primeiros passos (ficará claro o porquê em alguns instantes)

 

Para deixar as coisas um pouco mais simples, vamos fazer um select * into em uma nova entidade e depois usa-la para a demo.

use AdventureWorks2016CTP3
GO
SELECT P.FirstName, P.LastName, B.EmailAddress, PN.PhoneNumber
INTO PERSON.BLOG_PIROTO_TB1
FROM PERSON.Person P
JOIN PERSON.EmailAddress B ON P.BusinessEntityID = B.BusinessEntityID
JOIN Person.PersonPhone PN ON P.BusinessEntityID = PN.BusinessEntityID

Faça um select na nossa nova tabela e veja como estão os dados

capturar

Agora que carregamos os dados para nossa tabela PERSON.BLOG_PIROTO_TB1, vamos adicionar mascaras a seus campos.

ALTER TABLE PERSON.BLOG_PIROTO_TB1 ALTER COLUMN LASTNAME ADD MASKED WITH (FUNCTION = 'default()')

ALTER TABLE PERSON.BLOG_PIROTO_TB1 ALTER COLUMN emailAddress ADD MASKED WITH (FUNCTION = 'email()')

ALTER TABLE PERSON.BLOG_PIROTO_TB1 ALTER COLUMN FirstName ADD MASKED WITH (FUNCTION = 'partial(2, "BL-Piroto-X", 2)')

No total estamos usando três tipos diferentes de mascaramento:

  1. Default na coluna LASTNAME
  2. Email na coluna EMAILADDRESS
  3. Custom na coluna FIRSTNAME

Faça um select na tabela e vamos ver o que mudou nos dados

capturar

Os dados continuam os mesmos? Sem mascara nenhuma?
Bem, como eu disse no início do post, a ideia aqui é que os dados sensíveis não sejam apresentados para usuários que não devem ter acesso.
Se você está conectado com uma conta de ADM você terá aceso aos dados sem máscara. (Se   é uma premissa proteger seus dados, inclusive do DBA, você pode partir para outras features de criptografia como, por exemplo, o Always Encrypted.

Vamos criar um usuário com privilégios inferiores e ver como os dados são mostrados

CREATE LOGIN SUPORTE WITH PASSWORD = 'IXn*321Mnn#'
CREATE USER SUPORTE FOR LOGIN SUPORTE
ALTER AUTHORIZATION ON SCHEMA::person TO [suporte]

Faça o login com o novo usuário “suporte” e refaça o select na tabela PERSON.BLOG_PIROTO_TB1

capturar

Agora sim 🙂
Todas as máscaras estão configuradas conforme fizemos no segundo passo.

OBS: Mesmo que o usuário faça um select * into em uma nova entidade, os dados serão armazenados tal qual o retorno do select.

Se você precisar remover uma máscara ou conceder/revogar a permissão de um usuário (não ADM) a ver o dado original, faça o seguinte:

--remover máscara
ALTER TABLE PERSON.BLOG_PIROTO_TB1 ALTER COLUMN FIRSTNAME DROP MASKED
--Permissionamento
GRANT UNMASK TO SUPORTE
REVOKE UNMASK TO SUPORTE

Por fim, para descobrir quais colunas do seu banco possuem a feature de masking habilitada, há uma nova DMV chamada: SYS.MASKED_COLUMNS

SELECT
 OBJECT_NAME(A.OBJECT_ID) AS TABELA,
 A.NAME COLUNA,
 A.MASKING_FUNCTION MASCARA
FROM SYS.MASKED_COLUMNS A

Espero que, depois desse overview, vocês possam ter uma ideia de como implementar e obter vantagens dessa feature de mascaramento de dados no SQL Server 2016.

por agora é isso.

[]’s

Piroto

 

[Azure] SQL Azure

Fala Galera,
Seguimos em frente falando do MS Azure, mais especificamente do SQL Azure (FINALMENTE!)

Bem, possivelmente agora você já tem uma ideia de que o MS Azure é composto por uma gama gigante de tecnologias não correlatas ao assunto: Banco de Dados. Como o enfoque principal do Blog do Piroto é tratar de assuntos relacionados justamente a este tema que tanto me atrai, nós ficaremos mais envolvidos com o SQL Azure.
O SQL Azure é a  solução de banco de dados em nuvem da Microsoft como serviço.

[Update] Em alguns momentos, eu vou sim tratar de outros assuntos; ex: publicação de um website no Azure (já fiz e é bem fácil). Porém, em um primeiro momento, este não será o foco.

Em geral temos dois modos de utilizar o SQL Server no Azure.

  1. IaaS: Instalado em uma máquina virtual (bem similar ao modelo on-primise que a maioria das empresas usa) e todas as tarefas administrativas, de segurança, de cuidado para manter o serviço no ar continuam sendo de responsabilidade do DBA.
    Não sabe o que é uma VM no Azure? Clique aqui.
  2. PaaS: Usado como um serviço. Isso significa que toda a responsabilidade por manter o serviço no ar, integro, redundante e seguro é do time Microsoft e você, como cliente, somente precisa contratar o tier* de serviço que mais se adéqua a sua necessidade. Este modelo é ideal para a maioria dos desenvolvedores ou negócios que querem focar no desenvolvimento de suas aplicações e não na administração do ambiente.

E é nesse segundo modelo que grande parte dos próximos posts vai seguir.

Vantagens de contratar o SQL Azure?

  • Escalabilidade:  Escalar o poder de processamento do hardware é simples e requer , na maioria das vezes, alguns poucos clicks.
  • Gerenciamento: A equipe de TI da Microsoft é responsável  por aplicar atualizações e realizar manutenções nas máquinas, deixando essa parte administrativa longe dos olhos do contratante.
  • Alta disponibilidade: A Microsoft garante que seu DB que caso exita um problema, um failover automático irá acontecer e evitar quaisquer possíveis indisponibilidade para sua base de dados.
  • Ferramentas: Seus devs não vão precisar aprender uma gama de novas ferramentas para usar o SQL Azure; O acesso ainda pode ser feito direto pelo SSMS, pelo Visual Studio (2010+), ADO.NET ou Entity Framework.

Ainda falando de alta disponibilidade, a Microsoft garante um SLA (Service Level Agreement) de ao menos 99.99% para o SQL Azure; Ou seja, 43 minutos por mês de outage.
Mais detalhes sobre SLAs aqui

Service Tiers

Antes de sairmos criando o nosso serviço do SQL Azure, vamos fazer uma breve introdução as tiers de máquina que você pode contratar.
Os service tiers são grupos de máquinas, separados por capacidade de processamento, que você precisa escolher quando cria um serviço no Azure.

Atualmente tempos três tipos, são eles:

  • Basic
  • Standard
  • Premium

Cada uma das opções possui diferenças nos níveis de performance entre aos contratantes. Além da tiers, você deve escolher a capacidade de processamento que será entregue a um único serviço de banco de dados (também pode ser compartilhada entre várias bases  através do elastic pool).
Database Transaction Unit (DTU) foi a medida que a Microsot encontrou para estimar o workload de um servidor e facilitar a contratação de um correspondente na nuvem. O número de DTUs disponíveis varia de 5 a 1750.

6064-2

Se ainda tem dúvidas sobre os DTUs e como Calcula-los: Clique Aqui

 

Segurança

O SQL Azure pode ser acessado, basicamente, de duas maneiras: Via internet e via Windows Azure VM.
Uma séria de validações é realizadas por uma capada de firewall, por exemplo:

  • O IP que está tentando acessar o SQL está liberado? (No caso de uma máquina interna do Azure você pode usar o IP “0.0.0.0”, para liberar acesso)
  • Usuário + Senha

 

Pessoas,
Até agora a linha dos posts foi mais voltada a dar uma base teórica sobre Cloud Computing e Azure. A partir do próximo post vou me voltar a algo mais prático.

Espero que estejam gostando 🙂

 

Referências

Microsoft Azure Essentials: Migrating SQL Server Database to Azure.

https://blogs.msdn.microsoft.com/igorpag/2015/12/05/sql-server-in-azure-compare-paas-sqldb-and-iaas-virtual-machine/ 

[SQL Saturday 570] Apresentação e Demo

14606507_1268027666574151_7511353594773806550_n

Fala Galera,

No sábado final de semana (08/10) tivemos a edição 570 do SQL Saturday. Foi minha primeira vez como palestrante em um evento desse porte e, com o perdão da palavra, foi FODA!
Esse post é para agradecer que pode comparecer ao evento e a minha palestra. Tive muitos feedbacks legais: tanto pro lado positivo, quanto ao de coisas a serem melhoradas. Tudo devidamente anotado.
Aos que quiserem o material utilizado na apresentação aqui

Abraço a todos!

Piroto

 

 

 

Alex Souza

Banco de dados, Business Intelligence, Big Data, Governança de TI ... /* Um eterno aprendiz... */

Blog - Thiago Carlos de Alencar

Aprendendo SQL Server !

SQL Authority with Pinal Dave

SQL Server Performance Tuning Expert

Vitor Fava

SELECT (CrazyIdeas*2), (InsaneIdeas*100), MyExperience FROM MyBigHead WHERE InsaneLevel > 1000

Think Think SQL

DBCC DumpMemory 'TECH','ALL'

Gustavo Maia Aguiar

Artigos, dicas e algumas reflexões sobre o SQL Server

Kimberly L. Tripp

DBCC DumpMemory 'TECH','ALL'

Thiago Zavaschi R2

www.zavaschi.com

Blog do Luti

DBCC DumpMemory 'TECH','ALL'

Luan.Moreno a.k.a [SQL.Soul]

Lead Database Consultant at Pythian

Blog do Leka

let's make things better