Aprimorando a segurança de dados por meio do SQL Server 2005

Usando criptografia de SQL Server 2005 para ajudar a proteger dados

Publicado em: 1 de outubro de 2005

Informe oficial técnico

Nesta página

Sinopse
Introdução
Ambiente de aplicativo
Solução: Criptografia do SQL Server 2005
FeedStore
Sistema de relatórios de controles de folha de pagamento
Metropolis
Práticas recomendadas
Conclusão
Para obter mais informações
Apêndice: Cenários de uso de criptografia

Sinopse

A Microsoft, como várias grandes empresas, analisa cuidadosamente as estruturas de segurança de banco de dados existentes para garantir que as estruturas de segurança cumpram com os requisitos reguladores recentes do governo, como a Lei Sarbanes-Oxley, de 2002. Esses requisitos reguladores especificam condições para o armazenamento de informações de identificação pessoal. Os requisitos não só afetam os dados quando armazenados em um banco de dados. Afetam também os mecanismos de transferência de dados, os controles de autorização e acesso a banco de dados e a auditoria de banco de dados.

Ao usar essa análise de banco de dados, a TI da Microsoft (Tecnologia da informação da Microsoft) confirmou que os dados confidenciais eram duplicados por todo o espaço de aplicativo LOB (line-of-business, linha de negócios) da TI da Microsoft. Esses dados eram duplicados quando dados eram transferidos e replicados durante as operações diárias da empresa.

Em resposta a essa análise, a TI da Microsoft desenvolveu estratégias para reduzir a duplicação de dados confidenciais e aprimorar a segurança de informações de identificação pessoal no espaço de aplicativo LOB da TI da Microsoft. Essas estratégias baseiam-se nos novos recursos e funcionalidades de segurança contidos no Microsoft® SQL Server™ 2005.

O grupo Enterprise Data Services da TI da Microsoft criou um repositório central de informações de 2 terabytes, denominado FeedStore. O grupo desenvolveu um projeto piloto para aprimorar a segurança das informações de identificação pessoal que passam pelo FeedStore. Esse projeto envolveu a criação de um armazenamento criptografado centralizado, com o nome de Digital Asset Store, para abrigar informações de identificação pessoal altamente confidenciais. O grupo Enterprise Data Services desenvolveu o Digital Asset Store para usar os recursos de gerenciamento de chave e a funcionalidade de criptografia em nível de coluna, no SQL Server 2005, para criptografar dados confidenciais em um local central. Esse projeto piloto possuía metas de negócios e metas funcionais claras para ajudar a remover ou a reduzir a duplicação de dados nos aplicativos LOB da TI da Microsoft.

O departamento de TI da Área Financeira da TI da Microsoft criou o aplicativo PCRS (Payroll Controls Reporting System, Sistema de relatórios de controles da folha de pagamento). Esse departamento desenvolveu uma estrutura de segurança para aprimorar a segurança de dados por meio da criptografia de dados confidenciais que seriam armazenados no armazém de dados do PCRS. Além disso, o departamento de Serviços de TI, que integra a TI da Microsoft, usou a funcionalidade de gerenciamento de chave do SQL Server 2005, e os recursos de criptografia em nível de coluna, para criar um mecanismo de criptografia robusto (confiável e forte) para criptografar dados no aplicativo LOB Metropolis.

Este documento compartilha experiências da TI da Microsoft com essas estratégias de segurança e com os recursos de criptografia do SQL Server 2005. Como vários projetos piloto do SQL Server 2005 estão atualmente em andamento, a TI da Microsoft extraiu lições valiosas e práticas recomendadas relativas à consolidação de dados e à criptografia no espaço de aplicativo LOB da TI da Microsoft. Já que os requisitos da TI da Microsoft encontram-se entre os mais desafiadores do mundo, as estratégias desenvolvidas e as lições extraídas pela TI da Microsoft por meio da implantação do SQL Server 2005 devem fornecer orientação significativa para as empresas que desejam implantar uma estrutura de criptografia e um gerenciamento de chave baseados no SQL Server 2005.

Este documento é destinado aos responsáveis pelas decisões empresariais, responsáveis pelas decisões técnicas, arquitetos de TI, desenvolvedores de bancos de dados e gerentes de implantação. Embora este documento forneça recomendações fundamentadas em experiências pioneiras da TI da Microsoft, não se destina a servir como guia de procedimentos. Cada ambiente empresarial passa por circunstâncias únicas. Portanto, cada organização deve adaptar as informações para atender a requisitos específicos.

Observação: por razões de segurança, os nomes de exemplos de recursos internos, organizações, e nomes de arquivo de segurança desenvolvidos internamente, usados neste documento, não representam nomes de recursos reais usados dentro da Microsoft, constando deste documento apenas para fins ilustrativos.

Introdução

Os responsáveis por decisões empresariais, em geral, solicitam informações sobre experiências com a utilização de produtos e tecnologias da Microsoft no âmbito da própria Microsoft. Os departamentos de TI da Microsoft não fornecem apenas serviços de TI. Esses departamentos agem também como primeiro cliente de cada nova versão de software para servidores e produtividade nos negócios. Como os requisitos da TI da Microsoft encontram-se entre os mais desafiadores em termos técnicos do mundo, os métodos que a TI da Microsoft usa para implantar essas tecnologias, e a experiência que a TI da Microsoft subtrai dessas implantações, em geral, fornecem orientação significativa quanto à implantação e à operação para outras empresas que desejam implantar produtos da Microsoft.

Além disso, uma vez que a TI da Microsoft trabalha com novos produtos Microsoft de edições de pré-lançamento das versões RTM (Release to Manufacturing, versão para produção), a TI da Microsoft fornece à Microsoft um valioso feedback sobre recursos e funcionalidades. Esse feedback aprimora os produtos de software. Esse feedback ajuda também os clientes e parceiros da Microsoft a implantar esses produtos e tecnologias com sucesso.

Visão geral de requisitos reguladores

Como outras empresas, a Microsoft vem reavaliando as estruturas de segurança atuais para garantir que as estruturas de segurança cumpram com as leis federais, estaduais e internacionais recentes que definem as obrigações de conformidade reguladora relativas às informações pessoais. Nos Estados Unidos, essas leis incluem as seguintes leis federais e estaduais:

  • Lei Sarbanes-Oxley de 2002

  • Lei GLBA (Gramm-Leach-Bliley) de 1999

  • Lei HIPAA (Health Insurance Portability and Accountability, Portabilidade e transparência dos planos de seguro saúde) de 1996

  • Lei FERPA (Family Educational Rights and Privacy, Direitos ??educacionais e de privacidade da família)

  • Título FDA 21 Parte 11 do CFR

  • California Senate Bill 1386

  • Washington Senate Bill 6043

Além disso, alguns regulamentos internacionais definem as obrigações de conformidade reguladora para empresas que armazenam informações de identificação pessoal. Esses regulamentos englobam:

  • Lei PIPEDA (Canadian Personal Information Protection and Electronic Documents, Proteção a informações pessoais e documentos eletrônicos canadense)

  • European Union Data Protection Directive (Política ??de proteção a dados da União Européia)

  • Basel Capital Accord, também conhecida como Basel II

As organizações que armazenam informações pessoais do consumidor devem considerar cuidadosamente as implicações relativas a esses novos requisitos reguladores. Esses requisitos afetam todas as seguintes operações de bancos de dados:

  • Autenticação de banco de dados, inclusive diretivas de senha e protocolos de autenticação

  • Controles de autorização e acesso a banco de dados

  • Proteção a dados confidenciais armazenados em um banco de dados

  • Proteção a dados confidenciais transferidos para um banco de dados ou de um banco de dados

  • Auditorias de transações de bancos de dados para ajudar a garantir confidencialidade e integridade de dados

As empresas devem cumprir as obrigações de conformidade reguladora relativas às informações de identificação pessoal. Para fornecer proteção a dados eficaz e econômica, os departamentos de TI das empresas devem reexaminar como suas organizações armazenam e gerenciam dados confidenciais.

Visão geral da criptografia de dados

Durante a avaliação de uma estrutura de segurança, os departamentos de TI da empresa devem reavaliar a segurança em toda a organização. Essas precauções de segurança podem incluir diretivas de senha, diretivas de auditoria, isolamento dos servidores de bancos de dados e controles de autenticação e autorização de aplicativo. No entanto, a barreira de segurança final para auxiliar na proteção de dados confidenciais é normalmente a criptografia de dados.

A criptografia é um mecanismo que ajuda a proteger dados. A criptografia ajuda a fornecer confidencialidade pela ofuscação dos dados, de modo que somente as pessoas autorizadas podem acessar e ler os dados. Os dados são criptografados quando os dados originais, conhecidos como texto simples, juntamente com um valor que é conhecido como chave, são submetidos a uma ou mais fórmulas matemáticas. Esse procedimento torna os dados originais ilegíveis. O dados criptografados resultantes são conhecidos como texto codificado. Para tornar esses dados legíveis novamente, o destinatário descriptografa os dados, revertendo o processo matemático juntamente com a chave correta.

Esse tipo de proteção a dados, no entanto, possui um custo quanto ao tempo do processador do computador e quanto aos requisitos de armazenamento. Uma chave de criptografia mais longa ajuda a tornar o texto cifrado mais seguro do que se uma organização usar uma chave de criptografia mais curta. No entanto, essa operação de criptografia/descriptografia mais complexa custa mais em termos de tempo de processador do que a criptografia que usa uma chave de criptografia menor. Além disso, a criptografia amplia o tamanho dos dados de destino (criptografados).

Existem dois tipos principais de criptografia a seguir:

  • Criptografia simétrica. Esse tipo de criptografia é também conhecido como criptografia de chave compartilhada.

  • Criptografia assimétrica. Esse tipo de criptografia é também conhecido como criptografia em duas partes, ou criptografia de chave pública.

1quote.gifCom o SQL Server 2005, poderemos elevar a segurança ao próximo nível e criptografar os atributos que precisam ser protegidos... como números de previdência social e outras informações confidenciais.2quote.gif David FaheyMicrosoft Corporation
Criptografia simétrica

A criptografia simétrica usa a mesma chave tanto para criptografar como para descriptografar dados. Os algoritmos que são usados para a criptografia simétrica são mais simples do que os algoritmos usados na criptografia assimétrica. Em função desses algoritmos mais simples, e porque a mesma chave é usada tanto para criptografar como para descriptografar dados, a criptografia simétrica é muito mais rápida que a criptografia assimétrica. Portanto, a criptografia simétrica é adequada à criptografia e descriptografia de uma grande quantidade de dados. A Figura 1 mostra o processo de criptografia simétrica.

Figura 1. Processo de criptografia simétrica

Figura 1. Processo de criptografia simétrica

Uma das principais desvantagens da criptografia simétrica é o uso da mesma chave tanto para criptografar como para descriptografar os dados. Por isso, todas as partes que enviam e recebem os dados devem conhecer ou ter acesso à chave de criptografia. Esse requisito cria um problema de gerenciamento de segurança e problemas de gerenciamento de chave que uma organização deve considerar em seu ambiente. Um problema de gerenciamento de segurança existe porque a organização deve enviar essa chave de criptografia a todos que requererem acesso aos dados criptografados. Os problemas de gerenciamento de chave que uma organização deve considerar incluem a geração, distribuição, backup, regeneração e ciclo de vida da chave.

A criptografia simétrica fornece autorização para dados criptografados. Por exemplo, ao usar a criptografia simétrica, uma organização pode estar razoavelmente certa de que apenas as pessoas autorizadas a acessar a chave de criptografia compartilhada podem descriptografar o texto codificado. No entanto, a criptografia simétrica não fornece não-repúdio. Por exemplo, em um cenário em que várias partes têm acesso à chave de criptografia compartilhada, a criptografia simétrica não pode confirmar a pessoa específica que envia os dados. Os algoritmos de criptografia usados na criptografia simétrica incluem o seguinte:

  • RC2 (128 bits)

  • 3DES (Triple Data Encryption Standard, Padrão triplo de criptografia de dados)

  • AES (Advanced Encryption Standard, Padrão de criptografia avançada)

Criptografia assimétrica

A criptografia assimétrica usa duas chaves diferentes, porém matematicamente relacionadas, para criptografar e descriptografar dados. Essas chaves são conhecidas como chaves privadas e chaves públicas. Em conjunto, essas chaves são conhecidas como par de chaves. A criptografia assimétrica é considerada mais segura do que a criptografia simétrica, porque a chave usada para criptografar os dados é diferente da que é usada para descriptografá-los. Contudo, como a criptografia assimétrica usa algoritmos mais complexos do que a criptografia simétrica, e como a criptografia assimétrica usa um par de chaves, o processo de criptografia é muito mais lento quando uma organização usa a criptografia assimétrica do que quando usa a criptografia simétrica. A Figura 2 mostra o processo de criptografia assimétrica.

Figura 2. Processo de criptografia assimétrica

Figura 2. Processo de criptografia assimétrica

Com a criptografia assimétrica somente uma parte mantém a chave privada. Essa parte é conhecida como o assunto. Todas as outras partes podem acessar a chave pública. Os dados criptografados por meio da chave pública só podem ser descriptografados pela chave privada. Por outro lado, os dados criptografados por meio da chave privada só podem ser descriptografados pela chave pública. Por conseguinte, esse tipo de criptografia fornece confidencialidade e não-repúdio.

Uma organização pode usar esse tipo de criptografia para fornecer autorização, usando a chave pública para criptografar dados. Essa chave é disponibilizada publicamente. Desse modo, qualquer um pode criptografar os dados. No entanto, como apenas o assunto mantém a chave privada, a organização pode estar razoavelmente certa de que apenas o destinatário pretendido pode descriptografar e exibir os dados criptografados.

Uma organização pode usar esse tipo de criptografia para fornecer autenticação, usando a chave privada para criptografar dados. Apenas o assunto mantém essa chave. No entanto, todos podem descriptografar os dados porque a chave pública que descriptografa esses dados é disponibilizada publicamente. Conseqüentemente, se o destinatário pode descriptografar esses dados por meio da chave pública, pode estar razoavelmente certo de que apenas o assunto criptografou os dados. Os algoritmos de criptografia usados na criptografia assimétrica incluem o seguinte:

  • Diffie-Hellman key agreement

  • Rivest-Shamir-Adleman (RSA)

  • DSA (Digital Signature Algorithm, Algoritmo de assinatura digital)

Criptografia híbrida

A criptografia híbrida é um esquema de criptografia em que a criptografia de dados é realizada por meio da combinação de criptografias simétrica e assimétrica. O método de criptografia híbrida utiliza as forças de ambos os tipos de criptografias para ajudar a assegurar que apenas o destinatário pretendido leia os dados.

Em um cenário de criptografia híbrida, uma organização criptografa dados usando a criptografia simétrica em conjunto com uma chave gerada aleatoriamente. Essa etapa aproveita a velocidade da criptografia simétrica. Desse modo, a organização criptografa a chave de criptografia simétrica por meio da chave pública de um par de chaves assimétricas. Essa etapa tira proveito da segurança ampliada da criptografia assimétrica. Os dados criptografados, juntamente com a chave simétrica criptografada, são enviados para o destinatário de dados. A Figura 3 mostra o processo de criptografia híbrida.

Figura 3. Processo de criptografia híbrida

Figura 3. Processo de criptografia híbrida

Para descriptografar os dados, o destinatário usa primeiramente a chave privada do par de chaves assimétricas para descriptografar a chave simétrica. Em seguida, o destinatário usa a chave simétrica descriptografada para descriptografar os dados. A Figura 4 ilustra o processo de descriptografia híbrida.

Figura 4. Processo de descriptografia híbrida

Figura 4. Processo de descriptografia híbrida
Considerações sobre a criptografia

Quando uma organização decide a criptografar dados, deve considerar o aumento de carga do processador para realizar a criptografia e a descriptografia. No entanto, deve também considerar o aumento do espaço de armazenamento que os dados criptografados consomem. A quantidade de espaço de armazenamento que os dados consomem depende do algoritmo que a organização usa, do tamanho da chave e do tamanho do texto simples que a organização criptografa.

Embora uma organização deva considerar tanto problemas de desempenho como de armazenamento ao implementar a criptografia, o problema mais importante é o gerenciamento da chave. As chaves de criptografia usadas por uma organização para criptografar e descriptografar dados são partes essenciais de sua estrutura de segurança de dados. Para assegurar que apenas usuários autorizados exibam dados criptografados, a organização deve implementar medidas para gerenciar, armazenar, ajudar a proteger e realizar backup de chaves de criptografia.

Ambiente de aplicativo

A TI da Microsoft fornece serviços de TI globais para a Microsoft. Esses serviços incluem os serviços de suporte para 57.000 funcionários, mais de 200.000 computadores pessoais e mais de 8.000 servidores. Esses serviços abrangem operações de servidor e rede para implantação de software e suporte técnico ao usuário final. Além disso, a TI da Microsoft lida mensalmente com mais de 100.000 problemas relativos à segurança.

A TI da Microsoft possui mais de 300 aplicativos LOB que manipulam dados confidenciais nas operações diárias da empresa. A meta da TI da Microsoft é aprimorar a segurança de dados à medida que são armazenados, transmitidos, processados ou exibidos em sistemas ou relatórios de todos os aplicativos LOB. Por conseguinte, a TI da Microsoft atualiza atualmente todos os seus aplicativos LOB relativos a bancos de dados para o SQL Server 2005. Essa atualização utiliza os novos recursos e funcionalidades relacionados ao gerenciamento, à segurança e ao desempenho do SQL Server 2005.

A TI da Microsoft analisou (e continua a analisar) suas soluções de armazenamento de banco de dados em resposta aos seguintes requisitos:

  • Requisitos governamentais reguladores para ajudar a proteger a privacidade de pessoas, clientes e parceiros

  • Requisitos de segurança de informações corporativas da Microsoft relativos às informações de identificação pessoal confidenciais, como informações pessoais sobre funcionários e parceiros

Este documento discute as estruturas de criptografia que a TI da Microsoft desenvolveu e continua a desenvolver para os três sistemas de bancos de dados que a análise incluía:

  • O repositório central de informações de 2 terabytes denominado FeedStore, do grupo Enterprise Data Services

  • O armazém de dados PCRS da TI da Área Financeira

  • O serviço Metropolis e o banco de dados da ferramentas de suporte do departamento de TI de Serviços

Como diferentes quantidades de dados estão envolvidos, diferentes números de aplicativos estão envolvidos, e os ambientes de banco de dados particular diferem, os departamentos de TI que gerenciavam cada um desses sistemas de bancos de dados dentro da TI da Microsoft precisaram desenvolver estratégias de criptografia e processos de implementação diferentes durante suas análises do ambiente de aplicativo particular que gerenciavam. Contudo, o comum dessas estratégias era usar o SQL Server 2005 para implementar uma hierarquia de gerenciamento de chave e uma criptografia em nível de coluna.

Solução: Criptografia do SQL Server 2005

O SQL Server 2005 inclui diversos recursos relativos à segurança que ajudam a proteger dados em uma organização. O SQL Server 2005 inclui a aplicação de diretiva de senha, uma forte funcionalidade de autenticação e um modelo de permissões hierárquicas granulares. O SQL Server 2005 também inclui um recurso interno de criptografia de dados. Esse recurso de criptografia em nível de coluna é aprimorado por uma infra-estrutura aperfeiçoada e integrada de gerenciamento de chaves de criptografia. As funções internas de criptografia e as APIs (application programming interfaces, interfaces de programação de aplicativos) facilita a criação de uma estrutura de segurança criptográfica para a organização.

1quote.gifCom a criptografia interna do SQL Server 2005 não é necessário pensar em como o processo funciona no plano de fundo. Basta chamar a função de criptografia para criptografar os dados.2quote.gif Devendra TiwariMicrosoft Corporation

Recursos internos de criptografia

O gerenciamento de chave é o elemento mais importante de uma estrutura de segurança de criptografia. O SQL Server 2005 oferece suporte a três tipos de criptografia. Cada um dos tipos usa uma espécie diferente de chave e cada tipo tem vários algoritmos de criptografia e eficácias de chaves, como segue:

  • Criptografia simétrica: O SQL Server 2005 oferece suporte às famílias RC4, RC2, DES e AES de algoritmos de criptografia.

  • Criptografia assimétrica: O SQL Server 2005 suporta o algoritmo de criptografia de RSA, juntamente com as eficácias de chaves de 512 bits, 1.024 bits e 2.048 bits.

  • Certificados: O uso de certificado é uma outra forma de criptografia assimétrica. Contudo, uma organização pode usar um certificado para associar um conjunto de chaves públicas e privadas ao seu usuário por meio de uma assinatura digital. O SQL Server 2005 oferece suporte à IETF (Internet Engineering Task Force, Força-tarefa de Engenharia da Internet), especificação X.509, versão 3 (X.509v3). Uma organização pode usar certificados gerados internamente com o SQL Server 2005, ou pode gerar certificados utilizando o SQL Server 2005.

Hierarquia de chave de criptografia

O SQL Server 2005 implementa uma estrutura para ajudar a proteger chaves de criptografia, usando uma hierarquia de chave de criptografia, como mostrado na Figura 5. Cada camada nessa hierarquia criptografa as camadas que se encontram abaixo.

Figura 5. Hierarquia de chave de criptografia do SQL Server 2005

Figura 5. Hierarquia de chave de criptografia do SQL Server 2005

A DPAPI (Data Protection API, Proteção de dados de API) encontra-se no topo da hierarquia de chave de criptografia. A DPAPI consiste em chamadas de par de funções que fornecem serviços de proteção a dados em nível de sistema para os processos de usuário e de sistema. Como essa API faz parte do sistema operacional Microsoft Windows®, os aplicativos podem usar a DPAPI para criptografar dados, mas não têm que usar nenhum código de criptografia, exceto o código que chama as funções DPAPI. A DPAPI é um serviço de proteção a dados baseado em senha. Desse modo, a DPAPI requer uma senha para criptografar os dados.

Observação: a senha usada aqui é a mesma da conta que chama a funcionalidade de criptografia. Conseqüentemente, um desenvolvedor que implemente a criptografia não precisa especificar uma senha adicional.

A chave mestre de serviço do SQL Server 2005 é uma chave simétrica que a função cryptGenKey gera automaticamente quando um administrador instala o SQL Server 2005. A DPAPI usa a senha da conta em que o SQL Server 2005 é executado para gerar a chave com a qual a DPAPI criptografará a chave mestre de serviço. Desse modo, se um administrador altera a conta de serviço em que o SQL Server 2005 é executado, deve descriptografar a chave mestre de serviço usando as credenciais originais. Em seguida, deve criptografar a chave mestre de serviço por meio de novas credenciais. É altamente recomendável que os administradores alterem a conta de serviço em que o SQL Server 2005 é executado usando apenas a ferramenta Computer Manager do SQL Server 2005. Essa ferramenta realiza automaticamente as etapas requeridas para descriptografar a chave mestre de serviço e, em seguida, para criptografar novamente a chave mestre de serviço.

Observação: um administrador não precisará realizar essas ações se alterar apenas a senha da conta de serviço. Essas ações só precisam ser realizadas se a conta de serviço atual em que o SQL Server 2005 é executado for alterada.

A chave mestre de serviço criptografa a chave mestre do banco de dados. A chave mestre do banco de dados é requerida em todos os bancos de dados em que uma organização criptografe dados. A chave fornece a mesma funcionalidade da chave mestre de serviço. A funcionalidade, porém, ocorre em nível de banco de dados, em vez de em nível da instância do SQL Server 2005.

A chave mestre do banco de dados é uma chave simétrica. Não é criada automaticamente quando um novo banco de dados do SQL Server 2005 é criado. Conseqüentemente, o desenvolvedor deve criar essa chave explicitamente para implementar a criptografia em um banco de dados.

A chave mestre do banco de dados criptografa as chaves de usuário criadas por um desenvolvedor. Essas chaves de usuário incluem certificados e chaves assimétricas. Em contrapartida, certificados e chaves assimétricas criptografam chaves simétricas criadas pelo desenvolvedor.

Observação: um desenvolvedor também pode usar certificados e chaves assimétricas para criptografar dados diretamente. No entanto, os certificados e chaves assimétricas são mais apropriados à criptografia de quantidades pequenas de dados.

Um desenvolvedor pode usar chaves simétricas para criptografar outras chaves simétricas que cria, ou para criptografar dados. É importante considerar essa hierarquia de chave de criptografia, em especial, quando o desenvolvedor determina o tipo de chave a ser usado para criptografar chaves recentemente criadas. A estrutura de chave de criptografia do SQL Server 2005 oferece ao desenvolvedor uma grande flexibilidade para a criação de uma hierarquia de chave de criptografia simples ou complexa para cada banco de dados que cria. É recomendável, porém, que o desenvolvedor crie uma estrutura de chave tão simples quanto sua organização permita.

Observação: um desenvolvedor também pode criptografar a chave privada de um certificado, ou uma chave simétrica, especificando uma senha. No entanto, esse método é geralmente mais apropriado a um ambiente onde se aceita que aplicativos ou usuários finais tenham conhecimento do método de criptografia e das chaves de criptografia usados. Esse método não é bom para um cenário em que o processo de criptografia é destinado a ser transparente aos usuários finais.

Chaves de criptografia

O processo de criptografia e descriptografia requer as seguintes chaves.

Certificado

Um certificado é uma forma de usar a criptografia assimétrica. Um certificado é um objeto de segurança assinado digitalmente que vincula o valor da chave pública ao usuário, dispositivo ou serviço que mantém a chave privada correspondente. Uma CA (certification authority, autoridade de certificação) emite e assina certificados. Os certificados que o SQL Server 2005 cria atendem o padrão de certificado IETF X.509v3. Em geral, um desenvolvedor usa um certificado para criptografar outros tipos de chaves de criptografia em um banco de dados.

Chave assimétrica

Uma chave assimétrica consiste em uma chave privada e em uma chave pública correspondente. Cada uma dessas chaves pode descriptografar dados que a outra chave criptografar. Em geral, um desenvolvedor usa a criptografia assimétrica para criptografar uma chave simétrica para armazenamento em um banco de dados. No SQL Server 2005, chaves assimétricas são pares de chaves pública e privada. A chave pública não tem um formato específico como um certificado teria, e o desenvolvedor não a exporta para um arquivo.

No SQL Server 2005, os certificados e chaves assimétricas possuem funções intercambiáveis. Um desenvolvedor pode criptografar chaves assimétricas usando os dois métodos a seguir:

  • Uma chave de usuário é derivada de uma senha fornecida pelo usuário

  • Chave mestre de banco de dados

Chave simétrica

Uma chave simétrica é uma chave simples usada tanto para criptografar quanto para descriptografar. As operações de criptografia e descriptografia são realizadas rapidamente com a criptografia simétrica. Por conseguinte, a criptografia simétrica é bastante apropriada para criptografar uma grande quantidade de dados no SQL Server 2005.

No SQL Server 2005, um desenvolvedor pode criptografar uma chave simétrica usando um ou mais dos seguintes métodos:

  • Chave pública de um certificado

  • Senha fornecida por usuário

  • Outra chave simétrica

  • Uma chave assimétrica

    Observação: a chave simétrica não é armazenada no banco de dados. Apenas os valores criptografados da chave simétrica são armazenados no banco de dados. Portanto, os usuários que podem acessar o banco de dados não pode descriptografar dados sem primeiramente descriptografar a chave simétrica.

Quando um desenvolvedor criptografar chaves simétricas usando outras chaves simétricas, precisará abrir as chaves na ordem correta. A ordem correta é dos níveis superiores da hierarquia de criptografia para os níveis inferiores, um nível de cada vez. O desenvolvedor deve seguir a ordem correta porque não pode abrir e descriptografar uma chave simétrica sem primeiramente abrir e descriptografar a chave com a qual a chave específica foi criptografada. Os desenvolvedores devem manter essa ordem em mente quando desenvolvem a hierarquia de chaves de criptografia no banco de dados.

FeedStore

O FeedStore é um aplicativo interno criado pelo grupo Enterprise Data Services. Esse aplicativo extrai dados de 39 fontes internas e gera dados de aproximadamente 500 aplicativos inscritos em todo o mundo. O FeedStore recebe dados utilizando todos os métodos a seguir:

  • Servidores vinculados

  • Parceiros de replicação

  • Arquivos planos

O FeedStore processa esses dados para criar conjuntos de dados padronizados para submeter a servidores de distribuição. Essas informações são passadas como tabelas completas ou parciais para aplicativos inscritos por meio dos métodos a seguir:

  • Aplicativo personalizado interno da rede corporativa da Microsoft

  • Replicação de envio de SQL Server da extranet da Microsoft

Os Enterprise Data Services confirmaram que os dados confidenciais estavam duplicados por todo o espaço do aplicativo LOB da TI da Microsoft no decorrer dos negócios. Por exemplo, os dados são enviados para o FeedStore. O FeedStore envia esses dados para aproximadamente 500 inscritos. Em seguida, os aplicativos LOB da TI da Microsoft enviam dados a partir desses inscritos. Em função desse processo, uma cópia dos dados confidenciais reside no FeedStore e uma outra cópia reside no assinante local. A Figura 6 ilustra o fluxo de dados pelos aplicativos da TI da Microsoft.

Figura 6. Fluxo de dados pelos aplicativos da TI da Microsoft

Figura 6. Fluxo de dados pelos aplicativos da TI da Microsoft

Além disso, os Enterprise Data Services observaram que dados foram duplicados pela seguinte maneira: Dados relativos aos negócios são submetidos ao SAP, FeedStore e outros bancos de dados. Esses bancos de dados consolidam os dados em um outro armazém de dados do qual os dados são exportados para o FeedStore e para outros bancos de dados. Vários aplicativos LOB acessam esses dados de outros bancos de dados além do FeedStore. Além disso, o FeedStore distribui esses dados entre outros locais. Em todos esses processos os dados são armazenados em vários locais e, em seguida, copiados para vários locais. Os dados são movimentados entre os bancos de dados do SQL Server, locais de arquivos planos e outros armazenamentos proprietários. Desses locais, os dados podem ser acessados por processos em lotes, aplicativos e usuários.

Os Enterprise Data Services determinaram que o mesmo dado pode ser usado por um conjunto diverso de usuários ou em uma ou mais contas de usuários em qualquer momento específico, no sistema. Por exemplo, um aplicativo pode usar um subsistema confiável para acessar dados. Nesse cenário, um aplicativo pode autorizar um usuário a acessar um dado específico. No entanto, após a autorização bem-sucedida do usuário, o aplicativo na verdade recupera os dados relevantes usando as credenciais da conta de serviço na qual o aplicativo particular é executado. A Figura 7 ilustra esse processo de autorização.

Figura 7. Exemplo de processo de autorização

Figura 7. Exemplo de processo de autorização

Estratégia do FeedStore

Os Enterprise Data Services determinaram que, como em vários outros ambientes corporativos, os dados confidenciais eram duplicados e armazenados em vários locais no espaço de aplicativo LOB. Uma resposta inicial a esse tipo de descoberta pode ser aplicar criptografia a todo local que abrigar dados confidenciais. Essa ação deve fornecer um alto nível de segurança aos dados confidenciais. Contudo, o custo de criptografar cada bit de dados em cada local de armazenamento seria enorme.

Os Enterprise Data Services determinaram que consolidar e criptografar dados confidenciais em um armazenamento distinto seria a estratégia mais econômica e mais adequada para atender aos requisitos governamentais reguladores e aos requisitos de segurança da informação da Microsoft. Essa estratégia envolve a consolidação e a remoção de dados.

Consolidação de dados

A consolidação de dados confidenciais em um armazenamento central ajuda a reduzir a duplicação de dados. Além disso, manter todos os dados confidenciais em um único armazenamento facilita a aplicação de uma estrutura de criptografia aos dados. Por meio do uso de um armazenamento central de dados confidenciais, todos os problemas relativos à segurança, como gerenciamento de chave, autorização, autenticação e auditoria são manipulados em um único local central. Desse modo, a TI da Microsoft não precisaria impor grandes alterações de bancos de dados a todos os aplicativos LOB que lidam com dados confidenciais para criptografar localmente esses dados confidenciais. A Figura 8 mostra o fluxo de dados que os Enterprise Data Services propuseram para ajudar a proteger dados confidenciais por meio do espaço de aplicativo LOB da TI da Microsoft.

Figura 8. Fluxo de dados proposto para todos os aplicativos da TI da Microsoft

Figura 8. Fluxo de dados proposto para todos os aplicativos da TI da Microsoft
Remoção de dados

A TI da Microsoft reexamina os aplicativos LOB para identificar se esses aplicativos requerem acesso a dados confidenciais. Para aplicativos que não requerem acesso a dados confidenciais, a TI da Microsoft reconfigura a alimentação para remover os dados confidenciais. Esse processo não só é menos dispendioso que a criptografia de dados, como também segue a melhor prática de segurança de privilégio mínimo—assegurando que os dados confidenciais sejam acessados à medida que se torne necessário conhecê-los. O processo para modificar alguns ou todos os aplicativos LOB da TI da Microsoft para remover algumas ou todas as informações identificáveis já está em andamento por toda a TI da Microsoft.

Com relação aos aplicativos que requerem acesso a dados confidenciais, os Enterprise Data Services determinaram que criptografar esses dados seria mais dispendioso que reconfigurar o aplicativo para obter os dados confidenciais de um armazenamento criptografado separado. No entanto, em alguns casos, não é possível reconfigurar o aplicativo particular para obter os dados confidenciais de um armazenamento separado. Nesse cenário, o aplicativo LOB deve ser reconfigurado para criptografar localmente os dados confidenciais.

O desafio da estratégia de consolidação de dados é como manter os dados confidenciais verdadeiramente disponíveis. Os Enterprise Data Services tiveram que considerar os seguintes desafios:

  • Os departamentos BUIT (Business unit IT, Unidade de negócios de TI) da TI da Microsoft possuem desempenho específico e requisitos de tolerância a falhas. Um armazenamento criptografado centralizado deve ser suficientemente responsivo e deve ter alta disponibilidade para atender a esses requisitos.

  • A carga aumentada do processador exigida pela criptografia pode retardar processos a um ponto em que o armazenamento criptografado centralizado se torne inutilizável.

  • Os departamentos BUIT dentro da TI da Microsoft teriam que alterar seus aplicativos para obter informações de identificação pessoal altamente confidenciais do armazenamento criptografado centralizado.

  • Talvez não seja exeqüível proceder à reengenharia de todos os aplicativos LOB para usar um armazenamento criptografado centralizado. Os aplicativos LOB podem executar determinados processos em que informações de identificação pessoal altamente confidenciais sejam armazenadas e copiadas em vários locais para processamento de negócios.

  • Um armazenamento criptografado centralizado deve fornecer mecanismos de criptografia, descriptografia, autenticação, autorização, retenção de dados e de recuperação de dados.

Piloto do Digital Asset Store

Como ponto de partida para a meta de aumentar a conformidade reguladora e a segurança corporativa, os Enterprise Data Services desenvolveram um projeto piloto para criar um armazenamento criptografado centralizado usando os novos recursos e funcionalidades de criptografia do SQL Server 2005. Os Enterprise Data Services denominaram esse armazenamento centralizado de Digital Asset Store. A finalidade do serviço Digital Asset Store é integrar-se ao aplicativo FeedStore para ajudar a remover informações de identificação pessoal altamente confidenciais do aplicativo FeedStore e a ampliar a segurança de dados confidenciais no espaço de aplicativo LOB da TI da Microsoft.

Os Enterprise Data Services determinaram que, até mesmo como produto beta, o SQL Server 2005 era suficientemente sólido e possuía os recursos e funcionalidades necessários para atender aos requisitos do serviço do Digital Asset Store. Os Enterprise Data Services constataram que as soluções personalizadas de criptografia existentes eram muito dispendiosas. Milhões de dólares eram gastos em soluções personalizadas que tinham reutilização limitada. Além disso, os Enterprise Data Services determinaram que as soluções de criptografia existentes, de terceiros, eram excessivamente dispendiosas em termos de custo, integração, manutenção e problemas de suporte.

Requisitos de negócios

Antes de o grupo Enterprise Data Services implementar o piloto do Digital Asset Store, o grupo criou uma série de requisitos de negócios. Esses requisitos listavam metas e objetivos que os Enterprise Data Services usavam para determinar se o piloto do Digital Asset Store era bem-sucedido. Os Enterprise Data Services tinham as seguintes metas de recursos específicas para o serviço do Digital Asset Store:

  • Fornecer serviços de criptografia, descriptografia, autenticação e autorização, juntamente com serviços de retenção de dados e de recuperação de dados.

  • Fornecer um método para preencher campos em trocas de documentos de negócio-a-negócio com dados confidenciais em tempo de execução. Esse método é também conhecido como tradução embutida.

  • Fornecer um plano de migração para mover dados confidenciais para o Digital Asset Store.

Os Enterprise Data Services criaram também os objetivos básicos de negócios a seguir, para o Digital Asset Store:

  • Fazer com que os orçamentos de aplicativo LOB da TI da Microsoft incluíssem financiamento para migração de informações de identificação pessoal altamente confidenciais no Digital Asset Store.

  • Reduzir o custo da migração de informações de identificação pessoal altamente confidenciais para o Digital Asset Store. Especificamente, reduzir esse custo para menos que o custo de criptografar dados localmente em todos os aplicativos LOB da TI da Microsoft. Portanto, os Enterprise Data Services visavam a um custo final de aproximadamente US$ 10.000, ou menos, para modificar todos os aplicativos LOB para que usassem o Digital Asset Store.

Para determinar quais informações seriam movidas para o Digital Asset Store, os Enterprise Data Services tiveram primeiramente que classificar as informações atuais em um contexto de segurança. Em função dos custos envolvidos tanto em mover como em criptografar dados, a Microsoft e outras empresas precisam determinar cuidadosamente quais informações são confidenciais o bastante para exigir criptografia.

Criar um armazenamento criptografado separado para abrigar dados confidenciais requer planejamento e monitoração cuidadosas para assegurar que os dados confidenciais estejam disponíveis para os aplicativos solicitadores. Os dados confidenciais devem permanecer nos armazéns de dados não-criptografados até que os aplicativos inscritos possam ser modificados para obterem esses dados do armazenamento criptografado.

Observação: em alguns casos, um aplicativo LOB específico não pode ser reconfigurado para obter os dados confidenciais de um armazenamento criptografado. Nesse cenário, o aplicativo LOB deve ser reconfigurado para usar recursos como a criptografia em nível de coluna do SQL Server 2005 para criptografar localmente os dados confidenciais.

Implementação

Os Enterprise Data Services determinaram que os recursos relativos à segurança do SQL Server 2005 tornariam o projeto piloto do Digital Asset Store um sucesso. Para implementar o Digital Asset Store, os Enterprise Data Services determinaram que seria necessário realizar as ações a seguir no espaço de aplicativo LOB da TI da Microsoft, com relação ao FeedStore:

  • Identificar elementos de dados confidenciais que existem no espaço de aplicativo ?LOB.

  • Remover elementos de dados confidenciais de aplicativos LOB que não requerem essas informações.

  • Mover informações de identificação pessoal altamente confidenciais para o Digital Asset Store.

  • Criptografar informações de identificação pessoal altamente confidenciais no Digital Asset Store.

  • Ajudar a proteger informações de identificação pessoal altamente confidenciais à medida que se movimentam entre aplicativos.

Para implementar o serviço do Digital Asset Store, os Enterprise Data Services determinaram que seria necessário configurar editores que enviassem dados confidenciais para o Digital Asset Store. No entanto, os editores continuariam a enviar dados não-confidenciais para o FeedStore.

O FeedStore recebe alimentações de dados usando a replicação, operações de extração de dados do SQL Server de servidores vinculados e operações de coleta de locais de arquivos planos. O Digital Asset Store forneceria criptografia para os dados em repouso (dados que não estão sendo transferidos nem acessados) no Digital Asset Store. Contudo, os dados confidenciais repousariam também em um local de arquivo plano que é, presentemente, usado para enviar dados para o Digital Asset Store. Os Enterprise Data Services determinaram que um local de arquivo plano apresenta um link inaceitável na transferência de dados para o Digital Asset Store. A Figura 9 mostra o local do arquivo plano na estrutura de alimentação de dados atual do FeedStore.

Figura 9. Estrutura de alimentação de dados atual do FeedStore

Figura 9. Estrutura de alimentação de dados atual do FeedStore

Em vez de desenvolver um método para criptografar os dados em locais planos, os Enterprise Data Services optaram por permitir somente um método de transferência de banco de dados para banco de dados. Nesse cenário, o Digital Asset Store obteria dados usando um mecanismo de transporte de dados para obter pontos únicos menores de dados em vez dos conjuntos grandes de dados que se encontram nos transportes para o FeedStore. A Figura 10 mostra a estrutura de alimentação de dados proposta para o Digital Asset Store.

Figura 10. Estrutura de alimentação de dados proposta para o Digital Asset Store

Figure 10. Estrutura de alimentação de dados proposta para o Digital Asset Store
1quote.gifOs recursos de criptografia e segurança do SQL Server 2005 permitem que a TI da Microsoft implemente facilmente uma estrutura de criptografia sem ter que se preocupar com o gerenciamento da chave de criptografia.2quote.gif Devendra TiwariMicrosoft Corporation

Os recursos de criptografia do SQL Server 2005 são desenvolvidos para criptografar dados em repouso. Os dados armazenados no Digital Asset Store seriam criptografados. A transferência de dados entre os aplicativos e o Digital Asset Store seria realizada pela passagem de dados descriptografados (texto simples) por um túnel criptografado. A TI da Microsoft determinou que essa abordagem seja recomendada como melhor prática para a transferência de dados entre bancos de dados. Nessa abordagem, as chaves de criptografia não são compartilhadas entre sistemas. Além disso, os dados em repouso são criptografados por meio da estrutura de criptografia que está presente em todos os sistemas. A Figura 11 ilustra essa transferência de dados.

Figura 11. Método recomendado para a transferência de dados confidenciais

Figura 11. Método recomendado para a transferência de dados confidenciais

Na Figura 11, dados de texto simples são transferidos por um canal criptografado entre dois computadores que executam o SQL Server 2005. Nessa situação, ocorrem as ações a seguir:

  1. Os dados armazenados (dados em repouso) no Servidor 1 são criptografados por meio da Chave 1 de criptografia.

  2. Esses dados são descriptografados por meio da Chave 1 antes de os dados serem transferidos por um canal criptografado para o Servidor 2.

  3. Os dados são criptografados no Servidor 2 por meio de uma chave de criptografia (Chave 2) gerada pelo Servidor 2.

Para realizar essas ações usando um processo que é executado no Servidor 2, o processo particular deve descriptografar os dados do Servidor 1 usando a Chave 1; copiar os dados descriptografados no Servidor 2, e, em seguida, criptografar os dados do Servidor 2 por meio da Chave 2. Para realizar essas ações, a conta em que o processo é executado deve ter todos os direitos de usuário a seguir:

  • Exibir a definição das chaves para criptografar e descriptografar dados

  • Exibir a definição dos certificados para criptografar e descriptografar dados

  • Controlar permissões do certificado para descriptografar os dados

    Observação: a criptografia do SQL Server 2005 é desenvolvida para criptografar dados em repouso. Assim sendo, se uma organização decidir transferir texto codificado entre computadores que executam o SQL Server 2005, não deverá usar a criptografia do SQL Server 2005 como estrutura única de segurança dos dados quando os mesmos estiverem em trânsito. A organização deverá também usar outros métodos para ajudar a proteger esses dados transmitidos, como o IPsec (Internet Protocol security, Segurança do protocolo de Internet) ou SSL (Secure Sockets Layer, Camada de soquetes seguros). Embora o SQL Server 2005 forneça uma criptografia sólida, os dados em trânsito estão sujeitos a ataques, como ataques de análises estatísticas, ataques criptoanalíticos ou ataques de resposta. Assim, é recomendável que a organização criptografe o canal de transporte mesmo que transfira dados criptografados.

Os assinantes do FeedStore teriam que ser modificados para obter informações de identificação pessoal altamente confidenciais do Digital Asset Store. Para reduzir a duplicação de dados e seguir a melhor prática de segurança de privilégio mínimo, os Enterprise Data Services determinaram que implementariam um procedimento de alto desempenho para inserção de dados confidenciais na alimentação de dados de negócio-a-negócio em tempo de execução. Os Enterprise Data Services desenvolveram, portanto, a técnica que denominam tradução embutida. Com a tradução embutida, ocorrem as seguintes ações:

  1. Pesquisa de pontos de dados, como números de previdência social em uma alimentação de entrada em chaves como números de pessoal.

  2. Descriptografia dos dados.

  3. Inserção dos dados na alimentação, como especificado.

Por exemplo, um aplicativo pode gerar uma alimentação de dados que contenha números de previdência social. Essa alimentação de dados é enviada a uma instituição financeira de terceiros. Contudo, o ambiente que gera essa alimentação de dados pode não requerer acesso aos números de previdência social. Nessa situação, o número de segurança social não deve existir no ambiente que gera a alimentação se o número de previdência social puder ser inserido na alimentação para a instituição financeira de terceiros. A tradução embutida reduz o número de instâncias em que os dados confidenciais são acessados, armazenados e transmitidos. Além disso, a tradução embutida usa um armazenamento criptografado distinto para abrigar os dados confidenciais.

Processo de criptografia do Digital Asset Store

Os Enterprise Data Services determinaram que o Digital Asset Store usaria um mecanismo de criptografia híbrida. Assim sendo, os dados que são enviados para o Digital Asset Store seriam criptografados por meio da criptografia interna do SQL Server 2005 e de uma chave simétrica. Em seguida, o SQL Server 2005 criptografaria essa chave simétrica usando criptografia baseada em certificado. A Figura 12 mostra o processo de criptografia do Digital Asset Store como os Enterprise Data Services pretendiam implementá-lo.

Figura 12. Processo de criptografia do Digital Asset Store

Figura 12. Processo de criptografia do Digital Asset Store

Para transferir dados do Digital Asset Store para um assinante ou processamento de assinante, o processo de criptografia é invertido. O SQL Server 2005 descriptografaria a chave simétrica usando a criptografia baseada em certificado. O SQL Server 2005, em seguida, descriptografaria os dados por meio da chave simétrica descriptografada. Os dados descriptografados seriam processados por um processo de assinante, e, em seguida, dissipados (excluídos), ou os dados descriptografados seriam enviados por um canal criptografado para um assinante. O assinante criptografaria esses dados usando a criptografia interna do SQL Server 2005. A Figura 13 mostra o processo de descriptografia do Digital Asset Store como os Enterprise Data Services pretendiam implementá-lo.

Figura 13. Processo de descriptografia do Digital Asset Store

Figura 13. Processo de descriptografia do Digital Asset Store

A implementação do projeto piloto do Digital Asset Store forneceu à TI da Microsoft informações valiosas sobre implementação com relação a outros projetos de consolidação de dados e criptografia no espaço de aplicativo LOB da TI da Microsoft. O SQL Server 2005 oferece à TI da Microsoft aprimoramentos de protocolo para autenticação, permissões granulares aperfeiçoadas e um mecanismo interno de criptografia para ajudar a manter a confidencialidade e a integridade de dados confidenciais.

Sistema de relatórios de controles de folha de pagamento

Os funcionários da Microsoft baseados nos Estados Unidos usam o aplicativo PCRS para gerar a contabilidade da folha de pagamento, operações de folha de pagamento e relatórios dos benefícios pertinentes.

O aplicativo PCRS é essencialmente um armazém de dados de folha de pagamento. Esse banco de dados guarda 350 GB (gigabytes) de dados e contém informações de folha de pagamentos relativas a todos os funcionários da Microsoft baseados nos Estados Unidos. O PCRS usa trabalhos em lote para obter informações do FeedStore e do SAP quase diariamente. O PCRS armazena essas informações em um banco de dados, calcula valores desses dados e, em seguida, preenche o banco de dados de relatórios do PCRS por meio desses valores calculados. Após o armazenamento dos valores calculados no banco de dados de relatórios, as operações de folha de pagamento e contabilidade da Microsoft podem gerar relatórios relativos à folha de pagamento por meio de programas como o Microsoft Access ou o Microsoft Excel® A Figura 14 ilustra o fluxo de dados por meio do PCRS.

Figura 14. Fluxo de dados do Sistema de relatórios de controles da folha de pagamento

Figura 14. Fluxo de dados do Sistema de relatórios de controles da folha de pagamento

Estratégia do sistema de relatórios de controles da folha de pagamento

Para assegurar conformidade com os regulamentos governamentais relativos às informações de identificação pessoal, e para assegurar a conformidade com os requisitos de segurança corporativos da Microsoft, o departamento de TI da Área Financeira determinou que o aplicativo PCRS seria modificado para usar a criptografia do SQL Server 2005, visando à proteção de dados confidenciais. Além disso, como o PCRS recebe dados confidenciais de vários locais, e como há necessidade de se realizar processamento adicional desses dados confidenciais, a TI da Área Financeira determinou que a criptografia deve ser implementada no banco de dados PCRS local, em vez de ser implementada em armazenamento criptografado independente.

Somente um pequeno número de colunas do banco de dados PCRS exigiu criptografia. No entanto, a estratégia de criptografia da TI da Área Financeira envolveria também a criação de uma estrutura de gerenciamento de chave do SQL Server 2005 e a modificação de procedimentos armazenados para acesso a dados criptografados no PCRS. A TI da Área Financeira não acreditou que modificar o aplicativo PCRS para incluir a criptografia em nível de coluna do SQL Server 2005 fosse um procedimento complexo. No entanto, a TI da Área Financeira estava preocupada com o backup, com a restauração e com a realização de manutenção contínua da hierarquia de chave de criptografia do SQL Server 2005. Conseqüentemente, antes de a TI da Área Financeira implementar essa estratégia em um ambiente de produção, implementou um protótipo de banco de dados para testar e garantir o backup, a manutenção e a restauração bem-sucedidos das chaves de criptografia do SQL Server 2005. Além disso, como a indexação não funciona em colunas criptografadas, a TI da Área Financeira teria que localizar e remover índices de colunas que exigissem criptografia.

Piloto de Sistema de relatórios de controles da folha de pagamento

O departamento de TI da Área Financeira definiu uma data alvo para implementar a criptografia do SQL Server 2005 em nível de coluna no aplicativo PCRS. Contudo, antes que a TI da Área Financeira implementasse essa solução de criptografia no ambiente de produção, criou um protótipo de banco de dados que continha dados de exemplo criptografados para garantir que a hierarquia de chave de criptografia do SQL Server 2005 fosse submetida a backup, restaurada e mantida com sucesso no ambiente de produção.

A TI da Área Financeira criou um banco de dados de exemplo denominado PCRS_Encryption para testar a estratégia de criptografia do aplicativo PCRS. Esse banco de dados continha dados confidenciais de exemplo juntamente com procedimentos armazenados para submissão de dados confidenciais ao banco de dados e para obtenção de dados confidenciais do banco de dados. O acesso ao banco de dados baseava-se na segurança fundamentada em funções do SQL Server 2005. A Figura 15 ilustra essa arquitetura de banco de dados.

Figura 15. Banco de dados de exemplo do Sistema de relatórios de controles da folha de pagamento

Figura 15. Banco de dados de exemplo do Sistema de relatórios de controles da folha de pagamento

Para implementar e testar essa configuração de banco de dados, a TI da Área Financeira usou as etapas a seguir para criar uma hierarquia de chave de criptografia simples, porém robusta, para o SQL Server 2005:

  1. Criar a chave mestre do banco de dados.

  2. Regerar a chave mestre de serviço. Essa etapa foi uma precaução de segurança a mais, para garantir que a chave mestre de serviço não ficasse comprometida.

  3. Criar um certificado com assinatura automática para o SQL Server 2005.

  4. Criar uma chave simétrica. Criptografar essa chave usando o certificado do SQL Server 2005.

Em seguida, o departamento de TI da Área Financeira usou as etapas abaixo para modificar o esquema do banco de dados para criptografar dados confidenciais na tabela:

  1. Criar uma nova tabela com a mesma estrutura da tabela original, sendo que a coluna de dados confidenciais deveria ser do tipo de dados varbinary.

  2. Abrir a chave simétrica.

  3. Realizar uma consulta SELECT INTO para copiar dados da tabela existente na tabela recentemente criada para criptografar os dados confidenciais.

  4. Fechar a chave simétrica aberta.

  5. Descartar a tabela original.

  6. Renomear a tabela criada recentemente com o nome da tabela original.

  7. Remover todos os índices das colunas criptografadas, se aplicável.

A TI da Área Financeira, em seguida, atualizou os procedimentos armazenados para usar a função EncryptByKey() e a função DecryptByKey() para acessar os dados criptografados. A atualização incluiu as seguintes etapas:

Observação: para obter mais informações sobre essas funções, consulte "Apêndice: Cenários de uso de criptografia", posteriormente neste documento.

  1. Abrir a chave simétrica.

  2. Use a função EncryptByKey() ou a função DecryptByKey() para criptografar ou descriptografar dados da coluna que contém os dados confidenciais.

  3. Fechar a chave simétrica aberta.

A TI da Área Financeira, após completar as etapas precedentes, configurou permissões nas funções do SQL Server para a concessão de permissões à chave simétrica para a função que requeria acesso a dados criptografados e para negar permissões à chave simétrica para a função que não deveria ter acesso aos dados criptografados.

Após a TI da Área Financeira configurar com sucesso o banco de dados de exemplo para oferecer suporte à criptografia de dados confidenciais, submeteu a backup a chave mestre do banco de dados, o certificado do SQL Server 2005 e a chave simétrica com a qual os dados foram criptografados. Como os dados criptografados foram, em seguida, armazenados no banco de dados, a TI da Área Financeira determinou que precisava usar o procedimento a seguir para submeter o banco de dados a backup:

  1. Efetuar backup das chaves de criptografia do SQL Server 2005 por meio dos comandos de Transact-SQL correspondentes do SQL Server 2005.

  2. Efetuar backup do banco de dados do SQL Server 2005 que contém os dados criptografados.

  3. Registrar o backup da chave de criptografia que corresponde ao backup do banco de dados particular.

Quando uma organização restaura um banco de dados que contém dados criptografados, precisa ter as chaves de criptografia que foram usadas para criptografar os dados armazenados. Se uma organização altera regularmente as chaves de criptografia para cumprir com requisitos corporativos de segurança, deve garantir que tenha chaves de criptografia que possam descriptografar os dados de um backup particular.

Para restaurar um banco de dados que contenha dados criptografados, uma organização deve seguir etapas adicionais para assegurar que os dados criptografados possam ser descriptografados. Após o banco de dados ser restaurado, a organização deve descriptografar a chave mestre do banco de dados. Em seguida, precisa criptografar a chave mestre do banco de dados por meio da chave mestre de serviço. Para descriptografar a chave mestre do banco de dados, a organização deve usar a senha com a qual criptografou a chave mestre do banco de dados quando o mesmo usava os comandos Transact-SQL do SQL Server 2005 para efetuar backup da chave.

Embora a meta específica da TI da Área Financeira fosse desenvolver e implementar uma estratégia de criptografia para o aplicativo PCRS, o departamento também possuía uma meta mais ampla. Essa meta era criar uma solução prescrita que outros departamentos de TI dentro da TI da Microsoft pudessem usar para implementar criptografia em aplicativos LOB locais.

Ainda que a TI da Área Financeira usasse apenas dados de exemplo contidos no banco de dados PCRS_Encryption, o aplicativo PCRS possuía várias semelhanças com outros aplicativos LOB dentro da TI da Microsoft. Portanto, a TI da Área Financeira testou o banco de dados PCRS_Encryption em vários cenários reais para determinar se as diretrizes de backup e restauração funcionariam em outros departamentos de TI, além da TI da Área Financeira. A TI da Área Financeira não experimentou nenhum problema de desempenho relativo ao processo de criptografia ou ao processo de descriptografia durante esse teste. O processo de criptografia e descriptografia era transparente para os funcionários da Microsoft que usaram o banco de dados de exemplo.

1quote.gifO SQL Server 2005 integra essencialmente a segurança E2E do aplicativo PCRS.2quote.gif Steven DevinMicrosoft Corporation

Metropolis

Metropolis é um aplicativo de serviço ao cliente e de suporte técnico que o departamento de TI de Serviços criou. Esse aplicativo consiste em uma ferramenta front-end criada por meio do Microsoft Win32® API, uma segunda camada de serviços de Web baseada em XML (Extensible Markup Language, Linguagem de marcação estendida), e uma terceira camada baseada no SQL Server 2005.

A Microsoft apóia profissionais que usam a ferramenta front-end para ajudar a direcionar e a solucionar chamadas de assistência técnica. Juntamente com outras funcionalidades relacionadas ao suporte, como a criação de solicitações de serviço e operações de pesquisa para localizar técnicos de suporte disponíveis, essa ferramenta habilita a equipe de suporte a acessar compartilhamentos de arquivos e outros locais que contêm dados confidenciais, como chaves de produto e senhas.

1quote.gifA abordagem da criptografia de dados do SQL Server 2005 habilita nossa infra-estrutura a fornecer um ponto único de obtenção de dados confidenciais. Armazenar segredos de forma segura em um banco de dados torna o trabalho com dados confidenciais tão simples para os nossos desenvolvedores de aplicativos como lidar com qualquer outro dado, embora fornecendo uma tecnologia moderna de criptografia para proteger nosso ativo mais valioso".2quote.gif Brad UhrichMicrosoft Corporation

Quando o departamento de TI de Serviços criou o aplicativo Metropolis, o departamento de TI de Serviços, assim como vários outros departamentos de TI da empresa, teve que cumprir exigências de segurança corporativa que afetam o armazenamento de dados confidenciais, como chaves de produto e senhas. Em geral, os dados confidenciais são armazenados em um compartilhamento de arquivo criptografado ou em um local compartilhado onde as listas de controle de acesso são definidas para limitar o acesso do usuário aos dados confidenciais. O principal problema dessa abordagem é que, quando uma organização ajuda a proteger dados confidenciais usando uma senha ou um segredo, precisa proteger essa senha ou segredo. Por exemplo, pode criptografar informações usando a frase secreta. A organização deve, em seguida, proteger essa frase secreta com outra senha ou segredo. Essa abordagem pode levar a uma série de senhas em cascata ou a mecanismos de criptografia.

Os requisitos de segurança corporativos da Microsoft permitem o uso de DPAPI para atuar como mecanismo de segurança de dados confidenciais. Um dos motivos para essa diretiva é que a conta que usa a DPAPI deve ser registrada em um computador local.

O departamento de TI de Serviços determinou que a hierarquia de gerenciamento de chave interna do SQL Server 2005 não apenas satisfaria as exigências de segurança corporativa da Microsoft, como também habilitaria o departamento de TI de Serviços a criar um mecanismo simples para permitir acesso a dados confidenciais nos bancos de dados Metropolis. Por conseguinte, o departamento de TI de Serviços criou um banco de dados administrativo para guardar dados confidenciais. Esse banco de dados administrativo é conhecido como banco de dados de ambiente. O banco de dados mantém todos os dados confidenciais que são exigidos para a manutenção do banco de dados Metropolis, ou seja, nomes de servidores, locais de compartilhamento de arquivo, credenciais e chaves criptográficas. O departamento de TI de Serviços configurou a criptografia em nível de coluna do SQL Server 2005 para criptografar todos os dados confidenciais nesse banco de dados.

O departamento de TI de Serviços determinou que o banco de dados Metropolis de ambiente deve atender às seguintes condições:

  • Os usuários com baixo nível de permissões de segurança podem criptografar dados no banco de dados de ambiente.

  • Somente usuários com permissões de segurança de nível suficientemente alto podem descriptografar dados no banco de dados de ambiente.

O departamento de TI de Serviços determinou que os recursos de criptografia do SQL Server 2005 habilitariam-no a criar uma estrutura simples, embora robusta, para atender às duas condições precedentes. Para criar essa estrutura de segurança de criptografia, a TI de Serviços criou a hierarquia de chave de criptografia híbrida do SQL Server 2005 ilustrada pela Figura 16.

Figura 16. Hierarquia de chave de criptografia do Metropolis

Figura 16. Hierarquia de chave de criptografia do Metropolis

Ao usar a DPAPI para criptografar a chave mestre de serviço do SQL Server 2005, TI de Serviços garantiu que essa estrutura de chave de criptografia atendesse aos requisitos de segurança corporativos da Microsoft. Além disso, ao usar um esquema de criptografia híbrido, o departamento de TI de Serviços obedeceu às práticas recomendadas de criptografia da TI da Microsoft. Uma chave simétrica é usada para criptografar dados, aproveitando a velocidade da criptografia simétrica. Um método de criptografia assimétrica é usado para criptografar a chave simétrica, aproveitando a segurança aumentada da criptografia assimétrica sobre a criptografia simétrica.

No entanto, a parte interessante da estrutura de criptografia de TI de Sistemas é que a estrutura usa um certificado para assinar digitalmente o procedimento armazenado que criptografa dados. Ao usar a chave privada do certificado do SQL Server 2005 para assinar digitalmente o procedimento armazenado, o usuário que não tem permissões para o certificado pode usar o procedimento armazenado para descriptografar a chave simétrica e criptografar dados no banco de dados de ambiente. Contudo, um usuário que deseje descriptografar a chave simétrica para descriptografar dados no banco de dados de ambiente deve ter permissões mestre de chave.

Ao usar um certificado de SQL Server para criptografar a chave simétrica, e ao usar esse certificado para assinar digitalmente o procedimento armazenado que criptografa dados no banco de dados de ambiente, o departamento de TI de Serviços pôde configurar uma estrutura de permissões em que qualquer usuário pode criptografar dados no banco de dados. Entretanto, somente determinados usuários podem descriptografar esses dados.

O departamento de TI de Serviços implementou a estrutura de criptografia do Metropolis em um ambiente de produção com grande sucesso. O processo de criptografia é transparente para os profissionais de serviço que usam esse sistema. Além disso, o departamento de TI de Serviços planeja expandir o uso dessa estrutura de criptografia para incluir outros bancos de dados no aplicativo LOB do Metropolis.

Práticas recomendadas

A TI da Microsoft possui vários projetos piloto relativos à criptografia do SQL Server 2005 em andamento no espaço de aplicativo LOB da TI da Microsoft. Conseqüentemente, a TI da Microsoft obteve grande experiência com as técnicas de criptografia do banco de dados do SQL Server 2005. Essa experiência levou a uma lista de melhores práticas. Outras organizações podem usar essas melhores práticas para ajudar a simplificar a tarefa de aprimorar a segurança do banco de dados para que sejam cumpridos os requisitos da legislação do governo, e para atender aos requisitos de seus departamentos de segurança corporativa.

O gerenciamento de chave é essencial para a estrutura de criptografia

O SQL Server 2005 inclui recursos e funcionalidades para criptografar e descriptografar dados sem necessidade de lidar com os ínfimos detalhes dos algoritmos de criptografia. Porém, um dos principais benefícios da criptografia do SQL Server 2005 é que o SQL Server 2005 pode gerenciar as chaves de criptografia.

São estas as recomendações da TI da Microsoft para a geração de chave:

  • Criar sempre um backup por meio de uma senha forte para a chave mestre de serviço.

  • Usar uma senha forte quando criar uma chave mestre de banco de dados. Essa senha deve estar sujeita à diretiva de verificação de senha local, e o SQL Server 2005 precisa ser configurado para verificar a força da senha. Além disso, criptografar essa senha usando tanto certificados quanto chaves simétricas. Efetuar backup da chave mestre de banco de dados, de modo que seja possível recuperar a chave se você a perder.

  • Usar o algoritmo de criptografia de AES com 256 bits de tamanho durante a criação de uma chave simétrica. Criptografar chaves simétricas usando o certificado do SQL Server 2005. Conceder permissões a objetos criptográficos (como certificados ou chaves) para uma parte confiável. Se uma parte confiável limitada precisar usar a chave para descriptografar ou criptografar dados, usar a cláusula EXECUTE AS em módulos para alterar a chave e os dados, em vez de conceder permissões diretamente à conta de usuário limitado.

  • Criar certificados com assinatura automática. As funções internas de criptografia e assinatura não verificam as datas de vencimento dos certificados. Por isso, teste o vencimento do certificado no aplicativo por meio de um procedimento armazenado ou lógica de camada mediana de negócios.

  • Auditar as tabelas de banco de dados que contêm dados confidenciais com regularidade, juntamente com o catálogo de chaves e certificados para determinar quem gera os certificados e chaves. Para conduzir a auditoria, monitorar essas tabelas usando um script de SQL Server e mecanismo de alerta.

São estas as recomendações da TI da Microsoft para uso de chave:

  • Não distribuir chaves de criptografia entre os servidores. Os dados devem ser criptografados e descriptografados no mesmo computador. Portanto, não é necessário, em geral, transferir as chaves de criptografia para um outro computador.

  • Ao abrir chaves de criptografia durante uma operação de criptografia e descriptografia, fechar sempre as chaves da mesma sessão.

São estas as recomendações da TI da Microsoft para backup de chave:

  • Efetuar backup da chave privada do certificado e da senha usada para criptografar a chave privada do certificado.

  • Efetuar backup da chave mestre de banco de dados por meio da instrução DUMP.

  • Mover a chave mestre de serviço para um arquivo, e, em seguida, efetuar backup do arquivo.

São estas as recomendações da TI da Microsoft para a regeneração de chave:

  • Regerar regularmente a chave mestre de serviço porque se trata de uma chave simétrica. Essa prática ajuda a evitar a chave potencial e o vazamento de dados por intermédio de ataques de força bruta.

  • Examinar cuidadosamente o uso da opção FORCE REGENERATE. Usar a opção FORCE apenas quando for exigido, ou seja, se a regeneração falhar com regularidade. A opção FORCE faz com que o processo de regeneração de chave prossiga mesmo que o processo não possa recuperar a chave mestre atual ou não possa descriptografar todas as chaves privadas.

Limitar o uso da criptografia para dados confidenciais

Antes que uma organização implemente a criptografia do SQL Server 2005, deverá considerar o efeito do desempenho da criptografia, mesmo que uma fonte externa solicite acesso a dados criptografados, e um tamanho aumentado de texto codificado sobre texto simples. Estas são as diretrizes que a TI da Microsoft possui com relação ao uso de criptografia no SQL Server 2005:

  • Classificar cuidadosamente os dados. Em seguida, criptografar apenas os dados que requeiram a segurança ampliada que a criptografia fornece.

  • Se os dados forem criptografados somente quando estiverem armazenados no banco de dados (em repouso), e se for possível salvar e recuperar esses dados como texto simples, usar as chaves simétricas para criptografar os dados. Não criptografar chaves simétricas usando senhas, a menos que seja possível gerenciar essas chaves e senhas com cuidado. Não distribuir as chaves simétricas entre usuários e aplicativos.

  • Se você desejar criptografar uma pequena quantidade de dados, use a criptografia assimétrica. Para criptografar uma grande quantidade de dados, use uma abordagem de criptografia híbrida.

Conclusão

A TI da Microsoft começa a mover seus aplicativos LOB para o SQL Server 2005 para tirar proveito dos novos recursos relativos a desempenho e segurança disponibilizados na mais recente versão do SQL Server. A TI da Microsoft precisava responder aos novos requisitos reguladores do governo relativos às informações de identificação pessoal, juntamente com requisitos de segurança de informações da Microsoft relativos a dados confidenciais. Dessa forma, a TI da Microsoft reavaliou a estrutura de segurança que existe no espaço de aplicativo LOB da TI da Microsoft.

O aplicativo FeedStore que integra a TI da Microsoft, serve como repositório central de dados para a Microsoft. Como esse aplicativo lida com dados que podem conter informações de identificação pessoal, já existe um forte esquema de segurança para ajudar a proteger esses dados. Por conseguinte, os Enterprise Data Services decidiram elevar a estrutura de segurança do FeedStore a um nível mais alto, desenvolvendo uma estrutura de criptografia e implementando um piloto para o Digital Asset Store. Esse piloto do Digital Asset Store ajudaria a remover informações de identificação pessoal do FeedStore e do espaço de aplicativo LOB da TI da Microsoft.

O departamento de TI da Área Financeira e o departamento de TI de Serviços enfrentaram um cenário em que eles exigiram criptografia em seus aplicativos LOB locais. Cada departamento usou o SQL Server 2005 para desenvolver uma estrutura de criptografia que fosse robusta, embora simples de gerenciar.

Ao usar mecanismos internos de gerenciamento de chave e funcionalidade de criptografia em nível de coluna no SQL Server 2005, a TI da Microsoft tomou as primeiras medidas em direção à ampliação da segurança de dados no espaço de aplicativo LOB da TI da Microsoft.

Para obter mais informações

Para obter mais informações sobre os produtos e serviços da Microsoft nos EUA, ligue para (800) 426-9400. No Canadá, ligue para o Microsoft Canada Information Centre, telefone (800) 563-9048. No Brasil, entre em contato com a Microsoft Informática Ltda., telefone (11) 5853-2345. Para acessar informações na Internet, vá para:

http://www.microsoft.com/brasil/

http://www.microsoft.com/itshowcase

http://www.microsoft.com/technet/itshowcase

Para tirar dúvidas, fazer comentários e sugestões sobre este documento ou para obter informações adicionais sobre Apresentações de TI da Microsoft, envie um e-mail para:

showcase@microsoft.com

Apêndice: Cenários de uso de criptografia

Criptografando dados em repouso

Para criptografar dados em repouso usando a criptografia simétrica do SQL Server 2005, use as etapas a seguir:

  1. Criar a chave mestre do banco de dados. O SQL Server 2005 usa a chave mestre de banco de dados para criptografar a chave privada do certificado criado na etapa 2.

  2. Crie um certificado. O SQL Server 2005 usa certificados para criptografar dados ou para criptografar chaves simétricas.

  3. Crie uma chave simétrica para criptografar os dados de destino. Criptografe essa chave simétrica usando o certificado criado na etapa 2, usando uma outra chave simétrica ou usando uma senha fornecida por usuário.

  4. Abra a chave simétrica para criptografar ou descriptografar dados. Para abrir essa chave, use o mesmo mecanismo com o qual você criptografou a chave.

  5. Criptografe dados por meio da função EncryptByKey(), ou descriptografe dados por meio da função DecryptByKey(). Esses dados são armazenados neste momento como BLOB (binary large object, objeto binário grande) no banco de dados, ou os dados são descriptografados neste momento, dependendo da instrução Transact-SQL que você usou.

  6. Feche todas as chaves simétricas.

O SQL Server 2005 fornece um parâmetro opcional que é possível usar com a função EncryptByKey(), e com a função DecryptByKey() para verificar a integridade da coluna. Use esse parâmetro se desejar garantir que um usuário que tenha as permissões necessárias não substitua dois valores criptografados entre linhas de um banco de dados. Por exemplo, é possível manter informações salariais criptografadas em uma tabela de banco de dados. Embora a criptografia em nível de coluna evite que um usuário leia o salário criptografado, a criptografia em nível de coluna não evita que um usuário com as permissões necessárias troque o salário criptografado de um gerente pelo salário de um outro funcionário.

O SQL Server 2005 ajuda a proteger contra essa situação, usando um parâmetro opcional para especificar o valor de hash no momento da criptografia. Durante o processo de criptografia, é possível especificar o seguinte.

Insert into empTable values (emp1id, encryptbykey(Key1Guid, 50000, 
 emp1id))

Durante o processo de descriptografia, é possível especificar o seguinte.

Select empID, decryptbykey(salary, empID) from empTable

Nesses exemplos, a criptografia é realizada no valor de texto simples de 50000, que é concatenado com o hash do terceiro parâmetro opcional. Neste exemplo, emp1id é o terceiro parâmetro. No momento da descriptografia, o SQL Server 2005 compara o hash do terceiro parâmetro com o hash armazenado no BLOB criptografado. Se houver correspondência entre dois hashes, o SQL Server 2005 determina que o valor criptografado não foi movido entre colunas do banco de dados.

Observação: é recomendável usar a chave primária como terceiro parâmetro da função EncryptByKey() .

Acessando dados criptografados por meio de uma exibição

Há cenários atuais dentro da TI da Microsoft em que as exibições e funções fazem referência a colunas criptografadas. O SQL Server 2005 fornece a função DecryptByKeyAutoCert() para descriptografar os dados contidos nas exibições. Em um cenário em que os dados são criptografados por meio de uma chave simétrica e em que um certificado protege essa chave simétrica, essa função trabalha pesquisando a chave criptografada por intermédio do certificado que você especificar. A função DecryptByKeyAutoCert() em seguida, abre automaticamente a chave simétrica, descriptografa os dados e fecha a chave.

Observação: com relação a exibições e funções que citam uma coluna criptografada, é preciso modificar a exibição ou a função para incluir a lógica de criptografia de dados.

O script de exemplo a seguir ilustra o modo pelo qual se acessam dados criptografados por meio de uma exibição no SQL Server 2005.

Create View testview 
as 
Select Convert(varchar(100), 
  decryptbykeyautocert(cert_id('myCert1'), NULL, SSN, 0, Null)) as SSN 
From Customer

A função DecryptByKeyAutoCert() espera os argumentos a seguir:

  • O certificado ou identificação de chave assimétrica; por exemplo, myCert1.

  • A senha do certificado especificado. Neste exemplo, o certificado é criptografado por meio da chave mestre de banco de dados. Desse modo, a senha do certificado especificado é NULL.

  • O fluxo a ser descriptografado, por exemplo, coluna SSN.

  • Se bytes de autenticidade estiverem presentes. Esse parâmetro opcional possui valor de 0 ou 1.

  • Bytes para autenticidade. O valor padrão desse parâmetro opcional é NULL.

    Observação: quando se usa a função DecryptByKeyAutoCert() para pesquisar uma chave simétrica criptografada por um certificado, e se esse certificado foi usado para criptografar outras chaves simétricas, o SQL Server 2005 usa o certificado particular para examinar a estrutura de BLOB criptografada para determinar o GUID (globally unique identifier, identificador único global) chave associado ao BLOB. O SQL Server 2005, em seguida, abre apenas a chave simétrica particular que foi usada para criptografar a coluna.

Dados de inserção em massa

O script de exemplo a seguir ilustra como inserir dados em massa de um arquivo em uma tabela, e, em seguida, criptografar esses dados usando a criptografia do SQL Server 2005.

Observação: o código snippet a seguir foi exibido em várias linhas somente para se obter mais legibilidade. Deve ser inserido em uma linha exclusiva.

Create Procedure test_sp 
as 
CREATE TABLE #InsertTemp 
( 
      PN int, 
      SSN varchar(100) 
) 
BULK INSERT #InsertTemp 
   FROM 'C:\test.txt'     
TRUNCATE TABLE BulkInsertTbl 
 
OPEN SYMMETRIC KEY key1AES DECRYPTION BY CERTIFICATE myCert1 
 
INSERT INTO BulkInsertTbl (PersonnelNumber, SSN) 
SELECT Tmp.PN, EncryptByKey(Key_GUID('key1AES'),Tmp.NID) 
FROM #InsertTemp Tmp 
 
DROP TABLE #InsertTemp 
/* Note: The following code is not required. The DecryptByKey  
    function call is not required. The function call appears here to 
test whether the inserted data is encrypted. */ 
SELECT 
      T.PersonnelNumber, 
      convert(varchar(20), decryptbykey(T.SSN)) as SSN 
 FROM BulkInsertTbl T 
CLOSE SYMMETRIC KEY key1AES 
go 
 
/* Script to create the BulkInsertTbl table */ 
CREATE TABLE BulkInsertTest 
( 
      PersonnelNumber int, 
      SSN varbinary(100)     /* Note: The encrypted column data type 
   is varbinary.) */ 
) 
go

Neste exemplo, a chave simétrica denominada key1AES é criptografada por meio do certificado denominado myCert1. É preciso abrir a chave key1AES antes de executar a criptografia de dados. Em seguida, é preciso fechar essa chave após a conclusão da criptografia. Neste exemplo, a função DecryptByKey() não é exigida. A função é incluída para se verificar se os dados inseridos foram criptografados.

Criptografando e descriptografando dados por meio de certificados

Em geral, é recomendável criptografar dados usando uma chave simétrica. Esse método tira proveito da velocidade da criptografia simétrica. No entanto, é possível criptografar dados por intermédio de um certificado em vez de uma chave simétrica. Como a criptografia assimétrica é mais segura do que a criptografia simétrica, usar um certificado para criptografar dados é útil em um cenário em que se deseje transferir chaves de criptografia entre servidores que executam o SQL Server 2005. O script de exemplo a seguir ilustra como criptografar dados usando um certificado.

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Yukon900' 
go 
CREATE CERTIFICATE [cert_name] WITH SUBJECT = 'MyApp - Data 
   encryption' 
go 
INSERT INTO TABLE VALUES (encryptbycert( cert_id(cert_name), data))

Para descriptografar esses dados, use a função DecryptByCert().

Situação

As leis federais, estaduais e internacionais recentes, que definem as obrigações de conformidade reguladora de empresas que armazenam informações de identificação pessoal, fizeram com que a TI da Microsoft reavaliasse as estruturas de segurança de banco de dados existentes.

Solução

  • Os recursos internos de gerenciamento de chave e de criptografia em nível de coluna do Microsoft SQL Server capacitaram a TI da Microsoft a desenvolver diversas estratégias de criptografia diferentes para aprimorar a segurança de dados confidenciais no espaço de aplicativo da linha de negócios da TI da Microsoft.


Benefícios

  • O gerenciamento de chave do Microsoft SQL Server 2005 possibilita a criação de uma estrutura de gerenciamento de chave de criptografia sólida e fácil de usar.

  • Os recursos internos de criptografia em nível de coluna fornecem a flexibilidade para se criptografarem dados confidenciais em aplicativos, sem necessidade de considerar a sobrecarga de se criptografar todo um armazenamento.

  • Os recursos internos de criptografia do SQL Server 2005 permitem a descriptografia de dados dentro de uma exibição, e fácil acesso a dados criptografados.

  • A hierarquia de gerenciamento de chave com todos os tipos de recursos, do SQL Server 2005, fornece a capacidade de criar digitalmente procedimentos armazenados assinados para simplificar a criptografia de dados.


Produtos & Tecnologias

Microsoft SQL Server 2005


Download
Bb735261.icon_Word(pt-br,TechNet.10).gif

Encryptionat MSTWP.doc
629KB
Arquivo do Microsoft Word

Bb735261.icon_PowerPoint(pt-br,TechNet.10).gif

Encryptionat MSTWPPpt.ppt
629KB
Arquivo do Microsoft PowerPoint

Mostrar: