Skip to Content
DocsOplon Secure AccessConfigurazione

Configurazione di Oplon Secure Access

In questa parte di guida, rivolta agli amministratori della suite Oplon, descriviamo i concetti fondamentali di Oplon Secure Access e come configurare nuove risorse per consentirne l’accesso da terzi.

Al termine della guida si comprenderanno i concetti di User Group e Resource e si riuscirà a creare per la prima volta una risorsa di tipo Host o Web App/Link.

Prerequisiti

  1. Avere già installato e configurato l’appliance come descritto qui.
  2. Avere configurato MFA come indicato in questa guida.
  3. (Opzionale) Se si desidera usare il File Managing su risorse Windows, installare OpenSSH Server su ogni risorsa:

Concetti fondamentali

Dentro OSA esistono alcuni concetti fondamentali che è utile spiegare:

User Group

Gli User Group rappresentano una classe di utenti con gli stessi privilegi e servono per associare risorse (Host / Link) agli utenti.

Uno User Group ha un nome univoco e una descrizione. Gli User Group definiti in Oplon Secure Access si associano agli User Group definiti in MFA—come descritto in questa guida—in modo che a ogni utente censito in Oplon MFA venga concesso il privilegio corretto.

Resources e Location

In Secure Access una Resource è un’entità che può identificare:

  • un Host (Windows, Linux, macOS)
  • una Remote App
  • una Web App/Link

Ogni risorsa può essere catalogata tramite una Location, un’etichetta usata per raggruppare logicamente le risorse.

Host

Un Host è la rappresentazione di una macchina (fisica o virtuale) identificata da IP/hostname. È possibile assegnare a un Host una Location per raggruppamento logico.

Su un Host possono convivere vari tipi di accesso:

  • SSH
  • RDP
  • Remote App (RDP)
  • VNC
  • SFTP (File manager)

Questi accessi possono essere assegnati ai User Group secondo le policy desiderate. È inoltre possibile definire dei OS login/AD login predefiniti, in modo che l’utente non debba inserire né username né password.

Remote App

Le Remote App (RDP only) sono entità figlie di un Host e consentono di esporre singole applicazioni tramite il protocollo RDP.

Una Web App/Link è una risorsa rappresentata da un URL. Può essere accessibile tramite Oplon Secure Access:

  • in modalità nativa HTTP/HTTPS
    • tramite il Reverse Proxy di Oplon (con autenticazione MFA)
    • pubblicata su Internet
  • in modalità Browser Isolation (vedi qui)

La modalità nativa richiede meno risorse rispetto alla Browser Isolation, che necessita di appliance dedicate ma offre un livello di sicurezza e segregazione superiore.

Shared Folders

Le Shared Folders permettono di montare, tramite l’Oplon Client (Windows, Linux, macOS), dei drive di rete protetti dalla piattaforma (MFA, ZTNA, policy). L’accesso è sempre autenticato e autorizzato in base agli User Group e alle policy configurate.

Attualmente il protocollo supportato per il mount è WebDAV: la condivisione viene esposta al client come unità/drive o mount point e tutte le operazioni file sono mediate e tracciate da Oplon.

Trusted Connection

Una Trusted Connection apre un canale sicuro tra l’host e i backend selezionati (ad es. DB Server, Telenet, applicativi in generale). L’accesso passa tramite MFA, ZTNA e le policy PAM di Oplon; l’Oplon Client può localmente reverse‑proxare il servizio su localhost in una porta specifica (es. localhost:NNNN), consentendo l’utilizzo di servizi interni senza esporre porte pubbliche.

Interfaccia di configurazione

Per configurare nuove risorse aprire l’interfaccia di amministrazione di Oplon Secure Access all’indirizzo: https://<your-ip>:4444 e autenticarsi.

Nel menu di sinistra aprire Secure Access > Settings e accedere al modulo.

In questa schermata è possibile:

  • visualizzare la lista degli User Group
  • gestire la lista degli Host
  • gestire la lista delle Web App/Link

Aggiunta nuovi User Groups

Per aggiungere un nuovo User Group cliccare il pulsante verde (+) su uno User Group esistente: ne verrà creato uno vuoto e poi potrà essere modificato.

Per ogni User Group è possibile abilitare o disabilitare il permesso di utilizzare le session temporary connections (funzionalità riservata tipicamente agli amministratori) e la registrazione video delle sessioni ad esse associate. Le session temporary connections sono connessioni temporanee che consentono agli utenti — appartenenti ad almeno un gruppo in cui questa funzionalità è abilitata — di connettersi a qualsiasi Host, anche in assenza di gruppi associati alla risorsa di destinazione.

Gli utenti con questo privilegio possono accedere a una risorsa anche senza possedere gruppi ad essa associati, a condizione che siano in possesso delle relative credenziali di accesso.

Aggiungere un nuovo Host

Per aggiungere un nuovo Host cliccare il pulsante verde (+) di un Host esistente: verrà duplicato e poi potrà essere modificato.

Per modificare un Host è consigliabile aprire i dettagli premendo See Details.

Campi importanti:

  • Hostname / IP
  • Name
  • Location
  • Description
  • Servizi e porte: SSH, RDP, VNC, SFTP (File manager)…
  • Eventuali RD Gateway (RDP only)
  • User Group associati
  • Eventuali Remote App (RDP only)

Qui abbiamo configurato un Host 127.0.0.1 e associato lo User Group Local.

Aggiungere una nuova Remote App

Per aggiungere una nuova Remote App, bisogna necessariamente partire da un Host con l’accesso RDP già configurato.

Per aggiungere una Remote App partire da un Host con accesso RDP configurato, aprire Secure Access > Settings aprire un Host e poi su una Applications possiamo inserire:

  • name (nome visualizzato)
  • description
  • app name (alias RDP)
  • working dir (opzionale) la directory di lavoro dell’app
  • args (opzionale) gli argomenti di start dell’app

Ricordarsi di eseguire sempre Save e Re‑Init.

Aggiungere una nuova Web App

Per aggiungere una nuova Web App, è possibile andare sempre nell’interfaccia di Settings e infondo trovare la schermata Web Apps.

Qui inserire le informazioni minime per poter usufruire della Web App ovvero:

  • name
  • url
  • location

Ricordarsi di eseguire Save e Re‑Init.

Browser Isolation

Se per la Web App nativa è necessario seguire le istruzioni indicate sopra, per rendere disponibile la Web App in modalità Browser Isolation è necessario attivare l’opzione enable Browser Isolation.

Da qui, entrando dentro con la freccetta nera a fine rigo, possono seguirsi una serie di configuzioni/personalizzazioni specifiche per la sola modalità di Browser Isolation e sono:

  1. enable Browser Isolation: serve ad abilitare la browser isolation
  2. Whitelisted: serve ad andare in white list sull’url inserito sopra. Questo avrà l’effetto di bloccare la navigazione su tutti gli altri url se non l’url stesso ed eventualmente quelli specificati sotto in “White Listed Domain”:
  3. White Listed Domains: Qui è possibile indicare una serie di indirizzi da non bloccare, se si è in “Whitelisted=true”, separati da virgola. La sintassi da seguire è: <scheme>://<host><path> (qui  per una guida più completa sulla sintassi)

Nel caso della whitelist, attualmente non possono essere impostate le porte nello schema.

Aggiungere una nuova Shared Folder

Per aggiungere una Shared Folder basta cliccare (+) sulla schermata dedicata.

Per modificare una Shared Folder è consigliato entrare nel dettaglio tramite il pulsante “See Details”.

Campi configurabili:

  • url: indirizzo tramite l’ADC di Oplon (es. https://sales.drive.acme.net)
  • name: nome leggibile
  • assignedUserGroups: User Group autorizzati
  • description: breve descrizione e policy

Configurazione Shared Folders su Oplon ADC

Prima di tutto, è importante verificare che l’endpoint /api/sf/verify-token del grouping di Secure Access sia presente e abilitato con la seguente regola di rewrite applicata: LBLWebDavConnector.

Se l’endpoint non è presente (caso in cui si viene da un’installazione precedente alla 11.3.0), è necessario crearlo clonando l’endpoint /api e personalizzandolo con i valori richiesti.

Perché l’url funzioni, l’ADC di Oplon deve eseguire il reverse‑proxy verso il backend WebDAV e applicare la rewrite rule LBLWebdavConnector.

Passi minimi:

  • creare/usare il virtual domain (es. https://sales.drive.acme.net)
  • applicare la rewrite rule LBLWebdavConnector sulla route

Assicurarsi di fornire un certificato SSL/TLS valido per il dominio reverse‑proxato (ad esempio sales.drive.acme.net). Un certificato corretto evita avvisi del browser e garantisce connessioni sicure tra i client e l’ADC.

Se si usa MFA sullo stesso listener o grouping, occorrerà impostare la regola di rewrite di MFA in NOP (come riportato nello screenshot).

Firewalling dei file trasferiti con Shared Folders

Per filtrare i file WebDAV applicare due rewrite rule sulla stessa route:

  • LBLHTTPWebDavFileCheckHeader (rewrite header)
  • LBLHTTPWebDavFileCheckBody (rewrite body)

Entrambe le rule sono personalizzabili: modificando la variable WHITE_LIST_EXT si imposta la lista di estensioni consentite / bloccate (es. .exe,.bat,.js). Le rule verificheranno header e/o contenuto dei trasferimenti e bloccheranno i file non consentiti.

Aggiungere una nuova Trusted Connection

Per aggiungere una Trusted Connection cliccare (+) nella sezione Trusted Connections; la voce duplicata è poi modificabile.

Campi configurabili:

  • name: nome descrittivo della connessione
  • description: breve descrizione
  • endpoint IP: IP del backend di destinazione
  • endpoint PORT: porta del backend di destinazione
  • listener IP: IP su cui Oplon ascolta le connessioni per il tunneling
  • listener PORT: porta su cui Oplon ascolta le connessioni per il tunneling
  • location: etichetta logica
  • connection timeout: timeout di connessione (ms)
  • upstream port: porta locale su localhost che l’Oplon Client esporrà (es. localhost:NNNN)
  • assignedUserGroups: User Group autorizzati

Salvare e fare Save e Re‑Init.

Configurazione di Trusted Connections su Oplon ADC

Per poter creare almeno una Trusted Connection è necessario predisporre sul modulo ADC un listener dedicato al tunneling.

  1. Andare in ADC Settings > Listeners e abilitare “View Template Listners”.
  2. Cercare il template denominato “Trusted Connections listener” e usare il pulsante Copy per copiarlo nel modulo ADC target.
  3. Modificare il listener appena copiato impostando l’address e la listener PORT desiderati per il tunneling.
  4. Nota bene: questo listener opera a Layer 4 ed ha applicata la rewrite rule: LBLRWL4P2P.
  5. Se il tunnel richiede terminazione o rientro SSL, associare al listener il certificato appropriato (keystore/alias) e abilitare le opzioni SSL prima del salvataggio.
  6. Salvare le modifiche e procedere con Save / Re‑Init del modulo ADC.

  1. È anche importante inoltre, abilitare (se non già fatto) i due endpoint del grouping di Secure Access che si chiamano corrispettivamente: /api/p2p e /api/p2p/verify-token

Se gli endpoint non dovessero essere presenti (caso in cui si viene da un’installazione precedente alla 11.3.0), è necessario crearli clonando l’endpoint /api e personalizzandolo con i valori richiesti.

AddressPortURI PathRW Header Rules
127.0.0.12222/api/p2pLBLP2PConnector 2faGeneric;NOP
127.0.0.12222/api/p2p/verify-tokenLBLP2PConnector

Assicurarsi di fornire un certificato SSL/TLS valido per il dominio reverse‑proxato. Un certificato corretto evita avvisi del browser e garantisce connessioni sicure tra i client e l’ADC.

Assegnazione User Group

L’associazione di uno User Group a una risorsa conferisce il diritto di accesso agli utenti del gruppo. Assegnando una risorsa a uno User Group si abiliteranno/diseabiliteranno varie policy, tra cui:

  • accesso SSH
  • accesso RDP
  • accesso VNC
  • File Manager (con opzioni: Upload, Download, Hypercopy)
  • copia/incolla remoto
  • Impersonification
  • logging di sessione (RDP/SSH)
  • stampante virtuale, audio in/uscita

Se non è definito almeno un OS Login/AD Login su una risorsa assegnata a un User Group, gli utenti di quel gruppo potranno autenticarsi con qualsiasi credenziale a prompt.

Assegnazione di uno User Group con Impersonification

L’Impersonification consente di mappare l’identità digitale dell’utente (proveniente da MFA e/o Active Directory) a uno specifico OS Login/AD Login (es. utenza di dominio o locale) per l’accesso alle risorse.

L’impersonification può provenire da diverse fonti:

  1. MFA: definita nel MFA Manager e per riassumero può essere:
    • Globale: un singolo impersonification valido ovunque (es. ImpersonificationGlobal).
    • Per Gruppo: specifica per l’appartenenza a un gruppo (sintassi Group::Impersonification).
  2. Active Directory: derivata dall’integrazione AD (ImpersonificationAD).

Regole di priorità:

  • Possono esistere più impersonification legati ai gruppi (da MFA), ma solo uno per ogni gruppo specifico. (Questo ha priorità su quello globale)
  • Può esistere un solo impersonification AD. (Questo ha priorità su quello globale)
  • Può esistere un solo impersonification globale (da MFA).

Logica di Accesso (Strict vs Non-Strict) Il controllo degli accessi varia in base a come è configurato lo User Group sulla risorsa:

  • Modalità Non-Strict (Nessun OS Login/AD Login specificato nel gruppo): L’accesso è consentito. Se è presente un valore di impersonificazione (si guarda quello per gruppo se esiste Group::Impersonification, altrimenti si passa a quello globale o di AD se esiste ImpersonificationGlobal/ImpersonificationAD ), verrà proposto come username per la sessione.

  • Modalità Strict (Almeno un OS Login/AD Login specificato nel gruppo): L’accesso è consentito solo se il valore di impersonificazione dell’utente (si guarda quello per gruppo se esiste Group::Impersonification, altrimenti si passa a quello globale o di AD se esiste ImpersonificationGlobal/ImpersonificationAD ) corrisponde esattamente a uno degli OS Login/AD Login elencati nella configurazione del gruppo.

Tabella riassuntiva assegnazione User Group

OS/AD Login NamesComportamento di Accesso
Libero: L’utente inserisce qualsiasi credenziale a prompt.
Vincolato: L’utente seleziona uno degli utenti definiti (password gestita dal Vault).

Tabella riassuntiva assegnazione User Group con impersonification a true

OS/AD Login NamesGroup::ImpersonificationGlobal/AD ImpersonificationComportamento di Accesso
❌ (Non-Strict)Impersonato: L’utente entra automaticamente con l’identità Global/AD.
❌ (Non-Strict)Impersonato (Gruppo): L’utente entra con l’identità del Gruppo (che ha priorità su Global).
✅ (Strict)Verificato: Accesso consentito solo se l’identità Global/AD è presente nella lista OS/AD Login.
✅ (Strict)Verificato (Gruppo): Accesso consentito solo se l’identità del Gruppo è presente nella lista OS/AD Login.

Assegnazione OS Login/AD Login a uno User Group

Una volta assegnato uno User Group dentro un Host, possiamo assegnarli degli utenti prefissati che devono esistere all’interno dell’host stesso (OS Login) o all’interno di un dominio Active Directory (AD Login).

Entrambi, una volta popolati, andranno a contribuire alla creazione dei Vault di Secure Access, corrispettivamente avremo un:

  • OS Login Vault per gli utenti locali della macchina
  • AD Login Vault per gli utenti di dominio Su questa parte rimandiamo alle sezioni successive e alla pagina di configurazione dei vault.

Qui possiamo inserire tanti utenti quanti sono quelli con cui vogliamo far accedere quel determinato User Group.

L’inserimento di anche un solo utente, disabilita la possibilità per lo User Group di fare accesso con qualsiasi credenziale forzando gli accessi successivi con le sole credenziali indicate.

Inserendo anche un solo username si costringeranno gli utenti appartenenti a quello User Group di entrare unicamente con quello username e d’inserire ogni volta le password corrispettive.

Nel Caso si voglia inserire anche una password, per far si che l’utente non debba ricordarla, saperla o inserirla ogni volta, rimandiamo ai paragrafi successivi.

Assegnazione utenti “administrator” e “root”

Inserimento password per un OS Login (Host Vault)

Per assegnare la password a un OS Login (assegnato a uno User Group) di un Host, occorre andare nella sezione Host Vault tramite il menù: PAM Management > Vault Manager > Host Vault

Cercare la risorsa corrispettiva dalla barra di ricerca e cliccare il pulsante con la chiave verde per andare in modifica sugli OS Login Names.

Da qui selezionare gli utenti di cui si vogliono inserire le password dal menu a tendina e inserire le

corrispettive password

Ricordarsi sempre di fare Save e Re‑Init.

Inserimento password per un AD Login (AD Vault)

Per assegnare la password a un AD Login (assegnato a uno User Group) di un Host, occorre andare nella sezione AD Vault tramite il menù: PAM Management > Vault Manager > AD Vault

Cercare lo username di AD corrispettivo dalla barra di ricerca e cliccare il pulsante con la chiave verde per andare in modifica sugli AD Login Names.

Da qui è possibile inserire la corrispettiva password:

Ricordarsi sempre di fare Save e Re‑Init.

Access Schedule

Questa funzionalità consente di controllare quando una macchina può essere raggiunta o utilizzata. Le impostazioni vengono definite in ogni User Group assegnato alla risorsa. I parametri dello User Group sono:

  • Enable access schedule: indica se abilitare la restrizione temporale;
  • Time zone: indica il time zone sul quale si applica la restrizione temporale.

Nel dettaglio dello User Group esiste un pannello chiamato Access Schedule che definisce le regole di accesso.

Parametri di configurazione

ParametroTipoDescrizione
enablebooleanIndica se la restrizione temporale è attiva. Se false, l’accesso è sempre consentito.
dailybooleanSe true il controllo è giornaliero; se false, si applica un intervallo assoluto continuo tra due istanti temporali.
fromDatestring (YYYY-MM-DD)Data di inizio.
toDatestring (YYYY-MM-DD)Data di fine.
fromTimestring (HH-MM)Ora di inizio.
toTimestring (HH-MM)Ora di fine.

Logica di accesso

  • enable = false: nessuna restrizione, l’accesso è sempre consentito (gli altri parametri non influenzano il risultato).

  • enable = true e daily = false: Pianificazione assoluta. L’accesso è consentito solo all’interno di un intervallo continuo compreso tra: fromDate + fromTime e toDate + toTime. Esempio:

    ParametroValore
    fromDate2025-10-01
    fromTime08:00
    toDate2025-10-05
    toTime19:00

    Accesso valido solo dal 01/10 ore 08:00 al 05/10 ore 19:00.

  • enable = true e daily = true: Pianificazione ricorrente giornaliera. La finestra è valida solo se:

    1. La data corrente rientra tra fromDate e toDate
    2. L’orario rientra nella finestra definita da fromTime e toTime
    CondizioneEsempioLogica di accesso
    fromTime < toTime08:00 – 17:00Accesso solo tra 08:00 e 17:00 dello stesso giorno
    fromTime > toTime22:00 – 06:00Accesso dopo le 22:00 oppure prima delle 06:00 (attraversa la mezzanotte)

Schema riepilogativo

EnableDailyTipo di intervalloLogica di valutazioneAccesso consentito
falsequalsiasiNessunoNessuna restrizioneSempre
truefalseFinestra assolutaControllo continuoadesso ∈ [fromDate+fromTime , toDate+toTime]
truetrueFinestra giornalieraControllo ricorrenteoggi ∈ [fromDate , toDate] e ora nel range

Parametri Trusted Connections

Nel listener Trusted Connection è possibile impostare il parametro protocol al valore trusted-connection ottenendo così un timeout client di 12 ore (quello di default è di 7 minuti e mezzo). Se la connessione rimane inattiva oltre questo limite, viene chiusa automaticamente.

Nel file di configurazione L4.conf contenuto nella cartella conf del modulo ADC (platform, standardHA o enterprise), è possibile specificare ulteriori regole.

  • TRUST_CONN_TRACE=val: val può essere true o false. Abilita/disabilita i log verbosi per fare debug;
  • TRUST_CONN_LEASE_TIME_CUT_CONN=n: n è un valore in millisecondi che rappresenta il timeout di connessione (se impostato viene preso il minimo tra il valore di protocol del listener e questo valore);
  • TRUST_CONN_INTERVAL_TO_TOUCH=n: n è un valore in millisecondi che rappresenta ogni quanto far eseguire la verifica del traffico che resettare il timeout di connessione.

Network Metrics

La funzionalità di monitoraggio delle metriche, consente di analizzare in tempo reale e storicizzare le prestazioni di rete del client. I dati raccolti vengono visualizzati tramite un grafico interattivo nell’interfaccia client e inviati al backend per la memorizzazione e l’analisi storica.

Questa funzionalità è pensata per:

  • Monitorare la qualità della comunicazione client–server
  • Individuare anomalie di latenza e instabilità di rete
  • Supportare attività di troubleshooting e analisi delle performance

Le metriche sono calcolate direttamente dal client e rappresentano le reali condizioni di rete percepite dall’utente.

Visualizzazione delle metriche

Nell’interfaccia client è disponibile un grafico temporale che si trova nel menu delle impostazioni sotto la voce Network Metrics.

Viene mostrata un’anteprima della qualità della connessione del client in tempo reale:

  • buona
  • mediocre
  • scarsa

Cliccando sulla chip colorata si apre il grafico interattivo che mostra le metriche in tempo reale degli ultimi 5 minuti circa.

I dati mostrati nel grafico sono:

  • TTR: misura la latenza di rete;
  • Jitter: misura quanto stabile è questa latenza nel tempo (stabilità della connessione).

Cliccando sulla voce Show graph meaning si apre una sezione che descrive i dati con i relativi valori di riferimento.

Nell’interfaccia di amministrazione di Oplon Secure Access all’indirizzo: https://<your-ip>:4444 si possono trovare le metriche di tutti i client andando su: Running Status > Reports, selezionando il DB a cui sono stati inviati i dati e poi su User Network Metrics.