L’isolation des locataires Cloudflare AI Search compte dès qu’une application sert des organisations aux documents privés. Un résultat peut divulguer une information avant génération, et une citation exposer un document malgré une réponse apparemment anodine. La frontière d’autorisation doit couvrir tout le parcours de recherche.
Déduisez le périmètre du locataire de l’identité applicative authentifiée, puis sélectionnez l’instance permise ou appliquez des filtres obligatoires contrôlés par le serveur. Gardez ingestion, récupération, citations et caches dans le même modèle d’accès. Prouvez l’isolation avec des tests négatifs : changement de locataire, sessions périmées et ouverture directe d’une source étrangère.
Imaginez un SaaS où des distributeurs déposent des accords fournisseurs. Chacun souhaite un assistant expliquant ses conditions de livraison et remises. Le produit peut aussi proposer un manuel public commun. Combiner ces sources est utile seulement si le contenu privé ne traverse jamais la frontière prévue.
Il s’agit d’une conception et d’une approche d’acceptation proposées. Un espace de noms ou filtre seul n’est pas présenté comme suffisant pour toute exigence de sécurité.
L’isolation des locataires Cloudflare AI Search commence avant la recherche
Le guide multilocataire décrit les approches par instances distinctes ou partagées. L’architecture exige d’abord un modèle d’identité applicatif. Définissez ce qu’est un locataire et quels utilisateurs peuvent agir en son sein.
Obtenez le locataire depuis une session vérifiée ou un contexte fiable équivalent. Un paramètre peut exprimer la sélection souhaitée, mais le serveur doit vérifier son autorisation. Ne laissez jamais le modèle fournir le périmètre faisant autorité.
Pour un collègue membre de plusieurs distributeurs, rendez l’organisation active explicite. En changer doit modifier les sources permises et le contexte conversationnel associé. Un passage privé récupéré avant le changement ne doit pas rester silencieusement dans la réponse suivante.
| Frontière | Entrée fiable | Substitut non fiable à rejeter |
|---|---|---|
| Sélection du locataire | Appartenance authentifiée et périmètre actif | Identifiant arbitraire du navigateur |
| Routage d’instance | Correspondance contrôlée par le serveur | Nom d’instance inventé par le modèle |
| Périmètre documentaire | Propriété et permissions vérifiées | Fichier téléversé revendiquant son locataire |
| Accès aux citations | Autorisation actuelle à l’ouverture | Simple possession de l’URL |
Comparer instances et filtrage obligatoire
Des instances séparées rendent parfois la frontière plus facile à inspecter, mais ajoutent gestion de cycle de vie et provisionnement. Une instance commune peut réduire ce travail ; chaque parcours doit alors appliquer le bon périmètre sans contournement facultatif.
La documentation des espaces de noms explique regroupement et accès par bindings. Examinez leur périmètre soigneusement. Un regroupement logique ne prouve pas le bon routage de tous les appelants.
| Choix | Avantage opérationnel à examiner | Responsabilité restante |
|---|---|---|
| Instances par locataire | Séparation plus claire des sources et cycles | Routage et appartenance corrects |
| Instance partagée avec filtres | Ingestion et gestion d’index communes | Périmètre obligatoire partout |
| Collection publique distincte | Contenu partagé explicite | Empêcher l’ingestion privée dans cette collection |
| Sous-ensembles restreints | Accès plus fin dans un locataire | Permissions documentaires actuelles |
Choisissez selon permissions et exploitation, pas seulement le nombre de locataires. Un locataire avec des équipes internes restreintes peut demander plus qu’une frontière d’organisation, quelle que soit la disposition des instances.
Appliquer le périmètre à l’ingestion et aux requêtes
Établissez la propriété à l’entrée du contenu. Associez chaque source à son locataire et à sa visibilité prévue via des métadonnées applicatives fiables. N’acceptez pas une propriété déclarée par l’upload sans contrôler l’autorité de l’appelant.
Gardez les identifiants stables entre mises à jour. Un accord de remplacement doit modifier le contenu du bon locataire, et une suppression viser source et dérivés corrects. Une collision d’identifiants peut casser l’isolation avant même la recherche.
Séparez décisions d’ingestion publique et privée. Un manuel commun peut être volontairement public ; un accord fournisseur ne doit pas y entrer parce que son extension ou dossier ressemble à un manuel.
Consignez quelle identité d’ingestion peut lire chaque emplacement source. L’application peut filtrer correctement alors qu’un connecteur trop large importe du contenu qu’il ne devrait jamais traiter. La révision du périmètre couvre les deux côtés de la chaîne.
Faire des filtres une politique non facultative
Cloudflare documente le filtrage de récupération . Traduisez les permissions actuelles dans le contrat de filtre choisi et testez la requête réelle du serveur.
N’exposez pas un objet filtre générique remplaçable par un client ordinaire. N’ajoutez pas non plus un repli pratique sans filtre lorsqu’aucun résultat ne correspond. L’absence de résultat est valide et nécessaire pour une information absente ou interdite.
Séparez périmètre applicatif et préférences comme type de document ou langue. L’utilisateur peut restreindre la recherche, mais pas retirer la condition obligatoire d’accès par une option.
Testez chaque voie : résultats, réponses générées, exports, outils d’agents et aperçus administratifs. Une page sûre ne compense pas un outil non filtré interrogeant la même collection.
Protéger citations, caches et historique
Une réponse peut omettre un passage privé tout en retournant un titre ou une URL révélant un autre locataire. Vérifiez tous les champs, pas seulement la prose.
Ouvrez les citations avec les droits documentaires actuels. Si l’application sert la source, vérifiez d’abord l’appelant. Pour un système documentaire externe, établissez que le lien préserve ses règles d’accès.
Incluez locataire et permissions pertinentes dans tout cache applicatif. Une réponse propre à une organisation ne doit pas devenir partagée simplement parce que la question est identique.
L’historique peut conserver des passages après changement d’organisation ou perte d’accès. Décidez quel historique peut être rouvert et quel contexte fourni au modèle. La révocation doit avoir un effet défini sur les copies dérivées, pas seulement la requête en direct.
Construire des tests négatifs révélant les fuites
Utilisez des documents synthétiques aux marqueurs distincts et impossibles à confondre. Posez la même question sous plusieurs organisations et vérifiez l’absence du marqueur étranger dans passages, réponses, métadonnées et citations.
| Test | Résultat attendu |
|---|---|
| Modifier l’identifiant demandé | Rejet ou maintien du périmètre permis |
| Chercher une phrase privée d’un autre locataire | Aucun passage, réponse ou citation privé |
| Ouvrir son URL documentaire | Accès refusé |
| Changer d’organisation active | Recherche et contexte suivent le nouveau périmètre permis |
| Retirer l’appartenance en session | Accès suivants selon droits actuels |
| Répéter une question mise en cache entre locataires | Aucune réutilisation croisée |
Traitez séparément un administrateur multilocataire autorisé. Le diagnostic administratif exige sa propre autorité et ses preuves. Ne normalisez pas ses résultats larges dans les tests des utilisateurs ordinaires.
Répétez les tests après modification de routage, ingestion, filtres ou caches. La pertinence seule ne détecte pas une régression de permissions : un résultat très pertinent peut être précisément le document interdit.
Budgéter le cycle des permissions
L’effort dépend d’appartenance, droits documentaires, intégrations sources et nombre de voies de recherche. Une simple démonstration de filtre omet beaucoup du cycle réel d’un SaaS.
Demandez un devis en GBP comprenant provisionnement, changements de locataire, suppression, révocation et acceptation. Précisez si l’isolation s’arrête à l’organisation ou couvre équipes et documents internes.
| Domaine | Preuve à demander |
|---|---|
| Identité | Règles d’appartenance et de changement |
| Ingestion | Propriété vérifiée et correspondance d’accès source |
| Recherche | Périmètre serveur sur chaque voie |
| Dérivés | Politiques de cache, citation et historique |
| Exploitation | Procédures de provisionnement, suppression et incident |
Un pilote d’intégration IA limité peut tester organisations synthétiques et documents représentatifs avant les données privées. Demandez une proposition de recherche multilocataire avec modèle d’appartenance et permissions sources. L’isolation devient un contrat testable plutôt qu’une étiquette rassurante sur un schéma.
Questions fréquentes
Chaque locataire exige-t-il sa propre instance AI Search ? Pas forcément. Cloudflare documente instances distinctes et partagées. Comparez permissions, provisionnement et fiabilité du filtrage obligatoire. Aucune approche n’élimine l’autorisation applicative.
Le navigateur peut-il envoyer l’identifiant du locataire ? Il peut demander une sélection, mais le serveur doit la vérifier avec l’appartenance authentifiée. Un paramètre arbitraire ou une valeur du modèle n’est pas une source d’autorité.
Les espaces de noms constituent-ils un système d’autorisation ? Ils organisent l’accès aux instances selon le modèle de binding documenté. L’application doit authentifier et router correctement. Examinez le périmètre et prouvez la frontière avec les tests négatifs ordinaires.
Une recherche vide doit-elle recommencer sans filtre ? Non. Retirer le périmètre obligatoire peut exposer autrui. Retournez une absence utile ou examinez indexation et permissions sans élargir l’accès de l’utilisateur.
Les citations peuvent-elles divulguer des informations ? Oui. Titres, URL, extraits et téléchargements peuvent révéler du privé même si la réponse l’omet. Testez toute la réponse et exigez l’autorisation actuelle à l’ouverture.
Que se passe-t-il à la perte d’appartenance ? Les accès suivants doivent respecter les permissions actuelles. Définissez l’effet sur sessions, caches, historique et copies dérivées autant que la recherche directe. Testez la révocation pendant une session.
Que doit prouver le pilote d’isolation ? Que les utilisateurs ordinaires ne récupèrent pas, ne déduisent pas depuis les métadonnées et n’ouvrent pas les sources privées d’autrui. Incluez falsification de périmètre, changement, cache, mises à jour et révocation.