Comment mieux contrôler les données dans une stack autonome

Sécuriser chaque application d’une stack marketing autonome laisse subsister un second problème de sécurité : que devient une donnée sensible après sa réception par un composant autorisé ? Un workflow peut utiliser des applications authentifiées et des identifiants API valides tout en envoyant des informations personnelles identifiables (PII) de clients, des stratégies propriétaires ou des informations financières à des composants qui n’ont pas besoin de ces données. Pour les responsables des opérations marketing (MOps), chaque transfert doit donc faire partie de la conception de la sécurité.

L’évaluation des fournisseurs détermine si une application est approuvée pour l’usage. La gouvernance des flux détermine quelles informations elle peut recevoir, combien de temps elle peut les conserver et où ces informations peuvent ensuite être envoyées. À mesure que les logiciels acquièrent davantage d’autorité pour analyser des segments, générer des messages et exécuter des campagnes sur des plateformes connectées, les équipes ont besoin de règles explicites pour ces transferts.

Sécuriser chaque application laisse les transferts à gouverner

La sécurité des applications commence par des contrôles bien connus tels que les comptes authentifiés, les utilisateurs restreints, les évaluations des fournisseurs, la configuration des applications et les engagements contractuels. Ces contrôles régissent chaque composant. Un workflow autonome crée une autre décision de sécurité chaque fois qu’un composant autorisé envoie des données à un autre.

Prenons le cas d’un composant qui construit un segment client et envoie du contexte à un second composant qui génère des messages personnalisés. Le second composant peut avoir besoin des attributs du segment. Il peut n’avoir aucun besoin fonctionnel des adresses e-mail brutes, des numéros de téléphone, des dossiers de facturation, des données de chiffre d’affaires de l’entreprise ou de tout autre champ disponible en amont. Des identifiants valides établissent l’accès ; la conception du workflow doit établir quels champs sont nécessaires à la tâche.

Le même principe s’applique aux autorisations. Une identité autonome dotée de scopes API étendus peut accéder à tout ce que ces autorisations exposent, y compris à des ressources en dehors de sa fonction assignée. Si ses identifiants sont compromis, les autorisations associées à cette identité définissent ce qui peut être demandé par son intermédiaire. Restreindre ces scopes limite les ressources accessibles via cette identité.

Pour chaque transfert, l’organisation doit décider quelles données peuvent franchir la frontière et quelle identité est autorisée à les déplacer.

Faire de chaque transfert une frontière de sécurité gouvernée

Le premier contrôle est la minimisation des données : n’envoyer que les informations requises pour la tâche en aval. Dans l’exemple du segment et de la messagerie, un composant peut avoir besoin d’attributs descriptifs sans avoir de raison fonctionnelle de recevoir l’adresse e-mail réelle d’un client. Le workflow peut supprimer un champ inutile ou le remplacer par un token avant d’envoyer la charge utile plus loin.

Une instruction au niveau du prompt ne remplit pas la même fonction. Si une charge utile contient déjà une adresse e-mail, dire à un modèle d’ignorer ce champ envoie malgré tout l’adresse dans la charge utile. Supprimer le champ avant la transmission empêche cette valeur d’entrer dans le circuit de traitement. La règle doit suivre la tâche de la destination, car certaines opérations peuvent légitimement nécessiter une valeur protégée.

L’identité fournit le contrôle suivant. Chaque profil autonome peut avoir sa propre identité et des scopes API alignés sur sa fonction assignée. Les administrateurs peuvent alors révoquer l’accès d’un composant sans modifier automatiquement des identités sans lien, tandis que les journaux d’activité peuvent enregistrer une identité automatisée distincte. Des identifiants partagés affaiblissent cette séparation, car plusieurs composants opèrent via le même compte.

Le traitement des données après transmission exige une décision distincte. Avant que des données opérationnelles ne soient envoyées à une application externe, les équipes doivent établir les conditions de conservation, la configuration de traitement et les engagements contractuels pour ce déploiement. « Zero-data-retention » signifie l’exigence selon laquelle le fournisseur ne conserve pas les données soumises au-delà de la période de traitement autorisée. Le fait qu’un service et un contrat donnés satisfassent à cette exigence doit être vérifié pour le déploiement utilisé.

La politique d’entraînement exige la même vérification spécifique au fournisseur. Les équipes doivent consigner les usages autorisés des données soumises comme une exigence pour chaque destination, plutôt que de supposer une politique commune à l’ensemble des services externes.

Ces contrôles traitent différentes parties d’un même échange. La minimisation des données détermine ce qui est transmis. L’identité et les scopes API déterminent quel composant automatisé peut le demander ou l’envoyer. Les exigences de conservation, de traitement et contractuelles régissent le traitement autorisé à la destination.

Les mêmes informations doivent figurer dans la gestion des changements. Ajouter un scope API, diriger un workflow vers un autre endpoint ou donner à un composant existant un contexte client plus riche modifie le flux, même si la liste des fournisseurs reste la même. Un inventaire utile des flux enregistre l’identité autonome, ses scopes, les classes de données accessibles, la destination et les exigences de traitement applicables.

Les contrats et les contrôles techniques jouent des rôles différents dans cet inventaire. Les clauses contractuelles définissent les obligations du fournisseur. Le filtrage des charges utiles, les scopes API, la configuration réseau et les paramètres des endpoints définissent le chemin technique déployé. Conserver les deux formes de preuve associées au flux facilite l’examen de ce qui a été promis et de ce qui a été configuré.

Certains workloads justifient une frontière de modèle isolée

La minimisation des données et les contrôles d’accès peuvent malgré tout laisser subsister des workloads qu’une organisation classe comme trop sensibles pour un environnement de traitement externe. Une option d’architecture consiste à exécuter un modèle open source ou propriétaire dans un cloud privé virtuel isolé, soumis aux propres contrôles réseau et d’identité de l’organisation.

La décision de placement doit découler des exigences de données du workload et du modèle de menace de l’organisation. Des entrées assainies peuvent satisfaire les exigences d’un workflow. Des informations client hautement sensibles ou des renseignements propriétaires sur l’entreprise peuvent conduire l’organisation à exiger un traitement au sein d’une infrastructure qu’elle contrôle plus directement. Cette décision doit préciser les chemins réseau requis, les identités, les règles d’accès et la journalisation.

Un déploiement privé exige toujours des contrôles sur les identités, les autorisations, les entrées et les transferts internes. Déplacer le traitement dans un environnement privé modifie l’emplacement du workload et sa frontière administrative. Chaque composant autonome a toujours besoin d’une définition explicite des informations auxquelles il peut accéder et des actions que son identité peut effectuer.

La capacité opérationnelle compte également dans le choix des contrôles. Le filtrage centralisé des charges utiles, les identités machine granulaires, l’infrastructure privée et la gouvernance contractuelle exigent chacun un travail de mise en œuvre et de maintenance. Une organisation peut prioriser les contrôles selon la sensibilité des données et le risque du workload tout en conservant la même unité centrale de gouvernance : chaque flux a un expéditeur identifié, une charge utile autorisée, une destination permise et des règles de traitement définies.

Points clés à retenir pour les décideurs

Gouvernez les transferts : Les évaluations des fournisseurs et l’accès authentifié ne contrôlent pas quelles données circulent entre des composants autonomes. Les dirigeants doivent définir les données autorisées et l’identité pour chaque transfert de workflow.
Faites de chaque flux de données une frontière de sécurité : Minimisez les charges utiles, attribuez des identités machine distinctes avec des scopes API restreints et établissez des exigences de conservation et de traitement pour chaque destination. Suivez ces contrôles dans la gestion des changements à mesure que les workflows, les endpoints et les autorisations évoluent.
Isolez les workloads lorsque la sensibilité l’exige : Des données client ou d’entreprise hautement sensibles peuvent justifier l’exécution de modèles dans un environnement privé contrôlé. Fondez cette décision sur le workload et le modèle de menace, tout en maintenant des contrôles sur les identités, les autorisations, les transferts et la journalisation à l’intérieur de la frontière privée.