Exit point: verificare chi controlla gli accessi da rete

Rivista il

Accedi per salvare

Le interfacce di rete — FTP, ODBC, JDBC, trasferimento dati ACS, condivisione file, DDM — accedono al database senza attraversare i menu applicativi. Il perimetro effettivo per quelle connessioni è quindi il diritto sugli oggetti, che sui sistemi non revisionati è più ampio di quanto risulti da una decisione.

Gli exit point sono il punto in cui quel perimetro può essere ristretto in modo indipendente dai diritti. In assenza di un programma registrato, la richiesta viene sempre accolta.

Cinque strade arrivano al database. Solo quella del 5250 attraversa il menu applicativo; ODBC, JDBC, FTP, trasferimento dati e DDM lo scavalcano. Tutte passano dall'exit point e poi dal diritto sugli oggetti.

Verificare cosa è registrato

SELECT EXIT_POINT_NAME, EXIT_POINT_FORMAT, EXIT_PROGRAM,
       EXIT_PROGRAM_LIBRARY, EXIT_PROGRAM_NUMBER
  FROM QSYS2.EXIT_PROGRAM_INFO
 ORDER BY EXIT_POINT_NAME;

Se non ci sono righe relative a QIBM_QZDA* e QIBM_QTMF*, per quelle interfacce non esiste alcun controllo oltre al diritto sugli oggetti.

I punti disponibili per le due famiglie rilevanti:

SELECT EXIT_POINT_NAME, EXIT_POINT_FORMAT, TEXT_DESCRIPTION
  FROM QSYS2.EXIT_POINT_INFO
 WHERE EXIT_POINT_NAME LIKE 'QIBM_QZDA%'
    OR EXIT_POINT_NAME LIKE 'QIBM_QTMF%'
 ORDER BY EXIT_POINT_NAME;

QIBM_QZDA* copre l'accesso al database: ODBC, JDBC, trasferimento dati. QIBM_QTMF* copre FTP. I punti di queste due famiglie sono questi:

Exit point Copre
QIBM_QZDA_INIT apertura della connessione al database
QIBM_QZDA_SQL1, QIBM_QZDA_SQL2 istruzioni SQL
QIBM_QZDA_NDB1 accesso nativo al database
QIBM_QZDA_ROI1 richieste di informazioni sugli oggetti
QIBM_QTMF_SVR_LOGON collegamento al server FTP
QIBM_QTMF_SERVER_REQ singola richiesta al server FTP
QIBM_QTMF_CLIENT_REQ richieste del client FTP

La query ne restituisce più righe che punti, perché lo stesso exit point compare una volta per formato, e il formato determina quali informazioni riceve il programma. QIBM_QTMF_SVR_LOGON ne ha tre, e la scelta non è indifferente: i formati più recenti passano dati che i precedenti non hanno.

I due punti a livello di connessione

QIBM_QZDA_INIT viene richiamato all'apertura della connessione al database, prima che sia nota la richiesta. QIBM_QTMF_SVR_LOGON ha la stessa funzione per FTP, con tre formati disponibili.

Gli altri QIBM_QZDA* agiscono più a valle: SQL1 e SQL2 sulle istruzioni SQL, NDB1 sull'accesso nativo al database, ROI1 sulle richieste di informazioni sugli oggetti.

Agiscono sulla sessione e non sulla singola operazione: un controllo in questi due punti vale per tutto ciò che segue, con un impatto sulle prestazioni indipendente dal volume delle richieste. I punti per singolo comando o singola istruzione SQL consentono un controllo più fine, con un costo per operazione.

Rilevare prima di filtrare

Un programma che blocca sulla base di regole non verificate interrompe integrazioni non censite: interfacce verso il gestionale, estrazioni schedulate, procedure di terzi.

Il primo programma da registrare non applica regole: restituisce sempre l'autorizzazione e scrive un record con profilo, indirizzo di origine, funzione richiesta e orario. Dopo un ciclo completo di attività quel file contiene l'elenco documentato degli utilizzi effettivi, che è il presupposto per definire le regole.

È lo stesso approccio della raccolta delle autorizzazioni per i diritti sugli oggetti: la misura precede la restrizione.

Esempio: cosa restituisce la verifica, e cosa se ne ricava

Gli esiti che seguono sono illustrativi, servono a mostrare la forma del dato.

Su un sistema mai revisionato, la prima query restituisce tipicamente poche righe e nessuna sulle famiglie che interessano:

EXIT_POINT_NAME      EXIT_POINT_FORMAT  EXIT_PROGRAM  EXIT_PROGRAM_LIBRARY
QIBM_QCA_CHG_COMMAND CHGC0100           MONCMD        TOOLLIB

Nessuna riga QIBM_QZDA* né QIBM_QTMF*: per ODBC e per FTP non esiste alcun controllo oltre al diritto sugli oggetti.

Dopo un mese di sola registrazione su QIBM_QZDA_INIT, il file di raccolta contiene qualcosa di questo genere, aggregato per profilo e origine:

PROFILO    ORIGINE          CONNESSIONI  PRIMA        ULTIMA
GESTIONALE 10.0.4.12                812  02/07 06:00  01/08 06:00
MROSSI     10.0.7.44                 47  03/07 09:12  31/07 17:40
UTE0147    10.0.9.201                 6  05/07 02:15  30/07 02:15
BACKUPSRV  192.168.50.9               4  06/07 23:00  27/07 23:00

Le quattro righe si leggono in modo diverso l'una dall'altra. GESTIONALE da un solo indirizzo, con cadenza giornaliera all'alba, è un'integrazione schedulata: bloccarla fermerebbe un'elaborazione. MROSSI in orario d'ufficio è una persona che usa un foglio di calcolo. UTE0147 alle 2 di notte e BACKUPSRV da una rete diversa sono le due righe da cui parte l'analisi, perché nessuno le aveva censite.

Il valore della registrazione preventiva sta qui: le prime due righe sono le regole da scrivere, le ultime due sono le domande da porre, e senza un mese di dati sarebbero state entrambe bloccate o entrambe lasciate passare.

Prodotti di mercato

Esistono soluzioni commerciali che coprono registrazione, regole per gruppo, reportistica e segnalazioni. In presenza di obblighi normativi o di verifiche periodiche la voce di valore non è il filtro in sé ma la reportistica e la manutenzione del prodotto nel tempo.

In assenza di quegli obblighi, un programma di sola registrazione sviluppato internamente risponde alla domanda che conta (quali profili accedono da rete e con quale interfaccia) con un impegno limitato.

Il controllo che precede tutto

Prima di progettare un filtro va verificato se il servizio è necessario. Un server FTP attivo su un sistema che non lo utilizza si disattiva anziché regolamentarlo:

NETSTAT OPTION(*CNN)
WRKACTJOB SBS(QSYSWRK)

Per FTP, la disattivazione e l'esclusione dall'avvio automatico:

ENDTCPSVR SERVER(*FTP)
CHGFTPA AUTOSTART(*NO)

La stessa verifica va fatta per gli altri server TCP attivi ma non utilizzati.

Su quali versioni funziona

Gli exit point precedono i servizi SQL. Le viste QSYS2.EXIT_POINT_INFO e QSYS2.EXIT_PROGRAM_INFO sono arrivate con IBM i 7.4 TR3 e 7.3 TR9. In precedenza le stesse informazioni erano accessibili con WRKREGINF, non interrogabile via SQL.

Fonti

← Torna al blog

Commenti

Nessun commento ancora. Sii il primo a commentare!

Devi avere un account per commentare. Accedi · Registrati