[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

 

Anúncios

[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] Máquinas Virtuais

Fala Galera,

Continuando nossa série de artigos sobre Cloud Computing e Microsoft Azure, hoje vamos ver um pouco sobre as máquinas virtuais que podemos criar no Azure.

Um dos serviços mais básicos que um vendor de  cloud computing pode disponibilizar para seus clientes é o de  criação de máquinas virtuais.

Atualmente o Azure tem suporte para vários sistemas operacionais, por exemplo:

capturar

Se você preferir, e além da apenas a máquina virtual “crua”, você também quiser que um software específico venha instalado, há a opção de utilizar imagens pré-existentes de sistemas operacionais com uma solução já prontos para serem usados..
Discutimos um pouco do licenciamento desde modelo aqui.

capturar

Basicamente uma maquina virtual na Azure é composta por três recursos:

  • Recursos Computacionais
  • Storage
  • Network

Existem vários tipo tamanhos para as máquinas virtuais na Azure. Dependendo da quantidade disponível de um recuso eles são enquadrados em uma “série” específica. exemplos:
Série A – Máquinas básicas
Série D
Série DS: 16+ cores | 112+ GB RAM | 224+ SSD | 512MB/s Largura de Banda
Série G
Série GS: 16+ cores | 448+ GB RAM | 896+ SSD | 2GB/s Largura de Banda

Os tamanhos são muitos e sempre adicionam novas séries. Eu gosto de olhar sempre aqui para me atualizar.

E, para que tenhamos sucesso na hora de dimensionar a máquina que precisaremos contratar antes de fazer uma migração pra núvem,  a Microsoft nos disponibiliza o calculador de DTU: http://dtucalculator.azurewebsites.net/
E se você não tiver um ambiente on-premise para coletar essas informações? Bem, aí você pode usar uma das mais importantes (e legais) características de máquinas na nuvem: Resizing. (a.k.a: tentativa e ajuste)

Modos de Deploy

Quando criamos uma máquina no Azure, precisamos que ela seja  implantada com base em um modelo de deploy; Atualmente existem dois tipos:

  • Classic
  • Azure Resource Manager (ARM)

De modo geral o que muda de um para o outro é a forma como se controla os recursos computacionais da máquina; No modelo clássico estes recursos são gerenciados individualmente e no ARM eles podem ser gerenciados em grupo em grupos de recursos.

obs: Atualmente não há um modo de converter uma VM criada no modelo clássico para o ARM. 😦

Modos de Licenciamento

Quando vamos migrar um sistema existente ou novo para a nuvem, precisamos levar em conta os modelos de licenciamento das tecnologias que vamos fazer uso.
No caso de máquinas virtuais, se você optar pola instalação default de um S.O um preço será pago.

  • Por tempo de utilização (SO + RDBMS): Uma VM é criada já com uma imagem do SO e do SQL Server (versões disponíveis). Neste modelo a licença do Windows e do SQL Server já estão embutidas no preço.
  • Por tempo de utilização (SO) + Licença Existente: Uma VM do Windows é criada e a instalação é de responsabilidade do administrador da máquina; Esta abordagem possui significativas vantagens, já que há mais flexibilidade com relação a qual versão do Windows e do SQL Server usar.

 

Conclusão

Máquinas virtuais no Azure são bem parecidas com o modelo já existente na maioria das empresas.
O grande desafio, a meu ver,  está na hora de dimensionar corretamente a máquina, permitindo assim que seu cliente ou empregador economize $.

 

Por agora é isso galera.
[]’s

Piroto

[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

 

 

 

SQL Saturday #570 – São Paulo

download.png

Pessoas,

No dia 8 de setembro teremos a edição 570 do SQL Saturday aqui em São Paulo.

Não conhece o SQL Saturday?

“SQLSaturday é um evento de capacitação para profissionais de SQL Server, Business Intelligence e aqueles que querem aprender sobre o universo da Plataforma de dados da Microsoft. Este evento será realizado em 08 de Outubro de 2016, na UNIP Tatuapé, Rua Antônio Macedo, 505 – Parque São Jorge, Tatuapé – São Paulo – SP, São Paulo, 03087-040, Brasil.

A entrada ao evento é gratuita, todos os custos são cobertos por doações e patrocínios. Os lugares são limitados, registre-se para garantir sua vaga, e compartilhe com os outros para que todos possam comparecer.”

 

Bom, nessa edição eu serei um dos palestrantes. Mal posso explicar o quão ansioso eu estou de palestrar ao lado de figuras como Fabiano Amorim, Luti, Diego Nogare, Vitor Fava entre outros, que são as referências de SQL Server na comunidade.

Sem título.png

Já são mais de 1000 inscritos, e estamos com lista de espera.

Se cadastra aê 😀

https://www.sqlsaturday.com/570/RegisterNow.aspx

Agenda
http://www.sqlsaturday.com/570/Sessions/Schedule.aspx

[]’s

Piroto

Alex Souza

"Aprendendor 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