June 2008 June 2008
Sicurezza: Il grande dibattito: la sicurezza tramite segretezza
La sicurezza tramite segretezza implica l'adozione di misure che, anziché eliminare un vettore di attacco, si limitano a nasconderlo. Alcuni la ritengono una procedura inefficace, mentre altri la considerano come parte di una strategia più ampia e complessa. Il dibattito è piuttosto accesso e vede lo scontro tra alcuni dei nostri migliori esperti della sicurezza, che espongono le loro ragioni a favore o contro tale procedura. Jesper M. Johansson and Roger Grimes
Security: Nuovi PowerToy per l'elevazione dei privilegi in Windows Vista
Michael Murgolo torna con un aggiornamento dei PowerToy di elevazione dei privilegi. In questo articolo verrà illustrato come sia possibile utilizzare la funzionalità per l'esecuzione come amministratore migliorata con strumenti di script di terze parti, verrà esaminata una soluzione con cui sostituire un'utile funzionalità di Windows XP rimossa da Windows Vista e verranno descritti molti altri strumenti interessanti. Michael Murgolo
Sicurezza: Miglioramenti di Crittografia unità BitLocker
Windows Vista SP1 e Windows Server 2008 introducono importanti novità in BitLocker, inclusi il supporto dei volumi di dati e una protezione migliorata contro gli attacchi crittografici. Byron Hynes esplora le nuove funzioni, illustra come utilizzare BitLocker su un server e discute di alcuni recenti articoli e recensioni su BitLocker. Byron Hynes
Security: Blocco di applicazioni con i criteri di restrizione software
Quando si desidera ridurre il costo totale di proprietà dei computer desktop nella propria organizzazione, il blocco delle applicazioni può rivelarsi particolarmente utile, in quanto consente di limitare i problemi IT correlati alle applicazioni non supportate. Scopri come utilizzare i criteri di restrizione software e Criteri di gruppo per controllare le applicazioni eseguite all'interno dell'infrastruttura IT. Chris Corio and Durga Prasad Sayana
Sicurezza: Gestione del firewall di Windows Vista
L'ultimo aggiornamento del firewall di Windows Vista introduce alcune funzioni notevoli grazie alle quali rappresenta un'opportunità imperdibile per l'ambiente delle aziende. Jesper Johansson riassume l'evoluzione del firewall di Windows e spiega i miglioramenti, come nuove regole e profili, isolamento del dominio e crittografia, che daranno una visione più approfondita agli amministratori. Jesper M. Johansson
Security: Garanzia della sicurezza della posta elettronica tramite i certificati digitali
Il protocollo Secure Multi-Purpose Internet Mail Extensions (S/MIME) consente di nascondere le informazioni in transito, convalidare i mittenti e autenticare i messaggi. Scopri come garantire la sicurezza della posta elettronica mediante i certificati digitali e come risolvere i problemi che si possono verificare nel sistema S/MIME. Matt Clapham and Blake Hutchinson
Columns
Dal redattore: Il grande dibattito: | Lettere: La parola ai lettori: | Toolbox: Nuovi prodotti per professionisti IT:
SQL Q&A: Errori di I/O, mirroring del database e altro: Paul Randal risponde a domande relative a SQL Server, illustrando come creare problemi di danneggiamento in un database di test, come evitare un ciclo di compattazione-aumento di dimensioni-compattazione-aumento di dimensioni e come determinare il numero di database di cui è possibile eseguire il mirroring prima che le prestazioni inizino a risentirne.Paul S. Randal | Utility Spotlight: Windows Vista Upgrade Advisor: Sei pronto per aggiornare i sistemi della tua organizzazione a Windows Vista? Scopri in che modo Windows Vista Upgrade Advisor può aiutarti a determinare se i sistemi in uso sono pronti per l'aggiornamento a Windows Vista e quali versioni sono in grado di supportare.Lance Whitney | Inside SharePoint: Decentralizzazione dell'amministrazione di siti: Scopri i vantaggi e le implicazioni associati alla delega del controllo amministrativo sui siti di SharePoint ai singoli reparti, mantenendo nel contempo il controllo amministrativo centralizzato sull'infrastruttura SharePoint.Pav Cherny
Windows PowerShell: Un output bello e chiaro: La natura orientata a oggetti di Windows PowerShell consente di applicare delle formattazioni all'output.Don Jones | Hey, Scripting Guy!: Anche chi non lavora troppo duramente avrà le sue ricompense: Gli Scripting Guy riflettono sul lavoro duro, su come raggiungere la vera e su come generare un output di dati in formato tabulare e leggibile nella finestra di comando.The Microsoft Scripting Guys | File desktop: Protezione contro Conformità: I professionisti dell'IT spesso si trovano a dover conseguire obiettivi che si contraddicono l'un l'altro. Per mantenere la conformità, spesso si rischia di venir meno in termini di protezione.Wes Miller
The Business of IT: 10 punti chiave per diventare leader nelle scelte ambientali: Con il ruolo crescente che i reparti IT stanno assumendo negli sforzi di sostenibilità ambientale delle aziende, i professionisti IT hanno l'opportunità di indirizzare il cambiamento e diventare veri leader di riferimento nelle aziende e nell'intero settore. Ecco una panoramica su come diventare un vero leader di riferimento per le iniziative di sostenibilità ambientale nella propria organizzazione.Michael Walsh and Eliza Walsh | Field Notes: Condivisione di uno schermo: Sviluppato da Microsoft Research India, il software Split Screen consente a due utenti di condividere un monitor durante l'esecuzione di due istanze separate del sistema operativo.Kentaro Toyama | Windows Confidential: I due peggiori computer di tutti i tempi: Raymond Chen si abbandona ai ricordi e riporta alla memoria i due peggiori computer mai prodotti.Raymond Chen


Sicurezza
Il grande dibattito: la sicurezza tramite segretezza
Jesper M. Johansson and Roger Grimes
Panoramica:
  • Definizione della sicurezza tramite segretezza
  • Valutazione delle misure di sicurezza tramite segretezza
  • Importanza della ridenominazione dell'account Administrator
  • Come prendere decisioni di gestione dei rischi consapevoli

La definizione "sicurezza tramite segretezza" incontra spesso la derisione del personale della sicurezza, in particolar modo di coloro che si considerano esperti. Letteralmente sottovalutata da molti, la sicurezza
tramite segretezza, come evidenziato in Wikipedia (http://it.wikipedia.org/wiki/Security_through_obscurity), rappresenta uno degli aspetti più controversi inerenti la sicurezza. La definizione "sicurezza tramite segretezza" viene spesso utilizzata per fare riferimento ad attività di scarsa importanza.
In poche parole, la sicurezza tramite segretezza è una violazione del principio di Kerckhoff, che sostiene che un sistema dovrebbe essere sicuro di per sé e non perché la sua struttura è sconosciuta all'avversario. Il principio di Kerckhoffs si basa sulla premessa che i segreti non rimangono tali per molto tempo.
Come esempio di ciò, prendiamo in considerazione il protocollo di autenticazione Windows NT® LAN Manager (NTLM), considerato inizialmente un segreto. Per implementare il prodotto di interoperabilità Samba per i sistemi operativi basati su UNIX, il team Samba è stato costretto a eseguire il reverse engineering del protocollo. Si ottenne così la più vasta documentazione disponibile sul protocollo NTLM (monyo.com/technical/samba/translation/ntlm.en.html) oltre che l'identificazione di una serie di bug. Visto che gran parte della sicurezza si sviluppava dalla crittografia e molti progetti segreti erano stati rivelati, molti professionisti della sicurezza ritennero che tutta la sicurezza delle informazioni dovesse seguire il principio di Kerckhoff.
Ma è vero che la sicurezza tramite segretezza è sempre inefficace? In questo articolo, verrà illustrata la sicurezza tramite segretezza, verranno indicati i motivi per i quali molti (ma non tutti) la considerano una perdita di tempo e verrà mostrato come la questione sia, come al solito, molto più complicata di come potrebbe sembrare di primo impatto.

Introduzione alla sicurezza tramite segretezza
Non modificare le impostazioni predefinite di Steve Riley
Io sono uno di quelli che pensano che non si dovrebbero modificare i nomi account Questo in realtà non è un problema di sicurezza, ma piuttosto un problema di gestione dei sistemi. E, visto che mi ritrovo sempre più spesso a pensare allo spazio di gestione dei sistemi (dato che la gestione e la sicurezza stanno diventando un'unica questione), divento sempre di più un sostenitore del non fare nulla che possa potenzialmente aumentare la vulnerabilità di un sistema. Un modo sicuro per aumentare la vulnerabilità consiste nel modificare le impostazioni predefinite. Esistono ben due (o tre) motivi per i quali le persone modificano le impostazioni predefinite:
  • Esiste l'esigenza della funzionalità fornita dalla modifica.
  • Si pensa che la modifica possa migliorare la sicurezza.
  • (Ricordare: non è affatto vero.) Qualcuno ne ha sentito parlare in un articolo di giornale.
Se si ha bisogno di modificare un nome predefinito per il motivo 1, procedere alla modifica. Questi tipi di modifiche in genere non comportano un'instabilità del sistema, spesso perché sono state già testate.
Se si desidera apportare una modifica per il motivo 2, è necessario fermarsi un attimo e riflettere. Questi tipi di modifiche non vengono quasi mai testate dal produttore del software e, di conseguenza, quest'ultimo non sa prevedere quale sarà la reazione del sistema alla modifica. Inoltre, di solito esistono alternative di gran lunga migliori che saranno in grado di fornire una sicurezza efficace.
Cosa accade se un malintenzionato scopre un nome account? Sarà la password, e la sua complessità, a tenere il malintenzionato lontano dal sistema. L'impellenza di modificare i nomi account predefiniti come Administrator e Guest in nomi difficili da ricordare è spesso realmente indicativa del desiderio di evitare password o passphrase complesse. È sufficiente risolvere il vero problema (segreti inappropriati) per evitare la vulnerabilità (modificando i nomi predefiniti).

La sicurezza tramite segretezza non include misure che sono del tutto inefficaci per la risoluzione di un problema. Ad esempio, un'organizzazione che blocca il protocollo Network News Transfer Protocol (NNTP) sui router di confine per impedire ai dipendenti di leggere i newsgroup ma consente il protocollo Secure Shell (SSH) in uscita non sta utilizzando la sicurezza tramite segretezza. Dato che il protocollo SSH può effettuare il tunneling di ogni protocollo, il problema non viene nascosto; la scarsa attenuazione implementata riesce solo a impedire che utenti legittimi eseguano attività legittime senza violare i criteri di sicurezza. Tali misure non costituiscono la sicurezza tramite segretezza; sono semplicemente inappropriate e inutili.
Come il termine "sicurezza" incluso nella definizione "sicurezza tramite segretezza" implica, è possibile ottenere un certo grado di sicurezza dalla misura. Tuttavia, è implicito anche che (e questo è il problema) non si sta facendo nulla per bloccare un attacco su uno o più vettori. (Un vettore di attacco è fondamentalmente un mezzo attraverso il quale un autore di un attacco riesce ad accedere a un sistema.)
Si supponga, ad esempio, di avere un server Web vulnerabile che può essere attaccato sulla porta TCP 80 utilizzando un exploit pubblico. Per chiudere quel particolare vettore, è possibile applicare una patch al server Web oppure disattivarlo; entrambe le azioni sono in grado di bloccare completamente il vettore. È possibile bloccare il vettore di attacco parzialmente utilizzando un firewall o IPsec per lasciare aperta la porta 80 solo per alcuni computer prescelti. In questo modo, il vettore di attacco non viene bloccato completamente, ma il problema risulta attenuato significativamente.
D'altra parte, la sicurezza tramite segretezza implica l'adozione di alcune misure che non bloccano il vettore di attacco, ma si limitano semplicemente a nasconderlo. Ad esempio, si può decidere di spostare il server Web sulla porta 81 anziché 80 per fare in modo che possa essere trovato solo da coloro che sanno dove trovarlo. Per lo meno, questa è la teoria. In realtà, lo spostamento del server Web sulla porta 81 blocca solo alcuni attacchi e crea grandi inconvenienti per l'utente finale. È sufficiente che un intruso esperto esegua uno scanner per porta e un richiamo di banner Web per un'ampia serie di porte per individuare i server Web sulle porte non standard. Non appena ne trova uno, può inviare l'exploit contro il server dato che il vettore di attacco non è stato realmente eliminato, ma solo (temporaneamente) nascosto.
Ciò vuol dire che non si dovrebbe nemmeno tentare? Dipende. Come sempre avviene nell'area della sicurezza delle informazioni, è tutta una questione di gestione dei rischi. Per comprendere i fattori fondamentali da prendere in considerazione, verranno esaminate brevemente alcune altre misure di sicurezza tramite segretezza e ne verrà illustrata uno (la ridenominazione dell'account Administrator) in modo più dettagliato.

Valutazione della misure di sicurezza
Gli esempi di sicurezza tramite segretezza possono essere svariati. Possono essere azioni eseguite dagli amministratori di rete e di sistema oppure avviate dagli sviluppatori software. Tuttavia, hanno tutte un fattore in comune, ovvero l'intenzione di attenuare una vulnerabilità nascondendola dai potenziali autori di attacchi.
Alcune di queste procedure non potrebbero avere quanto meno un effetto benefico? È davvero giusto dire che tutta la sicurezza tramite segretezza è inefficace? Non è difficile trovare dei sostenitori di almeno alcune di queste misure. Ad esempio, in Windows® è possibile nascondere le lettere di unità in Esplora risorse. Molti ambienti, quali i laboratori informatici delle scuole, utilizzano questa tecnica per impedire agli utenti di salvare i dati sul disco rigido. Ovviamente, la maggior parte delle applicazioni potrà continuare a salvare i dati sul disco fisso; quindi, questa misura non garantisce una sicurezza massima. Tuttavia, gli istituti che l'hanno implementata dichiarano spesso che riduce la quantità di dati sul disco rigido.
Un altro tipo di procedura di scurezza tramite segretezza spesso implementata su Windows è la disattivazione delle condivisioni di rete amministrative (ad esempio, C$, Admin$ e così via). Si ritiene che in questo modo si possa impedire a un autore di un attacco di connettersi al computer in remoto. Ciò è vero, ma un autore di un attacco con un account che consente di utilizzare le condivisioni amministrative è comunque in grado di riabilitarle in remoto. Tuttavia, molte organizzazioni affermano che la disabilitazione di tali condivisioni riduce le incidenze di malware sulle loro reti.
Uno dei migliori esempi di sforzo inutile è l'impostazione "Dispositivi: consenti il disinserimento senza dover effettuare l'accesso" di Windows. Se è disabilitata, il pulsante "Disinserisci computer" viene nascosto dalla schermata di accesso. L'idea è che in questo modo un autore di un attacco non può disinserire normalmente il computer. Naturalmente, un intruso può semplicemente inserire sia il computer che l'alloggiamento di espansione in una borsa e portarseli via con sé, indipendentemente dalla disponibilità di quel pulsante. Questa possibilità non corrisponde alla sicurezza tramite segretezza neanche a livello marginale.
Un altro esempio chiaro è l'impostazione "Controller di dominio: consenti agli operatori dei server di pianificare le attività", che consente agli utenti membri del gruppo Server Operators di pianificare le attività. Questo è un problema delicato perché tali attività possono essere eseguite come processi di sistema locale e solo gli amministratori dovrebbero pianificare attività di questo tipo. Naturalmente, gli operatori dei server possono agire da amministratori attraverso una serie di vettori diversi; di conseguenza, impedire loro di pianificare le attività in questo modo non produce realmente grandi effetti.
Tuttavia, a molte organizzazioni piace questa impostazione in quanto consente ai loro sistemisti di agire da operatori dei server anziché da amministratori e, in tal modo, è meno probabile che distruggano involontariamente il server. Ciò potrebbe apportare qualche beneficio.
Allora, qual è il verdetto? Ovviamente, alcuni di questi problemi possono essere davvero complicati. Abbiamo fatto lunghi dibattiti su questi tipi di misure. Roger è fermamente convinto che tali procedure generino enormi vantaggi. Jesper, da parte sua, crede che nella maggior parte dei casi siano al massimo una perdita di tempo. È ora possibile dare uno sguardo a uno dei casi più citati (e più discussi) che riguardano la sicurezza tramite segretezza, ovvero la ridenominazione dell'account Administrator. Roger sarà a favore della misura, mentre Jesper sarà contrario. Intervengono anche gli esperti della sicurezza Aaron Margosis e Steve Riley, rispettivamente nelle intestazioni laterali "Rinominare l'account dell'amministratore" e "Non modificare le impostazioni predefinite".

Come nascondere l'account Administrator
Rinominare l'account Administrator, identificatore relativo (RID) 500, assegnandogli un nome sconosciuto a gran parte degli utenti è una procedura spesso consigliata dai professionisti della sicurezza ed è un suggerimento fornito anche in diverse guide alla protezione avanzata di Microsoft. Anche Criteri di gruppo include un'impostazione per rinominare l'account Administrator, come mostrato nella Figura 1. L'idea è che, se l'account Administrator viene rinominato, sarà più difficile per un autore di un attacco accedere come vero amministratore. Naturalmente, il problema ovvio relativo all'uso di Criteri di gruppo per questa operazione è che l'account Administrator rinominato avrà lo stesso nome su ogni computer in cui è stato applicato questo oggetto Criteri di gruppo. Ciò riduce il valore della segretezza di questa particolare misura.
Figura 1 Ridenominazione dell'account Administrator
Figura 1 Ridenominazione dell'account Administrator (Fare clic sull'immagine per ingrandirla)
In questo contesto, è importante comprendere anche che qualsiasi utente con un account valido può recuperare il nome dell'account Administrator, indipendentemente dal fatto che sia stato rinominato o meno. L'account Administrator ha sempre un RID di 500. Chiedendo semplicemente il nome dell'account con RID 500, qualsiasi utente può scoprire il suo vero nome, come mostrato nella Figura 2.
Figura 2 Ricerca degli account Administrator rinominati
Figura 2 Ricerca degli account Administrator rinominati (Fare clic sull'immagine per ingrandirla)

Posizione di Roger
Il principale motivo che mi spinge a essere contrario alla ridenominazione dell'account Administrator è la facilità con cui è possibile convertire il nome account di una qualsiasi entità di sicurezza nel relativo identificatore di sicurezza (SID) e scoprirne il RID. E l'account Administrator ha sempre un RID di 500. Pertanto, se l'autore di un attacco può convertire senza difficoltà i nomi di account utente nelle combinazioni SID/RID e trovare RID 500, perché preoccuparsi tanto?
Ma la storia non è così semplice. Per eseguire le conversioni da nome di account utente a SID/RID, è necessario disporre dell'accesso alla porta NetBIOS o LDAP. La maggior parte dei firewall perimetrali non consentono quel tipo di accesso su Internet e, quindi, fin quando l'autore di un attacco non aggira completamente il firewall, non riuscirà ad eseguire alcuna conversione. Inoltre, le conversioni SID anonime non funzionano con Windows XP e le versioni successive di Windows, tranne che sui controller di dominio. Per i computer che si trovano più vicini al perimetro (quelli più esposti al rischio), l'autore di un attacco ha bisogno di credenziali autenticate per eseguire le conversioni da nome a SID.
Pertanto, è necessario aggirare una buona serie di reali ostacoli di difesa in profondità per iniziare un attacco di conversione. E persino se l'autore dell'attacco riesce nel suo intento, si ritrova nello stesso punto in cui sarebbe finito se il nome account non fosse stato convertito. La ridenominazione dell'account Administrator non può che migliorare la sicurezza, o quanto meno non la peggiorerà.
Un altro segreto Se l'autore di un attacco non conosce il nome account Administrator, diventa un'altra etichetta "segreta", simile a una password, che l'autore dell'attacco deve riuscire a scoprire. È vero, è molto meno probabile che i nomi di account utente siano complessi come una password amministrativa, ma rappresentano sempre un ostacolo che potenzialmente complica il problema dell'individuazione della password. Se qualcuno ha provato a individuare una password, avrà scoperto quanto è più difficile riuscire a individuare sia il nome utente che la password. Rende più gravosa un'attività già difficile di per sé e rende il tutto molto più complicato.
Contrasta il malware automatizzato e gli script kiddie Sono 22 anni che mi occupo della strategia di sicurezza di Windows e, negli ultimi 5 anni, ho fatto uso di otto honeypot Windows, esposti a Internet. In tutto questo periodo, non ho mai visto un malware automatizzato (che rappresenta la quasi totalità degli attacchi) che non utilizzasse un'etichetta di account utente che non fosse Administrator (oppure root, nel caso dei sistemi *NIX). Se si rinomina l'account Administrator, viene immediatamente stroncato tutto il malware basato sul nome Administrator. E ciò comporta una riduzione del rischio per la sicurezza.
Lo stesso vale per gli script kiddie. Tutti i manuali relativi agli attacchi Windows "kewl" che conosco menzionano le tecniche di conversione da nome a SID; tuttavia, non ne ho mai vista una messa in pratica nei miei honeypot nel caso in cui avessi avuto un account Administrator "fittizio" per sbarazzarmi di loro. I pirati informatici davvero esperti dovrebbero sempre verificare che l'account Administrator trovato sia il vero account Administrator (RID 500), ma non lo fanno. Non so perché. Penso dipenda dalla pigrizia dei pirati informatici e da una tipica indole dell'uomo.
Blocca anche la maggior parte dei pirati professionisti Questo fatto sorprende molte persone. Dopo aver utilizzato gli honeypot per alcuni anni, si riconosce subito la differenza tra gli attacchi automatizzati, gli script kiddie e i pirati professionisti. Negli ultimi cinque anni, con milioni di attacchi registrati contro i miei honeypot, non ho mai visto pirati professionisti eseguire la conversione SID in presenza dell'account Administrator fittizio.
Sono certo che alcuni di loro la eseguono, ma spero si tratti di una piccola minoranza. Perché i pirati professionisti dovrebbero fare ciò? Immagino che loro stessi non vedano alcuna ragione per provare a fare qualcosa che il resto del mondo non fa.
Semplifica gli avvisi A questo punto, coloro che sostengono la tesi opposta alla mia potrebbero affermare che se la ridenominazione dell'account Administrator si diffondesse troppo, perderebbe il suo valore come tecnica di segretezza. Il motivo è che il malware, gli script kiddie e i pirati professionisti modificherebbero le loro tattiche predefinite per ricercare altri nomi diversi da Administrator. E questo è un motivo assolutamente valido. Fortunatamente, non modifica la condizione essenziale. In primo luogo, se l'account super-privilegiato di Windows non è denominato Administrator, il pirata informatico malintenzionato deve lavorare più duramente. Questo è un puro fatto. E se il pirata informatico deve lavorare di più, è meno probabile che proverà quella via di attacco e potrà così consentire a una delle altre tecniche di difesa in profondità di individuare l'attività dannosa in modo più rapido.
E ciò introduce il mio ultimo punto a favore della ridenominazione. Se l'account Administrator non viene mai denominato Administrator ed è possibile creare un altro account con tale nome, come mostrato nella Figura 3, vuol dire che il meccanismo di avviso è davvero efficace. Se il monitoraggio degli eventi individua un tentativo di accesso che utilizza il nome predefinito, l'evento dovrà essere analizzato immediatamente.
Figura 3 I tentativi di accesso a un account fittizio denominato Administrator possono fungere da sistema di avviso tempestivo
Figura 3 I tentativi di accesso a un account fittizio denominato Administrator possono fungere da sistema di avviso tempestivo (Fare clic sull'immagine per ingrandirla)
I nostri registri eventi sono pieni di accessi "non riusciti" che non hanno alcun significato. In genere, si tratta di un utente (o di Windows) che sta tentando di accedere utilizzando una password non valida o qualcosa di simile. Tuttavia, se l'account Administrator è denominato effettivamente Administrator, come è possibile distinguere i tentativi di accesso validi da quelli dannosi? Se si ha un account di accesso denominato Administrator e viene rilevato un tentativo di accesso con tale nome, l'intento sarà certamente dannoso. Un avviso tempestivo con un segnale acustico di bassa intensità si rivela prezioso nei sistemi di difesa di oggi.

L'opinione di Jesper
Rinominare l'account Administrator di Aaron Margosis
Jesper, in un mondo ideale, avresti sicuramente ragione. Le password sarebbero sempre sufficientemente complesse da bloccare l'individuazione delle password e gli account di amministratore locale -500 verrebbero utilizzati solo per i ripristini di emergenza. Tuttavia, nel mondo reale le cose non sono così.
Nonostante il tuo grande impegno nel descrivere l'importanza di un sistema di sicurezza efficace e gli articoli da te scritti a tale proposito ("The Great Debates: Pass Phrases vs. Passwords" parte 1, 2 e 3 agli indirizzi go.microsoft.com/fwlink/?LinkId=113157, go.microsoft.com/fwlink/?LinkId=113159 e go.microsoft.com/fwlink/?LinkId=113160), molti amministratori di sistema non hanno ancora capito come creare una password complessa.
Non è trascorso molto tempo da quando una password costituita da otto caratteri derivanti da più set di caratteri era davvero complessa; la legge di Moore rese ciò obsoleto. La formazione degli utenti (e degli amministratori di sistema) costituisce un punto debole e molto probabilmente resterà tale, almeno fino a quando l'argomento della complessità delle password non susciterà l'interesse dei canali di informazioni via cavo.
Pertanto, considerato che l'individuazione delle password del mondo reale di oggi richiede pochissimo tempo, l'aggiunta di un moltiplicatore x1000 può rivelarsi un autentico vantaggio. E contro i molti attacchi automatizzati che tentano di identificare l'account denominato Administrator, la ridenominazione rende l'account invulnerabile.
Il tempo e gli sforzi profusi per la ridenominazione dell'account Administrator in genere sono pochi; si tratta, come tu hai messo in evidenza, di impostare l'oggetto Criteri di gruppo. In effetti, la Federal Desktop Core Configuration del Governo degli Stati Uniti (csrc.nist.gov/fdcc) richiede la ridenominazione dell'account -500. La ridenominazione è solo una delle numerose impostazioni necessarie e ho sperimentato che nessuna di loro richiede un'eccessiva quantità di tempo o grande attenzione. Non ho neanche mai visto nessuno farsi cullare da un falso senso di sicurezza riguardo al suo valore; non ho mai sentito nessuno dire: "Non abbiamo bisogno della gestione delle patch visto che abbiamo rinominato i nostri account Administrator".
La ridenominazione ha valore quando l'account viene rinominato allo stesso modo nell'intera organizzazione? Non ha grande valore, ma qualche vantaggio lo apporta: in primo luogo, blocca gli attacchi automatizzati contro l'account Administrator; in secondo luogo, l'insieme dei potenziali autori di attacchi non è necessariamente un sottoinsieme di coloro che conoscono il nuovo nome. (Il rischio più grande si ha quando gli account di amministratore locale, rinominati o meno, condividono una stessa password in tutta l'organizzazione. Gestire tali account resta il problema sicuramente più grande. Per risolverlo, è possibile disabilitare l'account -500, anche se in questo modo viene bloccata un'importante via di ripristino quando gli account di dominio non possono essere utilizzati.) Intendo sottolineare anche che le nostre guide sulla sicurezza hanno sempre consigliato di rinominare gli account predefiniti e, quindi, quanto suggerito risulta già testato e supportato.
Penso che tutti sappiamo bene che le misure di segretezza non costituiscono da sole una difesa adeguata. Ma possono contribuire a potenziare altre misure di sicurezza, come illustrato chiaramente dai dati di Roger. Fin quando il costo di implementazione resta basso, le organizzazioni non dovrebbero escluderle.

Così come esistono validi motivi a favore della ridenominazione dell'account Administrator, ve ne sono altrettanti per non rinominarlo. Tuttavia, prima di passarli in rassegna, è opportuno riconoscere la validità dell'ultimo punto avanzato da Roger. Eppure, in un ambiente a elevata gestione, è opportuno valutare qualsiasi accesso con l'account Administrator dato che tale account dovrebbe essere utilizzato solo nei casi di ripristino di emergenza.
È superfluo Il rischio principale che si prevede venga attenuato dalla ridenominazione dell'account Administrator è l'individuazione della sua password in remoto. Ma in questo modo verrebbe contrastato solo un utente che non dispone di un altro account autorizzato sul computer. Un autore di attacchi di questo tipo in genere tenta di accedere all'account Administrator utilizzando una serie di password casuali. Tuttavia, riceverebbe lo stesso messaggio di errore indipendentemente dal fatto che abbia individuato il nome account errato o la password errata.
Ciò suggerisce che uno dei principali motivi a favore della ridenominazione dell'account Administrator (che fa scappare gli script kiddie) presenta dei difetti. Non scappano quando l'account Administrator viene rinominato, ma quando ha il nome originale, che loro non riescono a individuare! Gli script kiddie individueranno lo stesso insieme di password casuali e quindi passeranno alla vittima potenziale successiva.
Ciò vuol dire che fin quando la password dell'account Administrator è sufficientemente complessa per respingere gli attacchi, la ridenominazione non fornisce valore aggiuntivo. Supponiamo di avere una password di 15 caratteri per l'account Administrator, composta di lettere minuscole e maiuscole, numeri e simboli. Individuare tale password sulla rete richiederà circa 591.310.404.907 anni. Si tratta di un numero di anni di 43 volte superiore agli anni di vita dell'universo.
A questo punto, supponiamo di rinominare l'account Administrator e di renderlo uno dei 1.000 valori possibili. In questo caso, gli anni necessari per individuare la password saranno 591.310.404.906.787, ovvero un periodo di tempo di 43.161 volte superiore agli anni di vita dell'universo. Siamo più sicuri così? Sì, lo siamo. Siamo riusciti a fare in modo che fosse meno probabile per l'autore dell'attacco individuare la nostra password? Bene, in entrambi i casi la probabilità è infinitamente bassa. In altre parole, nel mondo reale, riusciamo a essere realmente sicuri solo con il nome account Administrator originale. Solo perché rinominare l'account uccide il malware che tenta di utilizzarlo non significa che il malware sarebbe riuscito nella sua impresa se non avessimo rinominato l'account. In effetti, se si utilizza una password complessa, come si dovrebbe fare, si potrà essere quasi certi che il malware non riesca a individuarla, indipendentemente dal nome dell'account.
Molte guide sulla sicurezza suggeriscono di rinominare l'account Administrator; ma ciò non ne fa una misura di sicurezza preziosa o valida. Evita semplicemente di dover prendere una decisione di gestione dei rischi efficace. Le guide sulla sicurezza hanno spesso richiesto l'uso di impostazioni inutili e, in molti casi, anche inesistenti. Alla fine, per ottenere successi nel campo della sicurezza, è necessario andare oltre i requisiti, analizzare effettivamente i problemi e capire se vale la pena o no tentare di mitigarli. A questo punto, è importante ricordare un punto critico, ovvero che non è necessario modificare una funzione per il semplice fatto che questa rappresenta l'obiettivo dell'autore di un attacco. È necessario modificare una funzione solo se si prevede che un attacco possa riuscire senza tale modifica.
Se prendiamo in considerazione una password complessa, la probabilità di successo è praticamente nulla sia che l'account venga rinominato o meno. Pertanto, fin quando si utilizza una password complessa, non si ha praticamente alcun motivo per rinominare l'account. Inoltre, se si agisce, come faccio io, in base al principio che un computer possa essere più stabile con il minor numero di modifiche possibili (questo è un fatto comprovato), esistono tutte le ragioni per non rinominare l'account Administrator.
Attenzione alle attenuazioni di valore minimo Un problema inerente le attenuazioni della sicurezza tramite segretezza di valore minimo è il rischio che l'attenzione delle organizzazioni venga distolta dalle attenuazioni di maggiore valore. Ad esempio, il tempo e gli sforzi profusi per rinominare l'account Administrator non possono essere utilizzati per qualcos'altro. Se qualcos'altro fornisce maggiore valore rispetto alla ridenominazione degli account Administrator, l'organizzazione ha perso un'opportunità. Questo fatto potrebbe non sembrare un costo reale, ma basta immaginare di dover rinominare 50.000 account Administrator e si inizierà ad avere un'idea della situazione.
Un ulteriore inconveniente è la reale possibilità che, una volta implementata l'attenuazione di valore minimo, i responsabili dell'organizzazione inizino a rilassarsi troppo. I responsabili potrebbero non comprendere il valore minimo fornito dalle attenuazioni della sicurezza tramite segretezza e potrebbero non prendere ulteriori misure di sicurezza. Ciò può comportare un rischio significativo per l'organizzazione, anche se tale rischio può essere evitato laddove i responsabili impieghino il tempo e gli sforzi necessari per capire il valore delle attenuazioni che vengono implementate.
Gestione onerosa Infine, a seconda di come viene implementata, l'attenuazione può comportare una gestione troppo onerosa. Se si imposta semplicemente un oggetto Criteri di gruppo per rinominare l'account Administrator, il costo risulta molto basso. Tutti conosceranno il nome e il costo della distribuzione è praticamente nullo. Tuttavia, anche il valore fornito risulta essere minimo in quanto, come è già stato spiegato, tutti coloro che hanno un account conosceranno il nome. Quindi, per ottenere più valore da questa attenuazione, è necessario utilizzare nomi diversi su host diversi, cosa che rende più onerosa la gestione del sistema.
Sarebbe molto meglio utilizzare uno strumento come passgen (protectyourwindowsnetwork.com/tools.htm) per impostare una password completamente casuale di 100 caratteri per tutti gli account Administrator sulla rete e utilizzare account diversi per la gestione giornaliera. Considerato che l'account Administrator è specifico per i ripristini di emergenza (tranne che su Windows Small Business Server 2003), non dovrebbe avere alcun impatto sul sistema di gestione della rete. Inoltre, l'autore dell'attacco potrebbe riuscire più facilmente a trovare un ago nel pagliaio che a individuare correttamente la password di uno degli account Administrator. Concentrandosi invece su password complesse e univoche, gli script kiddie possono riuscire a individuare tutto ciò che vogliono.

L'importanza della gestione dei rischi
In pratica, qualsiasi misura di sicurezza tramite segretezza può essere analizzata come è stato fatto qui. Esistono i vantaggi e gli svantaggi in qualsiasi schema e non è detto che un approccio adatto per una organizzazione sia altrettanto adatto per un'altra organizzazione. Alla fine, il tutto diventa un problema di gestione dei rischi. I rischi prevalgono sui costi di implementazione della soluzione? Qualsiasi decisione presa per la protezione del patrimonio di informazioni deve essere una decisione di gestione dei rischi consapevole e raramente si tratta di una decisione netta.
In realtà, alcune decisioni sono già state prese al posto dell'utente. Ad esempio, anche se è possibile scegliere di non crittografare le informazioni delle carte di credito o archiviare i codici di verifica delle carte, entrambe le azioni porteranno all'impossibilità di accettare le carte di credito come forma di pagamento. Il possibile impatto negativo che la decisione provoca sull'azienda è che non si ha una vera possibilità di scelta. In altre parole, anche se riguarda la gestione dei rischi, si tratta di una decisione abbastanza facile da prendere.
Analogamente, è anche vero che nessuno sano di mente collegherebbe una rete wireless aperta al back-end della rete interna in un archivio fisico. Tuttavia, ciò non vuol dire che non si tratti di una decisione di gestione dei rischi. In realtà è proprio una decisione del genere. Si può decidere di fare ciò, e se lo si fa, si deve essere in grado anche di sopportare le eventuali conseguenze (che si spera non arrivino mai).
L'azione fondamentale da intraprendere a questo punto è valutare chiaramente il problema da affrontare, le soluzioni proposte per il problema e i vantaggi e gli svantaggi di ciascuna di esse. Fatto ciò, si disporrà di tute le informazioni necessarie per prendere una decisione di gestione dei rischi consapevole. Senza tale informazioni, le decisioni vengono prese in base a mere idee e raramente si rivelano soluzioni efficaci.

Jesper M. Johansson, Software Architect, si occupa del software di sicurezza e collabora con TechNet Magazine come redattore. Ha conseguito il titolo di PhD nei sistemi di gestione delle informazioni e vanta di oltre venti anni di esperienza nel campo della sicurezza; è inoltre Microsoft MVP nella sicurezza aziendale. L'ultimo libro di Jesper è Windows Server 2008 Security Resource Kit.
Roger Grimes (CPA, CISSP, MCSE: Security), Senior Security Consultant per il team ACE di Microsoft, ha scritto, o ha collaborato alla stesura, di otto libri sulla sicurezza dei computer ed è autore di 200 articoli di giornale. Spesso partecipa come relatore a conferenze sulla sicurezza e scrive articoli sulla sicurezza su InfoWorld.
© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.


Security
Nuovi PowerToy per l'elevazione dei privilegi in Windows Vista
Michael Murgolo
Panoramica:
  • PowerToy per l'esecuzione come amministratore per strumenti di script di terze parti
  • PowerToy per l'esecuzione come altro utente
  • Prompt eseguito come sistema per CMD e Windows PowerShell
  • Elevation Gadget di trascinamento
Scarica il codice per questo articolo: Elevation2008_06.exe (197KB)

Ecco un'altra edizione dei PowerToy di elevazione dei privilegi per Windows Vista. Questo argomento è stato illustrato in dettaglio nel numero di giugno 2007 di TechNet Magazine. Un anno dopo ci risiamo. Questa volta, tuttavia, verrà illustrato come la funzionalità per l'esecuzione come amministratore sia stata estesa ad alcuni
dei miei strumenti di script di terze parti preferiti, verrà descritto un metodo per sostituire un'interessante funzionalità di Windows® XP che è stata rimossa da Windows Vista® e verranno analizzati alcuni degli utili strumenti inclusi nei PowerToy di elevazione dei privilegi.

PowerToy per l'esecuzione come amministratore per strumenti di script aggiuntivi
Uno degli argomenti trattati nell'articolo precedente (disponibile all'indirizzo technet.microsoft.com/magazine/cc162321.aspx) riguardava l'attivazione dell'opzione per l'esecuzione come amministratore per gli strumenti di script di Windows nativi. Per questo articolo ho creato i PowerToy per l'esecuzione come amministratore per alcuni strumenti di script di terze parti:
  • AutoIt v3 (www.hiddensoft.com)
  • AutoHotkey (www.autohotkey.com)
  • ActivePerl (www.activestate.com)
  • KiXtart 2010 (www.kixtart.org)
Il codice per ciascuno di questi strumenti è incluso nel download di questo articolo, disponibile all'indirizzo technetmagazine.com. I file effettivi sono denominati ElevateAutoIt3.inf, ElevateAutoHotKey.inf, ElevatePerlScript.inf ed ElevateKiXtart.inf, rispettivamente. Per AutoIt v3, AutoHotkey e ActivePerl, la configurazione è piuttosto semplice. Scaricare semplicemente l'applicazione corrispondente e installarla nella posizione predefinita. Una volta installate le applicazioni a cui si è interessati, è possibile installare il PowerToy per l'esecuzione come amministratore appropriato per ciascuno strumento.
Purtroppo, KiXtart 2010 non include un programma di installazione. Pertanto, per assicurarsi che KiXtart venga installato in una posizione standard in modo da garantire il corretto funzionamento del PowerToy, in questo articolo viene fornito un file INF che consentirà di installare KiXtart 2010 (v 4.60) in Programmi\KiXtart e di registrare l'estensione di file .kix.
Accedere al sito Web www.kixtart.org/?p=downloads, scaricare KiX2010_460.zip e decomprimerlo in una cartella. Copiare il file Install_KiXtart.inf (incluso nel download del codice che accompagna questo articolo) nella stessa cartella. Fare quindi clic con il pulsante destro del mouse su Install_KiXtart.inf e selezionare Install. Infine, installare semplicemente il PowerToy ElevateKiXtart.inf.

PowerToy per l'esecuzione come altro utente
La funzionalità Controllo dell'account utente (UAC) è stata progettata per rendere il sistema operativo meno vulnerabile al malware, configurando il sistema in modo che gli utenti, anche quelli con privilegi di amministratore, eseguano la maggior parte delle applicazioni con privilegi utente standard. Controllo dell'account utente offre la possibilità di elevare i privilegi per l'esecuzione di attività amministrative e altre funzioni delle applicazioni. Questa possibilità di elevazione dei privilegi viene fornita tramite l'opzione per l'esecuzione come amministratore, che viene visualizzata quando si fa clic con il pulsante destro del mouse sui file eseguibili. I PowerToy per l'elevazione dei privilegi trattati nel numero di giugno 2007 hanno esteso questa capacità di utilizzare altri tipi di file e oggetti.
La funzionalità incorporata in Windows Vista funziona piuttosto bene per molte attività amministrative. Tuttavia, in Windows Vista non è stato preso in considerazione uno scenario importante. Molti reparti IT prevedono un criterio in base al quale gli amministratori di rete utilizzano un account utente per le relative attività quotidiane, come l'utilizzo della posta elettronica, la creazione di documenti e simili, e un secondo account utente specifico per l'amministrazione della rete (o amministrazione del computer locale).
Questo avviene allo scopo di ridurre il rischio che un amministratore di rete comprometta l'intero sistema in uso o il dominio in cui risiede nel caso in cui esegua accidentalmente codice malware durante lo svolgimento delle relative attività quotidiane. Questa configurazione è stata implementata in Windows XP utilizzando l'opzione Esegui come..., visualizzata facendo clic con il pulsante destro del mouse. Tuttavia, questa opzione non è stata introdotta in Windows Vista perché è stata sostituita con l'opzione Esegui come amministratore.
Lo strumento da riga di comando runas, tuttavia, è ancora presente in Windows Vista. Purtroppo, non è possibile utilizzarlo per le attività più comuni che prevedono l'utilizzo di due account, eseguendo gli snap-in di Microsoft® Management Console (MMC). Si supponga, ad esempio, che si sia responsabile di alcune attività di gestione di account in Active Directory®. Per l'esecuzione delle attività quotidiane viene utilizzato l'account utente standard e il proprio account di amministrazione di rete è anche membro del gruppo Administrators locale (è possibile quindi installare strumenti di gestione di rete quando necessario) su un computer Windows Vista con la funzionalità Controllo dell'account utente attivata. Si desidera avviare lo snap-in Utenti computer di Active Directory (ADU&C) con l'account amministrativo di Active Directory. Si tenta, pertanto, di eseguire il comando runas, come indicato di seguito:
runas /user:mydomain\admin
"mmc.exe %windir%\system32\dsa.msc"
Tuttavia, questo comando non determina l'avvio di ADU&C, ma viene visualizzato il seguente messaggio di errore: "Per l'operazione richiesta è necessaria l'elevazione dei privilegi". In questo caso l'eseguibile MMC è contrassegnato per l'esecuzione con il livello di privilegio highestAvailable. Poiché il livello highestAvailable per l'account di amministrazione di rete è quello di amministratore, l'avvio di ADU&C utilizzando questo metodo richiede l'elevazione dei privilegi. Poiché il comando runas non determina una richiesta di elevazione dei privilegi, viene generato il messaggio di errore.
Pertanto, in Windows Vista questo scenario risulta particolarmente complesso a causa della mancanza di una voce di menu di scelta rapida per l'opzione Esegui come... e di meccanismi incorporati che consentano di eseguire un processo con un altro nome utente che richiede l'elevazione dei privilegi.
Questo articolo sarebbe piuttosto deludente se non fornisse una soluzione a questo problema; tuttavia, per fortuna, uno dei miei PowerToy di elevazione dei privilegi originali fornisce la chiave per risolvere il secondo problema e nel presente articolo ne viene definito un altro per risolvere il primo problema. Sarebbe bello poter affermare che sono riuscito a escogitare la soluzione al problema correlato all'elevazione dei privilegi, ma questa è stata elaborata da Gov Maharaj del team Windows AppCompat.
Alla fine si scopre che il PowerToy Elevate Command può essere utilizzato con il comando runas. A differenza del comando precedente, il seguente comando è in grado di determinare una richiesta di elevazione dei privilegi:
runas /user:mydomain\admin
"elevate mmc.exe%windir%\system32\dsa.msc"
In tal modo, runas provoca l'avvio di elevate.cmd (dal punto di vista tecnico, il processo avviato è cmd.exe) come altro utente e il comando elevate è responsabile dell'avvio di mmc.exe con una richiesta di elevazione dei privilegi.
Infine, ho utilizzato questo trucco in combinazione con le associazioni per i file .exe e .msc e vi ho associato l'interfaccia utente di un'applicazione HTML per creare un PowerToy che consente di creare l'opzione Run as Another User, disponibile tramite il menu di scelta rapida. Quando si seleziona Run as Another User, viene visualizzata un'applicazione HTML simile a quella riportata nella Figura 1.
Figura 1 Strumento Run as Another User
Figura 1 Strumento Run as Another User (Fare clic sull'immagine per ingrandirla)
Immettere semplicemente il nome utente e il dominio; per un account sul computer locale, selezionare la casella di controllo Use Local Account. È possibile quindi fare clic sul pulsante Run per avviare l'applicazione come utente standard o sul pulsante Run as Admin per avviare l'applicazione con privilegi elevati. Dopo aver fatto clic su uno di questi due pulsanti, runas.exe verrà eseguito e verrà richiesta una password o il PIN della smart card.
Poiché questo PowerToy utilizza il PowerToy Elevate Command, è necessario prima installare quest'ultimo. Fare quindi clic con il pulsante destro del mouse sul file RunAs.inf, selezionare Install e approvare l'elevazione dei privilegi. Per disinstallare lo strumento, utilizzare Programmi e funzionalità nel Pannello di controllo.
Notare che alcuni dei collegamenti relativi ai file .msc in Strumenti amministrativi (come Gestione computer) funzionano correttamente con questo PowerToy. Tuttavia, tenere presente che se si installano gli strumenti amministrativi di Windows Server® 2003 utilizzando adminpak.msi, i collegamenti creati non rappresentano collegamenti standard per i file .msc. Rappresentano invece collegamenti di Windows Installer e, di conseguenza, in Esplora risorse non viene visualizzata l'opzione Run as Another User per questi collegamenti.
Per tali collegamenti sarà necessario individuare i file .msc e fare clic con il pulsante destro del mouse su di essi o creare nuovi collegamenti ai file .msc. Inoltre, il comando runas non funziona con Internet Explorer® a causa delle nuove caratteristiche di progettazione di Internet Explorer per la compatibilità con la modalità protetta di Windows Vista (ulteriori informazioni relative a questo problema sono disponibili all'indirizzo support.microsoft.com/?id=922980).
Nota: nel periodo intercorso tra il completamento di questi PowerToy e la pubblicazione del presente articolo, Windows Sysinternals ha rilasciato un nuovo strumento che, dal punto di vista funzionale, è molto simile al mio PowerToy per l'esecuzione come altro utente. Questo strumento è denominato ShellRunas ed è disponibile sul sito di Windows Sysinternals: technet.microsoft.com/sysinternals/cc300361.
Poiché gli sviluppatore nel team di Sysinternals scrivono codice per professione, è preferibile utilizzare lo strumento da essi creato. È possibile utilizzare il PowerToy illustrato nel presente articolo come esempio del modo in cui questa attività in particolare e le estensioni della shell in generale possano essere eseguite utilizzando applicazioni HTML con codice di script.

CMD e PowerShell Prompt Here as System
Accade talvolta che sia necessario eseguire i programmi nel contesto del sistema locale. Ad esempio, molti strumenti di distribuzione software, come System Center Configuration Manager (SCCM), utilizzano un agente client che viene eseguito come sistema locale per lo svolgimento delle relative attività.
Per verificare il comportamento di un programma di installazione software in esecuzione come sistema locale, prima di tentare una distribuzione con un prodotto, come SCCM, può essere utile avviare il programma di installazione utilizzando un prompt dei comandi in esecuzione come sistema locale. Ho pertanto deciso di creare i PowerToy CMD e PowerShell Prompt Here as System.
In ambiente Windows XP, una funzione come questa viene in genere eseguita con uno script della shell dei comandi:
@echo off
sc create CmdAsSystem type= own type= interact
binPath= "cmd /c start cmd /k (cd c:\ ^& color ec ^&
title ***** SYSTEM *****)"
net start CmdAsSystem
sc delete CmdAsSystem
Tuttavia, se si tenta di eseguire questa funzione da un prompt dei comandi con privilegi elevati in Windows Vista, verrà generato il seguente messaggio di errore e il prompt dei comandi in esecuzione come sistema non verrà visualizzato:
AVVISO:  Il servizio CmdAsSystem è configurato come interattivo, tuttavia il supporto non risulta valido. Il servizio potrebbe non funzionare correttamente.
Il problema è che questo script tenta di creare e avviare un servizio interattivo. I servizi interattivi non funzionano correttamente a causa della funzione Session 0 Isolation introdotta in Windows Vista. Per una descrizione di Session 0 Isolation, vedere il white paper "Services in Windows Vista" disponibile all'indirizzo microsoft.com/whdc/system/vista/Vista_Services.mspx.
Per superare questa limitazione ho utilizzato lo strumento Psexec sviluppato da Sysinternals (visitare il sito Web all'indirizzo technet.microsoft.com/sysinternals/bb897553.aspx). Questo strumento consente di avviare i processi nel contesto di sistema. Purtroppo, la maggior parte degli strumenti di Sysinternals non include un programma di installazione. Pertanto, ho fornito un file INF (disponibile nel download del codice) per installare l'intera suite di Sysinternals (che contiene Psexec) in Programmi\ Sysinternals Suite. Questo file INF crea inoltre i collegamenti del menu Start per gli strumenti grafici della suite.
Per installare la suite, scaricare SysinternalsSuite.zip da technet.microsoft.com/sysinternals/bb842062.aspx e decomprimerlo in una cartella. Copiare il file INF (Install_SysinternalsSuite.inf) nella cartella, fare clic con il pulsante destro del mouse su Install_SysinternalsSuite.inf e selezionare Install. Poiché questi nuovi PowerToy utilizzano il PowerToy Elevate Command, installare quest'ultimo. Successivamente, è possibile installare CmdHereAsSystem.inf e PowerShellHereAsSystem.inf. Una volta installati questi PowerToy, le opzioni CMD Prompt Here as System e PowerShell Prompt Here as System saranno disponibili come voci del menu di scelta rapida per le cartelle e le unità in Esplora risorse, come illustrato nella Figura 2.
Figura 2 Opzioni CMD Prompt Here as System e PowerShell Prompt Here as System
Figura 2 Opzioni CMD Prompt Here as System e PowerShell Prompt Here as System
Nella Figura 3 viene illustrato un prompt CMD eseguito come sistema. I colori chiari indicano che questo prompt viene eseguito come sistema e che, se vengono immessi i comandi errati, è possibile che si verifichino eventi imprevisti che possono causare danni al sistema.
Figura 3 Occorre utilizzare il PowerToy CMD Prompt as System con responsabilità
Figura 3 Occorre utilizzare il PowerToy CMD Prompt as System con responsabilità
Infine, questi PowerToy aggiungono dei comandi al sistema in modo che sia possibile avviare questi prompt nella finestra di dialogo Esegui o in un prompt CMD. Ad esempio, l'esecuzione del seguente comando dalla finestra di dialogo Esegui consentirà di avviare un prompt CMD come sistema nella cartella di Windows:
cmdassystem "c:\windows"
Il comando equivalente per Windows PowerShellTM è psassystem. Tenere presente inoltre che i PowerToy CMD e PowerShell Prompt Here as Administrator sono stati modificati per installare comandi simili: cmdasadmin e psasadmin, rispettivamente.

Elevation Gadget
La maggior parte dei miei PowerToy richiede un clic del pulsante destro del mouse. Tuttavia, a questo aggiornamento ho aggiunto una funzionalità un po' più divertente. Si tratta di un gadget di Windows Sidebar, denominato Elevation Gadget (illustrato nella Figura 4) e rappresenta una destinazione di trascinamento. Trascinare da Esplora risorse un eseguibile o uno script per il quale sia definita un'azione runas. In tal modo, verrà avviato con privilegi elevati.
Figura 4 Elevation Gadget di destinazione
Figura 4 Elevation Gadget di destinazione
Se si sono installati i precedenti PowerToy di elevazione dei privilegi, questo gadget sarà compatibile con gli script di Windows Script Host, gli script di Windows PowerShell, le applicazioni HTML e i pacchetti e le patch di Windows Installer nonché con gli eseguibili e gli script della shell dei comandi per i quali, per impostazioni predefinita, in Windows Vista è definita un'azione runas. È inoltre possibile trascinare più elementi contemporaneamente. Provare a trascinare una cartella nel gadget per vedere cosa succede.
Per installare il gadget, fare doppio clic su Elevation.gadget (disponibile nel download del codice). Se si desidera esaminare il codice per il gadget, aggiungere l'estensione .cab al nome del file. È possibile quindi estrarre il contenuto dal file Cab.

Conclusioni
Il download per questo articolo contiene sia i nuovi PowerToy che quelli dell'articolo originale. Ad alcuni dei PowerToy precedenti sono state apportate lievi modifiche. Ad esempio, le versioni originali di Windows PowerShell Prompt Here as Administrator e di Elevate WSH Script prevedevano l'installazione delle nuove copie di elevate.cmd ed elevate.vbs. Poiché anche alcuni dei nuovi PowerToy sono basati su questi file, ho modificato questi strumenti in modo da richiedere l'installazione del PowerToy Elevate Command (e pertanto condividono tale copia). Per determinare se un PowerToy richiede l'installazione del PowerToy Elevate Command, esaminare l'intestazione nel file INF.
Anche in altri PowerToy originali sono state apportate modifiche secondarie e non funzionali. Disinstallare sempre la versione precedente di un PowerToy prima di installare quella più recente. Poiché questa raccolta ora comprende 17 strumenti, ho incluso gli script della shell dei comandi per installare e disinstallare l'intera raccolta (InstallAllPowerToys.cmd e UninstallAllPowerToys.cmd, rispettivamente). È possibile configurare questi script in modo che vengano installati e disinstallati solo gli strumenti che è necessario utilizzare.
Tenere presente che InstallAllPowerToys.cmd, per impostazione predefinita, non prevede l'installazione dei PowerToy per l'esecuzione come amministratore per gli strumenti di script di terze parti. È possibile modificare questo script in modo che vengano installati solo i PowerToy per i quali si è installato il software. Quando uno di questi script viene eseguito, si riavvia automaticamente con privilegi elevati. UninstallAllPowerToys.cmd determina anche la rimozione di tutte le versioni precedenti di questi strumenti.
Come tutti i PowerToy, questi strumenti non sono supportati e vengono utilizzati a proprio rischio. Tenere presente che non si tratta di prodotti Microsoft ufficiali, ma sono mie creazioni personali. Questi strumenti sono stati testati solo da me e da pochi altri volontari su un sistema Windows Vista a 32 bit in cui viene utilizzato l'inglese come lingua predefinita. Infine, è possibile che tutti o alcuni di questi PowerToy non funzionino con aggiornamenti, service pack o versioni future del sistema operativo Windows.

Michael Murgolo è un consulente senior per le infrastrutture dei servizi di consulenza Microsoft. Lavora in particolare su sistemi operativi, distribuzione, servizi di rete, Active Directory, gestione dei sistemi, automazione e gestione delle patch. È un esperto nell'area della distribuzione e migrazione dei desktop.


Sicurezza
Miglioramenti di Crittografia unità BitLocker
Byron Hynes
Panoramica:
  • Miglioramenti di BitLocker
  • Reperimento e installazione di BitLocker
  • Uso di BitLocker su un server
  • Considerazioni sulla protezione completa dei dati

Nel numero sulla sicurezza di TechNet Magazine dello scorso anno, sono state illustrate brevemente alcune funzioni di Crittografia unità BitLocker di Windows per indicare come è stato implementato nella versione iniziale di Windows Vista. Ora, con il rilascio di Service Pack 1 per
Windows Vista® e il nuovo sistema operativo Windows Server® 2008, è necessario riesaminare BitLocker®.
In questo articolo, verranno trattate alcune delle modifiche apportate all'ultima versione, verrà fornita una panoramica su come installare e utilizzare BitLocker su un server e verranno prese in esame alcune importanti considerazioni pubblicate in articoli recenti. (Per leggere l'articolo dello scorso anno, "Suggerimenti per la protezione dei dati con Crittografia unità BitLocker", andare all'indirizzo technet.microsoft.com/magazine/cc138009.aspx.)

Novità
Le modifiche introdotte in questa versione di BitLocker garantiscono un nuovo livello di flessibilità senza tuttavia alterare le operazioni di base. Le modifiche che verranno riesaminate riguardano il supporto dei volumi di dati, l'autenticazione a tre fattori per l'accesso ai computer, il supporto di Unified Extensible Firmware Interface (UEFI) e del nuovo firmware standard del settore per i sistemi a 64 bit, la protezione avanzata contro gli attacchi crittografici sui metadati del volume e il sempre maggiore utilizzo del Trusted Platform Module (TPM).

Volumi di dati
Nella versione iniziale di Windows Vista, il Pannello di controllo BitLocker consentiva di attivare la crittografia solo per il volume del sistema operativo Windows® (in genere, l'unità C:). Per molti utenti ciò si rivelava sufficiente, dato che i computer di casa in genere sono configurati con tutti i programmi e i dati dell'utente archiviati sullo stesso volume del sistema operativo. Tuttavia, per le aziende, e in particolare per i server, spesso la situazione è diversa. Di conseguenza, una delle richieste più frequenti avanzate dai clienti era la possibilità di crittografare i volumi di dati, ovvero quei volumi diversi dal volume del sistema operativo e che sono installati nel computer (BitLocker non è progettato per crittografare i supporti rimovibili).
Come mostrato nella Figura 1, su questo computer sono disponibili tre volumi utilizzabili. (In realtà, i volumi sono quattro se si considera anche la piccola partizione attiva utilizzata per l'avvio.) Il mio sistema operativo è installato sull'unità C: (ciò è indicato dal "contrassegno" Windows sull'icona) e sono presenti anche due volumi di dati, ovvero E: e P:. Il volume P: è già stato crittografato con BitLocker e al momento risulta bloccato. Il volume E: non è ancora crittografato. In Windows Vista SP1 e Windows Server 2008, è possibile crittografare e sbloccare questi volumi di dati dall'applet del Pannello di controllo BitLocker.
Figura 1 Interfaccia di BitLocker
Figura 1 Interfaccia di BitLocker (Fare clic sull'immagine per ingrandirla)
Se il volume del sistema operativo è crittografato con BitLocker, il comportamento predefinito prevede che i volumi di dati crittografati vengano sbloccati ogni volta che si sblocca il volume del sistema operativo. Se si utilizza il Pannello di controllo per sbloccare un volume di dati, questa opzione sarà disponibile sotto forma di casella di controllo, come mostrato nella Figura 2.
Figura 2 Salvataggio delle chiavi per lo sblocco automatico
Figura 2 Salvataggio delle chiavi per lo sblocco automatico (Fare clic sull'immagine per ingrandirla)
Per attivare o disattivare lo "sblocco automatico" di un volume di dati, è possibile utilizzare lo strumento da riga di comando manage-bde.wsf. Manage-bde.wsf è uno script potente incluso con Windows che utilizza i provider Strumentazione gestione Windows (WMI) sottostanti installati con BitLocker.
Ad esempio, per contrassegnare il volume di dati P: affinché venga sbloccato manualmente, utilizzare il seguente comando:
manage-bde.wsf –autounlock –disable P:
Per riattivare lo sblocco automatico per P:, utilizzare:
manage-bde.wsf –autounlock –enable P:
Il Pannello di controllo BitLocker non espone tutte le funzioni che è possibile eseguire con BitLocker e i volumi di dati e, di conseguenza, è necessario utilizzare l'opzione -? per esplorare i comandi manage-bde.wsf. La sintassi di manage-bde.wsf è inclusa nelle guide "Windows BitLocker Drive Encryption Design Guide" e "Windows BitLocker Deployment Guide", disponibili nell'Area Download Microsoft all'indirizzo go.microsoft.com/fwlink/?LinkId=115215.

TPM+USB+PIN
I clienti desideravano anche utilizzare ulteriori fattori di autenticazione con BitLocker. BitLocker utilizza il chip TPM sul computer per verificare l'integrità della piattaforma, ovvero per controllare che i componenti di avvio iniziali, incluso il BIOS, non siano stati manomessi o danneggiati. Tuttavia, dal rilascio di Windows Vista, è diventato possibile anche richiedere un PIN o la presenza di un'unità flash USB contenente una chiave creata al momento dell'abilitazione di BitLocker.
Con Windows Server 2008 e Windows Vista SP1, si ha la possibilità di utilizzare congiuntamente tutti e tre gli elementi. Il TPM continua a verificare l'integrità della piattaforma, la chiave USB rappresenta "qualcosa di cui si dispone" e il PIN rappresenta "qualcosa di cui si è a conoscenza". Questa configurazione fornisce una protezione avanzata per impedire agli utenti non autorizzati di avviare i computer e sbloccare le unità protette da BitLocker.
Tuttavia, come spesso avviene nel caso della sicurezza, ciò rappresenta un compromesso. Ovviamente, quando BitLocker è configurato in questo modo, un computer non può essere riavviato automaticamente. Nel caso di un server, ad esempio, è necessario stabilire cosa ha la priorità: un riavvio semplice o livelli di protezione più elevati.

Supporto di UEFI
Con Windows Server 2008 e Windows Vista SP1, è stato aggiunto il supporto anche per i computer dotati di Unified Extensible Firmware Interface (UEFI). UEFI è una specifica che rappresenta la versione moderna del BIOS tradizionale utilizzato dalla maggior parte dei computer all'avvio. Per ulteriori informazioni sulla specifica UEFI, visitare il sito www.uefi.org.

Maggiore protezione
Quando BitLocker rileva che il sistema è stato modificato, oppure se un PIN o una chiave USB richiesta non è disponibile all'avvio, viene attivata la modalità di ripristino. Durante il ripristino, i volumi abilitati da BitLocker restano bloccati e viene visualizzata la finestra di dialogo in modalità testo Console di ripristino di emergenza.
Per sbloccare l'unità, è necessario che l'utente immetta una password di ripristino (un numero di 48 cifre) utilizzando la tastiera o un'unità flash USB. (Quando è archiviata su un'unità flash USB, la password a volte è definita "chiave di ripristino" perché è in formato binario e non di testo.)
BitLocker utilizza la password di ripristino per decrittografare le chiavi archiviate nei metadati del volume, ovvero la chiave master del volume (VMK) e la chiave di crittografia dell'intero volume (FVEK), per sbloccare l'unità. Per la riuscita di un ripristino, è necessario che sia disponibile una copia della password di ripristino.
A tale scopo, oltre all'archiviazione eseguita dall'utente (ad esempio, su un'unità flash USB), si consiglia vivamente anche un'archiviazione della password di ripristino a livello centralizzato. Il sistema operativo include la funzionalità per l'archiviazione delle password di ripristino in Servizi di dominio Active Directory® (ADDS).
I segreti archiviati nei metadati del volume, ad esempio la chiave VMK, sono crittografati e l'integrità dei metadati dell'intero volume risulta protetta tramite crittografia. Se BitLocker rileva che i metadati del volume sono stati manomessi, rifiuterà di utilizzarli e non sbloccherà nessuno dei volumi protetti. Tenere presente che la password ripristino non sarà in grado di sbloccare da sola un'unità in questo stato.
È importante evidenziare che questa situazione si verifica solo in presenza di un attacco alla sicurezza intenzionale contro il computer. In una situazione di questo tipo, esistono buone probabilità che il computer sia già caduto nelle mani di un unte malintenzionato e sia fuori dal proprio controllo. Questo problema non deriverà da una semplice modifica non pianificata della piattaforma o dal PIN dimenticato.
Per sbloccare il volume, saranno necessari i tre elementi seguenti:
  • Password di ripristino (come testo da digitare in un'unità flash USB)
  • Pacchetto di chiavi binarie che include le versioni crittografate delle chiavi FVEK e VMK
  • Strumento di ripristino BitLocker
In breve, è necessario che l'azienda abbia sempre la possibilità di accedere a questi elementi.
Il backup della password ripristino può essere eseguito manualmente o automaticamente. Si consiglia di utilizzare l'impostazione Criteri di gruppo per consentire il backup automatico della password di ripristino in Servizi di dominio Active Directory.
Quando si configura questa impostazione, come mostrato nella Figura 3, è necessario includere l'opzione per eseguire il backup del pacchetto di chiavi binarie. Tale pacchetto contiene le versioni crittografate delle chiavi VMK e FVEK, che consentono di utilizzare lo strumento di ripristino BitLocker, se necessario.
Figura 3 Configurazione di Criteri di gruppo per includere i pacchetti di chiavi nelle informazioni di ripristino
Figura 3 Configurazione di Criteri di gruppo per includere i pacchetti di chiavi nelle informazioni di ripristino (Fare clic sull'immagine per ingrandirla)
Lo strumento di ripristino BitLocker è stato progettato per consentire il ripristino dei dati dai dischi danneggiati che sono stati abilitati da BitLocker. Si tratta di uno strumento avanzato, ideato appositamente per gli amministratori esperti. Per ulteriori informazioni sullo strumento di ripristino BitLocker, leggere l'articolo della Microsoft Knowledge Base all'indirizzo support.microsoft.com/kb/928201 oppure visualizzare il mio webcast "Microsoft BitLocker in the Enterprise: BitLocker Tools to Make Your Life Easier" (che include una demo in diretta) all'indirizzo go.microsoft.com/fwlink/?LinkId=114985.
A questo punto, è opportuno ricordare che BitLocker non elimina la necessità di eseguire il backup dei dati. Se il disco è danneggiato o ha subito un attacco intenzionale, non si avrà la certezza che lo strumento di ripristino BitLocker riesca a ripristinare tutti i dati.

Maggiore uso del TPM
Pur non trattandosi di una vera e propria novità introdotta in BitLocker, vale comunque la pena prenderla in considerazione. Prima di SP1, l'unica parte del sistema operativo Windows che utilizzava il TPM era BitLocker, mentre ora viene utilizzato anche per altre funzioni. Quando Windows individua un TPM disponibile, lo utilizza come una fonte di maggiore entropia durante la generazione dei numeri causali. Ciò migliora la qualità di tutti i tipi di crittografia (e consente di far funzionare meglio anche tutto il resto).
Tuttavia, ciò vuol dire anche che non tutti gli eventi correlati al TPM e mostrati nel Visualizzatore eventi sono necessariamente correlati a BitLocker. Un professionista IT ha la responsabilità di accertarsi che tutti gli altri componenti del sistema, e l'eventuale software di altri fornitori, possano utilizzare e utilizzino effettivamente il TPM e che, di conseguenza, consentano la registrazione degli eventi.

BitLocker in Windows Server 2008
Data la base di codice condivisa tra Windows Vista e Windows Server 2008, le modifiche di BitLocker introdotte in SP1 possono essere considerate parte integrante di Windows Server 2008. Ma perché BitLocker è tanto importante su un server? Dopo tutto, BitLocker è progettato per proteggere un computer dagli attacchi offline. Pertanto, BitLocker non offre alcuna protezione a un sistema in esecuzione e si presume che, ovviamente, i server restino in esecuzione ininterrottamente.
Quando viene disattivato, esistono casi in cui un server, o un disco rigido di un server, può essere esposto a un attacco offline. Anche se l'attacco non si verifica, BitLocker può rivelarsi estremamente utile al momento di rimuovere le autorizzazioni di un server o disco rigido, come verrà illustrato più avanti. Osserviamo prima di tutto come installare ed eseguire BitLocker su un server.

Reperimento e installazione di BitLocker
BitLocker è incluso in tutte le edizioni di Windows Server 2008, ma è un componente, o una funzione, opzionale da installare da Server Manager o dalla riga di comando. BitLocker viene implementato, in parte, come driver di filtro NTFS. L'installazione di questo driver di filtro richiede un riavvio del computer e, di conseguenza, l'attivazione di BitLocker su un server richiederà un riavvio. Inoltre, come con Windows Vista, BitLocker richiede una configurazione con carico separato, in cui la partizione attiva utilizzata per avviare il computer resti non crittografata. Lo strumento Preparazione unità BitLocker consente di configurare correttamente i dischi rigidi per il supporto di BitLocker se il server non risulta preconfigurato dal produttore. Tuttavia, se si è esperti del partizionamento dei dischi rigidi, è possibile configurarli manualmente.
Per installare BitLocker in Windows Server 2008, è possibile utilizzare l'interfaccia grafica di Server Manager per selezionare BitLocker dall'elenco di funzioni, come mostrato nella Figura 4, oppure è possibile utilizzare l'interfaccia della riga di comando di Server Manager, generando il comando:
Figura 4 Selezione di BitLocker in Server Manager
Figura 4 Selezione di BitLocker in Server Manager (Fare clic sull'immagine per ingrandirla)
ServerManagerCmd –install BitLocker –restart
Quando si utilizza Server Manager, vengono installati BitLocker e i corrispondenti strumenti di gestione. È possibile inoltre installare i componenti di gestione senza installare BitLocker. Ciò evita la necessità di un riavvio dato che il driver di filtro non è incluso. Il nome di questo componente è "RSAT-BitLocker".
BitLocker funziona alla perfezione sui computer in cui è in esecuzione l'opzione di installazione Server Core, ma non è possibile utilizzare Server Manager per installare BitLocker su Server Core oppure l'interfaccia utente grafica per gestire BitLocker su Server Core. Per installare i componenti, è invece possibile utilizzare lo strumento da riga di comando pkgmgr o ocsetup.
Dopo aver installato i file binari di BitLocker e configurato i dischi nella configurazione con carico separato, è possibile abilitare BitLocker sul volume del sistema operativo. In Windows Server 2008, l'applet del Pannello di controllo BitLocker fornisce le stesse icone e opzioni fornite in Windows Vista SP1. Per abilitare le modalità avanzate di BitLocker, sarà necessario regolare le impostazioni predefinite utilizzando l'editor dei criteri locali o un oggetto Criteri di gruppo valido per il server.
Su Server Core, oppure se semplicemente non si desidera utilizzare il Pannello di controllo, è possibile utilizzare manage-bde.wsf per abilitare BitLocker. Per abilitare BitLocker sull'unità C:, digitare
manage-bde.wsf –on C: -RecoveryPassword –RecoveryKey F:\
dove C: rappresenta il volume da crittografare e F:\ rappresenta una chiave USB o un altro volume in cui verrà archiviata una copia della chiave di ripristino (in formato binario). È anche possibile utilizzare un percorso UNC per archiviare la chiave di ripristino su un'unità di rete. Verrà generata e visualizzata anche una password di ripristino (in formato di testo numerico). Se si è certi che la piattaforma hardware soddisfa tutti i requisiti di BitLocker, è possibile aggiungere il parametro –skiphardwaretest. In questo modo, verrà evitato il riavvio.

Scenari per i server
Prendiamo ora in considerazione alcuni scenari specifici in cui BitLocker si rivela utile per i server. È opportuno ricordare che BitLocker è stato progettato per fornire una protezione dagli attacchi offline, ovvero quei tipi di attacchi realizzati quando Windows non è in esecuzione.
Succursali L'uso di BitLocker su un server si rivela utile nell'ambito della strategia di distribuzione in succursali di Windows Server 2008. Circa un terzo/quarto dei server viene installato nelle succursali, ovvero in uffici con un minore livello di sicurezza fisica, accesso al supporto IT e, probabilmente, connettività ai centri dati. Tra l'altro, le succursali risultano anche il luogo ideale per gli attacchi. Insieme a funzioni quali i controller di dominio di sola lettura, BitLocker consente di proteggere i dati sensibili che devono essere archiviati in una succursale, anche se non si tratta dello stesso livello di sicurezza garantito in un centro dati.
Passiamo ora ad illustrare il livello di protezione appropriato. Cosa si rivela più importante: prevenire un accesso non autorizzato ai dati oppure che un server torni immediatamente operativo senza alcun intervento da parte degli utenti? Il mio parere è che in molte succursali è opportuno richiedere l'immissione di un PIN per il riavvio di un server, anche se la decisione deve spettare all'azienda.
Spedizione di dischi È spesso necessario spedire i dati archiviati in un disco rigido a una destinazione distante. Ciò può comportare la spedizione di un singolo disco oppure la preconfigurazione e la spedizione dell'intero server. Durante la spedizione, i dati contenuti nei dischi risultano non controllati ed è possibile che vengano copiati, perduti o rubati.
Per attenuare questo rischio, è sufficiente abilitare BitLocker sui volumi del computer prima della spedizione e, quindi, rimuovere tutte le protezioni con chiave, ad eccezione di una chiave o password di ripristino. Tale chiave o password può essere spedita separatamente dal server oppure comunicata telefonicamente o tramite un messaggio di posta elettronica crittografato al personale del luogo di destinazione. Dopo aver ricevuto il computer o il disco, la password di ripristino consente di sbloccare l'unità. L'unità può rimanere crittografata (riaggiungendo qualsiasi altra protezione con chiave) oppure può essere decrittografata completamente dopo la spedizione, se lo si desidera.
Questo è un metodo particolarmente efficace per la gestione dei server e dei controller di dominio delle succursali.
Furto di un server Come già messo in evidenza nella sezione precedente, i server (soprattutto i controller di dominio) sono esposti al rischio reale di furto. Può capitare che dei ladri si approprino di un portatile, ma un server può essere un bersaglio molto più ambito. Se BitLocker è configurato per richiedere solo il controllo di integrità TPM, il server rubato potrebbe essere semplicemente accesso e avviato. Al contrario, se le unità in un server sono protette con BitLocker e quest'ultimo è configurato in una modalità avanzata (ovvero, richiede una chiave USB, un PIN o entrambi), sarà molto difficile per i ladri riuscire ad appropriarsi delle informazioni in un lasso di tempo relativamente breve.
Furto di un disco Se un disco viene rubato, il TPM fornisce sempre un livello elevato di protezione. Solo il TPM del server originale può essere utilizzare per bloccare l'unità protetta da BitLocker; di conseguenza, non sarà possibile inserire semplicemente il disco in un altro computer e leggerne i dati.
Minore esposizione ai rischi Ordinando l'hardware per server che include un chip TPM e utilizzando il controllo di integrità della piattaforma BitLocker, è possibile aumentare il livello di protezione da alcuni tipi di malware. In particolare, BitLocker rileverà le modifiche apportate quando Windows è offline oppure quelle introdotte a componenti di avvio iniziali, soprattutto se per l'installazione del malware (ad esempio, un rootkit) è necessario un riavvio. Sebbene questa non sia una soluzione definitiva, se combinata con funzioni come l'integrità del codice di Windows e prodotti come Microsoft® ForefrontTM Client Security, consente di implementare una strategia di difesa in profondità efficace.
Rimozione sicura delle autorizzazioni Uno degli scenari in cui BitLocker si rivela molto utile è alla fine del ciclo di vita di un server o disco. Quante volte si è sentito parlare di utenti che si disfano dei server, o dei i loro dischi, senza rimuoverne le autorizzazioni nel modo corretto? Sapevate che i dischi rigidi usati vendono venduti meglio nei siti di aste di quelli nuovi perché acquirenti privi di scrupoli sperano di accaparrarsi le informazioni preziose in essi contenute?
Fortunatamente, anziché dovere intraprendere un processo oneroso in termini di tempi e denaro per rimuovere dal disco i dati ancora utili, BitLocker consente di agire diversamente. Fondamentalmente, le informazioni non vengono mai scritte nel disco in un formato utile. Considerato che i dati crittografati sono inutilizzabili, è possibile rimuovere tutte le informazioni importanti in modo semplice e rapido. Dopo questa operazione, la sorte dell'hardware del disco non ha più alcuna importanza; può essere venduto, riciclato, riutilizzato o altro ancora senza il timore che i dati possano finire nelle mani sbagliate.
In Windows Vista e Windows Server 2008, il comando di formattazione è stato aggiornato per cancellare le chiavi di BitLocker, incluse le sovrascritture multiple. In questo modo, si avrà ora disposizione un metodo semplice ed efficace per rimuovere le autorizzazioni di un'unità.

Informazioni recenti
Durante la scrittura di questo articolo, avvenuta alcune settimane prima della sua pubblicazione, una serie di recenti articoli, documenti e report hanno illustrato alcune interessanti caratteristiche relative all'hardware e il loro impatto su BitLocker, altre funzioni di sicurezza di Windows e ulteriori prodotti di crittografia di diversi fornitori. Soffermiamoci ora ad analizzare alcune di queste pubblicazioni.
Uno di questi documenti è stato pubblicato dai ricercatori della Princeton University che hanno dimostrato (in modo straordinario!) una caratteristica della memoria dei computer moderni definita anche "residuo di dati nella DRAM" (disponibile all'indirizzo citp.princeton.edu/pub/coldboot.pdf). In parole semplici, è possibile accedere al contenuto della memoria del computer per un determinato periodo di tempo dopo la disattivazione della memoria stessa. BitLocker, naturalmente, mantiene le chiavi per decrittografare i dati nella memoria durante l'esecuzione di Windows e il problema riguarda la possibilità che utenti non autorizzati si approprino delle chiavi.
Un'altra ricerca condotta da Adam Boileau (security-assessment.com/files/presentations/ab_firewire_rux2k6-final.pdf) ha dimostrato come lo standard IEEE 1394 (noto come FireWire) consenta l'accesso diretto alla memoria (DMA), che può essere utilizzata per acquisire i segreti da Windows, quali password o chiavi di decrittografia. Il punto interessante è che il DMA è esattamente lo scopo dello standard IEEE 1394; non si tratta di un difetto, ma piuttosto del motivo specifico per il quale è stato progettato il FireWire.
L'elemento in comune di questi attacchi è che richiedono l'accesso fisico a un computer in esecuzione al momento o che lo sia stato di recente. BitLocker non è progettato per fornire una protezione contro gli attacchi online e non elimina la necessità di un livello di sicurezza fisica. Una corretta strategia di difesa in profondità richiede l'uso di una serie di strumenti e funzioni, la creazione di un ambiente di sicurezza fisica, la definizione di criteri aziendali essenziali e una formazione continua degli utente.
Quelle menzionate non sono delle vere e proprie novità. Sono caratteristiche conosciute da tempo e, in effetti, sono trattate nel Microsoft® Data Encryption Toolkit (DET). L'analisi dei rischi fornita nel DET ha l'obiettivo di consentire ai clienti di raggiungere un equilibrio tra fattori quali la sicurezza, l'utilizzabilità e i costi di implementazione e gestione. Non si tratta di una cosa da poco. Riteniamo che dei clienti con una buona formazione possano decidere meglio in merito ai compromessi da raggiungere tra sicurezza, utilizzabilità e costi.
Oltre al DET, alcuni dei miei colleghi hanno fornito informazioni aggiuntive e una raccolta di commenti davvero preziose. In primo luogo, Russ Humphries ha illustrato i compromessi relativi alla sicurezza nel contesto del "residuo di dati nella DRAM" sul suo blog all'indirizzo go.microsoft.com/fwlink/?LinkId=115217. Quindi, Douglas MacIver ha trattato ulteriori contromisure e operazioni di configurazione che è possibile eseguire oggi sul blog di System Integrity (SI) all'indirizzo go.microsoft.com/fwlink/?LinkId=115218. Si consiglia vivamente di leggere con attenzione questi due blog preziosi. Sarebbe inoltre opportuno leggere anche il DET.
Il suggerimento fondamentale è quello di utilizzare una modalità avanzata (ovvero, una che richiede una chiave USB o un PIN) e di non lasciare un computer non presidiato in modalità sospensione (attivare invece lo stato di ibernazione).

Conclusioni
BitLocker resta una delle funzioni più preziose di Windows Vista. Con il rilascio di SP1, è stato potenziato sulla base dei commenti e suggerimenti dei clienti per abilitare un maggior numero di scenari e soddisfare una più ampia serie di esigenze di protezione dei dati. Il miglioramento della protezione dei dati in Windows Server 2008 offre nuovi modi per proteggere i dati e mantenere la conformità nei casi in cui i dati siano archiviati nei server o nelle workstation client, nel centro dati, nella succursale o con un utente che opera tramite il telelavoro.

Byron Hynes è un Enterprise Technology Strategist di Enterprise and Partner Group (EPG) presso Microsoft, che si occupa delle funzioni e dei prodotti di sicurezza. Prima dell'assunzione in EPG, ha lavorato nella divisione Windows Server e utilizza BitLocker (System Integrity) dal 2005. Sarà lieto di ricevere eventuali commenti e domande da parte vostra. È possibile contattarlo presso Tech•Ed 2008 oppure inviargli un messaggio di posta elettronica all'indirizzo bhynes@microsoft.com.


Security
Blocco di applicazioni con i criteri di restrizione software
Chris Corio and Durga Prasad Sayana
Panoramica:
  • Funzionamento dei criteri di restrizione software
  • Esecuzione dell'inventario delle applicazioni nell'ambiente in uso
  • Creazione e applicazione di criteri

Quando i professionisti IT intendono ridurre il costo totale di proprietà (TCO) dei relativi computer desktop, vengono in genere prese in considerazione due strategie principali. La prima prevede la rimozione degli
account degli utenti desktop dal gruppo Administrators. La seconda consiste nel limitare le applicazioni che gli utenti possono eseguire. La risoluzione di questi problemi può rivelarsi un'impresa alquanto impegnativa in un ambiente aziendale, ma Windows Vista® offre alcune tecnologie che consentono di ottenere questo risultato.
Con Windows Vista e la relativa funzionalità Controllo dell'account utente (UAC) è stato fatto un enorme passo avanti verso la possibilità per i professionisti IT di consentire l'esecuzione dei relativi utenti aziendali come membri del gruppo Users (utenti standard). Con Controllo dell'account utente il contesto di sicurezza predefinito per tutte le applicazioni è stato modificato da amministratore a utente. Questa migrazione al gruppo Users resta un'attività straordinaria ma, man mano che il settore si adegua a questo nuovo paradigma, l'attività verrà ulteriormente semplificata.
Dopo l'analisi dei problemi correlati alla migrazione degli utenti al gruppo Users o, talvolta, durante questo processo, molti amministratori catalogano le applicazioni che i relativi utenti necessitano di eseguire e prendono in considerazione i passaggi necessari per consentire solo l'esecuzione di queste applicazioni. La funzionalità criteri di restrizione software è stata progettata per consentire ai professionisti IT di conseguire esattamente questo scopo.
Occorre semplicemente specificare le applicazioni consentite per l'esecuzione e distribuire il criterio mediante Criteri di gruppo. L'imposizione di un criterio di questo tipo in un'intera organizzazione determina una riduzione del costo totale di proprietà, in quanto questo blocco consente di limitare i problemi correlati alle applicazioni non supportate. È inoltre possibile utilizzare i criteri di restrizione software in alcuni contesti interessanti ed estremi, come illustrato nell'intestazione laterale "Criteri di restrizione software di base".

Funzionamento dei criteri di restrizione software
I criteri di restrizione software sono stati progettati per controllare esattamente il tipo di codice che può essere eseguito da un utente su un computer con Windows Vista. L'amministratore crea un criterio che stabilisce quali applicazioni è possibile o non è possibile eseguire nell'ambiente in uso. Questo criterio viene quindi valutato nel contesto in cui è consentita l'esecuzione del codice, ovvero durante la creazione del processo, in una chiamata a ShellExecute e durante l'esecuzione di uno script. Questo contesto verrà analizzato in maggiore dettaglio più avanti in questo articolo.
Se si stabilisce che un'applicazione può essere eseguita, l'applicazione verrà avviata. Se, tuttavia, si stabilisce che un'applicazione non può essere eseguita, l'applicazione verrà bloccata e l'utente riceverà una notifica. Se, ad esempio, si tentasse di eseguire Solitario dal menu Start, pur non essendo l'esecuzione di questa applicazione, verrebbe visualizzata una finestra di dialogo simile a quella riportata nella Figura 1.
Figura 1 Quando un'applicazione è bloccata viene visualizzata una finestra di dialogo
Figura 1 Quando un'applicazione è bloccata viene visualizzata una finestra di dialogo (Fare clic sull'immagine per ingrandirla)
L'interfaccia utente per la definizione di un criterio di restrizione software è esposta in Editor oggetti Criteri di gruppo, ovvero la posizione in cui viene creato il criterio di blocco. Sono disponibili diversi metodi per definire il tipo di codice che è possibile o non è possibile eseguire. Una volta completato e testato il criterio, è possibile distribuirlo.

Definizione dei criteri di restrizione software
La prima importante decisione da prendere, una decisione che influirà in modo significativo sulla modalità di funzionamento dei criteri di restrizione software nell'ambiente in uso, prevede la selezione di un tipo di regola predefinito. I criteri di restrizione software possono essere distribuiti utilizzando una delle due modalità seguenti: elenco delle applicazioni consentite o elenco delle applicazioni non consentite. In sostanza, queste due modalità consentono di specificare se si desidera creare un criterio che descriva ciascuna applicazione che è possibile eseguire nell'ambiente in uso o un criterio che stabilisca quale applicazione non può essere eseguita.
Nella modalità elenco delle applicazioni consentite la regola predefinita all'interno del criterio è impostata su Con restrizioni e determina il blocco di tutte le applicazioni la cui esecuzione non è consentita. Nella modalità elenco delle applicazioni non consentite, la regola predefinita è impostata su Senza restrizioni e limita solo le applicazioni elencate in modo esplicito.
La modalità elenco delle applicazioni non consentite, come è possibile intuire, rappresenta un approccio poco realistico se si desidera ottenere una riduzione elevata del costo totale di proprietà e conseguire i vantaggi in termini di sicurezza derivanti dal blocco delle applicazioni. La creazione e la gestione di un elenco esteso che blocchi tutti i malware e altre applicazioni problematiche è praticamente impossibile; pertanto, è consigliabile che il criterio di restrizione software venga implementato nella modalità elenco delle applicazioni consentite, che prevede l'utilizzo della regola predefinita Con restrizioni.

Esecuzione dell'inventario delle applicazioni nell'ambiente in uso
Se si prevede di progettare un criterio che specifichi le applicazioni che possono essere eseguite, è necessario determinare esattamente quali applicazioni sono richieste dagli utenti. I criteri di restrizione software offrono una funzionalità di registrazione avanzata con un criterio molto semplice che consente di determinare esattamente quali applicazioni vengono eseguite nell'ambiente in uso.
Su un insieme di computer di esempio all'interno del proprio ambiente distribuire un criterio di restrizione software con la regola predefinita impostata su Senza restrizioni e assicurarsi di rimuovere tutte le altre regole aggiuntive. L'obiettivo è abilitare il criterio di restrizione software ma non utilizzare tale criterio per limitare l'esecuzione delle applicazioni; al contrario, il criterio viene utilizzato semplicemente per monitorare le applicazioni eseguite.
Successivamente, creare il seguente valore del Registro di sistema per attivare la funzionalità di registrazione avanzata e impostare il percorso in cui deve essere scritto il file di registro:
"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\
CodeIdentifiers"
String Value: LogFileName, <path to a log file>
A questo punto, quando un'applicazione viene eseguita e il criterio di restrizione software viene valutato (questo criterio viene valutato anche se è consentita l'esecuzione di tutte le applicazioni disponibili), viene scritta una voce nel file di registro.
Ciascuna voce del registro include il chiamante del criterio di restrizione software e l'ID processo (PID) del processo chiamante, la destinazione valutata, il tipo di regola del criterio di restrizione software selezionata e un identificatore per la regola. Di seguito viene riportata una voce di esempio scritta quando un utente fa doppio clic su notepad.exe:
explorer.exe (PID = 3268) identified
C:\Windows\system32\notepad.exe as Unrestricted using
path rule, Guid =
{191cd7fa-f240-4a17-8986-94d480a6c8ca}
Questo file di registro rappresenta ciascun frammento di codice eseguibile che verrà controllato dal criterio di restrizione software dopo che è stato abilitato e impostato per il blocco delle applicazioni. Ne consegue che per ciascuna voce del file di registro è necessario decidere se deve essere inclusa nell'elenco delle applicazioni consentite. Tenere presente che verranno controllati diversi file binari che fanno parte di Windows® e sono necessari per il corretto funzionamento del sistema.
La tecnica di registrazione descritta in questo articolo offre un metodo chiaro per comprendere esattamente quali applicazioni nell'ambiente in uso verranno rilevate dai criteri di restrizione software. Tuttavia, tale tecnica non rappresenta l'unico metodo per eseguire questa attività.
Lo strumento Inventory Collector, integrato in Microsoft® Application Compatibility Toolkit 5.0, consente di eseguire l'inventario delle applicazioni utilizzate nel proprio ambiente. Questo strumento offre diversi metodi per determinare quali applicazioni sono installate nel proprio ambiente e consente di consolidare i risultati in un database centrale.

Creazione di regole aggiuntive
Dopo aver creato l'elenco delle applicazioni di cui è necessario consentire l'esecuzione nell'ambiente in uso, è possibile creare le regole che consentiranno l'esecuzione effettiva di tali applicazioni. La funzionalità criteri di restrizione software prevede l'utilizzo di due metodi per identificare i criteri: un metodo è basato sulle proprietà di crittografia di un'applicazione, come il relativo hash, mentre l'altro definisce una cartella o un percorso attendibile in cui devono risiedere le applicazioni considerate attendibili.
Nella Figura 2 viene illustrato dove aggiungere le regole per consentire l'esecuzione delle applicazioni nel nodo Criteri restrizione software dell'Editor oggetti Criteri di gruppo (gpedit.msc). Il metodo più semplice per definire le applicazioni nel proprio ambiente consiste nel creare una regola hash per ogni singolo file binario rilevato durante la fase di registrazione.
Figura 2 Utilizzo di gpedit.msc per creare i criteri di restrizione software
Figura 2 Utilizzo di gpedit.msc per creare i criteri di restrizione software (Fare clic sull'immagine per ingrandirla)
Poiché l'hash è un valore univoco restituito per uno specifico insieme di bit, a ciascun file binario nel criterio sarà associato un hash differente. Questo approccio è particolarmente sicuro e consentirà solo l'esecuzione degli specifici file binari presenti nel criterio definito.
Ovviamente, questo approccio presenta delle limitazioni. È possibile, ad esempio, che nell'ambiente in uso siano presenti diverse migliaia di file binari. La creazione di tutte queste regole nell'interfaccia utente dei criteri di restrizione software può rivelarsi piuttosto difficoltosa e, se il numero di regole diventa particolarmente elevato, le prestazioni possono risentirne. Inoltre, l'aggiornamento di ciascuna applicazione nel proprio ambiente richiederà la distribuzione nell'ambiente di una o più nuove regole hash. L'aggiornamento di un criterio così vasto man mano che le applicazioni vengono aggiornate può rappresentare un onere non indifferente.
Per fortuna, per ovviare a questo problema, è possibile utilizzare altri due metodi di identificazione delle regole che consentono di semplificare l'utilizzo dei criteri di restrizione software nell'ambiente in uso. Esplorando ulteriormente il meccanismo di sicurezza crittografica, è possibile creare una regola che consentirà l'esecuzione di qualsiasi file binario firmato da uno specifico certificato.
L'esecuzione di questa attività consente di semplificare la gestione dell'elenco dei criteri in quanto, quando un'applicazione viene aggiornata, i nuovi file binari vengono in genere firmati dallo stesso certificato di quelli precedenti. Tuttavia, se non si desidera che una versione precedente del file binario venga eseguita nel proprio ambiente, è necessario aggiungere la regola hash Con restrizioni in modo da impedire che venga consentita l'esecuzione del file.
Per impostazione predefinita, la valutazione delle regole certificati è disattivata per i criteri di restrizione software. Due sono le ragioni alla base dell'esecuzione di questa operazione.
Primo, le regole certificati nei criteri di restrizione software vengono definite in base agli elementi presenti nell'archivio Autori attendibili del sistema. Poiché l'archivio Autori attendibili viene utilizzato per scopi diversi da quelli delle regole dei criteri di restrizione software, è necessario dedicare maggiore tempo e attenzione quando questo archivio viene utilizzato per la funzionalità criteri di restrizione software.
La seconda ragione è che, per determinare se la firma di un file è valida, è necessario eseguire l'hash del file e confrontarlo con le informazioni sulla firma. L'esecuzione dell'hash di un file è un'operazione molto dispendiosa: per calcolare l'hash è necessario leggere l'intero file dal disco ed elaborarlo.
Per attivare le regole certificati, accedere al nodo Criteri restrizione software e selezionare l'oggetto di imposizione nel riquadro dei risultati. Fare doppio clic per aprire la finestra di dialogo delle proprietà e selezionare l'opzione Imponi regole certificati.
L'altro metodo comune per identificare il codice consiste nell'utilizzare il percorso del codice sul computer locale. Questa è una tecnica efficace ed efficiente, ma presenta una limitazione: è necessario assicurare che le impostazioni di sicurezza siano impostate in modo appropriato nella cartella.
Se si aggiunge una specifica regola percorso e agli utenti è consentito scrivere in tale percorso, ad esempio sul desktop, gli utenti saranno in grado di eseguire tutte le applicazioni desiderate inserendo l'eseguibile nella cartella in questione. Tuttavia, se gli utenti non fanno parte del gruppo Administrators, non saranno in grado di apportare modifiche nella directory Programmi o Windows. Questo implica che, se tutte le applicazioni risiedono nella directory Programmi e gli utenti non fanno parte del gruppo Administrators, sarà necessario ricorrere alle regole percorsi per poter disporre di un criterio semplice ed efficiente.
Le regole percorsi offrono alcune altre funzionalità che le rendono particolarmente appropriate per determinati ambienti. Questa tecnica fornisce il supporto per i caratteri jolly e consente di utilizzare le variabili di ambiente per semplificare la definizione delle regole portabili nel proprio ambiente; dopo tutto, %systemdrive% potrebbe non corrispondere a c:\ per tutti gli utenti.
Quanto alle prestazioni e alla gestione, questo metodo rappresenta probabilmente la soluzione più semplice per identificare il codice. Le regole percorsi sono certamente una soluzione da prendere in considerazione, ma occorre tenere presenti alcune considerazioni di sicurezza aggiuntive.

Regole area rete
I criteri di restrizione software includono un tipo di regola denominato Regola area rete, che ora tuttavia, è diventato obsoleto. L'intento originale di queste regole era basato sull'idea che l'origine di uno specifico codice eseguibile può essere identificata e considerata attendibile e, pertanto, consentirne l'esecuzione. Purtroppo, questo obiettivo è particolarmente difficoltoso da raggiungere e, di conseguenza, questo metodo non ha mai funzionato in modo ottimale. Attualmente, questo tipo di regola non viene applicato nella maggior parte delle posizioni dei punti di ingresso dei criteri di restrizione software.
Nei casi in cui la maggior parte delle applicazioni viene installata nella directory %Programmi% ma altri file eseguibili vengono installati in posizioni differenti e firmati da uno specifico certificato, potrebbe essere opportuno utilizzare tipi di regole differenti. Utilizzando alcune regole hash e un paio di regole percorsi si sarà in grado di ottenere il criterio appropriato.
Tenere presente semplicemente che le regole vengono elaborate secondo uno specifico ordine, come illustrato nella Figura 3. Le regole certificati sono le regole più specifiche, seguono quindi le regole hash, le regole percorsi e infine le regole percorsi contenenti caratteri jolly. Pertanto, se un frammento di codice viene identificato da una regola hash e da una regola percorso, il livello di sicurezza della regola hash avrà la priorità.
Figura 3 Ordine di elaborazione delle regole
Figura 3 Ordine di elaborazione delle regole (Fare clic sull'immagine per ingrandirla)

Imposizione dei criteri
I criteri di restrizione software forniscono un'ampia gamma di copertura sul sistema da proteggere. L'idea è che qualsiasi posizione da cui il codice può essere eseguito deve essere integrata con il criterio di restrizione software e, a sua volta, deve controllare il criterio per verificare se è consentita l'esecuzione del codice eseguibile.
Anche se sono presenti numerose posizioni che controllano i criteri di restrizione software, il punto di ingresso più semplice è CreateProcess. Durante CreateProcess, il criterio viene controllato per determinare se è consentita o meno l'esecuzione del file binario che rappresenta l'applicazione. La verifica dei criteri viene eseguita dall'API SaferIdentifyLevel, che è documentata pubblicamente. Il processo generale è illustrato nella Figura 4. L'API SaferIdentifyLevel verrà trattata in maggiore dettaglio più avanti.
Figura 4 Utilizzo di SaferIdentifyLevel di determinare se un file binario può essere eseguito
Figura 4 Utilizzo di SaferIdentifyLevel di determinare se un file binario può essere eseguito (Fare clic sull'immagine per ingrandirla)
Dopo CreateProcess, l'API più comunemente utilizzata in cui viene imposto il criterio di restrizione software è ShellExecute. Questa API viene chiamata quando l'utente fa clic su un'applicazione nel menu Start o fa doppio clic su un elemento sul desktop.
È possibile chiamare ShellExecute in un'ampia gamma di formati di file. Nel caso di un file .txt, la chiamata di ShellExecute nel file non comporta l'esecuzione del file; dal punto di vista tecnico, il file viene ovviamente aperto. Per questa ragione, i criteri di restrizione software contengono un elenco di tipi di file eseguibili in modo che possano determinare quali tipi di file vengono controllati quando ShellExecute viene chiamata. È possibile personalizzare questo elenco di tipi di file eseguibili nell'interfaccia utente dei criteri di restrizione software.
Oltre a CreateProcess e ShellExecute, sono disponibili altri due punti di integrazione principali: LoadLibrary e host di script. LoadLibrary è ovviamente una posizione importante da cui controllare il codice eseguibile, ma presenta alcuni vincoli speciali.
La maggior parte delle applicazioni include un eseguibile e diverse DLL che vengono caricate. Sul sistema vengono in genere eseguite molte applicazioni. Questo significa che LoadLibrary richiede un numero elevato di controlli dei criteri. A seconda del criterio utilizzato per l'identificazione del codice, l'imposizione di questo punto di ingresso può rivelarsi un'operazione piuttosto dispendiosa. Per avere un'idea, si immagini un contesto che prevede il controllo dell'hash di ogni DLL caricata nel sistema, il che implica l'esecuzione dell'hash del file binario e il confronto di tale file con un elenco costituito probabilmente da migliaia di hash.
Questa funzionalità è disattivata per impostazione predefinita, ma può essere abilitata manualmente A tal fine, accedere al nodo Criteri restrizione software in gpedit.msc e fare doppio clic su Imposizione. Selezionare quindi il pulsante di opzione Tutti i file nel software.
Come affermato, i criteri di restrizione software sono integrati con la maggior parte degli host di script nel sistema, tra cui cmd, VBScript, Cscript e JScript®. Questi punti di ingresso, analogamente agli altri, utilizzano l'API di imposizione dei criteri di restrizione software principale: SaferIdentifyLevel.
L'API SaferIdentifyLevel determina se deve essere consentita l'esecuzione di uno specifico eseguibile in base alle informazioni di identificazione presenti nei criteri di restrizione software pertinenti. Questa API è documentata pubblicamente. Gli host di script di terze parti e gli ambienti eseguibili possono e devono utilizzarla per l'integrazione con i criteri di restrizione software in modo che i criteri possano determinare se consentire l'esecuzione di un frammento di codice eseguibile.

Esecuzione con l'account Utente standard
Una funzionalità non molto nota dei criteri di restrizione software è la capacità di filtrare i privilegi di determinate applicazioni in fase di avvio. Questa funzionalità è stata introdotta in Windows XP, ma non è stata esposta nell'interfaccia utente dei criteri di restrizione software fino al rilascio di Windows Vista.
In tal modo, questa funzionalità può essere considerata un'anticipazione di Controllo dell'account utente di Windows Vista, in quanto può essere utilizzata per eseguire un'applicazione con l'account Utente standard anche quando l'utente è membro del gruppo Administrators. Questa situazione si verifica quando si crea una regola e si imposta il livello di sicurezza sulla modalità di esecuzione come utente normale nell'interfaccia utente di Regole aggiuntive.
Sia la funzionalità di filtraggio dei token di Controllo dell'account utente che le regole di esecuzione come utente normale dei criteri di restrizione software sfruttano i vantaggi di un'API sottostante che implementa lo stesso comportamento dell'API CreateRestrictedToken. Tuttavia, tra le due tecnologie esistono differenze architetturali globali molto significative. In particolare, Controllo dell'account utente si differenzia dai criteri di restrizione software per due aspetti principali.
Primo, in Windows Vista con la funzionalità Controllo dell'account utente attivata, ogni applicazione viene avviata per impostazione predefinita con un token di sicurezza simile a un membro del gruppo Users, anche quando l'utente è un amministratore. Questo risultato può essere ottenuto con i criteri di restrizione software, ma non esiste alcun metodo per avviare un'applicazione con il token di amministratore effettivo dell'utente, ad esempio quando l'utente deve installare un'applicazione. La modifica nel contesto di sicurezza predefinito e la semplicità di accesso al token di amministratore completo di un utente sono i vantaggi principali di Controllo dell'account utente.
La seconda differenza è che, nel caso di eseguibili, lo stesso codice stabilisce il livello di privilegio necessario per il relativo funzionamento. Questa è una distinzione importante in quanto i fornitori di software indipendenti (ISV) e gli sviluppatori sono in grado di comprendere le esigenze del relativo codice. Ad esempio, se un'applicazione del Pannello di controllo deve apportare una modifica che richiede privilegi di amministratore, può specificare tale requisito nel relativo file manifesto. Pertanto, l'ISV può descrivere i privilegi richiesti da un'applicazione piuttosto che imporre un determinato livello di privilegio su di essa senza alcuna possibilità di modificare questo livello.
Per ora, è opportuno evitare di utilizzare le regole di esecuzione come utente normale a meno che non si sia in grado di comprenderne il funzionamento. Controllo dell'account utente rappresenta un metodo eccellente per rimuovere gli utenti desktop dal gruppo Administrators ed è opportuno considerare seriamente l'idea di lasciare abilitata la funzionalità Controllo dell'account utente nell'ambiente aziendale.

Criteri di restrizione software attualmente in uso
Occorre prendere in considerazione diversi fattori quando si utilizzano i criteri di restrizione software. Tuttavia, accade talvolta che i criteri di restrizione software vengano utilizzati senza averne la consapevolezza. Se, ad esempio, si esegue Controllo genitori su un sistema Windows Vista, per controllare l'esecuzione delle applicazioni vengono utilizzati i criteri di restrizione software.
I criteri di restrizione software hanno rappresentato un importante sviluppo tecnologico quando sono stati introdotti per la prima volta in Windows XP. Tuttavia, il blocco delle applicazioni solo ora sta iniziando effettivamente ad attirare l'attenzione dei professionisti IT.
La funzionalità criteri di restrizione software in Windows Vista presenta aspetti che devono essere ancora perfezionati, ma è chiaro che gli amministratori desiderano disporre di un maggiore controllo sulle applicazioni in esecuzione nei relativi ambienti. Per fortuna, questa tecnologia continuerà a evolversi, agevolando per i professionisti IT la gestione dei relativi sistemi e la riduzione dei costi correlati all'esecuzione di un ambiente Microsoft Windows.
Criteri di restrizione software di base
Un'applicazione dei criteri di restrizione software prevede la creazione di un criterio che determina il blocco di Windows in modalità tutto schermo. Per creare questa modalità, Microsoft produce un toolkit, denominato SteadyState™. Tuttavia, se si è interessati solo al blocco delle applicazioni che possono essere eseguite, questo risultato può essere ottenuto con maggiore facilità.
Per consentire l'insieme minimo di applicazioni necessarie per accedere a Windows Vista, creare un criterio che consenta di eseguire logonui.exe e userinit.exe da %windir%\system32. La maggior parte degli utenti richiederà probabilmente che venga consentita l'esecuzione anche delle seguenti applicazioni:
dllhost.exe, rundll32.exe, control.exe (also under %windir%\system32)....
Se si desidera utilizzare la shell di Windows predefinita, è opportuno aggiungere anche %windir%\explorer.exe.
In alternativa, è possibile scegliere di eseguire l'avvio direttamente da un'applicazione, come Internet Explorer®. In tal caso, sarà necessario elencare iexplore.exe anziché explorer.exe.
Un altro aspetto di questi criteri di base è che gli utenti non devono essere membri del gruppo Administrators. Questo requisito è importante in quanto impedisce che il criterio venga ignorato dagli utenti. Tuttavia, poiché possono eseguire solo un insieme di applicazioni di base e non dispongono di privilegi di amministratore, gli utenti non disporranno neppure dei privilegi necessari per installare le applicazioni o gestire il sistema.
Pertanto, per eseguire queste attività per i computer in questione, sarà necessario disporre di metodi specifici. Se si intende aggiornare e gestire questi computer eseguendo l'accesso localmente con un account di amministratore, è consigliabile selezionare il pulsante di opzione che prevede l'applicazione dei criteri di restrizione software a tutti gli utenti eccetto gli amministratori locali. I criteri devono includere anche consent.exe e cmd.exe. Questo consentirà all'amministratore di avviare qualsiasi opzione di amministrazione da un prompt cmd con privilegi di amministratore.
Notare che la funzionalità Controllo dell'account utente, per impostazione predefinita, limita i privilegi del token di sicurezza dell'utente in modo da dare l'impressione che il token non sia membro del gruppo Administrators. Anche se si configura l'impostazione sopra riportata in modo che il criterio non venga applicato agli amministratori, tale criterio verrà comunque applicato agli utenti. Solo quando si utilizza la funzionalità di elevazione dei privilegi di Controllo dell'account utente, l'amministratore potrà disporre di privilegi di amministratore completi e il criterio di restrizione software non verrà applicato.

Chris CorioChris Corio è stato membro del team Windows Security in Microsoft per oltre cinque anni. I suoi interessi si rivolgono principalmente al campo delle tecnologie di sicurezza delle applicazioni e delle tecnologie di gestione per la sicurezza di Windows. È possibile contattare Chris all'indirizzo winsecurity@chriscorio.com.
Durga Prasad SayanaDurga Prasad Sayana è Software Design Engineer responsabile dei test nel team Windows Core Security. I suoi interessi si rivolgono principalmente al campo delle tecnologie di sicurezza e dei test del software. È possibile contattare Durga all'indirizzo durgas@microsoft.com.


Sicurezza
Gestione del firewall di Windows Vista
Jesper M. Johansson
Panoramica:
  • Tipi di regole e scenari
  • Profili di firewall
  • Regole di isolamento del dominio
  • Il problema con il filtro in uscita

Poco tempo fa ho scritto un articolo nel mio blog sul firewall di Windows Vista. In quell'articolo ho semplicemente evidenziato alcune funzioni che ritenevo importanti ma senza scendere nel merito dello sviluppo.
In questo articolo, approfondisco alcune delle funzioni del firewall di Windows Vista® pensate in modo specifico per facilitare la gestione aziendale. Fornirò anche consigli su come usarle per semplificare il lavoro e garantire una maggiore protezione agli utenti.
L'ultimo rilascio del Service Pack 1 per Windows Vista potrebbe far pensare che le aziende si decidano a implementare Windows Vista (generalmente le aziende aspettano il rilascio del primo Service Pack prima di migrare a un nuovo sistema operativo). I professionisti IT che stanno prendendo in seria considerazione Windows Vista per l'ambiente aziendale dovrebbero esaminare più a fondo il firewall. Una volta capito cosa può fare il firewall di Windows Vista, è possibile rinegoziare il contratto con terze parti per la suite di protezione e rimuovere il firewall dal pacchetto.

Breve storia dei firewall di Windows fino a oggi
Il firewall nella versione originale di Windows® XP lasciava molto a desiderare. Sebbene rispondesse bene alla funzionalità di protezione tipica dei firewall basati su host allora in commercio, non aggiungeva niente di nuovo o innovativo.
La versione in dotazione con Windows XP SP2 venne completamente modificata proprio per facilitare la gestione aziendale. Il firewall di Windows XP SP2 ha molti pregi in quanto è leggero, gestibile a livello centrale, efficace e non invadente. Ma soprattutto protegge il sistema all'avvio.
Questa caratteristica è cruciale. Ho visto molti sistemi in passato infettarsi durante l'avvio anche con un firewall in funzione. Infatti, al culmine dell'epidemia di Blaster, la frequenza degli attacchi era di uno in quattro minuti. In altre parole, se avessimo lasciato un computer senza protezione in Internet, sarebbero bastati quattro minuti per infettarlo. E se stavamo usando un firewall che non proteggeva il sistema all'avvio, un sistema su 12 sarebbe stato infettato al riavvio. Sono state queste cifre a far sì che Microsoft garantisse la protezione del sistema all'avvio con il firewall di Windows XP SP2.
In Windows Vista il firewall è stato completamente trasformato. La modifica più ovvia, dal punto di vista della gestione, è stata la fusione delle interfacce di gestione del protocollo IPsec (Internet Protocol Security) con il firewall. Si tratta di una modifica molto logica. IPsec e il firewall sono progettati entrambi per bloccare elementi non consentiti. La differenza è che nel firewall i parametri che definiscono cosa è permesso non sono molto granulari mentre in IPsec il blocco o l'ammissione di grandi porzioni dello spazio degli indirizzi è scomodo.
Grazie alla compresenza delle due funzioni in una singola interfaccia di gestione, gli amministratori possono usare entrambe le tecnologie senza problemi e senza preoccuparsi troppo se applicare una regola IPsec o un filtro firewall. In sostanza, si ha una vista unica della superficie di attacco della rete del sistema e quindi si riduce il rischio di errori.
Il Service Pack 1 per Windows Vista aggiunge alcuni miglioramenti dell'affidabilità alle funzioni del firewall. Aggiunge anche nuovi algoritmi, in particolare gli algoritmi Suite B adatti a IPsec. Si tratta di una serie di algoritmi basati sulla crittografia, compresi AES (Advanced Encryption System, ECC (Elliptic Curve Cryptography) e SHA (Secure Hash Algorithm) 256 e 384.
Ma più importante di tutti è il fatto che il Service Pack 1 aggiunge il supporto per NAP (Network Access Protection). NAP è uno strumento di applicazione dei criteri che garantisce che i client gestiti e non compromessi vengano aggiornati con i criteri di protezione, gli aggiornamenti e le definizioni antimalware più recenti prima che possano connettersi alla rete. NAP non può impedire agli host pericolosi di connettersi alla rete ma assicura che tutti gli host gestiti siano completamente conformi purché non vengano attivamente compromessi.
Il firewall di Windows Vista, chiamato Windows Firewall with Advanced Security, è incluso anche in Windows Server® 2008. Inoltre tutte le funzioni possono essere gestite in remoto e configurate in una rete mediante criteri di gruppo.

Tipi di regole e scenari
La combinazione delle funzionalità del firewall e di IPsec nell'interfaccia di gestione comporta due tipi diversi di regole: regole direzionali e regole di connessione. Le regole direzionali sono regole standard del firewall che definiscono quale traffico consentire nella giusta direzione. Le regole di connessione definiscono i parametri di protezione per le connessioni tra i computer. Per fare un'analogia, le regole direzionali sono un poco simili alle regole dei firewall precedenti mentre le regole di connessione sono più simili alle regole IPsec usate insieme al firewall in Windows XP SP2.
Combinando il firewall e IPsec nella stessa interfaccia, si aprono diversi scenari molto interessanti. Ad esempio, uno dei concetti sulla protezione oggi più preziosi è l'isolamento di ogni sistema nella rete. Questo concetto in Microsoft è chiamato "isolamento di dominio e server".
L'isolamento di dominio e server usa la funzionalità sia di IPsec che del firewall. Pertanto la nuova interfaccia di gestione del firewall include funzionalità specifiche per le regole di isolamento. Ciò è valido se, ad esempio, si intende limitare la connessione in base agli attributi dei sistemi di origine o destinazione, come l'appartenenza a un dominio.
Come si vede nella Figura 1, la Creazione guidata nuova regola di protezione della connessione inizia chiedendo che tipo di regola si intende creare. Se si sceglie l'isolamento, la procedura guidata preconfigura determinate impostazioni che sono appropriate a una regola di isolamento.
Figura 1 Uso della Creazione guidata nuova regola di protezione della connessione per creare una regola di isolamento
Figura 1 Uso della Creazione guidata nuova regola di protezione della connessione per creare una regola di isolamento (Fare clic sull'immagine per ingrandirla)
Nella Figura 1 è inoltre possibile notare che la regola di isolamento riguarda anche lo stato di integrità. Le regole usate per l'isolamento di dominio e server sono effettivamente le stesse regole usate per NAP.
Non è possibile applicare l'autenticazione ad alcuni tipi di traffico. Ad esempio, probabilmente non si desidera richiedere l'autenticazione per la risoluzione dei DNS. Per gli endpoint di quel tipo di traffico è necessaria una regola di esenzione dell'autenticazione. Un regola di esenzione dell'autenticazione esenta il traffico dai requisiti IPsec.
Il nome della regola di connessione tra server può essere fuorviante: sebbene usata più spesso con i server, può essere usata anche con i client. Una regola di connessione tra server semplicemente configura una connessione che richiede l'autenticazione. Si differenzia da una regola di isolamento in quanto quest'ultima non solo richiede l'autenticazione ma richiede anche il rispetto di determinati altri criteri come l'appartenenza a un dominio e lo stato di integrità.
Una regola di tunneling sostanzialmente definisce una VPN (Virtual Private Network) da sito a sito e il tunnel tra i gateway. Le regole di tunneling sono usate di rado con Windows Vista, in quanto è improbabile che si usi Windows Vista in una capacità gateway. È possibile creare regole del tutto personalizzate. Pertanto è possibile personalizzare ogni parametro della regola.

Ordine delle regole
A un primo sguardo l'ordine delle regole sembra un poco complicato. Il segreto per capirlo è proprio dimenticare il concetto di ordine, in quanto si tratta più di una selezione di corrispondenze (rispetto dei requisiti di una regola) che di un ordine vero e proprio. Consideriamo il traffico in entrata come esempio. Il traffico in entrata che non soddisfa nessuna regola viene bloccato per impostazione predefinita. Questa assunzione potrebbe essere considerata come un ordine secondo cui le regole di autorizzazione vengono per prime, ma non sarebbe corretto. Se un determinato pacchetto soddisfa sia una regola di autorizzazione che una regola di blocco, prevale la regola di blocco. Spieghiamo in parole semplici la corrispondenza:
  1. Regole di blocco. Se un pacchetto o una connessione soddisfa una regola di blocco viene scartato.
  2. Regole di autorizzazione. Se un pacchetto o una connessione soddisfa una regola di autorizzazione viene permesso.
  3. Comportamento predefinito del profilo direzionale. Se non viene rispettata nessuna regola di blocco o di autorizzazione, il traffico verrà considerato secondo il comportamento specificato in quel profilo come predefinito per il traffico in quella direzione. Nella direzione in entrata in tutti i profili, il traffico viene bloccato in una configurazione predefinita. Nella direzione in uscita, per impostazione predefinita il traffico viene autorizzato nella configurazione predefinita.
Il processo di corrispondenza è moderato dalle regole IPsec di bypass autenticato. Usando quel tipo di regola, tutto il traffico autenticato che soddisfa gli altri parametri della regola viene autorizzato indipendentemente dal fatto che soddisfi o meno altre regole. Le regole di bypass autenticato sono regole direzionali in cui è selezionata l'opzione per ignorare le regole di blocco, come mostrato nella Figura 2. Queste regole vengono considerate per prime per permettere al traffico autenticato di raggiungere sempre il sistema. Ciò è essenziale per facilitare l'autorizzazione del traffico da host autenticati e il blocco del traffico proveniente da altre origini. Questa regola può essere considerata la 0 nell'ordine. Di conseguenza l'elenco dell'ordine completo delle regole somiglia al seguente:
Figura 2 Selezione dell'opzione per ignorare le regole di blocco per configurare una regola di bypass autenticato
Figura 2 Selezione dell'opzione per ignorare le regole di blocco per configurare una regola di bypass autenticato (Fare clic sull'immagine per ingrandirla)

0. Regole di bypass autenticato
1. Regole di blocco
2. Regole di autorizzazione
3. Comportamento predefinito del profilo direzionale

L'eventuale presenza di più regole in ogni classe che rispondono al modello di traffico non è veramente importante. Non appena viene stabilita una corrispondenza tra una regola e il traffico, l'elaborazione della regola viene interrotta.

Pubblico, privato e di dominio
Risorse sulle connessioni in rete
  • TechNet Security Center (in inglese)
  • Using the Netsh Advfirewall Command-Line Tool (in inglese)
  • Regole di protezione per Windows Firewall e per connessioni basate su IPsec in Windows Vista e in Windows Server 2008
  • Security Watch Using SCW on Windows Server 2008 (in inglese)

Il nuovo firewall ha tre profili: pubblico, privato e di dominio. Il firewall di Windows XP SP2, invece, ha due profili di rete: standard e di dominio. Il profilo di dominio viene richiamato automaticamente quando il computer è in grado di trovare il controller del dominio. Diversamente, in Windows XP veniva usato il profilo standard. Questo profilo forniva una potente funzionalità grazie alla quale un amministratore della protezione poteva bloccare completamente il computer quando questo eseguiva il roaming e permettere comunque tutte le funzionalità di gestione in remoto necessarie quando era presente nella rete di un'organizzazione. Ma questo approccio presentava determinati problemi ad alcuni utenti: in particolare a coloro con reti personali domestiche. Poiché veniva sempre usato il profilo standard se il sistema non era in grado di raggiungere il controller del dominio, il sistema veniva bloccato dall'abitazione dell'utente.
Il nuovo profilo privato incluso in Windows Vista aiuta a risolvere questo problema. Ora quando si connette il sistema a una nuova rete, viene chiesto se la rete è pubblica (pubblico è semplicemente il nome nuovo del procedente profilo standard) o privata e il sistema viene configurato appropriatamente. Il sistema lo ricorda ogni volta che si collega a quella particolare rete, in base ai parametri presentati dai server dell'infrastruttura nella rete. Non è una soluzione perfetta ma è comunque utile perché consente di bloccare meglio più reti.
È stata migliorata anche la logica di rilevamento della presenza del sistema nel dominio. Di conseguenza la transizione è più veloce e affidabile e c'è un numero minore di sistemi che ritengono di dover usare profili pubblici o privati quando in realtà si trovano nel dominio.
È possibile associare le regole a un determinato tipo di rete per impedire al sistema di fornire spontaneamente troppe informazioni e di tentare la connessione a sistemi in rete non attendibili. Questa è un'area in cui l'integrazione del firewall e IPsec si dimostra particolarmente valida.
Usando queste nuove regole, è possibile porre alcune limitazioni in precedenza impossibili. Ad esempio, da molti anni gli hacker inducono gli utenti a fare connessioni di rete Windows SMB (Server Message Block) a host non attendibili e quindi li costringono a una sequenza di autorizzazioni challenge-response che può essere usata per individuare le password. Anche le versioni più vecchie di questo attacco sono state usate per il downgrade, in modo da cancellare l'autenticazione del testo o da riflettere la coppia challenge-response dell'utente nel computer di origine. La tecnica più vecchia è stata smantellata anni fa. Quella più recente è stata mitigata da Windows XP SP2, ma non dobbiamo dimenticare che non è mai prudente fornire spontaneamente coppie challenge-response.
Per impedire questo rischio è possibile usare una nuova funzione nel firewall di Vista: il filtro in uscita. Ad esempio, un amministratore potrebbe decidere di bloccare tutte le connessioni SMB in uscita (quelle che terminano alle porte TCP 135, 139, 445 e UDP 137, 138, 445) nel profilo pubblico. In questo modo diventa più difficile usare un sistema in un attacco mirato a ottenere coppie challenge-response o si impedisce al sistema di accedere a condivisioni file di Windows non attendibili in Internet.
Anche questa soluzione non è infallibile. Ad esempio, se il sistema è già compromesso, questa regola non gli impedisce di comunicare, dato che potrebbe essere semplicemente disattivata dall'kacker. Tuttavia può rivelarsi molto utile come misura di protezione di sistemi sani ma potenzialmente esposti.
È importante sottolineare che in questo contesto, proprio come in Windows XP SP2, può essere attivo un solo profilo alla volta in Windows Vista e Windows Server 2008. Se nel sistema convivono due interfacce di rete e una si trova nel dominio mentre l'altra in una rete pubblica, a entrambe verrà applicato il profilo di firewall pubblico. Verrà usato sempre il profilo più restrittivo. Come si può immaginare, il profilo pubblico è più restrittivo di quello privato e quest'ultimo è più restrittivo di quello dominio. Pertanto tenere presente che la regola di blocco SMB in uscita può interrompere molto del traffico nelle connessioni VPN.
Per consentire il traffico in una connessione VPN quando il computer è in una rete pubblica o privata, vengono create le regole direzionali che valgono solo per le interfacce VPN. Affinché queste regole funzionino, le interfacce VPN devono essere riconosciute in quanto tali da Windows. Se non si usa il server VPN dei servizi Routing e Accesso remoto di Microsoft®, provare questa funzionalità prima di distribuirla su larga scala. È un problema che riguarda principalmente il traffico in entrata nel client e le regole personalizzate per il traffico in uscita eventualmente create.

Creazione di regole del firewall
La creazione di una regola è molto più facile nel nuovo firewall. La Creazione guidata nuova regola, mostrata nella Figura 3, consente di definire tutti i tipi generali di regole. Include anche regole predefinite per determinati servizi.
Figura 3 Regole predefinite nella Creazione guidata nuova regola
Figura 3 Regole predefinite nella Creazione guidata nuova regola (Fare clic sull'immagine per ingrandirla)
Le regole predefinite sono particolarmente importanti. L'isolamento del server consiste essenzialmente nel limitare determinati servizi, rendendoli disponibili solo per quei sistemi che necessitano di usarli. Per facilitare questa operazione nel caso dei prodotti server, è possibile usare la Configurazione guidata impostazioni di sicurezza di Windows, sebbene non senza qualche difficoltà (ho parlato di questa procedura nell'edizione di marzo 2008 di TechNet Magazine).
Finora le versioni client di Windows non hanno avuto una funzionalità simile. Quando si usa il tipo di regola predefinita, gran parte del lavoro più impegnativo, cioè la determinazione di quali endpoint vengono usati da un servizio, viene svolta automaticamente. Il firewall non solo è in grado di riconoscere quale programma il servizio iSCSI rappresenta ma contiene anche regole predefinite che descrivono una determinata funzionalità. Ciò consente di concentrarsi su quali computer devono essere considerati in una regola. Quest'attività è comunque difficile e lunga ma almeno è esclusiva del proprio ambiente.
Esiste anche una regola personalizzata (nascosta dal menu a discesa nella Figura 3) che offre tutta la flessibilità che ci si aspetta da un firewall di autenticazione. Ad esempio, se si desidera definire una regola che consente solo il traffico crittografato IPsec, è possibile selezionare l'opzione che autorizza solo le connessioni protette, nella pagina Azione della procedura guidata, mostrata nella Figura 2.
Quando si seleziona questa opzione è possibile anche attivare la crittografia. Se non si seleziona questa opzione, il traffico userà ESP-NULL (Encapsulated Security Payload con una chiave NULL). Se si intende usare IPsec per l'autenticazione, si consiglia di adottare questo metodo in quanto consente a molti strumenti di gestione della rete di continuare a operare, visto che il traffico sta attraversando la rete in chiaro e, se si vuole usare la crittografia, basta selezionare la casella.
In molte situazioni, crittografare il traffico della rete non è efficace come rifiutare tutto il traffico proveniente da host pericolosi. Con la crittografia del traffico della rete si blocca un utente malintenzionato che ha ottenuto l'accesso alla rete autonomamente guardando il contenuto del pacchetto. L'obbligatorietà dell'autenticazione può impedire innanzitutto l'invio del pacchetto e quindi l'attacco. Ci sono molte situazioni in cui la crittografia a livello di rete è importante ma ci sono anche molte altre situazioni in cui solo l'autenticazione è efficace.

Creazione di regole di isolamento del dominio
In molti ambienti, può essere necessario limitare il numero di computer in grado di inviare traffico a una workstation. Come minimo, tutte le workstation dovrebbero essere configurate con regole di isolamento del dominio. Questa operazione era complicata in Windows XP ma è facile in Windows Vista.
Innanzitutto aprire lo strumento di gestione che si preferisce, quindi selezionare il nodo Regole di protezione delle connessioni. Quindi fare clic con il pulsante destro del mouse sul nodo e selezionare Nuova regola; verrà visualizzata la finestra di dialogo mostrata nella Figura 1. Selezionare la regola Isolamento e fare clic su Avanti. A questo punto occorre selezionare se si desidera l'applicazione della regola. In molte workstation può essere necessario esigere l'autenticazione per il traffico in entrata. In questo modo si impedisce a eventuali computer non appartenenti al dominio di inviare traffico alla workstation. Tuttavia, per richiedere i servizi dall'infrastruttura, il sistema deve autorizzare il passaggio in chiaro di un certo traffico in uscita. La scelta migliore, pertanto, è esigere l'autenticazione per le connessioni in entrata e valutare l'autenticazione delle richieste di connessioni in uscita a seconda dei casi.
Quindi scegliere il metodo di autenticazione. La selezione predefinita non ha un nome particolarmente utile. È possibile configurare il metodo di autenticazione predefinito per ogni computer nelle proprietà IPsec (a cui si accede facendo clic con il pulsante destro del mouse sul nodo Windows Firewall con protezione avanzata e selezionando Proprietà). Il metodo di autenticazione predefinito è sempre Kerberos dato che è quello più semplice e sicuro. Tuttavia, per chiarezza, consiglio di selezionarlo effettivamente quando si creano le regole. Di solito si desidera autenticare solo il computer e non anche l'utente. Se è necessario autenticare entrambi, si potrebbe non essere in grado di accettare determinati tipi di traffico, come il traffico SNMP trasmesso in modo anonimo.
Dopo aver selezionato il metodo di autenticazione, è sufficiente selezionare i profili in cui dovrà essere disponibile questa regola. Poiché si tratta di una regola che si applica ai computer appartenenti al dominio, con l'eventualità della presentazione di un ticket Kerberos, non ha senso aprire questo varco nei profili privati o pubblici. Per finire salvare la regola.
Le regole di isolamento di base ora non sono più complicate. Tuttavia, per sfruttare la potenza di IPsec per l'isolamento, è necessario implementare l'isolamento del server anche nelle workstation. In questo modo è possibile impedire alle workstation l'ascolto di altri client e fare in modo che rispondano solo alle stazioni di gestione appropriate. È facile immaginare di quanto si ridurrebbe l'impatto delle varie interruzioni dovute a malware se i sistemi client si rifiutassero di ascoltare altri client.

Scrittura dello script del firewall
Il nuovo firewall è dotato di una solida API che consente di codificare sia la distribuzione che la valutazione. L'ideale sarebbe usare i criteri di gruppo per la distribuzione ma, poiché i criteri di gruppo non sono sempre disponibili, è importante disporre di un'impostazione API appropriata per configurare il firewall. Le API sono raggruppate nell'insieme INetFWPolicy2. Il Software Development Kit e MSDN® Library contengono dettagli più completi su come usarle ma è utile comunque fare alcuni esempi.
Un esempio comune riguarda la necessità di determinare se un gruppo di regole è attivato. Supponiamo, ad esempio, che un'applicazione o un amministratore debba determinare se la condivisione file e stampanti è permessa da un sistema. A questo scopo si usa INetFWPolicy2::IsRuleGroupCurrentlyEnabled. La Figura 4 presenta uno script VBScript che esemplifica questa funzione.
Figure 4 Uso di INetFWPolicy2::IsRuleGroupCurrentlyEnabled
' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")

' Get the Rules object
Dim RulesObject
Set RulesObject = fwPolicy2.Rules

'Create a profile object
Dim CurrentProfile
CurrentProfile = fwPolicy2.CurrentProfileTypes

'Check whether File and Printer Sharing is on, and turn it on if not
if fwPolicy2.IsRuleGroupEnabled(CurrentProfile, "File and Printer Sharing") <> TRUE then
    fwPolicy2.EnableRuleGroup CurrentProfile, "File and Printer Sharing", TRUE
end if
Ora, se la condivisione file e stampanti è disattivata ed è necessario attivarla, prima di tutto è necessario assicurarsi che sia fattibile e che non prevalgano i criteri di gruppo. A questo scopo si usa l'API INetFWPolicy2::LocalPolicyModifyState. Di seguito è riportato un esempio che può essere completato con il codice vero e proprio:
Const NET_FW_MODIFY_STATE_OK = 0
Const NET_FW_MODIFY_STATE_GP_OVERRIDE = 1
Const NET_FW_MODIFY_STATE_NO_EXCEPTIONS = 2

Dim PolicyModifyState
PolicyModifyState = fwPolicy2.LocalPolicyModifyState
Select Case PolicyModifyState
  Case NET_FW_MODIFY_STATE_OK
  Case NET_FW_MODIFY_STATE_GP_OVERRIDE
  Case NET_FW_MODIFY_STATE_NO_EXCEPTIONS
End Select

Riga di comando e tipi di interfaccia
Nessun firewall sarebbe completo senza un'appropriata riga di comando per la gestione. In netsh è presente un contesto secondario chiamato advfirewall. Il contesto advfirewall fornisce l'accesso dalla riga di comando per compiere tutte le operazioni che è possibile eseguire nella GUI. Ad esempio, se si desidera implementare il blocco in uscita sulla porta 445, è possibile eseguire il comando seguente da un prompt dei comandi con privilegi elevati:
netsh advfirewall firewall add rule name="Block CIFS Out in the Public profile"
dir=out action=block enable=yes profile=public
localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=any
Quindi è necessario eseguire lo stesso comando, sostituendo TCP con UDP per completare il blocco. A questo punto, è stata completata l'implementazione della regola.
Una funzione speciale del firewall è la capacità di configurare le regole in base al tipo di interfaccia di rete. Il richiamo di queste regole può influire sulle connessioni VPN. È possibile usare questo tipo di regola per escludere il traffico in quell'interfaccia purché Windows riconosca l'interfaccia come interfaccia VPN:
netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces"
dir=out action=allow enable=yes profile=public localIP=any
remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS
Questa operazione può essere eseguita anche nella GUI ma solo dopo la creazione della regola. Quindi è necessario fare clic con il pulsante destro del mouse sulla regola, selezionare Proprietà e fare clic sulla scheda Avanzate. In questa scheda c'è una sezione con i tipi di interfaccia che è possibile selezionare.

Filtro in uscita
La mancanza di un filtro in uscita nel firewall di Windows XP SP2 è stata vista come la prova principale che il firewall incorporato non era adatto alla protezione. Ci saranno migliaia di articoli in cui si sostiene che il firewall di Windows XP SP2 non è sicuro a causa dell'assenza del filtro in uscita, nonostante il fatto che in effetti nessun firewall in Windows XP potrebbe fornire in modo sicuro un filtro in uscita.
La funzionalità essenziale alla trasformazione di un filtro in uscita da mero aspetto legato alla velocità, o strumento di applicazione dei criteri come ho fatto io in precedenza, a un'utile funzione di protezione, semplicemente non esiste in Windows XP. Esiste invece in Windows Vista. È una logica conseguenza che il nuovo firewall usi questa funzionalità. Per impostazione predefinita, viene bloccata la maggior parte del traffico in entrata e viene consentita la maggior parte del traffico in uscita.
Per impostazione predefinita, il filtro in uscita nel nuovo firewall di Windows Vista blocca solo il traffico inutile proveniente dai servizi. Questo è il massimo che si può fare effettivamente per la protezione, considerando l'host che fornisce i filtri in uscita e l'inutilità di ciò in Windows XP.
I servizi in Windows Vista possono essere eseguiti con un token molto limitato. In sostanza, ogni servizio ha un proprio esclusivo identificativo di sicurezza (SID). Questo SID può essere usato per limitare l'accesso alle risorse, ad esempio le porte di rete. Si tratta della stessa funzionalità che abbiamo visto prima quando abbiamo parlato della limitazione del traffico agli utenti. Ciò significa che, anche se due servizi possono essere eseguiti come NetworkService, non possono gestirsi reciprocamente i processi e il firewall può essere configurato solo su uno di essi per comunicare. Se il servizio che viene bloccato è compromesso, non può assumere il controllo del servizio consentito e usarne la porta per comunicare in quanto l'accesso alla porta si basa sul SID del servizio.
Questa è un'altra delle funzionalità notevoli aggiunte a Windows Vista ed è usata dal nuovo firewall per garantire una reale protezione tramite il filtro del firewall in uscita.
Infatti, per impostazione predefinita, nel nuovo firewall è attivato il filtro dei SID dei servizi. In ogni caso non c'è nessuna GUI per fare questa configurazione. Le regole sono predefinite nella chiave del registro di sistema HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices. Prestare comunque molta attenzione a modificare manualmente questa chiave perché non è un'operazione comprovata.

Quanta protezione può dare il filtro in uscita?
Un argomento piuttosto controverso nella comunità che si occupa di sicurezza è il livello di protezione effettivamente offerto dal filtro in uscita. Ho accennato a due scenari che forniscono la protezione per mezzo del filtro in uscita ma entrambi si fondano sulla nuova funzionalità in Windows Vista che non era disponibile in precedenza. Nonostante ciò, si è diffusa la sensazione che il filtro in uscita sia generalmente valido e dovrebbe costituire un fattore chiave nella decisione di acquistare il firewall.
Paradossalmente, in molte organizzazioni le capacità del filtro in uscita hanno determinato la decisione di acquistare il firewall ma poi il filtro in uscita non è stato usato una volta implementato il firewall. Questa impressione è fuorviante e comporta uno spreco di denaro e fatica da parte del gruppo addetto alla protezione delle informazioni. Sembra motivata più dal desiderio di sentirsi a posto con la coscienza facendo qualcosa per la protezione che non da un'analisi effettiva di una minaccia reale. Troppo spesso questo desiderio fa prendere decisioni che invece andrebbero prese basandosi sui fatti.
C'è un fatto molto semplice che riguarda il filtro in uscita che i suoi fautori non sono riusciti a prendere in considerazione. L'argomento addotto solitamente dai fornitori di firewall basati su host è che, se un sistema è compromesso, sia da un worm che da un utente malintenzionato interattivamente, il filtro in uscita impedirà al worm di infettare gli altri sistemi o all'hacker di comunicare. Non è vero.
È vero, fermo restando quanto detto finora, che un filtro in uscita avrebbe bloccato alcuni storici programmi malware. Tuttavia, se Windows XP avesse avuto il filtro in uscita, è molto più che probabile che i worm che abbiamo conosciuto sarebbero stati scritti in modo da disattivare il filtro o comunque da eluderlo.
In Windows XP (e nelle versioni precedenti di Windows) avrebbe potuto farlo qualsiasi worm in esecuzione come servizio (e tutti i worm comunemente noti che sono saltati fuori funzionavano come un servizio). L'unico motivo per cui non lo hanno fatto è che praticamente non esisteva nessun ambiente con il filtro in uscita e quindi non c'era necessità di disattivarlo. In un attacco interattivo, l'hacker può eludere i filtri in uscita a suo piacimento. È facile se l'hacker è in grado di eseguire un codice arbitrario. Ma se necessario, l'hacker può anche indurre l'utente a eludere i filtri.
I filtri in uscita dei firewall basati su host possono essere elusi in vari modi, a seconda dello scenario dell'attacco. Il modo più semplice consiste nel "chiedere" a un utente con i massimi privilegi di farlo per lui. In troppi ambienti gli utenti operano come amministratori. Questi utenti hanno l'autorizzazione a eludere i criteri di sicurezza a proprio piacimento. Tutto quello che deve fare l'hacker è presentare all'utente una scelta tra qualcosa che sia un beneficio immateriale e non immediato per la sicurezza e qualcosa a cui l'utente tiene di più: il classico paradosso dei "dancing pigs".
In molti casi, l'utente è talmente sommerso da questi tipi di finestre di dialogo che fa subito clic senza comprendere veramente ciò che sta succedendo. Questo è il problema principale con i filtri in uscita. Quando si tratta di scegliere tra la sicurezza e gratificazioni sufficientemente allettanti, ad esempio i cosiddetti "dancing pigs", vincono sempre questi ultimi dato che la maggior parte delle finestre di dialogo che chiedono agli utenti di prendere decisioni in merito alla sicurezza è priva delle informazioni che consentirebbero agli utenti di prendere effettivamente quella decisione.
Presentare finestre di dialogo, che chiedono di prendere una decisione sulla sicurezza, con un numero sufficiente di informazioni su cui basare quella decisione è molto più difficile di quanto sembri: richiederebbe che il prodotto addetto alla protezione, ad esempio il firewall, non solo riconoscesse porte, protocolli e l'applicazione che sta facendo la richiesta, ma anche cosa stia tentando di fare la richiesta e il relativo significato per l'utente. È molto difficile reperire queste informazioni a livello di programma. Ad esempio, il fatto che Microsoft Word tenti di stabilire una connessione in uscita non è tanto interessante quanto il fatto di cosa Word stia tentando esattamente di fare con quella connessione.
Dobbiamo ridurre il numero di finestre di dialogo senza senso e non aumentarlo; in questa direzione i firewall con i filtri in uscita non aiutano. Per avere un'idea del livello attuale della capacità di fornire informazioni preziose all'utente, ho esaminato la documentazione delle vendite di uno dei principali fornitori di firewall basato su host. Vengono pubblicizzate le capacità di filtro in uscita e di consigliare del firewall. La capacità di consigliare consiste nel rilevare quello che l'utente sta tentando di fare e dare il consiglio appropriato. Più o meno questa è la teoria. Il testo nella brochure era accompagnato da una schermata con un contenuto simile a questo: "Non sono disponibili consigli per questo programma. Scegliere o fare clic su Altre informazioni per assistenza". Sembra che neanche nei materiali marketing i fornitori siano in grado di produrre finestre di dialogo informative.
Poiché gli utenti non hanno informazioni sufficienti per prendere le decisioni giuste per la sicurezza, tocca all'amministratore configurare interamente il filtro in uscita in quanto l'utente finale non è in grado di farlo. In questo modo il carico di lavoro dell'amministratore aumenta a dismisura.
Anche se l'utente fa clic sull'opzione per ricordarlo in seguito alla richiesta del firewall, il malware di solito può aggirare il firewall. Finché l'utente per cui è in esecuzione il codice dannoso può aprire connessioni in uscita su una porta, è sufficiente che il codice dannoso usi quella porta. Pertanto qualsiasi processo può essere trasportato su un processo esistente. Ciò è permesso nei sistemi operativi di basso livello. A partire da Windows Vista, i processi possono essere adeguatamente sottoposti a limitazioni, motivo per cui i servizi, che sono gli unici a essere soggetti a limitazioni per impostazione predefinita, vengono bloccati usando i filtri in uscita per impostazione predefinita.
Purtroppo molte persone ritengono che il filtro in uscita dei firewall basati su host impedisca a una risorsa capitale compromessa di attaccare le altre risorse. Questo non è possibile. Adottare misure protettive per una risorsa capitale compromessa e aspettarsi che questa non comprometta tutte le altre risorse è un metodo che semplicemente non funziona. La protezione appartiene alla risorsa che si sta tentando di proteggere e non a ciò contro cui ci si sta proteggendo! Chiedere ai ladri di non rubare dopo che già sono entrati a casa nostra è improbabile che sia efficace quanto impedire loro di irrompere in casa.

Jesper M. Johansson, Software Architect, si occupa dei problemi di protezione software e collabora con TechNet Magazine in qualità di redattore. Ha conseguito un dottorato in gestione dei sistemi informatici, vanta un'esperienza più che ventennale sul tema della sicurezza ed è Microsoft MVP per la protezione delle aziende. Il suo ultimo libro è Windows Server 2008 Security Resource Kit.


Security
Garanzia della sicurezza della posta elettronica tramite i certificati digitali
Matt Clapham and Blake Hutchinson
Panoramica:
  • Creazione di un'identità verificabile
  • Aggiornamento dello stato dei certificati
  • Recupero e scambio di certificati
  • Risoluzione dei problemi del sistema S/MIME

Per millenni, gli esseri umani hanno utilizzato diversi metodi per nascondere le informazioni in transito, convalidare il mittente e autenticare il messaggio. Con l'evoluzione della civiltà umana, è stato sviluppato un metodo per l'esecuzione di tutte e tre le tre attività che va acquisendo una diffusione sempre maggiore. Secure Multi-Purpose Internet Mail
Extensions (S/MIME) è un sistema per l'invio in modo sicuro della posta elettronica mediante l'uso della crittografia e delle firme digitali.
Le tecnologie di crittografia correnti rientrano in due categorie principali: algoritmi a chiavi simmetriche (segrete), come Data Encryption Standard (DES) o Advanced Encryption Standard (AES), e algoritmi a chiavi asimmetriche (pubbliche/private), come RSA o Elliptical Curve Cryptography (ECC). Gli strumenti moderni per la convalida del mittente sono funzioni matematiche unidirezionali denominate hash che garantiscono l'univocità delle firme. Due metodi di hash comunemente utilizzati sono l'algoritmo Message Digest 5 (MD5) e Secure Hash Algorithm (SHA). I computer possono utilizzare questi metodi per generare un hash univoco o un numero che corrisponda al singolo testo di origine (l'hash di testi di origine identici è impostato sullo stesso valore). Questi strumenti semplici vengono utilizzati e combinati per creare un sistema di infrastruttura a chiave pubblica (PKI).

Identità verificabile
Risorse per l'Autorità di certificazione
  • Utilizzo di un'Autorità di certificazione per il servizio Crittografia file system
  • Impossibile rinominare o rimuovere dalla rete i server Autorità di certificazione
  • Come rimuovere n'Autorità di certificazione attendibile dai computer del dominio
  • Come rimuovere le autorizzazioni di un'Autorità di certificazione dell'organizzazione (enterprise) Windows e come rimuovere tutti gli oggetti correlati da Windows Server 2003 e Windows 2000 Server
  • Come spostare un'Autorità di certificazione su un nuovo server in esecuzione su un controller di dominio

Le identità all'interno di un sistema PKI vengono gestite mediante certificati digitali, che non sono diversi dal documento di identificazione governativo utilizzato per attraversare un confine internazionale, ovvero il passaporto. Lo standard del settore dei certificati digitali per il passaporto è il formato X.509, che viene ampiamente utilizzato per la firma e la crittografia in tecnologie come S/MIME, Internet Protocol Security (IPsec), Secure Shell (SSH), sicurezza della rete wireless, reti private virtuali (VPN) e, persino, comunicazioni server sicure (come i siti Web SSL).
I certificati sono basati sulla crittografia asimmetrica e sugli hash. Per creare un certificato, il richiedente (l'entità che desidera una chiave firmata da un'autorità più elevata) genera una chiave privata. La chiave viene tenuta in un luogo sicuro in modo che la relativa autenticità non venga mai messa in discussione. Insieme alla chiave privata, viene anche generata una chiave pubblica corrispondente. Come implica lo stesso nome, la parte pubblica della coppia non è segreta e viene distribuita liberamente, ma sempre utilizzando metodi che ne garantiscano l'autenticità.
Questa coppia di chiavi consente due operazioni fondamentali. Primo, tutti possono utilizzare la chiave pubblica per crittografare dati che solo la chiave privata è in grado di decrittografare; secondo, la chiave pubblica può essere utilizzata per decrittografare dati crittografati con la chiave privata. Questo è importante per verificare una firma che potrebbe essere stata creata solo da una chiave privata.
La richiesta all'Autorità di certificazione include dettagli come l'identità della persona o del computer a cui la chiave è destinata, il tipo e la complessità dell'algoritmo e la parte pubblica della coppia di chiavi. L'Autorità di certificazione (CA) riceve e convalida le informazioni nella richiesta e, utilizzando un algoritmo hash, crea un identificatore univoco corrispondente alle informazioni ricevute.
Utilizzando la relativa chiave privata, la CA esegue la crittografia dell'hash delle informazioni e lo assembla in un formato standard, come X.509, creando un certificato corrispondente alla richiesta originale. Il certificato X.509 contiene un elenco di attestazioni che includono l'identità del certificato (soggetto), un intervallo di validità, la chiave pubblica e le operazioni per le quali è possibile utilizzare il certificato. Il certificato viene quindi restituito al richiedente; si tratta di un token in cui è possibile ravvisare un'affermazione di questo tipo: "Io, in quanto Autorità di certificazione, garantisco per questa chiave pubblica e la parte privata corrispondente nonché per tutti gli utilizzi ivi descritti".
Per le Autorità di certificazione radice, ovvero quelle al livello più elevato della catena di certificati, i certificati sono autofirmati. Le Autorità di certificazione radice più accettabili sono preinstallate nel sistema operativo o nell'applicazione di base ma possono essere aggiornate o modificate tramite pacchetti o la configurazione dell'organizzazione. Tra la CA radice e un nodo foglia, che descrive in genere una singola persona o un sistema, è possibile che sia presente una o più CA intermedie.
La catena è costituita da tutti i nodi e tutti i certificati precedenti in essi incorporati, firmati dalla CA a tale livello. Una terza parte che tenta di convalidare il certificato può controllare l'hash calcolato localmente e confrontarlo con quello decrittografato dal certificato utilizzando la chiave pubblica corrispondente per una specifica CA o uno specifico utente. In tal modo si ottiene una catena di certificati completamente convalidata, dai nodi fogli alla radice, presupponendo ovviamente che la radice sia attendibile.

Aggiornamento dello stato dei certificati
Ogni CA valida dispone di un metodo per distribuire un elenco di certificati che non devono più essere considerati attendibili. In questo elenco di revoche di certificati (CRL) vengono descritti gli elementi emessi che sono stati specificamente negati dalla CA. Per comodità, la posizione dell'elenco di revoche di certificati è in genere una proprietà del certificato CA.
Gli elenchi di revoche di certificati vengono in genere emessi dalle CA in base a una pianificazione (probabilmente ogni due settimane) o un evento (un'occorrenza che indica che un certificato emesso non deve più essere considerato attendibile). Gli elenchi di revoche di certificati vengono firmati da una CA quando vengono pubblicati. Quando un sistema ricevente valuta la validità di una catena, tenta in genere di acquisire l'elenco di revoche di certificati per ciascuna CA di emissione nella catena (tramite i dettagli incorporati nei certificati stessi o attraverso un meccanismo di distribuzione predefinito attendibile). Se non è disponibile alcun elenco di revoche di certificati, il client potrebbe ricorrere a una copia recente memorizzata nella cache, purché non sia precedente al periodo di aggiornamento dell'elenco di revoche di certificati specificato. In caso contrario, tuttavia, sui sistemi client viene visualizzata in genere una sorta di messaggio di errore che indica che il certificato sembra valido ma non è possibile determinare lo stato della revoca.
Molte applicazioni, se non sono in grado di convalidare la catena o l'elenco di revoche di certificati per ogni nodo della catena, richiedono una notevole quantità di tempo per il caricamento di un certificato. La decisione dell'utente di considerare attendibile o meno un certificato dipende dal tipo di dati protetti dal certificato. Un punto di distribuzione CRL ampiamente diffuso e aggiornato periodicamente è assolutamente necessario per ogni CA, in particolare per le radici pubbliche.
Le radici sono la base della catena di certificati, mentre il concatenamento costituisce la base di tutte le gerarchie dei certificati. La maggior parte delle applicazioni o dei sistemi client presuppone che un certificato di un nodo foglia sia valido solo se è collegato a una radice attendibile. Tale radice può essere rappresentata da una CA dell'organizzazione (enterprise), posseduta e gestita da una specifica azienda, o da una CA radice pubblica, come VeriSign.
È necessario che le CA radice pubbliche dispongano di un significativo livello di competenze operative in modo da garantire l'integrità. Le organizzazioni devono garantire che le relative operazioni interne raggiungano lo stesso livello, in quanto l'integrità di una CA radice in tale contesto è altrettanto importante. Per un livello di protezione ottimale, è opportuno mantenere le CA radice in modalità non in linea e utilizzarle solo per emettere i certificati e aggiornare gli elenchi di revoche di certificati. Per ulteriori informazioni sulle procedure operative consigliate relative alle CA, vedere gli articoli elencati nell'intestazione laterale "Risorse per l'Autorità di certificazione".
Un aspetto importante da considerare è il recupero chiavi. Per semplificare le ricerche e assicurare che i dati non vengano irrecuperabilmente bloccati da un utente, è opportuno che l'organizzazione esegua copie di backup di tutte le chiavi emesse dall'utente. Inoltre, queste copie di backup devono essere memorizzate in un archivio sicuro. In tal modo, se la chiave di un utente scompare, ad esempio nel caso in cui una smart card venga lasciata in un taxi, è comunque possibile continuare ad accedere al contenuto protetto dalla chiave in questione.
Infine, ogni sistema di crittografia efficace è basato sul concetto di gestione del ciclo di vita. Quanto più la velocità dei computer aumenta, tanto più vulnerabili diventano gli algoritmi. Un sistema di crittografia efficace deve essere in grado nel corso del tempo di rinnovarsi e di passare all'utilizzo di nuovi algoritmi e dimensioni di chiavi. Quando vengono identificati dei punti deboli nel sistema crittografico e determinate funzioni vengono gradualmente introdotte o sostituite, è opportuno aggiornare le CA in modo appropriato.

Implementazione di S/MIME
L'avvio, la composizione, l'invio e la ricezione di un messaggio di posta elettronica firmato o crittografato mediante S/MIME prevede diverse fasi. In questo articolo verranno illustrati i dettagli, i problemi e le potenziali soluzioni sulla base dell'analisi di uno scenario S/MIME tipico: due utenti che si inviano l'un l'altro messaggi di posta elettronica firmati e/o crittografati da due diverse foreste di Active Directory® e da catene di Autorità di certificazione differenti, ovvero da entità separate dal punto di vista operativo, all'interno o meno della stessa azienda, utilizzando Microsoft® Office Outlook® 2007.
L'analisi di questo scenario presuppone che l'infrastruttura necessaria sia già stata implementata per abilitare le operazioni che verranno descritte. In questo scenario di esempio viene utilizzato un server per certificati dell'organizzazione integrato in Active Directory.

Recupero di certificati
La prima attività consiste nel recuperare i certificati appropriati. A tal fine, aprire la console MMC di gestione dei certificati (certmgr.msc), fare clic con il pulsante destro del mouse su Cartella personale, selezionare Tutte le attività nell'elenco popup, quindi selezionare Richiedi nuovo certificato dall'elenco.
Verrà avviata la procedura guidata di registrazione dei certificati, come illustrato nella Figura 1. Per impostazione predefinita, vengono visualizzate diverse opzioni di livello aziendale, ma la più importante è Certificato utente. Questa opzione verrà utilizzata più avanti nell'articolo per attivare i processi di firma e crittografia. È necessario che sia possibile utilizzare il certificato per le seguenti attività:
Figura 1 Richiesta di un certificato
Figura 1 Richiesta di un certificato (Fare clic sull'immagine per ingrandirla)
  • Firme digitali (creando un messaggio con un sigillo di autenticità da parte del relativo creatore)
  • Crittografia a chiave (proteggendo una chiave con un'altra per tecnologie come Crittografia file system)
  • Sicurezza della posta (messaggistica crittografata che può essere letta solo dal destinatario in possesso della chiave privata corrispondente)
Per l'invio dei messaggi di posta elettronica firmati S/MIME, la proprietà di crittografia a chiave non è necessaria. Tuttavia, per l'invio o la ricezione di un messaggio crittografato, questa proprietà è necessaria, mentre la proprietà di firma non è necessaria. Per impostazione predefinita, queste tre proprietà sono abilitate nei modelli in Servizi certificati Windows®. Se all'utente non è consentito richiedere nuovi certificati, all'avvio della procedura guidata non verrà visualizzato alcun certificato. Se non è disponibile alcuna CA dell'organizzazione (enterprise), all'utente verrà visualizzato il messaggio "Errore di registrazione" che indica che non è possibile contattare il dominio o la CA. Ai fini di questa procedura dettagliata,si presupporrà un singolo certificato che consente sia la firma che la crittografia a chiave.

Scambio di certificati
Il metodo più semplice per due utenti per iniziare a inviare messaggi di posta elettronica crittografati consiste semplicemente nell'inviare l'un l'altro messaggi firmati. Dopo aver composto un messaggio, l'utente fa clic sul pulsante Firma. Questo pulsante, per impostazione predefinita, è nascosto in Outlook fino a quando non viene utilizzato almeno una volta. È possibile individuare questo pulsante facendo clic sull'impostazione Opzioni per i nuovi messaggi, facendo clic sul pulsante "Impostazioni protezione...", quindi selezionando la casella "Aggiungi una firma digitale a questo messaggio" nella finestra di dialogo Proprietà di protezione. Il pulsante di firma (una piccola busta gialla con una barra multifunzione rossa con la dicitura Firma) consente di aggiungere una firma digitale al messaggio per stabilire l'autenticità della relativa origine.
Una volta fatto clic sul pulsante Invia, è possibile che all'utente venga chiesto di fornire token aggiuntivi per dimostrare che è in possesso della chiave, come l'inserimento di una smart card o l'immissione di un codice PIN. Questo dipende dagli specifici metodi di protezione delle chiavi implementati all'interno dell'organizzazione.
L'utente che riceve il messaggio firmato con S/MIME deve visualizzare e fare clic con il pulsante destro del mouse sul nome del mittente (dopo la casella Da:), quindi selezionare "Aggiungi a contatiti di Outlook" dal menu di scelta rapida in modo da aggiungere una nuova voce di contatto o aggiornarne una esistente. Il certificato viene quindi associato alla specifica voce di contatto. Notare che in un ambiente Active Directory comune (due utenti nella stessa foresta o azienda), la distribuzione di certificati utente pubblici viene eseguita automaticamente tramite gli attributi nell'oggetto Active Directory dell'utente.
Un altro metodo per lo scambio di certificati prevede che ciascun utente invii il relativo certificato S/MIME come allegato. A tal fine, entrambe le parti devono esportare i relativi certificati in un file CER. È necessario che gli utenti visualizzino il certificato e seguano il processo di esportazione che verrà illustrato più avanti, facendo attenzione a non esportare la chiave privata insieme al certificato, come illustrato nella Figura 2.
Figura 2 Durante lo scambio dei certificati, non esportare la chiave privata
Figura 2 Durante lo scambio dei certificati, non esportare la chiave privata (Fare clic sull'immagine per ingrandirla)
Ciascun destinatario crea manualmente una voce di contatto in Outlook e aggiunge il certificato alla voce del mittente. Una volta scambiati i certificati, i due utenti saranno in grado di scambiarsi reciprocamente i messaggi di posta elettronica crittografati.

Risoluzione dei problemi
A volte il destinatario ha difficoltà ad aprire il messaggio crittografato. Le tre cause più probabili dei problemi riscontrati in questa area sono rappresentate dalla mancata attendibilità delle CA radice, dall'impossibilità di convalidare le CA intermedie e dalla mancata disponibilità degli elenchi di revoche di certificati.
Una CA radice non attendibile in genere viene visualizzata in Outlook come messaggio di errore associato alla firma: "Sono stati rilevati problemi per la firma. Fare clic sul pulsante della firma per visualizzare i dettagli". Per risolvere il problema, aprire il certificato da Outlook e fare clic sul pulsante "Visualizza autorità di certificazione" nella finestra di dialogo popup. Esaminare il messaggio nella scheda Generale della finestra di dialogo delle proprietà del certificato. Se il messaggio indica che il certificato radice CA non è attendibile e deve essere installato, accedere alla scheda Dettagli. Fare clic sul pulsante "Copia su file..." e seguire la procedura guidata, accettando tutte le impostazioni predefinite e specificando, quando richiesto, un nome file e una cartella.
Aprire una nuova console MMC (Microsoft Management Console) come amministratore di computer. Accedere a File|Aggiungi/Rimuovi snap-in (Ctrl+M), selezionare il nodo Certificati e aggiungerlo per l'account del computer, scegliendo Computer locale, quando richiesto. Espandere il nodo Certificati nell'albero a sinistra, quindi espandere Autorità di certificazione radice disponibile nell'elenco locale. Fare clic con il pulsante destro del mouse e selezionare Tutte le attività|Importa dal menu popup. Importare il file di certificato esportato menzionato in precedenza in Autorità di certificazione radice disponibile nell'elenco locale e fare clic su Fine. Indicare all'utente interessato di riavviare Outlook.
Queste istruzioni devono essere utilizzate solo per aggiungere una CA radice considerata attendibile. Non tutte le radici vengono create uguali. Prima di utilizzare questo metodo per aggiungere una radice all'archivio per l'intero sistema, valutare attentamente chi possiede e gestisce la CA radice. Se la propria organizzazione controlla l'elenco delle radici attendibili tramite Criteri di gruppo, la configurazione verrà inserita nei sistemi client. In tal caso, le istruzioni potrebbero non funzionare. Se si verifica una situazione di questo tipo, potrebbe essere necessario esplorare ulteriori alternative, come server o siti Web sicuri per lo scambio di dati, in quanto l'invio della posta elettronica non avverrà in modo protetto e trasparente.
Il secondo problema, correlato all'impossibilità di convalidare le CA intermedie, in genere si verifica in due situazioni: un client che tenta di convalidare il certificato non è in grado di accedere al percorso Accesso alle informazioni dell'autorità (AIA) definito nel certificato o il client include una versione del certificato della CA intermedia che non corrisponde a quello emesso dalla CA (il client è in genere indietro di una o due versioni). Queste condizioni sono molto simili nell'interfaccia utente di Outlook. Questo problema è stato riscontrato solo in una circostanza molto specifica, quando una CA di livello intermedio nella catena è scaduta ed è stata emessa nuovamente prima della scadenza degli altri certificati subordinati da essa emessi.
In sostanza, questo problema si verifica in presenza di spazi vuoti nella catena. È possibile che alcuni certificati padre non siano documentati in modo adeguato o non siano incorporati nel nodo foglia in modo appropriato, complicando ulteriormente la situazione.
Per risolvere questo problema, il mittente deve aprire un nuovo messaggio e fare clic su Opzioni nel nuovo messaggio, quindi sul pulsante Impostazioni protezione e, infine, sul pulsante Cambia impostazioni. A questo punto, occorre fare clic sul pulsante Scegli per il certificato di firma e sul pulsante Visualizza certificato nella finestra di dialogo popup. Accedere alla scheda del percorso del certificato, selezionare l'autorità emittente del nodo foglia (al livello superiore nella catena) e fare clic sul pulsante Visualizza certificato. Fare clic sulla scheda Dettagli, quindi sul pulsante Copia su file... e completare l'Esportazione guidata, selezionando PKCS #7 (.P7B). Assicurarsi che l'opzione "Includi tutti i certificati nel percorso certificazione" sia selezionata, come illustrato nella Figura 3. Infine, inviare il file della catena esportato al destinatario desiderato.
Figura 3 Correzione di spazi vuoti in una catena di certificati
Figura 3 Correzione di spazi vuoti in una catena di certificati (Fare clic sull'immagine per ingrandirla)
Una volta ottenuta la catena di certificati esportata, il destinatario dovrà aprire e importare la catena seguendo una procedura simile a quella utilizzata in precedenza per l'importazione di una radice. L'unica differenza è che la cartella di archiviazione scelta deve essere Autorità di certificazione intermedia. Se il messaggio viene aperto e il certificato viene visualizzato come valido in Outlook, questo indica che non esiste alcun problema.
Quanto al terzo problema, la mancata disponibilità degli elenchi di revoche di certificati, la correzione è relativamente semplice. La risposta iniziale di Outlook sembrerà molto simile a quella fornita al problema precedente. Tuttavia, l'errore viene visualizzato anche se le CA di firma radice o intermedie sono attendibili. Per ogni livello della catena di certificati al di sopra della foglia, aprire le proprietà del certificato, fare clic sulla scheda Dettagli ed esaminare il campo "Punti di distribuzione Elenco di revoche di certificati (CRL)".
Per ogni punto di distribuzione CRL elencato, in particolare quelli accessibili da Internet, verificare che sia possibile aprire l'URL del file CRL. Una volta convalidato un livello, spostarsi al livello superiore della catena. Se non è possibile acquisire alcun elenco di revoche di certificati, quest'ultimo rappresenta probabilmente l'origine del problema. Per risolvere il problema, occorre verificare che i criteri di rete locali non blocchino l'accesso. In caso contrario, provare a contattare l'azienda proprietaria della CA o attendere che il punto di distribuzione CRL della CA ritorni allo stato operativo.

Distribuzione di certificati
La distribuzione è la parte più semplice. In sostanza, il messaggio firmato viene trasmesso a un server di posta, che lo invia da una posizione locale a un'altra tramite un metodo noto, SMTP. L'unico problema riscontrato con la posta firmata o crittografata in transito è che alcuni sistemi di posta rifiutano o interrompono i messaggi firmati o crittografati che passano attraverso di essi. La correzione di questo problema prevede l'utilizzo del gestore IT del sistema per ottenere i tipi di messaggi consentiti. Ovviamente, occorre tenere presente che alcuni tipi di messaggi sono bloccati. La parte ricevente potrebbe avere buone ragioni per non consentire messaggi crittografati in uno specifico ambiente operativo.

Crittografia delle risposte
Per creare una risposta crittografata (presupponendo che il processo di avvio sopra descritto sia stato completato), il mittente deve solo creare un messaggio e fare clic sul pulsante Crittografa (la piccola busta di colore giallo che include il blocco blu con la dicitura Crittografa) nella finestra di composizione del messaggio. Se il pulsante Crittografa non è disponibile, seguire la procedura per l'invio di un messaggio firmato, eccetto l'ultimo passaggio, e selezionare la casella di controllo "Crittografa contenuto e allegati del messaggio".
La firma S/MIME non è necessaria per l'invio di un messaggio crittografato a un destinatario, ma le due funzioni funzionano bene insieme in quanto la firma consente al lettore di convalidare il mittente (la funzione di crittografia non fa alcuna richiesta relativamente al mittente). Il processo di crittografia tenterà di crittografare il messaggio con le chiavi pubbliche note di tutti i destinatari. Se il sistema non è in grado di identificare i certificati per alcuni dei destinatari desiderati, questi verranno contrassegnati in una finestra di dialogo popup in cui viene chiesto se si desidera inviare i messaggio in formato non crittografato, come illustrato nella Figura 4.
Figura 4 È possibile decidere di inviare un messaggio non crittografato se si verifica un problema con un certificato
Figura 4 È possibile decidere di inviare un messaggio non crittografato se si verifica un problema con un certificato (Fare clic sull'immagine per ingrandirla)
Per impostazione predefinita, la firma e la crittografia funzionano correttamente con altri sistemi client configurati in modo analogo, ma talvolta lo scambio di messaggi crittografati o firmati tra versioni diverse può presentare dei problemi quando non viene fornito il supporto per versioni precedenti. Tale problema è stato riscontrato durante l'invio di un messaggio di posta elettronica firmato (utilizzando SHA-512 come algoritmo hash) a un computer su cui veniva eseguito Windows XP SP2. Poiché il sistema ricevente non forniva il supporto per l'hash, l'utente non è stato in grado di convalidare la firma o leggere il messaggio. Tuttavia, è poco probabile che gli utenti incontrino molti problemi in questa fase, a meno che le impostazioni predefinite di Outlook non siano state modificate.
Una volta ricevuto il messaggio, il destinatario previsto sarà in grado di aprirlo, purché sia disponibile la chiave privata associata al certificato pubblico. È possibile che all'utente venga di nuovo chiesto di fornite un token aggiuntivo per dimostrare di essere proprietario della chiave privata, a seconda della relativa modalità di distribuzione. È possibile che altri utenti che hanno completato un processo di avvio simile partecipino a comunicazioni firmate e crittografate simili con il mittente. Se, a un certo punto, un utente modifica la relativa chiave privata, ad esempio in conseguenza dello smarrimento del computer, dovrà richiedere i certificati e ridistribuire un messaggio firmato o un file di certificato ad altri utenti che desiderano scambiare posta crittografata.

Conclusioni
Lo scambio di messaggi S/MIME firmati e crittografati tra due utenti in due directory o organizzazioni differenti non presenta, in genere, ulteriori difficoltà rispetto a quelle già illustrate nel presente articolo. La firma è molto utile quando utilizzata correttamente, in quanto aggiunge autenticità al messaggio. Per i dettagli riservati, i messaggi crittografati forniscono un ulteriore livello di riservatezza per i dati in transito. Le due funzioni, utilizzate in combinazione, garantiscono l'autenticità dell'origine e la riservatezza dei dati. Sulla base del processo descritto in questo articolo, non sarà un'impresa ardua per gran parte degli utenti sfruttare i vantaggi offerti da queste funzionalità.

Matt Clapham, CISSP, è Security Engineer presso Microsoft IT. Esegue revisioni della sicurezza sulle applicazioni LOB di giorno e si diletta di tecnologia, giochi, musica per computer o sicurezza di notte. Talvolta, partecipa alle discussioni della community per la sicurezza IT di Puget Sound. È possibile contattarlo all'indirizzo matt.clapham@microsoft.com.
Blake Hutchinson è Support Analyst nel gruppo Business Online Services Group (BOSG) di Microsoft. Il suo ruolo prevede supporto operativo e revisione di progetti di strumenti LOB creati internamente per i clienti aziendali del gruppo BOSG. Blake si diletta di fotografia, gli piace sciare e ama i giochi per computer. È possibile contattarlo all'indirizzo blakeh@microsoft.com.


Dal redattore Il grande dibattito
Joshua Hoffman

Amo i grandi dilemmi. Non parlo di disaccordi banali, in cui opinioni differenti e personalità forti causano irragionevoli sconti. Che perdita di tempo! Intendo un vero e proprio dibattito, in cui persone intelligenti con punti di vista opposti trovano un punto di incontro per proporre le proprie idee e ricevere un'opinione...questo sì che è uno scenario entusiasmante! Pensate all'enlightenment! Pensate a Socrate!
Questo mese vi presentiamo uno dei più grandi dibattiti del settore dell'IT: sicurezza tramite segretezza. Spiegherei il concetto qui, ma ho il vago sospetto che subito dopo aver letto quelle poche righe, la maggior parte di voi avrà già espresso la sua opinione a riguardo e probabilmente ad alta voce. Sono anche propenso a credere che la maggior parte di voi rientrino in pieno in due categorie: Quella che ritiene che la sicurezza tramite segretezza è completamente inutile e quella che ritiene che, quando si tratta di sicurezza, ogni mezzo è valido.
Questo mese abbiamo riunito dei rinomati esperti in materia di sicurezza, ovvero Jesper Johansson e Roger Grimes, per esporre entrambi i lati di questo dibattito. Abbiamo inoltre incluso due opinioni speciali in supporto di entrambe le opinioni, quella dei luminari Aaron Margosis e Steve Riley. Sebbene io sia estremamente orgoglioso di ogni pagina che pubblichiamo, devo ammettere che questo è certamente uno dei miei articoli preferiti. Mi auguro che, indipendentemente dall'opinione da voi sostenuta, ognuno di voi legga il presente articolo con una mente aperta. Sono certo che lo apprezzerete.
Dal momento che questo è il nostro articolo annuale sulla sicurezza, ovviamente c'è molto altro da dire. Rivisiteremo alcuni degli argomenti già trattati nel numero dell'anno scorso. Uno degli articoli più popolari dell'anno scorso illustrava una serie di PowerToy per l'elevazione dei privilegi degli script. Tale articolo scritto dal nostro collaboratore Michael Murgolo, consente di eseguire script VBScript o Windows PowerShell in un contesto elevato in combinazione con la funzione Controllo dell'account utente di Windows Vista. Michael ha ricevuto molti commenti estremamente positivi su tale articolo ed è quindi tornato quest'anno con una nuova serie di utilità per estendere il suo codice originale. Vi invito a provare questi potentissimi strumenti.
Byron Hynes è stato con noi anche lo scorso anno, con un'introduzione alla Crittografia unità BitLocker di Windows Vista. Byron riprende il suo ruolo con uno sguardo ai cambiamenti avvenuti in BitLocker con la versione di Windows Vista SP1 e Windows Server 2008. Vengono inoltre presentati articoli sui criteri di restrizione software, sulla gestione del firewall di Windows Vista, sulla risoluzione dei problemi S/MIME, sulla seconda edizione della nostra nuova rubrica Inside SharePoint, sulle idee commerciali per promuovere un'elaborazione sostenibile...e l'elenco continua. Buon divertimento! -Joshua Hoffman

Si ringraziano i seguenti esperti tecnici Microsoft: Troy Funk, Aaron Margosis, Michael Murgolo, Steve Peschka, Steve Riley, Mark Russinovich, Jon Schwartz e Jim Truher.


Lettere La parola ai lettori

Backup di Windows
Ero così eccitato all'idea di leggere il numero di Windows Server® 2008 (TechNet Magazine, marzo 2008, technet.microsoft.com/magazine/cc268370), che sono andato all'evento di lancio portando con me una copia per la mia rete domestica. L'installazione è andata a buon fine, ma ho avuto dei problemi con i backup.
NT Backup è stato rimosso e il nuovo Windows Server Backup non supporta le unità nastro, sebbene il sistema operativo le supporti. (Eseguo il backup i miei dati personali, inclusi Active Directory® ed Exchange Server 2007, su un'unità nastro).
Ho tentato di scaricare Microsoft® Data Protection Manager (DPM) seguendo i suggerimenti sul Web, anche se il DPM potrebbe provocare dei problemi alla mia installazione. Tuttavia, DPM non si installa su Windows Server 2008 e non ho avuto fortuna seguendo le relative istruzioni di installazione manuali. Come eseguire un backup su piccole installazioni?
-Ravi S.

DPM è la soluzione adeguata per i backup su nastro, poiché la nuova soluzione in Windows Server 2008 è ottimizzata per l'archiviazione basata su disco. DPM supporterà ufficialmente Windows Server 2008 nel giro di un paio di mesi.
-Karandeep Anand, Senior Program Manager Lead, Microsoft

Flussi di lavoro per i sondaggi
Nell'articolo del febbraio 2008, "Creazione di una potente infrastruttura di sondaggio" (technet.microsoft.com/magazine/cc194407), la sezione Utilizzo di WSS contiene la seguente affermazione: "È inoltre possibile assegnare un flusso di lavoro al sondaggio".
Per esperienza, ritengo che Windows® Sharepoint® Services 3.0 (WSS) e Microsoft Office Sharepoint Server 2007 (MOSS) non supportino flussi di lavoro associati a risposte al sondaggio. Ho tentato di associare un flusso di lavoro ad una risposta al sondaggio ma, sebbene SharePoint Designer consenta l'associazione, il flusso di lavoro riporta sempre un errore di avvio non riuscito. Uno degli articoli della Knowledge Base (support.microsoft.com/kb/926370) indica chiaramente che i flussi di lavoro associati a risposte al sondaggio non sono supportati.
Ritengo che sia possibile collegare un ricevitore di evento ad un sondaggio per poi avviare un altro processo, ma questo non è il flusso di lavoro a cui si fa riferimento in Sharepoint. Questa affermazione è inesatta o sono io a non aver ben capito la questione?
-Matt B.

Il paragrafo a cui si fa riferimento spiega in che modo WSS fornisce una procedura guidata per un processo dettagliato per la creazione di sondaggi. Esiste anche una discussione sulle varie opzioni (struttura logica ad albero, domande aperte/chiuse e così via).
Una delle opzioni che la procedura guidata fornisce è l'assegnazione di un flusso di lavoro; quindi, in un certo senso, non è proprio inesatto dire "è possibile assegnare un flusso di lavoro al sondaggio". È realmente possibile assegnarlo. Tuttavia, come hai fatto notare, i flussi di lavoro nei sondaggi non funzionano, anche se per qualche motivo l'opzione è prevista. Lasciami spiegare perché.
Dopo avere associato un flusso di lavoro ad un sondaggio e averne tentato l'avvio, si riceverà un errore di avvio non riuscito. I registri per questa attività mostrano quanto segue:
RunWorkflow: System.ArgumentException: Invalid field name.
{<<< GUID>>>} at ...
Tale GUID rappresenta l'istanza del flusso di lavoro. Sembra un valido modo per verificare che venga attivato il flusso di lavoro corretto, eccetto per il fatto che il tipo di elenco "sondaggio" non supporta l'attributo del flusso di lavoro. Semplicemente non è codificato; quindi quando il flusso di lavoro tenta l'attivazione con il metodo MakeActivation ed effettua un'azione simile alla seguente:
internal static void MakeActivation(SPWorkflow workflow, SPWorkflowEvent e)
{e.EventData = new object[ ] { workflow.InstanceId, new SPWorkflowActivation
Properties(workflow, e.RunAsUserId, associationData, initiationData) };
...
}
chiama SPWorkflowActivationProperties, in modo simile al seguente:
internal SPWorkflowActivationProperties(SPWorkflow workflow,
int runAsUserId, string associationData, string initiationData)
{
...
this.m_itemGuid = new Guid((string)
this.Item[SPBuiltInFieldId.GUID]);
...
}
Quindi se prevede la stringa GUID come attributo nel sondaggio (che apparentemente dovrebbe essere incorporata) e il sondaggio non presenta l'attributo per il GUID del flusso di lavoro, non potrà mai funzionare.
Esiste una possibile soluzione alternativa, quindi sei sulla buona strada. La soluzione alternativa implica la creazione di un elenco personalizzato che attivi un flusso di lavoro e colleghi un ricevitore di evento al sondaggio con ItemEventReceiver. Tale ricevitore crea un elemento nell'elenco personalizzato, che attiva un flusso di lavoro. Ma hai ragione... Non è esattamente la stessa cosa. Per farla breve: sì, la tua idea era ottima, ma in realtà non funziona.
-Pav Cherny, Columnist, Inside SharePoint, TechNet Magazine


Toolbox Nuovi prodotti per professionisti IT
Greg Steen

Diffusione di annunci sulla rete
NetSupport Notify
www.netsupportnotify.com
I PC sono ormai onnipresenti in ogni ufficio. La maggior parte degli utenti è davanti ad uno schermo tutto il giorno ed è connessa ad una rete che gestisce grazie ad un supporto. Oltre a fornire un trasporto per risorse condivise, applicazioni, e Internet, la rete della propria azienda può essere utilizzata all'interno della strategia della propria organizzazione per comunicare i messaggi importanti agli utenti. Uno strumento che facilita la consegna dei messaggi agli utenti attraverso la LAN e la WAN (wide area network) è NetSupport Notify, di NetSupport Limited.
Questo server delle applicazioni lightweight offre un supporto di messaggistica di trasmissione rapido e affidabile. È ad esempio possibile avvisare gli utenti di un'interruzione di servizio imprevista ad una risorsa condivisa, informare le persone che l'allarme di protezione attualmente riprodotto è stato attivato per errore o avvertire i dipendenti di un'emergenza nell'edificio.
Alcuni semplici strumenti di messaggistica di trasmissione disponibili sono limitati alla LAN su cui sono installati. NetSupport Notify, invece, è basato su un agent e con il relativo componente gateway di notifica, può attraversare facilmente la vostra topologia di rete, raggiungendo client Windows® e Mac, indipendentemente dal fatto che siano connessi direttamente, con una connessione wireless o tramite VPN (virtual private network).
Il servizio di notifica viene eseguito come servizio Windows, a cui ci si connette tramite la console di notifica amministrativa, che può essere installata sullo stesso computer o su una macchina diversa. Le notifiche provenienti dal servizio vengono classificate in tre livelli di severità: messaggio, avviso o critico. Quando il client riceve un messaggio, viene creata una voce del registro eventi ed il server riceve una notifica dell'avvenuta ricezione di tale messaggio. Altre opzioni di messaggio includono la riproduzione di un segnale acustico oltre alla visualizzazione della finestra, la visualizzazione permanente della notifica e l'impostazione di un timeout automatico sul messaggio per la relativa chiusura automatica.
È inoltre possibile scegliere come destinatari specifici gruppi di notifica. La console di notifica può connettersi a più server di notifica, quindi una console può essere il centro del broadcast di messaggi.
Oltre al server e alla console, NetSupport Notify include anche uno strumento di distribuzione che consente di distribuire in remoto l'agent ai propri utenti finali. È possibile specificare PC di destinazione per intervallo di indirizzi IP o tramite il rilevamento di gruppi di lavoro e domini di rete Windows.
La console di distribuzione fornisce anche una visione rapida della propria rete, mostrando la versione dell'agent installato con le informazioni essenziali, tra cui nome DNS, indirizzo MAC, indirizzo IP, piattaforma ed eventuale accesso della console alla macchina remota. Se si utilizza Active Directory®, è possibile gestire la configurazione e la distribuzione tramite criteri di gruppo.
Per proteggere da trasmissioni non autorizzate (come "Ehi, c'è una festa nel mio ufficio alle 16:00!"), gli agent e le console utilizzano un codice di protezione simile ad una stringa di chiavi WMI (Windows Management Instrumentation). In più, è possibile controllare la capacità di inviare degli avvisi tramite il criterio Active Directory.
Prezzo: si parte da $180 per 75 licenze.
Consegna di annunci ai propri dipendenti con NetSupport Notify
Consegna di annunci ai propri dipendenti con NetSupport Notify (Fare clic sull'immagine per ingrandirla)

Monitoraggio della propria rete
NetOptics: Teeny Tap
www.netoptics.com
Utilizzato in combinazione con una valida applicazione di monitoraggio, i dispositivi tap di rete passivi possono essere uno strumento essenziale nella risoluzione dei problemi delle reti instabili, nella correzione di applicazioni con funzionalità inadeguate e nella riduzione delle potenziali minacce alla propria infrastruttura. Un dispositivo tap valido che è stato portato alla mia attenzione per 10/100 reti è Teeny Tap di NetOptics.
Questo minuscolo dispositivo da meno di 8 cm x 4 cm fornisce un monitoraggio del traffico full-duplex dal livello 1 in su, consentendo di eseguire un controllo a campione o un monitoraggio continuo del traffico sulla propria rete 10/100. Il dispositivo consente un monitoraggio full-duplex con le due porte RJ45, che forniscono una visione completa del flusso di traffico su entrambi i lati delle due porte di rete quando tali porte sono connesse al network monitor, all'analista di protocollo, ad ID/IP o ad un'altra sonda.
Teeny Tap non ha bisogno di un indirizzo IP. Tramite un isolamento dalla rete, è possibile rimanere invisibile per coloro che potrebbero utilizzare la propria presenza come spunto per smettere di armeggiare con la rete. Nel frattempo, la funzionalità Zero Delay garantisce che un'interruzione dell'alimentazione nel dispositivo tap non influisca sul flusso di traffico e che non si verifichino perdite di pacchetti o ritardi.
Il dispositivo tap può essere alimentato tramite USB o con l'alimentatore incluso oppure è possibile utilizzare entrambe le soluzioni per ridondanza, capacità notevole per un dispositivo di dimensioni così ridotte. Teeny Tap è compatibile anche con servizi PoE (Power su Ethernet), ad esempio webcam e telefoni IP. In questo modo, è possibile anche monitorare il traffico per garantire la sicurezza delle proprie comunicazioni.
Il kit di Teeny Tap include il dispositivo tap, un alimentatore universale, due cavi RJ45 incrociati e due cavi standard e una custodia per il trasporto. Se si preferisce disporre di maggiore potenza nel proprio ambiente, è possibile scegliere anche altri prodotti dello stesso genere proposti da NetOptics. La linea di prodotti dispone dell'intera gamma, a partire da piccole reti per ufficio fino ad arrivare ad ambienti aziendali di grandi dimensioni sia per reti in rame che in fibre ottiche da 10 MB a 10 GB.
Prezzo: $325 (diretto).
Monitoraggio della rete con Teeny Tap
Monitoraggio della rete con Teeny Tap (Fare clic sull'immagine per ingrandirla)

Ottimizzazione del proprio computer
DTweak Pro
www.daoisoft.com
In qualità di professionisti dell'IT e come tecnici generici, avrete sicuramente il desiderio di modificare il vostro sistema e ottenere il massimo dalle prestazioni e dalla propria esperienza per le attività di ogni giorno. Esistono alcuni strumenti disponibili sul mercato che consentono di ottimizzare e personalizzare l'esperienza dell'utente sul computer che esegue Windows Vista®. Una soluzione economica è DTweak Pro di Daoisoft. È disponibile anche una versione per Windows® XP e Windows Server® 2003.
L'applicazione offre diverse viste di accesso rapido a differenti strumenti e personalizzazioni per Windows Vista Ad esempio, nella sezione Daily Tools, è possibile eseguire un'utilità di pulitura del registro di sistema, un'utilità di pulitura file, strumenti di deframmentazione disco e registro di sistema e un monitoraggio prestazioni del disco rigido.
Con DTweak, è possibile visualizzare e modificare facilmente i propri elementi di avvio, ottenere informazioni sulla CPU (tra cui ID CPU, velocità bus e velocità di clock) e acquisire informazioni sul computer, tra cui fornitore, stato di avvio, configurazione di memoria e tipo di sistema. È inoltre possibile modificare la propria memoria cache I/O e il tempo di attesa per la chiusura di servizi bloccati e programmi interrotti in modo anomalo.
La sezione Tools della GUI fornisce collegamenti a strumenti incorporati di Windows Vista incorporati, tra cui diskpart e ripristino configurazione di sistema, come pure collegamenti a utili strumenti di rete, tra cui finger, ping, netstat e nslookup. Tra le altre modifiche di rete, è possibile cambiare il valore MTU (maximum transmission unit), il TTL TCP/IP e le impostazioni di timeout DNS e limitare la sua larghezza di banda con il servizio dell'utilità di pianificazione pacchetti QoS.
Prezzo: $29,95 (download diretto).
Modifica e ottimizzazione del sistema con DTweak
Modifica e ottimizzazione del sistema con DTweak (Fare clic sull'immagine per ingrandirla)

Recensione
Manuale dell'amministratore di Microsoft Exchange Server 2007
www.microsoft.com/mspress
La posta elettronica può essere una brutta bestia! Ad esempio, non si ha un controllo vero e proprio sul flusso di messaggi in arrivo. Se si tenta di bloccare il flusso in entrata sospendendo il server SMTP fino alla riduzione delle relative code, è possibile che il mittente riceva l'avviso "Impossibile recapitare il messaggio". L'analogia con un sistema di idraulica è molto appropriato: l'acqua scorre sempre e se si chiude una valvola in un punto, si rischia lo scoppio di un tubo in un altro. Un'infrastruttura di posta elettronica flessibile, ben pianificata e organizzata è essenziale per consentire alla propria azienda di operare ad alti livelli.
Ovviamente, Microsoft Exchange Server® 2007 è progettato per gestire elevatissimi volumi di posta e per consentire l'adattamento della propria infrastruttura per soddisfare le esigenze presenti e future della propria azienda. Ma esistono numerose opzioni e decisioni da prendere in una distribuzione Exchange 2007. Ed Exchange si occupa di molte altre attività, il che complica ulteriormente la questione.
È realmente necessario disporre di almeno un valido riferimento per prendere le giuste decisioni strutturali e gestionali. Un riferimento che può essere indispensabile è il Manuale dell'amministratore di Microsoft Exchange Server 2007
Questo manuale illustra l'intero ciclo di vita di distribuzione di prodotto, dalla pianificazione e distribuzione alla manutenzione e protezione. Descrive anche i vari client e le relative opzioni di connettività disponibili per Exchange 2007. Parte da una panoramica sulle differenze tra le varie versioni ed un'occhiata alle novità di Exchange 2007 e fornisce anche un'ampia panoramica sui vari componenti architettonici di Exchange Server 2007.
La sezione seguente spiega come pianificare la distribuzione di Exchange e mostra come calcolare i propri requisiti di memoria, server e processore e aggiungere la tolleranza agli errori. Il manuale illustra poi l'installazione e la distribuzione vere e proprie, mostrando la procedura di preparazione del server per Exchange e la modalità di installazione dei differenti componenti del software. Il lettore troverà anche un riferimento approfondito ai servizi di clustering di Exchange per conseguire un maggiore livello di disponibilità.
Il manuale passa poi alla descrizione dei numerosi strumenti di gestione a disposizione, tra cui il pannello MMC di Exchange e il nuovo Exchange Management Shell basato su Windows PowerShell™. All'interno di questa sezione l'utente apprenderà la procedura di creazione delle caselle di posta e dei gruppi di archiviazione e la modalità di esecuzione delle operazioni di backup e ripristino. Un altro aspetto interessante di questa sezione è che il lettore imparerà ad eseguire tutte queste operazioni sia con la GUI di gestione che tramite la riga comandi di Windows PowerShell.
Exchange 2007 dispone di numerose funzioni di Messaggistica unificata, che consentono di gestire le comunicazioni di dati e vocali con un unico sistema e il manuale mostra anche la procedura di impostazione e utilizzo della messaggistica vocale e l'accesso alla Posta in arrivo tramite ricerca vocale, per citarne alcuni.
Per quanto riguarda l'aspetto della manutenzione, il manuale illustra gli strumenti e le tecniche di base per la risoluzione dei problemi, il ripristino in caso di danneggiamento e situazioni di emergenza e l'ottimizzazione delle prestazioni. La protezione, ovviamente, dovrebbe essere un argomento di primaria importanza in qualsiasi sistema di messaggistica unificata e il manuale contiene informazioni approfondite per la protezione della propria distribuzione. Il lettore scoprirà le linee guida e i criteri di protezione, le funzioni antivirus e anti-spam e l'infrastruttura a chiave pubblica.
Infine, il manuale esplora i client Exchange e spiega come supportare altri client POP3 e IMAP (Internet Message Access Protocol) nella propria organizzazione. In fondo, è un valido riferimento generale per qualsiasi amministratore, rivolto sia a coloro che hanno intenzione di eseguire una progettazione o una manutenzione, che a coloro che desiderano approfondire la propria conoscenza della piattaforma di messaggistica unificata Exchange Server 2007.
Prezzo: $49.99 (prezzo di listino).
(Fare clic sull'immagine per ingrandirla)

Greg Steen è un professionista IT oltre a essere un appassionato imprenditore. È sempre alla ricerca di nuovi strumenti che aiutino a rendere più semplici le operazioni, il controllo della qualità e lo sviluppo per i professionisti IT.


SQL Q&A Errori di I/O, mirroring del database e altro
Paul S. Randal

D Ho iniziato a eseguire controlli di coerenza periodici sui database che gestisco e ho persino aggiunto alcuni avvisi di SQL Agent per rilevare eventuali errori di I/O che si verificano durante le query degli utenti. Non so se la logica che ho implementato nei controlli e negli avvisi funzionerà in quanto nessuno dei database che gestisco presenta problemi di danneggiamento. Come è possibile creare problemi di danneggiamento in un database di test in modo da accertare che tutte le impostazioni configurate funzionino in modo corretto? Inoltre, sono disponibili altri metodi per rilevare eventuali errori di I/O?
R In SQL Server® 2000, il vecchio trucco per creare un database danneggiato per il test prevedeva l'eliminazione manuale di una riga dalla tabella sysindexes di un database di test. Tuttavia, con SQL Server 2005, il danneggiamento di una tabella di sistema utilizzando questo metodo risulta alquanto difficoltoso. Il metodo migliore per danneggiare un database di test consiste nel modificare un file di dati mediante l'uso di un editor esadecimale dopo aver arrestato il database. Di seguito viene illustrata la procedura:
  • Arrestare il database in modo che i file di dati non vengano bloccati. Fare attenzione, tuttavia, a non disconnettere il database, in quanto se si danneggia la pagina errata, è possibile che non si sia in grado di connetterlo di nuovo.
  • Selezionare un valore di offset superiore, ad esempio, a 100 pagine nel file (almeno 819.200 byte), ma assicurarsi che tale valore sia allineato a un limite di 8192 byte (un limite di pagina). Questo consentirà di evitare bitmap di allocazione e pagine di metadati critiche e sarà possibile avviare il database ed eseguire DBCC CHECKDB.
  • Scrivere alcuni byte di zeri nel file in corrispondenza dell'offset selezionato. L'utilizzo di questa tecnica garantisce nella maggior parte dei casi l'introduzione di alcuni errori di danneggiamento delle intestazioni di pagina.
Tuttavia, il metodo più rapido per creare un database di test danneggiato consiste nell'utilizzare un database danneggiato già creato da un altro utente. Esempi di database SQL Server 2000 e SQL Server 2005 danneggiati sono disponibili sul mio blog (con descrizioni) all'indirizzo go.microsoft.com/fwlink/?LinkId=115151.
Quanto alla seconda domanda relativa alle eventuali azioni da intraprendere per rilevare errori di I/O, è opportuno attivare i checksum di pagina. Questa funzionalità è stata introdotta in SQL Server 2005 per proteggere un'intera pagina di database da errori generati dal sottosistema di I/O.
In sostanza, quando una pagina viene scritta su disco, l'ultima operazione eseguita da SQL Server consiste nel calcolare un checksum nell'intera pagina di 8 KB e nel contrassegnare il checksum nella pagina. Quando una pagina viene letta dal disco, se include un checksum di pagina, il checksum viene ricalcolato e confrontato con quello memorizzato nella pagina. La mancata corrispondenza tra i due valori indica che la pagina è stata danneggiata da un problema esterno a SQL Server e viene generato l'errore 824. L'errore viene visualizzato nel corso della connessione che ha causato la lettura della pagina e viene registrato nel log degli errori di SQL Server e nel registro eventi applicazioni di Windows®.
I checksum di pagina sono attivi per impostazione predefinita per tutti i database creati in SQL Server 2005 e SQL Server 2008. Tuttavia, è necessario attivarli manualmente per i database aggiornati dalle versioni precedenti di SQL Server. È possibile attivare i checksum di pagina utilizzando il seguente codice:
ALTER DATABASE mydb SET PAGE_VERIFY CHECKSUM;

Suggerimento: modificare la porta SQL Server predefinita
Per impostazione predefinita, la porta configurata delle istanze di SQL Server è 1433. Quando viene utilizzata da un'istanza, questa porta non può essere occupata da un'altra istanza. Pertanto, se si installa una seconda istanza (denominata) in ascolto sulla rete tramite tcp, sarà necessario utilizzare un'altra porta. In alcuni casi, è opportuno che l'amministratore modifichi la porta per motivi di offuscamento (anche se questa forma di offuscamento è secondaria e può essere facilmente interrotta da uno scanner per porta). In tal caso, è necessario configurare il client per l'utilizzo di una porta differente. Esistono tre approcci comuni per l'esecuzione di questa operazione.
Primo, presupponendo che l'amministratore abbia modificato la porta di un'istanza in 5555, è possibile specificare semplicemente il numero di porta dell'istanza nel nome del computer a cui si desidera connettersi utilizzando la sintassi MyServername,5555. Se la porta viene modificata di nuovo, i client dovranno modificare nuovamente anche la relativa sezione connectionStrings.
Un'altra opzione consiste nell'utilizzare gli alias di SQL Server, che sono configurati sul client. Oltre a specificare il nome di un alias, è necessario specificare anche il nome del server, il nome della porta e il protocollo. Una volta configurato, l'alias può essere utilizzato come nome di server per connettersi all'istanza del database. Il vantaggio di questo approccio è rappresentato dal fatto che le modifiche di configurazione del server possono essere distribuite da un amministratore di dominio, in quanto le impostazioni sono memorizzate nel Registro di sistema.
La terza opzione per le istanze denominate, che prevede che l'utente conosca solo il nome dell'istanza e specifichi il nome utilizzando MachineName\InstanceName in connectionString, consiste nell'utilizzare il servizio SQL Server Browser. Il servizio è già implementato in SQL Server 2000 come parte di un servizio in esecuzione. Tuttavia, in SQL Server 2005, il servizio SQL Server Browser è stato creato come servizio separato. Oltre a individuare le istanze per il computer, il servizio è in grado di rispondere alle richieste UDP (User Datagram Protocol) in ingresso sulla porta 1434 con il numero di porta appropriato per l'istanza richiesta, attivando il reindirizzamento per il client e supportando una connessione trasparente.
- Jens K. Suessmeyer, Database Consultant presso Microsoft

D Per rimuovere completamente la frammentazione nel mio database, ho impostato un piano di manutenzione notturno che consente di ricostruire tutti gli indici nel database di produzione, che viene eseguito su SQL Server 2005 Enterprise Edition con SP2. Avendo, tuttavia, notato che questo determina un aumento eccessivo delle dimensioni del database, ho aggiunto un passaggio che prevede la compattazione di tutto lo spazio aggiuntivo in modo da liberare spazio sul disco. Ora sembra che il passaggio di ricostruzione non funzioni in modo corretto. Che cosa è successo?
R Hai sollevato un problema comune a cui molti utenti devono far fronte durante l'impostazione di un piano di manutenzione. Sei entrato in un ciclo che vede l'alternarsi delle operazioni di compattazione-aumento di dimensioni-compattazione-aumento di dimensioni.
Quando un indice viene ricostruito, prima che l'indice esistente venga eliminato, viene creata una nuova copia dell'indice. Questa procedura richiede spazio aggiuntivo nei file di database, in genere la stessa quantità di spazio utilizzata dall'indice corrente. In SQL Server 2000, lo spazio aggiuntivo era necessario anche per l'ordinamento delle righe dell'indice (circa il 20% delle dimensioni dell'indice); tuttavia, per semplificare il processo di ricostruzione dell'indice, questo requisito è stato eliminato in SQL Server 2005.
Talvolta, gli amministratori desiderano rimuovere lo spazio aggiuntivo creato durante la ricostruzione dell'indice e, pertanto, aggiungono un'operazione di compattazione al piano di manutenzione dopo il passaggio di ricostruzione. Non è molto noto, tuttavia, che l'operazione di compattazione causa una frammentazione dell'indice in ragione della natura del relativo algoritmo. Ne consegue che l'indice appena ricostruito e deframmentato viene immediatamente frammentato, annullando l'effetto stesso della relativa ricostruzione.
Dato che le dimensioni del file di database aumenteranno di nuovo la volta successiva in cui viene eseguita la ricostruzione dell'indice, è preferibile non rimuovere dal database lo spazio aggiuntivo ed evitare di eseguire l'operazione di compattazione. Inoltre, l'esecuzione costante di operazioni di compattazione e di aumento di dimensioni sui file di database causa una frammentazione dei file a livello di sistema operativo, determinando, analogamente alla frammentazione dell'indice, un peggioramento delle prestazioni.
Infine, è opportuno ridurre la frequenza con cui viene eseguito il processo di ricostruzione degli indici. È consigliabile utilizzare un metodo alternativo, come lo strumento DBCC INDEXDEFRAG che ho scritto per SQL Server 2000 o la nuova sintassi ALTER INDEX REORGANIZE in SQL Server 2005 e SQL Server 2008.
È disponibile inoltre un articolo molto utile in cui viene illustrata la frammentazione dell'indice e vengono fornite istruzioni su come rimuovere la frammentazione (go.microsoft.com/fwlink/?LinkId=115154). Sebbene questo articolo sia stato scritto per SQL Server 2000, i concetti restano tutti validi.

D Nella mia organizzazione stiamo valutando la strategia di ripristino di emergenza e ritengo che il mirroring del database rappresenti la soluzione ideale per la nostra situazione. Sul server che sto tentando di proteggere vengono eseguiti numerosi database non correlati (il risultato di un precedente progetto di consolidamento dei server) e vorrei utilizzare il mirroring per tutti i database disponibili. La domanda che mi pongo è la seguente: "Quanti database è possibile sottoporre a mirroring prima che le prestazioni inizino a risentirne?
R Non esiste una risposta precisa a questa domanda: il numero di database varia in base al contesto. Le linee guida pubblicate suggeriscono di non eseguire il mirroring di più di 10 database per ciascuna istanza; tuttavia 10 è solo una stima approssimativa del valore che verrà considerato come numero massimo dalla maggior parte degli utenti. Per quanto riguarda la configurazione dell'hardware, è necessario considerare i seguenti fattori:
  • Quanta memoria è disponibile nelle istanze principali e mirror? In teoria, la quantità di memoria deve essere identica.
  • Qual è la potenza di elaborazione delle istanze principali e mirror? Anche la potenza di elaborazione deve essere identica.
  • Quanta larghezza di banda è disponibile nel sottosistema di I/O nell'istanza mirror? La quantità di larghezza di banda deve essere identica a quella dell'istanza principale.
  • Quanti log delle transazioni vengono generati dal carico di lavoro su ciascun database?
  • Quanta larghezza di banda di rete è disponibile tra le istanze principali e mirror?
Gli ultimi due fattori sono i più critici. Se la larghezza di banda di rete disponibile tra le due istanze non è sufficiente per gestire la frequenza totale di generazione del log delle transazioni al secondo su tutti i database sottoposti a mirroring, le prestazioni subiranno un calo nei database principali. SQL Server 2008 consente di ovviare al problema con la compressione del flusso del log.
Il secondo fattore critico da considerare è rappresentato dai requisiti di memoria e thread per il mirroring. Ciascun database con mirroring richiede un thread e una certa quantità di memoria. Sui server poco potenti l'esecuzione di un numero elevato di database con mirroring potrebbe costituire un carico eccessivo quando combinato con il normale carico di lavoro.
È necessario inoltre considerare la modalità in cui eseguire il mirroring del database. In modalità sincrona, non è possibile eseguire il commit delle transazioni sul database principale fino a quanto tutti i record dei log delle transazioni non sono stati copiati nel log delle transazioni del database con mirroring. Pertanto, qualsiasi ritardo causato da una rete sovraccarica può generare un problema di prestazioni del carico di lavoro sul database principale.
In modalità asincrona, è possibile eseguire il commit delle transazioni sul database principale senza dover attendere, ma un ritardo della rete potrebbe determinare un aumento del numero di log delle transazioni in attesa di essere inviati. Questo può, a sua volta, causare problemi correlati alle dimensioni dei log delle transazioni. Quel che è peggio è che, in caso di errore, tutti i log delle transazioni non inviati verranno persi. Pertanto, più è elevato il numero di log delle transazioni non inviati, maggiore sarà la possibilità di perdita di dati in una situazione di ripristino.
Gli scenari possono variare considerevolmente e, personalmente, ho avuto modo di assistere ad alcuni interessanti esempi in ambienti di produzione reali. Ho esaminato, ad esempio, un ambiente con 150 database, sui quali veniva eseguito un numero piuttosto esiguo di attività e non tutte venivano effettuate contemporaneamente. Il mirroring di tutti i 150 database veniva eseguito senza problemi.
Al contrario, ho esaminato una configurazione che includeva solo tre database con carico elevato, ma senza una connessione di rete efficace. In tale scenario, è possibile eseguire a stento il mirroring di un singolo database prima che la mancanza di larghezza di banda di rete determini un peggioramento delle prestazioni del carico di lavoro.
La chiave per il corretto funzionamento del mirroring del database è eseguire innanzitutto il calcolo della generazione dei log. Se la larghezza di banda di rete disponibile è in grado di supportare il numero di database di cui si desidera eseguire il mirroring, non vi sarà alcun problema. Verificare la configurazione prima di distribuirla nell'ambiente di produzione e assicurarsi di includere tutte le operazioni che possono generare il log delle transazioni, in particolare le operazioni di manutenzione del database eventualmente eseguite.

Paul S. Randal è Managing Director di SQLskills.com e MVP per SQL Server. Ha lavorato nel team di SQL Server Storage Engine in Microsoft dal 1999 al 2007. Paul ha scritto il comando DBCC CHECKDB/repair per SQL Server 2005 ed era responsabile di Core Storage Engine durante lo sviluppo di SQL Server 2008. Paul, che vanta una notevole esperienza nell'ambito del ripristino di emergenza, della disponibilità elevata e della gestione dei database, partecipa regolarmente a conferenze in qualità di relatore. Il suo blog è disponibile in SQLskills.com/blogs/paul.


Utility Spotlight Windows Vista Upgrade Advisor
Lance Whitney

È giunto il momento di iniziare a pianificare l'aggiornamento della propria organizzazione a Windows Vista® e, analogamente a quanto accade con qualsiasi tipo di aggiornamento, numerose sono le domande che bisogna porsi. I client di rete soddisfano i requisiti hardware e software? Quali problemi di compatibilità occorrerà affrontare? Per aiutare le organizzazioni a rispondere a queste e ad altre domande, Microsoft fornisce lo strumento Windows Vista Upgrade Advisor, disponibile gratuitamente. Questa utilità esegue la scansione di tutti i componenti hardware e software installati in un computer per determinare se è possibile eseguire un aggiornamento. Se è possibile, Advisor consiglia la versione ottimale di Windows Vista da utilizzare e segnala tutti i problemi da risolvere prima di eseguire l'aggiornamento.
La scansione eseguita da Upgrade Advisor in genere richiede alcuni minuti. Durante l'esecuzione della scansione, in un grafico vengono elencate le diverse versioni di Windows Vista e vengono confrontate le funzionalità di ciascuna versione. È inoltre possibile selezionare una specifica edizione, Ultimate, Home Premium, Business o Home Basic, per visualizzare una breve descrizione e un elenco delle funzionalità più importanti. Una volta completata la scansione, la schermata relativa ai dettagli di report indica se il computer fornisce il supporto per Windows Vista e la versione che è consigliabile utilizzare. I dettagli includono:
Requisiti di sistema I requisiti di sistema indicano se i componenti hardware, ovvero CPU, RAM, memoria video e unità CD/DVD, sono sufficienti. In caso contrario, vengono fornite informazioni sui requisiti necessari per l'aggiornamento del computer, indicando ad esempio la quantità di memoria aggiuntiva necessaria.
Dispositivi Vengono esaminati tutti i driver e i dispositivi esterni, tra cui modem, stampante, scanner, scheda audio, monitor e scheda video. Se un dispositivo non supera il test di compatibilità, nel report vengono indicate le azioni da intraprendere, come il download dei driver più recenti dal sito Web del produttore. A tal fine, viene fornito un collegamento al sito Web appropriato.
Upgrade Advisor segnala i problemi di compatibilità noti e consiglia i metodi appropriati per risolverli
Upgrade Advisor segnala i problemi di compatibilità noti e consiglia i metodi appropriati per risolverli (Fare clic sull'immagine per ingrandirla)
Programmi Viene analizzato il software installato. Vengono indicate le applicazioni che è possibile eseguire in un ambiente Windows Vista e le applicazioni che non sono compatibili o che devono essere aggiornate per superare il test.
Se un componente non supera il test di compatibilità quando eseguito su una versione più potente di Windows Vista, come Ultimate, è possibile tornare alla schermata introduttiva e selezionare un'altra versione, ad esempio Business. In tal modo, sarà possibile verificare se il computer in uso soddisfa tutti i requisiti di tale versione.
Infine, un elenco delle attività descrive la configurazione hardware del computer e illustra nei dettagli le attività che occorre completare prima e dopo l'installazione di Windows Vista. Fornisce inoltre un riepilogo degli elementi delle schermate precedenti e offre raccomandazioni aggiuntive, come illustrato nella schermata. L'elenco delle attività può essere stampato o salvato come file HTML.
Upgrade Advisor viene eseguito su un sistema Windows Vista a 32 bit o su Windows® XP Service Pack 2 e richiede l'utilizzo di Microsoft® .NET Framework 2.0 e MSXML 6.0. Per ulteriori informazioni sullo strumento e per eseguirne il download, accedere al sito Web all'indirizzo microsoft.com/windows/products/windowsvista/buyorupgrade/upgradeadvisor.mspx.

Lance Whitney è un consulente IT, docente e technical writer. Ha dedicato molto tempo alle modifiche di workstation e server di Windows. In origine era un giornalista, ma circa 15 anni fa ha fatto un salto nel buio lanciandosi nel mondo dell'IT.


Inside SharePoint Decentralizzazione dell'amministrazione di siti
Pav Cherny

Scarica il codice per questo articolo: SharePoint2008_06.exe (1160KB)

Microsoft Windows SharePoint Services (WSS) 3.0 e Microsoft Office SharePoint Server (MOSS) 2007 supportano un modello di sicurezza e di amministrazione flessibile che consente alle organizzazioni IT di centralizzare il controllo sui componenti dell'infrastruttura, come server Web e server di database, nonché di decentralizzare il controllo
sulle raccolte siti e sui siti ospitati. La centralizzazione dell'infrastruttura SharePoint® consente di ridurre l'overhead di manutenzione, consolidare la logica aziendale, fornire un singolo punto di accesso alle risorse SharePoint ed evitare investimenti non necessari nella tecnologia.
Nello stesso tempo, la decentralizzazione dell'amministrazione dei siti consente ai singoli reparti di mantenere un controllo autonomo sulle raccolte siti, sui siti, sulle raccolte documenti, sugli elenchi e sulle soluzioni di flusso di lavoro di reparto SharePoint nonché su altre risorse SharePoint ad essi associate. Tuttavia, uno degli svantaggi della delega dell'amministrazione dei siti a singoli reparti è rappresentata dalla maggiore complessità di gestione per il reparto IT. Come è possibile, ad esempio, tenere traccia dell'utilizzo delle risorse, dei siti di SharePoint scaduti e del contenuto non aggiornato in un'infrastruttura centralizzata se non si ha accesso ai siti e alle raccolte siti all'interno dell'ambiente in uso?
In questo articolo viene illustrato il modello di sicurezza di WSS 3.0, compresi i vantaggi e le implicazioni associati alla delega del controllo amministrativo sui siti di SharePoint ai singoli reparti, mantenendo nel contempo il controllo amministrativo centralizzato sull'infrastruttura SharePoint. Verrà inoltre illustrata la modalità di funzionamento dell'amministrazione delegata dei siti e verrà descritto come le autorizzazioni di accesso e la limitazione per motivi di sicurezza a livello di sito, elenco ed elemento consentano di garantire un ambiente di lavoro sicuro e semplice da gestire. Infine, verrà mostrato come gli amministratori di Web farm siano in grado di ottenere l'accesso alle statistiche dei siti necessarie senza disporre di autorizzazioni SharePoint elevate.
Se si desidera seguire le mie spiegazioni in un laboratorio di test, scaricare il materiale associato a questo articolo all'indirizzo technetmagazine.com. Il materiale contiene istruzioni dettagliate sulla distribuzione per una Web farm basata su Windows Server® 2008 che riflette in modo appropriato un ambiente di produzione per un'azienda con più reparti.

Amministrazione della raccolta siti e dell'infrastruttura SharePoint
È possibile creare un'infrastruttura SharePoint in base a una distribuzione a server singolo o una distribuzione di una Web farm. In effetti, le aziende utilizzano in genere entrambi gli approcci. La distribuzione a server singolo è appropriata per i singoli reparti che necessitano di una soluzione di collaborazione rapida e semplice. I requisiti di prestazioni e affidabilità sono minimi. Gli utenti tendono ad essere più comprensivi di fronte a una situazione in cui un server SharePoint di reparto, distribuito in genere sull'hardware di una workstation, non è disponibile in quanto la gestione dei sistemi rientra nell'ambito delle responsabilità del reparto e gli utenti che lavorano in tale reparto, dopo tutto, non sono amministratori IT.
Il quadro cambia completamente nel caso delle risorse server gestite dal reparto IT. Le prestazioni e l'affidabilità diventano fattori di importanza critica che, spesso, richiedono la distribuzione di soluzioni a disponibilità elevata per assicurare la conformità al contratto di servizio (SLA). Le distribuzioni di Web farm con carico bilanciato, i cluster di failover di SQL Server® e i database archiviati in reti SAN (Storage Area Network) possono contribuire a soddisfare le esigenze aziendali in termini di prestazioni ed elevata disponibilità. Per un'illustrazione di questa architettura, vedere la Figura 1.
Figura 1 Infrastruttura SharePoint con cluster di failover SQL Server e archiviazione SAN
Figura 1 Infrastruttura SharePoint con cluster di failover SQL Server e archiviazione SAN (Fare clic sull'immagine per ingrandirla)
Come è possibile osservare nella Figura 1, per gestire le risorse in un'infrastruttura SharePoint centralizzata, è necessaria la collaborazione di diversi tipi di amministratori; tuttavia, ciascuno di questi amministratori esamina l'ambiente da una prospettiva differente. Ad esempio, i server nell'infrastruttura sono trasparenti agli amministratori di raccolte siti. Gli amministratori delle raccolte siti utilizzano l'interfaccia utente SharePoint standard. Questa interfaccia non cambia, sia che i siti vengano ospitati su una workstation all'interno del proprio ufficio su cui viene eseguito WSS 3.0 sia che vengano ospitati in una Web farm all'interno di un centro dati.
L'infrastruttura SharePoint è inoltre trasparente agli amministratori di database e ai progettisti dell'archiviazione SAN. Per questi amministratori, i database di SharePoint sono identici a qualsiasi altro database di SQL Server e i numeri di unità logica (LUN, Logical Unit Number) per il cluster di failover di SQL Server non sono diversi da qualsiasi altro LUN. L'amministratore che ricopre un ruolo più diretto nella gestione dell'infrastruttura SharePoint è l'amministratore di Web farm che, tuttavia, non ha alcun controllo sulle raccolte siti, sui database o sui numeri di unità logica.
È opportuno dire che gli amministratori delle raccolte siti di reparto, in genere, non conoscono i dettagli dell'infrastruttura. Dopotutto, non è necessario conoscere questi dettagli per eseguire il provisioning dei siti e delegare le autorizzazioni di accesso a team e gruppi all'interno di un reparto. È semplice creare un nuovo sito e avviare nuovi rapporti di collaborazione; inoltre problemi, come i costi di archiviazione elevati associati alla tecnologia SAN, raramente vengono presi in considerazione.
Con ogni progetto e iniziativa, vengono creati nuovi siti di team, i siti scaduti continuano a essere visualizzati e il contenuto non aggiornato non viene eliminato; in tal modo, l'ambiente SharePoint si espande rapidamente a un passo impressionante fino a quando non raggiunge una scala che gli amministratori di sistema non possono più ignorare. Ad esempio, l'ambiente SharePoint interno in Microsoft in passato includeva più di 180.000 siti prima che Microsoft IT avviasse un'iniziativa di semplificazione nel 2006.
Una formazione adeguata degli amministratori delle raccolte siti può contribuire a tenere sotto controllo i diversi aspetti di un'infrastruttura SharePoint centralizzata. Anche l'applicazione di quote e blocchi alle raccolte siti risulta utile, anche se questi metodi non sono molto efficaci quando si tratta di gestire siti di team e contenuti non aggiornati che sprecano preziose risorse di backup e archiviazione.
I contenuti non aggiornati non portano necessariamente al superamento della quota di una raccolta siti. È possibile, ovviamente, configurare SharePoint per l'invio di notifiche tramite posta elettronica ai proprietari delle raccolte siti e per l'eliminazione automatica delle raccolte siti inutilizzate dopo uno specifico periodo di tempo mediante la funzionalità Conferma utilizzo siti ed eliminazione nel sito Amministrazione centrale di SharePoint 3.0; tuttavia questa funzionalità non funziona a livello di singolo sito. Una raccolta siti può contenere siti aggiornati e obsoleti, ma la funzionalità Conferma utilizzo siti ed eliminazione non funziona a questo livello di granularità.
Più avanti in questo articolo verrà illustrato come identificare i siti non utilizzati e i contenuti non aggiornati controllando la data dell'ultima modifica di documenti ed elementi di elenchi, anche senza disporre di autorizzazioni di accesso alla raccolta siti. Questa funzionalità di report non è disponibile per impostazione predefinita, ma non è difficile da implementare.

Amministrazione decentralizzata dei siti di SharePoint
La delega dei privilegi di amministrazione dei siti di SharePoint è molto semplice. Utilizzando il sito Amministrazione centrale di SharePoint 3.0, lo strumento da riga di comando Stsadm.exe o uno strumento di provisioning personalizzato, è possibile creare applicazioni Web, percorsi gestiti e raccolte siti all'interno dell'infrastruttura. In qualità di amministratore di Web farm, durante la creazione di una raccolta siti, è possibile specificare amministratori di raccolte siti principali e secondari. Gli amministratori di raccolte siti possono essere normali utenti di dominio. Non richiedono autorizzazioni amministrative per la Web farm o altri server dell'infrastruttura. Utilizzano i relativi browser Web per eseguire le attività di amministrazione dei siti direttamente nell'interfaccia utente di SharePoint.
Nella Figura 2 viene illustrata l'amministrazione delegata dei siti in base alle istruzioni dettagliate disponibili nei fogli di lavoro del materiale di accompagnamento. In questo esempio, l'amministratore di Web farm ha eseguito il provisioning delle raccolte siti separate per il reparto HR (http://sharepoint/hr) e il reparto IT (http://sharepoint/it).
Figura 2 Amministrazione delegata dei siti di SharePoint
Figura 2 Amministrazione delegata dei siti di SharePoint (Fare clic sull'immagine per ingrandirla)
Gli amministratori HR e IT possono quindi utilizzare la funzionalità Siti e aree di lavoro disponibile nel menu Azioni sito nell'interfaccia utente di SharePoint per creare siti secondari e possono applicare le autorizzazioni dal sito padre o definire nuove autorizzazioni utente e amministrative per i siti secondari. Tenere presente che, se non configurato diversamente in modo esplicito, l'amministratore di Web farm non può accedere a nessun sito principale o secondario, l'amministratore HR non può accedere ai siti IT e l'amministratore IT non può accedere ai siti HR, anche se tutti i siti sono ospitati nello stesso ambiente SharePoint.
La progettazione delle gerarchie delle raccolte siti e dei siti dipende dai requisiti dell'organizzazione. Nell'esempio riportato nella Figura 2 non è stato creato un sito master in base a http://sharepoint/hr e http://sharepoint/it. In altre parole, non è presente alcuna raccolta siti nel percorso http://sharepoint. Tuttavia, è possibile creare una raccolta siti in questo percorso o utilizzare altri percorsi gestiti, come http://sharepoint/sites/hr e http://sharepoint/sites/it.
È possibile, inoltre, creare applicazioni Web separate per HR e IT in modo da stabilire URL di base più intuitivi, come http://hr e http://it, eseguire il provisioning di siti portale generali per i reparti e utilizzare le web part di rollup per elencare le informazioni dei siti secondari in questi siti master. Le raccolte siti separate facilitano l'amministrazione autonoma, consentono di limitare l'accesso alle informazioni del reparto, forniscono singole funzionalità di personalizzazione per le pagine master, i layout di pagina, i modelli, le web part e i controlli di spostamento e possono essere utilizzate per inserire dati riservati in database del contenuto dedicati, separati da altre raccolte siti e altri database del contenuto.

Ruoli, autorizzazioni di siti e limitazione per motivi di sicurezza
Dopo aver creato le raccolte siti e aver delegato le autorizzazioni amministrative, l'amministratore di una raccolta siti può aprire un sito principale e utilizzare la funzionalità Impostazioni sito disponibile nel menu Azioni sito per gestire la raccolta siti. Questa attività include l'aggiunta (o la rimozione) degli altri amministratori di raccolte siti con autorizzazioni complete a tutti i siti della raccolta siti, la creazione di gruppi, l'associazione di questi gruppi a ruoli, l'aggiunta di utenti ai gruppi in questione per concedere autorizzazioni di lettura e collaborazione nonché il provisioning di siti di team e siti di gruppi secondari.
Sebbene sia possibile concedere autorizzazioni SharePoint agli utenti singolarmente, è preferibile creare gruppi SharePoint in base a ruoli specifici. Ad esempio, SharePoint include tre gruppi predefiniti per i ruoli Visitatori, Collaboratori e Proprietari. I visitatori dispongono dell'accesso di sola lettura; i collaboratori possono aggiungere elementi a elenchi e raccolte documenti e personalizzare le pagine Web; i proprietari dispongono del controllo completo.
Una funzionalità molto interessante è la capacità di SharePoint di eseguire la limitazione per motivi di sicurezza in base al ruolo dell'utente, il che implica che gli utenti sono in grado di visualizzare solo i collegamenti e gli elementi dell'interfaccia utente per i quali dispongono delle autorizzazioni di accesso. Se a un utente non si consente di accedere a una risorsa, come un elenco (configurando autorizzazioni esplicite in Impostazioni elenco) o un elemento di elenco selezionato (utilizzando il comando Gestisci autorizzazioni nel menu di scelta rapida dell'elemento), l'elenco o l'elemento non sarà visibile all'utente in questione. Se l'utente specifica l'URL dell'elemento direttamente nel browser, l'utente accederà alla pagina Errore: accesso negato.
Nella Figura 3 viene illustrata la funzionalità di limitazione per motivi di sicurezza in azione. L'amministratore HR dispone di autorizzazioni complete ed è in grado di utilizzare il menu Azioni sito per eseguire attività amministrative. Il visitatore HR, invece, dispone solo delle autorizzazioni di sola lettura alla raccolta siti e non è in grado di visualizzare questo menu.
Figura 3 Limitazione per motivi di sicurezza basata sui ruoli degli utenti nell'interfaccia SharePoint
Figura 3 Limitazione per motivi di sicurezza basata sui ruoli degli utenti nell'interfaccia SharePoint (Fare clic sull'immagine per ingrandirla)
La limitazione per motivi di sicurezza è molto utile in quanto nasconde funzionalità, collegamenti ed elementi inaccessibili, ma implica anche che gli amministratori di Web farm non possono utilizzare l'interfaccia utente SharePoint per elencare siti e risorse di siti senza disporre delle autorizzazioni di accesso. Queste risorse non vengono visualizzate nelle pagine Web o nelle web part. Inoltre, le risorse inaccessibili non vengono visualizzate nei risultati di ricerca, in quanto il servizio di ricerca avanzato di SharePoint esegue la limitazione per motivi di sicurezza in fase di query in base all'identità dell'utente che invia la query.

Considerazioni sulla riga di comando
Se l'interfaccia utente grafica non fornisce l'accesso alle informazioni desiderate senza disporre di autorizzazioni elevate a livello di raccolta siti, lo strumento da riga di comando Stsadm.exe rappresenta la soluzione al problema. Si potrebbe, ad esempio, pensare che sia possibile utilizzare il comando
Stsadm -o enumsites -url http://sharepoint
per elencare tutte le raccolte siti e i proprietari nell'applicazione Web http://sharepoint. Utilizzando quindi il seguente comando, si dovrebbe essere in grado di elencare tutti i siti secondari:
Stsadm -o enumsubwebs -url <raccolta siti>
Tuttavia, in un ambiente di Web farm, quando si esegue un'operazione di questo tipo, Stsadm.exe in genere visualizza un messaggio di errore che indica la mancanza di autorizzazione di accesso al database. Stsadm.exe non è in grado di enumerare le raccolte siti anche se si è amministratori di Web farm e consente di gestire le raccolte siti in Amministrazione centrale di SharePoint 3.0. Di seguito viene riportato il messaggio di errore visualizzato se si utilizza Stsadm.exe in una Web farm senza autorizzazioni di accesso a SQL Server:
C:\Programmi\File comuni\Microsoft Shared\Web Server Extensions\12\BIN>stsadm -o enumsites -url http://sharepoint
<Sites Count="2">
<Site Error="Impossibile aprire il database &quot;WSS_Content&quot; richiesto dall'account di accesso. Accesso non riuscito.&#xD;&#xA;Accesso non riuscito per l'utente 'CONTOSO\SPAdmin'.">
<Site Error="Impossibile aprire il database &quot;WSS_Content&quot; richiesto dall'account di accesso. Accesso non riuscito.&#xD;&#xA;Accesso non riuscito per l'utente 'CONTOSO\SPAdmin'." />
L'amministratore di Web farm riceve questo messaggio di errore perché Stsadm.exe viene eseguito nel contesto dell'utente connesso, come CONTOSO\SPAdmin, mentre il sito Amministrazione centrale di SharePoint 3.0 accede ai database di SharePoint nel contesto dell'account di sistema associato al pool di applicazioni di Amministrazione centrale di SharePoint 3.0, come CONTOSO\WssConfigAdmin. Sebbene la concessione all'account delle autorizzazioni db_owner per il database del contenuto in SQL Server consenta di eseguire il comando Stsadm -o enumsites -url http://sharepoint, non si sarà comunque in grado di enumerare i siti secondari all'interno della raccolta siti. Il comando Stsadm -o enumsubwebs -url <raccolta siti> restituisce il messaggio di errore Accesso negato. (Eccezione da HRESULT: 0x80070005 (E_ACCESSDENIED)), quindi si ritorna al punto di partenza. Tuttavia, esiste un metodo più efficace che non richiede autorizzazioni SQL Server elevate.

Informazioni relative al sito nei database del contenuto
Se non è possibile ottenere le informazioni desiderate tramite le interfacce e gli strumenti SharePoint standard, è necessario accedere direttamente ai database del contenuto SharePoint. Tenere presente, tuttavia, che questa operazione deve essere eseguita solo come ultima risorsa. I database del contenuto si basano su strutture di database e schemi proprietari che sono stati documentati da Microsoft solo parzialmente in WSS 3.0 SDK nel tentativo di impedire ai clienti di utilizzare i database direttamente. Quando possibile, per accedere alle informazioni desiderate, è opportuno utilizzare l'interfaccia utente, gli strumenti da riga di comando, il modello a oggetti o i servizi Web SharePoint.
Se non i dispone di altre alternative ed è necessario accedere ai database direttamente, è consigliabile almeno limitare la soluzione all'accesso di sola lettura. La modifica delle strutture di database o dello schema di database non è supportata e può causare problemi seri che potrebbero richiedere il ripristino delle raccolte siti dal backup o la reinstallazione della Web farm SharePoint.
Un'alternativa possibile all'implementazione di una soluzione di report che consenta di accedere direttamente ai database del contenuto consiste nello specificare l'account dell'amministratore della Web farm come proprietario secondario nella configurazione della raccolta siti. Gli amministratori di Web farm possono eseguire questo passaggio nel sito Amministrazione centrale di SharePoint 3.0. È possibile trovare il collegamento Amministratori raccolta siti corrispondente in Gestione siti di SharePoint nella pagina Gestione applicazioni.
Un amministratore secondario di raccolte siti può aprire la raccolta siti nel browser Web, visualizzare le impostazioni del sito e fare clic sul collegamento Report utilizzo sito in Amministrazione sito, purché si sia attivata la funzionalità Elaborazione analisi dati di utilizzo in Amministrazione centrale di SharePoint 3.0. Se si desidera tenere traccia dei dati di utilizzo nei file di registro sui server SharePoint, utilizzare Registrazione e report nella pagina Operazioni. La funzionalità Report utilizzo sito è disattivata per impostazione predefinita.
Tuttavia, la creazione manuale dei report di utilizzo del sito per le singole raccolte siti non è una soluzione pratica in ambienti con un numero elevato di raccolte siti o con requisiti rigidi che impediscono la concessione agli amministratori di Web farm delle autorizzazioni necessarie. Un approccio più pratico prevede l'implementazione di un'applicazione di report ASP.NET semplice che elenca tutte le raccolte siti e i siti presenti nel database del contenuto insieme a statistiche importanti, ad esempio il numero di elementi, la dimensione totale di tutti gli elementi e la data dell'ultima modifica degli elementi, come illustrato nella Figura 4.
Figura 4 Come ottenere direttamente le statistiche del sito da un database del contenuto
Figura 4 Come ottenere direttamente le statistiche del sito da un database del contenuto (Fare clic sull'immagine per ingrandirla)
Se si esegue questa applicazione con l'identità dell'account del pool di applicazioni di Amministrazione centrale SharePoint 3.0, sarà possibile ottenere l'accesso ai database del contenuto senza la necessità di disporre di autorizzazioni SQL Server elevate. Come affermato in precedenza, l'account di Amministrazione centrale dispone già delle autorizzazioni SQL Server necessarie.
Il materiale di accompagnamento include una semplice soluzione di report che prevede l'esecuzione di query SELECT nel database del contenuto sul server SQL e istruzioni dettagliate per la distribuzione di questa soluzione su un server Web. È importante notare che non è stato implementato alcun controllo di sicurezza. La soluzione viene eseguita con l'autenticazione anonima.
Non è necessario autenticare l'utente perché l'account di Amministrazione centrale fornisce il contesto di sicurezza richiesto per accedere ai database del contenuto. Per il sito Web della soluzione è stata utilizzata una porta personalizzata, bloccata tramite Windows® Firewall in Windows Server 2008; pertanto, solo un utente locale può aprire l'applicazione Web. In tal modo, i requisiti di sicurezza nell'ambiente di test sono stati soddisfatti, ma in un ambiente di produzione, è consigliabile rafforzare ulteriormente la sicurezza, ad esempio attivando l'autenticazione di Windows e configurando autorizzazioni di accesso restrittive alla directory virtuale dell'applicazione ASP.NET.

Conclusioni
SharePoint fornisce funzionalità di amministrazione di siti e raccolte siti flessibili che consentono di centralizzare l'infrastruttura SharePoint, decentralizzando nel contempo l'amministrazione dei siti in base alle specifiche esigenze aziendali. Un'infrastruttura centralizzata può essere vantaggiosa per le aziende di qualsiasi dimensione, in quanto un ambiente consolidato consente di ridurre i costi, semplifica la condivisione delle informazioni all'interno dei reparti, fornisce le basi per applicare le conoscenze degli esperti in modo più mirato per gestire l'ambiente con livelli elevati di sicurezza, affidabilità e scalabilità e offre agli utenti un singolo punto di accesso ai siti e alle risorse SharePoint nella rete aziendale.
I singoli reparti e unità aziendali, allo stesso tempo, possono continuare ad avere il controllo delle relative risorse SharePoint. Gli amministratori di Web farm possono designare gli amministratori delle raccolte siti, che eseguono quindi le attività di amministrazione dei siti all'interno delle relative aree di responsabilità senza alcun ulteriore coinvolgimento del reparto IT.
Tuttavia, con la delega del controllo ai reparti, gli amministratori di Web farm non sono più in grado di monitorare l'utilizzo delle risorse nell'infrastruttura mediante l'uso delle funzionalità e degli strumenti SharePoint standard. L'applicazione di quote ai database del contenuto, l'invio di promemoria tramite posta elettronica agli amministratori delle raccolte siti e il rilevamento dei dati di utilizzo a scopi di report possono contribuire ad attenuare il problema; tuttavia, per gestire l'infrastruttura SharePoint in modo efficace, gli amministratori di Web farm necessitano di ulteriori strumenti in grado di estrarre i metadati dei siti necessari direttamente dai database del contenuto in modalità di sola lettura.
Le opzioni disponibili includono l'utilizzo di SQL Server 2005 Reporting Services o di una soluzione di report aziendale simile. Come illustrato nell'esempio del materiale di accompagnamento, per ottenere le informazioni necessarie, è inoltre possibile utilizzare le query SELECT di SQL Server.

Pav Cherny è un esperto IT e un autore specializzato in tecnologie Microsoft per la collaborazione e le comunicazioni unificate. Le sue pubblicazioni includono white paper, manuali di prodotti e libri su amministrazione del sistema e operazioni IT. Pav è Presidente di Biblioso Corporation, un'azienda specializzata in servizi di localizzazione e documentazione gestita.


Windows PowerShell Un output bello e chiaro
Don Jones

Non è insolito desiderare che i propri script producano un output chiaro e piacevole e mi viene spesso chiesto quale sia il modo migliore per ottenere, ad esempio, delle tabelle. Esistono in effetti un paio di possibili metodi per produrre elementi del genere. La prima operazione da eseguire consiste nello scrivere uno script che inserisca i dati (qualsiasi tipo di dati che si desideri visualizzare con una determinata formattazione) in variabili denominate
$data1, $data2 e $data3. A questo punto si procede con la formattazione dei dati.

La modalità testo
Sul Web
Una dimostrazione veloce delle tecniche illustrate nell'articolo Windows PowerShell di questo mese è all'indirizzo technetmagazine.com/video, dove è possibile vedere come Don Jones utilizza i cmdlet.

Questa attività viene spesso eseguita allo stesso modo in cui si gestirebbe un'operazione simile in un linguaggio come VBScript, Perl, KiXtart o un altro linguaggio orientato al testo. È possibile iniziare scrivendo una serie di intestazioni di colonne nella schermata:
Write-Host "ColumnA'tColumnB'tColumnC"
È importante notare che `t è una sequenza di escape speciale in Windows PowerShellTM che inserisce un carattere di tabulazione. Per scrivere ciascuna riga della tabella, ricordando che i dati sono in $data1, $data2 e $data3, non si hanno molte scelte. Una possibilità consiste nello scrivere semplicemente le variabili, fidando sulla capacità della shell di sostituire le variabili con il relativo contenuto all'interno di virgolette doppie:
Write-Host "$data1't$data2't$data3"
Un'altra possibilità, che consente di ottenere un risultato un po' più ordinato, è l'utilizzo dell'operatore -f. Con questa tecnica si separa la formattazione dai dati e si ottiene una riga di codice di più facile lettura e manutenzione:
Write-Host "{0}'t{1}'t{3}" –f $data1,$data2,$data3
Questo approccio, tuttavia, presenta dei problemi sostanziali. Prima di tutto, quando si fa affidamento sulle tabulazioni fisse nella finestra della console, bisogna aspettarsi delle formattazioni strane. Se, ad esempio, una particolare riga di tabella ha un valore di 20 caratteri nella prima colonna, si scombussola l'intera formattazione della riga. Inoltre, poiché per l'output del testo si utilizza Write-Host, la visualizzazione viene limitata a una console.
Non esiste un metodo semplice per inviare l'output a un file o per renderlo in altri formati, in caso fosse necessario. Ciò che più conta, l'approccio basato sul testo non tiene in alcun conto la shell basata sugli oggetti che si sta utilizzando e non sfrutta tutte le incredibili tecniche e funzionalità che Windows PowerShell offre.

Il metodo di Windows PowerShell
Windows PowerShell è una shell orientata a oggetti. Vale a dire, teoricamente, che tutti gli elementi su cui si lavora devono essere all'interno di oggetti, consentendo alla shell di trasformare il tutto in visualizzazioni di testo, quando richiesto. Ma come si creano degli oggetti per blocchi di dati arbitrari?
Se si procede con l'esempio, si inizia creando un oggetto vuoto personalizzato che viene quindi memorizzato in una variabile:
$obj = New-Object PSObject
Si ottiene così un nuovo oggetto vuoto su cui lavorare. Si aggiungono quindi i dati all'oggetto nella forma di proprietà. A tal fine, è sufficiente inviare l'oggetto al cmdlet Add-Member. Si aggiunge quindi un elemento denominato NoteProperty, si attribuisce un nome alla proprietà (è una buona idea utilizzare le intestazioni di colonna come nomi di proprietà) e si inseriscono i dati come valori per le proprietà:
$obj | Add-Member NotePropertyColumnA $data1
$obj | Add-Member NotePropertyColumnB $data2
$obj | Add-Member NotePropertyColumnC $data3
A questo punto è sufficiente eseguire l'output dell'oggetto, non alla console ma alla pipeline:
Write-Output $obj
È quindi possibile ripetere questi passaggi per ciascuna riga della tabella di cui si desidera ottenere l'output. Di seguito è riportata una breve funzione che accetta una stringa ed esegue l'output di una versione maiuscola e di una versione minuscola, oltre alla stringa originale:
functionStringVersions {
param([string]$inputString)
  $obj = New-Object PSObject
  $obj | Add-Member NoteProperty Original($inputString)
  $obj | Add-Member NoteProperty Uppercase($inputString.ToUpper())
  $obj | Add-Member NoteProperty Lowercase($inputString.ToLower())
  Write-Output $obj
}
$strings = @("one","two","three")
foreach ($item in $strings) {
StringVersions $item
}
Ai fini dell'esempio si inizia da una matrice di variabili di stringa, considerate singolarmente una per volta e inviate alla funzione. L'output della funzione viene quindi scritta nella pipeline.
Esistono metodi più rapidi per scrivere questo codice, ma ho scelto di descrivere questa tecnica perché illustra in modo chiaro il punto da esaminare. Il risultato, come illustrato nella Figura 1, è una tabella perfettamente formattata. Ciò accade perché la shell sa già come formattare gli oggetti in una tabella.
Figura 1 L'output di Windows PowerShell visualizzato in una tabella
Figura 1 L'output di Windows PowerShell visualizzato in una tabella (Fare clic sull'immagine per ingrandirla)
Quando un oggetto ha quattro o meno proprietà, Windows PowerShell sceglie automaticamente una tabella. Quindi senza alcuna necessità di intervento da parte dello sviluppatore, si ottiene una tabella molto chiara e gradevole.

Non è finita qui.
Cmdlet del mese: Get-Command
Sono sicuro che molti hanno già utilizzato Get-Command o il suo utile alias (gcm), una o due volte per esaminare l'elenco dei cmdlet disponibili di Windows PowerShell. Ma non tutti sanno quanto è davvero flessibile gcm. Se, ad esempio, si è interessati a scoprire tutto ciò che Windows PowerShell può fare con un servizio, eseguire gcm -noun service. Se invece si desidera visualizzare tutte le opzioni di esportazione di Windows PowerShell, provare con gcm -verb export. Se, ancora, serve solo visualizzare i cmdlet che sono stati aggiunti da un determinato snap-in, come PowerShell Community Extensions, provare con gcm -pssnapin pscx (si può sostituire "pscx" con qualunque nome di snap-in per visualizzare i cmdlet dello snap-in corrispondenti).
Come si può vedere, Get-Command è fondamentale nella fase di scoperta di Windows PowerShell. Consente di conoscere le funzionalità disponibili senza dover neanche aprire un manuale. Inoltre gcm rappresenta un metodo più preciso per scoprire le funzionalità rispetto all'utilizzo di un comando come Help *. Con la funzione Help si ottiene solo un elenco degli argomenti della guida disponibili. I cmdlet che non sono dotati di guida non vengono neanche riportati nell'elenco, anche se i cmdlet sono disponibili quando necessario.

Il vantaggio offerto da questa tecnica supera di gran lunga il semplice ordinamento in tabella. Quando si lavora con gli oggetti, Windows PowerShell sa già come trattare una gamma molto ampia di elementi. Si devono esportare i dati in un file CSV? Basta utilizzare Export-CSV. Si preferisce una tabella HTML? Basta inviare gli oggetti a ConvertTo-Html. È necessario formattare un elenco? Basta inviare i dati a Format-List. Quando si utilizzano gli oggetti, si possono sfruttare tutte le funzioni che la shell sa già come eseguire. Ecco un esempio:
functionStringVersions {
  PROCESS {
   $obj = New-Object PSObject
   $obj | Add-Member NoteProperty Original($_)
   $obj | Add-Member NoteProperty Uppercase($_.ToUpper())
   $obj | Add-Member NoteProperty Lowercase($_.ToLower())
   Write-Output $obj
}
}
Questa volta la funzione è stata modificata in modo da accettare l'input della pipeline (sempre una buona idea quando si lavora con gli oggetti) e di eseguire l'output sulla pipeline.
Il codice della funzione ora è all'interno di uno scriptblock PROCESS. Ne consegue che la funzione accetterà l'input della pipeline ed eseguirà lo scriptblock PROCESS una volta per ciascun oggetto proposto dalla pipeline.
All'interno dello scriptblock PROCESS, la variabile speciale $_ fa riferimento all'oggetto di pipeline corrente in corso di elaborazione. Il risultato pratico è la possibilità di inviare semplicemente tramite pipeline una matrice di stringhe:
@("one","two","three") | StringVersions
Si ottiene una tabella perché la funzione invia l'output alla pipeline. Alla fine della pipeline, la shell richiama il sottosistema di formattazione, che prende autonomamente la decisione di utilizzare una tabella perché gli oggetti nella pipeline hanno meno di cinque proprietà (per impostazione predefinita, quando le proprietà sono più di cinque, la shell utilizza un elenco).
Ma non è necessario confidare sul comportamento predefinito. Per fare in modo che gli oggetti vengano trattati in modo diverso, è sufficiente inviarli a un altro cmdlet:
@("one","two","three") | StringVersions | Format-List
@("one","two","three") | StringVersions | ConvertTo-HTML | Out-File "strings.html"
@("one","two","three") | StringVersions | Export-CSV "strings.csv"
@("one","two","three") | StringVersions | Select Uppercase,Lowercase -unique
Nella Figura 2 viene illustrato l'HTML che risulta dal secondo esempio visualizzato in un browser Web. La semplice rappresentazione dei dati di output in oggetti, piuttosto che in testo semplice, consente di accedere a una ricca gamma di funzionalità integrate nella shell: una varietà di layout di formattazione; conversione in HTML; opzioni di esportazione; possibilità di ordinamento, filtraggio e raggruppamento e molto altro ancora.
Figura 2 Output dei dati di Windows PowerShell nel formato HTML
Figura 2 Output dei dati di Windows PowerShell nel formato HTML (Fare clic sull'immagine per ingrandirla)
Si tratta di funzionalità molto potenti. Infatti, non esito a consigliare di scrivere tutti gli script in modo da produrre un oggetto come output, che potrà quindi essere utilizzato nei modi più diversi senza ricorrere alla scrittura di una sola riga di codice aggiuntiva.

Don Jones è un esperto di automazione dell'amministrazione di Windows e ha scritto libri come Windows PowerShell: TFM e VBScript, WMI, and ADSI Unleashed. È possibile contattarlo nei forum del sito ScriptingAnswers.com.


Hey, Scripting Guy! Anche chi non lavora troppo duramente avrà le sue ricompense
I Microsoft Scripting Guy

Scarica il codice per questo articolo: HeyScriptingGuy2008_06.exe (150KB)

Per centinaia di anni, le persone hanno creduto che il lavoro duro rappresentasse in se stesso una ricompensa, che la vera soddisfazione fosse nello svolgere un lavoro onesto e che la vera felicità derivasse dalla meta da raggiungere e non dal viaggio da intraprendere. Bisogna lavorare sodo e senza lamentarsi (tipo Cenerentola) e, un giorno, verremo ricompensati.
Nota: ma è realmente vero che se si lavora duramente si sarà più felici e, un giorno, si verrà anche ricompensati? Perché ci si fa una domanda del genere?
Ovviamente, Cenerentola era fortunata; dopotutto, se si vive con una perfida matrigna e due perfide sorellastre, si avrà certamente l'opportunità di lavorare sodo. Ma per chi non è così fortunato? Cosa accade a chi non vive con una perfida matrigna e due perfide sorellastre? In che modo potrà fare un lavoro lungo ed estenuante? Come potrà mai riuscire a trovare la vera felicità?
Se si è destinati e determinati a lavorare sodo, gli Scripting Guy suggeriscono di provare a scrivere uno script che generi un output di dati in un formato tabulare preciso, come quello mostrato nella Figura 1.
Figura 1 Output tabulare
Figura 1 Output tabulare (Fare clic sull'immagine per ingrandirla)
Come abbiamo già detto, Cenerentola era molto fortunata: poteva pulire la casa da cima a fondo e, dopo aver finito, poteva tranquillamente restarsene seduta tra la cenere e la fuliggine. Ma anche Cenerentola sarebbe stata riluttante a scrivere uno script per visualizzare i dati in formato tabulare. Rimanersene seduti tra la cenere e la fuliggine è una cosa. Scrivere uno script che generi un output di dati in formato tabulare è una cosa completamente diversa.
Nota: sono cose diverse se non si è costretti a starsene seduti vicino al focolare per scrivere lo script; in caso contrario, le due cose corrispondono.
Perché Cenerentola dovrebbe essere riluttante nei confronti di questa attività? Semplicemente perché è maledettamente faticosa. L'unico modo per visualizzare i dati in formato tabulare in VBSCRIPT è eseguire una delle operazioni indicate:
  • Iniziare determinando le dimensioni massime per ogni colonna. Ad esempio, si potrebbe desiderare che il nome visualizzato di un servizio sia di 52 spazi di carattere.
  • Partendo da ciò, calcolare il numero di caratteri in una parte di dati. Ad esempio, il nome visualizzato Adobe LM Service ha 16 caratteri.
  • Se il nome visualizzato supera il limite di 52 caratteri, determinare il numero di caratteri da eliminare per fare in modo che la stringa rientri nello spazio assegnato. Se il nome supera i 52 caratteri, determinare quanti spazi vuoti devono essere aggiunti alla fine della stringa per fare in modo che sia lunga esattamente 52 caratteri.
  • Ripetere la stessa procedura per il set di dati successivo. Quindi, farlo anche per quello dopo e così via.
Se si conosce bene la storia di Cenerentola, si saprà anche che la fatina buona potrebbe arrivare in qualsiasi momento, trasformare il mouse in un amministratore di sistema (in modo semplicissimo) e fare in modo che questi scriva lo script per noi. Ma non si dovrebbe fare troppo affidamento sul fatto che ciò accada. Probabilmente si è soli in questa iniziativa.
Tuttavia, il lato positivo è che potremo essere le persone più soddisfatte del mondo. E questo perché saremo le persone che sgobbano di più al mondo. Quelle che svolgono il lavoro di gran lunga più duro.
Alcuni certamente preferirebbero barattare una parte di soddisfazione con la possibilità di non dover lavorare così duramente. Ma non siamo noi quelle persone; probabilmente si starà pensando: "Grazie al cielo, ci sono gli Scripting Guy; mi diranno come fare per trasformare un mouse in un amministratore di sistema e riuscire a generare un output in formato tabulare". Ebbene, ci dispiace, ma ci sono delle cattive notizie: gli Scripting Guy non hanno assolutamente idea di come fare per trasformare un mouse in un amministratore di sistema. (Tuttavia, siamo in grado di trasformare un amministratore di sistema in un mouse, se essere utile.) Non sappiamo dire come si può spingere qualcuno a scrivere script per noi e tanto meno script che generino dati in formato tabulare.
Ma non c'è da preoccuparsi. Finché si esegue Windows® XP o Windows Server® 2003 (come fanno in molti), non si avrà bisogno di un mouse che scriva gli script per noi. (Ci dispiace, ma con Windows Vista® le cose sono diverse.) Potremo farlo da soli, e con il minimo sforzo, grazie all'oggetto Microsoft.CmdLib. A questo punto, osservare lo script di esempio della Figura 2.
Figure 2 Creazione di una visualizzazione tabulare
Dim arrResultsArray()
i = 0

Set objCmdLib = _
  CreateObject("Microsoft.CmdLib")
Set objCmdLib.ScriptingHost = _
  WScript.Application

arrHeader = Array("Display Name", _
  "State", "Start Mode")
arrMaxLength = Array(52, 12, 12)
strFormat = "Table"
blnPrintHeader = True
arrBlnHide = Array(False, False, False)

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" _
  & strComputer & "\root\cimv2")

Set colServices = objWMIService.ExecQuery _
  ("Select * FROM Win32_Service")

For Each objService In colServices
  ReDim Preserve arrResultsArray(i)
  arrResultsArray(i) = _
  Array(objService.DisplayName, _
    objService.State,objService.StartMode)
  i = i + 1
Next
objCmdLib.ShowResults arrHeader, _
  arrResultsArray, arrMaxLength, _
  strFormat, blnPrintHeader, arrBlnHide
Microsoft.CmdLib è un oggetto COM fornito con Windows XP e Windows Server 2003. Quest'oggetto dispone di un'ampia serie di funzioni; per ulteriori informazioni, digitare cmdlib.wsc /? al prompt dei comandi e leggere i commenti nel file script visualizzato. Per ora, ci interessa unicamente la funzionalità di Microsoft.CmdLib, ovvero la capacità di visualizzare i dati in formato tabulare.
Ciò conduce a una domanda ovvia: come fare per visualizzare i dati in formato tabulare? Vediamo se riusciamo a capirlo. Come è evidente, il nostro script di esempio inizia definendo un array dinamico denominato arrResultsArray:
Dim arrResultsArray()
In uno script tradizionale, i dati vengono riprodotti sullo schermo man mano che vengono recuperati. Ma perché ci si dovrebbe aspettare che gli Scripting Guy facciano qualcosa in maniera tradizionale? In questo script, non desideriamo visualizzare i dati sullo schermo man mano che vengono recuperati. Intendiamo invece archiviare tutti i dati restituiti in un array e quindi consentire a Microsoft.CmdLib di formattarli e visualizzarli al posto nostro.
In altre parole, questo è il motivo per il quale iniziamo creando un array dinamico (ovvero, un array che possa essere ridimensionato durante il corso dello script). Dopo aver definito l'array, impostiamo su 0 il valore di una variabile contatore denominata i; utilizzeremo questa variabile per tenere traccia delle dimensioni correnti dell'array.
A questo punto, impostiamo il valore di i su 0 perché il primo elemento di un array è sempre il numero di indice 0. Di conseguenza, quando aggiungiamo il primo elemento all'array, aggiungiamo l'elemento 0 anziché l'elemento 1.
Quindi, dobbiamo inizializzare la nostra istanza dell'oggetto Microsoft.CmdLib; le due righe di codice riportate di seguito hanno questo scopo:
Set objCmdLib = _
CreateObject("Microsoft.CmdLib")
Set objCmdLib.ScriptingHost = WScript.Application
E ciò ci porta a questo piccolo blocco di codice:
arrHeader = Array("Display Name", "State", "Start Mode")
arrMaxLength = Array(52, 12, 12)
strFormat = "Table"
blnPrintHeader = True
arrBlnHide = Array(False, False, False)
Ciò che stiamo facendo è impostare alcuni parametri per configurare il nostro output. Nella prima riga, assegniamo dei valori a un array denominato arrHeader; come previsto, sono le intestazioni per ciascuna delle colonne della nostra tabella di output. Per questo script di esempio, recupereremo le informazioni sui servizi in esecuzione su un computer e quindi visualizzeremo i valori delle proprietà DisplayName, State e StartMode per ogni servizio.
In modo abbastanza prevedibile, assegneremo al nostro array i nomi di colonna Nome visualizzato, Stato e Modalità di avvio (anche se avremmo potuto assegnare alle colonne i nomi A, B, e C; Larry e Moe o qualsiasi altro nome dato che non è necessario che i nomi delle colonne corrispondano ai nomi delle proprietà).
Nota: esistono molte varianti della storia di Cenerentola, che riguardano anche i nomi delle due sorellastre. Nella versione di Disney, le sorellastre si chiamano Genoveffa e Anastasia, che per caso corrispondono proprio al primo e secondo nome del nostro editor di script!
Nella seconda riga del codice, assegniamo dei valori a un altro array, denominato arrMaxLength. Questo array include le dimensioni di ogni colonna della tabella. Nel nostro output, desideriamo allocare 52 spazi di carattere alla colonna 1 (il nome visualizzato del servizio); allocheremo quindi 12 spazi ciascuno alla modalità di avvio e allo stato del servizio. (Microsoft.CmdLib inserirà automaticamente uno spazio vuoto tra le colonne.) Se desideriamo (come in questo caso) che le colonne abbiamo dimensioni di 52, 12 e 12 spazi di carattere, utilizzeremo un codice simile al seguente:
arrMaxLength = Array(52, 12, 12)
La terza riga specifica il formato di output per i nostri dati. Desideriamo che i dati vengano visualizzati sotto forma di tabella; pertanto, impostiamo su Table il valore di strFormat (la variabile che contiene il tipo di output). Supponiamo invece di voler visualizzare i dati sotto forma di elenco di valori delimitati da virgole. In quel caso, dovremmo impostare il formato CSV, come indicato:
strFormat = "CSV"
In questo modo, otterremmo un output simile al seguente:
"Display Name","State","Start Mode"
"Adobe LM Service","Stopped","Manual"
"Adobe Active File Monitor V4","Stopped","Manual"
"Alerter","Stopped","Manual"
"Application Layer Gateway Service","Running","Manual"
"Apple Mobile Device","Running","Auto"
"Application Management","Stopped","Manual"
Microsoft.CmdLib inserisce virgole tra un elemento e l'altro e racchiude i singoli valori tra virgolette. Questa funzione è più preziosa di quanto si potrebbe pensare di primo impatto. Dopotutto, per fare tutto ciò manualmente, si dovrebbe utilizzare un codice di questo tipo:
Wscript.Echo Chr(34) & objService.DisplayName & Chr(34) & "," & Chr(34) & objService.State & Chr(34) & "," & Chr(34) & objService.StartMode & Chr(34)
Complicato, vero?
Cosa c'è? Non piacciono le tabelle, ma neanche il formato CSV? Bene, in tal caso si può provare a impostare il formato su List si otterrà un output simile al seguente:
Display Name: Adobe LM Service
State:        Stopped
Start Mode:   Manual
Display Name: Adobe Active File Monitor V4
State:        Stopped
Start Mode:   Manual
Ma così stiamo facendo una digressione. (Come siamo inclini a fare di tanto in tanto.) Dopo aver definito il formato di output, impostiamo su True il valore di una variabile denominata blnPrintHeader:
blnPrintHeader = True
Utilizzeremo quindi blnPrintHeader per specificare che Microsoft.CmdLib stampi le intestazioni di colonna. Cosa fare se invece non vogliamo stampare le intestazioni di colonna? Bene, in tal caso è necessario impostare blnPrintHeader su False:
blnPrintHeader = False
In questo modo, otterremo questa riga di codice:
arrBlnHide = Array(False, False, False)
Quando arriva il momento di visualizzare i dati, Microsoft.CmdLib ci offre l'opportunità di visualizzare o nascondere una colonna. Per nascondere una colonna (ovvero, per sopprimere i dati per una particolare proprietà), impostare il valore della proprietà su False; per visualizzare una colonna, impostare il valore su False.
Nel nostro output, visualizzeremo i valori per la proprietà DisplayName, State e StartMode, esattamente in tale ordine; quindi, utilizzeremo i valori False, False, False nell'array. Cosa fare per visualizzare DisplayName, nascondere State e visualizzare StartMode? In tal caso, utilizzeremmo questa riga di codice:
arrBlnHide = Array(False, True, False)
Ricordare sempre di utilizzare False per visualizzare una colonna e True per nasconderla.
A questo punto, siamo pronti per generare dei dati, o lo saremmo se avessimo dei dati. (Gli Scripting Guy hanno mai scritto uno script che non riesce a generare dati e quindi impiegato una smisurata quantità di tempo per eseguire il debug dello script e scoprire, infine, che non avrebbero dovuto recuperare alcun dato inizialmente? No, naturalmente; cosa potrebbe mai farlo pensare?)
Ricordando ciò, la nostra prossima operazione consisterà nell'eseguire l'associazione al servizio Strumentazione gestione Windows (WMI) sul computer locale e quindi nell'utilizzare il metodo ExecQuery per recuperare le informazioni su tutti i servizi installati su tale computer:
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colServices = objWMIService.ExecQuery ("Select * FROM Win32_Service")
Probabilmente dovremmo ricordare che in questo caso non si ha l'obbligo di lavorare con i dati WMI. Come previsto, Microsoft.CmdLib può funzionare con qualsiasi tipo di dati. WMI è semplicemente un metodo facile per recuperare una serie di dati.
Una volta ottenuta la nostra raccolta di dati relativi ai servizi, impostiamo un ciclo For Each per eseguire tutti i servizi nella raccolta. Tuttavia, anziché restituire i valori delle proprietà per ogni servizio, eseguiamo questo codice:
ReDim Preserve arrResultsArray(i)
arrResultsArray(i) = Array(objService.DisplayName, objService.State,objService.StartMode)
i = i + 1
Cosa facciamo in questo blocco di codice? Bene, nella riga 1 ridimesioniamo il nostro array, utilizzando il comando ReDim Preserve anche per preservare gli eventuali dati esistenti nell'array. (Senza la parola chiave Preserve, l'array verrebbe ridimesionato, ma gli eventuali dati inclusi nell'array verrebbero cancellati.)
Quali dimensioni abbiamo scelto per l'array? La prima volta che eseguiamo il ciclo, creiamo un array di dimensioni pari a 0; in altre parole, creiamo un array contenente un unico elemento. E come possiamo esser certi di creare un array di dimensioni pari a 0? Perché utilizziamo la variabile contatore i, che è uguale a 0.
Quindi, se utilizzassimo la variabile i per rappresentare le dimensioni dell'array, vorrebbe dire che impostiamo le dimensioni su 0? Sì, è così, tranne se incrementiamo il valore di i di 1 ogni volta che eseguiamo il ciclo; come è evidente, è esattamente ciò che facciamo nella riga 3 del nostro blocco di codice.
In questo modo, ci resta un'unica riga di codice a cui pensare:
arrResultsArray(i) = Array(objService.DisplayName, objService.State,objService.StartMode)
In questo esempio, prendiamo semplicemente in considerazione i valori delle proprietà desiderati (DisplayName, State e StartMode) e li aggiungiamo all'array arrResultsArray. Non intendiamo aggiungere il valore di ogni singola proprietà, ma preferiamo aggiungerli come array di valori. È vero, la cosa è un po' insolita: significa che ogni elemento dell'array arrResultsArray sarà un altro array; Microsoft.CmdLib funziona esattamente in questo modo.
Ovviamente, ciò potrebbe essere fonte di ulteriori preoccupazioni. "Un array di array? In che modo posso mai accedere a ogni singolo valore in un array pieno di array?" Non bisogna allarmarsi. È semplice: è sufficiente lasciare il compito a Microsoft.CmdLib.
Nota: ci dispiace, ma accedere ai singoli valori di un array di array è esattamente l'unica cosa che Microsoft.CmdLib può fare per noi. Tuttavia, pulire le camere della nostra perfida matrigna, lavare i piatti e cucire i vestiti delle nostre perfide sorellastre vengono considerate attività adatte alla versione successiva dell'oggetto.
In realtà, possiamo generare l'output dei nostri dati in un formato tabulare preciso semplicemente chiamando il metodo ShowResults e passandolo a tutti gli array e le variabili configurati in precedenza nello script:
objCmdLib.ShowResults arrHeader, arrResultsArray, arrMaxLength, strFormat, blnPrintHeader, arrBlnHide
Quali risultati si otterranno? Si otterrà esattamente l'output ben formattato che speravamo di ottenere quando abbiamo osservato la Figura 1.
Non male, no? Si ottiene l'output desiderato e quasi senza svolgere alcuna attività. (E il prossimo script sarà anche più facile, perché sarà semplicemente necessario apportare alcune piccole modifiche a questo primo script.)
A questo punto, bisogna ammetterlo, non si proverà lo stesso senso di soddisfazione provato da Cenerentola che sgobba tutto il giorno per visualizzare l'output dello script in una tabella. E, a essere sinceri, probabilmente non si riuscirà neanche a trovare un principe azzurro da sposare; ma ciò non rientra nell'accordo. Tra l'altro, sembra un prezzo da pagare davvero piccolo per riuscire a ottenere l'output ideale da uno script VBScript, soprattutto se si pensa a come sono i principi azzurri al giorno d'oggi.
E chissà: si potrebbe ugualmente riuscire a trovare un principe azzurro. Dopotutto, anche i principi hanno bisogno di ottenere informazioni su tutti i servizi installati sui loro computer, non è vero?

Il rompicapo di script del Dottor Scripto
La sfida mensile che verifica non solo le sue capacità di risoluzione dei puzzle, ma anche le sue competenze di scripting.

Giugno 2008: Percorso di attivazione di PowerShell
In ciascuno di questi puzzle, associare le lettere in orizzontale, verticale e diagonale per creare il nome di cmdlet di Windows PowerShell. Ogni lettera verrà utilizzata una sola volta: Ecco un esempio:
Il cmdlet creato in questo puzzle è New-Alias. Adesso è il suo turno. Ecco altri tre puzzle:

ANSWER:
Il rompicapo di script del Dottor Scripto
Risposte: Percorso di attivazione di PowerShell, giugno 2008

Read-Host

br />Set-AuthenticodeSignature

I Microsoft Scripting Guy lavorano o, per meglio dire, sono stipendiati da Microsoft. Quando non si dedicano al baseball (o a varie altre attività) da giocatori, allenatori o semplici spettatori, gestiscono il TechNet Script Center. Consultare la pagina www.scriptingguys.com.


File desktop Protezione contro Conformità
Wes Miller

In qualità di professionisti dell'IT, vi sarete spesso trovati a dover raggiungere obiettivi che anziché di essere complementari tra di loro erano in conflitto. La protezione e la conformità sono due obiettivi organizzativi talmente correlati che il conseguimento di uno dovrebbe rafforzare l'altro, ma purtroppo non è sempre così. La mia intenzione con questo articolo è fornirvi
una panoramica sui motivi per cui "protetto" non sempre coincide con "conforme" alle iniziative richieste e viceversa o, per lo meno, non sempre conformità e protezione sono complementari come dovrebbero essere.

La protezione non è una casella di controllo
Risorse di SDL
  • The Security Development Lifecycle (in inglese) di Michael Howard e Steve Lipner (Microsoft Press, 2006)
  • Blog di Security Development Lifecycle (in inglese)
  • A Look inside the Security Development Lifecycle at Microsoft (in inglese)
  • Security Developer Center (in inglese)
  • The Trustworthy Computing Security Development Lifecycle (in inglese)

La conformità generalmente implica dei requisiti (persone, processo, infrastruttura, tecnologia e così via) imposti su un'organizzazione, settore, azienda o prodotto dall'esterno. A volte la conformità ha a che fare con uno standard promulgato dall'interno del settore (come le normative Payment Card Industry Data Security Standards o PCI-DSS). Idealmente si tratta di iniziative in linea con il modo di lavorare della vostra organizzazione, al meno fino a un certo punto. Con il proliferare dell'adozione di uno standard, vi sarete resi conto che non è possibile ignorarlo, se si vuole avere successo nel campo degli affari. L'unico atteggiamento da seguire è quindi rispettarlo e trarne i massimi vantaggi.
È l'altro tipo di conformità ad essere di solito più problematico. Mi riferisco alle iniziative stabilite dal governo, come le normative Health Insurance Portability and Accountability Act (HIPAA) e Sarbanes-Oxley (SOX), in cui l'implementazione e la sincronizzazione raramente sono una questione di scelta.
Il punto principale da capire sulla conformità alle normative è che spesso implica un approccio dall'alto verso il basso. In genere un banalissimo modello definisce l'iniziativa ed è necessario esaminare i propri prodotti e processi per capire in che modo integrarli con l'insolito modello fornito. Occorre tenere presente non soltanto l'intento dell'iniziativa di conformità ma soprattutto le eventuali conseguenze legali o finanziarie in cui si potrebbe incorrere se non si seguisse il suddetto modello.
Sebbene l'intento di molte iniziative di conformità sia lodevole, l'implementazione è spesso difficile e non sempre porta al raggiungimento dell'obiettivo desiderato. E purtroppo molte di tali iniziative sono inefficaci, il che significa che il mancato raggiungimento dell'obiettivo di conformità non comporta conseguenze legali o finanziarie.
Come paziente, posso dirvi che non sono in grado di descrivere il reale vantaggio di HIPAA per me. L'unico aspetto che potrei sottolineare è che ho molte più scartoffie da compilare di quando andavo da uno specialista. E le conseguenze impreviste potrebbero essere anche peggiori. Avete mai provato a passare importanti informazioni mediche da un dottore o ente ad un altro? In assenza di autorizzazione scritta, questo processo non è possibile, indipendentemente dall'urgenza con cui si ha bisogno di tali informazioni.
Il punto è che, in molti sensi, alcune iniziative di conformità diventano procedure di compilazione dei campi. Il che significa che si progetta o modifica il proprio processo o prodotto esclusivamente per soddisfare l'iniziativa di conformità. Come spesso chiedo a mio figlio di tre anni: "è una buona idea?"
La protezione, d'altra parte, è un'iniziativa svolta dal basso verso l'alto, quando viene eseguita correttamente. Indipendentemente dal fatto che si stia progettando un prodotto software o l'architettura per la nuova rete della propria organizzazione, il concetto principale da ricordare è "valutare due volte, eliminare una volta sola". Quando si progetta l'architettura di un prodotto, ad esempio, all'inizio è consigliabile descrivere la comunicazione, la localizzazione, le versioni e così via, ossia la procedura preliminare dovrebbe descrivere gli elementi di protezione che è necessario creare nell'applicazione dal primo giorno e che si dovrebbe continuare ad esaminare e perfezionare in ogni fase dello sviluppo.
Se ci si trova a dover gestire un'applicazione o un'architettura ereditata da altri, come avviene nella maggior parte dei casi, è essenziale eseguire il tipo di analisi della protezione approfondita che cito spesso in questo articolo. Se non si capisce il funzionamento di un elemento, come si può capire qual è il suo grado di protezione? Per ulteriori informazioni su Microsoft® Security Development Lifecycle (SDL), consultate il riquadro "Risorse SDL".

Il quadro generale
Ricordo di avere imparato fin da subito che la protezione non equivale alla semplice implementazione della codifica, degli elenchi di controllo accessi (ACL) o dell'infrastruttura a chiave pubblica (PKI). La protezione reale consiste nel comprendere appieno il quadro generale: Capire perché quella versione di quel protocollo è stata eliminata o non è mai stata supportata; perché questa nuova parte della struttura blocca gli attacchi MITM (man-in-the-middle); come mai la propria implementazione per il prodotto v2 è molto più sicura rispetto alla v1, anche se la v1 era molto più rapida. Ed è inoltre necessario comprendere in che modo le varie parti della propria infrastruttura vengono combinate insieme.
La conformità, dall'altro lato, comporta l'utilizzo della propria tecnologia e la verifica del soddisfacimento di determinati criteri all'interno dell'infrastruttura creata. Alcune iniziative, tra cui Payment Card Industry Data Security Standards (PCI-DSS) o North American Electric Reliability Council (NERC), sono ben concepite e potrebbero finire con l'incoraggiare un vero e proprio cambiamento in termini di protezione. Ma, tutto sommato, con una selezione così vasta di iniziative di conformità che è necessario conciliare con i propri specifici progetti e le risorse finite disponibili, le iniziative di protezione perdono terreno.
La protezione è da lungo tempo la "figliastra" dello sviluppo software. Certamente molti di voi hanno lavorato in un'organizzazione in cui la protezione era qualcosa di cui occuparsi in un secondo momento. E, dunque, le iniziative di conformità sono state create proprio perché la filosofia "la protezione può attendere" non funziona e non ha mai funzionato.

La filosofia del "minimo indispensabile"
Recentemente ho cambiato lavoro. Ora lavoro per una nuova azienda qui ad Austin, Texas, che sta creando una tecnologia di whitelist delle applicazioni piuttosto simile alla tecnologia che abbiamo creato a Winternals con il nostro prodotto Protection Manager. Un aspetto che mi è sembrato molto interessante da affrontare con i clienti è la loro valutazione del grado di protezione attuale delle tecnologie correnti in uso o, in modo più specifico, la loro percezione del grado di protezione fornito dalla loro infrastruttura nella suite di tecnologie in uso. Sebbene sia probabile che la maggior parte di loro siano protetti e non soggetti a problemi di violazione della protezione, l'affermazione che sento spesso e che mi fa raccapricciare è che un sistema è "abbastanza sicuro".
Le iniziative di conformità sono buffe: è possibile portarle a compimento o non riuscire a completarle affatto. La responsabilità è vostra. La conseguenza del mancato compimento di un'iniziativa è di solito una multa, una penale o il licenziamento da un'organizzazione. Spesso tali conseguenze non garantiscono che le cose cambino realmente.
Nel caso di un'iniziativa governativa, incontro regolarmente l'atteggiamento "abbastanza buono per soddisfare il revisore" o la volontà di eseguire un sistema senza attuare alcun framework di conformità vero e proprio a causa di un sovvenzionamento inadeguato della normativa legislativa di supporto (come la HIPAA). È molto più conveniente guidare senza assicurazione e affrontare le eventuali conseguenze in un secondo momento!
La protezione colpisce spesso lo stesso blocco stradale, ma nella mia mente almeno è più concreta. Se voi, in qualità di sviluppatori o implementatori, riusciste a far capire ai responsabili che un mancato rispetto delle specifiche renderebbe il prodotto molto più vulnerabile agli attacchi, una volta lanciato il prodotto o completata la distribuzione, avrete la coscienza pulita per avere svolto il vostro compito. Nel campo delle iniziative di conformità, la mia esperienza mi insegna che spesso il soddisfacimento di una specifica è un processo affrettato, condotto con un budget estremamente limitato. Secondo la mia opinione, l'obiettivo è soddisfare il livello minimo richiesto dall'iniziativa, senza capirne lo spirito vero e proprio.

Il vostro ruolo
Risorse di protezione e conformità
  • Security and Compliance Solutions Guidance (in inglese)
  • Guida alla protezione
  • Payment Card Industry Data Security Standard Compliance Planning Guide (in inglese)
  • Conformità alle normative e aggiornamenti della protezione
  • Achieving Compliance (in inglese)
  • Office for Civil Rights—HIPAA (in inglese)
  • PCI Security Standards Council (in inglese)
  • North American Electric Reliability Council (in inglese)

Sebbene possa essere idealistico da parte mia sostenere che dovreste rendere il vostro prodotto e la vostra organizzazione il più possibile sicuri, la realtà è che la maggior parte delle iniziative di conformità non sono altro che un compromesso derivante da una scarsa progettazione o, più spesso, soddisfazione. Viviamo in un mondo dove vige la filosofia dell'accontentarsi. Ma, nel settore della protezione, raramente ci si può accontentare. In qualità di professionisti IT, noi potremmo prendere a cuore le iniziative di conformità e tentare di portarle a compimento sia nell'essenza che nell'implementazione, verificando che l'infrastruttura che stiamo creando non sia soltanto protetta come potrebbe essere, ma piuttosto come dovrebbe essere. In altre parole, dovremmo garantire una conformità tramite protezione reale e non soltanto rispettando l'iniziativa.
È importante fare un passo indietro ed esaminare la tecnologia che si sta creando, sia nel caso in cui si tratti di una parte di software commerciale che nel caso in cui sia una serie di tecnologie da integrare in un sistema di proporzioni maggiori. Non sottolineerò mai abbastanza l'importanza di avere una visione chiara delle componenti del sistema, del loro funzionamento congiunto e delle minacce principali a cui tale sistema potrebbe essere sottoposto.
In base al settore in cui operate, differenti iniziative di conformità potrebbero giocare un ruolo importante nel vostro lavoro. Potreste incontrarle nella vostra vita quotidiana o soltanto in caso di progettazione di nuovi progetti o tecnologie. Oppure, tali iniziative potrebbero far parte del vostro lavoro durante verifiche o analisi di conformità appositamente concepite. Non importa. Ritengo che tali iniziative non vadano ignorate, ma mi piacerebbe che voi sfidaste lo status quo e, invece di operare esclusivamente per il soddisfacimento delle suddette iniziative, eseguiste un'analisi completa della protezione per capire la vostra tecnologia dall'interno e la modellaste contemporaneamente in base all'analisi della conformità.

Cosa avete da perdere?
Tutto sommato, le penali dovute al mancato soddisfacimento di un'iniziativa di conformità potrebbero apparire ambigue. La mancanza di conformità vi mette al rischio proprio per lo scenario da cui l'iniziativa dovrebbe proteggere. Le conseguenze potrebbero sembrare vaghe o remote, ma sono reali. Tuttavia, non è detto che influiscano direttamente su di voi. Siate intransigenti, ma prendete sempre a cuore le tipologie di scenari peggiori.
Se si osserva lo stesso spazio da una prospettiva rigorosa di protezione, la minaccia dovrebbe essere ovvia e soprattutto dovreste essere in grado di identificare immediatamente i potenziali rischi di vulnerabilità.
Molte persone con cui ho discusso questo argomento hanno evidenziato il fatto che le iniziative di conformità sono talvolta dissimulate, poiché spesso danno adito ad un'interpretazione aperta. Una volta condotta un'analisi della protezione, tuttavia, la stessa regola non vale più per le omissioni di protezione. Le minacce immediate dovute ad una protezione ignorata dovrebbero essere chiaramente visibili. Se non lo sono, dovreste riconsiderare la scelta di coloro che si occupano delle analisi della protezione; potrebbero mancare dei membri importanti nel vostro team, in grado di individuare i veri problemi nella vostra soluzione.

Un cane che si morde la coda
Nell'articolo dello scorso anno relativo alla protezione, ho parlato di "Come evitare di perdere i dati" (technet.microsoft.com/magazine/cc162325). Un anno è passato, altri sistemi sono stati compromessi, altri computer portatili sono andati persi e altre informazioni personali sono cadute in mani potenzialmente discutibili. Non è facile dire se siano stati compiuti dei progressi. Perché siamo ancora allo stesso punto? I progetti spesso vengono eseguiti in ritardo, con budget limitato e risorse sovraccariche, nel tentativo di fornire un numero eccessivo di elementi in un intervallo temporale estremamente ridotto.
Questo tipo di ambiente, purtroppo, ne genera un altro in cui il minimo indispensabile diventa la norma. Non è certamente questo il modo per garantire che una soluzione sia protetta o conforme e, contemporaneamente, non influisca su costi o scadenze di un progetto.
Personalmente, sono un fermo sostenitore delle seguenti idee:
  1. Non si dovrebbe creare una soluzione se non si è disposti a proteggerla.
  2. Ogni qualvolta si aggiungono nuovi elementi, è necessario progettarne la protezione prima di iniziare.
  3. Se la vostra organizzazione non è disposta a investire nella protezione all'interno del processo di progettazione, dovreste interrogarvi sugli obiettivi organizzativi o generali della vostra azienda.
Le organizzazioni dispongono sempre più spesso di dati personali di partner e clienti e hanno la responsabilità di tenere tali informazioni al sicuro. Purtroppo viviamo in un mondo in cui, troppo spesso, la protezione non è la norma e i dipendenti non si sentono sicuri quando vengono interpellati sull'impegno dell'organizzazione nei confronti della protezione.
La mancanza di protezione (non di conformità) molto spesso è sintomo del fatto che affermazioni quali "è ora di proteggere il sistema" e concetti quali "assicurazione contro il furto di identità" sono diventati uno stratagemma standard di responsabilità per placare l'ira di clienti, studenti, pazienti e dipendenti i cui dati personali (e il potenziale benessere finanziario) sono stati compromessi.
A tutti noi viene chiesto di fare più del dovuto, spesso con compensi inadeguati e scadenze molto brevi. Ma è nostra responsabilità, in qualità di professionisti dell'IT, interrogarsi sui motivi per cui la protezione non sia il centro d'interesse principale e sul perché i responsabili troppo spesso pensino alla protezione soltanto quando si trovano di fronte ad iniziative di conformità o in caso di violazioni della protezione e delle relative minacce legali reali o potenziali (che potrebbero imbarazzare e mettere a rischio l'organizzazione).

La mia sfida
Vi invito a sfidare lo status quo. Se vi viene richiesto soltanto di soddisfare gli obiettivi di conformità, provate a non sprecare tempo nel soddisfare il concetto di protezione di qualcun altro. Siate certi, piuttosto, che il vostro obiettivo sia la protezione del sistema e, durante il processo, la definizione di elementi sufficienti nel processo o nella vostra infrastruttura per portare a compimento l'iniziativa di conformità. Per ulteriori informazioni su questo argomento, consultate il riquadro "Risorse di protezione e conformità".
In sintesi, ricordate che la conformità troppo spesso non è un percorso verso la protezione. La protezione, tuttavia, se implementata e applicata correttamente, spesso può essere un percorso verso la conformità.

Wes Miller è un Senior Technical Product Manager di CoreTrace (www.CoreTrace.com) di Austin, Texas. In passato ha lavorato per Winternals Software e per Microsoft in qualità di Program Manager. È possibile contattarlo all'indirizzo technet@getwired.com.


The Business of IT 10 punti chiave per diventare leader nelle scelte ambientali
Michael Walsh and Eliza Walsh

Oggi in tutte le aziende si parla di sostenibilità ambientale. Un reparto IT può assumere un ruolo fondamentale in questo campo, con grandi opportunità per i professionisti IT di guidare il cambiamento e diventare leader di riferimento nella propria azienda e nell'intero settore. È necessario però individuare un buon punto di partenza. Ecco 10 punti chiave per diventare leader nelle iniziative di sostenibilità ambientale.
Acquisire familiarità con questo tipo di problematiche
Il primo passaggio consiste necessariamente nello sviluppare conoscenze ed esperienza nel campo della sostenibilità ambientale applicata all'informatica. Un professionista IT può iniziare dal comprendere a fondo i metodi di riduzione dell'impatto ambientale delle attività informatiche, come il risparmio di energia, il consolidamento dell'hardware e la gestione dei rifiuti elettronici.
Un leader in campo ambientale deve anche comprendere in che modo software e hardware possono aiutare a ridurre l'impatto delle operazioni al di fuori del reparto IT. Chi decide di occuparsi di questi argomenti, si troverà a lavorare a stretto contato con responsabili delle risorse umane, avvocati e dirigenti d'azienda per definire le politiche da adottare per ridurre l'impatto ambientale globale dell'azienda in tutti i sensi, dai viaggi per lavoro alla conformità alle norme per ridurre la produzione di anidride carbonica.
Le persone esterne all'azienda si aspettano da un leader in questo ramo le competenze e l'esperienza necessarie in materia ambientale, nelle pratiche aziendali e del settore in cui opera l'azienda. Quindi si devono valutare attentamente le proprie competenze in tema di sostenibilità ambientale e informatica sostenibile, oltre che delle esigenze specifiche della propria azienda a breve e lungo termine.
Un neoassunto o un dipendente che ha appena ricevuto incarichi in questo ambito dovrà sopportare una certa pressione (reale o solo percepita) ad agire con rapidità. Questo è particolarmente vero in aziende che non possono vantare una storia significativa nel posizionarsi come azienda consapevole in materia ambientale (e che ora sono ansiose di recuperare il tempo perduto).
È importante resistere alla tentazione della fretta. Si rischia di perdere la propria credibilità e quella dell'azienda. A breve termine, è preferibile concentrarsi sui problemi urgenti e posporre le iniziative di strategia della comunicazione al momento più opportuno, ovvero a quando l'apprendistato sarà ormai concluso.

Valutare l'azienda con obiettività
Nella fase successiva si deve valutare in modo obiettivo la consapevolezza e sostenibilità ambientale della propria azienda o line of business. A tale scopo, è necessario interagire con tutte le funzioni aziendali interessate e con altre persone influenti all'interno e all'esterno dell'azienda.
Si deve sviluppare una rete di contatti interni ed esterni con persone in grado di fornire input utili nella definizione dell'ecosistema di interessati e decisori. Possono aiutare a sviluppare una migliore comprensione del posizionamento dell'azienda sul campo della sostenibilità ambientale.
In base alle proprie responsabilità, potrebbe essere necessario scoprire il livello di conformità dell'azienda (corrente e futura) rispetto alle normative, agli standard e ai regolamenti ambientali. È probabile che sia necessario valutare la reale posizione dell'azienda rispetto alla concorrenza e alle aspettative degli analisti. È anche necessario comprendere in che modo l'azienda e il lavoro che questa ha intrapreso in ambito ambientale vengono percepiti da clienti, partner, enti pubblici e dalle organizzazioni di difesa dei consumatori più influenti. La determinazione dei limiti tecnologici, finanziari e ambientali correnti e futuri inerenti all'iniziativa possono anche assumere particolare rilievo.
In base alle dimensioni e al budget dell'azienda, può diventare opportuno eseguire ricerche aggiuntive. Una conoscenza costruttiva del problema può derivare da sondaggi interni, gruppi d'interesse e ricerche di terze parti. Può aiutare a capire meglio la soddisfazione dei dipendenti rispetto alle azioni intraprese in passato dall'azienda in materia ambientale, il posizionamento dell'azienda in riferimento alla concorrenza e le opportunità di mercato latenti. Il maggior potenziale di valore qui, tuttavia, è la capacità delle ricerche di terze parti di convalidare o confutare le opinioni delle parti interessate principali.

Prevedere tempi e nuovi posizionamenti dell'azienda
A questo punto si può iniziare a valutare quale deve essere il nuovo posizionamento dell'azienda, sia nel breve che nel lungo termine. Per iniziare, si possono approssimare questi termini come a uno e a cinque anni, rispettivamente, e definire quindi con maggiore precisioni questi periodi di tempo in base alle esigenze specifiche. Il fatto è che l'ambiente non è certo un problema a breve termine e chi si posiziona solo a breve termine rende un pessimo servizio all'azienda, agli azionisti, ai partner e ai clienti.
Per determinare il posizionamento dell'azienda nei periodi a un anno e a cinque anni, è necessario determinare il panorama del mercato corrente e futuro da affrontare. Un'operazione del genere comprende la cultura aziendale, gli obiettivi di mercato a breve e a lungo termine dell'azienda, le limitazioni di budget correnti e future, i progetti di espansione geografica e i cambiamenti di tipo legale e normativo del settore in materia ambientale.
Ad esempio, un centro dati rappresenta un contesto per il conflitto tra decisioni di tipo tattico e posizionamento strategico. In passato, lo spazio era la considerazione principale per la progettazione di un centro dati. Tuttavia, nei pochi anni più recenti, il consumo energetico ha assunto una rilevanza quasi uguale allo spazio come fattore di limitazione della crescita ed è diventato costo operativo in continua crescita. Gli operatori dei centri dati, che hanno compreso le implicazioni a lungo termine della maggiore rilevanza del consumo energetico, hanno adottato delle contromisure per ridurre le inefficienze nel consumo di energia, con cambiamenti radicali nella gestione dei centri dati in contraddizione con il fattore decisionale prevalente dello spazio. In alcuni casi gli investimenti per ridurre i consumi hanno comportato costi a breve termine significativi, se paragonati al mantenimento del paradigma esistente. Tuttavia, con il forte aumento dei prezzi dell'energia, gli operatori dei centri dati che pochi anni fa hanno modificato in maniera proattiva il corso della gestione dei centri dati, ora vengono considerati dei veri preveggenti e le loro aziende hanno più che ammortizzato gli investimenti iniziali.

Sviluppare una visione e una strategia
A questo punto si devono sviluppare una visione e una strategia. Queste devono derivare dalla comprensione del posizionamento attuale e futuro dell'azienda. In fase di definizione, visione e strategia non devono essere considerate come fisse ed eterne. Se l'impegno dell'azienda in campo ambientale è di certo di lunga durata, è probabile che la visione e la strategia non lo siano. Dovranno affrontare revisioni sostanziali dovute a variabili interne ed esterne, come cambiamenti dei requisiti normativi, spostamenti nella percezione dei clienti ed evoluzione nelle esigenze del mercato. Con l'avvento dell'iniziativa ambientale aziendale, è importante allineare visione e strategia IT a visione e strategia aziendale nel suo complesso.
Quando si definisce una visione, si imposta la direzione delle attività aziendali. È importante scegliere con attenzione le parole in modo che siano chiare, concise e coerenti, ma non esaurienti. Con la visione non si vuole rispondere a tutti gli interrogativi sulle iniziative ambientali dell'azienda, ma solo ai problemi che devono essere menzionati per orientare correttamente dipendenti e partner. Una dichiarazione di missione (o di visione) viene spesso utilizzata per trasmettere la visione. È essenziale iniziare a comunicare la visione entro i primi sei mesi dell'incarico.
Con l'impostazione della strategia, non solo si definisce la direzione, ma si stabiliscono anche scopi e obiettivi, oltre a delineare gli investimenti che saranno fatti per conseguire gli scopi e gli obiettivi proposti. Esistono alcuni modelli che possono aiutare a formulare un progetto strategico. Due dei migliori modelli per i problemi di ambiente e sostenibilità sono SWOT (Strengths, Weaknesses, Opportunities and Threats, ovvero punti di forza e di debolezza, opportunità e pericoli) e PESTLE (Political, Economic, Social, Technological, Legal and Environmental, ovvero politica, economia, tecnologia, norme e ambiente). Si può definire quindi la strategia in un documento, come un piano strategico.
In genere i leader che sollecitano commenti e suggerimenti sulle proprie visione e strategia da parte dei diretti interessati, percepiti come sostenitori e resistenti, prima che venga rilasciata la versione scritta della dichiarazione hanno maggiori probabilità di successo. Questo è vero soprattutto per chi richiede commenti e suggerimenti a chi oppone resistenze al piano finale.

Evangelizzare è un imperativo
Non è necessario attendere la stesura di una visione e di una strategia per iniziare l'opera di evangelizzazione. Anzi, questa deve essere intrapresa il giorno stesso in cui si assume il nuovo incarico. Dopo la comunicazione delle proprie visione e strategia, tuttavia, è necessario assumere un ruolo più pubblico, sia all'interno che all'esterno dell'azienda. Inizialmente, è necessario comunicare in prima persona o tramite portavoce la propria visione ai gruppi più influenti, come dipendenti, analisti, stampa, partner, clienti e organizzazioni di difesa dei consumatori. Sarà necessario ispirarli e motivarli a credere nella visione e nella strategia e trovare un argomento in grado di persuadere che la strategia proposta è nell'interesse dell'azienda e dell'audience in generale.
Nel corso del tempo, si dovrà spostare l'attenzione sui singoli elementi della strategia. È inoltre necessario aggiornare periodicamente l'audience di destinazione, facendo risaltare i risultati significativi ottenuti, comunicando gli eventuali cambi di strategia e parlando francamente delle sfide che l'azienda o il settore in generale devono affrontare.
Ciascuna audience presenterà interessi ed esigenze diversi. Se da un lato si dovrà saper parlare alle esigenze e agli interessi specifici di ogni audience, dall'altro la visione e la strategia sottostanti dovranno restare coerenti. In tal modo sarà più semplice ottenere l'approvazione e la collaborazione delle diverse audience di destinazione.
È bene resistere all'impulso di comunicare "esigenze aziendali" in conflitto tra loro per accontentare audience diverse. Un leader che si comporta in questo modo non acquisisce credibilità sui problemi. Come minimo, ne risulta limitata l'efficacia nel condurre il cambiamento. Nel peggiore dei casi, si mette in pericolo la credibilità dell'intera azienda. Nella Figura 1 sono evidenziati i sette punti chiave per comunicare il proprio messaggio con efficacia.
Figura 1 Sette punti chiave per la comunicazione del messaggio
Figura 1 Sette punti chiave per la comunicazione del messaggio (Fare clic sull'immagine per ingrandirla)

Gestire il messaggio
Quando si comunicano le proprie visione e strategia, è necessario tenere conto della professionalità e integrità dei messaggi indirizzati sia all'interno che all'esterno dell'azienda. Ambiente e sostenibilità sono tanto collegati alla responsabilità sociale dell'azienda quanto allo sviluppo del prodotto, ai servizi, alle vendite e al marketing. Anche se dal punto di vista funzionale l'azienda assegna la leadership ambientale a una figura professionale, senza peraltro attribuire a tale figura la proprietà sugli sforzi di cittadinanza di sostenibilità ambientale, il leader deve agire sempre in base alla supposizione di essere tenuto agli stessi standard di cittadinanza.
Non si deve sottostimare la passione per i problemi ambientali e la conoscenza delle pratiche aziendali ambientali dell'audience esterna. È ancora più importante non sottostimare anche la sua capacità di smontare la comunicazione proposta, se questa manca di integrità o promette troppo o troppo poco. In caso contrario l'azienda rischia di essere etichettata come "ambientalista di facciata".
Quindi, nella strategia di comunicazione deve essere prevista una procedura di verifica che coinvolga degli esperti interni, in grado di fornire commenti e suggerimenti prima che si assuma una posizione pubblica. La strategia di comunicazione deve includere gli elementi principali del messaggio, ad esempio, un foglio informativo aziendale sull'ambiente, un framework di messaggistica, un elenco di portavoce approvati e gli argomenti oggetto delle comunicazioni. La strategia di comunicazione, che è fondamentale ai fini di una struttura chiara e coerente, deve essere completata poco dopo lo sviluppo di visione e strategia. È possibile trarre vantaggio dall'attribuire le responsabilità personali ai proprietari principali della messaggistica.

Attivare la gestione mediante la misurazione
È importante gestire le responsabilità all'interno dell'ambito di visione e strategia. Per operazioni, sviluppo del prodotto o vendite e marketing, si devono definire i fattori che hanno un impatto sulla capacità di raggiungere scopi e obiettivi. Tali fattori devono essere organizzati in un breve elenco e associati al piano globale strategico. Sarà quindi necessario definire i fattori qualitativamente e/o quantitativamente e stabilire dei criteri di misurazione di controllo che rendano possibili analisi future. I criteri di misurazione devono essere gestiti attivamente.
Le responsabilità per il reporting dei criteri di misurazione di controllo devono essere definite in modo chiaro e si devono organizzare riunioni periodiche con tutte le parti interessate. Le parti interessate potranno quindi discutere sull'impatto dei criteri di misurazione sull'integrità del piano strategico, attività resa possibile dall'associazione dei criteri di misurazione ai fattori e dei fattori, a propria volta, ai singoli elementi del piano strategico.
Purtroppo, molti leader in campo ambientale scopriranno che le organizzazioni di riferimento non sono preparate a supportare un controllo basato su misurazioni con gli strumenti adeguati. Ma questi strumenti sono necessari per fornire i dati qualitativi e quantitativi necessari per analizzare correttamente e riportare i dati sul lavoro svolto per la sostenibilità ambientale. Quindi è necessario sviluppare strumenti di misurazione specializzati, mediante la ridefinizione dei processi aziendali, la distribuzione di tecnologie di collaborazione e misurazione o lo sviluppo di strumenti interni personalizzati.
In assenza del supporto della direzione aziendale sull'investimento dell'azienda negli strumenti di misurazione, si dovranno prendere importanti decisioni di costi e benefici sull'opportunità di attribuire agli strumenti di misurazione necessari una priorità maggiore rispetto alle spese per personale aggiuntivo.

Analizzare e riportare l'impatto ambientale
La raccolta di dati quantitativi e qualitativi consente di eseguire analisi approfondite. Le analisi sono fondamentali per i leader che vogliono conoscere i risultati delle proprie iniziative e l'impatto delle azioni intraprese sull'azienda o sulla line of business.
Il panorama mutevole del reporting in base a regolamenti, standard, normative e iniziative volontarie delle aziende in materia ambientale ha posto grande pressione sulle aziende per la pubblicazione di informazioni dettagliate sugli impatti ambientali delle rispettive attività. La disponibilità degli strumenti e processi necessari a supporto di gestione, misurazione e analisi facilita la raccolta delle informazioni utili per i report annuali obbligatori, per gli archivi richiesti e per i report volontari dell'azienda sulla sostenibilità. È, quindi, importante comprendere quali sono i requisiti di reporting correnti e quali saranno nel futuro, in modo da poter investire in un'infrastruttura integrata di gestione, misurazione, analisi e reporting che crescerà insieme alle esigenze aziendali.
La tecnologia per analisi e reporting è molto importante per le aziende che cercano di emergere come leader in questo campo. Il software assume un ruolo fondamentale in questo spazio, soprattutto il software utilizzato per gestione ambientale, progettazione dei processi, raccolta dei dati, manipolazione dei dati, telerilevamento, collaborazione, visualizzazione e presentazione.
Il software commerciale disponibile a volte dovrà essere personalizzato per applicazioni specifiche nello spazio ambientale. È quindi possibile che l'investimento in tecnologia diventi significativo, se finalizzato alla creazione di un'infrastruttura integrata di gestione, misurazione, analisi e reporting.

Essere un leader
La leadership è ovviamente fondamentale da conseguire per un leader ambientale. È vero che esistono tipi diversi di leader (vedere la Figura 2 per alcuni esempi), ma tutti hanno questo in comune: la loro competenza non deriva da un titolo, ma piuttosto dalla capacità comprovata di intraprendere azioni e condurre il cambiamento con integrità e apertura.
Figura 2 I diversi tipi di leader
Figura 2 I diversi tipi di leader (Fare clic sull'immagine per ingrandirla)
L'ecosistema della sostenibilità ambientale globale si fonda su leader in grado di guidare il cambiamento. Con una rete in espansione di contatti tra enti pubblici, privati, aziende del settore e organizzazioni di difesa dei consumatori, un leader può mettere in connessione le parti più influenti per risolvere problemi che richiedono una stretta collaborazione. Un leader conosce anche bene molti dei problemi ambientali emergenti, che sono di interesse per la comunità globale, e può diffondere le informazioni su radici e soluzioni di questi problemi a un pubblico globale.
Infine, un leader sa immaginare soluzioni a problemi importanti che non sono ancora entrati nel cono di interesse del settore su scala globale. Lo sviluppo di queste soluzioni può richiedere la collaborazione e la reciproca influenza con altri, compresa la concorrenza, e può spingere la propria azienda verso mercati non ancora serviti, ma il risultato è che un leader può influire su cambiamenti di livello globale.

Restare aggiornati
Questa è una disciplina tutta nuova e le novità nel corpo di conoscenze che ne costituisce la base sono continue. Una credibilità duratura richiede una comprensione da studioso delle diverse prospettive scientifica, politica, legale, economica e commerciale promosse da altri leader in ambito ambientale. Ma non per questo è necessario conformarsi con le opinioni dominanti del giorno, quanto piuttosto promuovere prospettive originali basate sulle competenze in materia di sostenibilità ambientale e informatica. Questa integrità sarà un importante fattore di differenziazione, dato il numero sempre crescente di leader ambientali (o di persone che si presentano come leader) nel settore.
Un leader deve anche mostrare sicurezza nel delegare responsabilità ai collaboratori con competenze specifiche su un argomento di interesse e nel lasciare ai dirigenti più esperti in politiche ambientali all'interno dell'azienda quando un impegno lo richiede. Mentre le riunioni periodiche con i dirigenti e i report garantiscono il mantenimento di un livello di conoscenza completo sugli sforzi dell'azienda in riferimento alla sostenibilità ambientale, la chiave sta nel sapere quando è il caso di parlare a nome dell'azienda. A questo scopo sono necessari una comprensione chiara dei principali impegni assunti e una volontà che rifletta la sincera responsabilità di sostenere le soluzioni di sostenibilità ambientale necessarie che le audience interna ed esterna si aspettano.

Michael Walsh è Senior Environmental Product Manager presso Microsoft.
Eliza Walsh è Communications Strategy Consultant e ha lavorato come Communications Specialist per Microsoft in Cina.


Field Notes Condivisione di uno schermo
Kentaro Toyama

Consentire al maggior numero di utenti possibile di accedere al computer è il grandioso obiettivo di Microsoft Research India, già raggiunto grazie a MultiPoint (illustrato nel numero di TechNet Magazine di maggio 2008), un programma che consente a numerosi utenti di interagire con un PC utilizzando più mouse.
Split Screen è un'altra forma di elaborazione degli accessi simultanei condivisi sviluppata da Microsoft Research India. Il programma configura un unico computer con due tastiere e due mouse e quindi adatta Servizi terminal per suddividere il monitor nella parte centrale. Due utenti possono quindi condividere il monitor, eseguendo istanze separate del sistema operativo e il software prescelto in modo indipendente su ciascun lato (research.microsoft.com/users/udaip/splitscreen.htm). Ad esempio, un utente può svolgere un'attività di elaborazione testi mentre l'altro utilizza un foglio di calcolo.
Per abilitare Split Screen, vengono utilizzate tre istanze separate di Terminal Server in esecuzione in Windows Server® 2003 (al momento stiamo eseguendo l'aggiornamento a Windows Server 2008). Il primo è un contenitore, che acquisisce e ridistribuisce tutti gli eventi dei mouse e delle tastiere. Questo livello utilizza lo stesso trucco utilizzato per MultiPoint, dove vengono acquisiti tutti gli eventi dei mouse e delle tastiere, unitamente ai relativi ID dispositivo (Windows® assegna automaticamente ID univoci ai dispositivi USB collegati; non sono univoci per il dispositivo hardware, ma nell'istanza di funzionamento corrente e ciò consente di capire se i due clic provengono dallo stesso mouse o da due mouse diversi). Il contenitore attira anche i cursori del mouse.
Al suo interno, è possibile aprire due istanze aggiuntive di Terminal Server, ognuna delle quali ricevente solo gli eventi relativi a uno schermo. Nella modalità predefinita, tutti gli eventi derivanti dal mouse con ID x, ad esempio, finiranno nello schermo di sinistra, mentre quelli dell'ID y verranno inclusi nello schermo di destra.
Split Screen utilizza Servizi terminal per suddividere il monitor di un computer nella parte centrale
Split Screen utilizza Servizi terminal per suddividere il monitor di un computer nella parte centrale (Fare clic sull'immagine per ingrandirla)
È importante disporre dell'istanza contenitore di Terminal Server per avere il controllo totale di dove vanno a finire gli eventi e per abilitare funzioni più avanzate. Ad esempio, è possibile consentire al cursore di destra di spostarsi sullo schermo di sinistra e semplicemente puntare (a scopo di esercitazione) o persino interagire con l'altra finestra.
In questo caso, una parte degli eventi del mouse di destra verrà inclusa anche nello schermo di sinistra. Avevamo inoltre considerato l'uso della tecnologia di virtualizzazione in Windows per eseguire funzioni simili; ciò è possibile, ma abbiamo riscontrato un maggiore utilizzo di risorse.
I ricercatori si preoccupavano del fatto che gli utenti potessero essere insoddisfatti della possibilità di utilizzare solo metà parte di uno schermo. Abbiamo condotto degli studi a Bangalore, India, con la Hope Foundation, che ha l'obiettivo di insegnare ai giovani delle zone urbane a basso reddito i principi fondamentali dei computer. Gli studenti sembravano apprendere con Split Screen esattamente allo stesso di modo di quando avevano un unico computer, almeno relativamente a una serie limita di attività di formazione IT. Ricercammo anche la presenza di problemi ergonomici, ma non insorsero, anche sugli schermi a 14". Fattore più importante, il centro di formazione IT era ben lieto di poter supportare un numero doppio di studenti con lo stesso numero di computer.
Microsoft Research India sta valutando con Servizi terminal e altri gruppi Microsoft se Split Screen è una tecnologia da introdurre sul mercato. Se Split Screen è esattamente ciò che desiderate utilizzare, fateci conoscere in quali scenari intendete farlo. Inviare un messaggio di posta elettronica a splitscr@microsoft.com.

Kentaro Toyama è Assistant Managing Director di Microsoft Research India (research.microsoft.com/india) e Principal Researcher of the Technology per il gruppo Emerging Markets (research.microsoft.com/research/tem), che sviluppa strategie per le comunità a basso reddito a livello mondiale.


Windows Confidential I due peggiori computer di tutti i tempi
Raymond Chen

Nel marzo 2007, quando PC World pubblicò l'elenco dei 10 peggiori computer di tutti i tempi, le prime due posizioni catturarono la mia attenzione perché erano occupate da computer che ho utilizzato sul lavoro. Insomma, "utilizzato" è una parola grossa. Forse dovrei dire che ho assistito alla parabola di questi due computer, mentre passavano la maggior parte della loro vita produttiva in un ufficio di un dipendente Microsoft.
Il Barbie PC della Mattel si è classificato al secondo posto tra i peggiori nell'elenco di PC World. Questo computer doveva rappresentare un'importante evoluzione rispetto ai computer economici con colori scialbi. In effetti era un computer economico con colori scialbi su cui però si potevano incollare eleganti adesivi rosa, se rendo l'idea. Veniva venduto con del software in tema Barbie preinstallato.
Ne acquistammo uno come computer di test e ricordo che il povero tester a cui fu affidato questo computer ebbe almeno il senso dell'umorismo di tuffarsi nell'impresa con finto entusiasmo, applicando tutti gli adesivi e le decorazioni fornite per garantire un'installazione "come da progetto" del computer. Lo posizionammo sulla scrivania in bella vista, in modo che chiunque passasse dal corridoio e notasse il vistosissimo disastro rosa fosse invogliato a entrare per giocarci un po'.
Il Barbie PC è stato un'ottima e inesauribile fonte di divertimento. Quando si verificava un problema sul computer e gli sviluppatori dovevano intervenire presso il nostro ufficio per il debug, la reazione era sempre di un attimo di esitazione prima di una profusione di esclamazioni "forte!", non appena diventava chiaro che il computer su cui era richiesto l'intervento era proprio quello rosa. Mi dicono che un'estate gli stagisti di un'università decisero di installare una copia della Datacenter Edition di Windows Server® sul Barbie PC, per puro divertimento.
L'onore, o meglio il disonore, della prima posizione è andato al computer di Packard Bell. Ah, che ricordi! Solo un esempio della cura posta nella progettazione di questo computer: la configurazione predefinita non prevedeva nemmeno uno slot di espansione libero. Devono aver pensato: "Il nostro computer è così perfetto che non sarà mai necessario migliorarlo".
Ai tempi del progetto di Windows® 95, uno dei dirigenti lo acquistò come computer domestico e vi installò regolarmente la versione più recente di Windows 95 sfoggiando l'usuale fiducia nel proprio prodotto. Come è facile immaginare, si verificò ogni sorta di problemi e fu necessario mandarlo molto spesso in assistenza.
Il responsabile dello sviluppo di Windows 95 era un uomo intelligente con l'abitudine ad affrontare i problemi in modo molto diretto. Per accertarsi che Windows 95 garantisse la migliore copertura di compatibilità delle applicazioni possibile, ad esempio, si recò presso il più vicino negozio di informatica con il suo furgone pick-up e comprò una copia di tutti i programmi disponibili in negozio. Tornato in azienda, scaricò tutti i prodotti software sui tavoli della mensa e invitò i membri del team Windows 95 a prenderne almeno un paio, con la clausola condizionale che dovevano installare ed eseguire tutto il software che sceglievano, registrando i bug e tutto ciò che non funzionava, anche il problema più irrilevante. In cambio, i membri del team potevano tenersi il software. La mensa diventò una specie di mercato delle pulci, con tanta gente che curiosava tra i tavoli in cerca di un buon affare chiedendo a tutti i colleghi: "Tu cosa hai preso?".
Imbarazzato dalla frequenza con cui il nostro alto dirigente era costretto a portare il computer in assistenza, il responsabile dello sviluppo di Windows 95 adottò ancora una volta un approccio diretto al problema. Presso lo stesso negozio di informatica comprò un computer Packard Bell identico a quello del nostro dirigente.
La sola esistenza di due computer di questo tipo era di per se una pessima evenienza, ma ciò che la rese peggiore fu che il secondo computer fu affidato a me per l'installazione di tutte le nuove versioni di Windows 95 e il debug degli eventuali problemi. In tal modo, l'alto dirigente avrebbe sempre installato la versione più recente sul suo computer senza problemi.
Chi ha seguito con un po' di attenzione la descrizione degli eventi, avrà già capito che nel piano c'era un inghippo. Poiché non esistevano slot di espansione liberi sul computer Packard Bell, era praticamente impossibile installare una scheda di rete. Per ottenere la connessione alla rete dovetti ricorrere a ogni tipo di mezzucci ed espedienti. Ecco un computer che ho davvero odiato!

Raymond ChenThe Old New Thing, così come nell'omonimo libro, vengono illustrate la storia di Windows e della programmazione in Win32. Una dimostrazione di come la storia possa suggerire sempre nuove soluzioni per il futuro.