Boas Práticas para Licitação de Serviços de Computação em Nuvem

Tabela de conteúdo Conceitos de Serviços em Nuvem Características Essenciais de Computação em Nuvem Modelos de Computação em Nuvem Delimitação de Conceitos Vantagens da adoção de Computação em Nuvem Vantagens específicas para Governo Modelos de comercialização de serviços de computação em nuvem Comercialização de IaaS Comercialização de PaaS Comercialização de SaaS Acordos de nível de serviço Privacidade e Soberania dos Dados Normas e padrões internacionais aplicáveis à contratação de serviços de computação em nuvem CSA (Cloud Security Alliance) AICPA (American Institute of Certified Public Accountants) ENISA (European Union Agency for Network and Information Security) NIST (National Institute of Stantards and Technology) Isaca (Information Systems Audit and Control Association) Conclusão do Ministro Relator no Acórdão 1739/2015 Quanto aos Benefícios Quanto às Incertezas Quanto aos Riscos Potenciais Requisitos para Contratação de Serviços de Computação em Nuvem Previamente à Contratação Requisitos Habilitadores e Contratuais Comparação de Soluções de Mercado em Computação em Nuvem Proposta de Termo de Referência para Contratação de Serviços de Computação em Nuvem

Conceitos de Serviços em Nuvem

A partir dos Normativos identificados apresentaremos um resumo de conceitos quem envolvem Computação em Nuvem.

Quadro – Conceitos de Computação em Nuvem

Entidade	Conceito
National Institute of Standards and Technology (NIST)	Computação em nuvem é um modelo que permite acesso ubíquo, conveniente e sob demanda, através da rede, a um conjunto compartilhado de recursos computacionais configuráveis (por exemplo: redes, servidores, armazenamento, aplicações e serviços), que podem ser rapidamente provisionados e disponibilizados com o mínimo de esforço de gerenciamento ou de interação com o provedor de serviços. (Tradução livre)
International Data Group (IDG)	Computação em nuvem é um modelo, não uma tecnologia. Neste modelo de computação, todos os servidores, redes, aplicações e outros elementos relacionados a data centers são disponibilizados para a TI e para os usuários finais através da Internet, de maneira que a TI compra somente o tipo e a quantidade de serviços computacionais que realmente são necessários. O modelo em nuvem difere das terceirizações tradicionais à medida em que os clientes não entregam seus próprios recursos de TI para gerência de terceiros. Ao invés disso, eles se conectam à “nuvem” para ter serviços de infraestrutura, ou serviços de software, lidando com a “nuvem” da mesma maneira que eles fariam com um data center interno ou um computador que tivesse as mesmas funções. (tradução livre)
O International Data Corporation (IDC)	Computação em nuvem é um modelo emergente de desenvolvimento, implantação e entrega de TI, permitindo a entrega em tempo real de produtos, serviços e soluções através da Internet

Dentre as contribuições obtidas no Setor Privado, a Amazon Web Service disponibilizou o whitepaper Aquisição de soluções em nuvem melhores práticas para clientes do setor público que apresenta várias definições dos serviços prestados pela AWS, bem como boas práticas de Serviços de Computação em Nuvem.
Outros contribuições, agora da ORACLE, envolvem dois artigos da Accenture, enfatizando que não basta observar a questão custo, mas avaliar principalmente os benefícios que os Serviços de Computação em Nuvem agregam à organização, e cita como exemplo: se o TCO tiver uma divisão de 20% para Infra, 40% para SW e 40% para serviços; ao contratar IaaS haverá uma economia sobre a fatia de Infra (20%). Mas se ao fazer isto, a necessidade de processadores pular de 10 para 20 (pois a vCPU pode ser pouco performática), a fatia de SW dobrará, pois é precificada por número de processadores. Haveria, neste caso, um aumento do TCO!

White_Paper_-_Accenture_AOBG_-_IaaS_-_Enterprise_Cloud_-_EXTERNAL

White_paper_-_Oracle_IaaS_Cloud_Performance_-_An_Accenture_Point_of_View

Características Essenciais de Computação em Nuvem

O NIST descreve cinco características essenciais de Computação em Nuvem

• Auto-provisionamento sob demanda (“on-demand self-service”): o consumidor pode ter a iniciativa de provisionar recursos na nuvem, e ajustá-los de acordo com as suas necessidades ao decorrer do tempo, de maneira automática, sem a necessidade de interação com cada provedor de serviços.
• Acesso amplo pela rede (“broad network access”): os recursos da nuvem estão disponíveis para acesso pela rede por diferentes dispositivos (tais como: estações de trabalho, tablets e smartphones) através de mecanismos padrões.
• Compartilhamento através de pool de recursos (“resource pooling”): Os recursos computacionais do provedor são agrupados para servir a múltiplos consumidores (modelo multi-tenant), com recursos físicos e virtuais sendo alocados e realocados dinamicamente, de acordo com a demanda dos seus consumidores. Há uma ideia geral de independência de localização, uma vez que o cliente geralmente não possui controle ou conhecimento sobre a localização exata dos recursos providos. No entanto, é possível especificar este local em um nível mais alto de abstração (por exemplo: país, estado, ou data center). Os serviços são concebidos como um padrão, com a finalidade de atender à demanda de vários consumidores de maneira compartilhada, não sendo focados em necessidades customizadas de um único consumidor.
• Rápida elasticidade: os recursos podem ser elasticamente provisionados e liberados, e, em alguns casos, de maneira automática, adaptando-se à demanda. Do ponto de vista do consumidor, os recursos disponíveis para provisionamento parecem ser ilimitados, podendo ser alocados a qualquer hora e em qualquer volume.
• Serviços medidos por utilização (“measured service”): os serviços de computação em nuvem automaticamente controlam e otimizam a utilização de recursos, através de mecanismos de medição utilizados em nível de abstração associado ao tipo de serviço utilizado (por exemplo: armazenamento, processamento, largura de banda, e contas de usuário ativas). A utilização dos recursos pode ser monitorada, controlada e reportada, fornecendo transparência tanto para provedores como para consumidores. Portanto, a precificação, se houver, será balizada pelo uso dos serviços.

Modelos de Computação em Nuvem

Os modelos mais difundidos atualmente são os definidos pelo NIST, descritos pelo Cloud Security Alliance (CSA):

• Modelo baseado na forma de implantação:
  • Nuvem pública – A infraestrutura de nuvem pública está disponível para uso aberto do público em geral e fica nas instalações do provedor. A sua propriedade, gerenciamento e operação podem ser de uma empresa, uma instituição acadêmica, uma organização do governo, ou de uma combinação desses.
  • Nuvem privada – A infraestrutura de nuvem privada está disponível para uso exclusivo por uma única organização. Sua utilização, gerenciamento e operação podem ser feitos pela própria organização, terceiros, ou por uma combinação dos dois, e pode estar localizada em suas dependências ou fora delas. No entanto, o cliente terá controle sobre sua localização geográfica, o que a faz tornar atrativa para dados ou sistemas com restrições de acesso ou que são de missão crítica.
  • Nuvem comunitária – A infraestrutura de nuvem comunitária está disponível para uso exclusivo de uma comunidade específica formada por organizações que possuem interesses e preocupações em comum (por exemplo: requisitos de segurança e conformidade). Sua utilização, gerenciamento e operação podem ser feitos por uma ou várias das organizações pertencentes à comunidade, por terceiros, ou por uma combinação deles. Ela pode estar localizada nas dependências de uma ou mais destas organizações, ou fora delas.
  • Nuvem híbrida – A infraestrutura de nuvem é uma composição de duas ou mais infraestruturas de nuvem (privada, comunitária, ou pública), interligadas por tecnologias padronizadas ou proprietárias que permitem portabilidade de aplicações e de dados entre as nuvens.

Segundo o TCU é possível utilizar esta abordagem para valer-se dos benefícios dos modelos público e privado, e ao mesmo tempo minimizar os riscos e custos advindos de cada modelo, ou quando existem necessidades distintas associadas a determinados tipos de usuários ou de dados.

• Modelo baseado na arquitetura dos serviços disponibilizados pela nuvem:
  • Infraestrutura como Serviço (Infrastructure as a Service – IaaS) – É o provisionamento de processamento, armazenamento, comunicação de rede e outros recursos de computação fundamentais pelo fornecedor, nos quais o consumidor pode instalar e executar softwares em geral, incluindo sistemas operacionais e aplicativos. O consumidor não gerencia nem controla a infraestrutura subjacente da nuvem, mas tem controle sobre os sistemas operacionais, espaço de armazenamento, e aplicativos instalados, e possivelmente possui controle limitado sobre alguns componentes de rede (como firewalls);
  • Plataforma como Serviço (Platform as a Service – PaaS) – O recurso fornecido ao consumidor são linguagens de programação, bibliotecas, serviços e ferramentas de suporte ao desenvolvimento de aplicações, para que o consumidor possa implantar, na infraestrutura da nuvem, aplicativos criados ou adquiridos por ele. O consumidor não gerencia nem controla a infraestrutura subjacente da nuvem (rede, servidores, sistema operacional, banco de dados ou armazenamento), mas tem controle sobre as aplicações implantadas e possivelmente sobre as configurações do ambiente que hospeda as aplicações;
  • Software como Serviço (Software as a Service – SaaS) – São as aplicações do fornecedor executadas em uma infraestrutura de nuvem (conforme as cinco características de computação em nuvem), disponíveis ao consumidor. As aplicações podem ser acessadas por vários dispositivos clientes, tais como um navegador web ou um software cliente. O consumidor não gerencia nem controla a infraestrutura da nuvem associada ao serviço, incluindo rede, servidores, sistemas operacionais, armazenamento, ou mesmo recursos individuais da aplicação. Para este último, há a possível exceção de restritas configurações de aplicação, específicas a usuário.

Para Matt Hester’s WebLog, conforme adaptação pelo TCU, a divisão de responsabilidades entre cliente e fornecedor de nuvem é representada na figura abaixo:

Delimitação de Conceitos

O TCU explicita que os modelos permeiam-se assim é necessário diferenciar os conceitos abaixo:

• Nuvem (cloud): De acordo com o site whatiscloud.com, uma nuvem refere-se a um ambiente distinto de TI projetado com o propósito de provisionar recursos de TI escaláveis e mensuráveis, com fronteiras delimitadas e acessados remotamente. O termo originou-se como uma metáfora à Internet, a qual é, em sua essência, uma rede de redes provendo acesso remoto a um conjunto de recursos de TI descentralizados. (tradução livre)

• Serviços na nuvem (cloud services): A partir da definição do IDC, deriva-se que são quaisquer serviços e soluções entregues e consumidos em tempo real, localizados na nuvem e acessados remotamente, comumente pela Internet, tais como serviços de compras, bancos, colaboração, etc. Os consumidores não estão explicitamente comprando “computação em nuvem”, mas “serviços na nuvem” providos por ambientes de computação em nuvem;

• Computação em nuvem (cloud computing): De acordo com o IDC, é “o ambiente de TI – envolvendo todos os elementos da “pilha” de TI e produtos de rede (e serviços de suporte) – que permite o desenvolvimento, entrega e consumo de serviços na nuvem”, de maneira escalável e elástica. Envolve um framework e vocabulário voltados ao domínio de TI;

• Serviços de computação em nuvem (cloud computing services): são serviços que abrangem o provimento de computação em nuvem, com todas suas características.

Para o TCU quaisquer análises sobre contratações de serviços de computação em nuvem variam de acordo com as nuances dos dois modelos: modelo baseado na forma de implantação e modelo baseado na arquitetura dos serviços disponibilizados pela nuvem. Por exemplo, nuvens privadas apresentam riscos reduzidos relativos à segurança da informação, porém maiores no que concerne à escalabilidade e elasticidade, quando comparadas a nuvens públicas.

Assim, como é possível fornecer serviços de computação em nuvem associados a qualquer modelo de nuvem, faz-se necessário estabelecer uma linha divisória conceitual, e, dentre os vários degraus para prestação de serviços de computação em nuvem, não há dúvidas de que os serviços associados a uma nuvem pública representam o maior grau de terceirização.

Vantagens da adoção de Computação em Nuvem

Para a IDC, as principais vantagens do uso de computação em nuvem são:

• Redução de custos de infraestrutura e serviços de TI. O benefício mais significativo vem de hospedar aplicações em infraestrutura em nuvem devido à redução de custos de capital (capital expenditure – Capex) e custos operacionais (operacional expenditure – Opex).

• Otimização da produtividade da equipe de TI. A mudança para o uso de IaaS, ao acelerar o desenvolvimento e a implantação de aplicações, bem como automatizar o seu gerenciamento, torna a equipe de TI mais produtiva e capaz de melhorar o suporte de operações de missão crítica.

• Melhoria da produtividade do usuário final. Os usuários finais beneficiaram-se de menor indisponibilidade do serviço e recuperação mais rápida, reduzindo o tempo de inatividade em 72% e economizando expressivos recursos de cada aplicativo por ano.

• Aumento de benefícios do negócio. Muitas das empresas estão empregando soluções em nuvem para possibilitar novos modelos de negócios e suportar aplicações de geração de receita, atingindo um maior número de usuários/clientes.

A ISACA apontas vantagens desse serviço na publicação “Controls and Assurance in the Cloud: Using COBIT 5”:

• Melhorar capacidade de resposta. Computação em nuvem fornece serviços flexíveis e escaláveis que podem ser implementados rapidamente para fornecer às organizações a capacidade de responder a mudanças de requisitos e a períodos de picos.

• Ciclo mais rápido de inovação. No ambiente de nuvem, a inovação é tratada muito mais rápido do que dentro da empresa. O gerenciamento de patches e atualizações para novas versões tornam-se mais flexíveis.

• Redução do tempo para implementação. Computação em nuvem oferece poder de processamento e capacidade de armazenamento de dados conforme a necessidade, quase em tempo real.

• Resiliência. Computação em nuvem pode fornecer um ambiente altamente resiliente e reduzir o potencial de falha e o risco de downtime.

Segundo análise da ENISA (European Network and Information Security Agency), os ganhos de escala refletem-se também na área de segurança: Segurança e os benefícios de escala: de forma simples, todos os tipos de medidas de segurança são mais baratos quando implementados em larga escala. Portanto, um mesmo valor de investimento em segurança permite adquirir uma melhor proteção. Isso inclui todos os tipos de medidas defensivas, tais como filtragem, gerenciamento de atualizações, o hardening das instâncias de máquinas virtuais e hypervisors etc. Outros benefícios de escala incluem: multiplicidade de localizações, redes de borda (conteúdo entregue ou processado mais perto de seu destino), menor tempo de resposta em incidentes e gerenciamento de ameaças. (tradução livre)

Como a segurança é um dos elementos diferenciadores de mercado, os principais fornecedores de nuvem competem com propostas abrangentes e robustas de segurança, possivelmente superando o padrão de segurança em data centers próprios dos clientes, que possuem menos recursos disponíveis de segurança a serem amortizados sobre uma menor base de usuários. Dentre essas vantagens de segurança na nuvem, destacam-se:

• Maior resistência a ataques contra a disponibilidade de serviços (distributed denial of service – DDoS) devido à maior capacidade do provedor de nuvem para realocar dinamicamente os recursos de filtragem, traffic shaping, autenticação, criptografia etc.

• Vantagens para auditoria e perícia: o uso de virtualização em computação em nuvem, permite fornecer imagens dedicadas para a perícia forense de máquinas virtuais, acessíveis sem precisar desconectar a infraestrutura operacional, levando a um menor tempo de inatividade durante o período de análise. O uso de nuvem também permite fornecer mais espaço de armazenamento de baixo custo para logs, permitindo conservar registros de atividade mais abrangentes e por mais tempo.

• Atualizações e parametrização padrão de segurança mais efetivas e rápidas: a padronização das imagens de máquinas virtuais e dos módulos de software usados pelos clientes possibilita ajustes finos (hardening) de parâmetros de segurança, tornando-os mais robustos e otimizados, e atualizações contínuas.

Vantagens específicas para Governo

O TCU identifica outras vantagens, mais específicas para atividades do relacionadas a governo:

• Maior agilidade da administração pública na entrega de serviços e em sua atualização tecnológica, pois os processos formais de contratação pública podem dificultar a manutenção de uma infraestrutura de TI própria atualizada e que responda rapidamente às demandas de seus usuários.

• Suporte a iniciativas de Big Data e Dados Abertos, facilitando a abertura de informações governamentais que hoje encontram-se em sistemas que controlam as operações cotidianas do Estado e portanto são fechados com acesso limitado aos seus operadores. O uso de nuvem pública permitiria ampliar o acesso a esses dados a um custo menor, sem comprometer a segurança, a disponibilidade e o desempenho operacional dos sistemas originais. Uma vez os dados governamentais estando facilmente acessíveis, torna-se possível maior participação da sociedade na criação de novos serviços baseados nesses dados.

• Atendimento a picos de demanda sazonal de serviços públicos pela Internet sem necessidade de alocar grande quantidade de recursos fixos. Várias atividades estatais acarretam picos sazonais de demanda de serviços próximos a datas limite como: entregas de declarações de imposto de renda, inscrições e resultados do Enem, resultados eleitorais e listagem de gestores públicos inelegíveis, períodos de recadastramento do INSS, listagem dos percentuais do fundo de participação dos municípios, etc.

• A contratação de serviços em nuvem de IaaS ou PaaS pode levar a uma redução de oportunidades de desvios e irregularidades, quando comparada às múltiplas contratações de máquinas, licenças de software, manutenção e suporte necessárias para a operação de CPD próprio. As ofertas de IaaS e PaaS identificadas neste levantamento são todas por contrato de adesão, utilizando métricas de precificação com custos unitários divulgados publicamente e iguais para todos os clientes, o que facilita a pesquisa de preços.

• Agilidade e economia na entrega de serviços para instituições públicas com unidades descentralizadas, que podem ter serviços disponibilizados por meio de acesso à internet, mais barato que as interconexões via redes privadas atualmente utilizadas.

Modelos de comercialização de serviços de computação em nuvem

O TCU apresenta o panorama do mercado brasileiro, em 2014, e identifica modelos de comercialização de serviços de computação em nuvem para cada um dos três modelos de implementação (IaaS, PaaS e SaaS), descrevendo as formas de precificação e outros parâmetros comuns.

Comercialização de IaaS

Segundo o TCU, Thoran Rodrigues, em seu artigo intitulado “Comparing cloud infrastructure as a service providers”, identificou 14 critérios comparativos comuns ao universo de 11 provedores. Grande parte destes critérios influem na composição de preço, e todos são variáveis a serem consideradas em comum na forma de comercialização dos fornecedores:

1) Precificação. São oferecidos planos de acordo com o uso (medidos geralmente por hora), planos mensais, ou descontos por “fidelização” (onde o cliente ganha um desconto em taxas de uso se assina previamente o serviço por um ano). O modelo de pagamento por uso permite um controle mais granular e está mais próximo do conceito de computação em nuvem. Já os planos mensais ou anuais aumentam o risco de pagamento por recursos não utilizados;

2) Preço mensal médio. A fim de encontrar-se um valor comum, o custo foi nivelado em dólares para um servidor na nuvem com 1 CPU e 2 GB de RAM (ou a melhor opção que mais se aproxime). Utilizou-se uma média entre data centers de provedores que possuem preços diferentes de acordo com a localização dos dados, e também uma média entre servidores Windows/Linux. Quando disponível, foi utilizada a precificação por hora, baseada em meses de 730 horas. Não estão incluídos os custos de transferência de dados;

3) Service Level Agreement (SLA). SLA oferecido de disponibilidade, em pontos percentuais;

4) Número de datacenters. Quantidade de data centers oferecidos como escolha;

5) Capacidade de ampliação (Scale Up). Se é possível ampliar instâncias de servidores em nuvem individualmente, adicionando mais memória, CPUs, ou armazenamento;

6) Capacidade de crescimento (Scale Out). Se é possível implantar rapidamente novas instancias de servidores;

7) Suporte. Foi definida uma escala subjetiva de três níveis:

• Pequeno – empresas que oferecem somente suporte incluído como fóruns online; qualquer outro tipo de suporte é pago adicionalmente;
• Médio – empresas que oferecem um único tipo de suporte 24×7 incluído (ou telefônico, ou chat online), além dos fóruns;
• Extensivo – empresas com ofertas de suporte múltiplo incluídas no preço básico;

8) Monitoramento. Também definido em outra escala subjetiva em três níveis:

• Pequeno – empresas que não possuem soluções de monitoramento e alerta integradas, requerendo a implantação de ferramentas de terceiros ou que serviços extras sejam adquiridos;
• Médio – empresas com ferramentas muito simples de monitoramento integradas (poucos indicadores ou sem alertas);
• Extensivo – empresas com ferramentas de monitoramento completas integradas, oferecidas sem custo adicional;

9) Interfaces (APIs). Se a companhia oferece interfaces para interação com os servidores;

10) Testes gratuitos. Se o provedor oferece período de testes gratuitos do serviço;

11) Sistemas operacionais suportados. Número de sistemas operacionais suportados, independentemente de versão, disponíveis como imagem pré-configurada;

12) Número de tipos de instâncias. Número disponível de diferentes configurações de servidores. Alguns provedores oferecem servidores totalmente customizáveis em termos de CPU, o que foi classificado como “configurável”;

13) Custo de saída de dados. O custo, em dólares, para cada GB de dados que saem do servidor. Empresas que oferecem conexões em Mbps sem ônus possuem custos listados como zero;

14) Custo da entrada de dados. Mesmo que acima, mas para cada GB de dados que entram no servidor.

Estes critérios, apesar de representarem somente uma fração do universo de variáveis que permeiam um contrato de serviços de computação em nuvem, estabelecem parâmetros mínimos que podem ser utilizados para efeitos comparativos, ou no mínimo, observados dentro de uma contratação. No caso do estudo citado, estabeleceu-se um comparativo entre os provedores. O primeiro ponto levantado foi a grande variação de preços entre os fornecedores, entre US$ 40,00 a US$ 135,00 por mês, valores estes de 2012 não atualizados, mas que servem para demonstrar a heterogeneidade do mercado.

Além disto, alguns provedores oferecem SLA de 100%, não sendo possível saber se a médio e longo prazo este valor poderá ser mantido. Alguns também não fornecem a possibilidade de ampliação para um servidor já criado, ponto que merece atenção. Mais da metade cobra ou necessita de solução de terceiros para fazer monitoramento. Por fim, mais de 80% das empresas cobram pela transferência de dados (saída), ou seja, a utilização de rede influi nos valores cobrados.

A ORACLE contribui com essa questão, esclarecendo que uma métrica mínima de TPS (transações por segundo) ou SPECs deveria ser exigida por vCPU, evitando que um provedor forneça ambientes excessivamente lentos ou sem performance em geral. Apresenta o OOW17_-_database-cloud-services-comparison-3227721, cuja execução das querys ali inseridas dariam ao contratante um benchmark sobre a performance mínima aceitável.

Comercialização de PaaS

Para o TCU, a diferença entre os custos de serviços na nuvem entre IaaS e PaaS é que o IaaS possui critérios mais objetivos para composição de preços. Assim, uma fórmula básica para o custo de infraestrutura como serviço poderia considerar:

horas de computação + horas de armazenamento + custos de software

Já a estimativa de custos para Plataforma como Serviço é mais difícil, e neste caso, uma proposta de fórmula de custo poderia considerar, simplificadamente, algo como:

horas de armazenamento + número de chamadas API * preço por chamada API + duração de consultas

O problema é que o fornecimento de Plataforma como Serviço possui muitas variáveis de custo. Além da dimensão de tempo de uso, é preciso considerar as chamadas de API, storage, etc.

As maneiras mais óbvias para fazer comparações entre provedores de PaaS, tais como linguagens de programação suportadas e bancos de dados incluídos não são tão importantes se o usuário utiliza padrões de mercado. Já avaliar os provedores de PaaS com base no suporte que estes podem dar ao ciclo de vida de desenvolvimento da aplicação, em procedimentos de desenvolvimento e grau de controle sobre a infraestrutura que sustenta a plataforma, pode ser mais útil.

Por exemplo, se a equipe de desenvolvimento utiliza procedimentos e ferramentas especificas para realizar versionamento, testes e implantação em produção (deploy), pode-se comparar os serviços fornecidos dentre aqueles que integram com estas ferramentas. Fatores como opções de gerenciamento de ciclo de vida da aplicação (Application Lifecycle Management), APIs (Application Programming Interface) oferecidas, gerenciamento de logs e feedback, além dos acima propostos, devem ser considerados.

Comercialização de SaaS

O Software como Serviço utiliza um modelo de entrega de um-para-muitos, no qual um único provedor fornece serviços de software para múltiplos usuários. Neste modelo, a cobrança pelos serviços é feita baseada nos tipos e quantidades de serviços utilizados, algo semelhante ao consumo de serviços de água ou energia elétrica.

Uma limitação chave ao modelo do SaaS é que este está focado em prover aplicações que possuam o potencial de alcançar um amplo mercado. Para serem rentáveis, as aplicações disponibilizadas como serviço precisam atrair uma grande base de clientes, e portanto são confeccionadas de uma forma padrão e igual para um grande número de usuários, atendendo às suas necessidades comuns.

Desta forma, aplicativos de missão crítica ou que necessitam customização de acordo com as regras de negócio provavelmente não são candidatos para migração ao SaaS.

Os modelos de precificação de SaaS normalmente baseiam-se na quantidade de usuários, ou em volume de recursos consumidos, ou ainda em uma combinação dos dois. Normalmente a estrutura de preços é linear, e neste caso não há economia de escala.

Acordos de nível de serviço

O contrato estabelecido com o provedor deve incluir cláusula para “Acordos de Nível de Serviço” (Service Level Agreements – SLAs), com parâmetros específicos e níveis mínimos para cada elemento do serviço fornecido. Tais acordos necessitam ser razoáveis e exequíveis, e ao mesmo tempo estabelecer punições ou compensações quando do seu não-cumprimento. Parâmetros abordados normalmente dentro de tais acordos são disponibilidade, tempo de resposta, desempenho, tempo para correção de erros ou incidentes, e segurança.

Para o TCU, dentro da miríade de contratos-padrão dos provedores de nuvem, é importante definir os conceitos a serem abordados para SLA, pois cada provedor utiliza sua própria terminologia e não há uniformidade entre eles. Como por exemplo:

• Microsoft define “máximo de minutos disponíveis”, “tempo de inatividade”, “porcentagem de tempo de atividade mensal”, este último correspondendo ao percentual de disponibilidade em um mês, além de todo o vocabulário restante com termos que remetem ao tipo de serviço ofertado.

• Google Apps utiliza conceitos de “inatividade”, “serviços cobertos pelo Google”, “porcentagem de atividade mensal”.

• Mandic, provedora de IaaS no mercado brasileiro, considera como base períodos de 15 minutos de indisponibilidade e totais de períodos de 15 minutos em um mês, para o cálculo de seu SLA.

Outro ponto a ser observado diz respeito às exceções à computação do SLA, como manutenções programadas, casos fortuitos ou força maior, estes últimos muitas vezes com definições não claras.

As sanções previstas para o não cumprimento dos níveis de serviço geralmente preveem créditos em dias de serviço, proporcionais à indisponibilidade, ou em descontos no valor a ser pago no faturamento. Nem todos os provedores deduzem isto de maneira automática.

Apresentamos, abaixo, um amplo conjunto de SLAs de provedores de serviços de computação em nuvem (informação fornecida pelos próprios provedores).

IBM – SLAs do IBM Softlayer

Microsoft – SLAs do Azure – Contrato de Nível de Serviço para Serviços Online da Microsoft

Google – Google Compute Engine Service Level Agreement (SLA)

Oracle – Oracle PaaS and IaaS Public Cloud Services

Privacidade e Soberania dos Dados

A Microsoft como contribuição apresenta seus Termos de Privacidade e respeito a soberania dos dados de seus clientes em: Microsoft Trust Center // Privacy

Normas e padrões internacionais aplicáveis à contratação de serviços de computação em nuvem

O TCU efetuou pesquisas para identificar referências de boas práticas e controles relacionados à contratação e à auditoria de serviços de computação em nuvem que pudessem ser utilizados na identificação de riscos e na elaboração de sua matriz de auditoria. Relatou a existência de diversos esforços de padronização nas formas de auditoria de prestação de serviços em nuvem.

Como uma das características de serviços em nuvem encontra-se em ganhos de escala crescentes, tem-se um limitado número de fornecedores com um grande número de clientes, o que torna pouco provável que cada cliente audite por si próprio os controles de cada fornecedor.

Assim, a solução mais comum de auditoria é o próprio fornecedor contratar serviços de auditoria externa de reconhecidas empresas especializadas, que aplicam procedimentos de auditoria padronizados e cujos relatórios são comunicados aos clientes para que estes avaliem se os riscos específicos do fornecedor são aceitáveis.

CSA (Cloud Security Alliance)

A CSA elaborou uma matriz de controles de nuvem (Cloud Controls Matrix – CCM ) como uma meta-estrutura de controles de segurança específicos para nuvem, mapeando os padrões de referência, melhores práticas e regulação governamental.

Também foi elaborado o guia “Security Guidance for Critical Areas of Focus in Cloud Computing”, com orientações e recomendações para reduzir riscos na adoção de computação em nuvem. O documento está estruturado em 14 domínios que cobrem arquitetura, governança e operações em ambiente de computação em nuvem.

AICPA (American Institute of Certified Public Accountants)

O relatório de Controles de Prestador de Serviço (Service Organization Controls – SOC) avalia controles internos do prestador de serviço em aspectos relevantes para a segurança, disponibilidade, integridade de processamento, confidencialidade e privacidade. O relatório de tipo 2 (SOC 2) relata a descrição do sistema de informação do prestador de serviço, a adequação do sistema aos seus propósitos e a efetividade operacional de seus controles internos.

Esses relatórios SOC 2 tornaram-se o padrão de referência para comparar desempenho e riscos associados de propostas de diferentes prestadores de serviço para computação em nuvem.

ENISA (European Union Agency for Network and Information Security)

A ENISA estabeleceu um quadro referencial de garantias (Cloud Computing Information Assurance Framework) destinado a avaliar o risco de adoção de serviços em nuvem, comparar ofertas de diferentes provedores de nuvem, obter garantias dos provedores de nuvem selecionados e reduzir o esforço necessário para que os provedores de nuvem forneçam garantias padronizadas e criem confiança junto aos seus clientes.

Esse quadro prevê um conjunto de questões que uma organização pode abordar junto a provedores de nuvem para assegurar-se de que eles estão protegendo adequadamente a informação que lhes foi confiada. Estas perguntas têm a intenção de fornecer uma base mínima comum, desse modo, alguma organização pode ter requisitos específicos adicionais não cobertos pelo questionário.

Similarmente, o questionário não fornece um formato padrão de resposta para o provedor de nuvem, contemplando respostas em formato de texto livre. No entanto, o conjunto das respostas deverá alimentar uma referência detalhada mais abrangente, que ainda será desenvolvida, permitindo padronizar um conjunto consistente, comparável de respostas. Tais respostas fornecerão métricas quantificáveis e poderão ser utilizadas para avaliar a maturidade do provedor. Pretende-se que essas métricas sejam coerentes e unificadas entre provedores de tal forma que os serviços oferecidos sejam facilmente comparáveis pelos usuários finais.

Assim, a solução para auditar fornecedores de serviços em nuvem, preconizada pela ENISA, é bastante semelhante ao registro de controles (STAR) da CSA e poderia ser amplamente utilizado no Brasil, elaborando-se semelhante registro das características dos principais fornecedores que atuam no mercado nacional.

Destaca-se também o documento “Cloud Computing Security Risk Assessment”, com benefícios, riscos e recomendações para segurança da informação em computação em nuvem.

NIST (National Institute of Stantards and Technology)

O NIST é uma agência federal dos EUA, cuja missão é promover inovação e competitividade industrial. O NIST edita séries de publicações especiais em suas diversas áreas de atuação, incluindo tecnologia de sistemas computacionais (SP-500-XX) e segurança de computadores (SP-800-XX).

A publicação SP 800-145, “The NIST Definition of Cloud”, apresenta a definição do NIST para computação em nuvem, a qual é adotada como referência para este trabalho.

A publicação SP 500-292, “NIST Cloud Computing Reference Architecture”, apresenta uma arquitetura de referência do NIST para computação em nuvem, incluindo uma visão dos atores envolvidos e seus papeis e dos componentes necessários para a gestão e a prestação de serviços em nuvem, como implantação (deployment), orquestração, gerenciamento, segurança e privacidade.

Na publicação SP 800-144, “Guidelines on Security and Privacy in Public Cloud Computing”, o NIST fornece uma visão geral da nuvem pública e apresenta considerações a respeito de segurança e privacidade no contexto da terceirização de dados, aplicações e infraestrutura para o ambiente de nuvem pública. São abordados aspectos de governança, conformidade, confiança, arquitetura, gerenciamento de identidade e acesso, isolamento de software, proteção de dados, disponibilidade e resposta a incidentes.

Isaca (Information Systems Audit and Control Association)

O “Controls and Assurance in the Cloud: Using COBIT 5” é uma publicação editada pela Isaca com o propósito de mostrar como o COBIT 5 pode auxiliar as organizações na avaliação do valor da computação em nuvem para o negócio em função dos riscos associados com essa nova maneira de entregar serviços de TI, bem como na implantação de controles e mecanismos de governança apropriados.

De acordo com a publicação, quando uma organização decide usar computação em nuvem para prover serviços de TI, os processos de negócios são impactados, o que torna a governança ainda mais crítica. Gerenciar riscos crescentes e assegurar a continuidade de processos críticos de negócio que são estendidos além do data center local são algumas das razões pelas quais as organizações devem implementar uma boa governança em ambiente de nuvem.

Para obter consenso na organização e estabelecer as necessidades das partes interessadas em um programa de uso de computação em nuvem, a publicação sugere uma sequência de processos do Cobit 5. Considerando necessidades em geral (como conformidade com leis, regulamentos e políticas internas), objetivos organizacionais que são particularmente importantes em um ambiente de nuvem são identificados e correlacionados com objetivos de TI e também com processos do Cobit 5 que devem ser implementados para assegurar o alcance desses objetivos.

A publicação apresenta também um guia prático para decidir se ativos devem ser movidos para a nuvem e qual modelo de serviço é o melhor para a organização. Os quatro passos recomendados são:

• Preparar o ambiente interno;

• Selecionar o modelo de serviço de nuvem;

• Selecionar o modelo de implantação de nuvem; e

• Selecionar o provedor de nuvem.

Destaca-se que: no primeiro passo é apresentado um método de cálculo de retorno de investimento (ROI – return of investment) para computação em nuvem, em que são apresentados também os benefícios (tangíveis e intangíveis), custos e desafios a serem considerados; no segundo é apresentada uma árvore de decisão para auxiliar na escolha do modelo de serviço; e no terceiro passo uma árvore de decisão para escolha do modelo de implantação.

Considerações de segurança para computação em nuvem são apresentadas com base na publicação “Cobit 5 for Information Security” (também da Isaca), incluindo relação de ameaças e correspondentes ações de mitigação.

Por causa de preocupações específicas como compartilhamento de recursos, arrendamento múltiplo e geolocalização, a computação nuvem requer uma nova abordagem para obtenção de confiança/garantia (assurance). Assim, a publicação analisa a aplicabilidade de alguns modelos e certificações ao ambiente de nuvem, bem como apresenta benefícios e desafios do uso de cada um deles.

A publicação aborda ainda alguns aspectos da parceria entre o provedor de serviços em nuvem e o cliente, que devem compartilhar responsabilidades pela gerência de ativos que residem na nuvem.

Ao final, os apêndices da publicação fornecem informações mais detalhadas sobre os tópicos abordados em cada capítulo. Destacam-se o apêndice A, que adapta o modelo de processos do Cobit 5 ao ambiente de nuvem e identifica as práticas de processos que são relevantes para usuários e provedores de serviços de nuvem (figura 35); o apêndice D, que exemplifica cenários de riscos de nuvem positivos e negativos (figura 41); e o apêndice E, que fornece uma visão geral sobre aspectos contratuais.

Conclusão do Ministro Relator no Acórdão 1739/2015

Dentre vários aspectos registrados no Voto do Ministro Relator, Benjamin Zymler, no Acórdão TCU 1739/2015-Plenário, destacamos os seguintes:

Quanto aos Benefícios

7. Ressalta a unidade instrutiva que as vantagens da computação na nuvem “decorrem essencialmente de benefícios de escala: ao consolidar centros de processamento de dados (CPDs) isolados em um pool de recursos computacionais compartilhados em nuvem, reúne-se um conjunto maior de recursos o que permite reduzir seus custos unitários, melhorar seu aproveitamento, balanceando as demandas por serviços de diversos clientes, o que otimiza o nível de uso dos recursos e divide os custos fixos em uma maior base de usuários”.

8. Especificamente quanto à administração pública, foram enfatizados os seguintes benefícios:

(a) maior agilidade da administração na entrega de serviços e em sua atualização tecnológica;

(b) suporte a iniciativas de Big Data e Dados Abertos, facilitando a abertura de informações governamentais que hoje se encontram em sistemas que controlam as operações cotidianas do Estado;

(c) atendimento a picos de demanda de serviços pela internet sem necessidade de alocar grande quantidade de recursos fixos;

(d) a contratação de serviços em nuvem de IaaS ou PaaS pode levar a uma redução de oportunidades de desvios e irregularidades, quando comparada às múltiplas contratações de máquinas, licenças de software, manutenção e suporte necessárias para a operação de CPD próprio;

(e) agilidade e economia na entrega de serviços para instituições públicas com unidades descentralizadas, que podem ter serviços disponibilizados por meio de acesso à internet.

Quanto às Incertezas

11. Especificamente quanto à utilização da computação em nuvem no âmbito da administração pública federal, a averiguação promovida pela unidade instrutiva evidenciou que, por diversos motivos, tal opção não tem sido incluída no planejamento dos gestores dessa esfera governamental.

12. Nessa linha, foram constatadas incertezas inerentes ao quadro normativo aplicável a contratações de computação em nuvem e à inexistência de uma forma consolidada para se tratarem os riscos de segurança na nuvem, aspectos estes que contribuem sobremaneira para a pouca utilização de modalidade de computação em tela.

13. Com efeito, em relação ao citado quadro normativo, destacou-se o Marco Civil da internet, no qual são estabelecidos princípios, garantias, direitos e deveres para o uso da rede mundial de computadores no Brasil.

14. Além disso, foram evidenciados o Decreto 8.135, de 2013, e a Portaria interministerial 141/2014, competindo ao primeiro, o qual dispõe sobre as comunicações de dados da administração pública, estipular que “as comunicações de dados da administração pública federal direta, autárquica e fundacional deverão ser realizadas por redes de telecomunicações e serviços de tecnologia da informação fornecidos por órgãos ou entidades da administração pública federal, incluindo empresas públicas e sociedades da economia mista da União e suas subsidiárias”.

15. É de se ressaltar que no citado decreto há diversos comandos que, por um lado, visam fomentar empresas públicas que prestam serviços de tecnologia da informação e, por outro ângulo, com foco em resguardar informações sensíveis dos órgãos da administração pública federal, limitam o fornecimento de serviços de comunicação de dados às citadas empresas públicas, devendo estas empresas ofertar satisfatoriamente os serviços.

Quanto aos Riscos

16. No tocante aos riscos, relacionados precipuamente, à segurança das informações e à disponibilidade dos serviços, destacou a unidade instrutiva que, muito embora seja possível obter vantagem competitiva e/ou econômica por meio da adoção da computação em nuvem, devem ser adotadas ações com vistas a mitigá-los.

17. Nesse sentir, a Sefti, após pontuar, com acerto, que as defesas baseadas em nuvem tendem a ser mais robustas e eficientes em virtude do ganho de escala e da maior especialização das provedoras de serviços, deixou assente que “um trabalho de levantamento e análise de riscos deve ser executado para subsidiar a decisão de migrar para a nuvem e moldar previamente o processo de contratação”, competindo a cada organização “avaliar a criticidade de cada risco levantado de acordo com sua realidade, bem como se seus controles associados são, um a um, aplicáveis ou se podem ser individualmente desconsiderados em função da análise de seu custo/benefício”.

18. Como contribuição ao controle dos diversos riscos associados à migração e à utilização da computação em nuvem, elaborou a unidade instrutiva importante tabela, contida no anexo I de seu relatório, por meio da qual são enumerados diversos riscos específicos, devidamente categorizados, bem como são apresentados controles possíveis com base em critérios internacionalmente aceitos.

Conclusão do Ministro Relator no Acórdão 1686/2019

Potenciais Requisitos para Contratação de Serviços de Computação em Nuvem

O IBGP apresenta a seguir uma tabela com os principais requisitos para contratação de serviços de computação em nuvem, elabora com base na lista de riscos e controles relacionados nas normas vigentes e, principalmente, na matriz de auditoria de serviços de computação em nuvem publicada pelo Acórdão TCU 1739/2015 (TCU 1739), que consolida a maioria dos pontos relevantes a serem observados no processo de contratação desses serviços. Também observa as Instruções Normativas SGD/ME nº 1 (IN01) e nº 2 (IN02), de 4 de abril de 2019 e o documento Boas práticas, orientações e vedações para contratação de Serviços de Computação em Nuvem (STI).

Previamente à Contratação

Boa parte das orientações do TCU envolvem aspectos da fase Planejamento da Contratação, que já mitigam riscos específicos identificados a partir de padrões internacionais, a saber:

Quadro – Aspectos prévios à contratação

Grupo	Descrição	Fonte
Planejamento	A incorporação de computação em nuvem ao plano estratégico de TI deve ser precedida de análise adequada de modo a assegurar que serviços de nuvem são a solução mais apropriada para as necessidades da organização	TCU 1739 – Risco Espec 17
Planejamento	A incorporação de computação em nuvem ao plano estratégico de TI deve ser elaborada por um time de profissionais qualificados de TI e de negócio, e todas as partes interessadas na organização devem ser consultadas	TCU 1739 – Risco Espec 17
Planejamento	Os órgãos que não possuem infraestrutura de TI própria ou que necessitem renová-la ou ampliá-la devem contratar Infraestrutura como Serviço (IaaS)	STI – item 7
Planejamento	O planejamento orçamentário deve estar alinhado com as condições de contratação de serviços de computação em nuvem, particularmente quanto à transformação de verba de investimento na compra de equipamentos de TIC para verba de custeio dos serviços de nuvem	TCU 1739 – Risco Espec 18
Planejamento	O estudo de viabilidade técnica (estudos técnicos preliminares) da contratação deve avaliar se alternativas de mercado e soluções disponíveis adequam-se à arquitetura do cliente, ou se a adaptação da arquitetura do cliente à do provedor é viável	TCU 1739 – Risco Espec 43
Plano de Contingência	O plano de continuidade de negócio deve considerar as partes do negócio que estejam na nuvem e levar em consideração tanto as características do negócio envolvido e do provedor a selecionar	TCU 1739 – Risco Espec 1
Plano de Contingência	Deve ser definido e documentado um método para determinar o impacto de qualquer indisponibilidade à organização, incluindo de serviços que estão na nuvem, que deverá, também, estabelecer prioridades para recuperação e período máximo tolerável para a indisponibilidade	TCU 1739 – Risco Espec 2
Plano de Contingência	Especialmente no caso de informações críticas para o negócio, convém considerar a execução de plano de backup independente do fornecedor, duplicando dados em intervalos periódicos	TCU 1739 – Risco Espec 30, 31, 32 e 33
Segurança de Dados	Os dados devem ser submetidos à classificação prévia da informação, antes de serem transmitidos para a nuvem	TCU 1739 – Risco Espec 3
Segurança de Dados	Definição os serviços de Tecnologia da Informação e Comunicação (TIC), no todo ou em parte, que possam comprometer a segurança nacional, conforme os requisitos de confidencialidade, integridade, disponibilidade e autenticidade das informações envolvidas, em conformidade com a IN Nº 01 GSI/PR/2008 e suas Normas Complementares	STI – item 2
Segurança de Dados	Implementar controle de acesso lógico apropriado ao grau de confidencialidade dos dados armazenados na nuvem	TCU 1739- Risco Espec 3
Segurança de Dados	Utilizar técnicas de marca d’água para identificar origens de vazamento de informações sigilosas	TCU 1739 – Risco Espec 36
Segurança de Dados	Implementar controles para transferência de dados, como criptografia e uso de VPN adequada	TCU 1739 – Risco Espec 4
Segurança de Dados	Estabelecer políticas e procedimentos para o uso de criptografia, incluindo gerenciamento de chaves criptográficas, que devem ser seguidos pelo cliente e pelo provedor	TCU 739 – Risco Espec 5
Segurança de Dados	As chaves criptográficas não devem ser armazenadas na nuvem	TCU 1739 – Risco Espec 5
Segurança de Dados	Os dados armazenados no provedor devem estar criptografados, sendo que o esquema criptográfico deve ser adequado à classificação das informações	TCU 1739 – Risco Espec 5, 6 e 36
Política de RH	Deve ser conduzida política de recursos humanos de TI que contemple redefinições de funções e realocações de pessoal, considerando as capacidades e perfis individuais	TCU 1739 – Risco Espec 19
Política de RH	Implementar política institucional de incentivo à inovação, como forma de estimular o servidor e quebrar resistência à adoção de computação em nuvem	TCU 1739 – Risco Espec 19
Política de RH	Promover política institucional de incentivo à inovação de maneira a convertê-la em parte da cultura organizacional	TCU 1739 – Risco Espec 22
Modelo de Serviço	Recomenda-se aos órgãos contratar preferencialmente Nuvem Híbrida, como Modelo de Implantação, de fornecedor público ou privado, valendo-se dos benefícios dos modelos de nuvem pública (elasticidade e agilidade) e privada (desempenho garantido devido ao recurso dedicado).	STI – item 3
Portabilidade da Infraestrura e Dados	O plano de continuidade de negócio para nuvem pode considerar mais de um provedor como contingência	TCU 1739 – Risco Espec 1
Portabilidade da Infraestrura e Dados	Considerar a alternativa de utilizar sua própria infraestrutura de TI como contingência	TCU 1739 – Risco Espec 1
Portabilidade da Infraestrura e Dados	Estabelecer processos ágeis de contratação e migração para provedores alternativos, em caso de falhas do provedor principal	TCU 1739 – Risco Espec 20 e 21
Portabilidade da Infraestrura e Dados	Prever soluções de contingência independentes de provedor específico (portabilidade do serviço para outro fornecedor, contrato de contingência em caso de falha do fornecedor principal, espelhamento do serviço em infraestrutura própria etc)	TCU 1739 – Risco Espec 26
Portabilidade da Infraestrura e Dados	Os requisitos da organização para portabilidade e interoperabilidade devem ser cuidadosamente avaliados antes da contratação de nuvem frente às alternativas disponíveis no mercado, a fim de mitigar relações de dependência com o provedor	TCU 1739 – Risco Espec 30, 31, 32 e 33
Portabilidade da Infraestrutura e Dados	Os órgãos deverão assegurar que o serviço a ser contratado permita a portabilidade de dados e aplicativos e que as informações do órgão contratante estejam disponíveis para transferência de localização, em prazo adequado e sem custo adicional, de modo a garantir a continuidade do negócio e possibilitar a transição contratual	STI – item 11
Portabilidade da Infraestrura e Dados	Processos, procedimentos e recursos devem ser estabelecidos e testados, de maneira a viabilizar a transferência de operações de um provedor de computação em nuvem para outro provedor alternativo	TCU 1739 – Risco Espec 30, 31, 32 e 33
Portabilidade da Infraestrura e Dados	O provedor deve utilizar soluções de virtualização que sejam padrões ou referências de mercado	TCU 1739 – Risco Espec 37 e 38
Preparação da Infraestrutura de Rede	Contratos do cliente com provedores de rede devem ser revisados a fim de adequá-los a novos parâmetros, como latência e perda de pacotes, próprios de requisitos das aplicações pretendidas em nuvem	TCU 1739 – Risco Espec 41
Preparação da Infraestrutura de Rede	Deve-se buscar garantir que os mecanismos de monitoração das redes consigam distinguir entre problemas internos, na rede dos provedores, ou fora do seu escopo	TCU 1739 – Risco Espec 41
Conformidade com legislação vigente	A organização deve ser capaz de assegurar a conformidade dos dados e aplicações hospedadas na nuvem com os requisitos de padrões, legais e regulatórios, aos quais o negócio está sujeito, de maneira contínua e atualizada	TCU 1739 – Risco Espec 23
Conformidade com legislação vigente	Verificar, na fase de planejamento da contratação, se o objeto da contratação pode ser enquadrado como “comunicação de dados da APF”, conforme a Portaria Interministerial 141/2014, art. 1º e art. 11	TCU 1739 – Risco Espec 24
Conformidade com legislação vigente	Até o término da fase de planejamento da contratação, verificar se a contratação deve ser feita por meio de provedor público ou privado, consultando a disponibilidade dos provedores públicos de atender às especificações técnicas e níveis de serviço do objeto da contratação, conforme a Portaria Interministerial 141/2014, art. 5º, § 3º	TCU 1739 – Risco Espec 24
Conformidade com legislação vigente	Especialmente no caso de contratação de fornecedor privado, observar os requisitos comuns de implementação dos serviços estabelecidos pela Portaria Interministerial 141/2014: padrões do e-Ping (art. 8º) e obrigações que deverão estar contidas no termo de referência ou projeto básico e no contrato (art. 9º)	TCU 1739 – Risco Espec 24
Conformidade com legislação vigente	Especialmente no caso de contratação de fornecedor privado, observar os requisitos específicos de implementação dos serviços estabelecidos pela Portaria Interministerial 141/2014: requisitos mínimos para serviços de redes de telecomunicações (art. 10) e critérios mínimos de segurança da informação (art. 12)	TCU 1739 – Risco Espec 24
Conformidade com legislação vigente	Especialmente no caso de contratação de fornecedor privado, observar os requisitos de auditoria de programas e equipamentos estabelecidos pela Portaria Interministerial 141/2014 (arts. 13 e 14), os quais deverão estar previstos no termo de referência ou projeto básico e no contrato	TCU 1739 – Risco Espec 24
Conformidade com legislação vigente	No caso de infraestrutura de nuvem para sistemas estruturantes da APF, contratar órgão ou entidade da APF (item 4.2.3 da Norma Complementar 19/IN01/DSIC/GSIPR)	TCU 1739 – Risco Espec 25
Conformidade com legislação vigente	Antes de adotar a tecnologia de computação em nuvem, observar as diretrizes da sua Política de Segurança da Informação e Comunicações (SIC), do seu processo de Gestão de Riscos de SIC e do seu processo de Gestão de Continuidade de Negócios nos aspectos relacionados à SIC (item 5.1 da Norma Complementar 14/IN01/DSIC/GSIPR)	TCU 1739 – Risco Espec 25

Requisitos Habilitadores e Contratuais

Ainda com base em frameworks internacionais as orientações normativas estabelecem necessidade de registro contratual de pontos relevantes envolvendo contratação de serviços de computação em nuvem.

Os provedores devem ser capazes de atender aos requisitos habilitadores e contratuais recomendados pelos órgãos normativos e de controle, a saber:

Quadro – Itens Contratuais Relevantes

Grupo	Descrição	Fonte
Papeis e Responsabilidades	Definir e formalizar, no contrato, papéis e responsabilidades do provedor de serviços de nuvem e do cliente	TCU 1739 – Risco Espec 20, 21 e 28
Acordo de Nível de Serviços	Definir cláusulas contratuais especificando nível esperado dos serviços (SLA) e mecanismos clássicos de gestão contratual de serviços terceirizados (comunicações formais, multas, rescisão etc)	TCU 1739 – Risco Espec 20 e 21
Acordo de Nível de Serviços	Os SLAs com o provedor de nuvem devem ser cuidadosamente definidos e exequíveis, o que inclui penalidades em caso de não cumprimento	TCU 1739 – Risco Espec 1 e 42
Acordo de Nível de Serviços	Prever dispositivos contratuais que busquem assegurar os níveis de serviço no caso de interrupções de serviço planejadas ou não planejadas	TCU 1739 – Risco Espec 26
Acordo de Nível de Serviços	Definir em contrato modelo de remuneração vinculada aos níveis de serviço estabelecidos, prevendo glosas no caso de descumprimento de parâmetros mínimos	TCU 1739 -Risco Espec 26
Acordo de Nível de Serviços	Definir em contrato sanções no caso de descumprimento reiterado de parâmetros mínimos de níveis de serviço estabelecidos	TCU 1739 – Risco Espec 26
Acordo de Nível de Serviços	Estabelecer no contrato indicadores claros e precisos tanto de ambiente como de segurança, com responsáveis pelo seu monitoramento e disponibilização	TCU 1739 – Risco Espec 28
Monitoramento do Provedor	Definir no contrato as obrigações do provedor quanto a requisitos mínimos de contratação de pessoal e de monitoramento de suas atividades, bem como a respeito da necessidade de divulgação ao cliente de suas políticas e orientações específicas	TCU AC 1739/15 Risco Espec 15
Monitoramento do Provedor	Políticas, procedimentos e mecanismos devem ser estabelecidos e implementados pelo provedor para gerenciamento de vulnerabilidades conhecidas e atualizações de software, garantindo que aplicações, sistemas e vulnerabilidades de dispositivos de rede sejam avaliadas, e que atualizações de segurança fornecidas sejam aplicadas em tempo hábil, priorizando os patches mais críticos	TCU 1739 – Risco Espec 16
Monitoramento do Provedor	Definir em cláusula contratual a necessidade de realização de avaliações periódicas independentes, com a finalidade de verificar a adequação dos controles do provedor a um conjunto de critérios pré-definidos	TCU 1739 – Risco Espec 20 e 21
Monitoramento do Provedor	Assegurar que todas as vulnerabilidades sejam priorizadas e corrigidas dentro de SLAs acordados contratualmente entre cliente e provedor	TCU 1739 – Risco Espec 27
Monitoramento do Provedor	O processo de gestão de vulnerabilidades do provedor deve ser transparente ao cliente	TCU 1739 – Risco Espec 27
Monitoramento do Provedor	Prever verificações intermediárias do nível de uso da capacidade contratada, alertas quando atingidos patamares de recursos e tetos de recursos máximos utilizáveis em função do orçamento disponível	TCU 1739 – Risco Espec 29
Monitoramento do Provedor	Definir no contrato as obrigações do provedor quanto a requisitos mínimos de autorização e transparência de acesso do provedor aos ativos físicos e virtuais do cliente, bem como a respeito da necessidade de divulgação ao cliente de suas políticas e orientações específicas	TCU 1739 – Risco Espec 14
Segurança da Informação	O ambiente de serviço dos fornecedores privados devem estar em conformidade com a norma ABNT NBR ISO/IEC 27001:2013, sem prejuízo de outras exigências, objetivando mitigar riscos relativos à segurança da informação	STI – item 4
Segurança da Informação	Definir cláusulas contratuais estabelecendo limites do acesso do provedor aos dados do cliente	TCU 1739 – Risco Espec 5
Segurança da Informação	O modelo de segurança das interfaces do provedor deve ser desenvolvido com base em padrões de mercado, incluindo mecanismos de autenticação forte de usuários e controle de acesso para restringir o acesso aos dados do cliente	TCU 1739 – Risco Espec 13
Segurança da Informação	O provedor deve garantir controles eficazes e compatíveis com as políticas e procedimentos do cliente para gerenciamento de identidades de usuários e controle de acessos	TCU 1739 – Risco Espec 8
Garantias da propriedade intelectual	Definir cláusulas contratuais especificando mecanismos de segurança e proteção de propriedade intelectual, e quaisquer requisitos legais ou regulatórios	TCU 1739 – Risco Espec 20 e 21
Garantias de acesso e propriedade dos dados	O contrato entre cliente e provedor deve estabelecer direitos claros e exclusivos de propriedade e acesso aos dados, inclusive referentes a logs	TCU 1739 – Risco Espec 12
Garantias de acesso e propriedade dos dados	Avaliar quais informações serão hospedadas na nuvem, considerando o processo de classificação da informação, o valor do ativo de informação, os controles de acesso físicos e lógicos, o modelo de serviço e de implementação de computação em nuvem e a localização geográfica onde as informações serão armazenadas (item 5.3 da Norma Complementar 14/IN01/DSIC/GSIPR)	TCU 1739 – Risco Espec 25
Garantias de acesso e propriedade dos dados	Ao contratar ou implementar um serviço de computação em nuvem, garantir que o ambiente, incluindo infraestrutura e canal de comunicação, esteja aderente às diretrizes e normas de SIC do GSI/PR, que a legislação brasileira prevaleça e que o contrato de prestação de serviço contenha cláusulas de segurança quanto às informações hospedadas na nuvem (item 5.2 da Norma Complementar 14/IN01/DSIC/GSIPR)	TCU 1739 – Risco Espec 25 e 34
Controle de Logs	Logs de auditoria do provedor que registram atividades de acesso de usuários privilegiados, tentativas de acesso autorizados e não autorizados, exceções do sistema, e eventos de segurança da informação devem ser mantidos em conformidade com as políticas e regulamentos aplicáveis, e devem estar de acordo com as políticas do cliente	TCU 1739 – Risco Espec 10
Controle de Logs	O cliente deve prever cópia dos logs fornecidos pelo provedor, de acordo com sua própria política de retenção; deve haver, da parte do provedor, um mecanismo para filtragem e cópia dos logs gerados pelo fornecedor para a área do cliente	TCU 1739 – Risco Espec 11
Controle de Logs	O acesso e uso de ferramentas de auditoria que interajam com os sistemas de informação das organizações deverão estar devidamente segmentados e restritos para evitar comprometimentos e uso indevido de dados de log	TCU 1739 – Risco Espec 12
Isolamento da infraestrutura	O provedor deve implementar controles para isolamento e segurança de sistema operacional	TCU 1739 – Risco Espec 37 e 38
Isolamento da infraestrutura	Definir cláusulas contratuais estabelecendo responsabilidade do provedor em garantir o isolamento de recursos e dados contra acesso indevido por outros clientes	TCU 1739 – Risco Espec 7
Isolamento da infraestrutura	O provedor deve garantir e demonstrar isolamento de recursos e de dados de seus clientes	TCU 1739 – Risco Espec 7
Isolamento da infraestrutura	Os órgãos deverão assegurar que as informações sob custódia do fornecedor serão tratadas como informações sigilosas, não podendo ser usadas por este fornecedor ou fornecidas a terceiros, sob nenhuma hipótese, sem autorização formal do contratante	STI – item 12
Elasticidade e Flexibilidade	Os provedores devem utilizar pacotes modulares, usar formatos abertos ou populares para dados e serviços, e serem transparentes em regulações e taxas aplicadas à transferência de dados	TCU 1739 – Risco Espec 30, 31, 32 e 33
Disponibilidade	Os órgãos deverão exigir disponibilidade de no mínimo, 99,741% para os data centers onde os serviços estarão hospedados, aceita a comprovação por meio de certificação TIA 942 TIER II	STI – item 10
Gestão de Configuração	O provedor deve implementar política de atualização de versão de software e aplicação de correções	TCU 1739 – Risco Espec 37 e 38
Gestão de Incidentes	Cláusulas contratuais devem definir políticas e procedimentos que devem ser estabelecidos para triagem dos eventos relacionados à segurança e garantir o gerenciamento de incidentes completo e ágil	TCU 1739 – Risco Espec 10
Gestão de Incidentes	Eventos de segurança de informação devem ser comunicados através de canais predefinidos de comunicação, de maneira rápida e eficiente, e de acordo com os requisitos legais, regulatórios e contratuais	TCU 1739 – Risco Espec 10
Gestão de Incidentes	O contrato deve detalhar definições específicas de incidentes, eventos, ações a serem tomadas e responsabilidades do provedor e do cliente	TCU 1739 – Risco Espec 39 e 40
Gestão de Incidentes	O contrato deve definir requisitos de interoperabilidade entre as ferramentas de gestão de incidentes do provedor e do cliente	TCU 1739 – Risco Espec 39 e 40
Gestão de Mudanças	A política para gestão de mudanças deve ser acordada entre provedor e cliente, e este último deve ser comunicado com antecedência sobre mudanças (por exemplo, utilizando processos do ITIL)	TCU 1739 – Risco Espec 9
Limites Geográficos	O provedor deve ter capacidade de trabalhar com multirregiões em seu ambiente e ser capaz de transferir carga de uma região para outra, em prazo máximo especificado em contrato	TCU 1739 – Risco Espec 1
Limites Geográficos	O provedor deve assegurar que dados sujeitos a limites geográficos não sejam migrados para além de fronteiras definidas em contrato	TCU 1739 – Risco Espec 6 e 35
Limites Geográficos	Os órgãos deverão exigir, por meio de cláusulas contratuais, em conformidade com o disposto na NC 14/IN01/DSIC/GSIPR, que os dados e informações do contratante residam exclusivamente em território nacional, incluindo replicação e cópias de segurança (backups), de modo que o contratante disponha de todas as garantias da legislação brasileira enquanto tomador do serviço e responsável pela guarda das informações armazenadas em nuvem	STI – item 8
Ruptura Contratual	Prever em contrato condições e limites claros de custos para saída do provedor	TCU 1739 – Risco Espec 30, 31, 32 e 33
Ruptura Contratual	Deve ser previsto contratualmente que o provedor atenda à política de exclusão de dados do cliente	TCU 1739 – Risco Espec 36

Comparação de Soluções de Mercado em Computação em Nuvem

Para o site Right Scale a maioria das empresas têm uma estratégia multi-nuvem, mas escolher a nuvem certa para determinada carga de trabalho pode ser um desafio. Nesse sentido oferecem uma ferramenta gratuita para comparar as características de nuvem pública e ajudar na tomada decisão sobre cada carga de trabalho.

A Ferramenta da Right Scale compara as soluções da Amazon, Google, Microsoft e IBM, analisando as seguintes características:

• Security Certifications
• Operating Systems
• Regions
• Countries
• Compute Services
• Network Services
• Storage Services
• Relational Databases
• Non-Relational Databases
• Other DBaaS
• Data & Analytics Services
• Application Services
• Security & Identity.

Por outro lado, a IBM indica o portal da solução de Cloud Brokerage que faz Gestão Multi-Cloud + Análise Comparativa dos vários provedores de cloud, por requisitos técnicos, workloads, preço etc.