A questão da cloud europeia não é onde o servidor está
Um local pode ser verdadeiro e ainda assim deixar a questão em aberto
Há um momento familiar numa conversa sobre cloud. Alguém pergunta onde os dados serão armazenados. Outra pessoa responde com o nome de uma cidade europeia. A sala relaxa um pouco. A resposta pode ser perfeitamente exata, e pode importar muito. A geografia afeta a latência, a segurança física, a eletricidade, o planeamento de resiliência, o emprego, a responsabilização pública e os acordos legais em torno de um serviço. Uma autoridade pública que precise de que determinados registos permaneçam dentro de um território declarado tem uma razão legítima para perguntar. O problema começa quando o nome da cidade é usado para resolver todas as outras questões do acordo.
Um servidor está algures. Um serviço não está. Um serviço é uma relação entre entidades legais, pessoas com direitos de administrador, componentes de software, fornecedores de hardware, contratos, equipas de suporte, redes, acordos de encriptação, subcontratantes e o cliente que depende do resultado. O edifício é uma parte material dessa relação. Não revela quem pode emitir uma instrução privilegiada a partir de outro local, que grupo empresarial controla a empresa operadora, que jurisdição pode alcançar um fornecedor, se um subprocessador mudou, ou o que o cliente pode levar consigo quando o contrato termina.
Este não é um argumento contra centros de dados europeus ou fornecedores europeus. É um argumento contra deixar que uma resposta útil faça um trabalho que não pode fazer. A questão europeia da cloud não é se um servidor pode ser colocado em solo europeu. É se a organização que utiliza o serviço consegue compreender e exercer controlo suficiente sobre todo o acordo para o trabalho em causa. A localização pertence a essa resposta. Não pode ser a resposta inteira, tal como o endereço de uma empresa não nos diz quem tem as chaves das suas contas.
A distinção importa mais onde a cloud está a fazer trabalho comum e consequente. Uma autarquia pode ter correspondência, processos e informação pública num ambiente alojado. Um fabricante pode ter projetos e dados operacionais. Um grupo de investigação pode ter um conjunto de dados que não pode ser movido levianamente. Um hospital pode usar serviços que tocam em informação pessoal. Nenhum destes exemplos exige uma falha dramática ou um romance de espionagem para se tornar sério. A questão diária é mais simples: quem tem autoridade prática sobre um sistema que se tornou parte da capacidade da organização para trabalhar?
A lei e as orientações europeias tratam cada vez mais isto como uma questão de provas, papéis e mudança, em vez de uma questão de vocabulário tranquilizador. O Regulamento Dados dá aos clientes direitos e aos fornecedores deveres em torno da mudança, dos dados exportáveis e das interfaces para serviços de processamento de dados. A AEPD diz há muito tempo que as instituições europeias que utilizam serviços de cloud continuam responsáveis pelas suas obrigações de proteção de dados. O trabalho de risco da cloud da ENISA nomeia o aprisionamento e o risco legal como aspetos a avaliar. Estes não são instrumentos idênticos, e não criam uma doutrina única de cloud. Juntos, apontam numa direção útil: o controlo tem de ser descrito, não implícito.
O pino do mapa e o plano de controlo
A linguagem da cloud muitas vezes torna a distinção mais difícil de ver. A palavra cloud sugere um sistema meteorológico: grande, distante e talvez inevitável. Na prática, um serviço de cloud tem um plano de controlo e um plano de trabalho. O plano de trabalho é onde uma carga de trabalho corre, os dados são armazenados, os pedidos são processados e os resultados são devolvidos. O plano de controlo é o conjunto de mecanismos através dos quais as identidades são geridas, as políticas são alteradas, o software é atualizado, a capacidade é atribuída, o suporte é prestado, os registos são recuperados e os sistemas são parados ou restaurados. Ambos os planos podem ser tecnicamente distribuídos. Ambos podem atravessar fronteiras organizacionais.
Uma declaração de localização fala normalmente, em primeiro lugar, do plano de trabalho. Pode indicar onde se encontra uma determinada loja de dados, máquina virtual ou região. Essa informação deve ser suficientemente específica para ser útil. Deve indicar o que abrange, que categorias de dados lhe dizem respeito, como as alterações são comunicadas e se as cópias de segurança, registos, informações de suporte e dados derivados seguem a mesma regra. Uma afirmação que apenas diga Europa, sem uma fronteira, é um ponto de partida para uma pergunta, e não uma resposta. A Europa é um lugar grande, e a arquitetura de serviços é dada a exceções.
O plano de controlo coloca uma série diferente de perguntas. Quem pode criar ou remover um administrador? Quem aprova uma intervenção de emergência? Quem opera o serviço de identidade? Quem pode ver informações de diagnóstico? Que empresa mantém o software que faz a plataforma funcionar? Que entidade legal recebe um pedido de uma autoridade? Que subcontratado está autorizado a tratar do suporte? Que parte pode alterar uma descrição de serviço ou descontinuar uma funcionalidade? Um cliente pode conseguir iniciar sessão todos os dias e, ainda assim, não ter qualquer via independente para responder a nenhuma destas perguntas.
Isto não significa que os clientes devam esperar operar todos os dispositivos físicos. Normalmente não podem, e a maioria não precisa. O objetivo é tornar a delegação visível. A operação delegada pode ser responsável e eficiente quando os poderes delegados estão definidos, monitorizados e são reversíveis. Torna-se um problema de soberania quando o cliente tem apenas um rótulo contratual para o controlo, enquanto o fornecedor mantém as pessoas, interfaces, registos e conhecimento técnico necessários para o exercer. Um contrato que não pode ser usado na prática é um objeto decorativo com boa tipografia.
Para um comprador, a consequência prática é direta. Mantenha a pergunta sobre a localização. Acrescente a pergunta sobre o controlo ao lado. Pergunte onde está a carga de trabalho e depois pergunte quem pode alterar as suas condições. Pergunte onde os dados são processados e depois pergunte quem pode aceder à via administrativa. Pergunte onde está a cópia de segurança e depois pergunte quem pode restaurá-la e sob que autoridade. As respostas podem ser satisfatórias. Podem expor uma dependência que tem de ser aceite deliberadamente. Qualquer um dos resultados é melhor do que descobrir que um pino num mapa estava a fazer o trabalho de um modelo operacional.
A propriedade não é um detalhe administrativo
A propriedade é por vezes tratada como um debate separado sobre bandeiras, bolsas de valores e orgulho nacional. É mais concreta do que isso. A propriedade pode determinar quem nomeia o conselho de administração, quem aprova uma venda, quem dirige o investimento, quem detém a propriedade intelectual, que políticas de grupo se aplicam e que entidade decide, em última instância, se um serviço continua a ser uma linha de negócio. Um cliente não precisa de uma regra simplista segundo a qual apenas uma estrutura de propriedade é aceitável. Precisa de conhecer a estrutura antes de considerar o acordo independente.
A organização empresarial também afeta o significado de uma promessa de cloud. Uma marca pode ser local enquanto o serviço é operado por uma entidade diferente. Uma subsidiária europeia pode contratar com um cliente europeu enquanto um grupo noutro local fornece software essencial, operações de segurança, suporte, faturação, análise de dados ou autoridade executiva. Um parceiro local pode contribuir genuinamente com trabalho de implementação valioso enquanto depende de uma plataforma que não pode alterar. Nenhum destes acordos é automaticamente impróprio. São acordos de controlo diferentes e não devem ser apresentados como idênticos por um logótipo partilhado e um número de telefone local.
A questão relevante não é se um comprador consegue encontrar uma ligação estrangeira algures numa cadeia de abastecimento longa. A tecnologia moderna é interligada, e testes de pureza não são um método de aquisição. A questão é onde uma dependência se torna decisiva. Que entidade pode alterar o contrato? Que entidade controla a propriedade intelectual do serviço? Que entidade pode assumir um compromisso de suporte? Que entidade tem as credenciais ou o conhecimento necessários para recuperar a função? Que entidade pode ser comprada, sancionada, reorganizada ou instruída de uma forma que altere a posição do cliente? Essas são questões sobre influência real.
A propriedade também muda. Uma aquisição, uma ronda de financiamento, uma reestruturação ou uma transferência interna podem alterar o quadro de controlo sem mover um único servidor. Uma cláusula de localização redigida na assinatura pode permanecer factualmente correta enquanto os factos organizacionais à sua volta mudaram. É por isso que um ficheiro de cloud sério precisa de um processo de alteração. O cliente deve saber qual alteração tem de ser divulgada, quem avaliará o seu efeito, que provas têm de ser atualizadas e que autoridade pode suspender um novo fluxo de dados enquanto a avaliação é feita. Não é um trabalho glamoroso. Tão pouco é verificar o óleo de um carro, o que talvez explique porque é que as pessoas se lembram disso depois de o motor se queixar.
Nas suas orientações de cloud de 2018, a EDPS sublinhou que as instituições da UE continuam responsáveis pelas suas obrigações de proteção de dados quando utilizam serviços de cloud computing e devem garantir um nível de proteção equivalente ao de outros modelos de infraestrutura. Isso não é uma exigência de que cada instituição seja dona de tudo. É um lembrete de que externalizar uma função não externaliza o dever de compreender o acordo. O dever torna a propriedade relevante porque a responsabilidade não pode ser exercida através de um diagrama que omite a parte com o poder prático.
O alcance legal não é apagado por um endereço europeu
A jurisdição é muitas vezes a camada mais desconfortável porque resiste à resposta simples. Um contrato pode escolher uma lei aplicável e um tribunal. Essas escolhas importam. Não fazem desaparecer outros poderes legais. O alcance legal pode seguir uma entidade, um estabelecimento, um prestador de serviços, um grupo empresarial, uma pessoa com acesso, um fornecedor de hardware ou a localização e a natureza de dados específicos. A análise exata depende dos factos e da lei. Um blogue não pode resolver isso para uma organização real, e um modelo de aquisição não pode substituir aconselhamento adequado quando o risco é material.
A disciplina útil é separar uma questão legal de uma afirmação geográfica. Um centro de dados na União Europeia diz-nos onde o equipamento está situado. Não nos diz por si só que entidades podem ser obrigadas, que autoridades podem fazer um pedido, que notificação é possível, ou se um fornecedor tem obrigações ao abrigo de outra ordem jurídica. Tratar os dois como equivalentes pode produzir uma falsa sensação de conclusão. O comprador pode ter satisfeito um requisito de residência enquanto deixa a análise legal completamente por fazer.
As orientações finais da EDPB sobre a interação entre o artigo 3.º do RGPD e o capítulo V sobre transferências internacionais são úteis precisamente porque resistem a atalhos. Distinguem o âmbito territorial do RGPD da questão de saber se uma operação de tratamento é uma transferência internacional. Essa distinção não fornece uma conclusão universal sobre todos os acordos de cloud. Mostra, no entanto, porque é que expressões como baseado na UE ou abrangido pelo RGPD não podem suportar todas as inferências legais que um comprador possa querer fazer. A análise de proteção de dados segue o tratamento e os atores reais.
O Regulamento dos Dados traz uma questão conexa para o domínio dos serviços em nuvem. O seu Capítulo VII diz respeito ao acesso governamental internacional ilícito e à transferência de dados não pessoais detidos na União. O Regulamento exige que os prestadores de serviços de processamento de dados adotem medidas técnicas, organizativas e jurídicas adequadas, incluindo medidas contratuais, nas circunstâncias descritas no artigo 32.º. Não promete que um prestador possa fazer desaparecer todos os pedidos externos. Exige uma resposta disciplinada a um conflito que não pode ser afastado por um termo de marketing.
Para os clientes, o trabalho imediato é um mapa de evidências. Identificar a entidade contratante, as entidades prestadoras que operam partes materiais do serviço, os locais onde os dados e a administração ocorrem, as jurisdições declaradas, o percurso para receber e contestar pedidos, as condições de notificação e o aconselhamento jurídico necessário para a carga de trabalho específica. Marcar o que é conhecido, o que é declarado pelo fornecedor, o que está contratualmente comprometido e o que ainda precisa de investigação. Um mapa com uma data e uma lacuna é mais útil do que um parágrafo de garantia perpétua.
O controlo operacional é onde uma promessa se torna real
O controlo operacional é a capacidade de fazer um sistema executar algo, ou deixar de o executar, através de uma autoridade e mecanismo definidos. Inclui coisas banais: criar uma conta, alterar uma política de rede, rodar uma chave, restaurar uma cópia de segurança, aprovar uma versão, isolar um inquilino, retirar um administrador, inspecionar um registo e exportar um registo. Nenhuma destas ações é um certificado de soberania. Em conjunto, mostram se o cliente e o prestador têm uma divisão de responsabilidades inteligível.
Um acordo de nuvem é fraco quando todas as ações consequentes terminam com um e-mail para um endereço de suporte genérico. O suporte é importante, e o suporte especializado pode ser uma das boas razões para utilizar um serviço gerido. Mas uma organização crítica deve distinguir entre um percurso de suporte e um percurso de autoridade. Um percurso de suporte é como o prestador ajuda. Um percurso de autoridade é como o cliente pode iniciar, aprovar, observar e registar uma ação pela qual permanece responsável. Os dois podem encontrar-se num ticket. Não devem ser confundidos.
Consideremos um caso claramente hipotético. Um consórcio de investigação europeu utiliza um ambiente analítico alojado para um projeto sensível mas lícito. Tem um contrato de região europeia e uma localização de dados documentada. Durante uma revisão interna, o consórcio quer suspender um pipeline específico, preservar os registos associados e impedir que uma nova fonte de dados seja ligada até a revisão terminar. As perguntas úteis não são se um operador imaginário se comporta heroicamente. São se o consórcio tem uma função nomeada capaz de ordenar a alteração, se a plataforma expõe um mecanismo controlado, se a ação é registada e se os fluxos dependentes são visíveis antes de o interruptor ser utilizado.
O hipotético é deliberadamente discreto porque a autoridade comum é o ponto. Um serviço não precisa de falhar para o cliente precisar de controlo. Uma revisão de privacidade, mudança de finalidade, decisão de aquisição, disputa contratual, preocupação de segurança ou saída de pessoal podem exigir uma ação limitada. Se ninguém sabe quem pode tomá-la, ou se o cliente não pode inspecionar o que a ação fez, o problema não é que a nuvem seja misteriosa. O problema é que o modelo operacional nunca foi concluído.
Um bom controlo operacional não é necessariamente centralizado. Uma grande instituição pode dividir responsabilidades entre um responsável pelo serviço, uma função de segurança, uma função de proteção de dados, uma equipa de operações e um fornecedor. A divisão pode reduzir o risco de uma pessoa tomar sozinha uma decisão prejudicial. O importante é que a fronteira de autoridade seja legível. Cada função deve saber o que pode iniciar, o que pode aprovar, o que deve registar, quando deve escalar e como a organização recupera quando a pessoa habitual não está disponível. A nuvem não está isenta de governação só porque o seu painel é limpo.
A linha de subcontratação faz parte do serviço
A maioria dos serviços de nuvem não é prestada por uma única empresa que utiliza um único edifício e uma única pilha de software. Podem envolver fornecedores de infraestrutura, operadores de rede, serviços de segurança geridos, parceiros de suporte, processadores de pagamentos, mantenedores de software, serviços de identidade, fabricantes de hardware e subcontratantes especializados. Uma cadeia complexa não é prova de falha. É uma razão para descrever a cadeia. O cliente precisa de saber onde começam as dependências materiais, o que lhe é permitido fazer e como uma alteração será comunicada.
O vocabulário de proteção de dados de responsável pelo tratamento e subcontratante é útil aqui, mas não deve tornar-se um substituto da compreensão. Uma lista de subcontratantes pode identificar organizações que processam dados pessoais em nome de um fornecedor. Pode não responder a todas as questões operacionais sobre fornecimento de software, suporte de hardware, administração remota, telemetria, resposta a incidentes ou autoridade corporativa. Inversamente, um inventário de engenharia pode identificar componentes mas omitir quem tem uma obrigação contratual para com o cliente. As duas perspetivas precisam de ser lidas em conjunto, em vez de serem usadas como documentos concorrentes.
A orientação da EDPS sobre a nuvem recomenda uma atribuição clara de responsabilidades e atenção aos papéis das partes envolvidas nos serviços de nuvem. Essa preocupação prática permanece pertinente porque os modelos de prestação complexos podem criar a impressão de que a responsabilidade se evaporou na arquitetura. Não se evaporou. Alguém continua a decidir a finalidade de uma operação de tratamento. Alguém continua a definir as condições técnicas. Alguém continua a aceitar um subcontratante. Alguém continua a ter de explicar o que aconteceu quando um sistema muda. A complexidade pode explicar por que razão a resposta demora. Não torna a pergunta irrazoável.
Existe um teste útil para a materialidade. Se um fornecedor desaparecesse do acordo amanhã, o serviço perderia uma função de que o cliente precisa, perderia uma propriedade de segurança, perderia o acesso a um registo ou perderia a capacidade de migrar? Se a resposta for sim, esse fornecedor pertence ao mapa de controlo. O mapa não tem de expor cada resistência nem tornar pública todas as relações comerciais. Tem de mostrar as dependências que alteram a capacidade do cliente de governar o trabalho. Uma dependência oculta não é uma abstração inteligente. É uma reunião futura com um tom ligeiramente diferente.
O controlo de subcontratantes também depende do tempo. O comprador deve saber como são introduzidos novos subcontratantes e fornecedores operacionais materiais, que aviso é dado, que processo de objeção ou avaliação se aplica e como uma alteração é registada. Uma lista estática é melhor do que nenhuma lista. Uma lista atual e revista é melhor porque reconhece que um serviço não fica congelado na assinatura. A organização não pode governar as dependências de que não é informada que chegaram.
O hardware tem uma política e uma consequência operacional
É tentador parar a análise na interface do software. O serviço funciona, o painel está no idioma certo, o contrato menciona uma região europeia e a infraestrutura subjacente parece demasiado remota para ser útil. No entanto, o hardware e a sua cadeia de suporte podem ser decisivos quando estão em causa disponibilidade, confidencialidade, manutenção, reparação, capacidade ou continuidade. A questão não é se o cliente deve auditar cada chip. A questão é se o cliente sabe quais dependências tornam possível o serviço escolhido e o que acontece quando uma delas muda.
É aqui que a distinção entre aspiração soberana e autossuficiência merece cuidado. A Europa participa nas cadeias de abastecimento globais. Nenhuma organização séria pode fabricar todos os semicondutores, cabos, servidores, componentes de firmware, sistemas operativos e ferramentas dentro de um único limite de aquisição. Nem isso seria um limiar sensato para todas as cargas de trabalho. A soberania prática é a capacidade de reconhecer a dependência, definir condições em torno dela, manter alternativas onde forem necessárias e evitar fingir que um componente externo indispensável não é indispensável.
As dependências de hardware podem afetar o controlo da cloud através da atribuição de capacidade, acesso de manutenção, atualizações de software, vias de substituição e componentes de confiança. Podem também afetar a viabilidade de uma migração. Uma carga de trabalho construída em torno de uma funcionalidade gerida específica, de um ambiente de acelerador concreto ou de uma integração não documentada pode ser tecnicamente portável apenas da mesma forma que um piano é portável quando alguém se oferece para o carregar por seis lanços de escadas. O substantivo está correto. O plano está incompleto.
A avaliação de risco da cloud da ENISA é agora uma publicação mais antiga, mas a sua advertência sobre dependência, risco jurídico e perda de controlo não se tornou antiquada. O vocabulário técnico mudou várias vezes desde que foi publicada. A questão subjacente não mudou: o que perde o cliente se o serviço mudar, a relação terminar ou uma dependência não se comportar como esperado? Uma avaliação de risco não exige que o comprador rejeite todos os serviços geridos. Pede ao comprador que associe consequências às dependências antes de a dependência se tornar uma emergência.
Um ficheiro cloud consciente do hardware pode manter-se proporcionado. Registe a arquitetura ao nível que interessa à carga de trabalho. Identifique dependências exclusivas e pontos únicos de conhecimento operacional. Enuncie os termos contratuais que afetam a continuidade e a migração. Pergunte qual é a via de suporte necessária para atualizações de segurança ou recuperação. Verifique se um ambiente de substituição precisa dos mesmos componentes proprietários. O objetivo não é um catálogo de museu. É uma imagem sóbria das coisas que têm de permanecer disponíveis para a organização continuar a fazer o seu trabalho.
Sair é uma capacidade, não um botão de descarregamento
A pergunta mais reveladora sobre a cloud é muitas vezes o que acontece quando o cliente quer sair. Sair pode significar mudar para outro fornecedor, trazer uma função de volta para um ambiente on-premises, alterar a arquitetura, reduzir o serviço ou descontinuá-lo. Um cliente pode por vezes exportar uma base de dados e ainda assim não conseguir retomar o serviço. A função pode também depender de configuração, identidades, chaves, registos, permissões, automatização, modelos, material de avaliação, linhagem de dados, regras de integração e do conhecimento operacional que faz as peças funcionarem em conjunto.
O Regulamento Dados é invulgarmente concreto neste ponto. As suas disposições sobre mudança de fornecedor exigem que os contratos definam direitos e obrigações em torno da mudança e da portabilidade dos dados exportáveis e dos ativos digitais. Estabelece um período máximo normal de transição de 30 dias de calendário após o período de pré-aviso relevante, permitindo ao mesmo tempo um período alternativo em casos definidos de inviabilidade técnica, sujeito a condições. Aborda também interfaces abertas e interoperabilidade. O Regulamento dá aos compradores algo valioso: uma razão legal para pedir a via antes de precisarem dela.
Os limites são igualmente importantes. O Regulamento dos Dados não torna transferível qualquer ativo digital, não obriga um fornecedor a divulgar propriedade intelectual protegida ou segredos comerciais e não garante equivalência funcional no destino. Um fornecedor pode cumprir as obrigações legais enquanto uma migração continua difícil. Um comprador pode ter direito de exportação sem dispor das pessoas, do orçamento ou do destino necessários para o exercer. É por isso que a saída deve ser tratada como uma capacidade partilhada entre contrato, arquitetura e organização, e não como uma promessa feita numa linha de um formulário de encomenda.
Um registo de saída credível documenta o tipo de serviço de destino, os dados e ativos exportáveis, os respetivos formatos, o procedimento para os obter, as condições de continuidade esperadas, o período de recuperação, os pressupostos sobre o destino e as partes da função que não podem simplesmente ser movidas. Identifica quem validará se o material exportado é utilizável. Regista que registos e provas devem sobreviver. Nomeia a autoridade que pode aceitar a transição ou decidir que ainda não é seguro concluí-la. Isto é menos entusiasmante do que um anúncio de migração. É muito mais provável que torne o anúncio verdadeiro.
Os testes são importantes. Um exercício pequeno e delimitado pode revelar se um formato está meramente disponível ou é efetivamente utilizável, se uma identidade pode ser recriada sem alterar permissões, se uma chave pode ser transferida sob a autoridade certa, se os registos mantêm o seu significado e se um serviço reduzido pode continuar enquanto o serviço completo é movido. Não se trata de afirmar que todas as organizações devem ensaiar uma saída completa da nuvem todos os meses. O âmbito deve refletir a consequência de uma interrupção. Trata-se de afirmar que uma saída não testada é uma intenção, ainda não uma opção.
O que uma avaliação europeia da nuvem deve conter
Uma avaliação útil começa por nomear a função, não o fornecedor. Que trabalho se espera que o serviço suporte? Que dados, registos, direitos, necessidades de continuidade e consequências públicas estão envolvidos? Uma ferramenta de colaboração de baixa consequência e um sistema que detém registos operacionais sensíveis não precisam de controlos idênticos. Começar pela carga de trabalho impede uma organização de aplicar um grande rótulo de soberania a uma decisão pequena e específica, ou de tratar um serviço crítico como se fosse mais uma subscrição de escritório.
Em seguida, faça uma declaração de localização com um limite. Indique onde se espera que o plano de trabalho relevante opere, que categorias de dados abrange, que cópias e diagnósticos estão incluídos, que transferências são permitidas, como a posição é comprovada e como as alterações são notificadas. Se o fornecedor só puder fazer uma declaração regional ampla, registe essa limitação. Um comprador tem o direito de distinguir entre um compromisso preciso e uma descrição comercial geral. A distinção não é hostil. É para isso que servem os contratos.
De seguida, elabore um mapa de entidades e autoridade. Registe a entidade contratante, as entidades do grupo com um papel material, os processadores ou subprocessadores nomeados quando relevantes, os papéis que podem administrar o serviço, o percurso de escalada, os acordos de identidade e chaves e a autoridade do cliente que permanece após a externalização. Inclua as provas legais e técnicas que sustentam cada entrada. Não escreva fornecedor ou cliente quando uma entidade, papel ou mecanismo específico é conhecido. Os substantivos gerais são muito bons a ocultar ausências específicas.
Adicione um mapa de dependências. Este deve incluir software, hardware, rede, suporte e dependências de integração relevantes, o caminho de alteração para cada um e as consequências da perda ou alteração. Não é necessário prever o futuro. É necessário tornar o design atual questionável. Se uma dependência for aceitável, registe o motivo. Se não for aceitável, indique a condição de recusa. Se for desconhecida, não resolva o desconforto classificando-a como de baixo risco. Desconhecido é um estado real e, muitas vezes, merece a próxima tarefa.
Por fim, anexe o registo de saída e revisão. Registe as disposições contratuais aplicáveis, os procedimentos de exportação, os testes realizados, as lacunas encontradas, as ações corretivas, a data de revisão e os eventos que desencadeiam a reavaliação. O objetivo não é produzir um dossiê perfeito. É estabelecer um registo vivo de controlo que sobreviva a uma mudança de pessoal, a uma atualização de serviço, a uma renovação de contrato e ao dia em que alguém tenha de tomar uma decisão desconfortável rapidamente. Um relatório que não pode ser atualizado torna-se história com uma fatura anexada.
O que a contratação pública pode exigir sem fingir resolver tudo
Os compradores públicos têm uma razão particular para insistir nestas provas, porque muitas vezes detêm responsabilidades que não terminam quando um contrato é assinado. Podem ser responsáveis perante os cidadãos, estar sujeitos a regras de registo público, ser responsáveis por funções essenciais ou ser obrigados a explicar por que razão uma decisão foi razoável. Isso não significa que a contratação pública possa eliminar todas as dependências externas, nem que uma preferência nacional substitua uma avaliação técnica. Significa que o concurso pode fazer perguntas que tornem o acordo visível antes de este se enraizar.
Um concurso proporcional pode pedir as entidades que fornecerão partes relevantes do serviço, os limites geográficos e legais reivindicados, o modelo de função e autoridade, o processo de alteração de subcontratados, o percurso de suporte e incidentes, as provas retidas para o cliente, o procedimento de exportação e mudança, e as condições sob as quais um cliente pode suspender, limitar ou terminar a utilização. Pode avaliar a qualidade das respostas em vez de recompensar um adjetivo. Um fornecedor que conhece o seu próprio modelo operacional deve ser capaz de o explicar sem uma máquina de fumo.
Existem compromissos. Mais provas podem prolongar uma contratação. Alguns requisitos podem reduzir o número de propostas. Um pequeno fornecedor pode ter menos capacidade para produzir documentação elaborada, mesmo quando o seu modelo de controlo é forte. Um fornecedor estabelecido pode ter um excelente serviço técnico, mas um caminho de saída que necessita de negociação. Estes não são argumentos para saltar as perguntas. São os factos de que um comprador precisa para decidir qual o custo aceitável: o custo das provas e das alternativas agora, ou o custo da dependência mais tarde.
O trabalho da Comissão Europeia sobre soberania na nuvem tornou esta direção visível em termos de contratação, mas os compradores não precisam de esperar por um selo universal. Podem definir o seu próprio limite de risco e exigir provas que lhe correspondam. Uma biblioteca pública, uma agência de investigação, um departamento municipal e um operador de infraestruturas críticas não utilizarão o mesmo limiar. Não devem. O teste é se os requisitos seguem a função, são publicados de forma justa, podem ser avaliados de forma consistente e preservam a capacidade do cliente de explicar o que escolheu.
Essa é a promessa mais discreta da política europeia para a nuvem. Pode afastar a conversa do teatro da nacionalidade e orientá-la para a governação das relações. A resposta europeia não precisa de ser uma ilha tecnológica selada. Pode ser um mercado mais maduro em que as afirmações sobre localização, controlo, lei e saída são afirmações separadas, apoiadas por provas separadas. A interdependência não desaparece quando é nomeada. Torna-se possível decidir onde é tolerável.
Os controlos não respondem uns aos outros
Vale a pena resistir a um último atalho. A encriptação forte não responde a uma questão de propriedade. As chaves detidas pelo cliente podem reduzir riscos específicos de acesso e podem ser um controlo importante, mas não estabelecem por si só quem opera o serviço, quem controla a plataforma, que informação permanece visível nos metadados, ou se o cliente pode mover a função. Uma boa cláusula de saída não responde a uma questão de jurisdição. Uma empresa-mãe europeia não responde a uma questão de suporte de hardware. Cada controlo tem uma função. Cada um deve ser avaliado pela função que efetivamente desempenha.
É também por isto que uma decisão sobre cloud deve poder dizer «não chega» sem se tornar teatral. Um comprador pode achar que o compromisso de localização é adequado, mas que o aviso de alteração é demasiado vago. Pode aceitar um subprocessador, mas exigir um percurso de autoridade mais claro. Pode aceitar uma dependência de hardware estrangeiro, insistindo ao mesmo tempo num plano de substituição documentado. Pode decidir que um determinado serviço não é adequado para uma determinada categoria de dados, mas continua a ser adequado para outra. A nuance não é uma falha em decidir. É a condição para decidir com base em provas e não no reconhecimento da marca.
O trabalho torna-se mais fácil quando as provas são mantidas perto da decisão. Não coloque a declaração de localização de dados num sistema, o contrato noutro, a revisão de acessos numa caixa de entrada e o plano de saída na memória de alguém. Ligue-os ao registo do serviço e atribua um responsável a esse registo. Quando um requisito muda, a organização deve conseguir encontrar as provas, identificar o limite afetado e decidir se o serviço pode continuar. É esta a governação no seu aspeto menos glamoroso e mais útil.
Uma breve nota nossa
O nosso relatório The Sovereignty Illusion utiliza cinco lentes práticas para uma questão semelhante: propriedade, tecnologia, capital, infraestrutura e exposição legal. Esse é o nosso quadro de investigação, não uma classificação jurídica e não uma prova de que um determinado serviço satisfaz as necessidades de um cliente. A sua contribuição útil é um hábito de atenção. Quando uma afirmação sobre cloud parece completa, pergunte quais dessas lentes foram efetivamente cobertas e quais permanecem fora do enquadramento.
Esse hábito também molda a forma como descrevemos o nosso próprio trabalho. Uma afirmação de soberania deve ser limitada pela implementação, pelo contrato e pela responsabilidade operacional, não inflacionada numa promessa que uma página de produto não pode cumprir. O cliente, a carga de trabalho e o modelo de controlo acordado continuam a decidir o que pode ser dito com honestidade. Num campo cheio de substantivos grandiosos, a contenção não é um inconveniente de marketing. Faz parte das provas.
A questão depois do nome da cidade
A localização europeia continua a merecer ser questionada. Pode ser um requisito legal, um requisito operacional, uma escolha de resiliência, uma escolha de segurança física ou uma expressão de responsabilidade pública. Um comprador não deve ter vergonha de perguntar onde um sistema é executado. Deve simplesmente fazer a pergunta em boa companhia. Quem é o proprietário da entidade que importa? Quem tem autoridade operacional? Que ordens jurídicas podem alcançar o acordo? Que subcontratados e componentes são materiais? O que pode o cliente inspecionar, parar, mover e preservar?
Estas perguntas não tornam a computação em cloud menos útil. Tornam a utilização da computação em cloud mais deliberada. Substituem uma atmosfera de tranquilidade por um processo que pode ser revisto. Dão aos fornecedores uma oportunidade justa de mostrar os controlos que construíram, e aos compradores uma forma justa de distinguir um limite útil de uma afirmação vazia. Mais importante ainda, preservam a possibilidade de mudar de rumo antes que uma dependência se transforme numa acusação.
A questão do cloud europeu não é, portanto, onde está o servidor. É onde está o controlo quando o sistema tem de mudar. Um centro de dados pode fazer parte da resposta. Um contrato europeu pode fazer parte da resposta. Um fornecedor europeu pode fazer parte da resposta. A resposta só se torna credível quando a organização consegue percorrer o caminho do local à propriedade, da propriedade ao alcance legal, do alcance legal à autoridade operacional, e da autoridade a uma via de saída testada. Esse caminho é menos memorável do que uma bandeira ao lado de um edifício. É também onde o trabalho começa.
Fontes
- Cloud Computing, European Data Protection Supervisor. Utilizado para a posição de orientação da EDPS sobre cloud, segundo a qual as instituições da UE continuam responsáveis pelas suas obrigações de proteção de dados e devem garantir uma proteção equivalente.
- EDPB publishes three guidelines following public consultation, European Data Protection Board, 24 de fevereiro de 2023. Utilizado para o âmbito e o objetivo das orientações finais sobre o artigo 3.º do RGPD e as transferências internacionais do capítulo V.
- Regulation (EU) 2023/2854 (Data Act), EUR-Lex. Utilizado para as disposições sobre mudança de fornecedor, exportação, continuidade, interoperabilidade e acesso governamental internacional para serviços de processamento de dados.
- Cloud Computing Risk Assessment, European Union Agency for Cybersecurity. Utilizado para o enquadramento da avaliação de riscos relativo à dependência de fornecedor, ao risco legal e à perda de controlo.
- The Sovereignty Illusion, Dweve. Utilizado apenas para o enquadramento de investigação Dweve de cinco lentes, divulgado.