Obbligo di acquisto

L’obbligo di acquisto stabilisce che le applicazioni, conformemente alle condizioni quadro definite nella direttiva W008, devono ottenere le identità digitali, più precisamente la prestazione di autenticazione basata su di esse, obbligatoriamente dal servizio standard IAM Confederazione, ossia dal servizio eIAM della CaF TDT e, nei casi d’uso previsti a tale scopo, dal SSO-Portal del DFGP.

Per le applicazioni la cui prestazione di autenticazione deve essere ottenuta tramite eIAM, eIAM costituisce il punto di accesso previsto ai gestori di identità ammessi. Ciò vale indipendentemente dal fatto che eIAM sia collegato direttamente dall’applicazione di destinazione oppure, ove ammesso, indirettamente tramite un portale, un sistema IAM intermedio o un altro componente di intermediazione.

Se l’e-ID statale svizzera viene utilizzata allo scopo di autenticare una persona nei confronti di un’applicazione di destinazione soggetta all’obbligo di acquisto, tale utilizzo avviene tramite il componente del servizio standard AGOV. L’e-ID non può essere utilizzata direttamente, aggirando AGOV, come mezzo di login o di autenticazione proprio dell’applicazione. Per l’Amministrazione federale centrale, AGOV viene in linea di principio ottenuto tramite eIAM; AGOV «direct only» è ammesso unicamente se è stata concessa un’autorizzazione di deroga a tale scopo.

Di conseguenza, altre modalità di ottenimento della prestazione di autenticazione prescritta, ad esempio il collegamento diretto di gestori di identità (IdP) ad applicazioni, middleware, SaaS o altri sistemi di destinazione, nonché procedure di login proprie delle applicazioni, necessitano di un’autorizzazione di deroga della CaF TDT, nella misura in cui si applica l’obbligo di acquisto e la direttiva W008 non preveda altrimenti.

Nell’ambito del servizio standard IAM Confederazione è possibile ottenere anche la gestione delle autorizzazioni (Access Management). Occorre distinguerla dall’autorizzazione granulare interna all’applicazione, in particolare dalla gestione delle autorizzazioni relative a funzioni e dati all’interno di un’applicazione. Conformemente alla direttiva W008, tale autorizzazione granulare non fa parte del servizio standard IAM Confederazione e può essere gestita nell’applicazione di destinazione, in un middleware, in un SaaS o in un altro sistema previsto a tale scopo.

Questa regolamentazione persegue gli obiettivi di un’economicità ottimizzata, di un livello di sicurezza definito e della promozione della digitalizzazione dei processi amministrativi mediante l’interoperabilità delle identità digitali secondo il principio once-only.

Le spiegazioni seguenti si applicano alle prestazioni IAM che, conformemente alla direttiva W008, rientrano nel perimetro delle prestazioni del servizio standard IAM Confederazione e sono soggette all’obbligo di acquisto. Restano riservate le delimitazioni espressamente previste dalla direttiva W008 e le autorizzazioni di deroga validamente concesse.

L’obbligo di acquisto si fonda sull’ordinanza sulla digitalizzazione (ODigi) e sulla direttiva W008. Per le prestazioni IAM dell’Amministrazione federale centrale soggette all’obbligo di acquisto, il servizio standard costituisce la modalità di approvvigionamento prescritta. Le deroghe limitate a un’unità amministrativa o a un’applicazione sono decise dalla CaF TDT conformemente alla W008 e al processo P035 e sono limitate nel tempo.

Per le applicazioni web e le app mobili native soggette all’obbligo di acquisto, la prestazione di autenticazione deve essere in linea di principio ottenuta tramite eIAM. Ciò vale anche per i SaaS e per altre forme di esercizio nel cloud, indipendentemente dal fatto che una soluzione sia gestita o utilizzata internamente, esternamente, in Microsoft Azure, presso un altro hyperscaler o su un dispositivo mobile gestito dall’Amministrazione federale.

Microsoft Entra ID non costituisce una modalità alternativa a eIAM per l’autenticazione degli utenti di un’applicazione specialistica, un’applicazione web, una soluzione SaaS o un’app mobile nativa soggetta all’obbligo di utilizzare eIAM. La federazione diretta di tale applicazione di destinazione con Entra ID o l’utilizzo di Entra ID come servizio di login o di autenticazione non sono pertanto ammessi in assenza di una delimitazione applicabile o di un’autorizzazione di deroga.

Occorre distinguere da questo caso i servizi e le applicazioni Microsoft 365 messi a disposizione nell’ambito del servizio standard Burotica e autorizzati conformemente alle prescrizioni applicabili, in particolare AR009 ed E031. Il loro approvvigionamento IAM è disciplinato dalle prescrizioni specifiche del servizio standard Burotica. Questa configurazione specifica per M365 non costituisce un’autorizzazione generale a utilizzare Entra ID come servizio di autenticazione per altre applicazioni.

In particolare, un’applicazione specialistica o un’app mobile nativa non diventa un’applicazione Microsoft 365 e non viene esclusa dall’obbligo di utilizzare eIAM per il solo fatto di essere installata su un dispositivo gestito, distribuita, configurata, protetta o amministrata mediante Microsoft Intune, registrata in un tenant Entra ID, di utilizzare librerie Microsoft o di essere gestita in Microsoft Azure. Se l’applicazione è soggetta all’obbligo di utilizzare eIAM, l’autenticazione dei suoi utenti deve avvenire tramite eIAM.

In assenza di una delimitazione applicabile ai sensi della W008 o di una necessaria autorizzazione di deroga previamente concessa, sono in particolare vietati:

• le procedure proprie dell’applicazione per stabilire per la prima volta o nuovamente l’identità di un utente, ad esempio mediante account nome utente/password gestiti nell’applicazione o altre credenziali proprie dell’applicazione, se utilizzate al posto dell’autenticazione prescritta tramite eIAM;
• il collegamento diretto di un gestore di identità interno o esterno a un’applicazione di destinazione soggetta all’obbligo di acquisto, a un’app mobile nativa, a un middleware, a un livello di portale, a una soluzione SaaS o a un altro sistema di destinazione aggirando eIAM;
• la federazione diretta di un’applicazione specialistica, un’applicazione web, una soluzione SaaS o un’app mobile nativa soggetta all’obbligo di acquisto con Microsoft Entra ID oppure l’utilizzo di Entra ID come servizio di login o di autenticazione di tale applicazione al di fuori della configurazione M365 prevista nel servizio standard Burotica;
• l’utilizzo di Microsoft Entra ID come servizio di login o di autenticazione di un’app mobile nativa per il solo fatto che tale app è installata, distribuita, configurata, protetta o amministrata mediante Microsoft Intune;
• l’utilizzo di Microsoft Entra ID come servizio di login o di autenticazione di un’applicazione specialistica per il solo fatto che essa è gestita in Microsoft Azure, registrata in un tenant Entra ID o utilizza altri servizi dell’ecosistema cloud Microsoft;
• l’autenticazione diretta degli utenti di un’applicazione web o di un’app mobile nativa soggetta all’obbligo di acquisto nei confronti di Active Directory, LDAP, Kerberos o servizi di directory o di autenticazione comparabili aggirando eIAM; conformemente alle prescrizioni eIAM, l’utilizzo diretto di Kerberos da parte di applicazioni web e app mobili native necessita di un’autorizzazione di deroga;
• il collegamento diretto di IdP settoriali o di altri gestori di identità previsti per l’utilizzo tramite eIAM a sistemi di destinazione soggetti all’obbligo di acquisto o a sistemi IAM intermedi invece dell’ottenimento tramite eIAM;
• procedure di login proprie del portale o collegamenti diretti di gestori di identità su un livello di portale soggetto all’obbligo di acquisto; l’astrazione ammessa del collegamento eIAM mediante un livello di portale non elimina l’obbligo di acquisto;
• l’utilizzo di AGOV «direct only», ossia il collegamento diretto di AGOV a un’applicazione di destinazione o a un sistema IAM intermedio senza interposizione di eIAM, se per l’Amministrazione federale centrale non è stata previamente concessa un’autorizzazione di deroga a tale scopo; ciò vale anche per le app mobili native;
• l’utilizzo diretto dell’e-ID statale svizzera come mezzo di login o di autenticazione proprio di un’applicazione di destinazione o di un’app mobile nativa soggetta all’obbligo di acquisto, aggirando AGOV o la modalità di approvvigionamento IAM prescritta per l’applicazione interessata;
• l’interposizione a monte o intermedia di un sistema IAM, Identity Broker, di federazione o Single Sign-on se in tal modo eIAM viene sostituito o aggirato quale fonte prescritta della prestazione di autenticazione;
• l’introduzione di isole di login separate per singole applicazioni specialistiche, app mobili native, soluzioni SaaS, progetti, unità organizzative o gruppi di utenti, se la relativa prestazione di autenticazione è soggetta all’obbligo di acquisto del servizio standard IAM Confederazione.

Non è interessata la gestione delle autorizzazioni specifica dell’applicazione (Access Management), nella misura in cui riguarda l’autorizzazione e in particolare l’autorizzazione granulare all’interno dell’applicazione. Oggetti utente, ruoli, autorizzazioni, attributi specialistici e altre informazioni necessarie all’autorizzazione possono, conformemente alle prescrizioni applicabili, essere gestiti nell’applicazione di destinazione, in un middleware, in un SaaS o in un altro sistema previsto a tale scopo. Ciò non deve tuttavia comportare la sostituzione della prestazione di autenticazione prescritta con un approvvigionamento IAM proprio o diverso.

Per le app mobili native occorre inoltre distinguere tra l’autenticazione nei confronti di eIAM e l’accesso locale a uno stato di login già stabilito tramite eIAM e reso persistente. La persistenza del login è ammessa conformemente alle prescrizioni eIAM. Il nuovo accesso a tale stato di login persistente può essere autorizzato localmente mediante la protezione del dispositivo, in particolare tramite biometria o PIN del dispositivo. Tale riautenticazione locale non costituisce né un gestore di identità alternativo né un aggiramento dell’obbligo di utilizzare eIAM. Quando è necessaria una nuova autenticazione nei confronti del sistema IAM, essa avviene nuovamente tramite eIAM.

Sono altresì ammessi collegamenti indiretti a eIAM tramite portali, sistemi IAM intermedi o componenti di intermediazione comparabili, purché trasmettano all’applicazione di destinazione la prestazione di autenticazione ottenuta da eIAM e non sostituiscano né aggirino eIAM quale istanza di autenticazione prescritta. Lo stesso vale per i ponti di autenticazione che collegano a eIAM un’applicazione di destinazione altrimenti non compatibile.

Occorre inoltre distinguere l’utilizzo non ammesso di Entra ID come servizio alternativo di autenticazione degli utenti dall’utilizzo tecnico dell’ecosistema cloud Microsoft ammesso dalle prescrizioni applicabili. AR015 disciplina in particolare account Entra ID, registrazioni di applicazioni, Service Principals, tenant e altri componenti necessari all’esercizio di soluzioni cloud. Il loro utilizzo tecnico non costituisce di per sé un’autenticazione alternativa degli utenti. Esso non autorizza tuttavia l’impiego di Entra ID al posto di eIAM come gestore di identità o servizio di autenticazione di un’applicazione di destinazione soggetta all’obbligo di utilizzare eIAM. Restano applicabili le prescrizioni di AR015 relative all’intermediazione delle identità e alla federazione tramite il servizio standard IAM.

È quindi determinante la funzione e non il prodotto, la piattaforma o il luogo di esercizio: se l’autenticazione degli utenti è soggetta all’obbligo di acquisto del servizio standard IAM Confederazione, essa deve avvenire tramite il servizio del servizio standard previsto a tale scopo. Un’altra modalità di autenticazione è ammessa soltanto se la prestazione IAM interessata non è soggetta all’obbligo di acquisto secondo la W008 oppure se la necessaria autorizzazione di deroga è stata previamente concessa.

Le autorizzazioni di deroga sono disciplinate dalla direttiva W008 e dal processo P035. Le deroghe limitate a un’unità amministrativa o a un’applicazione sono decise dalla CaF TDT e sono limitate nel tempo.

Le autorizzazioni di deroga per l’approvvigionamento IAM di applicazioni web e app mobili native al di fuori del servizio standard pertinente dell’Amministrazione federale vengono concesse per esercizi pilota con una durata strettamente limitata.

Per l’approvvigionamento IAM di applicazioni web e app mobili native in esercizio produttivo, le prescrizioni eIAM pubblicate prevedono che in linea di principio non vengano concesse autorizzazioni di deroga, nemmeno con un numero ridotto di utenti o un basso fabbisogno di protezione, salvo in caso di assoluta impossibilità tecnica o di situazione urgente. Il solo fatto che un prodotto disponga già di un proprio meccanismo di login o che il fabbricante supporti soltanto un’altra soluzione IAM non costituisce di per sé un motivo di deroga.

AGOV «direct only» è previsto per l’Amministrazione federale centrale come caso di deroga molto raro e soggetto ad autorizzazione. In assenza della relativa autorizzazione preventiva, AGOV viene ottenuto tramite eIAM «full».

Gli acquisti di software, SaaS e altre soluzioni cloud ecc. devono essere interamente orientati alla possibilità di collegamento a eIAM conformemente a . Per le soluzioni soggette all’obbligo di acquisto, la possibilità di collegamento al servizio standard prescritto costituisce un criterio obbligatorio.

Se vengono acquisite soluzioni TIC, incluse soluzioni cloud come SaaS, che non possono essere collegate a eIAM nell’ambito dello standard eIAM, il proprietario dell’applicazione è tenuto a far sviluppare e gestire un ponte di autenticazione sotto forma di adattatore. Cfr. .

Un’autorizzazione di deroga concessa vale esclusivamente per il campo d’applicazione indicato e per la durata stabilita. Essa non costituisce un’autorizzazione generale a utilizzare lo stesso modello di approvvigionamento IAM per altre applicazioni, unità organizzative o progetti successivi.

L’approvvigionamento IAM uniforme del panorama applicativo dell’Amministrazione federale costituisce la base per una digitalizzazione efficace dei processi. In tale contesto, occorre assolutamente evitare o consolidare un accumulo di piccole applicazioni con approvvigionamento IAM proprietario.