Autonomous delegated authentication

Note prima dell'installazione

Oplon introduce l'autenticazione delegata in tutte le comunicazioni tra le componenti sensibili.

L'implementazione è maturata dall'esperienza in datacenter mission-critical per aumentare la sicurezza e diminuire le possibilità di utilizzi non autorizzati di procedure all'interno del/i datacenter.

L'utilizzo è stato specificatamente studiato per ambienti complessi dove è possibile delegare alcuni utenti o gruppi di utenti ad essere amministratori delle loro specifiche componenti.

Inoltre, la programmazione di funzioni di automazione attraverso remote shell o netsh, anche se protette con password crittografate e accessi censiti a livello centrale, espongono i datacenter moderni, basati sulla virtualizzazione, in serio pericolo. L'odierna possibilità di caricamento di un intero sistema operativo all'interno di virtualizzatori su Personal Computer compromette drasticamente la sicurezza dando la possibilità di eseguire da remoto procedure altamente pericolose, attraverso virtual machine clonate, se eseguite per produrre dei danni.

Procedure di business-continuity e di Disaster-Recovery impongono la necessità di scrivere moltissimi script che interagiscono a vari livelli del datacenter spesso con privilegi da amministratore/root. Una semplice operazione dolosa di inversione delle repliche dello storage, lanciata ad esempio da un sistema operativo clonato, può causare danni incalcolabili.

A questo proposito tutti i file delle password delle componenti Oplon sono crittografati ed utilizzabili solo dalla posizione e dal sistema operativo su cui sono stati originati. Eventuali clonazioni del sistema o furto dei file di autenticazione rende i file illeggibili e quindi qualsiasi operazione non possibile.

Questo documento è relativo alla sola configurazione delle autenticazioni utente e delle autenticazioni delegate. Per l'installazione delle componenti Oplon fare riferimento ai documenti di installazione dei singoli prodotti.

Introduzione

L'implementazione dell'autenticazione degli accessi Oplon Rel 9 si basa su 4 punti fondamentali:

1. crittografia dei repository delle autenticazioni

2. origine della creazione dei file di autenticazione

3. separazione dell'autenticazione utente e delegata

4. autonomia rispetto all'infrastruttura da gestire

Il primo (1) punto è importantissimo in quanto i file delle autenticazioni sono crittografati per permetterne la visibilità o leggibilità con i soli strumenti messi a disposizione dalla piattaforma Oplon

Il secondo (2) punto pone un significativo miglioramento nella sicurezza. Tutti i file risultano illeggibili, anche dagli strumenti Oplon, se vengono copiati o se vengono utilizzati su macchine virtuali o fisiche clonate.

Il terzo punto (3) separa la gestione degli utenti umani dagli utenti delegati o da sistemi Oplon di automazione o instradamento come Oplon Application Delivery Controller, Oplon Commander Decision Engine e Oplon Commander Work Flow che possono interagire su più livelli dei datacenter.

Il quarto punto (4) evidenzia come il sistema autoritativo debba essere completamente autonomo dall'infrastruttura che deve gestire. L'autorizzazione delegata all'azione è quindi completamente slegata ad esempio da Directory Server che potrebbero non essere disponibili al momento dell'esecuzione delle procedure di fail-over.

Panorama di riferimento

I panorami di riferimento di autenticazione delegata sono molteplici e tipicamente possono essere utilizzati per delegare dei sottosistemi ad essere amministrati da gruppi di persone che però non possono amministrare a loro volta i sistemi posti al di sopra di loro.

Un caso tra tutti, in un sistema gerarchico

Il panorama di riferimento dell'autenticazione delegata è un insieme di procedure che devono essere eseguite all'interno dei datacenter su più livelli infrastrutturali come Storage Area Network, Database, Directory server, application server e su più piattaforme operative, fisiche e virtuali: Sistemi operativi differenti, sistemi di virtualizzazione differenti. Uno scenario tipico di ambienti di Business-continuity e Disaster-recovery.

Oplon Commander Work Flow permette di eseguire le operazioni necessarie attraverso diversi layer architetturali invocando in uno step una operazione remota denominata Remote Workflow Command (RWC da questo momento). Una operazione RWC permette di eseguire un intero Workflow oppure un Workflow partendo da uno step designato o solamente uno step.

Solo a titolo esemplificativo di seguito una RWC dove #LBL_ADDRESS_RWC_TARGET# è la variabile che contiene l'indirizzo su cui effettuare l'operazione mentre selfTestNormalEnd è lo step da cui iniziare l'esecuzione del workflow. Per ulteriori approfondimenti si veda il manuale LBL_Commander_Installation.pdf.

step enable="true"
      name="rwcTest"
      description="Self Test ab end"
      waitBeforeExecute="1000"
      sysCommandTimeOut="600000"
      evaluateReturnCode="true"
      command="@RWC hostName=#LBL_ADDRESS_RWC_TARGET# workFlow=selfTestNormalEnd"
      maxRetry="3"
      gotoWhenFalse="abEnd"
      returncode value="0"
      description="ok"
      result="true"

Come si potrà notare nei parametri è assente qualsiasi elemento di autorizzazione come Login o Password. Infatti, le autorizzazioni sono contestuali alla persona o automa che avvia il workflow e vengono propagate ai nodi remoti che dovranno eseguire l'operazione. I nodi remoti in base al loro repository di autorizzazione verificheranno se la richiesta proviene da una fonte sicura ed in tal caso eseguiranno l'operazione.

Autorizzazioni utente

Le autorizzazioni utente sono le autorizzazioni che vengono utilizzate da persone che si accingono ad operare con gli strumenti Oplon. Ad esempio nel momento in cui si avvia Oplon Secure Web-Based GUI e viene richiesta una login password autoritativa utente:

L'impostazione delle autorizzazioni utente viene effettuata la prima volta tramite il comando lblsetup con l'impostazione dell'utente con autorizzazioni root e l'utente primario di delega.

Autorizzazioni delegate

Le autenticazioni delegate sono utilizzate per autorizzare un'operazione che deve attraversare più layer e dove il layer di esecuzione finale non necessariamente conosce l'utente o l'automa che ha effettuato la prima operazione.

Possiamo ad esempio ipotizzare un'organizzazione che necessiti di avere tre site con diverse autorizzazioni di esecuzione a seconda della posizione da cui si vuole effettuare l'operazione.

Supponiamo che le policy di autorizzazione permettano al sito A di poter effettuare operazioni nel sito B e C ma il sito B e C possano effettuare operazioni solo su loro stessi.

L'autenticazione e autorizzazione delegata si basa su un repository autoritativo diverso dal repository degli utenti. Per poter utilizzare e modificare il repository delegato è sufficiente utilizzare l'interfaccia web avendone l'autorizzazione come utente root.

Riassumendo il repository di autenticazione delegata deve avere al suo interno un unico utente che è stato definito come primario. L'utente primario verrà utilizzato dal programma "client", cioè colui che richiede di fare una operazione remota, proponendo le sue credenziali. Il programma "server", cioè l'obiettivo del comando, dovrà avere un utente con le stesse credenziali (login e password). Il programma "server" non deve necessariamente avere lo stesso utente dichiarato primario, ma deve contenerlo nella propria lista di utenti delegati.

In questo caso l'azione delegata del nodo A può essere effettuata verso il nodo B in quanto B contiene un utente con stesso login e password anche se in B non è primario. Il nodo B non può eseguire nessuna azione delegata verso il nodo A in quanto pur contenendo il login "delegated" con credenziali uguali al nodo A, B effettuerà una azione verso il nodo A esponendo le sue credenziali con il login "primaryB" che non è presente nel nodo A e che quindi rifiuterà l'operazione.

La tecnica è molto semplice e per questo molto efficace. Questa tecnica permette anche, in situazioni dove non è necessaria una stringente policy di sicurezza, di effettuare con poche impostazioni delle configurazioni auto consistenti.

Se torniamo al nostro esempio iniziale e lo implementiamo completamente di seguito un possibile schema autoritativo.

Con questo schema autoritativo il solo sita A è in grado di fare operazioni cross site mentre i site B e C possono effettuare solamente operazioni al loro interno. Se in un secondo momento volessimo abilitare delle operazioni tra il site C ed il site B l'operazione risulterà semplicissima aggiungendo al site B l'utente primaryC.

Conclusioni

Le tecnologie Oplon Autonomous Delegated Authentication permettono una sicurezza mai ottenuta prima con semplicità e tracciabilità delle operazioni.