A residência de dados diz onde os seus dados ficam. A soberania de dados diz
quem pode ser obrigado a entregá-los. O debate sobre soberania digital
costuma parar na localização do data center, e muitos questionários de
fornecedores verificam o primeiro ponto e presumem o segundo. É nessa
lacuna que uma implantação aparentemente em conformidade falha sem que
ninguém perceba.
A implantação, que parecia estar em conformidade, falha discretamente.
O mecanismo em questão é a CLOUD Act norte-americana. Um fornecedor sujeito à jurisdição dos Estados Unidos pode ser obrigado a entregar os dados que estejam em sua posse, guarda ou controle diante de um pedido legal norte-americano, mesmo que esses dados estejam armazenados fora do país. A obrigação recai sobre o fornecedor, não depende de onde está o servidor. Já apresentamos em outro artigo o argumento completo de soberania para o setor público, e ele vale igualmente para um banco, uma seguradora, um hospital ou um escritório de advocacia.
O mais fácil é perceber a distinção. Determinar se um fornecedor específico da sua lista de fornecedores pré-selecionados realmente passa no teste é mais difícil, porque o fornecedor, sua controladora, seu provedor de nuvem, seu parceiro de hospedagem e seu prestador de suporte podem estar sujeitos, cada um, a uma jurisdição diferente. As cinco perguntas a seguir permitem verificar isso. Coloque-as por escrito no edital ou RFP e trate uma resposta vaga ou parcial como uma constatação, não como mera formalidade.
As cinco perguntas
1. Quais entidades jurídicas estão de fato na cadeia?
A localização da sede não é uma resposta sobre jurisdição. Peça a identificação da entidade contratante, de sua controladora final e de qualquer empresa do grupo que armazene, processe ou possa acessar dados do cliente, junto com o país de constituição de cada uma. Um fornecedor com sede fora dos Estados Unidos ainda pode estar sujeito a uma ordem de entrega de dados se uma controladora ou empresa do grupo nos Estados Unidos tiver posse ou controle dos dados. Peça a cada fornecedor da lista de fornecedores pré-selecionados que declare sua posição jurisdicional no nível da entidade, não apenas no nível da marca. A entidade da Inuvika que assina o contrato está estabelecida no Canadá ou no Reino Unido, e não está sujeita à jurisdição norte-americana. Esse é o nível de clareza, entidade por entidade, que a resposta deve oferecer.
Como é uma resposta ruim: um endereço de marketing, o nome de um país sem uma entidade por trás, ou silêncio sobre a controladora.
2 Quem mais na cadeia pode ser obrigado a entregar os dados?
Esta é a pergunta que identifica um risco que a primeira deixa passar. O fornecedor de software é apenas um elo. O provedor de nuvem, o parceiro de hospedagem, o provedor de serviços gerenciados e qualquer subcontratado de suporte são regidos cada um por sua própria jurisdição, e cada um pode ter posse, guarda ou controle de dados que possam ter de ser entregues. Uma implantação em um hyperscaler norte-americano, ou um suporte prestado por meio de um provedor norte-americano, pode reintroduzir a exposição que a posição jurisdicional do fornecedor parecia ter afastado. Se essa parte tem posse, guarda ou controle de dados relevantes, há risco. Um fornecedor pode estar inteiramente fora da jurisdição norte-americana e ainda assim prestar o serviço por meio de partes que continuam sujeitas a ela.
Mapeie cada parte da cadeia e a jurisdição que rege cada uma. Como o Inuvika OVD Enterprise é agnóstico em relação a hipervisor e nuvem, você pode manter essa cadeia na infraestrutura e com os parceiros que escolher, em vez de herdar a pegada jurídica de uma única nuvem global.
Como é uma resposta ruim: uma resposta que cobre apenas a entidade do próprio fornecedor, ou uma região de nuvem apresentada como se a região fosse a jurisdição.
3. A que cada parte tem acesso, e quem guarda as chaves?
“Dados do cliente” não são apenas documentos. Para cada parte da cadeia, pergunte a quais conteúdos, logs, backups, dados de telemetria e arquivos de suporte ela pode ter acesso, e pergunte quem guarda as chaves de criptografia. A guarda das chaves é uma questão de jurisdição, não apenas de segurança. Isso porque uma parte que detém as chaves pode conseguir entregar dados legíveis. Em implantações on- premises, o OVD Enterprise não coleta dados do cliente (além da data de expiração da assinatura e dos dados agregados de uso, informados voluntariamente), o que reduz significativamente aquilo que poderíamos algum dia ser obrigados a entregar. O OVD Enterprise também pode ser usado em um ambiente totalmente isolado (air-gapped). Quando o cliente opta por um serviço gerenciado, nós o prestamos por meio de parceiros de hospedagem locais e independentes, no seu país, e não de um único operador global.
Como é uma resposta ruim: “os dados são criptografados”, dito sem informar quem guarda as chaves, ou um escopo limitado a documentos, sem menção a logs, backups ou telemetria.
4. Quais dados o suporte remoto envia para fora do ambiente?
Nem mesmo uma instalação on-premises fica automaticamente isolada. Pergunte quais dados saem do ambiente para atualizações, diagnósticos e suporte, e se as sessões de suporte remoto criam acesso temporário a informações do cliente. Esses são os canais que podem reintroduzir uma exposição que uma revisão de residência tenha considerado encerrada. Confirme o que é transmitido, inclusive se são metadados operacionais ou conteúdo do cliente, quem recebe e qual jurisdição rege o destinatário.
Como é uma resposta ruim: “nada sai do ambiente”, afirmado sem uma lista do que os canais de licenciamento, atualização e diagnóstico realmente transmitem.
5. Como o fornecedor lida com um pedido governamental?
A jurisdição, em última análise, diz respeito ao que acontece quando uma solicitação realmente chega. Peça a cada fornecedor que apresente seu processo documentado. Ele contesta ou restringe solicitações excessivamente amplas? Ele notifica o cliente quando isso for legalmente permitido? Ele informa o volume de solicitações que recebe? Um fornecedor sem um processo documentado corre o risco de ter que improvisar com seus dados caso receba uma solicitação. Aqui está um exemplo de uma consulta no Google.
Como é uma resposta ruim: a garantia de que nunca se recebeu um pedido, oferecida no lugar de um processo para qualquer pedido futuro.
É nas perguntas dois a cinco que muitas alegações de soberania desmoronam, e são justamente elas que um fornecedor não consegue satisfazer com uma única linha sobre a sua sede.
Onde isso entra na sua matriz de avaliação
Para organizações cujas obrigações de soberania proíbem a sujeição a ordens de entrega de dados emitidas por autoridades estrangeiras, a jurisdição é um critério eliminatório: uma solução que não atende a esse critério deve ser descartada antes mesmo da comparação de funcionalidades e preço. Para todas as demais organizações sujeitas a regulação, ela entra na matriz como um fator relevante de risco jurídico, ponderado diante da sensibilidade dos seus dados, do que o seu regulador exige, de como você implanta e do que os seus contratos já cobrem, em vez de ficar no rodapé. De um jeito ou de outro, é um critério que deve ser avaliado explicitamente, com perguntas que você escreveu de antemão.
Construímos o OVD Enterprise para compradores que fazem essas perguntas. Veja como o OVD Enterprise foi construído para implantações soberanas e seguras, ou comece um teste gratuito.
Perguntas frequentes
Um parceiro de hospedagem local pode reintroduzir a exposição estrangeira?
Sim, e é uma das formas mais comuns de uma revisão de soberania dar errado. Se o parceiro de hospedagem,
sua controladora ou o provedor de nuvem subjacente estiverem sujeitos a uma jurisdição estrangeira e
tiverem posse, guarda ou controle de dados relevantes, a exposição pode voltar, independentemente de onde
o fornecedor esteja constituído e de onde os dados fiquem fisicamente. O teste de jurisdição precisa valer para
todas as partes da cadeia, não apenas para o nome que está no contrato.
O que o processo de um fornecedor diante de um pedido governamental deve conter de fato?
No mínimo: um processo documentado para analisar a validade legal do pedido, o compromisso de contestar
ou restringir pedidos excessivamente amplos, a notificação ao cliente sempre que a lei permitir, e alguma
forma de relatório de transparência sobre o número de pedidos recebidos. Peça isso por escrito. Um fornecedor
que ainda não tem esse processo dificilmente conseguirá montar algo crível sob a pressão de uma
contratação.
Uma implantação on-premises encerra a questão por si só?
Não automaticamente. A implantação on-premises elimina uma categoria importante de exposição, mas por si
só não cobre as verificações de licença, os canais de atualização e diagnóstico nem as sessões de suporte
remoto, cada um dos quais pode levar informação para fora do ambiente. Peça a qualquer fornecedor que
documente exatamente o que esses canais transmitem, para quem, e qual jurisdição rege o destinatário.
Esses canais continuam existindo mesmo em uma implantação on-premises, e é exatamente por isso que
precisam ser avaliados separadamente.