Tenho que confessar que já estou cansado de todo este papo político-regulatório. Por isso, por mais importantes que estes assuntos sejam acho que já é mais que hora de mudar o lado do disco (opa... quantos de vocês por aí ainda lembram de discos de vinil, com dois lados gravados?), e voltar à linha técnica. Tenho certeza que haverá quem diga que eu nunca deveria ter saído dela :-) .
Parece ser um karma dos nossos tempos: toda inovação traz consigo o risco que seus usuários pioneiros sejam alvo de ataques que exploram vulnerabilidades inerentes a modelos de negócio ainda não totalmente compreendidos. Esse é o caso, agora, com o conceito de cloud computing.
O modelo clássico para a estruturação da segurança computacional (que é um subconjunto do tema mais amplo da segurança da informação) das organizações emula a técnica medieval de construção de castelos: cerque tudo com uma muralha bem alta e grossa, e, se possível, cerque também o lado externo da muralha com um fosso bem fundo, cheio de água e, possivelmente, povoado com jacarés, tubarões e piranhas; deixe um único ponto de entrada e saída e mantenha-o bem vigiado, fiscalizando em detalhes tudo e todos que entram e saem, 24 horas por dia, 7 dias por semana e 52 semanas por ano. Quer mais segurança? Sempre é possível construir um segundo perímetro dentro do primeiro. E assim por diante, até conseguir o nível de segurança desejado.
Um dos efeitos colaterais desta visão clássica é induzir nos desenvolvedores e usuários de aplicações a sensação de que toda a segurança computacional necessária para os seus dados será provida por estes perímetros de segurança, o que não é verdade. Recursos como firewalls, anti-vírus, IDS (intrusion detection system) e quetais garantem apenas que seu perímetro pode ser relativamente difícil de ser rompido (se bem configurado). Mas um eventual atacante que consiga pular a muralha defensiva não terá nenhuma dificuldade em ter acesso a tudo que está do lado de dentro.
Se isso ainda não é o suficiente, considerem como a evolução da variedade e mobilidade dos dispositivos de acesso, o advento da disponibilidade virtualmente universal de acesso em banda larga à Internet, e a mudança dos requerimentos de conectividade e interoperabilidade dos processos de negócio das organizações com seus clientes, fornecedores e parceiros, complicaram a forma de arquitetar canais seguros para a realização de transações entre pessoas e aplicações.
Em 2003 um grupo de chief information security officers (CISOs) de grandes corporações multinacionais decidiu formar um grupo para promover melhores técnicas para lidar com o fenômeno da erosão dos perímetros convencionais de segurança, que eles denominaram de desperimetralização (minha tradução para de-perimeterization). Este grupo denominou-se Jericho Forum, como referência àquela cidade bíblica que confiava totalmente na solidez das suas muralhas, e vejam o que aconteceu quando elas ruíram...
Como eles mesmos dizem, o trabalho do grupo não se propõe a invalidar ou substituir, mas complementar conceitos e metodologias correntes na área de segurança da informação, como os expressos no COBIT e na série de normas ISO/IEC 27000. (BTW, atenção para a norma ISO/IEC 27011, também publicada como a recomendação X.1051 da ITU-T - download em formato PDF disponível aqui, infelizmente custa 30 Francos Suiços, ou vc tem que ter acesso ao sistema TIES da ITU para baixar) mas complementá-los no contexto da desperimetralização. O trabalho do Jericho Forum está centrado em torno dos mandamentos (commandments) e da especificação do framework denominado collaboration-oriented architecture (COA).
Em 16 de abril do ano passado o Jericho Forum publicou o cloud cube model paper com a visão deles a respeito da arquitetura de segurança computacional para um ambiente de cloud computing. Também está disponível no YouTube um vídeo explicando o modelo proposto no paper.
Resumindo: o primeiro passo para mover suas aplicações, no todo ou em parte, para um ambiente cloud computing é (naturalmente) conhecer em detalhes os requerimentos de segurança (disponibilidade, integridade e confidencialidade) associados aos seus dados. Uma vez conhecidos estes requerimentos, é possível modelar que espécie de nuvem será mais adequada para cada situação identificada. As características das nuvens podem ser ordenadas em uma taxonomia que é disposta como um hipercubo de 4 dimensões. Para simplicidade visual este hipercubo é representado como um cubo tridimensional ordinário, e a 4ª dimensão é descrita como uma "cor" que pode ser aplicada a cada instância das outras três dimensões.
A primeira dimensão define a localização física dos dados: interna ou externa aos limites físicos da sua organização. Por exemplo: se os dados forem localizados em um disk array no data center da sua organização, então eles são internos; mas se sua aplicação armazenar os dados em um serviço como o S3 da amazon web services, então a localização será externa.
A segunda dimensão descreve se a tecnologia empregada para a construção da nuvem (serviços, APIs, etc.) é baseada em padrões abertos ou é proprietária. Esta característica é crítica caso você perceba como provável (ou não) a necessidade de portabilidade dos dados da sua aplicação entre diferentes provedores de serviços em nuvem. De maneira geral, quanto mais proprietária for a tecnologia empregada, mais difícil será a portabilidade os dados para outra tecnologia.
A terceira dimensão descreve se suas aplicações irão operar dentro de um perímetro convencional de segurança ou se irão operar em um contexto desperimetralizado. Vale observar que o uso de VPNs para conexão remota de usuários/parceiros com sua aplicações não configura uma desperimetralização. Este apenas é um caso em que o seu perímetro convencional de segurança é estendido virtualmente , e temporariamente, até a localização do usuário/parceiro. Nesta dimensão é essencial considerar os parâmetros do framewirk COA.
Por último, a 4ª dimensão (ou "cor") descreve se os serviços da nuvem serão operadas com recursos e staff próprios da organização (insourced) ou com recursos e staff de terceiros (outsourced). O paper observa (e eu concordo) que esta característica é definida pelo negócio, e não por requerimentos técnicos ou de arquitetura. Portanto os requerimentos desta dimensão devem ser especificados no contrato com o provedor do serviço de nuvem utilizado (e eu acrescento: mesmo que seja insourced).
A figura abaixo resume este modelo cúbico em 4 dimensões. Deixa um pouco vesgo inicialmente, mas vc se acostuma :-) .
Para terminar, é importante observar que o modelo de computação em nuvem tem de estar inserido em uma "pilha" de abstração como, por exemplo, a representada abaixo.
Os provedores de serviços em nuvem atuais estão ofertando seus produtos basicamente nas duas primeiras camadas de abstração deste modelo. Serviços na terceira camada ainda são incipientes. Portanto devemos ter cuidado com o que esperamos deles. Talvez a nossa especificação de requisitos ainda esteja fora do alcance dos serviços ofertados, e modelos forçados além das suas possibilidades deixam brechas que os atacantes podem identificar e explorar com facilidade.
[ ]'s
J. R. Smolka