Sicurezza degli oggetti su IBM i

La sicurezza su IBM i è disegnata bene: è il sistema operativo stesso a controllare gli accessi agli oggetti, non l'applicazione. Il problema è che molte installazioni la aggirano, e lo fanno per un motivo comprensibile: un programma non funzionava, si è dato *ALLOBJ all'utente, ha funzionato, e nessuno ci è più tornato.

Da dove si parte: QSECURITY

DSPSYSVAL SYSVAL(QSECURITY)

I valori che si incontrano:

• 20 — chi entra ha di fatto accesso a tutto. Da considerare come "nessuna sicurezza".
• 30 — controllo sulle autorizzazioni agli oggetti. È il minimo ragionevole.
• 40 — come 30, più la protezione dell'integrità: i programmi non possono aggirare le interfacce di sistema. È il valore consigliato da IBM e quello su cui gira la maggior parte delle installazioni sane.
• 50 — 40 con controlli aggiuntivi, per ambienti che devono rispettare requisiti particolarmente severi.

Il passaggio da 30 a 40 va preparato: alcuni programmi vecchi usano tecniche che al livello 40 non sono più ammesse. Il sistema però lo dice in anticipo: si attiva l'audit con almeno *AUTFAIL e *PGMFAIL in QAUDLVL, si fanno girare le applicazioni al livello 30 e si guardano nel giornale le voci AF. Si alza il livello dopo aver guardato quel registro per qualche settimana, non prima.

Chi ha le chiavi di tutto

Questa query risponde alla domanda più importante:

SELECT AUTHORIZATION_NAME, STATUS, SPECIAL_AUTHORITIES
  FROM QSYS2.USER_INFO
 WHERE SPECIAL_AUTHORITIES LIKE '%*ALLOBJ%'
 ORDER BY AUTHORIZATION_NAME;

L'elenco che esce è quasi sempre più lungo del previsto, e contiene tipicamente tre categorie: le utenze di servizio create anni fa, gli utenti che hanno avuto *ALLOBJ per risolvere un problema momentaneo, e i profili di gruppo che lo propagano a tutti i loro membri. La query vede i diritti scritti nel profilo, non quelli che arrivano dal gruppo: un utente in un gruppo con *ALLOBJ lo usa lo stesso. Chi fa parte di un gruppo si legge in GROUP_PROFILE_NAME e SUPPLEMENTAL_GROUP_LIST.

*ALLOBJ non è l'unica autorizzazione speciale che conta: *SECADM permette di gestire i profili utente, *JOBCTL di intervenire sui job altrui, *SPLCTL di vedere tutti gli spool — compresi quelli con le buste paga.

*PUBLIC: l'impostazione che decide tutto

Ogni oggetto ha un'autorizzazione pubblica, cioè quella che vale per chiunque non abbia diritti specifici. Il valore predefinito viene dalla libreria in cui l'oggetto viene creato, e su molte installazioni è *CHANGE: chiunque può modificare i dati.

DSPOBJAUT OBJ(MIALIB/CLIENTI) OBJTYPE(*FILE)

Il modello consigliato è l'opposto: *PUBLIC *EXCLUDE sui dati, e l'accesso concesso non direttamente agli utenti, ma ai programmi.

L'autorità adottata: la chiave del modello

È il meccanismo che permette di togliere i diritti agli utenti senza rompere le applicazioni. Un programma compilato così:

CRTBNDRPG PGM(MIALIB/AGGCLI)
          USRPRF(*OWNER)

viene eseguito con i diritti del proprietario del programma, non di chi lo lancia. Se il proprietario è un profilo che può scrivere sul file clienti, il programma può scrivere anche se l'utente, da solo, non potrebbe.

Il risultato è quello giusto: l'utente può modificare i dati solo passando dai programmi previsti. Se prova ad aprire lo stesso file con un download o con una query, non ha i diritti. È esattamente la distinzione che *ALLOBJ cancella.

Due avvertenze: il programma va tenuto sotto controllo, perché chi può modificarlo può fare qualsiasi cosa il proprietario possa fare; e il diritto adottato resta attivo finché il programma è nella pila delle chiamate: i programmi che chiama lo usano a loro volta, salvo quelli creati con USEADPAUT(*NO). Un programma di un proprietario con *ALLOBJ da cui si arriva a una riga di comando dà *ALLOBJ a chi ci arriva.

Le liste di autorizzazione, per non impazzire

Concedere diritti oggetto per oggetto diventa ingestibile appena i file sono qualche decina. Una lista di autorizzazione è un contenitore di permessi a cui si agganciano più oggetti:

CRTAUTL AUTL(DATIPAGHE) TEXT('Accesso ai dati del personale')
GRTOBJAUT OBJ(MIALIB/PAGHE*) OBJTYPE(*FILE) AUTL(DATIPAGHE)

Da quel momento i permessi si gestiscono in un punto solo, e aggiungere una persona non richiede di ricordarsi tutti i file coinvolti.

Un percorso realistico per rientrare

Togliere *ALLOBJ a tutti da un giorno all'altro ferma l'azienda. Un percorso che funziona:

1. Attivare l'audit e lasciarlo raccogliere dati per qualche settimana. Serve a sapere chi accede davvero a cosa, invece di indovinarlo.
2. Partire da un'applicazione sola, la meno critica. Impostare *PUBLIC *EXCLUDE sui suoi file e USRPRF(*OWNER) sui suoi programmi.
3. Provare con un utente reale che non abbia *ALLOBJ. È qui che vengono a galla gli accessi non previsti: report, estrazioni, macro Excel che leggono i file direttamente.
4. Ripetere su un'applicazione per volta.
5. Togliere *ALLOBJ solo alla fine, e a un utente per volta.

Il passo 3 è quello che rivela la vera architettura del sistema, che quasi mai coincide con quella che si crede di avere.

Il controllo che vale la pena rifare ogni anno

SELECT AUTHORIZATION_NAME, STATUS, PREVIOUS_SIGNON,
       SPECIAL_AUTHORITIES
  FROM QSYS2.USER_INFO
 WHERE STATUS = '*ENABLED'
   AND (PREVIOUS_SIGNON < CURRENT TIMESTAMP - 6 MONTHS
        OR PREVIOUS_SIGNON IS NULL)
 ORDER BY PREVIOUS_SIGNON;

Profili abilitati che non entrano da sei mesi. Sono quasi sempre persone che non lavorano più lì, o utenze di servizio di applicazioni dismesse: il punto di ingresso più comodo che esista, perché nessuno si accorgerebbe del loro uso.

Su quali versioni funziona

Il modello di sicurezza — livelli QSECURITY, autorizzazioni agli oggetti, *PUBLIC, liste di autorizzazione, autorità adottata con USRPRF(*OWNER) — è stabile da moltissime release e funziona allo stesso modo su 7.3, 7.4, 7.5 e 7.6. I comandi EDTOBJAUT, GRTOBJAUT, RVKOBJAUT, CRTAUTL e DSPUSRPRF sono tutti storici.

QSYS2.USER_INFO — la vista SQL sui profili utente è una IBM i Service, quindi la sua disponibilità dipende dalla release e dal livello di PTF del database. Viene inoltre ampliata nel tempo: le colonne sull'autenticazione a più fattori, per esempio, sono aggiunte recenti. Se una colonna citata qui non esiste sulla tua macchina, è perché è arrivata dopo.

Prima che questa vista esistesse, lo stesso elenco si otteneva così:

DSPUSRPRF USRPRF(*ALL) TYPE(*BASIC)
          OUTPUT(*OUTFILE) OUTFILE(QTEMP/PROFILI)

Il file che ne risulta si interroga in SQL come una tabella qualunque, con nomi di colonna suoi. È il metodo che funziona su qualsiasi release, e resta utile anche oggi quando serve una fotografia da archiviare.

Le autorizzazioni speciali (*ALLOBJ, *SECADM, *JOBCTL, *SPLCTL) e il giornale di audit QAUDJRN con i valori QAUDCTL e QAUDLVL esistono da molto tempo; i singoli valori di QAUDLVL sono stati ampliati nel corso delle release.

Fonti

• Using System Security (QSecurity) system value — IBM Documentation 7.3
• QSYS2.USER_INFO — IBM Support
• DB2 for i Services — IBM Support