Budget temporale (AX2Go e rete virtuale) - LSM 3.6 Business + Prof.
Il concetto “budget temporale” si presenta in due contesti diversi:
- AX2Go: Intervallo aggiornamento chiave (giorni)
- Rete virtuale: Finestra oraria dinamica
In ambedue i casi un mezzo di identificazione è utilizzabile solo per un tempo limitato, prima di dover ricaricare il budget temporale. Durante la ricarica si verifica se le modifiche delle autorizzazioni siano presenti o se il mezzo di identificazione sia stato anche bloccato.
| AX2Go: Intervallo aggiornamento chiave (giorni) | Rete virtuale: Finestra oraria dinamica |
|---|---|---|
Possibilità di impostazione |
|
|
Ricarica tramite | Servizio LSM.AX2Go. Non appena AX2Go e il servizio LSM.AX2Go accedono ambedue al cloud e si vedono, il budget temporale viene ricaricato completamente. | Gateway della rete virtuale |
Frequenza della ricarica | Lo smartphone con AX2Go è collegato in modo permanente con Internet e quindi con il cloud, a parte poche eccezioni. In questo modo, ogni volta che il servizio LSM.AX2Go si collega con il cloud, il budget temporale viene ricaricato completamente. Il servizio LSM.AX2Go si collega subito con il cloud in caso di modifiche importanti (ad es. modifiche delle autorizzazioni), altrimenti avviene come definito in Ciclo lento (min.). | Non appena il mezzo di identificazione viene azionato sul gateway e non è stato bloccato, il budget temporale viene ricaricato. |
Finalità dell’impiego | Uno smartphone potrebbe passare alla modalità aereo con la conseguente e prevista interruzione del collegamento al servizio LSM.AX2Go. Una modifica delle autorizzazioni in questo caso non raggiungerebbe mai AX2Go. Intervallo aggiornamento chiave (giorni) obbliga tutti gli utenti di AX2Go a consentire con regolarità un collegamento tra AX2Go e il servizio LSM.AX2Go. Così, la modalità aereo non può essere adoperata in modo improprio, per usare inopinatamente un’autorizzazione in maniera permanente. | Nella rete virtuale la "Finestra oraria dinamica" svolge due task:
Nella rete virtuale i dati vengono trasportati con l’ausilio dei mezzi di identificazione dal gateway alle chiusure e ritorno. A tale riguardo, quanto più spesso i mezzi di identificazione si trovano sul gateway, tanto meglio funziona lo scambio di dati. Con il budget temporale limitato vi assicurate che tutti gli utenti vadano regolarmente sul gateway. Inoltre, un mezzo di identificazione rubato, dopo la disattivazione (ad es. dopo uno smarrimento), non può essere utilizzato per un budget temporale superiore a quello impostato. Non importa che la disattivazione sulle chiusure sia stata attivata o meno. Il budget temporale del mezzo di identificazione rubato non può più essere rinnovato e quindi scade. |
Esempio (funzionamento normale) | Esempio: impostato budget temporale di 30 giorni. L’AX2Go di un utente si collega attraverso il cloud al servizio LSM.AX2Go. Dal momento che l’utente continua a essere autorizzato, il budget temporale si rinnova per tutti i 30 giorni. Il server con il servizio LSM.AX2Go non è utilizzabile per alcuni giorni a causa di interventi di manutenzione. Dal momento che l’AX2Go dell’utente dispone, però, di un budget temporale di 30 giorni, lo stesso AX2Go può continuare a essere utilizzato senza problemi durante l’intero periodo degli interventi suddetti. Dopo gli interventi di manutenzione, il server si riavvia. Il servizio LSM.AX2Go si collega al cloud e il budget temporale dell’utente viene rinnovato. L'AX2Go dell’utente funziona senza interruzioni durante l’intero periodo di tempo. | Esempio: impostato budget temporale di 10 ore. Un utente aziona il proprio mezzo di identificazione sul gateway. Il gateway si collega con il database e verifica che il mezzo di identificazione non sia stato bloccato e rinnova il budget temporale. L’utente, successivamente, può utilizzare il proprio mezzo di identificazione per 10 ore. In seguito, azionando nuovamente il proprio mezzo di identificazione sul gateway, ottiene un nuovo budget temporale. |
Esempio (problema) | Esempio: impostato budget temporale di 7 giorni. A un utente AX2Goviene revocata un’autorizzazione. Tuttavia, poiché l’utente sa che l’autorizzazione deve essere revocata ma intende comunque azionare la chiusura più tardi senza essere scoperto, inserisce la modalità aereo, per evitare che gli venga revocata l’autorizzazione. AX2Go non può più effettuare alcun collegamento al cloud e, di conseguenza, il budget temporale dell’utente interessato non viene più rinnovato. Una volta trascorsi 7 giorni, l’utente non può più azionare alcuna chiusura con il proprio AX2Go ed è costretto a consentire il collegamento online. In questo modo, anche l’autorizzazione revocata raggiunge il relativo AX2Go. | Esempio: impostato budget temporale di 10 ore. Un mezzo di identificazione viene segnalato come rubato e disattivato dal gestore del sistema di chiusura. Nel corso del tempo gli ID di blocco vengono distribuiti alle chiusure nella rete virtuale. Alcune chiusure più remote, però, non hanno ancora ricevuto alcun ID di blocco anche dieci ore dopo il blocco. Il mezzo di identificazione rubato, comunque, non può più essere utilizzato nemmeno su queste chiusure. Il budget temporale è scaduto e, a causa della disattivazione, non viene più rinnovato. |