Configurazioni di identità e accesso dei dispositiviIdentity and device access configurations

IntroduzioneIntroduction

Sebbene non esista un'unica indicazione ottimale per tutti gli ambienti dei clienti, le procedure consigliate nel documento descrivono le indicazioni generali di Microsoft su come applicare le impostazioni di configurazione e i criteri nel cloud Microsoft per garantire la sicurezza e la produttività dei dipendenti.While there is no single best recommendation for all customer environments, the best practices and recommendations in this document describe general Microsoft recommendations about how to apply policy and configuration within the Microsoft cloud to ensure that your employees are both secure and productive.

Destinatari I consigli illustrati qui sono concepiti per architetti dell'infrastruttura aziendale e professionisti dell'IT che hanno familiarità con Office 365 e Microsoft Enterprise Mobility + Security che include Azure Active Directory (identità), Microsoft Intune (gestione dei dispositivi) e Azure Information Protection (protezione dei dati).Intended audience These recommendations are intended for enterprise infrastructure architects and IT Pros familiar with Office 365 and Microsoft Enterprise Mobility + Security which includes, among others, Azure Active Directory (identity), Microsoft Intune (device management), and Azure Information Protection (data protection).

Ambiente del cliente I criteri consigliati sono applicabili a organizzazioni aziendali che operano interamente nell'ambito del cloud Microsoft e per clienti con un'infrastruttura distribuita in locale e nel cloud Microsoft.Customer environment The recommended policies are applicable to enterprise organizations operating both entirely within the Microsoft cloud and for customers with infrastructure deployed across on-premises and the Microsoft cloud.

Presupposti Molti dei consigli offerti si basano su servizi disponibili solo con sottoscrizioni di Enterprise Mobility + Security (EMS) E5 sottoscrizioni. I consigli illustrati presuppongono funzionalità complete della sottoscrizione a EMS E5.Assumptions Many of the provided recommendations rely on services available only with Enterprise Mobility + Security (EMS) E5 subscriptions. Recommendations presented assume full EMS E5 subscription capabilities.

Avvertenze importanti È possibile che l'organizzazione sia soggetta a requisiti normativi o altri requisiti di conformità, incluse indicazioni specifiche per le quali potrebbe essere necessario applicare criteri diversi dalle configurazioni consigliate in questo articolo. Tali configurazioni consigliano controlli dell'utilizzo non disponibili in precedenza. Tali controlli sono consigliabili perché rappresentano una soluzione equilibrata tra sicurezza e produttività.Caveats Your organization may be subject to regulatory or other compliance requirements, including specific recommendations that may require you to apply policies that diverge from these recommended configurations. These configurations recommend usage controls that have not historically been available. We recommend these controls, because we believe they represent a balance between security and productivity.

Nonostante il massimo impegno profuso per tenere in considerazione una vasta gamma di requisiti di protezione aziendale, non è possibile prendere in considerazione tutti i requisiti possibili o tutti gli aspetti unici di ogni organizzazione. Usare i consigli offerti nel documento come guida sul modo considerato corretto da Microsoft e dal team aziendale della produttività e della sicurezza di applicare i criteri.While we’ve done our best to account for a wide variety of organizational protection requirements, we’re not able to account for all possible requirements or for all the unique aspects of your organization. Use these recommendations as a guide for how Microsoft and the secure productive enterprise team is thinking about how to correctly apply policy.

Nota

Per una panoramica dei concetti principali necessari per comprendere le funzionalità di protezione descritte in queste indicazioni, vedere Panoramica di Microsoft 365 Enterprise.For an overview of the core concepts necessary to understand the protection capabilities described in these recommendations, see the Microsoft 365 Enterprise documentation home page.

Concetti baseCore concepts

Tutte le misure di sicurezza del mondo non bastano se gli utenti ignorano i criteri di sicurezza aziendali perché costituiscono un inutile ostacolo all'esecuzione del lavoro. Single Sign-On (SSO) di Azure AD cerca di ridurre al minimo la pressione sugli utenti. Questo consente agli utenti di rimanere produttivi pur conformandosi ai criteri di controllo di accesso dell'organizzazione.All the security measures in the world do not matter when users, who experience unnecessary friction when trying to get their work done, bypass your organizational security policies. Azure AD single-sign on (SSO) attempts to minimize the burden on users. This way users can remain productive while still conforming to the access control policies of the organization.

Autenticazione Single Sign-OnSingle sign-on authentication

Il diagramma seguente illustra un flusso di autenticazione SSO tipico:The following diagram illustrates a typical SSO authentication flow:

Autenticazione Single Sign-On utente finale

Per avviare l'autenticazione, il client invia le credenziali, ad esempio nome utente e password, e/o gli elementi SSO ottenuti in precedenza, a Azure AD. Un elemento SSO può essere un token di sessione per un browser o un token di aggiornamento per applicazioni complesse.To begin authentication, the client submits credentials (such as username and password) and/or any SSO artifacts obtained in the past to Azure AD. An SSO artifact can be a session token for a browser or a refresh token for rich applications.

Dopo che le credenziali e/o l'elemento SSO sono stati verificati in Azure AD e che sono stati valutati tutti i criteri applicabili, viene generato un token di accesso per il provider di risorse, Office 365 nel diagramma qui sopra. Azure AD rilascia anche un elemento SSO come parte della risposta per consentire ai client di ottenere l'autenticazione SSO nelle richieste successive. Il client archivia l'elemento SSO e invia il token di accesso come identificazione per il provider di risorse. Dopo che Office 365 ha verificato il token di accesso e ha eseguito i controlli necessari, concede l'accesso client ai documenti.After the credentials and/or SSO artifact have been verified in Azure AD, and all applicable policies have been evaluated, an access token for the resource provider (Office 365 in the above diagram) is issued. Azure AD also issues an SSO artifact as part of the response to allow clients to achieve SSO in subsequent requests. The client stores the SSO artifact and submits the access token as a proof of identity to the resource provider. After Office 365 verifies the access token and performs necessary checks, it will grant the client access to the documents.

Token di aggiornamento Single Sign-On (SSO)Single sign-on (SSO) refresh tokens

È possibile ottenere l'autenticazione SSO in diversi modi. Ad esempio, è possibile usare i cookie provenienti da un provider di identità come l'elemento SSO per archiviare lo stato di accesso per un utente all'interno di un browser. In questo modo saranno possibili tentativi futuri di accesso automatico alle applicazioni, ovvero senza alcuna richiesta di credenziali, tramite lo stesso provider di identità.SSO can be achieved in various ways. For example, cookies from an identity provider can be used as the SSO artifact to store the sign-in state for a user within a browser. Future attempts to sign in silently (without any prompts for credentials) to applications using the same identity provider are then possible.

Quando un utente esegue l'autenticazione con Azure AD, viene stabilita una sessione SSO con Azure AD e il browser dell'utente. Il token SSO, sotto forma di cookie, rappresenta la sessione. Azure AD usa due tipi di token di sessione SSO: permanente e non permanente. I token di sessione permanenti vengono archiviati come cookie permanenti dai browser quando durante l'accesso è stata selezionata la casella di controllo Mantieni l'accesso. I token di sessione non permanenti vengono archiviati come cookie di sessione e vengono eliminati quando il browser viene chiuso.When a user authenticates with Azure AD, an SSO session is established with the user’s browser and Azure AD. The SSO token, in the form of a cookie, represents this session. Azure AD uses two kinds of SSO session tokens: persistent and non-persistent. Persistent session tokens are stored as persistent cookies by browsers when the Keep me signed in checkbox is selected during sign in. Non-persistent session tokens are stored as session cookies, and are destroyed when the browser is closed.

Per applicazioni affidabili che possono usare protocolli di autenticazione moderna, ad esempio OpenId Connect e OAuth 2.0, l'autenticazione SSO viene abilitata con i token di aggiornamento come elementi SSO, oltre ai cookie SSO descritti in precedenza. I token di aggiornamento vengono presentati a un server di autorizzazione quando un'applicazione richiede un nuovo token di accesso. Il token di aggiornamento contiene le attestazioni e gli attributi sul tipo di metodi di autenticazione usata per autenticare gli utenti. Ad esempio, se un utente ha eseguito l'autenticazione usando diversi metodi, nome utente e password e autenticazione via telefono, nel token di aggiornamento è presente un'attestazione di autenticazione a più fattori (MFA, Multi-Factor Authentication). Potrebbero esserci anche attestazioni aggiuntive che contengono dati, ad esempio la durata della validità dell'autenticazione a più fattori.For robust applications capable of using modern authentication protocols, such as OpenId Connect and OAuth 2.0, SSO is enabled using refresh tokens as the SSO artifacts (in addition to earlier described SSO cookies). Refresh tokens are presented to an authorization server when an application requests a new access token. The refresh token contains claims and attributes about the kind of authentication methods used when authenticating users. For example, if a user has successfully authenticated using multiple methods (username & password and phone-based authentication), then a multi-factor authentication (MFA) claim is present in the refresh token. Also, there may be additional claims that contain data such as MFA validity duration.

I token di aggiornamento consentono al client di ottenere un nuovo token di accesso, senza la necessità di eseguire un'altra autenticazione interattiva. I token di aggiornamento hanno una durata molto più lunga rispetto ai token di accesso e possono essere riscattati per ottenere una nuova coppia di token di accesso e di aggiornamento. In seguito, i token di aggiornamento appena ottenuti possono essere usati per recuperare un altro set di token di accesso e di aggiornamento. Il client continuerà il processo SSO fino a quando non scadrà l'impostazione del tempo di inattività massimo del token di aggiornamento, non verrà raggiunta l'età massima del token di aggiornamento, o non verranno modificati i requisiti dei criteri di autenticazione e autorizzazione. Tale modifica si verifica quando viene generato il token di aggiornamento originale. Modifiche degli attributi utente significative, ad esempio la reimpostazione della password, richiedono anche la generazione di un nuovo token di autenticazione. Per continuare, è necessario che il client esegua una nuova autenticazione interattiva. Ciò significa essenzialmente un'interruzione del processo di SSO che il client non ha riscontrato fino ad ora.Refresh tokens allow the client to obtain a new access token, without needing to do another interactive authentication. Refresh tokens have a much longer lifetime than access tokens and can be redeemed to obtain a new access and refresh token pair. The newly obtained refresh tokens can then be continually used to fetch another set of access and refresh tokens. The client continues this SSO process until either the refresh token maximum inactive time setting expires, the refresh token max age expires, or the authentication and authorization policy requirements change. This change occurs during the time when the original refresh token was issued. Significant user attribute changes, for example a password reset, also require a new authentication token to be generated. The client must do a fresh interactive authentication to continue further. Essentially it signifies a break in the SSO process that the client has not experienced until now.

Accesso condizionaleConditional access

Azure AD agisce come un servizio di autorizzazione per le applicazioni determinando se rilasciare token di accesso in base alla valutazione di tutti i criteri di accesso condizionale applicati alla risorsa cui si sta tentando di accedere. Se vengono soddisfatti i requisiti dei criteri, vengono rilasciati un token di accesso e un token di aggiornamento aggiornato. Se il criterio non viene soddisfatto, l'utente riceve istruzioni su come soddisfare i criteri e/o deve completare passaggi aggiuntivi tra cui l'autenticazione a più fattori (MFA). Una volta completata l'autenticazione a più fattori, l'attestazione di autenticazione a più fattori viene aggiunta al token di aggiornamento risultante.Azure AD, acting as an authorization service for your applications, determines whether to issue access tokens based on an evaluation of any conditional access policies applied to the resource that you’re trying to access. If policy requirements are met, then an access token and updated refresh token are issued. If the policy is not met, the user receives instructions on how to meet the policy and/or is required to complete additional steps including multi-factor authentication (MFA). Once MFA has been completed, the MFA claim is added to the resulting refresh token.

Le attestazioni nel token di aggiornamento vengono accumulate nel tempo. Alcune delle attestazioni hanno sequenze temporali di scadenza, dopo le quali non sono più considerate durante i controlli di autorizzazione. In alcuni casi ciò può causare risultati imprevisti. Ad esempio, se i criteri di accesso condizionale sono configurati in modo che sia necessaria l'autenticazione a più fattori per i tentativi di autenticazione provenienti da percorsi Extranet. In questo caso, è possibile che gli utenti non ricevano la richiesta di autenticazione a più fattori prevista quando accedono a una risorsa dalla Extranet. Un possibile motivo è che l'utente potrebbe aver precedentemente eseguito l'autenticazione a più fattori poco prima di lasciare la Intranet. Pertanto, ha un'attestazione di autenticazione a più fattori valida nel relativo token di accesso. La richiesta di autenticazione a più fattori soddisfa i requisiti dei criteri e pertanto Azure AD non richiede all'utente un'altra autenticazione a più fattori.Claims in the refresh token get accumulated over time. Some of the claims have expiration timelines, after which they are no longer considered during authorization checks. This can sometimes cause unexpected results. For example, if a conditional access policy is configured so that MFA is required for authentication attempts coming from extranet locations. In this case, users might sometimes not receive the expected MFA prompt when accessing a resource from extranet. A possible reason for this is that the user could have previously performed MFA shortly before leaving the intranet. Therefore, they have a valid MFA claim in their access token. This MFA claim satisfies the policy requirement and thus Azure AD does not prompt the user with an additional MFA request.

Durata dei tokenToken lifetime policy

Oltre la scadenza delle attestazioni singole in un token, i token stessi hanno una scadenza. Come illustrato in precedenza, i token scaduti sono uno dei motivi per cui il servizio SSO può essere interrotto. È possibile impostare la durata di un token emesso da Azure AD tramite i criteri di durata del token. Come si può dedurre da quanto illustrato finora, non è facile definire i contorni di una sessione SSO. Ad esempio, quando le app complesse costituite da vari fattori apparentemente disconnessi influiscono sulla durata di una sessione SSO.Beyond the expiration of individual claims in a token, tokens themselves have expiration times. As noted before, expired tokens are one reason why the SSO experience can be broken. You can set the lifetime of a token issued by Azure AD by using token lifetime policies. As can be inferred from above, defining the contours of an SSO session is harder to capture. For example, when rich apps as various factors that are seemingly disconnected can impact the lifetime of an SSO session.

Nota

Gli amministratori globali di Azure AD possono controllare i periodi di inattività e di validità dei token di aggiornamento. Per informazioni sui token di accesso e le attestazioni vedere l'articolo Durata dei token configurabili in Azure Active Directory.Azure AD Global Administrators can control the validity and inactivity periods of refresh tokens. Information about access token and claims using the settings described in the article Configurable token lifetimes in Azure Active Directory.

Token di aggiornamento primariPrimary refresh tokens

Finora è stato illustrato il funzionamento di SSO nel contesto di un client singolo, ma questo non è sufficiente per descrivere l'esperienza di SSO in una sola app. Oggi gli utenti usano flussi di lavoro interattivi su più applicazioni all'interno della stessa suite di applicazioni, come ad esempio Microsoft Office. Agli utenti serve anche l'accesso ad applicazioni non correlate, tra cui le applicazioni LOB sviluppate internamente.So far, this article has discussed how SSO works within the context of a single client, but this is not enough to experience SSO within a single app. These days, users experience interactive workflows spanning multiple applications within the same suite of applications, such as Microsoft Office. Users also need access across unrelated applications, including internally developed line of business (LOB) applications.

In genere, i dispositivi Windows aggiunti a un dominio, tramite l'autenticazione integrata di Windows (Kerberos), ottengono un livello del servizio SSO elevato in diverse applicazioni e risorse. Queste applicazioni includono i browser supportati, come ad esempio Internet Explorer o Edge. Esiste qualcosa di analogo per Azure AD, sotto forma di un token di aggiornamento principale. Tale token con privilegi è disponibile solo per un insieme di entità client selezionato, ad esempio per componenti di sistema della piattaforma. Le entità possono quindi consentire l'accesso di autenticazione negoziata ad altre applicazioni client, in modo che possano offrire anch'esse un'esperienza SSO facile. Per gli utenti di Office 365 di dispositivi iOS e Android, è stato possibile ridurre il numero di autenticazioni richieste applicando la funzionalità di broker di autenticazione. La funzionalità è incorporata nelle app Microsoft Authenticator e Portale aziendale Intune.Traditionally, domain joined Windows devices, using Windows Integrated Authentication (Kerberos), achieve a high degree of SSO experience across multiple applications and resources. These apps include supported browsers such as Internet Explorer or Edge. There is an analog for the Azure AD realm, in the form of a primary refresh token (PRT). This privileged token is only available to a select set of client entities (such as platform system components). The entities can then allow brokered authentication access to other client applications, so that they can also offer a seamless SSO experience. For Office 365 users on iOS and Android devices, additional work has been done to reduce the number of required authentications by applying authentication broker functionality. This functionality is built into the Microsoft Authenticator and Intune Company Portal apps.

Nota

I consigli illustrati in questo documento presuppongono che una di queste app, Microsoft Authenticator o Portale aziendale Intune, sia stata distribuita agli utenti dei dispositivi IOS o Android.The recommendations described in this document assume that one of these apps (Microsoft Authenticator or Intune Company Portal) has been deployed to your users' iOS or Android devices.

Multi-Factor AuthenticationMulti-factor authentication

L'autenticazione a più fattori (MFA, Multi-Factor Authentication) garantisce un livello di attendibilità elevato sull'oggetto dell'autenticazione, poiché l'oggetto offre più prove o evidenze sulla propria identità. Le prove possono essere segreti prestabiliti conosciuti solo dall'oggetto e dall'autorità oppure un'entità fisica che solo l'oggetto possiede. L'autenticazione a più fattori in genere viene eseguita in diverse fasi. Per prima cosa stabilisce l'identità usando le password e quindi richiede un metodo di autenticazione diverso, meno soggetto ad attacchi dannosi, come secondo fattore, o viceversa.Multi-factor Authentication (MFA) provides a high level of trust about the subject of authentication, because the subject provides multiple proofs or pieces of evidence about its identity. The proofs can be pre-established secrets that only the subject and the authority are aware of or a physical entity that only the subject is expected to possess. MFA is typically performed in stages. First it establishes the identity using passwords, and then it requires a different (less prone to malicious attacks) authentication method as the second factor, or vice versa.

Diverse autorità possono avere un'interpretazione dell'autenticazione a più fattori leggermente diversa oppure possono usare l'autenticazione avanzata. Ad esempio, alcune autorità, o più precisamente gli amministratori dei criteri di configurazione, possono scegliere di interpretare l'autenticazione basata su smart card fisica come MFA. Questa situazione può verificarsi anche se in senso stretto l'autenticazione tramite smart card è un'autenticazione a fase singola.Different authorities may have a slightly different interpretation of MFA, or strong authentication. For example, some authorities (or more specifically the admins configuring policy on those authorities) may choose to interpret the physical smartcard-based authentication as MFA. This can happen even though strictly speaking smartcard authentication is a single stage authentication.

La combinazione di smart card e PIN, il segreto, obbligatori per poter usare la smart card può essere interpretata come MFA. Tuttavia, le organizzazioni potrebbero scegliere di essere più flessibili sulla frequenza con cui vengono richiesti metodi di autenticazione più gravosi. In questi casi le autenticazioni normali, che si verificano tra le autenticazioni più avanzate, possono essere considerate valide per risorse che in genere richiedono l'autenticazione avanzata. Ad esempio, in alcune organizzazioni può essere accettabile richiedere all'utente di eseguire l'autenticazione a più fattori dopo un certo numero di ore o di giorni. Il tempo dipende dalla riservatezza delle risorse protette e dal fatto che la posizione fisica dell'utente che tenta di accedere a una risorsa non cambia.The combination of requiring a physical smartcard and the requirement to enter a PIN (secret) to use smartcard can be interpreted as MFA. However, organizations might choose to be more lenient in terms of how often more onerous authentication methods are required to be performed. In these cases, normal authentications, that take place between stronger authentications,can be considered to be valid for resources that typically require strong authentication. For example, in some organizations it may be acceptable to require a user to do MFA every few hours or days. The time depends on the sensitivity of resources they are protecting and as long as the physical location of the user attempting to access a resource, does not change.

Azure Active Directory e AD FS usano l'attestazione MFA per indicare se l'autenticazione viene eseguita con l'autenticazione a più fattori. Per impostazione predefinita, Azure AD rilascia token con attestazione MFA quando l'autenticazione viene eseguita con Azure MFA o Windows Hello for Business. Negli scenari federativi Azure AD esegue l'attestazione MFA dai provider di identità federative, come ad esempio AD FS, e riporta l'attestazione MFA nei token.Azure AD and AD FS use the MFA claim to indicate whether the authentication is performed with MFA. By default, Azure AD issues tokens with MFA claim when authentication is done with Azure MFA or Windows Hello for Business. In federation scenarios, Azure AD honors the MFA claim from federated identity providers such as AD FS and carries over the MFA claim in the tokens.

In questa sezione vengono descritte le configurazioni client della piattaforma predefinite consigliate per offrire un'esperienza SSO ottimale agli utenti, oltre ai prerequisiti tecnici per l'accesso condizionale.This section describes the default platform client configurations we recommend to provide the best SSO experience to your users, as well as the technical pre-requisites for conditional access.

Dispositivi WindowsWindows devices

È consigliabile usare Windows 10, versione 1703 o successive, poiché Azure è progettato per offrire un'esperienza di uso ottimale di SSO sia in locale che in Azure AD. I dispositivi aziendali o dell'istituto di istruzione devono essere configurati per unirsi ad Azure AD direttamente o, se l'organizzazione usa l'aggiunta a un dominio AD in locale, devono essere configurati per la registrazione automatica e invisibile con Azure AD.We recommend the Windows 10 (version 1703 or later), as Azure is designed to provide the smoothest SSO experience possible for both on-premises and Azure AD. Work or school issued devices should be configured to join Azure AD directly or if the organization uses on-premises AD domain join, those devices should be configured to automatically and silently register with Azure AD.

Per i dispositivi Windows BYOD, gli utenti possono usare "Aggiungi account aziendale o dell'istituto di istruzione". Si noti che gli utenti del browser Chrome in Windows 10 devono installare un'estensione per poter ottenere la stessa esperienza di accesso ottimale degli utenti di Edge o Internet Explorer. Se l'organizzazione ha dispositivi Windows 7 aggiunti a un dominio, è possibile installare il pacchetto Microsoft Workplace Join per i computer non Windows 10 per registrare i dispositivi con Azure AD.For BYOD Windows devices, users can use "Add work or school account". Note that Chrome browser users on Windows 10 need to install an extension so those users can get the same smooth sign-in experience as Edge/IE. Also, if your organization has domain joined Windows 7 devices, you can install Microsoft Workplace Join for non-Windows 10 computers package to register the devices with Azure AD.

Dispositivi iOSiOS devices

È consigliabile installare l'app Microsoft Authenticator sui dispositivi degli utenti prima di distribuire i criteri MFA o dell'accesso condizionale. Come minimo, l'app deve essere installata nel momento in cui agli utenti viene richiesto di registrare i dispositivi in Azure AD tramite l'aggiunta di un account aziendale o dell'istituto di istruzione o quando installano l'app Portale aziendale Intune per registrare i dispositivi per la gestione. Ciò dipende dai criteri di accesso condizionale configurati.We recommend installing the Microsoft Authenticator app on user devices before deploying conditional access or MFA policies. At a minimum, the app should be installed when users are asked to register their device with Azure AD by adding a work or school account or when they install the Intune company portal app to enroll their device into management. This depends on the configured conditional access policy.

Dispositivi AndroidAndroid devices

È consigliabile che gli utenti installino l'app Portale aziendale Intune e l'app Microsoft Authenticator prima che vengano distribuiti i criteri di accesso condizionale o quando richiesto durante determinati tentativi di autenticazione. Dopo l'installazione delle app, è possibile che venga richiesto agli utenti di registrarsi con Azure AD o di registrare il dispositivo con Intune. Ciò dipende dai criteri di accesso condizionale configurati.We recommend users install the Intune Company Portal app and Microsoft Authenticator app before conditional access policies are deployed or when required during certain authentication attempts. After app installation, users may be asked to register with Azure AD or enroll their device with Intune. This depends on the configured conditional access policy.

È consigliabile anche che i dispositivi di proprietà dell'azienda vengano normalizzati in OEM e che le versioni che supportano Android for Work o Samsung Knox consentano che gli account di posta elettronica siano gestiti e protetti dai criteri MDM Intune.We also recommend that corporate-owned devices (COD) are standardized on OEMs and versions that support Android for Work or Samsung Knox to allow mail accounts to be managed and protected by Intune MDM policy.

Linee guida per la sicurezzaSecurity guidelines

In questa sezione vengono illustrate le linee guida per la sicurezza generali da seguire quando si implementa uno dei consigli descritti nelle sezioni successive.This section contains general security guidelines that should be followed when implementing any of the recommendations provided in later sections.

Compromesso tra sicurezza e produttivitàSecurity and productivity trade-offs

È necessario arrivare a un compromesso tra sicurezza e produttività. Per illustrare questo concetto, si usa spesso il triangolo Sicurezza-Funzionalità-Usabilità/Facilità di utilizzo:There is a trade-off to be made between security and productivity. To help understand these trade-offs, the Security-Functionality-Usability/Ease of Use (SFU) security triad is widely used:

Compromesso tra sicurezza e produttività

I suggerimenti sono sono forniti si basano sui seguenti principi triad SFU protezione:The recommendations are have provided are based on the following SFU security triad principles:

  • Conoscere il gruppo di destinatari: flessibilità in base a mansione lavorativa/barra della sicurezzaKnow the audience - Be flexible by job function/security bar
  • Applicare i criteri di sicurezza Just-In-Time e assicurarsi che siano efficaciApply security policy just in time and ensure it is meaningful

Amministratori e utentiAdministrators versus users

È consigliabile creare gruppi di sicurezza che contengano tutti gli utenti che hanno account amministrativi o idonei per ricevere temporaneamente privilegi di account amministrativo. Tali gruppi di sicurezza devono quindi essere usati per definire criteri di accesso condizionale specifici per gli amministratori di Azure AD e di Office 365.We recommend creating security groups that contain all the users who have administrative accounts or are eligible to receive an administrative account privileges on a temporary basis. These security groups should then be used to define conditional access policies specific to Azure AD and Office 365 administrators.

I consigli relativi ai criteri specificati tengono in considerazione i privilegi associati agli account. I ruoli di amministratore di Office 365 hanno molti più privilegi per i servizi di Office 365. Pertanto, i suggerimenti sui criteri per tali account sono più rigorosi rispetto a quelli per gli account utente normali. Tutti i criteri che fanno riferimento agli amministratori indicano i criteri consigliati per gli account di amministratore di Office 365.The provided policy recommendations consider the privileges associated with an account. Office 365 administrator roles have substantially more privileges to Office 365 services. Thus, our policy recommendations for these accounts are more stringent than for regular user accounts. All the policies that refer to Administrators indicate the recommended policy for Office 365 administrative accounts.

Ridurre il numero di account con accesso amministratore permanenteReduce the number of accounts with persistent admin access

Usare Azure AD Privileged Identity Management per ridurre il numero di account amministrativi permanenti. È consigliabile anche che gli amministratori di Office 365 abbiano un account utente separato, senza privilegi di amministratore, per l'uso normale, e usino l'account di amministratore solo quando è necessario per completare un'attività associata alla loro mansione lavorativa.Use Azure AD Privileged Identity Management to reduce the number of persistent administrative accounts. In addition, we recommend that Office 365 administrators have a separate user account for regular non-administrative use and only use their administrative account when necessary to complete a task associated with their job function.

Nota

Per ulteriori informazioni sulla protezione di account con privilegi di Azure Active Directory, fare riferimento a questo articolo nella Guida di orientamento per implementarla e le procedure consigliate.For more information on securing privileged accounts in Azure AD, refer to this article on best practices and a roadmap to implement it.

Livelli di sicurezza e protezioneTiers of security and protection

La maggior parte delle organizzazioni hanno requisiti specifici relativi a sicurezza e protezione dei dati. Tali requisiti variano in base al settore e alle mansioni lavorative all'interno delle organizzazioni. Ad esempio, l'ufficio legale e gli amministratori di Office 365 potrebbero richiedere maggiore sicurezza e controlli di protezione sulle informazioni della corrispondenza tramite posta elettronica che non sono richiesti per gli utenti di altre business unit.Most organizations have specific requirements regarding security and data protection. These requirements vary by industry segment and by job functions within organizations. For example, your legal department and Office 365 administrators might require additional security and information protection controls around their email correspondence that are not required for other business unit users.

Ogni settore ha anche il proprio set di normative specializzate. Anziché specificare un elenco di tutte le opzioni di sicurezza o un'indicazione per ogni settore o mansione lavorativa, sono stati specificati consigli per tre diversi livelli di sicurezza e protezione dati che possono essere applicati in base alle proprie esigenze di granularità: protezione di base, protezione avanzata e protezione per ambienti altamente regolamentati.Each industry also has their own set of specialized regulations. Rather than providing a list of all possible security options or a recommendation per industry segment or job function, recommendations have been provided for three different tiers of security and protection that can be applied based on the granularity of your needs: baseline, sensitive, and highly regulated.

Protezione di base. È consigliabile stabilire uno standard minimo per la protezione dei dati, nonché le identità e i dispositivi che accedono ai dati. I consigli basilari possono essere seguiti per garantire una solida protezione predefinita che soddisfi le esigenze di molte organizzazioni.Baseline. We recommend that you establish a minimum standard for protecting data, as well as the identities and devices that access your data. Baseline recommendations can be followed to provide strong default protection that meets the needs of many organizations.

Protezione avanzata. Alcuni clienti hanno un subset di dati che devono essere protetti a livelli superiori o richiedono che tutti i dati siano protetti a livelli superiori. È possibile applicare una protezione maggiore per tutti i set di dati o solo per alcuni di essi nell'ambiente Office 365. È consigliabile proteggere le identità e i dispositivi che accedono ai dati sensibili con livelli di sicurezza analoghi.Sensitive. Some customers have a subset of data that must be protected at higher levels or require all data to be protected at these higher levels. You can apply increased protection to all or specific data sets in your Office 365 environment. We recommend protecting identities and devices that access sensitive data with comparable levels of security.

Protezione per ambienti altamente regolamentati. Alcune organizzazioni potrebbero avere una piccola quantità di dati altamente classificati, segreti commerciali o dati soggetti a regolamentazione. Microsoft offre funzionalità che consentono alle organizzazioni di soddisfare questi requisiti, inclusa la protezione aggiuntiva per identità e dispositivi.Highly regulated. Some organizations may have a very small amount of data that is highly classified, trade secret, or regulated data. Microsoft provides capabilities to help organizations meet these requirements, including added protection for identities and devices.

Consigli per i meccanismi di protezione predefinitiDefault protection mechanism recommendations

Nella tabella seguente sono elencati i consigli sui meccanismi di protezione predefiniti per ognuno dei livelli di protezione e sicurezza definiti in precedenza:The following table contains default protection mechanism recommendations for each of the previously defined security and protection tiers:

Meccanismo di protezioneProtection mechanism Versione di baseBaseline Dati sensibiliSensitive Protezione per ambienti altamente regolamentatiHighly regulated
Applicare l'autenticazione a più fattoriEnforce MFA A partire da rischio di accesso medioOn medium or above sign-in risk A partire da rischio di accesso bassoOn low or above sign-in risk Per tutte le nuove sessioniOn all new sessions
Applicare modifica passwordEnforce Password Change Per gli utenti ad alto rischioFor high risk users Per gli utenti ad alto rischioFor high risk users Per gli utenti ad alto rischioFor high risk users
Applicare la protezione delle applicazioni di IntuneEnforce Intune Application Protection Yes Yes Yes
Applicare la registrazione di IntuneEnforce Intune Enrollment (COD) Richiede un dispositivo conforme o aggiunto a un dominioRequire a compliant or domain joined device Richiedi un dispositivo conforme o aggiunto a un dominioRequire a compliant or domain joined device Richiedi un dispositivo conforme o aggiunto a un dominioRequire a compliant or domain joined device

Proprietà del dispositivoDevice ownership

La tabella sopra riportata riflette la tendenza di molte organizzazioni a supportare una combinazione di dispositivi aziendali e dispositivi personali o BYOD per abilitare la produttività mobile tra i dipendenti. I criteri di Protezione app di Intune garantiscono che la posta elettronica sia protetta da divulgazioni non consentite al di fuori dell'app Outlook Mobile e di altre app di Office Mobile, sia aziendali che BYOD.The above table reflects the trend for many organizations to support a mix of corporate-owned devices (COD) as well as personal or bring-your-own devices (BYOD) to enable mobile productivity across their workforces. Intune App Protection Policies ensure that email is protected from exfiltrating out of the Outlook mobile app and other Office mobile apps, on both COD and BYOD.

I dispositivi di proprietà dell'azienda devono essere gestiti da Intune o aggiunti a un dominio per applicare altri tipi di protezione e controllo. A seconda della riservatezza dei dati, l'organizzazione potrebbe scegliere di non consentire l'uso di dispositivi BYOD per app o utenti specifici.Corporate-owned devices are required to be managed by Intune or domain-joined to apply additional protections and control. Depending on data sensitivity, your organization may choose to not allow BYOD for specific user populations or specific apps.

Passaggi successiviNext steps

Deploy common identity and device access policies (Distribuire criteri comuni di identità e accesso ai dispositivi)Deploy common identity and device access policies