Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Pratiques de marquage à éviter
Bien qu'il existe des pratiques à mettre en œuvre lors du marquage d'objets ou d'infrastructures AWS, il existe également des pratiques à éviter.
Balisage incohérent
Comme indiqué dans la Objectifs section, sans balisage, vous ne pouvez pas atteindre un niveau élevé d'automatisation, de nettoyage ou de surveillance. De même, lorsque les balises sont incomplètes ou incohérentes, les informations requises pour l'automatisation ou la surveillance ne sont pas complètes, ce qui entraîne des résultats peu fiables.
Imaginez un scénario dans lequel vous utiliseriez une stratégie de balisage pour calculer les coûts totaux de tous les projets. La stratégie commence à la proof-of-concept phase (PoC) et se termine à la phase de production. Envisagez les scénarios suivants avec des balises appliquées aux données et aux ressources pour les exemples de prévisions des ventes de projets P1, D1 et Pr1 et pour les exemples de maintenance après-vente de projets P2, D2 et Pr2.
Prévisions des ventes
Exemple P1 : projet PoC (domaine et horodatage manquants).
env: "poc" project: "sales forecasting"
Exemple D1 : phase de développement (domaine manquant).
env: "dev" project: "sales forecasting" timestamp: 20210505T12:34:55
Exemple Pr1 : phase de production (toutes les valeurs existent).
env: "prod" project: "sales forecasting" domain: "machine learning" timestamp: 20210505T12:34:55
Pour les prévisions des ventes du projet :
-
L'exemple P1 ne mentionne pas le domaine ou l'horodatage de l'objet.
-
L'exemple D1 ne mentionne pas non plus le domaine du projet.
-
L'exemple Pr1 contient toutes les données requises.
Les exemples P1 et D1 entraîneront des rapports ou des estimations incorrects pour la planification car les domaines ne sont pas définis.
Maintenance après-vente
Exemple P2 : projet PoC (toutes les balises sont manquantes).
Exemple D2 : phase de développement (projet manquant).
env: "dev" domain: "machine learning" timestamp: 20210505T12:34:55
Exemple Pr2 : phase de production (toutes les valeurs existent).
env: "prod" project: "post sales maintenance" domain: "machine learning" timestamp: 20210505T12:34:55
Pour la maintenance après-vente du projet :
-
L'exemple P2 ne contient aucune information et ne peut donc pas être suivi.
-
L'exemple D2 ne mentionne pas le nom du projet, il ne peut donc pas être suivi.
-
L'exemple Pr2 contient toutes les données requises.
Les exemples P2 et D2 entraîneront des rapports incorrects, une sous-planification ou une sous-déclaration en raison de balises manquantes ou incohérentes.
Il est donc important de mettre en œuvre la stratégie de balisage de manière cohérente.
Données incorrectes et sensibles dans les balises
Le balisage peut être contreproductif s'il est utilisé avec des informations incorrectes, sensibles ou privées. Des balises incorrectes peuvent produire des résultats trompeurs. L'utilisation de balises contenant des données sensibles, telles que des informations personnelles identifiables (PII), peut mettre en danger la sécurité de vos clients et de vos employés.
Informations incorrectes dans les balises
Imaginez un scénario dans lequel vous utiliseriez une stratégie de balisage pour calculer les coûts totaux pour chaque domaine ou département. Vous venez de terminer votre phase d'ingestion de données et vous vous dirigez vers le machine learning. L'exemple suivant inclut des balises personnalisées qui ont été copiées à partir de la phase précédente d'un projet.
env: "development" project: "sales prediction" domain: "data ingestion" timestamp: 20210505T12:34:55
Le domaine est mal étiqueté comme lors data ingestion de la phase précédente du projet, au lieu du bon domaine, qui estmachine learning. Désormais, les rapports relatifs au data ingestion domaine indiqueront les coûts, l'intervalle de temps et l'allocation des ressources plus élevés. Le machine learning domaine affichera des valeurs inférieures pour ces rapports. Cela se traduira par une planification, une allocation budgétaire et des estimations de délais incorrectes.
Disposer des balises appropriées est essentiel au bon fonctionnement du système.
Informations sensibles contenues dans les tags
AWS fournit plusieurs outils pour identifier les informations personnelles dans les objets. Ces outils incluent Amazon Macie et la détection des données AWS Glue sensibles pour trouver des données pouvant être utilisées pour identifier des individus. Cependant, il est important de ne pas utiliser d'informations personnelles ou de données sensibles dans les balises.
Prenons l'exemple suivant d'un fichier dans Amazon S3 dont les informations personnelles ont été expurgées ou anonymisées.
{ firstName: "67A1790DCA55B8803AD024EE28F616A2", lastName: "DRG54654DFHJGDYYRD", age: 21, city : "Frankfurt", probability_of_purchase: 48.858093, veggieName: "broccoli", creditcard: false }
Vous pouvez voir que le prénom et le nom de famille du client ont été hachés. Toutefois, dans cet exemple, l'enregistrement possède les balises personnalisées suivantes.
owner: "Company XYZ" about: "John Doe" contact: "johnthegreat@email.com" timestamp: 20210505T12:34:55
Dans ce cas, bien que le fichier lui-même ne contienne aucune information personnelle, les balises contiennent des informations sensibles. Cela augmente le risque de fuite d'informations, car lorsque vous partagez ou transférez un fichier ou un objet, vous partagez ou transférez également ses métadonnées. Cela s'applique également à d'autres AWS ressources, telles qu'une base de données, des tables, des tâches et des fonctions.
Il est donc extrêmement important d'éviter d'utiliser des informations privées dans les tags. Le même concept s'applique aux informations cruciales ou non publiques.
