2 Installazione sicura

In questa sezione viene descritto il processo di pianificazione e implementazione per un'installazione e una configurazione sicure e vengono illustrate topologie di distribuzione consigliate per ACSLS.

Informazioni sull'ambiente

Per comprendere meglio le esigenze di sicurezza, è necessario rispondere alle domande riportate di seguito.

Quali risorse è necessario proteggere?

Le risorse chiave gestite da ACSLS sono librerie a nastro, unità e cartucce. Tali risorse devono essere protette da accessi accidentali o dannosi. È possibile, ad esempio, impedire alle persone di accedere per errore a un server ACSLS diverso da quello desiderato utilizzando password diverse per gli ID utente ACSLS su server diversi.

Da chi è necessario proteggere le risorse?

È possibile proteggere le risorse di storage su nastro dall'accesso non autorizzato sia interno che esterno.

Cosa accade in caso di mancata protezione delle risorse strategiche?

ACSLS può installare le cartucce nelle unità nastro. Se un utente riesce a collegarsi all'unità nastro tramite il percorso dati, potrà leggere i dati sul nastro, se non sono cifrati.

Gli utenti che possono accedere sia ad ACSLS che a una libreria a nastro possono inserire ed espellere le cartucce da una libreria a nastro.

Procedura consigliata per la protezione di ACSLS

Quando si protegge ACSLS e i componenti dell'infrastruttura necessari, seguire questa procedura per accertarsi che ACSLS continui a funzionare dopo avere apportato le modifiche.

• Installare ACSLS.

• Verificare che ACSLS funzioni correttamente. Includere configurazione e controllo delle librerie, installazione e disinstallazione di nastri, inserimento ed espulsione di nastri, nonché backup e ripristino del database.

• Implementare le modifiche per aumentare la sicurezza.

• Verificare che ACSLS funzioni ancora correttamente.

Protezione della comunicazione via Internet di ACSLS

In questa sezione vengono forniti consigli per la distribuzione di ACSLS per un accesso a Internet sicuro.

Protezione di ACSLS e delle librerie a nastro tramite un firewall aziendale

ACSLS e le librerie a nastro che supporta devono essere distribuiti tramite il firewall aziendale. Le persone che lavorano in remoto possono effettuare il login al server ACSLS tramite una VPN.

Nota:

Se si dispone di un firewall perimetrale basato su IPv4, è necessario configurarlo in modo che escluda tutti i pacchetti IPv4 del protocollo 41 in uscita e i pacchetti UDP della porta 3544 per impedire agli host Internet di utilizzare il traffico in tunnelling IPv6 su IPv4 per raggiungere gli host interni.

Opzione di sicurezza del firewall ACSLS

Se le applicazioni client, che utilizzano ACSLS per l'installazione dei nastri e la gestione delle librerie a nastro, sono separate da ACSLS tramite un firewall, è consigliabile abilitare l'opzione di sicurezza del firewall. Anche se le applicazioni client non sono separate da ACSLS tramite un firewall, l'implementazione dell'opzione di sicurezza del firewall offre ulteriore sicurezza ACSLS limitando le porte utilizzate per la comunicazione tra ACSLS e le relative applicazioni client, come mostrato di seguito. Per questi motivi, in ACSLS 8.1 e release successive la variabile statica CSI_FIREWALL_SECURE viene impostata automaticamente su TRUE.

Per informazioni dettagliate, consultare l'appendice ”Firewall Security Option” nel manuale ACSLS Administrator’s Guide.

Porte Ethernet utilizzate per la comunicazione con ACSLS

• Le porte indicate di seguito vengono utilizzate nel server ACSLS. Assicurarsi che tutti i firewall siano configurati in modo da consentire il traffico su queste porte. Sono inclusi i firewall implementati da ipfilter su Solaris o iptables su Linux.

  • 22: utilizzata in entrambe le direzioni per l'accesso tramite ssh.

  • 111: portmapper, a meno che portmapper non sia stato disabilitato.

  • 115: utilizzata per SFTP (Secure File Transfer Protocol).

  • 161: porta predefinita per l'agente SNMP di ACSLS - preparazione/configurazione/funzionamento.

  • 162: porta predefinita per l'agente SNMP di ACSLS - trap.

    Nota:

    Le porte utilizzate dall'agente SNMP di ACSLS sono configurabili tramite il comando: AcslsAgtdSnmpConf [ -p port ] [-t trap port] [-d]. L'opzione -d visualizza l'impostazione corrente. Dopo avere modificato l'impostazione della porta, è necessario riavviare l'agente con il comando agentRegister.

  • La porta predefinita 5432 per la comunicazione interna da ACSLS al database PostgreSQL (la variabile di ambiente PGPORT per l'ID utente acsss).

    Se la porta 5432 è occupata, viene utilizzato il successivo numero di porta superiore disponibile.

    Nota:

    La porta 5432 deve essere accessibile solo dall'IP localhost (127.0.0.1).

  • 7001 e 7002: utilizzata da WebLogic e dalla GUI di ACSLS.

  • 30031 o la porta di ascolto del CSI di ACSLS, impostata da CSI_INET_PORT.

  • 50003: porta utilizzata per la comunicazione interna dalla GUI di ACSLS e dai componenti Java all'elaborazione ACSLS precedente. Non è configurabile.

• Affinché le applicazioni client possano comunicare con ACSLS tramite ACSAPI, è necessario che le porte indicate di seguito siano aperte.

  • L'applicazione client deve comunicare con la porta di ascolto del CSI di ACSLS. Viene impostata automaticamente la porta predefinita 30031 tramite la variabile statica CSI_INET_PORT.

    È possibile scoprire le porte utilizzate da ACSLS per l'ascolto delle richieste dei client ACSAPI con il seguente comando della shell Unix:

    rpcinfo -p | egrep "300031 | 536871166"

    Gli ID delle porte vengono elencati nell'ultimo campo visualizzato.

  • Il client ACSAPI (ad esempio, un server NetBackup o SAM-QFS) imposta la propria porta in entrata fissa utilizzando la variabile di ambiente SSI_INET_PORT. Specificare una porta compresa tra 1024 e 65535, escludendo le porte 50001 e 50004. È necessario che il server ACSLS possa comunicare con questa porta.

    Nota:

    In un server client ACSAPI le porte 50001 e 50004 vengono utilizzate per la comunicazione IPC del dominio AF_INET con il mini-Logger eventi e dalle applicazioni client all'SSI.

  Per maggiori dettagli sulla comunicazione tra le applicazioni client e ACSLS, consultare l'appendice sull'opzione di sicurezza del firewall nel manuale ACSLS Administrator’s Guide.

• Se è installato il componente XAPI, il server XAPI utilizza una porta di ascolto fissa per ricevere le richieste TCP in ingresso dai client ELS. La porta di ascolto XAPI è definita dalla variabile statica XAPI_PORT. Il valore predefinito di XAPI_PORT è 50020. Il valore deve essere compreso tra 1024 e 65535 e non può essere in conflitto con alcuna altra porta utilizzata da ACSLS o da altre applicazioni.

  Per maggiori dettagli sulla variabile XAPI_PORT, consultare l'appendice sull'interfaccia client di XAPI Client nel manuale ACSLS Adiminstrator’s Guide. Questa appendice contiene anche dettagli su come visualizzare e impostare la variabile statica XAPI_PORT.

• Porte che devono essere aperte in una libreria SL8500 o SL3000:

  ACSLS comunica con queste porte sulle connessioni Ethernet 2A e 2B di una libreria SL8500 o SL3000. Se la comunicazione da ACSLS a queste porte è bloccata, ACSLS non può gestire la libreria.

  • 50001: utilizzata per tutte le normali comunicazioni tra ACSLS e la libreria.

  • 50002: utilizzata da ACSLS HA per determinare se il nodo HA alternativo può comunicare con la libreria prima del failover del nodo alternativo.

Configurazione dei firewall sul server ACSLS

Oltre ai firewall esterni, la protezione del firewall può essere implementata sul server ACSLS tramite ipfilter su Solaris o tramite iptables su Linux. Di seguito viene descritto come gestire tali firewall in esecuzione sul server ACSLS.

• Gestione di ipfilter su Solaris:

  Per informazioni dettagliate, consultare le pagine man per ipf e ipfilter.

  • Il firewall ipfilter viene abilitato (disabilitato) dall'utente 'root' mediante il comando:

    svcadm enable ipfilter (svcadm disable ipfilter)

  • Per apprendere lo stato corrente di ipfilter:

    svcs ipfilter

  • I criteri del firewall sono definiti nel file: /etc/ipf/ipf.conf

    Per consentire una comunicazione libera tra i componenti nell'host locale (ad esempio, tra ACSLS e WebLogic o tra la GUI e il database ACSLS), includere un'istruzione come la seguente:

    pass in quick from 127.0.0.1 to 127.0.0.1

    oppure

    pass in quick from 127.0.0.1 to all

    È necessario definire criteri che consentano l'accesso a tutte le porte necessarie per ACSLS. Per includere un criterio che consenta ai browser remoti basati sul Web di accedere alla GUI di ACSLS, ad esempio, è necessario aprire le porte 7001 e 7002.

    pass in quick from any to any port = 7001

    pass in quick from any to any port = 7002

    Dopo avere rilevato le porte utilizzate da ACSLS per l'ascolto delle richieste dei client ACSAPI, aggiungere le istruzioni 'pass in quick' per ciascuna di queste porte.

    Potrebbe essere necessario includere un'istruzione 'pass in quick' per la porta portmapper RPC 111.

    L'ultima istruzione nel set di regole proposto, "block in from any", afferma che nessun traffico deve raggiungere l'host, a meno che non sia stato consentito in modo specifico nelle istruzioni precedenti.

• Gestione di iptables su Linux:

  • Il firewall iptables viene abilitato (disabilitato) dall'utente 'root' mediante il comando:

    service iptables start (service iptables stop)

  • Per controllare lo stato di iptables:

    service iptables status

  • Il file dei criteri per iptables è /etc/sysconfig/iptables:

    È necessario definire criteri che consentano l'accesso a tutte le porte necessarie per ACSLS. Per includere un criterio che consenta l'accesso remoto tramite http/https alla GUI di ACSLS, ad esempio, è necessario aggiornare tale file in modo che includa le eccezioni per le porte 7001 e 7002 utilizzando istruzioni simili alle seguenti:

    -A input -p tcp --dport 7001 -j ACCEPT

    -A input -p tcp --dport 7002 -j ACCEPT

    Dopo avere rilevato le porte utilizzate da ACSLS per l'ascolto delle richieste dei client ACSAPI, è necessario aggiungere le eccezioni per ciascuno dei file dei criteri di iptables. Potrebbe essere necessario includere un'istruzione di eccezione per la porta portmapper RPC 111.

Installazione e configurazione di Solaris

In questa sezione viene descritto come installare e configurare Solaris in modo sicuro.

Di seguito sono riportati alcuni suggerimenti.

• Applicare tutte le patch di sicurezza significative al sistema operativo e ai servizi installati con il sistema operativo. Applicare tali patch in modo selettivo, in quanto l'applicazione di tutti gli aggiornamenti disponibili potrebbe determinare l'installazione di nuove funzioni e anche di nuove release del sistema operativo non testate con ACSLS e ACSLS HA.

• Disabilitare telnet e rlogin. Utilizzare piuttosto ssh. Disabilitare anche ftp e utilizzare sftp.

  Disabilitare i servizi telnet, rlogin e ftp emettendo i comandi indicati di seguito come utente root.

  Per visualizzare tutti i servizi:

  svcs

  Per disabilitare telnet, rlogin e ftp:

  svcadm disable telnet

  svcadm disable rlogin

  svcadm disable ftp

• Non disabilitare ssh. Si desidera che gli utenti effettuino il login in remoto ad ACSLS utilizzando ssh e non telnet o rlogin. Non disabilitare sftp.

• ACSLS richiede rpc-bind. Non disabilitarlo.

  Se Solaris è installato con l'opzione di protezione predefinita, è necessario modificare la proprietà di configurazione di una rete per rpc-bind per consentire ai client ACSAPI di inviare richieste ad ACSLS.

  Per informazioni dettagliate, consultare la sezione "Installing Solaris" nel capitolo "Installing ACSLS on Solaris" del manuale ACSLS Installation manual.

• Per la comunicazione con ACSLS, è necessario che alcune porte Ethernet sul server ACSLS siano aperte. Le applicazioni client utilizzano porte Ethernet specifiche per la comunicazione con ACSLS e ACSLS comunica con porte specifiche sulle librerie a nastro. Per informazioni sulle porte che devono essere disponibili per la comunicazione con ACSLS, vedere Porte Ethernet utilizzate per la comunicazione con ACSLS. Sul server ACSLS accertarsi che ipfilter sia configurato in modo da consentire il traffico alle porte utilizzate da ACSLS.

Determinare i criteri di controllo di Solaris. Per informazioni su quali eventi pianificare per il controllo, dove salvare i log di controllo e come esaminarli, consultare la sezione ”Auditing in Oracle Solaris” in "Oracle System Administration: Security Services".

Installazione e configurazione di Linux

Di seguito sono riportati alcuni suggerimenti per l'installazione e la configurazione sicure di Linux.

• Applicare tutte le patch di sicurezza significative al sistema operativo e ai servizi installati con il sistema operativo. Applicare tali patch in modo selettivo, in quanto l'applicazione di tutti gli aggiornamenti disponibili potrebbe determinare l'installazione di nuove funzioni e anche di nuove release del sistema operativo non testate con ACSLS e ACSLS HA.

• Assicurarsi che telnet e rlogin non siano installati o disabilitati. Utilizzare piuttosto ssh.

  Assicurarsi anche che ftp non sia installato o disabilitato e utilizzare sftp.

  Per visualizzare tutti i servizi, effettuare il login come utente root e immettere:

  service –-status-all

• Per eliminare definitivamente i servizi, utilizzare:

  svccfg delete -f service-name

• Non disabilitare ssh. Si desidera che gli utenti effettuino il login in remoto ad ACSLS utilizzando ssh, non telnet né rlogin. Non disabilitare sftp.

• Per consentire la comunicazione con il client ACSLS, è necessario che i servizi di rete siano abilitati, in particolare rpcbind.

  Quando si avvia rpc su Linux, utilizzare il flag –i.

• Per la comunicazione con ACSLS, è necessario che alcune porte Ethernet sul server ACSLS siano aperte. Le applicazioni client utilizzano porte Ethernet specifiche per la comunicazione con ACSLS e ACSLS comunica con porte specifiche sulle librerie a nastro. Per informazioni sulle porte che devono essere disponibili per la comunicazione con ACSLS, vedere Porte Ethernet utilizzate per la comunicazione con ACSLS. Sul server ACSLS accertarsi che iptables sia configurato in modo da consentire il traffico alle porte utilizzate da ACSLS.

Controllo della sicurezza di Linux

Determinare i criteri di controllo di Linux. Per informazioni su quali eventi pianificare per il controllo, dove salvare i log di controllo e come esaminarli, consultare la sezione ”Configuring and Using Auditing” section in Oracle Linux: Security Guide for Release 6.

Di seguito sono riportati alcuni log e comandi utili per il controllo della sicurezza di Linux.

• Visualizzare var/log/secure come utente root per controllare la cronologia dei tentativi di login e altri messaggi correlati all'accesso.

• Il comando 'last | more' fornisce una cronologia degli utenti che hanno eseguito il login.

• In /var/log/audit/audit.log.[0-9] viene salvato un log dei tentativi di accesso negati da SE Linux. Per visualizzare questi dati è necessario accedere come utente root.

Sicurezza SELinux

ACSLS 8.4 è progettato per essere eseguito in ambienti Security Enhanced Linux opzionali. SELinux fornisce il controllo dell'accesso a file, directory e altre risorse di sistema che non rientrano nello standard di protezione tradizionale disponibile negli ambienti Unix. Oltre all'accesso su autorizzazione del proprietario/del gruppo/pubblica, SELinux include il controllo dell'accesso basato su ruolo, dominio e contesto dell'utente. L'agente che applica il controllo dell'accesso su tutte le risorse di sistema è il kernel Linux.

L'utente root in un sistema Linux può attivare o disattivare l'applicazione mediante il comando setenforce.

setenforce [Enforcing | Permissive | 1 | 0 ]

Utilizzare Enforcing o 1 per impostare SELinux in modalità di applicazione. Utilizzare Permissive o 0 per impostare SELinux in modalità permissiva.

Per visualizzare lo stato di applicazione del sistema corrente, utilizzare il comando getenforce.

Quando si installa ACSLS, nel kernel vengono caricati tre moduli di criteri SELinux: allowPostgr, acsdb e acsdb1. Questi moduli offrono le definizioni e le eccezioni di applicazione necessarie affinché ACSLS acceda ai propri database e ad altre risorse di sistema mentre l'applicazione di SELinux è attiva. Con questi moduli installati, è possibile eseguire le normali operazioni di ACSLS, incluse le operazioni di database, come bdb.acsss, rdb.acsss, db_export.sh e db_import.sh senza dover disabilitare l'applicazione di SELinux.

Per ulteriori informazioni, consultare la sezione su SELinux nell'Appendice ”Troubleshooting” del manuale StorageTek ACSLS 8.4 Administrator’s Guide.

Installazione e configurazione di ACSLS

In questa sezione viene descritto come installare ACSLS in sicurezza.

Esecuzione di un'installazione di ACSLS standard

L'esecuzione di un'installazione di ACSLS standard garantisce la disponibilità di tutti i componenti necessari.

Se si esegue la migrazione a una release di ACSLS successiva da una release di ACSLS precedente, analizzare le impostazioni per le variabili dinamiche e statiche per verificare se si desidera utilizzare più opzioni sicure, in particolare per quanto riguarda l'opzione di sicurezza del firewall.

Uso di password sicure per gli ID utente di ACSLS

ACSLS richiede gli ID utente di ACSLS acsss, acssa e acsdb. Scegliere password sicure per questi ID e modificarle a intervalli regolari.

Limitazione dell'accesso ai file di ACSLS

In genere l'accesso ai file di ACSLS è limitato al solo gruppo acsls, che include gli ID utente acsss, acssa, acsdb e root. Alcuni file diagnostici e di database sono accessibili solo da un singolo ID utente acsls. ACSLS viene eseguito con umask impostato su 027.

L'accesso pubblico ai file di ACSLS non deve essere disponibile né in lettura né in scrittura. La limitazione dell'accesso oltre le impostazioni predefinite dell'installazione, tuttavia, può causare il malfunzionamento delle funzioni di ACSLS.

Impostazione di ’root’ come ID utente effettivo per i tre file di ACSLS

Lo script di installazione avvisa i clienti che è necessario impostare l'ID utente effettivo di 'root' (setuid) in tre file eseguibili nel file system /export/home/ACSSS:

• acsss (questo file binario deve essere eseguito con privilegi 'root' in quanto viene utilizzato per l'avvio e l'arresto dei servizi di sistema richiesti dall'applicazione ACSLS).

• db_command (questo file binario avvia e arresta il motore di database PostgreSQL che controlla e gestisce il database ACSLS).

• get_diags (questo file binario viene richiamato da un cliente per raccogliere le informazioni diagnostiche complete sul sistema che possono essere necessarie durante una chiamata al servizio di assistenza).

Durante l'installazione di ACSLS con pkgadd, ai clienti viene chiesto se desiderano Installare i file come setuid/setgid. Se si risponde y al prompt, si consente agli utenti nel gruppo acsls di eseguire questi tre comandi, anche se le utility eseguono determinate operazioni di sistema che richiedono privilegi root.

Analisi delle impostazioni per le variabili statiche e dinamiche di ACSLS

Le variabili statiche e dinamiche di ACSLS controllano il comportamento di molte funzioni di ACSLS. Impostare queste variabili utilizzando la utility acsss_config. Proteggere le impostazioni per molte di queste variabili come indicato nel presente documento. Quando le opzioni per una variabile sono presentate da acsss_config, se si risponde con un punto di domanda (?), viene visualizzata una spiegazione dettagliata della variabile. Queste informazioni sono disponibili anche nel capitolo ”Setting Variables that Control ACSLS Behavior” del manuale ACSLS Administrator’s Guide.

Configurazione di WebLogic

ACSLS 8.1 e release successive utilizza WebLogic per il server Web. WebLogic viene installato con ACSLS.

Per informazioni sulle opzioni di protezione di un server WebLogic e sulle possibilità di audit trail con WebLogic, consultare Oracle Fusion Middleware; Understanding Security for Oracle WebLogic Server 11g Release 1 (10.3.6).

Uso della utility userAdmin.sh di ACSLS per creare e gestire gli utenti della GUI di ACSLS

La utility basata sui menu userAdmin.sh consente di amministrare le password degli utenti della GUI di ACSLS. È possibile aggiungere, rimuovere ed elencare gli utenti, nonché modificarne le password. Per usufruire di questa utility, è necessario che WebLogic sia in esecuzione. In caso contrario, questa utility avvia WebLogic e verifica che sia online prima di visualizzare il menu.

La utility userAdmin.sh deve essere eseguita dall'utente root e richiede l'autenticazione acsls_admin. L'account utente acsls_admin viene configurato durante l'installazione di ACSLS.

Uso della GUI di ACSLS

Per utilizzare la GUI di ACSLS, è necessario installare l'ultima versione di JRE e accedere alla GUI tramite un browser.

Installazione dell'ultima versione di JRE sui sistemi client della GUI

Accertarsi che sui sistemi che dovranno utilizzare la GUI per accedere ad ACSLS sia installato Java Runtime Environment (JRE).

Accesso alla GUI di ACSLS

Aprire un browser e immettere un URL con il nome host o l'indirizzo IP del server nel seguente formato:

https://myAcslsHostName.myDomainName:7002/SlimGUI/faces/Slim.jsp oppure https://127.99.99.99:7002/SlimGUI/faces/Slim.jsp

È preferibile utilizzare il nome host completo o l'indirizzo IP del computer host. Se WebLogic non riesce a risolvere completamente l'URL, è possibile che alcune pagine, incluse le pagine della Guida di ACSLS, non vengano visualizzate correttamente.

Se si utilizza http con la porta 7001, WebLogic reindirizza automaticamente su https sulla porta 7002.

Poiché WebLogic utilizza il protocollo sicuro https, è possibile che il browser visualizzi un avviso che indica che il certificato di sicurezza del sito non è stato registrato e pertanto non è sicuro. Se si è certi che l'URL corrisponde a quello del computer ACSLS locale, è possibile continuare in sicurezza. A questo punto, dovrebbe essere visualizzata la schermata di login.

Uso della GUI di ACSLS

L'accesso a AcslsDomain in WebLogic viene eseguito utilizzando il protocollo di sicurezza, https. Questo protocollo utilizza la comunicazione cifrata tra browser e server con chiavi private e certificati digitali. Di seguito sono riportate le opzioni per ottenere un certificato digitale.

Certificato demo ACSLS

ACSLS include un cosiddetto certificato 'demo'. Tale certificato offre un livello minimo di sicurezza di cifratura e consente agli utenti di iniziare a utilizzare l'interfaccia GUI di ACSLS senza dover eseguire ulteriori operazioni di configurazione. Nei casi in cui l'interazione del cliente con la libreria ACSLS si svolge interamente in una intranet protetta, questo metodo di certificazione demo è in genere sufficiente. Questo metodo, tuttavia, utilizza una chiave di cifratura a 512 bit non supportata in alcuni browser, in particolare Internet Explorer e FireFox Versione 39 e successive.

Configurazione di un certificato digitale autofirmato

Il manuale ACSLS Installation Guide offre agli amministratori ACSLS un metodo dettagliato per configurare un certificato digitale autofirmato della lunghezza di 2048 bit. Nella sezione 'Configuring an SSL Encryption Key', questo metodo offre un certificato supportato su tutti i browser. Si consiglia agli utenti che accedono a un sito https con un certificato autofirmato di non procedere nell'esplorazione del sito se non si è personalmente certi della sicurezza della risorsa Web. Nel contesto degli utenti ACSLS e del server di controllo della libreria, questo livello di sicurezza è in genere ben noto e, nella maggior parte dei casi, non è necessario ottenere una prova dell'integrità del sito tramite la verifica della firma di terze parti.

Certificati digitali firmati da un'apposita autorità di terze parti

È responsabilità dell'utente stabilire per ciascun sito se è necessario fornire l'autenticazione del certificato mediante un'autorità di firma di terze parti come Verisign o Entrust.net. La procedura di generazione di un certificato digitale firmato di questo tipo è descritta nel documento online di Oracle, Configuring Identity and Trust all'indirizzo:

http://docs.oracle.com/cd/E13222_01/wls/docs92/secmanage/identity_trust.html

Installazione di ACSLS HA

Se si utilizza la soluzione High Availability di ACSLS, seguire le istruzioni nel cluster ACSLS-HA per l'installazione, la configurazione e l'uso.