Resumo
- PREMI3NS não é mais um simples serviço futuro anunciado. A S3NS o tornou disponível em 16 de outubro de 2025, e a ANSSI qualificou o serviço IaaS, PaaS e CaaS de acordo com a norma SecNumCloud 3.2 em 17 de dezembro de 2025, sendo a decisão válida até 17 de dezembro de 2028.
- Sua geografia física é concentrada, mas deliberadamente particionada: a região autônoma
u-france-east1possui três zonas, cada uma associada a um dos três centros de dados independentes na França. A documentação pública do produto indica que funcionalidades que requerem múltiplas regiões estão indisponíveis. - A Thales Cloud Sécurisé é o fornecedor qualificado e a S3NS é a identidade comercial. A empresa é regida pelo direito francês e controlada pela Thales; suas contas de 2024 mostram uma participação de 95% para a Thales e 5% para o Google, enquanto seus estatutos atuais atribuem cinco assentos com direito a voto no conselho aos representantes da Thales e um cargo de observador sem direito a voto ao outro acionista.
- Os documentos públicos confirmam claramente o controle francês, um serviço operacional, um catálogo substancial de serviços gerenciados e um design por zonas. Eles não divulgam os três operadores dos locais, as localizações exatas, as fontes de energia, os contratos de trânsito, a topologia do backbone, os estoques de peças de reposição ou os compromissos de suporte ao cliente.
- O nível de evidência resultante é Médio. A S3NS possui evidências regulatórias e operacionais excepcionalmente fortes para uma nuvem jovem, mas um comprador não pode deduzir recuperação de desastre de toda a região, capacidade de failover utilizável ou reparo físico rápido apenas a partir da qualificação SecNumCloud ou de um mapa de três zonas.
Uma promessa de nuvem tornada serviço operacional
A S3NS agora deve ser avaliada como um provedor de infraestrutura operacional, e não como a proposta que a França debateu pela primeira vez em 2022. A cronologia é importante. A empresa abriu um programa de acesso antecipado em janeiro de 2025, afirmou que mais de 50 clientes e parceiros participaram até seu encerramento, tornou o PREMI3NS emdisponibilidade geral em 16 de outubro de 2025e recebeu umvisto de segurança SecNumCloud 3.2dois meses depois. Em abril de 2026, umanúncio da S3NS, SAP e Thalesindicava que a empresa atendia mais de 60 clientes e oferecia 30 serviços gerenciados, com mais 30 planejados para o ano seguinte.
Esses marcos resolvem uma questão que antes exigia cautela: PREMI3NS não é apenas uma capacidade de design ou um alvo de certificação futuro. Existe um serviço de produção, um escopo qualificado e uma base de organizações usando as ofertas da S3NS. A distinção entre as ofertas continua importante. CRYPT3NS, o produto anterior de controles locais construído em torno do Google Cloud padrão, foi explicitamente apresentado sem objetivo de qualificação SecNumCloud. PREMI3NS é o ambiente dedicado e distinto que a ANSSI qualificou.
Um cliente não pode transpor as garantias de um nome de produto para outro simplesmente porque ambos são vendidos pela S3NS.
Adecisão de qualificação da ANSSIé mais precisa do que um comunicado de imprensa. Ela designa o fornecedor como THALES CLOUD SÉCURISÉ e o serviço como CLOUD DE CONFIANCE S3NS. Seu escopo cobre serviços de infraestrutura, plataforma e contêineres, não software como serviço. Ocatálogo atual da agênciaindica as datas de qualificação de 17 de dezembro de 2025 a 17 de dezembro de 2028. Isso cria um limite de garantia claro: use o serviço qualificado, em seus termos qualificados, e verifique se cada produto dependente realmente está dentro desse escopo.
O catálogo de serviços é amplo o suficiente para criar uma dependência significativa. Apágina do produto PREMI3NSlista máquinas virtuais, Kubernetes, armazenamento de objetos e blocos, bancos de dados relacionais gerenciados, BigQuery, VPN, interconexão, DNS e serviços de segurança. Essas não são ferramentas periféricas. Elas podem hospedar funções de identidade, transação, análise, aplicação e backup que se tornam difíceis de desembaraçar depois que uma organização padroniza seu modelo operacional em torno delas.
É por isso que a camada física é importante agora. Um roteiro pode ser julgado por sua plausibilidade. Uma nuvem de produção deve ser julgada pelo que permanece utilizável quando um rack perde energia, uma zona é isolada, uma operadora cai, uma atualização é bloqueada, uma fila de suporte enche ou um cliente precisa sair.
O fornecedor é Thales Cloud Sécurisé, não uma aliança abstrata
O nome S3NS descreve uma parceria e uma marca, mas o fornecedor legal é concreto. O registro comercial francês identifica THALES CLOUD SECURISE, SIREN 908 211 980, como uma sociedade por ações simplificada francesa criada em 2021. Sua sede atual fica na 26 rue de Montholon em Paris. Osestatutos atualizados da empresaindicam um capital de 3,3 milhões de euros em abril de 2026.
O controle é mais informativo do que a descrição vaga "Thales e Google cloud". Asdemonstrações financeiras de 2024da empresa indicam que a Thales detinha 95% das ações e o Google 5% no final do exercício. Os estatutos de 2026 preveem cinco administradores com direito a voto propostos pela Thales e um observador sem direito a voto nomeado pelo outro acionista. Eles também excluem esse observador do acesso a dados de clientes e informações sensíveis de segurança física e lógica. Em uma audiência perante uma comissão parlamentar de inquérito francesa em 2026, o diretor de assuntos públicos do Google descreveu o Google como tendo um assento de observador sem voto ou veto no conselho. Os estatutos são a prova mais útil porque detalham a estrutura em vez de resumi-la em um slogan.
Isso não significa que o Google não é importante. As contas de 2024 indicam que a S3NS e o Google assinaram o acordo que rege as relações técnicas e comerciais para a nuvem de confiança em dezembro de 2024. O Google fornece a tecnologia de nuvem subjacente e sua evolução. A proposta de valor da S3NS é que a Thales Cloud Sécurisé controla o ambiente dedicado, a equipe, as chaves, as operações e a implantação de atualizações, enquanto se beneficia da engenharia de software do Google.
Essa fronteira passou por uma qualificação francesa exigente. Continua sendo uma fronteira de fornecedor. Se as atualizações de software pararem, se os termos de licença mudarem, se o acesso à documentação for reduzido ou se uma geração de hardware se tornar indisponível, o controle legal do ambiente de execução não fabrica uma pilha de tecnologia substituta. Inversamente, a dependência tecnológica não implica que o Google possa ler os dados dos clientes ou administrar o PREMI3NS. A avaliação relevante retém os dois fatos ao mesmo tempo: a S3NS controla o serviço qualificado; o Google continua sendo um fornecedor de tecnologia estratégico.
O dossiê da empresa também fornece evidências de rampa. A S3NS declarou 126 funcionários no final de 2024, tendo adicionado 51 pessoas durante o ano, incluindo 40 nas equipes técnicas. Seu balanço mostrava 14,2 milhões de euros em ativos fixos tangíveis em andamento, contra 3,7 milhões um ano antes. A receita atingiu 4,94 milhões de euros, enquanto a empresa registrou um prejuízo anual de 942.293 euros. Esses números descrevem um operador em fase de investimento antes da disponibilidade geral e qualificação.
Eles não provam capacidade do cliente ou fraqueza financeira por si só, mas mostram que o serviço dependia de construção e contratação substanciais antes do lançamento.
Uma região francesa contém três domínios de falha físicos
PREMI3NS é fisicamente mais estreito do que a palavra nuvem sugere. Avisão geral atual do Cloud de Confianceindica que é um universo de nuvem autônomo com uma única região,u-france-east1. Essa região possui três zonas:u-france-east1-a,u-france-east1-beu-france-east1-c. O material de marketing da S3NS indica que a região incluitrês centros de dados independentes na França. Documentos anteriores da S3NS os localizavam na região de Paris e descreviam salas dedicadas próximas aos três centros de dados do Google na França, com racks, servidores e redes física e logicamente isolados.
Esta é uma evidência física significativa. Indica mais do que três etiquetas colocadas em uma única sala de servidores. O fornecedor afirma que as zonas correspondem a centros de dados independentes, e sua documentação instrui os clientes a considerar cada zona como um domínio de falha distinto. Aplicações distribuídas entre zonas podem, portanto, ser projetadas para sobreviver a certas falhas de hardware, energia, resfriamento ou rede em uma zona.
Mas uma zona não é automaticamente uma duplicata completa de cada serviço. Instâncias de computação e discos zonais permanecem vinculados a uma zona. Alguns serviços regionais se replicam entre zonas, enquanto outros produtos gerenciados têm suas próprias semânticas de durabilidade e disponibilidade. Um cliente que inicia uma máquina virtual e anexa um disco zonal não obteve continuidade em três locais apenas escolhendo uma região de três zonas. Ele colocou dois recursos zonais em um único domínio de falha.
O ônus da arquitetura permanece com o cliente. O cálculo requer pelo menos outra instância em outra zona, verificações de saúde e um mecanismo de failover de tráfego. Sistemas com estado requerem um modelo de replicação cuja consistência e comportamento de recuperação correspondam à aplicação. Identidade, segredos, registro e controles de implantação também devem sobreviver à mesma falha de zona. Backups devem poder ser restaurados quando o serviço principal estiver comprometido, em vez de simplesmente existirem como outro objeto dentro do limite operacional afetado.
A S3NS não publica os endereços ou operadores das três instalações nos documentos aqui referenciados. Essa discrição é compreensível para uma plataforma projetada para cargas de trabalho sensíveis. Também significa que um comprador não pode determinar independentemente se os locais compartilham uma zona de inundação, uma subestação elétrica, um corredor de fibra, um proprietário, um contratante de manutenção ou um provedor de serviços de acesso remoto apenas pelos nomes das zonas. "Centros de dados independentes" é uma afirmação útil; o risco de correlação continua sendo uma questão de due diligence a ser feita sob confidencialidade.
Três zonas não criam uma segunda região
A restrição arquitetural mais importante é explicitamente indicada na documentação da S3NS: o Cloud de Confiance atualmente tem apenas uma região, efuncionalidades que exigem múltiplas regiões estão indisponíveis. Isso torna a diferença entre alta disponibilidade e recuperação de desastres particularmente importante.
Três zonas podem proteger contra um evento no nível do servidor, rack ou local se a aplicação as usar corretamente. Elas não protegem contra todos os eventos que afetam a região como unidade. Falhas regionais de identidade, plano de controle, software, roteamento ou operacionais podem atravessar as fronteiras das zonas. Um evento grave de energia metropolitano ou de fibra também pode criar pressão correlacionada mesmo quando os edifícios estão fisicamente separados. O mesmo se aplica a uma resposta de segurança que desative intencionalmente um serviço compartilhado em todo o ambiente.
O Google Cloud público normalmente permite que um cliente emparelhe regiões. PREMI3NS atualmente não oferece esse modelo em seu universo qualificado. Seus recursos "globais" são globais apenas dentro do ambiente S3NS autônomo e se resolvem para a única região francesa; eles não são réplicas distribuídas pelo Google Cloud mundial. Essa é uma consequência necessária de uma estrita separação jurisdicional e operacional, mas altera o cálculo de recuperação.
Um cliente que precisa sobreviver à perda deu-france-east1precisa de um segundo ambiente fora do PREMI3NS. Isso poderia ser um parque de TI local, outro fornecedor francês ou europeu qualificado, um ambiente de recuperação a frio controlado separadamente, ou um nível de serviço menos sensível com um limite de dados cuidadosamente definido. Cada escolha introduz seus próprios problemas: replicação de dados, custódia de chaves, compatibilidade de software, capacidade de rede, acesso de operadores e status legal da cópia de recuperação.
Isso não é um argumento contra o PREMI3NS. Uma única região pode ser o limite certo para dados sensíveis, especialmente quando a alternativa dá a um fornecedor estrangeiro controle operacional direto. É um argumento contra equiparar três zonas à recuperação geográfica de desastres. A decisão pertence à análise de impacto nos negócios: quais cargas de trabalho podem aceitar uma paralisação regional, quais devem se recuperar em outro lugar e quantos dados ou funcionalidades podem ser perdidos durante essa realocação?
A documentação do fornecedor aponta na direção certa ao instruir os clientes a distribuir aplicações entre zonas. Um contrato maduro deve levar esse pensamento adiante. Deve definir se a S3NS tem um plano de restauração regional, como a configuração e os metadados do cliente são recuperados após uma perda catastrófica e que suporte está disponível para reconstrução fora da plataforma se a região não puder voltar dentro do prazo do cliente.
O isolamento físico altera quem pode tocar nas máquinas
A reivindicação técnica central da S3NS não é apenas que os dados estão armazenados na França. É que o equipamento é isolado e as pessoas que podem operá-lo estão sob controle da S3NS. A empresa descreve racks, servidores e equipamentos de rede dedicados, controles de acesso físico, monitoramento e detecção de intrusão, e identidades, raízes de confiança, criptografia e limites de rede distintos. Oanúncio de qualificaçãoindica que apenas funcionários da S3NS administram o serviço e que a tecnologia e as atualizações do Google entram em uma zona de quarentena para análise e validação antes da implantação em produção.
Esses controles abordam vários riscos reais. Um administrador remoto empregado pelo Google não deve conseguir entrar no ambiente. Uma atualização de software não deve passar diretamente do fornecedor de tecnologia para a produção. O controle criptográfico e a identidade de produção são detidos pelo operador francês. O serviço qualificado também deve atender aos requisitos SecNumCloud para segurança física, administração isolada, tratamento de incidentes, continuidade, subcontratação e proteção contra a lei extraeuropeia.
A separação física, no entanto, cria um parque operacional que a S3NS deve manter por conta própria. Alguém precisa receber servidores, validar firmware, cabear racks, substituir discos defeituosos, rodar módulos de segurança de hardware e coordenar o trabalho dentro da sala de computadores. Um reparo que seria feito pela frota global de um hyperscaler torna-se responsabilidade da S3NS ou uma atividade subcontratada estritamente controlada. O operador precisa de pessoal, direitos de acesso, peças de reposição e contratos com fornecedores suficientes nos três locais.
Os documentos públicos não indicam o número de racks, gerações de servidores, alocação total de energia, margem de resfriamento, estoques de peças de reposição ou cobertura de técnicos locais para cada zona. Eles também não identificam quais trabalhos são feitos por funcionários da S3NS e quais permanecem com os proprietários dos locais ou subcontratados especializados. SecNumCloud estabelece que os controles foram avaliados dentro do escopo qualificado. Isso não fornece aos clientes um cronograma de capacidade ou uma garantia de tempo de reparo para cada componente.
Esse parque operacional oculto é a substância econômica do serviço. Os clientes pagam à S3NS para converter equipamentos, contratos de locação, energia, trânsito, licenças, controles de segurança e mão de obra especializada em serviços de nuvem medidos. A margem entre a infraestrutura instalada e a demanda do cliente determina se um rack com falha produz uma realocação de rotina ou uma escassez de capacidade. O contrato de peças determina se um chassi de rede com falha volta em horas ou espera pela logística internacional. Nenhum desses resultados é visível em um catálogo de produtos.
A soberania do software tem um relógio de manutenção
PREMI3NS é projetado para impedir que o Google administre o ambiente do cliente ou o desligue remotamente. Isso não elimina a dependência da engenharia do Google. Bancos de dados gerenciados, orquestração, armazenamento e serviços de análise continuam sendo sistemas de software complexos que exigem patches de segurança, trabalho de compatibilidade e adaptação de hardware. A questão, portanto, não é apenas se a S3NS pode manter o código de hoje funcionando após uma ruptura com o fornecedor. É por quanto tempo ele pode operar com segurança enquanto vulnerabilidades, certificados, dependências e requisitos do cliente continuam evoluindo.
Osrequisitos SecNumCloud 3.2tratam explicitamente da autonomia operacional quando um fornecedor depende de terceiros. O diretor da ANSSI posteriormente enfatizou publicamente que a qualificação protege contra acesso não europeu direto e uma paralisação específica do cliente, mas não significa que não há dependência tecnológica. Essa é a distinção correta. Soberania sobre a operação não é o mesmo que independência indefinida de cada fornecedor.
O Google afirma que seu design de Cloud Dedicado permite que o parceiro local monitore, bloqueie e cancele atualizações, e que pode continuar operando por até12 meses após a ruptura da conexão com o Google. A mesma publicação do Google identifica o PREMI3NS como a implementação francesa. Esta é uma afirmação de continuidade significativa, mas a formulação pública descreve uma capacidade de design em vez de uma garantia de recuperação específica do cliente. Um comprador deve estabelecer quais serviços do PREMI3NS são cobertos, o que "operar" significa durante o período, quais atualizações de segurança permanecem disponíveis e o que acontece no final dele.
O mecanismo de quarentena traz sua própria compensação. A filtragem de atualizações reduz o risco de uma versão comprometida ou inadequada entrar no ambiente de confiança. Também pode criar um descompasso de funcionalidades e uma fila quando muitas alterações upstream chegam ao mesmo tempo. A S3NS precisa de profundidade de engenharia suficiente para avaliar, testar, aprovar ou rejeitar atualizações sem deixar vulnerabilidades críticas sem solução. Os clientes precisam de aviso prévio das diferenças em relação ao Google Cloud padrão para que scripts de implantação e suposições de serviços gerenciados não derivem silenciosamente.
A documentação da S3NS já alerta que o Cloud de Confiance é um produto distinto com um subconjunto de produtos do Google Cloud e endpoints diferentes, incluindos3nsapis.frem vez degoogleapis.com. Isso é evidência de separação real. Também é evidência de que a migração não é uma simples mudança de região. Os proprietários de aplicações devem testar código, bibliotecas, suposições de identidade, disponibilidade de serviço e procedimentos operacionais em relação ao próprio universo S3NS.
A conectividade começa onde o cliente entra na nuvem
Um servidor soberano que não pode ser alcançado não é um serviço. PREMI3NS suporta acesso público à Internet, VPN Cloud e Cloud Interconnect, e esses caminhos têm diferentes limites de falha e confiança. Adocumentação de conectividade de rededescreve a VPN como tráfego criptografado pela Internet pública e o Interconnect como conectividade dedicada ou de parceiro entre uma rede do cliente e a nuvem.
Para um parque de produção, o design de acesso deve corresponder ao design de zonas. Duas máquinas virtuais em zonas separadas ainda dependem de um único roteador do cliente se ambas forem acessadas por um único túnel. Dois circuitos de interconexão podem ainda compartilhar uma entrada de edifício, uma operadora, um sistema óptico ou um duto metropolitano. Um esquema resiliente requer diversidade em cada ponto de transferência: roteadores do cliente, provedores de trânsito, interconexões, domínios de borda S3NS, sessões BGP e largura de banda de failover suficiente para transportar a carga crítica.
Adocumentação do Partner Interconnectda S3NS ilustra esse ponto. Ela afirma que um design de 99,9% requer duas conexões redundantes em diferentes domínios de disponibilidade de borda, enquanto seu modelo genérico de 99,99% requer quatro conexões distribuídas por duas zonas metropolitanas e duas regiões. Como PREMI3NS atualmente tem apenas uma região, esse modelo de duas regiões não pode ser implementado inteiramente no universo atual da S3NS. Os clientes não devem supor que a compra de quatro circuitos dentro de Paris cria o mesmo isolamento de falha.
A VPN HA tem uma topologia diferente. A S3NS documenta uma configuração de 99,99% quando ambas as interfaces do gateway gerenciado se conectam através de túneis correspondentes ao lado peer. Mas a disponibilidade ponta a ponta da conexão ainda depende dos gateways físicos do cliente, provedores de Internet ou interconexões, política de roteamento e carga de trabalho hospedada. Um número de nível de serviço do lado da nuvem não cobre um único roteador no escritório do cliente.
A taxa de transferência também faz parte da recuperação. Uma interconexão dimensionada para replicação normal de banco de dados pode ser muito pequena para reencher o armazenamento após uma falha. Uma VPN que transporta confortavelmente tráfego de gerenciamento pode colapsar quando se torna o único caminho para transações do cliente. Exercícios de recuperação devem medir as taxas de transferência na topologia degradada, e não usar a velocidade da porta como proxy.
A camada de trânsito e backbone permanece opaca
A documentação do PREMI3NS indica que sua rede premium transporta tráfego na rede Cloud de Confiance e seleciona caminhos BGP para redes de peering ou trânsito. Ela também permite que os clientes tragam intervalos IPv4 e IPv6 elegíveis, sujeitos a validação de propriedade e autorização de origem de rota. Estas são capacidades maduras de rede em nuvem. Elas não revelam os provedores reais ou as rotas físicas por trás da borda S3NS.
Os documentos públicos vinculados a este artigo não nomeiam as operadoras de trânsito, edifícios de interconexão, pontos de troca de Internet, provedores de fibra de backbone ou relações de servidor de rota usados pelo PREMI3NS. Eles não publicam um ASN de plataforma, lista completa de prefixos de provedor ou um mapa que um cliente poderia usar para estabelecer diversidade de caminhos. Os endereços expostos pela carga de trabalho de um cliente também podem depender se o cliente usa espaço atribuído pela S3NS, traz seus próprios endereços, entra através de um parceiro ou mantém o serviço privado.
A opacidade não é evidência de fragilidade. Fornecedores sensíveis frequentemente limitam a divulgação de topologia, e uma rede virtual distribuída não pode ser reduzida a um ícone de roteador. Isso significa que a expressão "caminhos múltiplos" requer evidências sob confidencialidade. Os compradores devem perguntar se as três zonas têm entradas de fibra fisicamente separadas, se os links entre zonas compartilham dutos, onde terminam as interconexões dedicadas e se dois produtos de operadora nomeados eventualmente usam a mesma rede de atacado.
Eles também devem perguntar como a S3NS valida a segurança de roteamento. Prefixos fornecidos pelo cliente requerem autorizações de origem de rota corretas, objetos de roteamento precisos e failover controlado. O espaço do fornecedor requer sua própria segurança de origem e filtragem. Uma política de rota incorreta pode remover um serviço saudável da Internet mesmo que cada rack permaneça energizado.
A fronteira se estende além da S3NS. Uma aplicação pública depende de DNS, emissão de certificados, registro de domínio, distribuição de conteúdo, identidade e redes de usuários upstream. Alguns desses serviços podem estar fora do PREMI3NS ou fora da França. Hospedar a carga de trabalho principal em uma região qualificada não traz automaticamente todo o serviço para a mesma jurisdição ou domínio de falha.
A capacidade instalada não é capacidade de failover
A S3NSanunciou 30 serviços gerenciados em fevereiro de 2026e lista máquinas virtuais GPU H100 entre suas opções de computação. Isso demonstra amplitude, não quantidade. Os documentos públicos não indicam quantos processadores, GPUs, dispositivos de armazenamento ou portas de rede estão instalados em cada zona, quantos estão reservados ou quanta margem resta após a perda de uma zona.
Isso é importante porque a capacidade da nuvem é vendida duas vezes na imaginação do cliente. A primeira venda é elasticidade: os recursos aparecem sob demanda. A segunda é redundância: outra zona parece pronta quando a primeira falha. Ambas as promessas tiram do mesmo inventário físico. Se muitos clientes solicitarem instâncias de substituição durante um evento de zona, a capacidade de reserva pode desaparecer rapidamente. Uma cota que permite um recurso em condições normais não garante que o hardware equivalente estará disponível durante estresse regional.
Equipamentos especializados apertam a restrição. Cargas de trabalho GPU podem depender de um acelerador, driver e família de máquina específicos que não estão uniformemente distribuídos em todas as zonas. Bancos de dados de grande memória e armazenamento de alta taxa de transferência têm limitações de posicionamento semelhantes. Um cliente pode construir um design nominal de múltiplas zonas que não pode realmente reiniciar em outro lugar com a mesma forma.
A medida correta é a capacidade utilizável após a falha escolhida, não a capacidade instalada antes. Para serviços críticos, os clientes precisam de capacidade reservada ou contratualmente prioritária, confirmação de posicionamento e evidências periódicas de que a zona de reserva pode aceitar a carga de trabalho. Eles também precisam de uma estratégia de degradação acordada: instâncias menores, análises reduzidas, trabalhos em lote suspensos ou serviço de transação mínimo quando a capacidade total não pode ser restaurada.
A S3NS tem boas razões para não publicar a contagem de máquinas. Concorrentes e atacantes apreciariam a informação, e os números mudam rapidamente. Uma garantia confidencial ainda pode dar aos compradores o que precisam: classes de capacidade, limites de evacuação testados, prazos de entrega para hardware escasso e regras de prioridade usadas durante contenção. Sem essas evidências, "três zonas" descreve locais, não a quantidade de serviço disponível após a perda de uma delas.
A mão de obra de suporte faz parte da infraestrutura
O programa de acesso antecipado revelou um detalhe útil sobre o modelo operacional da S3NS. A empresa afirmou que engenheiros de confiabilidade de sites, equipes de cibersegurança, pessoal de centro de dados, suporte, gerentes de contas técnicas e engenheiros de cliente participaram. Esta é uma evidência crível de uma organização projetada para operar mais do que um portal de autoatendimento. A visão geral atual da plataforma também indica que a S3NS, e não o Google Cloud, é responsável pelo gerenciamento e suporte da infraestrutura.
Essa responsabilidade local está no centro da reivindicação de soberania. Um incidente do cliente não deve exigir que um administrador do Google entre no ambiente. Isso também concentra a escalada na S3NS. Se um defeito de banco de dados gerenciado requer conhecimento upstream, a S3NS deve reproduzir o problema, controlar as informações que saem do ambiente, coordenar com o Google e retornar uma correção segura. O cliente depende da qualidade dessa camada de tradução.
Os documentos públicos não fornecem uma matriz de suporte completa com definições de gravidade, tempos de resposta iniciais, objetivos de restauração, condições de escalada por telefone e compensação por nível de serviço. O anúncio de disponibilidade geral afirma que acordos de nível de serviço contratuais acompanharam o lançamento, mas não os reproduz. Os compradores precisam, portanto, do contrato, não da linguagem de lançamento.
O relógio de reparo deve ser detalhado. A detecção é o tempo até que a S3NS ou o cliente percebam uma falha. O acionamento é o tempo até que alguém com autoridade a aceite. O diagnóstico identifica se o problema pertence à configuração do cliente, ao serviço gerenciado, à rede da S3NS, a uma instalação ou a uma atualização tecnológica. O acesso é o tempo para um engenheiro entrar no local afetado. O reparo inclui peças, aprovação de mudança e validação. A recuperação não está completa até que a aplicação, os dados e o trabalho em fila estejam novamente utilizáveis.
Um objetivo de restauração misturado esconde essas transições. Também esconde terceiros. Serviços remotos de instalações, técnicos de fibra, fornecedores de hardware e especialistas do Google podem todos estar envolvidos sem operar diretamente o ambiente do cliente. Um cliente deve saber qual parte pode parar o relógio, qual parte fala com ele durante um incidente grave e se o canal de status permanece contactável se a identidade ou console da S3NS estiver comprometido.
Um SLA não constrói uma aplicação resiliente
A S3NS descreveu a disponibilidade geral como trazendo SLAs formais e prontidão para produção. Esta é uma evidência comercial necessária. Um SLA continua sendo uma promessa limitada em torno de uma métrica de serviço definida. Ele não pode tornar uma máquina virtual zonal regional, adicionar uma segunda região PREMI3NS ou reparar uma arquitetura de cliente que faz passar cada rota por um único gateway.
A diferença torna-se nítida durante um incidente composto. Suponha que uma zona perca energia, a aplicação falhe e o banco de dados sobrevivente atinja um limite de conexão imposto pelo cliente. O serviço de infraestrutura pode satisfazer sua medida de disponibilidade enquanto a aplicação está indisponível. Se o cliente não distribuiu identidade, segredos ou monitoramento, o fornecedor pode restaurar a infraestrutura antes que a empresa possa restaurar o serviço.
Os créditos de serviço também são limitados. Eles ajustam uma fatura após uma falha elegível. Eles não reembolsam serviços públicos perdidos, trabalhos médicos atrasados, transações financeiras perdidas ou mão de obra de migração de emergência. Para sistemas sensíveis, a linguagem contratual útil cobre comunicação de incidentes, integridade de dados, assistência, preservação de evidências, prioridades de recuperação e suporte ao encerramento, não apenas uma porcentagem mensal de disponibilidade.
As exclusões de manutenção exigem igual atenção. Um fornecedor operando uma cadeia de suprimentos de software em quarentena precisa aplicar patches e atualizações. Os clientes devem saber qual aviso prévio se aplica, se as zonas são mantidas sequencialmente, o que acontece quando uma mudança de emergência não pode esperar e se um rollback é tecnicamente possível. Eles devem projetar aplicações para tolerar o comportamento de manutenção que o contrato permite.
O canal de status é outra dependência. A documentação da S3NS direciona os clientes a um painel de saúde do serviço Cloud de Confiance, mas um canal de incidente grave útil deve funcionar fora do console e do plano de identidade com falha. Contatos nomeados, caminhos de notificação independentes e uma cadência para atualizações são uma capacidade operacional: eles determinam a rapidez com que os clientes podem escolher entre esperar, failover e invocar um plano de recuperação regional.
SecNumCloud é uma garantia forte, não universal
A qualificação SecNumCloud é a evidência pública mais sólida que apoia o PREMI3NS. O framework da ANSSI cobre muito mais do que a localização dos dados. Seus requisitos incluem segurança física, controle de acesso, administração isolada, registro, gerenciamento de vulnerabilidades, criptografia, continuidade, gerenciamento de fornecedores, reversibilidade e proteção contra a lei extraeuropeia. AFAQ sobre a qualificaçãoda agência explica que os dados dos clientes, diretórios de administração, diretórios de usuários, logs, autoridades raiz e backups devem respeitar controles territoriais, e que a autonomia operacional contínua é avaliada.
A decisão também indica que a S3NS atende à recomendação R9 da doutrina de nuvem do estado francês e oferece proteção contra a lei extraeuropeia. Este é um resultado importante para entidades públicas e organizações regulamentadas. Adoutrina Cloud au Centrena França orienta cargas de trabalho estatais particularmente sensíveis para nuvens comerciais qualificadas protegidas contra acesso não autorizado por autoridades de países terceiros.
A qualificação não significa que cada uso da S3NS é automaticamente conforme ou resiliente. A decisão da ANSSI condiciona o uso às recomendações do framework. Os clientes ainda configuram identidades, redes, armazenamento, criptografia, registro e aplicações. Eles podem criar um banco de dados de zona única, expor um serviço não seguro ou copiar dados para um sistema externo não qualificado.
O visto também não cobre todos os produtos vendidos sob o nome S3NS. Ele cobre o serviço Cloud de Confiance nomeado como IaaS, PaaS e CaaS. CRYPT3NS foi explicitamente comercializado como um trampolim que não visava a qualificação SecNumCloud. Aplicações SaaS de parceiros executadas no PREMI3NS exigem sua própria análise de escopo. Um substrato qualificado não qualifica automaticamente o software e as práticas operacionais acima.
Finalmente, o visto tem datas. É válido por três anos e depende de conformidade contínua. Mudanças legais, organizacionais ou técnicas significativas devem ser gerenciadas dentro das obrigações de qualificação. As compras devem registrar o número da decisão, escopo, expiração e quaisquer condições subsequentes, em vez de usar "SecNumCloud" como um emblema atemporal.
Anúncios de clientes mostram demanda, não recuperação testada
A S3NS nomeou clientes nos setores de seguros, saúde, finanças, indústria e serviços. Seu anúncio de qualificação citava MGEN, Matmut, AGPM, Thales, Birdz, Qonto, BConnect e Club Med. Ocaso MGENé particularmente importante porque a seguradora descreveu uma plataforma destinada a atender até seis milhões de pessoas. Um anúncio de abril de 2026 indicava que o SAP RISE Private Cloud Edition seria implantado no PREMI3NS para a Thales no segundo semestre de 2026, cobrindo áreas de negócio principais, incluindo finanças, cadeia de suprimentos, manufatura e compras.
Esses nomes apoiam a conclusão de que a S3NS atende ou prepara cargas de trabalho reais. Eles também indicam quem arca com as consequências de uma falha: segurados, usuários de serviços de saúde, funcionários, fornecedores, equipes financeiras e operações industriais. Essa consequência aumenta o valor de um forte controle francês ao mesmo tempo que aumenta a necessidade de recuperação prática.
Um anúncio de cliente não é um histórico de incidentes. Ele raramente indica quais cargas de trabalho já estão em produção, quantos dados elas contêm, se cobrem as três zonas, qual tempo de recuperação foi demonstrado ou se uma saída regional foi exercitada. "Escolhido por" pode descrever um contrato, um programa de migração, um teste de adoção inicial ou um parque de produção. Cada um tem um peso probatório diferente.
O uso correto desses anúncios é, portanto, modesto. Eles validam a tração de mercado e mostram que organizações exigentes realizaram suas próprias avaliações. Eles não transferem a garantia não divulgada dessas organizações para outro comprador. Um novo cliente deve testar sua própria aplicação, rede, dados e cadeia de suporte.
A S3NS também é cliente de fornecedores. Proprietários de centros de dados, serviços públicos, operadoras, fabricantes de servidores, distribuidores de componentes e o Google estão por trás do serviço mesmo quando não podem administrá-lo. O modelo de confiança é mais forte quando cada dependência é restrita, substituível e testada. É mais fraco quando o cliente trata o contrato S3NS como o nó final da cadeia.
A localidade dos dados requer um mapa de cada cópia
PREMI3NS oferece uma proposta clara de localização principal: os dados e cargas de trabalho permanecem na França em um ambiente S3NS dedicado. Isso é mais forte do que supor a localização a partir de um endereço de faturamento ou resultado de geolocalização IP. A arquitetura também mantém identidade de produção, controle de chaves, administração e suporte sob a autoridade do operador francês.
Os clientes ainda devem mapear cada categoria de informação. Dados principais, réplicas, backups, snapshots, logs, anexos de suporte, registros de faturamento, telemetria, chaves e metadados de identidade não compartilham necessariamente o mesmo ciclo de vida. SecNumCloud impõe requisitos territoriais dentro do serviço qualificado, mas um cliente pode enviar logs para uma plataforma externa, abrir um caso de suporte contendo dados sensíveis ou replicar um banco de dados em outra jurisdição.
O design de região única torna o posicionamento de backups particularmente importante. Um backup copiado por três zonas pode sobreviver a uma falha de dispositivo ou local, mas permanece dentro deu-france-east1. Uma cópia fora da região melhora a recuperação de desastres, mas pode sair do limite qualificado exato que a organização escolheu. Algumas cargas de trabalho podem justificar armazenamento a frio criptografado em outro fornecedor qualificado; outras podem ser legal ou operacionalmente obrigadas a permanecer no ambiente S3NS. A resposta depende dos dados e do objetivo de recuperação.
O gerenciamento de chaves deve seguir o mesmo mapa. Uma cópia de recuperação é inútil se suas chaves estiverem presas na região com falha. Uma chave copiada em outro lugar pode criar um novo caminho de acesso que compromete o controle original. O design de recuperação requer, portanto, disponibilidade independente para chaves, identidade, configuração e pessoas autorizadas a usá-las, com controles pelo menos tão deliberados quanto os em torno dos dados.
A localidade também altera a latência e a zona de serviço. Os três centros de dados estão na França, com descrições anteriores da S3NS os localizando na região de Paris. Usuários europeus podem se beneficiar de boa latência, mas uma região francesa não está automaticamente próxima de cada filial, fábrica ou território ultramarino. A rede de acesso e o design da aplicação determinam o desempenho percebido. Uma organização multinacional também deve decidir se todos os usuários e dados pertencem à jurisdição francesa ou se o PREMI3NS deve conter apenas o subconjunto sensível.
A migração é o mecanismo definitivo de recuperação
A S3NS promove continuidade com a tecnologia Google Cloud, o que pode reduzir o esforço de migração para clientes que já usam APIs e serviços gerenciados familiares. Isso não torna as plataformas idênticas. O universo dedicado tem endpoints diferentes, um conjunto de serviços mais restrito, uma única região e controles operacionais ditados pela qualificação. Migrar para o PREMI3NS é um programa de engenharia planejado; migrar para fora dele também será.
Um guia de migração da S3NS observa que o tempo de transferência depende do volume de dados e da largura de banda da rede. Essa simples declaração torna-se severa durante uma falha. Mover 500 terabytes em um caminho que fornece 5 gigabits por segundo sustentado leva mais de nove dias antes de custos indiretos de protocolo, novas tentativas, validação e failover de aplicação. Se o serviço de origem estiver degradado, a taxa real pode ser muito menor. Se o destino usar um banco de dados gerenciado diferente, a conversão pode dominar a cópia.
As regras francesas e europeias fortalecem a posição do cliente. O artigo 28 dalei francesa SRENexige que os serviços de nuvem suportem interoperabilidade segura, portabilidade de dados exportáveis e ativos digitais, bem como interfaces e informações necessárias para realizá-la. Arecomendação de 2025 da Arcepfoca na transparência da mudança e em interfaces estáveis. O Regulamento Europeu de Dados impõe obrigações de mudança e elimina gradualmente as taxas de mudança.
Portabilidade legal não garante equivalência operacional. Dados exportáveis podem excluir propriedade intelectual do fornecedor. Uma aplicação Kubernetes pode se mover mais facilmente do que uma carga de trabalho construída em torno de BigQuery, comportamento do Cloud SQL, identidade do fornecedor e monitoramento proprietário. Mesmo quando os registros exportam corretamente, políticas, filas, histórico de eventos, estado criptográfico e painéis operacionais podem não exportar.
Os clientes devem, portanto, manter uma pequena implantação de recuperação completa em outro lugar. Ela deve restaurar dados reais, recriar identidade e rede, e provar que a empresa pode operar em um nível mínimo definido. O exercício deve registrar velocidade de transferência, falhas de conversão, metadados ausentes e pessoas necessárias. Um plano de saída que existe apenas como linguagem contratual não é uma capacidade de reserva.
Os caminhos de falha críveis são comuns
A S3NS atrai atenção devido a questões geopolíticas e legais, mas as falhas mais prováveis são eventos de infraestrutura familiares. Um componente de energia falha. Um dispositivo de armazenamento produz erros. Uma fibra é cortada. Uma rota BGP é retirada. Um certificado expira. Uma atualização de serviço gerenciado altera o comportamento. Um ticket de suporte é mal classificado. O pagamento ou status da conta de um cliente interrompe o acesso. Uma migração dura mais do que sua janela aprovada.
Uma falha de rack ou servidor deve ser contida por redundância local, mas apenas se o serviço e o posicionamento do cliente a suportarem. Uma falha de zona deve ser contida por arquitetura multi-zona e capacidade de sobrevivência adequada. Uma falha regional não tem segunda região PREMI3NS e, portanto, invoca o design de recuperação externa do cliente. Uma falha upstream ou de interconexão invoca caminhos de rede diversificados. Uma interrupção no fornecimento de software invoca a autonomia e estratégia de atualização da S3NS. Uma disputa contratual ou de faturamento invoca continuidade administrativa e direitos de exportação.
Cada caminho afeta uma população diferente. Um serviço de análise isolado pode atrasar relatórios internos. Uma falha de identidade pode impedir que todas as aplicações iniciem, mesmo que a computação permaneça saudável. A perda de uma plataforma de saúde pode afetar a administração de cuidados e o acesso dos pacientes. A perda de um ERP industrial pode parar compras, manufatura e expedição. A dependência deve ser classificada por função de negócio, e não pela importância aparente do nome do recurso de nuvem.
Falhas compostas merecem atenção especial. Uma falha de zona durante a manutenção deixa menos capacidade de reserva. Um incidente cibernético pode desativar a automação enquanto aumenta a demanda por suporte manual. Um problema de rede regional pode desacelerar a transferência de backup mesmo que planejado para recuperação. Uma disputa com fornecedor pode coincidir com uma vulnerabilidade de segurança urgente. Resiliência é a capacidade de operar através dessas combinações, não a presença de três caixas em um diagrama de arquitetura.
A S3NS construiu um controle excepcionalmente forte em torno de uma nuvem francesa baseada em tecnologia não francesa. Essa conquista remove alguns caminhos de falha, especialmente administração estrangeira direta e paralisação remota específica do cliente pelo fornecedor de tecnologia. Ela não remove a física, o envelhecimento do software, o erro humano ou a concentração de clientes.
As evidências que um comprador deve obter antes de comprometer uma carga de trabalho crítica
A primeira evidência deve descrever o posicionamento. A S3NS pode confirmar, sob confidencialidade apropriada, que os serviços selecionados usam os três centros de dados, quais componentes permanecem zonais, quais são regionais e quais dependências do plano de controle atravessam as zonas. O cliente pode então mapear cada componente de computação, armazenamento, identidade, chave, registro e implantação para um domínio de falha.
A segunda evidência deve descrever a capacidade de sobrevivência. Para cada máquina crítica e serviço gerenciado, o cliente deve saber se uma capacidade equivalente está reservada ou é provável que esteja disponível após a perda de uma zona. Processadores especializados, formas de grande memória, desempenho de armazenamento e endereços públicos devem ser incluídos. Um exercício bem-sucedido onde as cargas de trabalho reiniciam em outra zona tem mais valor do que um adjetivo de disponibilidade.
A terceira evidência deve descrever a diversidade física e de rede sem expor detalhes sensíveis publicamente. Risco independente de instalações e serviços públicos, entradas separadas, caminhos entre zonas, propriedade de operadoras, terminação de interconexão e largura de banda de failover podem ser validados em um quadro de garantia controlado. A resposta deve identificar dependências compartilhadas, e não apenas contar contratos.
A quarta evidência deve descrever reparo e escalada. O cliente deve saber quem atende 24 horas, quando o pessoal do local da S3NS é envolvido, quais reparos dependem de fornecedores de instalação ou hardware, quais peças são mantidas localmente e como um problema chega ao Google sem expor dados do cliente. Comunicações de incidente grave devem ter um canal fora da banda.
A quinta evidência deve ser um exercício de recuperação regional. Como existe apenas uma região PREMI3NS, o cliente deve restaurar um serviço representativo fora dela, incluindo dados, chaves, identidade, configuração e entrada de rede. O resultado medido deve ser comparado ao objetivo de recuperação da empresa. Qualquer etapa que assuma que o console de origem permanece disponível deve ser testada novamente sem essa suposição.
Finalmente, o contrato deve estar alinhado com o resultado técnico. O escopo de qualificação, níveis de serviço, manutenção, suporte a incidentes, localização de dados, subcontratados, continuidade de fornecimento de software, portabilidade, exclusão e suporte ao encerramento devem todos descrever o mesmo serviço que foi testado pelos engenheiros. Um contrato não pode criar capacidade, mas pode tornar a responsabilidade e as evidências disponíveis antes de uma falha.
O nível de evidência é Médio
A S3NS cruzou o limiar de projeto plausível para operador atestado. PREMI3NS está geralmente disponível, tem um fornecedor legal nomeado, emprega uma equipe francesa substancial, opera uma região autônoma documentada, expõe um amplo catálogo de serviços gerenciados, tem programas públicos de clientes e possui uma qualificação SecNumCloud 3.2 atual para IaaS, PaaS e CaaS. Estes são sinais mais fortes do que um mapa de marketing, um dossiê corporativo adormecido ou um selo de nuvem não verificado.
O rebaixamento de Forte reflete o que permanece indisponível publicamente. Os três operadores de centros de dados e locais exatos não são nomeados. A diversidade de serviços públicos, operadoras, backbone e interconexões não é descrita. Não há contagem pública da frota, limites de evacuação de zona, cronogramas de peças de reposição ou termos completos de resposta ao suporte ao cliente. Mais importante, PREMI3NS tem uma única região. Suas três zonas melhoram a disponibilidade, mas não fornecem recuperação interna em caso de perda da região.
A conclusão justa, portanto, não é nem "o controle francês resolve tudo" nem "a tecnologia Google torna a soberania sem sentido". A ANSSI estabeleceu que a Thales Cloud Sécurisé controla o ambiente qualificado e o protege contra acesso legal não europeu nos termos estabelecidos. A plataforma ainda depende da tecnologia Google, infraestrutura de centros de dados franceses, eletricidade, fibra, fornecimento de hardware e pessoal da S3NS. Essas dependências podem ser gerenciadas porque são identificáveis; elas não podem ser gerenciadas fingindo que desapareceram.
Para um comprador, a característica mais valiosa da S3NS pode ser a clareza de seu limite. O serviço é uma região de nuvem autônoma francesa com três zonas físicas, operada por uma empresa francesa controlada pela Thales usando tecnologia Google Cloud em um modelo de controle qualificado. Construa através das zonas. Prove capacidade nos locais sobreviventes. Obtenha evidências confidenciais de diversidade física e de roteamento. Mantenha um ambiente de recuperação testado além da região. Assim, a promessa de soberania se torna uma capacidade operacional em vez de um selo afixado nos racks de outra pessoa.