Pianificare una distribuzione di Microsoft Entra application proxy

2025-05-01

Application Proxy di Microsoft Entra è una soluzione di accesso remoto sicura e conveniente per le applicazioni locali. Fornisce un percorso di transizione immediato per le organizzazioni "Cloud First" per gestire l'accesso alle applicazioni locali legacy che non sono ancora in grado di usare protocolli moderni. Per altre informazioni introduttive, vedere Che cos'è il proxy dell'applicazione.

Il proxy dell'applicazione è consigliato per concedere agli utenti remoti l'accesso alle risorse interne. Il proxy di applicazione sostituisce la necessità di una VPN o un proxy inverso per questi casi d'uso di accesso remoto. Non è destinato agli utenti che si trovano nella rete aziendale. Questi utenti che usano il proxy dell'applicazione per l'accesso Intranet potrebbero riscontrare problemi di prestazioni indesiderati.

Questo articolo include le risorse necessarie per pianificare, gestire e gestire il proxy dell'applicazione Microsoft Entra.

Pianificare l'implementazione

La sezione seguente offre una panoramica generale degli elementi di pianificazione chiave che consentono di configurare un'esperienza di distribuzione efficiente.

Prerequisiti

È necessario soddisfare i prerequisiti seguenti prima di iniziare l'implementazione. Nell'esercitazione sono disponibili altre informazioni sulla configurazione dell'ambiente, inclusi questi prerequisiti.

Connettori: i connettori sono agenti leggeri che è possibile distribuire in:
- Hardware fisico in sede
- Una macchina virtuale ospitata all'interno di qualsiasi soluzione hypervisor
- Una macchina virtuale ospitata in Azure per abilitare la connessione in uscita al servizio proxy dell'applicazione.
Per una panoramica più dettagliata, vedere Informazioni sui connettori di rete privata di Microsoft Entra.
- I computer connettore devono essere abilitati per Transport Layer Security (TLS) 1.2 prima di installare i connettori.
- Se possibile, installare i connettori nella stessa rete e segmento degli server delle applicazioni Web back-end. È consigliabile distribuire i connettori dopo aver completato un'individuazione delle applicazioni.
- È consigliabile che ogni gruppo di connettori disponga di almeno due connettori per offrire disponibilità elevata e scalabilità. Avere tre connettori è ottimale per la manutenzione di un computer in qualsiasi momento. Esaminare la tabella della capacità del connettore per decidere il tipo di computer per il connettore.
Impostazioni di accesso alla rete: i connettori di rete privati Di Microsoft Entra si connettono ad Azure tramite HTTPS (TCP) Porta 443 e HTTP (porta TCP 80).
- Il traffico TLS del connettore di terminazione non è supportato e impedisce ai connettori di stabilire un canale sicuro con i rispettivi endpoint proxy dell'applicazione Microsoft Entra.
- Evitare tutte le forme di ispezione inline sulle comunicazioni TLS in uscita tra connettori e Azure. L'ispezione interna tra un connettore e le applicazioni back-end è possibile, ma potrebbe compromettere l'esperienza utente e, di conseguenza, non è consigliabile.
- Il bilanciamento del carico dei connettori stessi non è supportato e non è necessario.

Considerazioni importanti prima di configurare Application Proxy di Microsoft Entra

Per configurare e implementare Application Proxy di Microsoft Entra, è necessario soddisfare i requisiti di base seguenti.

Onboarding di Azure: prima di distribuire il proxy dell'applicazione, le identità utente devono essere sincronizzate da una directory locale on-premises o create direttamente nel tuo tenant di Microsoft Entra. La sincronizzazione delle identità consente a Microsoft Entra ID di preautenticare gli utenti prima di concedere loro l'accesso alle applicazioni pubblicate dal proxy di applicazione e di avere le informazioni necessarie sull'identificatore utente per eseguire l'accesso Single Sign-On (SSO).
Requisiti di accesso condizionale: non è consigliabile usare il proxy dell'applicazione per l'accesso Intranet perché aggiunge una latenza che influisce sugli utenti. È consigliabile usare il proxy dell'applicazione con criteri di preautenticazione e accesso condizionale per l'accesso remoto da Internet. Un approccio per fornire l'accesso condizionale per l'uso Intranet consiste nel modernizzare le applicazioni in modo che possano eseguire direttamente l'autenticazione con Microsoft Entra ID. Per altre informazioni, vedere Risorse per la migrazione di applicazioni a Microsoft Entra ID.
Limiti del servizio: per evitare un consumo eccessivo di risorse da parte di singoli tenant, sono previsti limiti di limitazione impostati per applicazione e tenant. Per visualizzare questi limiti, vedere Limiti e restrizioni del servizio Microsoft Entra. Questi limiti di limitazione si basano su un benchmark oltre il volume di utilizzo tipico e forniscono un ampio buffer per la maggior parte delle distribuzioni.
Certificato pubblico: se si usano nomi di dominio personalizzati, è necessario procurarsi un certificato TLS. A seconda dei requisiti dell'organizzazione, il recupero di un certificato può richiedere tempo ed è consigliabile iniziare il processo il prima possibile. Il proxy di applicazione di Azure supporta certificati standard, caratteri jolly o basati su SAN. Per altre informazioni, vedere Configurare domini personalizzati con il proxy dell'applicazione Microsoft Entra.
Requisiti di dominio: per usare la delega vincolata Kerberos (KCD) per l'accesso Single Sign-On (SSO), assicurarsi che il server connettore e il server delle applicazioni siano parte del dominio e nello stesso dominio o in domini attendibili. Il servizio connettore viene eseguito con l'account di sistema locale e non deve usare un'identità personalizzata. Per ulteriori informazioni, vedere KCD per l'accesso Single Sign-On.
Record DNS per gli URL
- Prima di usare domini personalizzati nel proxy dell'applicazione, è necessario creare un record CNAME nel DNS (Domain Name System) pubblico, consentendo ai client di risolvere l'URL esterno personalizzato definito nell'indirizzo proxy predefinito dell'applicazione. Se non si crea un record CNAME per un'applicazione che usa un dominio personalizzato, gli utenti remoti non si connettono all'applicazione. I passaggi necessari per aggiungere record CNAME possono variare da provider DNS a provider, quindi scopri come gestire record DNS e set di record usando l'interfaccia di amministrazione di Microsoft Entra.
- Analogamente, gli host del connettore devono essere in grado di risolvere l'URL interno delle applicazioni pubblicate.
Diritti e ruoli amministrativi
- L'installazione del connettore richiede diritti di amministratore locale per il server Windows in cui è installato. Richiede anche un ruolo minimo di amministratore dell'applicazione per autenticare e registrare l'istanza del connettore nel tenant di Microsoft Entra.
- La pubblicazione e l'amministrazione dell'applicazione richiedono il ruolo Amministratore applicazione. Gli amministratori di applicazioni possono gestire tutte le applicazioni nella directory, incluse le registrazioni, le impostazioni SSO, le assegnazioni di utenti e gruppi e le licenze, le impostazioni proxy dell'applicazione e il consenso. Non consente tuttavia di gestire l'accesso condizionale. Il ruolo Amministratore applicazione cloud ha tutte le capacità dell'amministratore dell'applicazione, ad eccezione del fatto che non consente la gestione delle impostazioni proxy dell'applicazione.
Licenze: il proxy dell'applicazione è disponibile tramite un abbonamento a Microsoft Entra ID P1 o P2. Per un elenco completo delle opzioni e delle funzionalità delle licenze, vedere la pagina dei prezzi di Microsoft Entra.

Iindividuazione di applicazioni

Creare un inventario di tutte le applicazioni nell'ambito pubblicate tramite Application Proxy raccogliendo le informazioni seguenti:

Tipo di informazioni	Informazioni da raccogliere
Tipo di servizio	Ad esempio: SharePoint, SAP, CRM, applicazione Web personalizzata, API
Piattaforma applicativa	Ad esempio: Windows Internet Information Services (IIS), Apache in Linux, Tomcat, NGINX
Appartenenza al dominio	Nome di dominio completo (FQDN) del server Web
Posizione dell'applicazione	Dove si trova il server Web o la farm nell'infrastruttura
Accesso interno	URL esatto usato internamente per accedere all'applicazione. Se si tratta di una farm, quale tipo di bilanciamento del carico è in uso? Indicare se l'applicazione prende contenuto da origini diverse da sé stessa. Determinare se l'applicazione opera su WebSocket.
Accesso esterno	La soluzione del fornitore attraverso la quale l'applicazione potrebbe già essere esposta esternamente. URL da usare per l'accesso esterno. Se SharePoint, verificare che i mapping di accesso alternativo siano configurati in base alle indicazioni. In caso contrario, è necessario definire URL esterni.
Certificato pubblico	Se si usa un dominio personalizzato, procurarsi un certificato con un nome soggetto corrispondente. Se esiste un certificato, prendere nota del numero di serie e della posizione da cui può essere ottenuto.
Tipo di autenticazione	Il tipo di autenticazione supportato dall'applicazione, ad esempio Basic, Autenticazione di integrazione di Windows, basata su moduli, basata su intestazione o su attestazioni. Se l'applicazione è configurata per l'esecuzione con un account di dominio specifico, prendere nota del nome di dominio completo (FQDN) dell'account del servizio. Se basata su SAML, l'identificatore e gli URL di risposta. Se l'autenticazione è basata su intestazione, la soluzione del fornitore e il requisito specifico per la gestione del tipo di autenticazione devono essere presi in considerazione.
Nome del gruppo di connettori	Nome logico per il gruppo di connettori designati per fornire il canale e l'accesso SSO all'applicazione back-end.
Accesso a utenti/gruppi	Utenti o gruppi di utenti a cui viene concesso l'accesso esterno all'applicazione.
Altri requisiti	Si notino altri requisiti di accesso remoto o di sicurezza che devono essere inseriti nella pubblicazione dell'applicazione.

È possibile scaricare il foglio di calcolo dell'inventario delle applicazioni per l'inventario delle app.

Definire i requisiti dell'organizzazione

Di seguito sono riportate le aree per le quali è necessario definire i requisiti aziendali dell'organizzazione. Ogni area contiene esempi di requisiti

Accesso

Gli utenti remoti con dispositivi aggiunti a un dominio o aggiunti a Microsoft Entra possono accedere in modo sicuro alle applicazioni pubblicate con l'accesso Single Sign-On (SSO) facile.
Gli utenti remoti con dispositivi personali approvati possono accedere in modo sicuro alle applicazioni pubblicate, purché vengano registrate in MFA e registrate l'app Microsoft Authenticator sul proprio telefono cellulare come metodo di autenticazione.

Governance

Gli amministratori possono definire e monitorare il ciclo di vita delle assegnazioni utente alle applicazioni pubblicate tramite Application Proxy.

Sicurezza

Solo gli utenti assegnati alle applicazioni per appartenenza a gruppi o come individuo possono accedere a tali applicazioni.

Prestazioni

Non esiste alcuna riduzione delle prestazioni dell'applicazione rispetto all'accesso all'applicazione dalla rete interna.

Esperienza utente

Gli utenti sono consapevoli di come accedere alle applicazioni usando URL aziendali conosciuti in qualsiasi piattaforma del dispositivo.

Revisione contabile

Gli amministratori sono in grado di controllare l'attività di accesso degli utenti.

Procedure consigliate per un progetto pilota

Determinare la quantità di tempo e il lavoro necessari per eseguire completamente il commissioning di una singola applicazione per l'accesso remoto con Single Sign-On (SSO). A tale scopo, eseguire un progetto pilota che consideri la sua iniziale individuazione, pubblicazione e il test generale. L'uso di una semplice applicazione Web basata su IIS già preconfigurata per l'autenticazione integrata di Windows (IWA) consente di stabilire una baseline, perché la configurazione richiede un impegno minimo per pilotare correttamente l'accesso remoto e l'accesso SSO.

Gli elementi di progettazione seguenti dovrebbero aumentare il successo dell'implementazione del progetto pilota direttamente in un tenant di produzione.

Gestione dei connettori:

I connettori svolgono un ruolo chiave nella fornitura del canale locale alle applicazioni. L'uso del gruppo di connettori predefinito è adeguato per il test pilota iniziale delle applicazioni pubblicate prima di commissionarle nell'ambiente di produzione. Le applicazioni testate correttamente possono quindi essere spostate nei gruppi di connettori di produzione.

Gestione delle applicazioni:

È molto probabile che la forza lavoro ricordi un URL esterno conosciuto e pertinente. Evitare di pubblicare l'applicazione usando i suffissi predefiniti msappproxy.net o onmicrosoft.com. Fornire invece un dominio di primo livello familiare verificato, preceduto da un nome host logico, ad esempio Intranet.<>customers_domain.com.

Limitare la visibilità dell'icona dell'applicazione pilota a un gruppo pilota, nascondendo la sua icona di avvio dal portale MyApps di Azure. Quando si è pronti per la produzione, è possibile limitare l'ambito dell'app ai rispettivi destinatari, nello stesso ambiente di preproduzione o pubblicando l'app nel tenant di produzione.

Impostazioni di Single Sign-On: Alcune impostazioni SSO hanno dipendenze specifiche che possono richiedere tempo per la configurazione, quindi è meglio evitare ritardi nel controllo delle modifiche assicurandosi che le dipendenze vengano risolte in anticipo. Il processo include gli host del connettore uniti al dominio per eseguire il Single Sign-On (SSO) utilizzando la delega vincolata Kerberos (KCD) e occuparsi di altre attività che richiedono molto tempo.

TLS tra l'host del connettore e applicazione di destinazione: La sicurezza è fondamentale, quindi è consigliabile usare TLS tra l'host del connettore e le applicazioni di destinazione. In particolare se l'applicazione Web è configurata per l'autenticazione basata su moduli, poiché le credenziali utente vengono trasmesse in modo efficace in testo non crittografato.

Implementare in modo incrementale e testare ogni passaggio. Eseguire test funzionali di base dopo la pubblicazione di un'applicazione per assicurarsi che tutti i requisiti aziendali e utente siano soddisfatti:

Testare e convalidare l'accesso generale all'applicazione Web con preautenticazione disabilitata. In caso di esito positivo, abilitare la preautenticazione e assegnare utenti e gruppi. Quindi testare e convalidare l'accesso. Aggiungere quindi il metodo SSO per l'applicazione e testare di nuovo per convalidare l'accesso. Applicare infine i criteri di accesso condizionale e MFA in base alle esigenze. Testare e convalidare l'accesso.

Strumenti per la risoluzione dei problemi: avviare la risoluzione dei problemi controllando l'accesso all'applicazione pubblicata direttamente dal browser nell'host del connettore. Verificare che l'applicazione funzioni come previsto. Semplificare la configurazione per isolare i problemi, ad esempio l'uso di un singolo connettore e la disabilitazione dell'accesso SSO. Strumenti come Fiddler di Telerik possono aiutare a eseguire il debug di problemi di accesso o contenuto tracciando il traffico, tra cui per piattaforme mobili come iOS e Android. Per ulteriori informazioni, vedere la guida alla risoluzione dei problemi.

Implementare la soluzione

Distribuire Application Proxy

I passaggi per distribuire il proxy dell'applicazione sono illustrati nell'esercitazione per l'aggiunta di un'applicazione locale per l'accesso remoto. Se l'installazione non riesce, selezionare Risolvere i problemi dell'applicazione proxy nel portale o usare la guida alla risoluzione dei problemi relativi all'installazione del connettore dell'agente proxy dell'applicazione.

Pubblicare le applicazioni con Application Proxy

Le applicazioni di pubblicazione presuppongono che siano stati soddisfatti tutti i prerequisiti e che siano presenti diversi connettori visualizzati come registrati e attivi nella pagina del proxy dell'applicazione.

È anche possibile pubblicare le applicazioni usando PowerShell.

Procedure consigliate da seguire durante la pubblicazione di un'applicazione:

Usare i gruppi di connettori: assegnare un gruppo di connettori designato per la pubblicazione di ogni rispettiva applicazione. È consigliabile che ogni gruppo di connettori disponga di almeno due connettori per offrire disponibilità elevata e scalabilità. Avere tre connettori è ottimale nel caso in cui sia necessario gestire un computer in qualsiasi momento. Vedere anche Informazioni sui gruppi di connettori di rete privata di Microsoft Entra per vedere come usare anche i gruppi di connettori per segmentare i connettori in base alla rete o alla posizione.
Imposta timeout applicazione back-end: l'impostazione è utile negli scenari in cui l'applicazione potrebbe richiedere più di 75 secondi per elaborare una transazione client. Ad esempio, quando un client invia una query a un'applicazione Web che funge da front-end a un database. Il front-end invia la query al server di database back-end e attende una risposta, ma quando riceve una risposta, il lato client della conversazione va in timeout. Configurare l'opzione di timeout su "Long" fornisce 180 secondi per il completamento di transazioni più lunghe.
Usare i tipi di cookie appropriati
- HTTP-Only Cookie: offre maggiore sicurezza perché il proxy dell'applicazione include il flag HTTPOnly nelle intestazioni di risposta HTTP set-cookie. L'impostazione consente di ridurre gli exploit, ad esempio lo scripting tra siti (XSS). Lasciare impostato su No per client/agenti utente che richiedono l'accesso al cookie di sessione. Ad esempio, il client RDP/MTSC si connette a un gateway Desktop remoto pubblicato tramite Application Proxy.
- Cookie sicuro: quando un cookie viene impostato con l'attributo Secure, l'agente utente (app lato client) include solo il cookie nelle richieste HTTP se la richiesta viene trasmessa su un canale protetto TLS. L'impostazione consente di ridurre il rischio di compromissione di un cookie su canali di testo non crittografati, pertanto deve essere abilitata.
- Cookie persistente: consente al cookie di sessione del proxy dell'applicazione di mantenere la persistenza tra le chiusure del browser rimanendo valido fino alla scadenza o all'eliminazione. Usato per gli scenari in cui un'applicazione avanzata, ad esempio office, accede a un documento all'interno di un'applicazione Web pubblicata, senza che l'utente venga reinterato per l'autenticazione. Abilitare con cautela, tuttavia, poiché i cookie persistenti possono in ultima analisi lasciare un servizio a rischio di accesso non autorizzato, se non usato con altri controlli di compensazione. Questa impostazione deve essere usata solo per le applicazioni meno recenti che non possono condividere cookie tra processi. È preferibile aggiornare l'applicazione per gestire la condivisione dei cookie tra processi anziché usare l'impostazione .
Tradurre gli URL nelle intestazioni: è possibile abilitare l'impostazione per gli scenari in cui il DNS interno non può essere configurato in modo che corrisponda allo spazio dei nomi pubblico dell'organizzazione(k.a Split DNS). A meno che l'applicazione non richieda l'intestazione host originale nella richiesta client, lasciare il valore impostato su Sì. L'alternativa consiste nel fare usare al connettore il nome di dominio completo nell'URL interno per il routing del traffico effettivo, e il nome di dominio completo nell'URL esterno come intestazione host. Nella maggior parte dei casi l'alternativa dovrebbe consentire all'applicazione di funzionare normalmente, quando si accede in remoto, ma gli utenti perdono i vantaggi di avere una corrispondenza all'interno e all'esterno dell'URL.
Tradurre URL nel corpo dell'applicazione: Attivare la traduzione dei collegamenti nel corpo dell'applicazione per un'app, quando si desidera che i collegamenti da tale app vengano convertiti in risposte al client. Se abilitata, la funzione fornisce un tentativo ottimale di tradurre tutti i collegamenti interni trovati dal proxy dell'applicazione nelle risposte HTML e CSS restituite ai client. È utile quando si pubblicano app che contengono collegamenti assoluti codificati o collegamenti con nome breve NetBIOS nel contenuto, o app con contenuto che si collega ad altre applicazioni in sede.

Per gli scenari in cui un'app pubblicata si collega ad altre app pubblicate, abilitare la conversione dei collegamenti per ogni applicazione, in modo da avere il controllo sull'esperienza utente a livello di app.

Si supponga, ad esempio, di avere tre applicazioni pubblicate tramite Application Proxy che si collegano tutte tra loro: Vantaggi, Spese e Viaggi, oltre a una quarta app, Feedback, che non è pubblicata attraverso Application Proxy.

Diagramma che mostra la traduzione dei collegamenti. Quando la traduzione dei collegamenti è abilitata per l'app Benefits, i collegamenti alle app Expenses and Travel vengono reindirizzati agli URL esterni, consentendo agli utenti esterni di accedervi. Tuttavia, i collegamenti da Expenses e Travelback a Benefits non funzionano a meno che la traduzione dei collegamenti non sia abilitata anche per tali app. Il collegamento dell'app Feedback non viene reindirizzato perché non dispone di un URL esterno, impedendo agli utenti esterni di accedervi tramite l'app Benefits. Per altre informazioni, vedere Opzioni di conversione e reindirizzamento dei collegamenti.

Accedere all'applicazione

Gestire l'accesso alle risorse pubblicate del proxy di applicazione selezionando l'approccio più adatto allo scenario e ai requisiti di scalabilità. I metodi comuni includono la sincronizzazione dei gruppi locali tramite Microsoft Entra Connect, la creazione di gruppi dinamici in Microsoft Entra ID in base agli attributi utente, l'abilitazione dei gruppi self-service gestiti dai proprietari delle risorse o la combinazione di queste strategie. Esplorare le risorse collegate per comprendere i vantaggi di ogni metodo.

Il modo più semplice per assegnare agli utenti l'accesso a un'applicazione consiste nell'accedere alle opzioni Utenti e gruppi, dal riquadro sinistro dell'applicazione pubblicata, e assegnarlo direttamente a gruppi o utenti.

Figura 24

È anche possibile consentire agli utenti di accedere in modalità self-service all'applicazione assegnando un gruppo di cui non sono attualmente membri e configurando le opzioni self-service.

Immagine 25

Se abilitato, gli utenti accedono al portale MyApps per richiedere l'accesso. Vengono approvati automaticamente e aggiunti al gruppo self-service o richiedono l'approvazione da parte di un approvatore designato.

Gli utenti guest possono anche essere invitati ad accedere alle applicazioni interne pubblicate tramite proxy applicativo di Microsoft Entra B2B.

Per le applicazioni locali normalmente accessibili in modo anonimo, senza autenticazione, potrebbe essere necessario disabilitare l'opzione disponibile nelle proprietà dell'applicazione.

Immagine 26

Se si lascia l'opzione impostata su No, gli utenti possono accedere all'applicazione locale tramite il proxy dell'applicazione Microsoft Entra senza autorizzazioni, quindi usare con cautela.

Dopo la pubblicazione dell'applicazione, l'applicazione deve essere accessibile digitando il relativo URL esterno in un browser o tramite l'icona all'indirizzo https://myapps.microsoft.com.

Abilitare la preautenticazione

Verificare che l'applicazione sia accessibile tramite il proxy dell'applicazione, accedendovi tramite l'URL esterno.

Passare a Entra ID>Enterprise apps>All applications (Tutte le applicazioni ) e scegliere l'app che si vuole gestire.
Selezionare Application Proxy.
Nel campo Pre-autenticazione, usare l'elenco a discesa per selezionare Microsoft Entra ID e selezionare Salva. Con la preautenticazione abilitata, Microsoft Entra ID autentica prima gli utenti. Se l'accesso Single Sign-On è configurato, l'applicazione back-end verifica anche l'utente prima di concedere l'accesso. Il passaggio della modalità di preautenticazione da Passthrough a Microsoft Entra ID protegge l'URL esterno con HTTPS, assicurando che qualsiasi applicazione che usa inizialmente HTTP funzioni ora tramite HTTPS.

Abilita l'accesso singolo

SSO migliora l'esperienza utente e la sicurezza consentendo agli utenti di accedere una sola volta con Microsoft Entra ID. Dopo la preautenticazione, il connettore di rete privata accede all'applicazione locale per l'utente, visualizzandolo come se l'utente ha eseguito l'accesso diretto.

La scelta dell'opzione Passthrough consente agli utenti di accedere all'applicazione pubblicata senza dover eseguire l'autenticazione all'ID Microsoft Entra.

Per abilitare l'accesso SSO, l'applicazione deve preautenticare gli utenti con l'ID Microsoft Entra. Senza preautenticazione, le opzioni SSO non sono disponibili.

Leggere Single Sign-On per le applicazioni in Microsoft Entra ID per scegliere il metodo SSO più appropriato durante la configurazione delle applicazioni.

Lavorare con altri tipi di applicazioni

Microsoft Entra application proxy supporta le applicazioni compilate con Microsoft Authentication Library (MSAL). Gestisce le app client native usando i token ID di Microsoft Entra nelle intestazioni delle richieste dei client per preautenticare gli utenti.

Informazioni sulle configurazioni disponibili del proxy dell'applicazione. Leggere la pubblicazione di app client native e per dispositivi mobili e applicazioni basate su attestazioni.

Rafforzare la sicurezza con l'accesso condizionale

La sicurezza delle applicazioni richiede un set avanzato di funzionalità di sicurezza che possono proteggere e rispondere a minacce complesse in locale e nel cloud. Usare i criteri di accesso condizionale per controllare l'accesso alle applicazioni in base a molte condizioni, ad esempio posizione, rischio, tipo di dispositivo, conformità dei dispositivi e altro ancora. Per esempi di criteri che è possibile distribuire, vedere l'articolo Modelli di accesso condizionale.

Per supportare Application Proxy di Microsoft Entra, è possibile usare le funzionalità seguenti:

Accesso condizionale basato su utente e posizione: mantenere protetti i dati sensibili limitando l'accesso utente in base alla posizione geografica o a un indirizzo IP con criteri di accesso condizionale basati sulla posizione.
Accesso condizionale basato su dispositivo: assicurarsi che solo i dispositivi registrati, approvati e conformi possano accedere ai dati aziendali con accesso condizionale basato su dispositivo.
Accesso condizionale basato su applicazioni: Quando un utente non si trova nella rete aziendale, non è necessario smettere di lavorare. Proteggere l'accesso al cloud aziendale e alle app locali e mantenere il controllo con l'accesso condizionale.
Accesso condizionale basato sul rischio: proteggere i dati da hacker malintenzionati con criteri di accesso condizionale basati sul rischio che possono essere applicati a tutte le app e a tutti gli utenti, sia in locale che nel cloud.
App personali di Microsoft Entra: Con il servizio Application Proxy distribuito e le applicazioni pubblicate in modo sicuro, si offre agli utenti un hub semplice per individuare e accedere a tutte le applicazioni. Aumentare la produttività con funzionalità self-service, ad esempio la possibilità di richiedere l'accesso a nuove app e gruppi o gestire l'accesso a queste risorse per conto di altri utenti, tramite App personali.

Gestire l'implementazione

Ruoli richiesti

Microsoft sostiene il principio per cui è preferibile concedere il minimo privilegio possibile per eseguire le attività necessarie con Microsoft Entra ID. Esaminare i diversi ruoli di Azure disponibili e scegliere quello giusto per soddisfare le esigenze di ogni utente. Alcuni ruoli devono essere applicati temporaneamente e rimossi al termine della distribuzione.

Ruolo aziendale	Attività aziendali	Ruoli di Microsoft Entra
Amministratore dell'help desk	Gestisce attività di supporto utente di base, ad esempio la reimpostazione delle password, l'invalidazione dei token di aggiornamento e il controllo dell'integrità del servizio.	Amministratore supporto tecnico
Amministratore delle identità	Leggere i report di accesso e i log di controllo di Microsoft Entra per eseguire il debug dei problemi correlati a Application Proxy.	Lettore di sicurezza
Proprietario dell'applicazione	Creare e gestire tutti gli aspetti delle applicazioni aziendali, delle registrazioni delle applicazioni e delle impostazioni di Application Proxy.	Amministratore di applicazioni
Amministratore dell'infrastruttura	Proprietario del rinnovo del certificato	Amministratore di applicazioni

Ridurre al minimo il numero di persone che hanno accesso a informazioni o risorse sicure aiutano a ridurre la probabilità che un attore malintenzionato ottenga l'accesso non autorizzato o un utente autorizzato che influisca inavvertitamente su una risorsa sensibile.

Per gestire l'accesso amministrativo in modo efficace e garantire un controllo appropriato, è consigliabile usare l'accesso JIT (Just-In-Time) con Privileged Identity Management. Questo approccio consente l'accesso con privilegi su richiesta alle risorse di Azure e all'ID Entra di Microsoft solo quando necessario.

Monitoraggio e creazione di report

Microsoft Entra ID fornisce maggiori informazioni sull'utilizzo e sull'integrità operativa dell'applicazione dell'organizzazione tramite log di controllo e report. Il proxy dell'applicazione semplifica anche il monitoraggio dei connettori dall'interfaccia di amministrazione di Microsoft Entra e dai registri eventi di Windows.

Log di controllo delle applicazioni

Questi log forniscono informazioni dettagliate sugli accessi alle applicazioni configurate con Application Proxy, oltre al dispositivo e all'utente che accede all'applicazione. I log di controllo si trovano nell'interfaccia di amministrazione di Microsoft Entra e nell'API di controllo per l'esportazione. Inoltre, i report di utilizzo e informazioni dettagliate sono disponibili anche per l'applicazione.

Monitoraggio del connettore di rete privato

I connettori e il servizio si occupano di tutte le attività che richiedono disponibilità elevata. È possibile monitorare lo stato dei connettori dalla pagina Application Proxy nell'interfaccia di amministrazione di Microsoft Entra. Per altre informazioni sulla manutenzione del connettore, vedere Informazioni sui connettori di rete privata di Microsoft Entra.

Registri eventi di Windows e contatori delle prestazioni

I connettori dispongono sia di log di amministrazione che di sessione. I log di amministrazione includono gli eventi principali e i relativi errori. I log di sessione includono tutte le transazioni e i relativi dettagli di elaborazione. I log e i contatori si trovano nei registri eventi di Windows. Per altre informazioni, vedere Informazioni sui connettori di rete privata di Microsoft Entra. Seguire l'esercitazione per configurare le origini dati del log eventi in Monitoraggio di Azure.

Guida alla risoluzione dei problemi e passaggi

Altre informazioni sui problemi comuni e su come risolverli con la guida alla risoluzione dei messaggi di errore.

Gli articoli seguenti illustrano scenari comuni che possono essere usati anche per creare guide alla risoluzione dei problemi per l'organizzazione di supporto.