Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Pratiche di etichettatura da evitare
Esistono delle pratiche da implementare per etichettare oggetti o infrastrutture AWS, ma esistono anche pratiche da evitare.
## Etichettatura incoerente
Come illustrato nella [Obiettivi](objectives.md) sezione, senza l'applicazione di tag non è possibile raggiungere un livello elevato di automazione, pulizia o monitoraggio. Analogamente, con tag incompleti o incoerenti, le informazioni necessarie per l'automazione o il monitoraggio non sono complete, con conseguenti risultati inaffidabili.
Immagina uno scenario in cui utilizzi una strategia di tagging per calcolare i costi totali per tutti i progetti. La strategia inizia nella proof-of-concept fase (PoC) e termina nella fase di produzione. Considera i seguenti scenari con tag applicati a dati e risorse per gli esempi di previsione delle vendite del progetto P1, D1 e Pr1 e per gli esempi di manutenzione post-vendita P2, D2 e Pr2 del progetto.
**Previsioni di vendita**
Esempio P1: progetto PoC (dominio e timestamp mancanti).
```
env: "poc"
project: "sales forecasting"
```
Esempio D1: fase di sviluppo (dominio mancante).
```
env: "dev"
project: "sales forecasting"
timestamp: 20210505T12:34:55
```
Esempio Pr1: fase di produzione (esistono tutti i valori).
```
env: "prod"
project: "sales forecasting"
domain: "machine learning"
timestamp: 20210505T12:34:55
```
Per la previsione delle vendite del progetto:
+ L'esempio P1 non menziona il dominio o il timestamp da cui proviene l'oggetto.
+ L'esempio D1 inoltre non menziona il dominio del progetto.
+ L'esempio Pr1 contiene tutti i dati richiesti.
Gli esempi P1 e D1 genereranno report o stime errati per la pianificazione perché i domini non sono definiti.
**Manutenzione post-vendita**
Esempio P2: progetto PoC (mancano tutti i tag).
Esempio D2: fase di sviluppo (progetto mancante).
```
env: "dev"
domain: "machine learning"
timestamp: 20210505T12:34:55
```
Esempio Pr2: fase di produzione (esistono tutti i valori).
```
env: "prod"
project: "post sales maintenance"
domain: "machine learning"
timestamp: 20210505T12:34:55
```
Per la manutenzione post-vendita del progetto:
+ L'esempio P2 non contiene alcuna informazione, quindi non può essere tracciato.
+ L'esempio D2 non menziona il nome del progetto, quindi non può essere tracciato.
+ L'esempio Pr2 contiene tutti i dati richiesti.
Gli esempi P2 e D2 comporteranno una segnalazione errata, una pianificazione insufficiente o una rendicontazione insufficiente a causa di tag mancanti o incoerenti.
Pertanto, è importante implementare la strategia di etichettatura in modo coerente.
## Dati errati e sensibili nei tag
L'etichettatura può essere controproducente se utilizzata con informazioni errate, sensibili o private. I tag errati possono produrre risultati fuorvianti. L'utilizzo di tag che includono dati sensibili, come le informazioni di identificazione personale (PII), può mettere a rischio la sicurezza di clienti e dipendenti.
**Informazioni errate nei tag**
Immagina uno scenario in cui utilizzi una strategia di tagging per calcolare i costi totali per ogni dominio o reparto. Hai appena terminato la fase di inserimento dei dati e ti stai muovendo verso l'apprendimento automatico. L'esempio seguente include tag personalizzati che sono stati copiati dalla fase precedente di un progetto.
```
env: "development"
project: "sales prediction"
domain: "data ingestion"
timestamp: 20210505T12:34:55
```
Il dominio è etichettato erroneamente come `data ingestion` nella fase precedente del progetto, invece del dominio corretto, che è. `machine learning` Ora, i report per il `data ingestion` dominio mostreranno costi, intervalli di tempo e allocazione delle risorse più elevati. Il `machine learning` dominio mostrerà valori inferiori per tali report. Ciò comporterà una pianificazione, un'allocazione del budget e una stima delle scadenze errate.
Avere i tag corretti è essenziale per un sistema funzionale.
**Informazioni sensibili nei tag**
AWS fornisce diversi strumenti per identificare le informazioni personali negli oggetti. Questi strumenti includono [Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html) e il [rilevamento di dati AWS Glue sensibili](https://docs.aws.amazon.com/glue/latest/ug/detect-PII.html) per trovare dati che possono essere utilizzati per identificare le persone. Tuttavia, è importante non utilizzare informazioni personali o dati sensibili nei tag.
Considera il seguente esempio di file in Amazon S3 con dati PII oscurati o resi anonimi.
```
{
firstName: "67A1790DCA55B8803AD024EE28F616A2",
lastName: "DRG54654DFHJGDYYRD",
age: 21,
city : "Frankfurt",
probability_of_purchase: 48.858093,
veggieName: "broccoli",
creditcard: false
}
```
Puoi vedere che il nome e il cognome del cliente sono stati sottoposti a hash. Tuttavia, in questo esempio, il record presenta i seguenti tag personalizzati.
```
owner: "Company XYZ"
about: "John Doe"
contact: "johnthegreat@email.com"
timestamp: 20210505T12:34:55
```
In questo caso, sebbene il file stesso non contenga informazioni personali, i tag contengono informazioni riservate. Ciò aumenta la probabilità di una fuga di informazioni, perché quando condividi o trasferisci un file o un oggetto, condividi o trasferisci anche i relativi metadati. Questo vale anche per altre AWS risorse, come database, tabelle, lavori e funzioni.
Pertanto è estremamente importante evitare di utilizzare informazioni private nei tag. Lo stesso concetto si estende alle informazioni cruciali o non pubbliche.