Introdução ao Azure Data Factory

Galera,

Estou começando hoje uma série de posts sobre o Azure Data Factory, ferramenta de ETL do MS Azure.

Ele nos permite fazer integração entre várias fontes de dados diferentes que estejam
on-premisses ou na nuvem, estes dados poderão ser transformados de várias maneiras possíveis e depois armazenados em um repositório que servirá de base para relatórios, por exemplo.

Objetivo a ser atingido com o artigo: Apresentar conceitos básicos sobre o ADF e criar uma integração simples entre uma storage account e um Azure Data Lake.

Terminologias

Antes de tudo precisamos entender alguns termos comuns que são utilizados no Data Factory:

  • Pipeline: agrupamento lógico de atividades que executam uma determinada atividade. Um Data Factory pode ter N pipelines.
  • Atividade: Representa a menor unidade de processamento. Cada um executa um tipo de atividade dentro do pipeline; Podendo se dividir em:
    • data movement activities
    • data transformation activities
    • control activities.
  • Dataset: estruturas de armazenamento de dados que servem como input e output para as atividades.
  • Linked server: Informações sobre as fontes de dados a serem usadas (connection strings)
  • Trigger: Como será disparada a execução do pipeline.

 

Criando um Data Factory

Para dar inicio na nossa PoC, precisamos criar todos os recursos que a compõe.
O primeiro deles é o Azure Data Factory.
Abra o portal do Azure e crie um novo recurso.

11.png

A definição dos parâmetros iniciais é bem auto-explicativa

12

Criando Storage Account (fonte de dados)

Continuando, vamos criar nossa fonte de dados. É aqui que a atividade de input de dados do pipeline irá buscar os dados para dar inicio ao processo.

Crie uma storage account, e insira um arquivo de texto, como blob, no seguinte formato dentro de um

14

 

nome,idade
dhiego,piroto
fernanda,tomiko
carlos,medeiros

Criando Azure Data Lake (Destino dos dados)

Agora vamos criar o destino dos nossos dados.
Não se preocupe se você nunca usou o ADL, vamos começar com o básico.

15

A definição dos parâmetros, assim como os do ADF, é bem auto-explicativa.

16

Gimme my demo!

Agora que já compreendemos alguns conceitos básicos e fizemos a criação do nosso ambiente, vamos para nossa demo de integração de dados.

Para manter as coisas simples, vamos criar essa primeira integração através do wizard que o Azure portal nos dá. Então acesse o nosso recém criado Azure Data Factory

17.png

A configuração via wizard é bem simples e precisamos nos atentar em alguns poucos detalhes:

Nome da task:

20

Fonte de Dados

21

onde, em nossa storage account, está o arquivo:

22

Qual padrão que o arquivo está, como é o delimitador de colunas e como é feita a quebra de linha?

24

Destino dos dados

Vamos mandar para nosso data lake

25

Precisamos trocar o tipo de autenticação de “principal” (que demandaria criar um application id no AD do Azure) para OAuth.

26.png

Como é o padrão que os dados vão ser exportados para o data lake

27

Como será o comportamento em caso se falha e qual será o nível de paralelismo

28

Validemos todos as informações.
Clique ‘Authorize’ para entrar com suas credencias do Azure (OAuth)

29

Acompanhando o deploy:

30

 

No final podemos ver isso nos diretório do nosso ADL e ver se o arquivo está lá
31

 

Você pode monitorar a execução de todos os seus pipelines no portal do Azure Data Factory: https://datafactory.azure.com 

31

Você poderá ver

  • Um modelo gráfico do seu código que exibe todas as entidades relacionadas ao seu pipeline.
  • Um correspondente, em json, ao seu pipeline

32.png

 

Pessoas, o exemplo de hoje foi bem simples, mas no decorrer da série vamos trabalhar algumas coisas mais complexas como: transformação de dados, agendamento de execuções, importação de pacotes DTS, integração com azure functions e outros.

Referencias

https://docs.microsoft.com/en-us/azure/data-factory/introduction 

[]`s

Piroto

Anúncios

Alertas Power BI + Flow/Azure Logic App

Fala Galera,

Recentemente precisei disparar alertas quando uma determinada condição dos meus dados exibidos em um dashboard do Power BI fosse verdadeira. Felizmente encontrei que há a possibilidade de integrar o MS Flow com tiles específicos do Power BI.

[Tudo que será explicado aqui envolvendo o Flow, pode ser replicado para o Azure Logic App. Escolhi fazer o tutorial no Flow pra que quem não use o Azure como provedor de cloud possa se beneficiar da funcionalidade.]

Vamos a um passo a passo bem simples de como fazê-lo:

Uma estrutura bem básica de tabelas será utilizada:

Estrutura de tabelas básica:

CREATE DATABASE TEMP
USE TEMP
GO
--Tabela que será usada para armazenar os dados do alarme
CREATE TABLE LOGPOWERBI (TEXTO VARCHAR(2000))
/*Tabela que irá armazenar os valores que serão usados como base
para nosso relatório o powerbi e para o alerta.*/
CREATE TABLE LOGPOWERBI_BASE (VALOR INT)
GO
INSERT INTO LOGPOWERBI_BASE (VALOR) VALUES (1000)
GO 4

 

  1. Configurações do  Power BI

No nosso exemplo vamos criar um report que vai somente somar os valores da coluna VALOR da tabela LOGPOWERBI_BASE e apresentar o total em um KPI.
Depois de publicado o relatório, vamos adicionar o nosso KPI em um dashboard:
(como não é o foco do artigo, esta parte será resumida em 3 imagens)

*lembrando que este processo não pode ser feito com todos os tipos de vizualizações do Power BI.
**O KPI e Gauge podem ser usados.

Uma vez adicionado o KPI a nosso dashboard podemos configurar o valor que servirá de trigger para disparar nosso fluxo do flow (rs) .

O menu pode ser acessado através de um clique na ellipsis (…)

4 adiciona alertas

Agora vamos configurar como será nossa regra para o acionamento do evento.
Em nosso caso, quero que quando a soma do campo VALOR da tabela LOGPOWERBI_BASE ultrapassar 6k, o fluxo seja disparado.

5 alerta
2. Configuração do Microsoft Flow

  • Acesse a página do MS Flow e crise sua conta. (**use a mesma conta que você usou para publicar seu relatório do Power BI)
  • No topo da página vá em  “meus fluxos” e depois “criar a partir do zero”
  • No final da página vá em: “Pesquisar outros conectores” e busque por “Power BI”

7

Como você usou a mesma conta que usou para publicar seu relatório do Power BI, agora é apresentada uma lista dos alertas que já existem configurados para esta conta. Selecione o que criamos no passo 1 do artigo.

8

Agora vamos adicionar outros passos a nosso fluxo.
Vá em “Adicionar nova etapa” e adicione um envio de alerta de e-mail.

9.png

Note que você pode selecionar cada uma das informações que você deseja receber no evento.

1, 2, 3 … Testando:

Nosso teste será bem simples. Vamos adicionar mais 1K linhas na nossa tabela, atualizar o dataset do dashboard e ver o que acontece:

 

INSERT INTO LOGPOWERBI_BASE (VALOR) VALUES (1000)  

6 refresh.png

Nada aconteceu,  certo?

Agora vamos executar o seguinte comando 3 vezes.

INSERT INTO LOGPOWERBI_BASE (VALOR) VALUES (1000)
GO 3 

e atualizar o datasource:

6 refresh

Resultados:

Você deve ter reparado que uma notificação apareceu no seu console do Power BI

10

Vamos checar o e-mail:

11

Bem bacana, né ?

Lembrando que o Flow tem MUITOS conectores diferentes: Twitter, Onedrive, Dropbox. Use a imaginação 😀

E o que é mais legal, você usa Azure? Ao invés de usar o Ms Flow, você pode usar o Azure Logic App. Fica mais fácil de controlar e com uma estrutura mais corporativa de gerenciamento centralizado.

Por hoje é isso.
[]’s

Piroto

[Power BI] Row Level Security

Fala Galera,

Quando falamos de dados, um dos assuntos que sempre nos vem a mente é a segurança. Não importa a natureza da informação ela é o bem maior das empresas e, como tal, o acesso a ela deve ser restrito a quem de direito.

Objetivo a ser atingido com o artigo: Criar um relatório utilizado o Power BI e controlar os acessos a um subgrupo de informações.

 

O Power Bi tem uma solução muito interessante para controlar estes acessos: Row Level Security (RLS).

Pre-requisitos para a demo:

  1. Executar o script abaixo para criação da nossa estrutura dos relatórios
CREATE TABLE MOVIMENTACAO(
FILIAL VARCHAR(20),
FATURAMENTO DECIMAL(10,2),
MES TINYINT ) 

INSERT INTO MOVIMENTACAO (FILIAL, FATURAMENTO, MES)
VALUES
('SP',43211.00, 1),
('SP',8297.00, 2),
('SP',50.00, 3),
('RJ',99.00, 1),
('RJ',1232.00, 2),
('RJ',5.00, 3),
('BH',8432.00, 1),
('BH',1243.00, 2),
('BH',321.00, 3)

 

Power BI
Criar uma nova conexão com sua base de dados, no meu caso em um Azure SQL Server, e fazer uma direct query que selecione todos os dados da tabela dbo.MOVIMENTACAO.

1 Select

Agora vamos criar alguns gráficos para representar nossos dados.

11.png

Agora vá até a aba de modelagem. Vamos usar os componentes da sessão de segurança.
A partir daqui faremos todas as configurações de permissionamento de vizualização dos dados do report.

2.5

Vamos criar duas regras: EstadoSP e EstadoRJ. Elas serão responsáveis, respectivamente, por dar acesso de visualização das informações destes estados aos usuários que estiverem dentro do grupo.

3 Config Roles

O PowerBI permite que o filtro seja feito através de uma expressão DAX. O que nos da muita liberdade pra criar regras complexas.

No nosso exemplo acima, estamos criando duas regras no meu dataset ‘query1’ e explicitando que no campo “FILIAL” somente os registros que contenham o valor “RJ” devem ser retornados.
Simples assim…

Testando o permissionamento

O próprio Power BI desktop permite que façamos testes com uma role de segurança específica.
Para isso vá até a modelagem >  componentes da sessão de segurança > View as Roles

4

Selecione uma das roles. (no nosso caso RJ)

rj.png

 

Vinculando os usuários com seus reports de direito

O próximo passo será adicionarmos os usuários que tem direito cada tipo de registro. Para isso precisamos publicar o relatório.

Uma vez publicado, acesse o portal e vá no menu de segurança do dataset desejado

6 onde atualizar

Agora basta adicionar os usuários em seus devidos grupos.

7

 

as simple as that.

Por hoje é isso.
[]’s

Piroto


[SSIS] Access is Denied com usuário não administrador

Fala Galera,

Mais uma dica rápida de SSIS:

Cenário: Ambiente com AD. Usuário não adm tentando acessar o Integration Services via SSMS.
Erro: Access is Denied.
By default, only administrators have access to the integration services.

Sem título.png

Motivo :”In previous versions of SQL Server, by default when you installed SQL Server all users in the Users group had access to the Integration Services service. When you install the current release of SQL Server, users do not have access to the Integration Services service. The service is secure by default. After SQL Server is installed, the administrator must grant access to the service.”

fonte: https://msdn.microsoft.com/en-us/library/hh213130(v=sql.110).aspx

Solução:

Adicionar o permissionamento necessário para o usuário

Abra o DCOMCNFG, um utilitário padrão do windows para alterar configurações do registro

Iniciar >  executar > dcomcnfg.exe

Capturar.PNG

 

Depois basta reiniciar o serviço do SSIS e testar novamente

Sem título.png

Done 🙂

[]’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

 

Alex Souza

"Aprendendo a Aprender e Aprendendo a Ensinar (inclusive Máquinas)!"

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