1. Introduzione

1. Introduzione

La questione di come un sistema possa sapere che un altro sistema può essere affidabile ha trovato nuovo interesse e rilevanza in un mondo in cui gli elementi di calcolo affidabile stanno maturando nelle architetture dei processori.

I sistemi che sono stati attestati e verificati come in buono stato (per un certo valore di "buono") possono migliorare la postura complessiva del sistema. Al contrario, i sistemi che non possono essere attestati e verificati come in buono stato possono ricevere accesso o privilegi ridotti, essere rimossi dal servizio o altrimenti contrassegnati per la riparazione.

Ad esempio:

• Un sistema backend bancario potrebbe rifiutarsi di effettuare transazioni con un altro sistema che non è noto essere in buono stato.

• Un sistema sanitario potrebbe rifiutarsi di trasmettere cartelle cliniche elettroniche a un sistema che non è noto essere in buono stato.

Nelle procedure di attestazione remota (Remote ATtestation procedureS, RATS), un peer (l'"Attestatore" (Attester)) produce informazioni credibili su se stesso ("Evidenza" (Evidence)) per consentire a un peer remoto (la "Parte Affidataria" (Relying Party)) di decidere se considerare o meno quell'Attestatore un peer affidabile. Le procedure di attestazione remota sono facilitate da una parte aggiuntiva vitale (il "Verificatore" (Verifier)).

Il Verificatore valuta l'Evidenza tramite politiche di valutazione (appraisal policies) e crea i Risultati di Attestazione (Attestation Results) per supportare le Parti Affidatarie nel loro processo decisionale. Questo documento definisce un'architettura flessibile costituita da ruoli di attestazione e dalle loro interazioni tramite messaggi concettuali. Inoltre, questo documento definisce un insieme universale di termini che possono essere mappati a varie procedure di attestazione remota esistenti ed emergenti. Vengono illustrati i modelli topologici comuni e la sequenza dei flussi di dati ad essi associati, come il "Modello Passaporto" (Passport Model) e il "Modello Controllo Precedenti" (Background-Check Model). Lo scopo è definire una terminologia utile per l'attestazione remota e consentire ai lettori di mappare la loro architettura di soluzione all'architettura di attestazione canonica fornita qui. Avere una terminologia comune che fornisca significati ben compresi per temi comuni, come ruoli, composizione dei dispositivi, modelli topologici e procedure di valutazione, è vitale per l'interoperabilità semantica tra soluzioni e piattaforme che coinvolgono più fornitori e provider.

Tra le altre cose, questo documento riguarda la fiducia (trust) e l'affidabilità (trustworthiness). La fiducia è una scelta che si fa riguardo a un altro sistema. L'affidabilità è una qualità dell'altro sistema che può essere utilizzata nel prendere la propria decisione se fidarsi di esso o meno. Questa è una differenza sottile; essere familiari con la differenza è cruciale per utilizzare questo documento. Inoltre, i concetti di freschezza (freshness) e relazioni di fiducia (trust relationships) sono specificati per consentire agli implementatori di scegliere soluzioni appropriate per comporre le loro procedure di attestazione remota.