Indice

Struttura e sui moduli del sistema: concetti fondamentali
Servizi installati dai moduli del sistema di amministrazione
Dimensionamento di installazioni tipiche (<100 computer) e di installazioni medio-grandi (>100 computer)
Architetture possibili
Esempi pratici di architetture

Struttura e moduli del sistema

In questo documento si intende fornire una serie di informazioni necessarie per effettuare il dimensionamento di un'installazione tipica standard, tipica con componenti addizionali o personalizzata del sistema AdminSecure, con particolare riferimento a reti di estensione medio-grande, superiori ai 100 computer e topograficamente distribuite in più sedi.

Il sistema AdminSecure (nelle sue varie versioni commerciali e tecniche) può essere applicato a reti organizzate come

1. Dominii Windows NT / 2K
2. Contesti Novell Netware
3. Workgroups Windows
4. Reti Peer-to-peer o assimilabili (esempio, con uno o più domain controller e/o altri server in tecnologia diversa da Microsoft/Novell)
5. Reti ibride tra le tipologie precedenti.

Su reti di dimensioni inferiori ai 100 computer il sistema può essere installato in modalità tipica su un server NT / 2K o su una workstation NT / 2K / XP-pro (che a tutti gli effetti diviene il Server Antivirus). In una rete Peer-to-peer o assimilabile, il Server Antivirus sarà ovviamente una workstation. E' sconsigliabile adibire una workstation a questo compito su reti di dimensioni superiori ai 50-70 computer.
E' caldamente consigliato che il Server Antivirus sia connesso ad Internet per poter scaricare efficacemente gli aggiornamenti sia completi che incrementali della lista di definizione malware da distribuire ai computer protetti; è altresì caldamente consigliato che esso sia disponibile 24h/24 o, perlomeno, che sia il primo ad essere acceso al mattino (almeno 15 min prima degli altri) e spento per ultimo la sera, in modo che acquisisca sempre le liste di definizione malware più recente da distribuire ai computer protetti prima che questi vengano utilizzati.

Concetti fondamentali

Il sistema AdminSecure è composto dai seguenti sette moduli logici:

1. CON: Console
   1.1 ACON: Console addizionale
   Interfaccia grafica dell’applicazione; da essa l'utente può controllare ogni aspetto della gestione del sistema, interfacciandosi all'Administration Server, ai Repository ed al Database. Attraverso la console la rete può essere vista attraverso una struttura ad albero organizzativo modificabile a piacere. In una rete possono coesistere più Console per avere diversi punti di comando/monitoraggio.

2. AS: Administration Server
   2.1 ASA: Administration Server addizionale
   Servizio che, in modo trasparente all’operatore, processa le richieste impartite dalle Console, gestendo la concorrenza dei processi ed  eseguendoli in background in funzione della disponibilità dei computer a cui le richieste sono diretti. Aggiorna le informazioni amministrative nel Database. Se il Database è implementato su MS-SQL Server è possibile installare più Administration Server addizionali per migliorare le prestazioni su reti molto vaste e garantire l'alta disponibilità del sistema.

3. RPP: Repository Primario Principale
   3.1 RPA: Repository Primario addizionale
   3.2 RSA: Repository Secondario addizionale
   “Magazzino” o Insieme di magazzini ognuno gestito trasparentemente da un servizio, che contiene i package di installazione di diverse versioni dei motori di scansione disponibili per tutti gli oggetti che si possono proteggere (per default la versione corrente più due anteriori, se disponibili) e diverse versioni della lista di definzione virus (per default, la versione corrente più dieci anteriori), oltre che le altre liste di definizione di altri malware. In una rete possono esistere più Repository Primari (la denominazione "Primari" indica che sono in grado di scaricare da Internet gli aggiornamenti in forma completa ed incrementale delle liste malware) e/o più Secondari (la denominazione "Secondari" indica che si sincronizzano automaticamente ad intervalli stabiliti dall'Administration Server, per default ogni 4 ore, da un Repository Primario, a cui sono asserviti, sia per le liste malware che per i packages) ma ne esiste almeno uno di tipo Primario (detto convenzionalmente Repository Principale per distinguerlo dagli altri Primari, benchè non sia differente da essi) installato sullo stesso computer che ha a bordo l'Administration Server.

4. DB: Event Storage Database
   4d DB-dMSDE: MSDE installato di default dal pacchetto di installazione
   4p installazione personalizzata, DB su un server SQL/MSDE esistente
   Questo archivio memorizza tutte le informazioni necessarie alla gestione del sistema: stato dei computer controllati, processi in attesa, in esecuzione, eseguiti, rilevamenti di malware, struttura della visualizzazione della rete, impostazioni per i gruppi di oggetti ecc. Sulla rete esiste un unico Database, che può essere installato contestualmente all’applicazione (basandosi su un motore MSDE, Microsoft SQL Server Desktop Engine) o essere appoggiato ad un motore MSDE o MS-SQL Server già presente sulla rete.
   Attenzione: se sulla rete è già presente un Database MS-SQL, è consigliato appoggiare l'Event Storage Database di AdminSecure su tale server SQL, migliorando le prestazioni del sistema.
   Attenzione: se sul medesimo computer su cui si installa AdminSecure è già presente un Database MSDE (installato da un'altra applicazione) o MS-SQL, è obbligatorio appoggiare l'Event Storage Database di AdminSecure su tale server per evitare conflitti tra le istanze dei due engine.

5. MSC: Motori di scansione
   Sono gli antimalware veri e propri, disponibili per le workstation in tecnologia da Windows 95 a XP-Pro (ClientShield), per i file server (FileSecure), per i mail server (ExchangeSecure, DominoSecure, SendmailSecure ecc…) e per altri moduli, come descritto nella pagina principale dell'Assistenza prodotti Corporate.

6. AC: Agenti di comunicazione
   Servizi che devono essere installati su ogni computer da gestire, che consentono la comunicazione tra i motori di scansione,  un Administration Server (a cui sono asserviti in fase di distribuzione) ed un Repository (a cui sono asserviti in fase di distribuzione): gli Agenti creano un “canale” (scambio di messaggi XML attraverso la porta TCP 19226) attraverso il quale i comandi impartiti da console ed processati dall’Administration Server vengono inviati  ai motori di scansione, e viceversa attraverso il quale i motori di scansione comunicano all'Administration Server i dati circa il loro stato; sempre attraverso lo stesso canale, i motori di scansione richiedono l'aggiornamento delle liste malware al Repository a cui sono asserviti. Da qui si può intuire che un corretto funzionamento del sistema passa innanzitutto dalla distribuzione degli Agenti, che può essere eseguita in tre diversi modi (installazione diretta, logon script o package) come meglio dettagliato nella sezione Elementi comuni degli Agenti di Comunicazione.

7. Sistema di roaming
   7.1 HUR: HTTP Update Repository
   7.2 HUS: HTTP Update Server
   7.3 RC: Roaming Client
   Insieme di applicazioni e servizi, da installarsi sia sui client (Roaming Client) che lato server (HTTP Update Repository e HTTP Update Server) che consentono la comunicazione tra i Communications Agent e l'Administration Server anche se un computer (tipicamente un laptop) non si trova all'interno della propria rete locale, ovvero si trova "ospite" di un'altra rete oppure è connesso ad Internet via modem.
    

IN BREVE

• Nell’installazione tipica i componenti CON, AS, RPP e DB-dMSDE risiedono su una stessa macchina e compongono un macromodulo che di seguito verrà indicato con il suo nome commerciale di AdminSecure.

• Nell'installazione personalizzata (DB esistente, MSDE o SQL), AdminSecure è composto dai soli CON, AS e RPP.

• Ogni computer che debba essere protetto con un AntiMalware MSC deve avere a bordo anche l'Agente AC.

• Su reti di medie-grandi dimensioni più Console addizionali ACON possono essere installate per avere più punti di monitoraggio della situazione, più Administration Server addizionali ASA e più Repository addizionali RPA e RSA possono essere installati per migliorare le prestazioni del sistema stesso: gli Agenti AC, in fase di distribuzione, vengono asserviti ad un preciso Administration Server AS o ASA (dal quale riceveranno i comandi ed al quale restituiranno i risultati) ed ad un preciso Repository RPP, RPA o RSA dal quale scaricheranno le liste malware ed i package di installazione delle protezioni. E' possibile, da Console, modificare le impostazioni di asservimento degli Agenti ad un Repository o ad un Administration Server per effettuare un tuning delle prestazioni del sistema o, in sede contingente, mantenere le protezioni aggiornate mentre si risolve un grave malfunzionamento o indisponibilità del Repository o dell'Administration Server stesso.

L'immagine che segue mostra un'installazione di complessità medio-alta di tipo personalizzato,basata su un AdminSecure (CON, AS e RPP, in verde) interfacciato ad un Database MS-SQL esistente (in ambra): i componenti in fucsia sono addizionali/opzionali.

Servizi installati dai moduli del sistema di amministrazione

Si ribadisce che un'installazione Tipica su un computer dove non sia presente un altro DB è composta da CON, AS, RPP e DB-dMSDE. Per reti di dimensione inferiore ai 100 computer e non disgiunte in più sottoreti, essa risponde alle necessità normalmente richieste al sistema di amministrazione.

Si ribadisce che un'installazione Personalizzata senza componenti addizionali (che necessita pertanto di essere interfacciata ad un DB in tecnologia MS-SQL o MSDE già esistente o predisposto ad hoc) è composta da CON, AS e RPP.

L'Agente di Comunicazione AC è un componente indispensabile del sistema che viene automaticamente installato dal modulo (di sistema o aggiuntivo) che ne necessita. Esso installa anche un servizio di autoprotezione (Panda Process Protection Service) che non è funzionale tanto alla protezione antimalware vera e propria (infatti potrebbe essere disabilitato senza influire sul funzionamento del sistema) quanto è volto ad impedire l'accesso non autorizzato da parte di altri processi alle cartelle che contengono i file del sistema di amministrazione e di protezione antimalware.

I servizi installati dai motori di scansione MSC sono dettagliati nella sezione relativa ai motori stessi.

Dimensionamento

Si tenga conto nel seguito che i dati ed i valori contenuti in questo documento non sono tanto canonici quanto invece dettati dall'esperienza acquisita sia da Panda Software Italia che, soprattutto, dalla Casa Madre Panda Software International nelle numerose installazioni eseguite/manutenute da quando il sistema è stato lanciato sul mercato (Ottobre 2003): tra i moltissimi casi generali trattati, ovviamente esiste sempre qualche caso particolare che richiede un approfondimento specifico.

Un requisito applicabile ad ogni tipologia ed architettura di rete è che i computer dove vengono installati Administration Server principali o addizionali abbiano un indirizzo IP statico. E' altresì raccomandato che anche i computer ove venga installato un Repository aggiuntivo (sia primario che secondario) abbiano anch'essi un IP statico.

La seguente tabella fornisce un orientamento al dimensionamento in base ai parametri "numero di computer" e "numero di sedi"; nel seguito sono descritte diverse Architetture possibili.

Dettagliando le informazioni:

1. per un numero di computer fino a 100 in un'unica sede, è sufficiente installare la configurazione Tipica del sistema AdminSecure su un computer con s.o. NT o superiore di classe workstation o server, che esegue anche altre applicazioni. La configurazione Tipica è valida a meno di controindicazioni relative al DB, come descritto in Concetti Fondamentali, nel qual caso si procede ad un'installazione Personalizzata (rientra nel caso 2)

2. per gestire fino a 500 computer in una o più sedi il sistema AdminSecure può essere installato su un computer con s.o. NT server o superiore in configurazione Tipica  se non presenti SQL server, o meglio Personalizzata se presente un SQL server. Se la rete è suddivisa in due o più "isole" connesse da tronchi a bassa velocità, è opportuno installare un RPA o RSA in ogni isola che contenga più di 20-25 computer, ed è consigliabile farlo se la sede contiene un server, sul quale il Repository verrà installato. La scelta tra RPA o RSA è dettata sia dal fatto che l'isola abbia una propria connessione internet indipendente dal tronco che la connette alla sede centrale, sia dalla velocità di cifra del tronco stesso. Un RPA non impegna il tronco di raccordo per scaricare gli aggiornamenti da distribuire alle protezioni ad esso asservite, ma in occasione di un aggiornamento della versione del sistema richiede che il package di aggiornamento venga eseguito localmente. Un RSA, di converso, si sincronizza sia come servizio che come contenuto dal RPP o RPA a cui è asservito, ma in occasione delle sincronizzazioni genera un traffico notevole sul tronco di raccordo.

3. da 500 a 1000 computer in una o più sedi: tipicamente in Aziende di queste dimensioni è presente un SQL server, per cui si installa una configurazione Personalizzata su un server di produzione non critico (es. print server, fax server) o si dedica un hardware a questo scopo. Se non presente SQL, è opportuno acquisirne una licenza per dedicarlo a DB del sistema di amministrazione.

4. oltre i 1000 computer in una o più sedi è caldamente consigliato dedicare un server alla sola funzione di Server Antivirus, con il sistema installato in configurazione Personalizzata appoggiato su un SQL dedicato, a meno che non sia presente un SQL server ad alta affidabilità (cluster) con potenza di elaborazione più che sufficiente, in modo da gestire anche il DB di AdminSecure

5. (non dettagliato in tabella) Ricollegandosi al caso precedente, in presenza di un SQL server ad alta affidabilità in cluster, qualora fosse richiesta l'alta affidabilità anche al sistema antimalware, il sistema di amministrazione potrebbe essere completamente ridondato installando su un HW dedicato una configurazione Personalizzata e su un HW gemello dedicato un ASA, un RPA ed una ACON. Si tratta di una configurazione che è stata simulata solo in laboratorio non essendo sinora risultata necessaria nella pratica: è infatti sufficiente, in caso del guasto dell'Antivirus Server, il suo ripristino dall'ultimo backup su un HW compatibile.

.

Architetture possibili

• Architettura centralizzata: installazione Tipica o Personalizzata con MS-SQL installati su una medesima macchina. E' il caso più comune che risponde alle esigenze della maggior parte degli utenti.

• Architettura parzialmente distribuita: installazione Personalizzata con MS-SQL (dedicato o condiviso) installato su un computer separato: consente migliori performance (rapporto dei tempi di 2,5 / 1) rispetto all'architettura centralizzata nella distribuzione degli aggiornamenti.

• Architettura totalmente distribuita: installazione Personalizzata su server dedicato e RPP senza computer asserviti, RPA su secondo server dedicato, MS-SQL esterno (dedicato o condiviso): rispetto all'architettura centralizzata consente anche un miglioramento dei tempi di installazione delle protezioni, abbattendoli da 2 a 5 volte in base al processore del server di amministrazione (2 volte con P III 800, 5 volte con Dual P IV 2600)

Parametri da considerare nella progettazione dell'architettura

• Numero e posizione degli Administration Server: questa decisione dipende dal numero di computer da gestire, dalla loro locazione topografica e dalle connessioni disponibili tra le sedi. Se la banda passante verso isole con molti computer è limitata (inferiore ai 512 kbps) e tali isole non hanno una propria connettività internet, è sconsigliabile usare RPA o RSA che potrebbero causare "intasamenti" del canale trasmissivo ed è invece preferibile locare in queste isole un ASA. Se la banda passante è superiore ai 512 kbps valgono le considerazioni espresse in calce alla tabella precedente.
  Attenzione: potrebbe rendersi necessario installare più Administration Server addizionali anche in reti di piccole dimensioni ma che generano una grande quantità di eventi (rilevamenti malware).

• Event Storage Database: se presente sul medesimo computer un engine MSDE o MS-SQL, è obbligatorio utilizzarlo eseguendo un'installazione Personalizzata; se presente in rete SQL server, è consigliabile utilizzarlo eseguendo un'installazione Personalizzata. In linea di principio è sempre opportuno utilizzare MS-SQL server se si intendono gestire oltre 100 computer.

• Numero e posizione dei Repository addizionali: come prima dettagliato, è sempre opportuno collocare un Repository aggiuntivo nelle sedi remote con un congruo numero di computer. Se l'Administration Server deve gestire un numero rilevante di computer (oltre 1000) è opportuno che il Repository Primario installato sullo stesso computer non debba eseguire repliche verso uno o più Secondari, e se possibile è opportuno implementare un'architettura completamente distribuita.

• Tipo dei Repository addizionali: se la sede remota ha una buona connettività internet, il Repository può essere di tipo Primario. Se la connettività locale è di bassa qualità o inesistente, ma il tronco di raccordo verso il più vicino Repository Primario è di buona qualità, si installi un Repository Secondario.

• Numero e posizione delle Console: non ci sono controindicazioni, si possono collocare quante console si desiderano per gestire il sistema da più punti.

Esempi pratici di architetture comuni