Vai al contenuto

Configurare una richiesta di accesso just-in-time

Una richiesta di accesso just-in-time (JIT) subordina un'applicazione a un'approvazione: l'utente non la avvia più direttamente, la richiede, e un amministratore concede l'accesso — facoltativamente per un solo utilizzo, per una fascia oraria o per una durata di sessione limitata.

È il meccanismo da utilizzare sulle risorse per le quali ogni accesso deve essere deciso anziché concesso una volta per tutte.

Come si articola il meccanismo

  1. In una politica di accesso, alcune delle applicazioni concesse a un gruppo vengono contrassegnate come con restrizioni.
  2. Nel portale queste applicazioni compaiono ma non possono essere avviate: l'utente invia una richiesta.
  3. Nel modulo Workflow l'amministratore la accetta o la rifiuta. L'accettazione crea un workflow, ossia l'autorizzazione effettiva, con le sue restrizioni.
  4. L'utente avvia l'applicazione entro i limiti di quel workflow.

La restrizione si imposta nella politica di accesso, la concessione nel modulo Workflow

I due moduli non sono intercambiabili: Access Policies decide quali applicazioni sono soggette a una richiesta, Workflows risponde alle richieste. Un'applicazione che non vi è sottoposta a restrizioni non produce mai alcuna richiesta.

Passaggio 1 — Sottoporre le applicazioni a un workflow

Aprire il modulo Access Policies e modificare — o creare — il contratto che riguarda gli utenti interessati. Percorrerne le schede nell'ordine: i gruppi di utenti, il sito che dà accesso alle risorse, poi le applicazioni pubblicate per quegli utenti.

Nella scheda Applications to restrict, spostare nell'elenco con restrizioni le applicazioni il cui accesso deve essere approvato.

Opzione Che cosa fa
Applications to restrict Elenco a due colonne. Ciò che si sposta a destra diventa soggetto a una richiesta.
Ask the user to complete a form when requesting access Chiede all'utente di documentare la propria richiesta. Le risposte vengono mostrate all'amministratore al momento della gestione della richiesta.

Fare clic su Validate.

Si può limitare solo ciò che è già stato concesso

L'elenco propone le applicazioni selezionate in precedenza nello stesso contratto: la restrizione è una riduzione di un accesso già concesso, non un modo per concederne uno.

Passaggio 2 — Che cosa vede l'utente

Nel portale un'applicazione con restrizioni viene visualizzata ma bloccata. Facendo clic su di essa si apre la richiesta anziché avviare l'applicazione — con la maschera da compilare, se l'opzione è stata selezionata nel passaggio 1.

L'utente attende quindi la risposta dell'amministratore. Una volta concesso l'accesso, l'applicazione diventa avviabile entro i limiti stabiliti dal workflow.

Passaggio 3 — Rispondere alla richiesta

Aprire il modulo Workflow e accedere alla scheda Users request. Selezionare la richiesta in attesa, quindi fare clic su Accept the request o Refuse the request.

L'accettazione apre una finestra precompilata con l'utente, il suo dominio e la risorsa richiesta.

Oltre a dare un nome al workflow, è qui che si impostano le restrizioni, che si cumulano:

Restrizione Che cosa limita
Unique usage L'applicazione può essere avviata una sola volta. Un ulteriore accesso comporta un'ulteriore richiesta.
Mandatory comment L'utente indica un motivo prima dell'avvio. Il commento viene poi visualizzato con la registrazione della sessione.
Date L'intervallo di date entro il quale l'applicazione può essere aperta.
Hour La fascia oraria entro la quale può essere aperta.
Maximum session duration La durata massima della sessione prima che venga chiusa.

La convalida senza alcuna restrizione produce un'autorizzazione senza limite temporale e la console richiede una conferma supplementare prima di crearla — è il momento di verificare che sia davvero ciò che si intendeva fare.

Il comportamento esaustivo delle due schede, del rifiuto e delle eliminazioni è descritto in Workflows.

L'eliminazione di un workflow revoca l'accesso

L'eliminazione di un workflow rimuove l'autorizzazione: l'utente deve inviare una nuova richiesta. I workflow obsoleti — date scadute, utilizzo unico esaurito, durata della sessione raggiunta — vengono eliminati automaticamente dal sistema.

Passaggio 4 — Essere avvisati delle richieste in arrivo

Per impostazione predefinita, nessuna e-mail avvisa l'amministratore che è stata inviata una richiesta. Finché non viene configurata una notifica, le richieste vanno cercate nella console.

Per essere avvisati:

  1. Disporre di un server SMTP nel modulo SMTP servers.
  2. Nel modulo Notification profiles creare un profilo: il server SMTP, il mittente e i destinatari, quindi, nella scheda Settings, selezionare l'opzione Application access requests.
  3. La selezione di tale opzione attiva la scheda Applications: aprirla, selezionare le applicazioni interessate, quindi convalidare.