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 — le violazioni vengono registrate nel giornale di audit prima ancora di alzare il livello, se l'audit è attivo. 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.

*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 l'autorità adottata non si propaga automaticamente ai programmi chiamati, a meno che non lo si chieda con USEADPAUT(*YES).

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 DATE - 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, DSPUSRPRF, CHGDLTPRF 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 esattamente come la vista. È 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