Pesquisar neste blog

4 de jun. de 2012

Desenvolva um aplicativo da web de conformidade regulamentar

Por: Arshad Noor
Em: http://feedproxy.google.com/~r/imasters/~3/em4v5edoc1A/story01.htm


O surgimento da computação em nuvem como uma estratégia de implementação alternativa para sistemas de TI apresenta muitas oportunidades, mas também desafia as noções tradicionais da segurança de dados. O fato de estes regulamentos de segurança de dados estarem desenvolvendo dentes deixa os profissionais da tecnologia da informação perplexos quanto a como aproveitar a computação em nuvem ao mesmo tempo mantendo-se em conformidade com os regulamentos desenvolvidos para proteger informações sensíveis - por exemplo, a TJX e a Heartland Payment Systems juntas pagaram mais de US$ 220 milhões em multas e quitações de violações de 94 e 130 milhões de números de cartões de crédito em 2007 e 2009, respectivamente. Elas representam as maiores violações de dados sensíveis de sistemas de computador publicamente divulgadas.
Há muitas abordagens para o problema; as primeiras são:
  • Não usar a nuvem de jeito algum;
  • Adotar a computação em nuvem completamente.
Na minha opinião, a solução ideal está em algum lugar entre elas; com dados sensíveis protegidos e gerenciados em zonas controladas, enquanto dados não sensíveis vivem nas nuvens. Isso permite que as empresas provem a conformidade com os regulamentos de segurança de dados ao aproveitar as nuvens, privadas ou públicas, ao máximo possível.
Neste artigo, descreverei como um tipo específico de arquitetura de aplicativo da web otimiza os investimentos de TI usando a computação em nuvem enquanto está em conformidade com os regulamentos de segurança de dados. 

A arquitetura tradicional de aplicativo da web

Conceitualmente, os aplicativos da web são simples. O navegador- representando o lado do cliente de uma conexão de cliente/ servidor - exibe um formulário e solicita dados do usuário. O servidor é representado por um programa de software em execução em alguns servidores de aplicativo da web. Após o envio do formulário pelo usuário, o programa do servidor recebe e processa as informações e retorna uma resposta com base no resultado da transação. Essa interação é mostrada na Figura 1. 
Figura 1
Embora o modelo possa se tornar complexo dependendo de quais tarefas os aplicativos executam, existe um recurso comum entre eles: o formulário da web deve identificar o Localizador Uniforme de Recursos (URL) do servidor para que o navegador saiba para onde enviar os dados de formulário quando o usuário enviar o formulário para processamento.
Para a maioria dos aplicativos, os usuários geralmente interagem com o mesmo servidor durante toda a transação. Entretanto, dependendo de muitos fatores, o navegador pode ser redirecionado a diferentes servidores e, portanto, a diferentes URLs, para algumas partes da transação. E, claro, os usuários são blindados contra as complexidades do redirecionamento, permitindo que percebam a transação como contínua. Mais frequentemente do que o contrário, os redirecionamentos são para o mesmo domínio, mesmo que sejam para servidores diferentes.
Em alguns aplicativos de e-commerce, o navegador pode ser redirecionado ao site do processador de pagamento no qual a transação de pagamento é processada e redirecionada de volta ao site original para concluir a transação. A vantagem do site de e-commerce é que eles não têm de desenvolver e manter a infraestrutura para a parte de processamento de pagamento da transação. Esse redirecionamento é mostrado na Figura 2. 
Figura 2

Desvantagens do modo atual de investimentos de TI

Há muitas desvantagens em como os investimentos de TI são realizados atualmente. Supondo que um aplicativo típico de e-commerce seja um exemplo, a responsabilidade de uma empresa no modo atual de investimentos da TI é:
  1. Ela deve adquirir recursos físicos, - computador, armazenamento e rede - para todas as funções do aplicativo:
    • Registro do cliente;
    • Gerenciamento de produto;
    • Inventário;
    • Transações de compra;
    • Processamento de pagamento;
    • Cumprimento.
    Entre outros. Geralmente, alguns anos depois, isso leva a uma responsabilidade adicional de gerenciar a transição da infraestrutura instalada, pois ela envelhece e fica aquém dos requisitos de desempenho desejados para a infraestrutura mais nova.

  2. Ela deve assegurar a redundância da infraestrutura de computação para a continuidade de negócios - geralmente dobrando o investimento em infraestrutura.

  3. Ela deve proteger toda a infraestrutura. Como a maioria dos sites não distingue dados sensíveis dos não sensíveis, a estrutura de segurança normalmente se aplica a todos os componentes da infraestrutura e aos dados. Isso representa uma alocação incorreta de recursos, já que as informações não sensíveis não precisam do mesmo grau de proteção das informações sensíveis. Nos últimos anos, devido ao PCI-DSS [Payment Card Industry Data Security Standard], os sites fazem uma distinção entre uma "zona de PCI" e uma "zona de não PCI", "dados de PCI" e "dados de não PCI". A zona de PCI e os dados geralmente recebem mais atenção e investimentos de um ponto de vista da segurança que suas contrapartes de não PCI. Embora isso possa ser considerado uma forma de otimização, pois a zona de não PCI está entre o perímetro da rede do site, a empresa ainda está gastando mais dinheiro protegendo os dados do que se o aplicativo fosse desenvolvido com a arquitetura descrita neste artigo.
Esse modo de investimento permaneceu inalterado nos últimos 40 anos. Embora a despesa de capital por investimento tenha sido reduzida radicalmente desde os dias do mainframe, um aplicativo que deve atender centenas de milhares de usuários ainda requer uma despesa de capital mensurável, apesar da disponibilidade dos servidores de mercadoria e do software livre. 

Urgência do investimento e mudanças na nuvem

A urgência da tecnologia da computação em nuvem, - especialmente as nuvens públicas -, altera radicalmente o modo como os investimentos de TI podem ser realizados. Não é mais necessário fazer investimentos iniciais grandes e arriscados e depreciar esses investimentos com o decorrer de muitos anos. Com despesas menores, as empresas podem configurar exatamente os serviços de TI de que precisam e pagar somente o que usarem. O impacto econômico dessa mudança não pode ser exagerado; novos negócios podem chegar ao mercado com orçamentos significativamente menores.
O fornecimento e o gerenciamento de serviços de TI serão tão significativos quanto essa mudança, pois a responsabilidade de proteger os dados sensíveis não pode ser terceirizada. Embora possa ser contratualmente delegada a um terceiro, a responsabilidade de assegurar a conformidade com os regulamentos de segurança ainda permanece com o proprietário dos dados.
Desse modo, acredito que os arquitetos e desenvolvedores de aplicativos da web considerarão o modelo descrito neste artigo útil para atender às suas obrigações de conformidade ao aproveitar ao máximo o poder da computação em nuvem. 

Conheça a computação em nuvem em conformidade regulamentar

As transações de negócios consistem em uma combinação de dados sensíveis e não sensíveis. O que é considerado sensível, assim como a proporção de dados não sensíveis para sensíveis, varia dependendo dos negócios e do tipo de transação.
Mas assumindo uma distribuição normal, para a grande maioria dos negócios, a proporção de dados não sensíveis para dados sensíveis se aproximará de 4:1. Com isso, a eficiência de investimentos de TI pode ser melhorada pela computação, armazenamento e gerenciamento de dados sensíveis em zonas regulamentadas dentro de um perímetro seguro, ao passo que todos os dados não sensíveis podem computadorizados, armazenados e gerenciados em nuvens públicas.
Essa arquitetura é chamada de Regulatory Compliant Cloud Computing (RC3): Um modelo de computação no qual as transações de negócios se estendem a zonas regulamentadas e nuvens públicas. Os dados sensíveis são criptografados, convertidos em token e gerenciados na zona regulamentada dentro do perímetro seguro de uma empresa (ou empresa terceirizada delegada), enquanto todos os dados não sensíveis residem na nuvem pública. Isso é mostrado na Figura 3. 
Figura 3
Em seguida, analisaremos a classificação de dados na arquitetura RC3 e, então, observar como as transações de dados de vários cenários do segmento de mercado funcionam na estrutura da RC3. 

Classificação de dados para a RC3

Um pré-requisito para o desenvolvimento de aplicativos da RC3 é classificar os dados em três categorias. Isso é necessário para que os aplicativos possam ser desenvolvidos para lidar com os dados de maneira adequada; para simplificar a comunicação entre as unidades de negócios e a equipe técnica, que desenvolvem e oferecem suporte aos serviços de TI.
Vamos analisar as classificações da RC3:
  1. Classe 1/C1: Consiste em dados sensíveis e regulamentados. São dados cuja divulgação ao público resultaria em multas, possíveis processos judiciais e perda de fundo de comércio da entidade violada. Exemplos de dados da Classe 1 são números de cartão de crédito, números de seguridade social, números de contas bancárias e outros dados desse tipo;
  2. Classe 2/C2: Consiste em dados sensíveis, mas não regulamentados. São dados que não são regulamentados, mas cuja divulgação ao público seria prejudicial a uma empresa e/ou resultaria em alguma perda de fundo de comércio na entidade violada. Exemplos de dados da Classe 2 são os salários de funcionários; números de vendas para linhas específicas de produtos; nome, sexo e idade de um cliente, etc;
  3. Classe 3/C3: Consiste em dados não sensíveis. Ou, em outras palavras, nenhum dado C1 ou C2. Por exemplo, descrições, imagens, etc. do produto.
É preciso observar que a classificação de dados pode ser flexível: quando os dados sensíveis são convertidos em token em um sistema de criptografia e gerenciamento de chaves (EKM) bem desenvolvido, eles são renderizados como não sensíveis de foram efetiva. Nesse caso, até mesmo os dados C1/C2 podem ser classificados como C3 após terem passado pela criptografia e tokenização.
Com base nessas classificações, as empresas que adotam a RC3 assegurarão o que segue:
  • Todos os dados C1 serão processados e armazenados em zonas regulamentadas, dentro de um perímetro de rede seguro. Essas zonas provarão serem compatíveis com regulamentos de segurança de dados aplicáveis. Os tokens de dados C1 (dados sensíveis que foram substituídos por tokens) podem ser armazenados em nuvens públicas;
  • Todos os dados C2 serão processados em zonas seguras, mas não necessariamente regulamentadas. Os tokens de dados C2 podem ser armazenados em nuvens públicas;
  • Todos os dados C3 podem ser processados e armazenados em nuvens públicas.
Os aplicativos devem ser gravados para lidar com essa separação de dados; mas a arquitetura do aplicativo da web -, principalmente a capacidade de redirecionar o navegador a servidores de destino -, serve para oferecer suporte a esse modelo.
As próximas seções descrevem alguns exemplos de transações em diferentes setores do segmento de mercado. O modelo, no entanto, pode ser aplicado a qualquer segmento de mercado que enfrente desafios semelhantes. 

Uma transação de e-commerce da RC3

Para o exemplo de transação de e-commerce da RC3, representada em alto nível, o cenário foi descrito usando o modelo de aplicativo Java, mas é preciso entender que o modelo não é exclusivo ao Java e pode ser facilmente duplicado na estrutura .NET ou usando quaisquer linguagens de script, como PHP, Ruby, etc. Além disso, embora os exemplos possam mostrar o uso do Amazon Web Services (AWS), eles são meramente ilustrativos; o modelo é facilmente duplicado em quaisquer infraestruturas da nuvem pública, como o Azure, vCloud, IBM SmartCloud, etc.
A zona regulamentada consiste em uma zona desmilitarizada (DMZ) e em uma zona segura (SECZ) da empresa. Um servidor de aplicativo da web reside na DMZ que recebe conexões de usuários na Internet. Ela se comunica com um servidor de banco de dados e uma Infraestrutura Corporativa de Gerenciamento de Chave (EKMI) na SECZ. A EKMI é responsável pela criptografia, tokenização e gerenciamento de chave para todos os dados C1 e C2. Espera-se que a EKMI tenha implementado todos os controles necessários para atender aos regulamentos de segurança de dados. Todas as comunicações são por TLS/SSL.
A zona de nuvem pública (PBZ) consiste em um servidor de aplicativo da web e um armazenamento de dados. O servidor de aplicativo da web recebe conexões de usuários na Internet, assim como solicitações de serviço da web do servidor de aplicativo da web na DMZ da empresa. Todas as comunicações são por TLS/SSL. As solicitações de serviço da web da DMZ da empresa à nuvem pública são ainda mais protegidas pelo SSL ClientAuth para autenticação mútua entre os terminais.
Esse tipo de transação segue estas etapas:
  • O usuário registra como um cliente na zona regulamentada e é designado um ID de Cliente (CID) exclusivo que é tratado como dados C3. As informações de contato do nome do cliente são designadas como dados C2, ao passo que os detalhes da ordem do cliente são designados como dados C3. Os dados C2 são criptografados, convertidos em token e armazenados na EKMI. Todos os dados C3 são armazenados na PBZ e transmitidos pelo link do SSL autenticado pelo cliente com dados relacionados à sessão para essa transação. Consulte a Etapa 1 na Figura 4.
Figura 4
  • O navegador do usuário é redirecionado à PBZ neste momento, no qual a maior parte da transação é processada ao:
    1. Revisar uma lista de produtos;
    2. Determinar seu preço e disponibilidade;
    3. Incluir produtos selecionados no carrinho de compras;
    4. Fornecer instruções de remessa;
    5. Quaisquer outros dados relacionados ao não pagamento.
    Os cabeçalhos da solicitação transportam tokens de sessão designados pelo servidor de aplicativo da web na DMZ; isso permite que os dados da transação na PBZ sejam correlacionados à mesma transação na zona regulamentada. Consulte a Etapa 2 na Figura 4.
  • Quando estiver pronto para efetuar o registro de saída, o navegador do usuário é redirecionado para o servidor da DMZ da empresa no qual o usuário envia um número de cartão de crédito para pagamento. Mediante a confirmação da transação, os dados C1 sensíveis são criptografados, convertidos em token e armazenados na EKMI. Quando forem convertidos em token, os dados C3 são armazenados na PBZ por meio de uma solicitação de serviço da web autenticada pelo cliente. Consulte a Etapa 3 na Figura 4.
    Algumas observações de segurança sobre a transação de e-commerce:
    • A conformidade com os regulamentos de segurança de dados é comprovada pelo fato de que os dados sensíveis e regulamentados são criptografados e armazenados pela EKMI na zona segura.
    • A PBZ não armazena nenhuma informação de credencial para o usuário. A autenticação do usuário é executada na zona regulamentada, um token de sessão válida é designado a esse usuário e o navegador do usuário é redirecionado à PBZ para processamento adicional.
    • As comunicações entre a DMZ e a PBZ são apenas em uma direção, da DMZ para a PBZ. A PBZ nunca se comunica com servidores na zona regulamentada; se o aplicativo for designado adequadamente, não há necessidade de fazê-lo. Isso assegura que qualquer compromisso na PBZ jamais escape para a zona regulamentada.
    • Os servidores da zona regulamentada comunicam-se com a PBZ somente por serviços da web autenticados pelo cliente SSL. Isso evita a necessidade de armazenar quaisquer credenciais de autenticação na PBZ. A autenticação do cliente SSL requer somente o armazenamento de um certificado digital confiável e válido na máquina de destino para autenticar uma conexão do cliente. O cliente, no entanto, deve possuir uma chave privada válida para o certificado digital e participar do protocolo autorizado pelo cliente SSL.

Uma transação de assistência médica da RC3

Este exemplo, representado em um alto nível, é semelhante à transação de e-commerce, exceto que essa transação vai além, mostrando como grandes BLOBs (objetos binários grandes) de dados não estruturados, como raios X, também podem ser armazenados na PBZ ao comprovarem sua conformidade. Supomos que informações básicas sobre o paciente já tenham sido criadas antes dessa transação.
Este tipo de transação segue estas etapas:
  • Um técnico em laboratório de raio X se autentica nos servidores da zona regulamentada de um hospital e estabelece uma sessão. Se houver a necessidade de criar novos dados do paciente, isso é feito na zona regulamentada na qual um ID de Paciente (PID) está designado. Alguns elementos dos dados demográficos do paciente são designados como dados C1/C2; como tais, são criptografados e convertidos em token pela EKMI. O hospital tem a opção de manter os dados C1/C2 convertidos em token na zona controlada ou armazená-los na PBZ usando o serviço da web unidirecional seguro na nuvem. Consulte a Etapa 1 na Figura 5.
Figura 5
  • O navegador do técnico é redirecionado para a PBZ, na qual ele envia as partes não sensíveis da transação, como:
    • Data e hora da visita;
    • Solicitação do identificador do médico e sua receita para o teste;
    • Auxílio ao técnico e medidas tomadas;
    • Quaisquer outros dados não sensíveis.
    O aplicativo é desenvolvido de modo que essa parte da transação não transporte nenhum dado C1 ou C2. Consulte a Etapa 2 na Figura 5.
  • Quando estiver pronto para enviar raios X e o relatório do radiologista, o navegador do técnico é redirecionado à zona regulamentada. O técnico faz upload de raios X e do relatório, que podem ser convertidos para um documento XML pelo aplicativo da web. O documento XML um tanto grande consiste em dados C1 que devem ser assegurados.
    Os dados C1 são recebidos no servidor de aplicativo da web da DMZ e enviados a um mecanismo criptográfico capaz de criptografar grandes dados não estruturados. Uma chave simétrica é gerada e usada para criptografar conteúdos do documento. Ela é confiada à EKMI enquanto o raio X criptografado e o relatório são armazenados na PBZ por meio de uma solicitação segura de serviço da web. Consulte a Etapa 3 na Figura 5.
    Todas as observações de segurança que se aplicam à transação de e-commerce também se aplicam à transação de assistência médica. A única diferença entre as duas transações é a inclusão de dados não estruturados, o raio X, na transação de assistência médica que requer o uso de um mecanismo especializado que é capaz de manipular a criptografia e decriptografia de grandes BLOBs.

Uma transação de manufatura da RC3

Este exemplo mostra um engenheiro em uma configuração industrial, enviando um documento sensível, como um projeto com uma lista de materiais (BOM), para uma linha de montagem para manufatura.
Este tipo de transação segue estas etapas:
  • Um engenheiro é autenticado nos servidores na zona regulamentada e estabelece uma sessão. Ele é, então, redirecionado à PBZ. Uma solicitação de serviço da web transfere informações relacionadas à sessão com segurança da SECZ para a PBZ.
Na PBZ, o engenheiro cria uma nova transação que aceita somente dados C3 na nuvem. Um ID de transação exclusivo é designado para a transação que, em seguida, é retornada ao navegador do engenheiro nos cabeçalhos de resposta da solicitação.
Como a transação é para a criação de uma nova peça pela planta, a parte pública das transações aceita os componentes não sensíveis da BOM. Consulte a Etapa 1 na Figura 6. 
Figura 6
  • O navegador do engenheiro é redirecionado à SECZ, na qual a parte sensível da transação é enviada. São informações como:
  • O projeto do objeto a ser fabricado;
  • As partes sensíveis da BOM;
  • Instruções especiais sobre o conjunto, se houver;
  • Quaisquer outros dados sensíveis.
O aplicativo é desenvolvido de modo que essa parte da transação transporte dados C1 e C2 necessários para a criptografia e tokenização na SECZ. O projeto criptografado é salvo na PBZ, já que não é mais sensível. Consulte a Etapa 2 na Figura 6.
Todas as observações de segurança que se aplicam às transações anteriores também se aplicam a essa transação. 

Conlcusão

Para encerrar, com o gerenciamento de chave de criptografia apropriado, é possível usar nuvens públicas para computar e armazenar dados sensíveis ao atender aos requisitos de conformidade dos regulamentos de segurança de dados. A tecnologia para ativar isso está disponível atualmente; o que falta é que os aplicativos sejam desenvolvidos para aproveitar esses recursos - principalmente para desenvolver aplicativos da nuvem para que eles apliquem o nível apropriado de recursos de segurança em níveis de dados diferentemente classificados acessados pelo aplicativo para seu funcionamento. 

Recursos

Aprender
Obter produtos e tecnologias
Discutir
***
Sobre o autor: Arshad Noor é CTO da StrongAuth Inc., uma empresa localizada no Vale do Silício cujo foco tem sido as soluções do gerenciamento corporativo de chave na última década. Ele tem 25 anos de experiência no setor de TI, dos quais mais de 12 foram dedicados à implementação de infraestruturas do gerenciamento de chave para proteger dados sensíveis em dezenas de ambientes essenciais para o desempenho no mundo todo.


Nenhum comentário:

Postar um comentário