Pianificare una distribuzione di Microsoft Entra application proxy

Articolo
04/13/2024

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 Informazioni sul 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 di 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 un quadro completo degli elementi chiave di pianificazione da configurare per un'esperienza di distribuzione efficace.

Prerequisiti

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

Connessione ors: i Connessione or sono agenti leggeri che è possibile distribuire in:
- Hardware fisico locale
- 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.
- Connessione or i computer devono essere abilitati per TLS 1.2 prima di installare i connettori.
- Se possibile, distribuire connettori nella stessa rete e segmento dei server 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à. La presenza di tre connettori è ottimale nel caso in cui sia necessario lavorare su uno dei computer. Esaminare la tabella della capacità del connettore per decidere il tipo di computer in cui installare i connettori. Maggiore sarà la dimensione del computer, maggiori saranno il buffer e le prestazioni del connettore.
Impostazioni di accesso alla rete: i connettori di rete privata Microsoft Entra si connettono ad Azure tramite HTTPS (porta TCP 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 o create direttamente all'interno dei tenant di Microsoft Entra. La sincronizzazione delle identità consente a Microsoft Entra ID di pre-autenticare gli utenti prima di concedere loro l'accesso alle applicazioni pubblicate dal proxy dell'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 influirà sugli utenti. È consigliabile usare il proxy dell'applicazione con i 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 dei 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 si basano su un benchmark molto superiore al 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/SSL. 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, con caratteri jolly o basati su SAN. Per altri dettagli, vedere Configurare domini personalizzati con il proxy dell'applicazione Microsoft Entra.
Requisiti di dominio: L'accesso Single Sign-On alle applicazioni pubblicate tramite delega vincolata Kerberos richiede che il server che esegue il connettore e il server che esegue l'app siano aggiunti a un dominio e che facciano parte dello stesso dominio o di domini attendibili. Per informazioni dettagliate sull'argomento, vedere KCD per l'accesso Single Sign-On con il proxy dell'applicazione. Il servizio connettore viene eseguito nel contesto del sistema locale e non deve essere configurato per l'uso di un'identità personalizzata.
Record DNS per gli URL
- Prima di usare domini personalizzati nel proxy dell'applicazione, è necessario creare un record CNAME nel DNS pubblico, consentendo ai client di risolvere l'URL esterno definito personalizzato nell'indirizzo proxy dell'applicazione predefinito. 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 dal provider DNS al provider, quindi informazioni su come gestire record e set di record DNS 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
- Connessione or l'installazione richiede diritti di amministratore locale per il server Windows in cui è installato. Richiede anche un minimo di un ruolo Application Amministrazione istrator per autenticare e registrare l'istanza del connettore nel tenant di Microsoft Entra.
- La pubblicazione e l'amministrazione dell'applicazione richiedono il ruolo Application Amministrazione istrator. Le applicazioni Amministrazione istrator possono gestire tutte le applicazioni nella directory, incluse registrazioni, impostazioni SSO, assegnazioni di utenti e gruppi e licenze, impostazioni proxy applicazione e consenso. Non consente tuttavia di gestire l'accesso condizionale. Il ruolo applicazione cloud Amministrazione istrator ha tutte le capacità di Application Amministrazione istrator, 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 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 a cui l'applicazione potrebbe essere già esposta, esternamente. URL da usare per l'accesso esterno. Se SharePoint, verificare che i mapping di accesso alternativi siano configurati in base a queste indicazioni. In caso contrario, sarà 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 basata su intestazione, la soluzione del fornitore e il requisito specifico per la gestione del tipo di autenticazione.
Nome del gruppo di connettori	Nome logico per il gruppo di connettori che verrà designato per fornire il canale e l'accesso SSO a questa applicazione back-end.
Accesso a utenti/gruppi	Utenti o gruppi di utenti a cui verrà concesso l'accesso esterno all'applicazione.
Requisiti aggiuntivi	Prendere nota di eventuali requisiti aggiuntivi 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, a condizione che siano registrati in MFA e abbiano registrato 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, se comparate con l'accesso dalla rete interna.

Esperienza utente

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

Controllo

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é questa configurazione richiede poco impegno per creare correttamente un progetto pilota per 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 del progetto pilota a un gruppo progetto pilota, nascondendo l'icona di avvio dal portale di App personali di Azure. Quando si è pronti per la produzione, è possibile definire l'ambito dell'app verso i rispettivi destinatari, nello stesso tenant di pre-produzione o pubblicando l'applicazione 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. Questo include assicurarsi che gli host del connettore di aggiunta a un dominio eseguano l'accesso SSO usando la delega vincolata Kerberos (KCD) e prendersi cura 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. Seguire le istruzioni seguenti per 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 pre-autenticazione disabilitata.
In caso di esito positivo, abilitare la pre-autenticazione e assegnare utenti e gruppi. Testare e convalidare l'accesso.
Aggiungere quindi il metodo SSO per l'applicazione e testare di nuovo per convalidare l'accesso.
Applicare i criteri di accesso condizionale e dell'MFA in base alle esigenze. Testare e convalidare l'accesso.

Strumenti per la risoluzione dei problemi: Quando si esegue la risoluzione dei problemi, iniziare sempre convalidando l'accesso all'applicazione pubblicata dal browser nell'host del connettore e verificare che l'applicazione funzioni come previsto. Più è semplice la configurazione, più è semplice determinare la causa radice, quindi prendere in considerazione l'idea di provare a riprodurre i problemi con una configurazione minima, ad esempio usando un solo connettore e nessun accesso SSO. In alcuni casi, gli strumenti di debug Web come Fiddler di Telerik possono rivelarsi indispensabili per risolvere i problemi di accesso o contenuto nelle applicazioni a cui si accede tramite un proxy. Fiddler può anche fungere da proxy per consentire di tracciare ed eseguire il debug del traffico per piattaforme mobili come iOS e Android e praticamente di qualsiasi elemento che può essere configurato per l'instradazione tramite un proxy. Per altre informazioni, vedere la guida alla risoluzione dei problemi.

Implementare la soluzione

Distribuire Application Proxy

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

Pubblicare le applicazioni con Application Proxy

Pubblicare applicazioni presuppone che siano stati soddisfatti tutti i prerequisiti e che siano presenti diversi connettori visualizzati come registrati e attivi nella pagina di Application Proxy.

È anche possibile pubblicare le applicazioni usando PowerShell.

Di seguito sono riportate alcune 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à. La presenza di tre connettori è ottimale nel caso in cui sia necessario lavorare su uno dei computer. 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.
Impostare il timeout applicazione back-end: Questa 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 la riceve, il lato client della conversazione è già scaduto. L'impostazione del timeout su Long fornisce 180 secondi per il completamento di transazioni più lunghe.
Usare i tipi di cookie appropriati
- Cookie solo HTTP: offre maggiore sicurezza con il proxy dell'applicazione che include il flag HTTPOnly nelle intestazioni di risposta HTTP set-cookie. Questa impostazione consente di ridurre gli exploit, ad esempio lo scripting intersito (XSS). Lasciare questa opzione impostata su No per i 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) includerà il cookie solo nelle richieste HTTP se la richiesta viene trasmessa su un canale protetto TLS. Ciò consente di ridurre il rischio di compromissione di un cookie su canali di testo non crittografati, quindi dovrebbe essere abilitato.
- Cookie persistente: consente al cookie di sessione del proxy dell'applicazione di mantenere in modo permanente tra le chiusura del browser rimanendo validi fino alla scadenza o all'eliminazione. Usato per scenari in cui un'applicazione avanzata, come Office, accede a un documento all'interno di un'applicazione Web pubblicata, senza che all'utente venga nuovamente richiesto di eseguire l'autenticazione. Tuttavia, è meglio abilitarli con cautela, poiché i cookie persistenti possono causare il rischio di accesso non autorizzato nel servizio, se non usati in combinazione 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 questa impostazione.
Tradurre URL nelle intestazioni: Questa opzione viene abilitata per gli scenari in cui il DNS interno non può essere configurato in modo che corrisponda allo spazio dei nomi pubblico dell'organizzazione (ovvero, Split DNS). A meno che l'applicazione non richieda l'intestazione host originale nella richiesta client, lasciare questo 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, questa 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, questa funzione offre un tentativo ottimale di tradurre tutti i collegamenti interni trovati da Application Proxy nelle risposte HTML e CSS restituite ai client. È utile quando si pubblicano app che contengono collegamenti assoluti hardcoded o nome breve NetBIOS nel contenuto o nelle app con contenuto collegato ad altre applicazioni locali.

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.

Immagine 1

Quando si abilita la conversione dei collegamenti per l'app Vantaggi, i collegamenti a Spese e Viaggi vengono reindirizzati agli URL esterni per tali app, in modo che gli utenti che tentano di accedervi dall'esterno della rete aziendale possano accedere. I collegamenti da Spese e Viaggi back a Vantaggi non funzionano perché la traduzione dei collegamenti non è stata abilitata per queste due app. Il collegamento a Feedback non viene reindirizzato perché non esiste un URL esterno, quindi gli utenti che usano l'app Vantaggi non potranno accedere all'app Feedback dall'esterno della rete aziendale. Vedere informazioni dettagliate sulla conversione dei collegamenti e altre opzioni di reindirizzamento.

Accedere all'applicazione

Esistono diverse opzioni per la gestione dell'accesso alle risorse pubblicate da Application Proxy, quindi scegliere la più appropriata per lo scenario e le esigenze di scalabilità specifiche. Gli approcci comuni includono: l'uso di gruppi locali sincronizzati tramite Microsoft Entra Connect, la creazione di gruppi dinamici in Microsoft Entra ID in base agli attributi utente, l'uso di gruppi self-service gestiti da un proprietario della risorsa o una combinazione di questi elementi. Per scoprire i vantaggi di ognuno, vedere le risorse collegate.

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 l'opzione abilitata, gli utenti potranno quindi accedere al portale App personali e richiedere l'accesso e essere approvati automaticamente e aggiunti al gruppo self-service già consentito, oppure dovranno essere approvati da un responsabile approvazione designato.

Gli utenti guest possono anche essere invitati ad accedere alle applicazioni interne pubblicate tramite proxy dell'applicazione tramite Microsoft Entra B2B.

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

Immagine 26

Se si lascia questa opzione impostata su No, gli utenti possono accedere all'applicazione locale tramite Application Proxy di Microsoft Entra senza autorizzazioni, quindi è meglio usarla 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 pre-autenticazione

Verificare che l'applicazione sia accessibile attraverso l'URL esterno tramite Application Proxy.

Passare a Identità>Applicazioni>Applicazioni aziendale>Tutte le applicazioni e scegliere l'app da gestire.
Selezionare Application Proxy.
Nel campo Pre-autenticazione, usare l'elenco a discesa per selezionare Microsoft Entra ID e selezionare Salva.

Con la pre-autenticazione abilitata, Microsoft Entra ID prima verificherà gli utenti per l'autenticazione e se l'accesso Single Sign-On è configurato, l'applicazione back-end verificherà anche l'utente prima che venga concesso l'accesso all'applicazione. La modifica della modalità di pre-autenticazione da Passthrough a Microsoft Entra ID configura anche l'URL esterno con HTTPS, quindi qualsiasi applicazione inizialmente configurata per HTTP verrà protetta con HTTPS.

Abilita Single Sign-On

L'accesso SSO offre la migliore esperienza utente e la migliore sicurezza possibile, perché quando gli utenti accedono a Microsoft Entra ID, devono farlo una volta sola. Dopo che un utente ha eseguito l'autenticazione preliminare, SSO viene eseguito dal connettore di rete privato che esegue l'autenticazione all'applicazione locale, per conto dell'utente. L'applicazione back-end elabora l'accesso come se fosse l'utente stesso.

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

L'esecuzione dell'accesso SSO è possibile solo se Microsoft Entra ID può identificare l'utente che richiede l'accesso a una risorsa, pertanto l'applicazione deve essere configurata per pre-autenticare gli utenti con Microsoft Entra ID al momento dell'accesso, affinché l'accesso SSO funzioni. In caso contrario, le opzioni SSO verranno disabilitate.

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 può supportare anche le applicazioni sviluppate per l'uso di Microsoft Authentication Library (MSAL). Supporta le app client native utilizzando i token rilasciati da Microsoft Entra ID, e ricevuti nelle informazioni di intestazione della richiesta client, per eseguire la pre-autenticazione per conto degli utenti.

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

Usare l'accesso condizionale per rafforzare la sicurezza

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 diverse 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. Potrebbe essere necessario applicare temporaneamente alcuni ruoli e rimuoverli dopo il completamento della distribuzione.

Ruolo aziendale	Attività aziendali	Ruoli di Microsoft Entra
Amministratore dell'help desk	In genere limitato a compiti legati alla verifica dei problemi segnalati dall'utente finale e all'esecuzione di attività limitate, ad esempio la modifica delle password degli utenti, l'invalidazione dei token di aggiornamento e il monitoraggio 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.	Ruolo con autorizzazioni di lettura per la sicurezza
Proprietario dell'applicazione	Creare e gestire tutti gli aspetti delle applicazioni aziendali, delle registrazioni delle applicazioni e delle impostazioni di Application Proxy.	Amministratore applicazione
Amministratore dell'infrastruttura	Proprietario del rollover del certificato	Amministratore applicazione

Riducendo al minimo il numero di utenti che hanno accesso a informazioni o risorse protette, è possibile ridurre le probabilità che un utente malintenzionato ottenga l'accesso non autorizzato o che un utente autorizzato abbia inavvertitamente un impatto su una risorsa sensibile.

Tuttavia, gli utenti devono comunque eseguire operazioni con privilegi giornalieri, quindi l'applicazione dei criteri JIT (Just-In-Time) basati su Privileged Identity Management per fornire l'accesso con privilegi su richiesta alle risorse di Azure e Microsoft Entra ID è l'approccio consigliato per gestire efficacemente l'accesso amministrativo e il controllo.

Monitoraggio e creazione di report

Microsoft Entra ID fornisce informazioni dettagliate aggiuntive sull'utilizzo e sull'integrità operativa dell'applicazione dell'organizzazione tramite log di controllo e report. Application Proxy 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 questa 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.

Condividi tramite