Cyberspace Administration of China et conformité cybersécurité
- Accueil
- Organismes
- Cyberspace Administration of China et conformité cybersécurité
Cyberspace Administration of China et conformité cybersécurité
Section intitulée « Cyberspace Administration of China et conformité cybersécurité »La Cyberspace Administration of China (CAC) n’est pas un équivalent chinois de la Commission nationale de l’informatique et des libertés (CNIL), ni une agence technique isolée. Elle combine supervision du cyberespace, gouvernance des données, contrôle des contenus et exigences de sécurité applicables aux opérateurs présents en Chine.
La CAC ressemble à une autorité qui vérifie à la fois les règles de circulation, ce qui entre et sort d’un bâtiment, et les affiches collées sur ses murs. Son rôle est de décider quelles activités numériques peuvent fonctionner sur le territoire chinois et sous quelles conditions.
→ Lire l’explication complète de la marmotte
Mandat de la CAC : souveraineté numérique avant conformité produit
Section intitulée « Mandat de la CAC : souveraineté numérique avant conformité produit »La CAC applique une logique de souveraineté numérique. Le compromis central est net : accéder au marché chinois permet d’opérer auprès d’utilisateurs locaux, mais impose de placer la maîtrise des données, des flux, des contenus et parfois des fournisseurs sous une autorité réglementaire locale. Ce n’est pas une exigence de protection des données au sens occidental, où la minimisation et les droits individuels structurent l’analyse. C’est une exigence de contrôle de l’espace numérique, dont la protection des données personnelles est une composante.
Trois textes structurent l’architecture :
- la Cybersecurity Law, entrée en vigueur en 2017, impose notamment des obligations de sécurité réseau et de localisation à certains opérateurs ;
- la Data Security Law, entrée en vigueur en 2021, organise la classification et la protection des données selon leur portée pour la sécurité nationale et l’intérêt public ;
- la Personal Information Protection Law, ou PIPL (Personal Information Protection Law), entrée en vigueur en 2021, encadre le traitement des informations personnelles et leurs transferts hors de Chine.
La CAC publie aussi des mesures sectorielles sur les recommandations algorithmiques, les contenus synthétiques, les services d’intelligence artificielle générative et les exportations de données. Une architecture conforme ne peut donc pas traiter la CAC comme un régulateur de confidentialité parmi d’autres. Elle doit la traiter comme une contrainte de conception du produit, du réseau et de l’exploitation.
La recommandation est d’isoler l’environnement chinois comme une zone réglementaire autonome dès que des données de production, des identités locales ou un service accessible localement sont concernés. Un simple drapeau region=cn dans une plateforme mondiale ne constitue pas une séparation. C’est un post-it numérique, et les post-it n’arrêtent ni une réplication asynchrone ni un compte administrateur global.
Les pages consacrées à la gouvernance et aux données fournissent le cadre général. Ici, la différence décisive est l’intensité du contrôle territorial : l’emplacement logique du service ne suffit pas, il faut pouvoir démontrer l’emplacement des données, des journaux, des sauvegardes, des accès d’administration et des flux de support.
Localisation des données et transferts transfrontaliers
Section intitulée « Localisation des données et transferts transfrontaliers »Les opérateurs d’infrastructures d’information critiques, ou CIIO (Critical Information Infrastructure Operator), doivent stocker en Chine les informations personnelles et les données importantes collectées ou produites sur le territoire. Une sortie hors de Chine nécessite alors une évaluation de sécurité. La qualification de CIIO dépend du secteur et de l’impact potentiel, pas d’un seuil universel que l’on pourrait cocher dans un tableur.
Pour les autres responsables de traitement, les mécanismes de sortie incluent l’évaluation de sécurité organisée par la CAC, le contrat type chinois et la certification de protection des informations personnelles. Les mesures de mars 2024 ont introduit des exemptions et révisé certains seuils, notamment pour les transferts nécessaires à l’exécution d’un contrat, à la gestion des ressources humaines ou à une urgence. Ces exemptions ne transforment pas une architecture mondiale en architecture chinoise. Elles réduisent un périmètre de procédure, pas une surface d’attaque.
L’évaluation de sécurité reste notamment requise lorsqu’un CIIO exporte des informations personnelles ou des données importantes, lorsqu’un opérateur exporte des données importantes, ou lorsque certains seuils de volumes d’informations personnelles exportées sont dépassés. Les seuils et exemptions doivent être vérifiés contre le texte en vigueur et la zone concernée, notamment les zones franches. Une règle réglementaire copiée dans un wiki sans propriétaire ni date de revue devient vite une fiction administrative. Le secteur adore appeler cela de la gouvernance.
Le point d’architecture est plus concret : inventorier les jeux de données par origine, finalité, sensibilité, destinataire et trajet réseau. Il faut aussi cartographier les flux cachés :
- réplication entre bases de données ;
- export de journaux vers un service centralisé ;
- télémétrie d’agent, traces applicatives et rapports d’erreur ;
- accès de support distant ;
- sauvegardes, archives et restauration hors région ;
- annuaires d’identité et fournisseurs d’authentification fédérée ;
- outils de détection de fraude ou de sécurité hébergés hors de Chine.
Une politique de résidence des données qui exclut les sauvegardes ne garantit rien. Restaurer une base chinoise depuis une copie mondiale revient à prouver que la copie mondiale existait. Le chiffrement ne corrige pas cette contradiction : une donnée chiffrée reste une donnée transférée si la clé, le déchiffrement ou l’usage restent accessibles.
Séparation d’architecture et contrôle des accès
Section intitulée « Séparation d’architecture et contrôle des accès »La séparation recommandée comporte au minimum un plan de données local, un plan de clés local et un plan d’administration dont les accès sont explicitement journalisés. Un tenant distinct chez un fournisseur cloud peut suffire pour certains services, à condition que les contrats, les interfaces de support, les comptes racine et les services managés ne réintroduisent pas un accès mondial implicite.
Les clés de chiffrement doivent être traitées séparément des données. Une DEK (Data Encryption Key) chiffre les données applicatives ; une KEK (Key Encryption Key) protège la DEK. Si la KEK est administrée depuis une région hors de Chine, l’architecture doit analyser si ce contrôle constitue un transfert ou un accès transfrontalier aux données protégées. La réponse dépend du cas, mais l’absence de journalisation du déchiffrement rend l’analyse impossible.
Un HSM (Hardware Security Module) local limite l’export des clés privées et matérialise la séparation cryptographique. Il ne règle ni la classification des données ni le transfert d’un export SQL vers un ticket de support. Un HSM ne sécurise pas magiquement une organisation, il rend surtout certaines mauvaises idées plus difficiles à exécuter. C’est déjà beaucoup.
L’authentification fédérée mérite une attention particulière. Un fournisseur d’identité global peut envoyer hors de Chine des identifiants, des adresses électroniques, des adresses IP, des événements de connexion et des métadonnées de terminal. La fédération réduit le nombre de mots de passe, pas le nombre de transferts. Une architecture locale doit donc prévoir soit un fournisseur d’identité régional, soit une fédération dont les attributs, journaux et chemins de récupération sont documentés et limités.
Les mécanismes décrits dans la page sur les identités restent valables : authentification multifacteur, comptes nominaux, privilèges temporaires, journalisation et révocation. Ils ne garantissent pas la conformité territoriale. La révocation d’un accès coupe une session future ; elle ne rappelle ni les exports déjà réalisés ni les captures de journaux déjà expédiées.
Surface d’attaque des flux soumis à la CAC
Section intitulée « Surface d’attaque des flux soumis à la CAC »Le principal risque technique vient des ponts entre zones : bastion d’administration global, réseau privé virtuel, agent de supervision, dépôt de code, outil de gestion des incidents ou plateforme d’analyse comportementale. Chaque pont devient simultanément un risque de fuite, un risque de disponibilité et un objet de contrôle réglementaire.
Un accès d’exploitation transfrontalier doit être limité à des sessions nominatives, temporaires et enregistrées. Les comptes partagés d’administration sont incompatibles avec une traçabilité crédible. La séparation des rôles doit empêcher le même compte d’exporter une base, de modifier les règles de sortie et d’effacer les journaux. Sans cette séparation, le contrôle d’accès devient une décoration de tableau de bord.
Les journaux doivent être classifiés. Un journal HTTP contient souvent des adresses IP, des identifiants de session, des URL et parfois des paramètres secrets. Centraliser tous les logs dans une plateforme mondiale est un réflexe d’exploitation, pas une décision neutre. Filtrer les champs, pseudonymiser les identifiants et conserver une plateforme locale pour les événements bruts réduisent l’exposition. La pseudonymisation ne supprime pas automatiquement la qualification d’information personnelle lorsqu’une table de correspondance ou un autre moyen permet la réidentification.
La disponibilité pose aussi problème. Une dépendance vers un service mondial peut être inaccessible depuis la Chine, dégradée par la connectivité ou rendue indisponible par une modification réglementaire. Les composants de contrôle, notamment la résolution de noms, l’horodatage, les listes de révocation et les mises à jour de sécurité, doivent disposer d’un chemin local ou d’un mode dégradé documenté. Un service qui dépend d’un appel externe pour authentifier chaque requête n’est pas résilient parce que son diagramme comporte trois zones de disponibilité.
Exemple de contrôle automatisé des destinations de données
Section intitulée « Exemple de contrôle automatisé des destinations de données »Un registre de flux versionné permet de bloquer les destinations non approuvées avant déploiement. L’exemple suivant vérifie qu’aucun flux étiqueté cn-production ne cible une région hors de Chine. Il ne prouve pas la conformité réglementaire, mais il évite qu’une règle de routage improvisée transforme une dérogation en fuite permanente.
# Fichier flows.json attendu :# [{"environment":"cn-production","destination_region":"cn-north-1"}]
# Échouer si un flux de production chinois sort vers une région non chinoise.jq -e ' all( .[]; (.environment != "cn-production") or (.destination_region | startswith("cn-")) )' flows.json
# Le code de sortie vaut 0 si tous les flux respectent la règle, 1 sinon.Ce contrôle doit être exécuté sur les déclarations d’infrastructure, les règles de pare-feu, les configurations de collecteurs de journaux et les manifestes de sauvegarde. Le fichier d’inventaire ne doit pas être maintenu à la main comme un album de souvenirs. Il doit être produit ou vérifié à partir des configurations réellement déployées.
Les exceptions nécessitent un identifiant, un propriétaire, une finalité, une date d’expiration et un mécanisme de retrait. Une exception sans échéance est une architecture définitive qui porte une moustache réglementaire.
Exploitation, preuves et reprise après incident
Section intitulée « Exploitation, preuves et reprise après incident »La conformité CAC dépend de preuves exploitables : inventaire des traitements, classification des données, enregistrements de transferts, décisions d’accès, journaux de sécurité et résultats de contrôle. La conservation doit respecter les exigences applicables sans produire une seconde base de données personnelle dans un système de supervision incontrôlé.
La rotation des secrets doit couvrir les identifiants applicatifs, les certificats Transport Layer Security, ou TLS, les clés de chiffrement, les comptes de sauvegarde et les jetons d’API (Application Programming Interface). Une rotation qui réémet seulement le secret sans invalider l’ancien secret laisse une fenêtre d’usage indéfinie. Les procédures doivent préciser le délai de révocation, les dépendances de cache et le comportement des sessions existantes.
Les sauvegardes doivent rester dans le périmètre validé, être chiffrées, testées et restaurables sans dépendance non documentée vers une région externe. Tester uniquement la création d’une sauvegarde ne teste rien de sérieux. La reprise exige de vérifier la restauration, les clés, les comptes de service, les listes de contrôle d’accès et l’intégrité des journaux. Un coffre de sauvegarde dont la clé est inaccessible pendant un incident est un musée numérique.
La CAC ne garantit pas la sécurité technique d’une plateforme. Elle ne remplace ni une analyse de menaces, ni le durcissement système, ni les contrôles décrits dans les pages réseaux et cryptographie. Elle impose un cadre de contrôle territorial. La sécurité réelle dépend ensuite de la qualité des frontières, des identités, des clés et de l’exploitation quotidienne.
🦫 Explication de la marmotte 🍫
Section intitulée « 🦫 Explication de la marmotte 🍫 »L’autorité chinoise chargée du numérique surveille les services en ligne qui fonctionnent en Chine ou traitent des données liées à la Chine. Elle vérifie notamment où les données sont stockées, qui peut y accéder, si elles sortent du pays et quelles règles sont appliquées aux services en ligne.
Une organisation doit d’abord recenser les données collectées : identifiants, coordonnées, journaux de connexion, documents et données métiers. Elle doit ensuite indiquer où chaque donnée est stockée, copiée, sauvegardée et consultée. Les données qui quittent la Chine peuvent nécessiter une procédure particulière, selon leur nature, leur quantité et le type d’organisation concerné.
Le système informatique doit donc séparer les données locales des autres données. Les accès d’administration doivent être attribués à des personnes identifiées, limités dans le temps et enregistrés. Les clés utilisées pour chiffrer les données doivent être protégées et renouvelées. Les journaux techniques doivent éviter d’envoyer automatiquement des informations personnelles vers une plateforme située hors de Chine.
En cas d’incident, il faut pouvoir retrouver les données touchées, couper les accès, restaurer les sauvegardes et prouver ce qui s’est passé. Si les copies, les journaux ou les clés sont répartis sans contrôle, la séparation annoncée cesse d’exister. La règle pratique est donc de construire un environnement local vérifiable, puis de surveiller chaque passage de données vers l’extérieur.
À lire aussi
- Résidence des données et souveraineté cloudRésidence des données et souveraineté : distinguer la localisation réelle des données, le contrôle technique et les dépendances juridiques.
- CNILRéférence française pour la protection des données personnelles, le RGPD et la sécurité des traitements.
- Conformité export et sanctions numériquesSanctions numériques et géopolitique : architecturer les contrôles export, le filtrage des accès et les preuves de conformité cyber.
- Pourquoi les fuites de données persistent malgré la sécuritéEnquête sur les causes techniques, organisationnelles et économiques des fuites de données massives malgré des décennies d’investissement en sécurité.
Pages voisines
La citent
Cyberspace Administration of China et conformité cybersécurité
Elle cite
