Estou movendo um aplicativo para o Azure e preciso obter conformidade com PCI para algumas colunas em uma única tabela. Sei que posso criptografar os dados antes de armazená-los, mas queria saber se havia um recurso no SQL Azure que pode gerenciar parte disso para mim. Eu fiz algumas leituras, mas não tenho certeza do que é; ou não é; com suporte no SQL Azure.
Eu li sobre padrões usando SQL Server ( e não SQL Azure ) onde a criptografia e descriptografia de dados foram aplicadas atrás de uma exibição. Nesse caso, todos os clientes acessaram os dados por meio de uma View e, conseqüentemente, foram abstraídos do processo de Criptografia/Descriptação. Com isso dito, parece um pouco perigoso.
Estou aberto a todas e quaisquer sugestões sobre como lidar com esta situação.
Resposta curta: a partir de 20 de abril de 2012, a criptografia de coluna não é suportada no SQL Azure, consulte: http://msdn.microsoft.com/en-us/library/windowsazure/ee336253.aspx e procure por ENCRYPT. Você verá que todas as funções de criptografia estão listadas como não suportadas.
Se você precisar criptografar seus dados em repouso e tiver que oferecer suporte ao SQL Azure, precisará fazer sua criptografia no nível do aplicativo. Isso é mais difícil de acertar, pois muitas boas práticas de criptografia (usando nonces como vetores de inicialização para cada célula, gerenciamento de chaves para rastrear quais chaves criptografam quais colunas, verificação de integridade, proteção em camadas de chaves de criptografia com permissões baseadas em função) você terá para implementar a si mesmo. Eu recomendo fortemente que um profissional de segurança trabalhe com você na criptografia, pois é um desafio acertar e, se você perder alguma coisa, terá uma falsa sensação de segurança que pode realmente queimá-lo mais tarde.
Você pode consultar http://securentity.codeplex.com , que afirma ser uma solução para gerenciar dados criptografados e oferece suporte ao SQL Azure. Eu não o usei pessoalmente, nem posso garantir sua exatidão, mas é uma opção em potencial.
Outra informação:
No SQL Server, a criptografia em nível de coluna é fácil e muito segura (mesmo com uma exibição), porque você pode usar funções para gerenciar quem pode acessar as chaves de criptografia. Mesmo que um usuário possa selecionar em uma exibição, se ele não tiver acesso à chave que criptografa os dados subjacentes, ele receberá NULLs para essas colunas criptografadas. Eu tenho um conjunto de código de amostra para SQL Server 2005 e superior que demonstra os recursos de criptografia do SQL Server aqui: http://sqlcrypto.codeplex.com
O Windows Azure está em conformidade com o Nível 1 dos Padrões de Segurança de Dados (DSS) da Indústria de Cartões de Pagamento (PCI), conforme verificado por um Avaliador de Segurança Qualificado (QSA) independente, permitindo que os comerciantes estabeleçam um ambiente de titular de cartão seguro e obtenham sua própria certificação.
https://www.windowsazure.com/en-us/support/trust-center/compliance/
Para criptografar uma tabela SQL hospedada no Azure, a rota mais fácil é simplesmente criar uma instância SQL IaaS e habilitar TDE ou criptografia em nível de coluna. (Em vez de usar o produto SQL Azure PaaS, que não oferece suporte à criptografia de dados transparente ou à criptografia em nível de célula).
Existem muitos outros requisitos de segurança a serem considerados, além da criptografia de números de cartão de crédito.
A partir de hoje, em relação ao artigo do MSDN e às informações de compatibilidade fornecidas pelo Microsoft Docs, ambos os recursos listados abaixo estão disponíveis no Banco de Dados SQL do Azure (PaaS).
Assim, você pode simplesmente usar esses recursos para atender aos seus requisitos e manter todo o processo de criptografia nos bastidores.
Aqui está um link para um resumo geral que apresenta os aspectos de segurança dos bancos de dados do Azure e pode ser o ponto de partida para preparar uma arquitetura de segurança apropriada.
Pela minha experiência, posso dizer que você deve ter cuidado se seu sistema estiver dividido entre os ambientes Azure e OnPremises. Nesse caso, pode haver um pouco de dificuldade em configurar tudo (autorização, sincronização).