Infrastruttura di sicurezza: autorizzazione - Procedure di mitigazione

Prodotto o servizio	Articolo
Limite di Trust del computer	Verificare che gli ACL appropriati siano configurati per limitare l'accesso non autorizzato ai dati nel dispositivo Verificare che il contenuto sensibile dell'applicazione specifico dell'utente venga archiviato nella directory del profilo utente Verificare che le applicazioni distribuite vengano eseguite con privilegi minimi
Applicazione Web	Applicare l'ordine dei passaggi in sequenza durante l'elaborazione di flussi di logica di business Implementare un meccanismo di limitazione della frequenza per impedire l'enumerazione Verificare che sia presente l'autorizzazione necessaria e che venga seguito il principio dei privilegi minimi Le decisioni riguardanti la logica di business e l'autorizzazione di accesso alle risorse non devono basarsi sui parametri di richiesta in ingresso Verificare che il contenuto e le risorse non siano enumerabili o accessibili tramite browsing forzato
Database	Assicurarsi che vengano usati account con privilegi minimi per connettersi al server di database Implementare la Sicurezza a livello di riga per impedire ai tenant di accedere ai dati degli altri tenant Il ruolo sysadmin deve avere solo utenti necessari validi
Gateway IoT cloud	Connettersi al gateway nel cloud usando token con privilegi minimi
Hub eventi di Azure	Usare una chiave di firma di accesso condiviso per autorizzazioni di solo invio per la generazione di token di dispositivo Non usare token di accesso che consentono l'accesso diretto all'hub eventi Connettersi all'hub eventi tramite chiavi di firma di accesso condiviso aventi solo le autorizzazioni minime necessarie
Azure Document DB	Usare i token delle risorse per la connessione ad Azure Cosmos DB, quando possibile
Limite di trust di Azure	Abilitare la gestione degli accessi con granularità fine alla sottoscrizione di Azure usando il controllo degli accessi in base al ruolo di Azure
Limite di trust di Service Fabric	Limitare l'accesso del client alle operazioni del cluster usando il controllo degli accessi in base al ruolo di Azure
Dynamics CRM	Eseguire la modellazione di sicurezza e usare la sicurezza a livello di campo quando richiesto
Portale di Dynamics CRM	Eseguire la modellazione di sicurezza degli account del portale tenendo presente che il modello di sicurezza per il portale è diverso dagli altri componenti di CRM
Archiviazione di Azure	Concedere l'autorizzazione con granularità fine in un intervallo di entità nell'archiviazione tabelle di Azure Abilitare il controllo degli accessi in base al ruolo di Azure nell'account di archiviazione di Azure con Azure Resource Manager
Client per dispositivi mobili	Implementare il rilevamento implicito di jailbreak o rooting
WCF	Riferimento debole alla classe in WCF WCF: implementare il controllo di autorizzazione
Web API	Implementare il meccanismo di autorizzazione appropriato nell'API Web ASP.NET
Dispositivo IoT	Eseguire i controlli di autorizzazione nel dispositivo se il dispositivo supporta azioni che richiedono diversi livelli di autorizzazione
Gateway IoT sul campo	Eseguire i controlli di autorizzazione nel gateway sul campo se il gateway supporta azioni che richiedono diversi livelli di autorizzazione

Verificare che gli ACL appropriati siano configurati per limitare l'accesso non autorizzato ai dati nel dispositivo

Titolo	Dettagli
Componente	Limite di Trust del computer
Fase SDL	Distribuzione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Passaggi	Verificare che gli ACL appropriati siano configurati per limitare l'accesso non autorizzato ai dati nel dispositivo

Verificare che il contenuto sensibile dell'applicazione specifico dell'utente venga archiviato nella directory del profilo utente

Titolo	Dettagli
Componente	Limite di Trust del computer
Fase SDL	Distribuzione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Passaggi	Verificare che il contenuto sensibile dell'applicazione specifico dell'utente venga archiviato nella directory del profilo utente. Si impedisce così che un utente del computer possa accedere ai dati degli altri utenti.

Verificare che le applicazioni distribuite vengano eseguite con privilegi minimi

Titolo	Dettagli
Componente	Limite di Trust del computer
Fase SDL	Distribuzione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Passaggi	Verificare che l'applicazione distribuita venga eseguita con privilegi minimi.

Applicare l'ordine dei passaggi in sequenza durante l'elaborazione di flussi di logica di business

Titolo	Dettagli
Componente	Applicazione Web
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Passaggi	Per verificare che questa fase sia stata eseguita da un utente reale si vuole far sì che l'applicazione elabori i flussi della logica di business solo nell'ordine dei passaggi in sequenza, con tutti i passaggi elaborati in tempi umanamente realistici e senza elaborazioni in un ordine diverso, passaggi omessi, passaggi elaborati da un altro utente o transazioni inviate troppo rapidamente.

Implementare un meccanismo di limitazione della frequenza per impedire l'enumerazione

Titolo	Dettagli
Componente	Applicazione Web
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Passaggi	Assicurarsi che gli identificatori sensibili siano casuali. Implementare il controllo CAPTCHA nelle pagine anonime. Verificare che errori ed eccezioni non rivelino dati specifici

Verificare che sia presente l'autorizzazione necessaria e che venga seguito il principio dei privilegi minimi

Titolo	Dettagli
Componente	Applicazione Web
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Passaggi	Con questo principio, all'account utente vengono assegnati solo i privilegi essenziali per il lavoro. Un utente del backup non deve ad esempio installare software, di conseguenza sarà autorizzato solo a eseguire backup e applicazioni correlate al backup. Gli altri privilegi, ad esempio l'installazione di nuovo software, saranno bloccati. Il principio è applicabile anche a un utente di PC che in genere svolge il lavoro in un normale account utente e apre un account con privilegi protetto da password (ovvero un utente con privilegi avanzati) solo quando la situazione lo rende assolutamente necessario. Questo principio è applicabile anche alle applicazioni Web. Invece di dipendere esclusivamente da metodi di autenticazione basati sul ruolo che usano le sessioni, si preferisce assegnare privilegi agli utenti tramite un sistema di autenticazione basato su database. Si continuano a usare le sessioni per determinare se l'utente ha effettuato l'accesso correttamente, solo che ora invece di assegnare all'utente un ruolo specifico gli vengono assegnati privilegi per verificare le azioni che è autorizzato a eseguire nel sistema. Un grande vantaggio di questo metodo risiede nel fatto che quando a un utente devono essere assegnati meno privilegi, le modifiche verranno applicate immediatamente perché l'assegnazione non dipende dalla sessione che altrimenti dovrebbe prima scadere.

Le decisioni riguardanti la logica di business e l'autorizzazione di accesso alle risorse non devono basarsi sui parametri di richiesta in ingresso

Titolo	Dettagli
Componente	Applicazione Web
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Passaggi	Quando si verifica se un utente è limitato alla visualizzazione di dati specifici, le limitazioni di accesso devono essere elaborate sul lato server. L'ID utente deve essere archiviato all'interno di una variabile di sessione all'accesso e deve essere usato per recuperare i dati utente dal database

Esempio

SELECT data 
FROM personaldata 
WHERE userID=:id < - session var 

Ora un possibile utente malintenzionato non può manomettere e modificare l'operazione dell'applicazione perché l'identificatore per il recupero dei dati viene gestito sul lato server.

Verificare che il contenuto e le risorse non siano enumerabili o accessibili tramite browsing forzato

Titolo	Dettagli
Componente	Applicazione Web
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Passaggi	I file statici e di configurazione sensibili non devono essere conservati nella directory web-root. Per il contenuto che non deve essere pubblico, applicare i controlli di accesso appropriati oppure rimuovere il contenuto stesso. Il browsing forzato si associa di solito a tecniche di forza bruta per raccogliere informazioni tentando di accedere al maggior numero di URL possibile per enumerare directory e file in un server. Gli utenti malintenzionati possono cercare tutte le varianti dei file comunemente esistenti. La ricerca di file di password include ad esempio file come psswd.txt, password.htm, password.dat e altre varianti. Per attenuare questo problema è necessario includere funzionalità di rilevamento di tentativi di attacchi di forza bruta.

Assicurarsi che vengano usati account con privilegi minimi per connettersi al server di database

Titolo	Dettagli
Componente	Database
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	Gerarchia delle autorizzazioni SQL, entità a protezione diretta SQL
Passaggi	È necessario usare account con privilegi minimi per connettersi al database. L'account di accesso dell'applicazione deve essere limitato nel database ed eseguire solo stored procedure specifiche. L'account di accesso dell'applicazione non deve avere accesso diretto alle tabelle.

Implementare la Sicurezza a livello di riga per impedire ai tenant di accedere ai dati degli altri tenant

Titolo	Dettagli
Componente	Database
Fase SDL	Build
Tecnologie applicabili	SQL Azure, locale
Attributi	Versione SQL: 12, versione SQL: MSSQL2016
Riferimenti	Sicurezza a livello di riga di SQL Server
Passaggi	La sicurezza a livello di riga consente ai clienti di controllare l'accesso alle righe in una tabella di database in base alle caratteristiche dell'utente che esegue una query, ad esempio l'appartenenza a un gruppo o il contesto di esecuzione. La sicurezza a livello di riga semplifica la progettazione e la codifica della sicurezza nell'applicazione Consente di implementare limitazioni per l'accesso alle righe di dati, assicurando ad esempio che i collaboratori possano accedere solo alle righe di dati pertinenti per il proprio reparto o limitando l'accesso ai dati di un cliente ai soli dati di interesse per l'azienda. La logica di restrizione dell'accesso si trova sul livello del database e non su un altro livello applicazione lontano dai dati. Il sistema del database applica le restrizioni di accesso a ogni tentativo di accesso ai dati da qualsiasi livello. Il sistema di sicurezza è così più affidabile e solido, grazie alla riduzione della superficie del sistema di sicurezza.

Si noti che la sicurezza a livello di riga come funzionalità predefinita del database è applicabile solo a SQL Server a partire dal 2016, database SQL di Azure e Istanza gestita di SQL. Se non viene implementata la funzionalità predefinita della sicurezza a livello di riga, assicurarsi l'accesso ai dati sia limitato tramite viste e procedure

Il ruolo sysadmin deve avere solo utenti necessari validi

Titolo	Dettagli
Componente	Database
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	Gerarchia delle autorizzazioni SQL, entità a protezione diretta SQL
Passaggi	I membri del ruolo predefinito SysAdmin del server devono essere molto limitati e non contenere mai account usati dalle applicazioni. Esaminare l'elenco di utenti nel ruolo e rimuovere gli account non necessari

Connettersi al gateway nel cloud usando token con privilegi minimi

Titolo	Dettagli
Componente	Gateway IoT cloud
Fase SDL	Distribuzione
Tecnologie applicabili	Generica
Attributi	Opzione gateway: Hub IoT di Azure
Riferimenti	Controllo di accesso dell'hub IoT
Passaggi	Assegnare autorizzazioni con privilegi minimi a vari componenti che si connettono al gateway cloud (hub IoT). Esempio tipico: il componente di gestione/provisioning di dispositivi usa registryread/write, l'elaboratore eventi (ASA) usa Connessione servizio. I singoli dispositivi si connettono usando le credenziali dispositivo

Usare una chiave di firma di accesso condiviso per autorizzazioni di solo invio per la generazione di token di dispositivo

Titolo	Dettagli
Componente	Hub eventi di Azure
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	Panoramica del modello di sicurezza e autenticazione di Hub eventi
Passaggi	Viene usata una chiave di firma di accesso condiviso per generare i singoli token di dispositivo. Usare una chiave di firma di accesso condiviso per autorizzazioni di solo invio per la generazione di token di dispositivo per un determinato server di pubblicazione

Non usare token di accesso che consentono l'accesso diretto all'hub eventi

Titolo	Dettagli
Componente	Hub eventi di Azure
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	Panoramica del modello di sicurezza e autenticazione di Hub eventi
Passaggi	Non assegnare al dispositivo un token che concede l'accesso diretto all'hub eventi. L'uso di un token con privilegi minimi per il dispositivo che concede l'accesso solo a un server di pubblicazione può aiutare a identificare e non consentire l'uso di un dispositivo non autorizzato o compromesso.

Connettersi all'hub eventi tramite chiavi di firma di accesso condiviso aventi solo le autorizzazioni minime necessarie

Titolo	Dettagli
Componente	Hub eventi di Azure
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	Panoramica del modello di sicurezza e autenticazione di Hub eventi
Passaggi	Assegnare autorizzazioni con privilegi minimi a varie applicazioni back-end che si connettono all'hub eventi. Generare chiavi di firma di accesso condiviso separate per ogni applicazione back-end e assegnare solo le autorizzazioni necessarie, ovvero invio, ricezione o gestione.

Usare i token delle risorse per la connessione ad Azure Cosmos DB, quando possibile

Titolo	Dettagli
Componente	Azure DocumentDB
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Passaggi	Un token di risorsa è associato a una risorsa autorizzazione di Azure Cosmos DB e acquisisce la relazione tra l'utente di un database e l'autorizzazione dell'utente per una risorsa applicazione di Azure Cosmos DB specifica (ad esempio, raccolta o documento). Usare sempre un token di risorsa per accedere ad Azure Cosmos DB se il client non è attendibile per quanto riguarda la gestione delle chiavi master o di sola lettura, ad esempio un'applicazione per l'utente finale come un client desktop o mobile. Usare la chiave master o le chiavi di sola lettura di applicazioni back-end in grado di archiviare queste chiavi in modo sicuro.

Abilitare la gestione degli accessi con granularità fine alla sottoscrizione di Azure usando il controllo degli accessi in base al ruolo di Azure

Titolo	Dettagli
Componente	Limite di trust di Azure
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	Assegnare ruoli di Azure per gestire l'accesso alle risorse della sottoscrizione di Azure
Passaggi	Il Controllo degli accessi in base al ruolo di Azure consente la gestione specifica degli accessi per Azure. Usando il controllo degli accessi in base al ruolo di Azure, è possibile concedere solo la quantità di accesso necessaria agli utenti per eseguire il proprio lavoro.

Limitare l'accesso del client alle operazioni del cluster usando il controllo degli accessi in base al ruolo di Service Fabric

Titolo	Dettagli
Componente	Limite di trust di Service Fabric
Fase SDL	Distribuzione
Tecnologie applicabili	Generica
Attributi	Ambiente: Azure
Riferimenti	Controllo degli accessi in base al ruolo di Service Fabric per i client di Service Fabric
Passaggi	Azure Service Fabric supporta due tipi di controllo di accesso diversi per i client che sono connessi a un cluster di Service Fabric: amministratore e utente. Il Controllo di accesso consente all'amministratore del cluster di limitare l'accesso a determinate operazioni del cluster per diversi gruppi di utenti, rendendo più sicuro il cluster. Gli amministratori hanno accesso completo alle funzionalità di gestione, incluse funzionalità di lettura/scrittura. Gli utenti, per impostazione predefinita, hanno solo l'accesso in lettura alle funzionalità di gestione, ad esempio funzionalità di query, e la possibilità di risolvere applicazioni e servizi. I due ruoli di client, amministratore o client, vengono specificati al momento della creazione del cluster fornendo certificati separati per ognuno di essi.

Eseguire la modellazione di sicurezza e usare la sicurezza a livello di campo quando richiesto

Titolo	Dettagli
Componente	Dynamics CRM
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Passaggi	Eseguire la modellazione di sicurezza e usare la sicurezza a livello di campo quando richiesto

Eseguire la modellazione di sicurezza degli account del portale tenendo presente che il modello di sicurezza per il portale è diverso dagli altri componenti di CRM

Titolo	Dettagli
Componente	Portale di Dynamics CRM
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Passaggi	Eseguire la modellazione di sicurezza degli account del portale tenendo presente che il modello di sicurezza per il portale è diverso dagli altri componenti di CRM

Concedere l'autorizzazione con granularità fine in un intervallo di entità nell'archiviazione tabelle di Azure

Titolo	Dettagli
Componente	Archiviazione di Azure
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	Tipo di archiviazione: tabella
Riferimenti	Come delegare l'accesso agli oggetti nell'account di archiviazione di Azure con la firma di accesso condiviso
Passaggi	In alcuni scenari di business, l'archiviazione tabelle di Azure potrebbe essere necessaria per archiviare dati sensibili per diverse parti, Ad esempio, dati sensibili relativi a paesi/aree geografiche diverse. In questi casi, le firme di firma di accesso condiviso possono essere costruite specificando gli intervalli di chiavi di partizione e riga, in modo che un utente possa accedere ai dati specifici di un determinato paese o area geografica.

Abilitare il controllo degli accessi in base al ruolo di Azure nell'account di archiviazione di Azure con Azure Resource Manager

Titolo	Dettagli
Componente	Archiviazione di Azure
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	Come proteggere l'account di archiviazione con il controllo degli accessi in base al ruolo di Azure
Passaggi	Quando si crea un nuovo account di archiviazione, si seleziona un modello di distribuzione classica o di Azure Resource Manager. Il modello di distribuzione classica per la creazione di risorse in Azure consente solo l'accesso di tipo "tutto o niente" alla sottoscrizione e, di conseguenza, all'account di archiviazione. Con il modello di Azure Resource Manager si inserisce l'account di archiviazione in un gruppo di risorse e si controlla l'accesso al piano di gestione di tale account di archiviazione specifico usando Microsoft Entra ID. Ad esempio, è possibile concedere a utenti specifici la possibilità di accedere alle chiavi dell'account di archiviazione, mentre altri utenti possono visualizzare le informazioni sull'account di archiviazione, ma non accedere alle relative chiavi.

Implementare il rilevamento implicito di jailbreak o rooting

Titolo	Dettagli
Componente	Client per dispositivi mobili
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Passaggi	L'applicazione deve proteggere i propri dati di configurazione e dell'utente in caso di jailbreak o rooting del telefono. Il rooting/jailbreak implica un accesso non autorizzato che gli utenti normali non eseguono sui propri telefoni. L'applicazione deve quindi avere una logica di rilevamento implicito all'avvio, per rilevare se è stato eseguito il rooting del telefono. La logica di rilevamento può prevedere semplicemente l'accesso a file cui normalmente solo gli utenti ROOT possono accedere, ad esempio: /system/app/Superuser.apk /sbin/su /system/bin/su /system/xbin/su /data/local/xbin/su /data/local/bin/su /system/sd/xbin/su /system/bin/failsafe/su /data/local/su Se può accedere a questi file, l'applicazione è in esecuzione come utente ROOT.

Riferimento debole alla classe in WCF

Titolo	Dettagli
Componente	WCF
Fase SDL	Build
Tecnologie applicabili	Generico, NET Framework 3
Attributi	N/D
Riferimenti	MSDN, Fortify Kingdom
Passaggi	Il sistema usa un riferimento debole alla classe che potrebbe consentire a un utente malintenzionato di eseguire codice non autorizzato. Il programma fa riferimento a una classe definita dall'utente che non è identificata in modo univoco. Quando .NET carica questa classe con identificazione debole, il caricatore di tipo CLR cerca la classe nei percorsi seguenti nell'ordine specificato: Se l'assembly del tipo è noto, il caricatore esegue una ricerca nei percorsi di reindirizzamento del file di configurazione, in GAC, nell'assembly corrente usando le informazioni di configurazione e nella directory base dell'applicazione Se l'assembly è sconosciuto, il caricatore esegue una ricerca nell'assembly corrente, in mscorlib e nel percorso restituito dal gestore eventi TypeResolve Questo ordine di ricerca CLR può essere modificato con hook quali il meccanismo di inoltro dei tipi e l'evento AppDomain.TypeResolve Se un utente malintenzionato sfrutta l'ordine di ricerca CLR creando una classe alternativa con lo stesso nome e inserendola in un percorso alternativo che CLR caricherà per primo, il CLR eseguirà involontariamente il codice specificato dall'utente malintenzionato

Esempio

L'elemento <behaviorExtensions/> del file di configurazione WCF seguente indica a WCF di aggiungere una classe di comportamento personalizzata a una particolare estensione WCF.

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name=""myBehavior"" type=""MyBehavior"" />
        </behaviorExtensions>
    </extensions>
</system.serviceModel>

L'uso di nomi completi (sicuri) identifica un tipo in modo univoco e aumenta la sicurezza del sistema. Usare nomi di assembly completi durante la registrazione di tipi nei file machine.config e app.config.

Esempio

L'elemento <behaviorExtensions/> del file di configurazione WCF seguente indica a WCF di aggiungere una classe di comportamento personalizzata con riferimento sicuro a una particolare estensione WCF.

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name=""myBehavior"" type=""Microsoft.ServiceModel.Samples.MyBehaviorSection, MyBehavior,
            Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"" />
        </behaviorExtensions>
    </extensions>
</system.serviceModel>

WCF: implementare il controllo di autorizzazione

Titolo	Dettagli
Componente	WCF
Fase SDL	Build
Tecnologie applicabili	Generico, NET Framework 3
Attributi	N/D
Riferimenti	MSDN, Fortify Kingdom
Passaggi	Questo servizio non usa un controllo di autorizzazione. Quando un client chiama un servizio WCF specifico, WCF mette a disposizione vari schemi di autorizzazione per verificare che il chiamante sia autorizzato a eseguire il metodo del servizio nel server. Se i controlli di autorizzazione non sono abilitati per i servizi WCF, un utente autenticato può ottenere l'escalation dei privilegi.

Esempio

La configurazione seguente indica a WCF di non verificare il livello di autorizzazione del client quando si esegue il servizio:

<behaviors>
    <serviceBehaviors>
        <behavior>
            ...
            <serviceAuthorization principalPermissionMode=""None"" />
        </behavior>
    </serviceBehaviors>
</behaviors>

Usare uno schema di autorizzazione del servizio per verificare che il chiamante del metodo del servizio sia autorizzato a eseguire l'operazione. WCF offre due modalità e consente la definizione di uno schema di autorizzazione personalizzato. La modalità UseWindowsGroups usa i ruoli e gli utenti di Windows, mentre la modalità UseAspNetRoles usa un provider di ruoli ASP.NET, ad esempio SQL Server, per l'autenticazione.

Esempio

La configurazione seguente indica a WCF di verificare che il client faccia parte del gruppo di amministratori prima di eseguire il servizio di aggiunta:

<behaviors>
    <serviceBehaviors>
        <behavior>
            ...
            <serviceAuthorization principalPermissionMode=""UseWindowsGroups"" />
        </behavior>
    </serviceBehaviors>
</behaviors>

Il servizio viene quindi dichiarato come indicato di seguito:

[PrincipalPermission(SecurityAction.Demand,
Role = ""Builtin\\Administrators"")]
public double Add(double n1, double n2)
{
double result = n1 + n2;
return result;
}

Implementare il meccanismo di autorizzazione appropriato nell'API Web ASP.NET

Titolo	Dettagli
Componente	API Web
Fase SDL	Build
Tecnologie applicabili	Generico, MVC 5
Attributi	N/A, Provider di identità - ADFS, Provider di identità - MICROSOFT Entra ID
Riferimenti	Autenticazione e autorizzazione nell'API Web ASP.NET
Passaggi	Le informazioni sul ruolo per gli utenti dell'applicazione possono essere derivate da attestazioni MICROSOFT Entra ID o ADFS se l'applicazione si basa su di essi come provider di identità o l'applicazione stessa potrebbe fornire. In questi casi, l'implementazione di autorizzazione personalizzata deve convalidare le informazioni sui ruoli utente. Le informazioni sul ruolo per gli utenti dell'applicazione possono essere derivate da attestazioni MICROSOFT Entra ID o ADFS se l'applicazione si basa su di essi come provider di identità o l'applicazione stessa potrebbe fornire. In questi casi, l'implementazione di autorizzazione personalizzata deve convalidare le informazioni sui ruoli utente.

Esempio

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple = true)]
public class ApiAuthorizeAttribute : System.Web.Http.AuthorizeAttribute
{
        public async override Task OnAuthorizationAsync(HttpActionContext actionContext, CancellationToken cancellationToken)
        {
            if (actionContext == null)
            {
                throw new Exception();
            }

            if (!string.IsNullOrEmpty(base.Roles))
            {
                bool isAuthorized = ValidateRoles(actionContext);
                if (!isAuthorized)
                {
                    HandleUnauthorizedRequest(actionContext);
                }
            }

            base.OnAuthorization(actionContext);
        }

public bool ValidateRoles(actionContext)
{
   //Authorization logic here; returns true or false
}

}

Tutti i controller e i metodi di azione da proteggere devono essere decorati con l'attributo indicato in precedenza.

[ApiAuthorize]
public class CustomController : ApiController
{
     //Application code goes here
}

Eseguire i controlli di autorizzazione nel dispositivo se il dispositivo supporta azioni che richiedono diversi livelli di autorizzazione

Titolo	Dettagli
Componente	Dispositivo IoT
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Passaggi	Il dispositivo deve autorizzare il chiamante per verificare se il chiamante è in possesso delle autorizzazioni necessarie per eseguire l'azione richiesta. Si supponga ad esempio che il dispositivo sia una serratura intelligente che può essere monitorata dal cloud e che offra funzionalità quali la chiusura remota della porta. La serratura intelligente consente l'apertura solo quando qualcuno si avvicina fisicamente alla porta con una scheda. In questo caso, l'implementazione del comando e del controllo remoto deve essere eseguita in modo da non fornire funzionalità di apertura della porta perché il gateway nel cloud non è autorizzato a inviare un comando per l'apertura della porta.

Eseguire i controlli di autorizzazione nel gateway sul campo se il gateway supporta azioni che richiedono diversi livelli di autorizzazione

Titolo	Dettagli
Componente	Gateway IoT sul campo
Fase SDL	Build
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Passaggi	Il gateway sul campo deve autorizzare il chiamante per verificare se il chiamante è in possesso delle autorizzazioni necessarie per eseguire l'azione richiesta. Devono essere ad esempio disponibili autorizzazioni diverse per un'interfaccia/API di utente amministratore usata per configurare un gateway sul campo rispetto ai dispositivi che si connettono al gateway.