Modello di architettura logica: distribuzione aziendale

Contenuto dell'articolo:

• Informazioni sul modello

• Obiettivi di progettazione globali

• Server farm

• Utenti, aree e autenticazione

• Provider di servizi condivisi

• Siti di amministrazione

• Pool di applicazioni

• Applicazioni Web

• Raccolte siti

• Database del contenuto

• Aree e URL

• Criteri per le aree

In questo articolo viene descritta un'implementazione pratica dei componenti dell'architettura logica per ottenere una progettazione efficace. Le informazioni incluse in questo articolo devono essere utilizzate con il modello Esempio di progettazione: Architettura logica di distribuzione aziendale (informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=82151&clcid=0x410) (informazioni in lingua inglese) .

Nel modello viene illustrata una distribuzione aziendale generica di Microsoft Office SharePoint Server 2007. Nel modello vengono applicati quasi tutti i componenti dell'architettura logica e viene illustrato in che modo tali componenti vengono integrati nella progettazione complessiva. In questo articolo vengono descritti gli obiettivi di progettazione per il modello e viene spiegato in che modo tali obiettivi possono essere raggiunti utilizzando i componenti dell'architettura logica illustrati nel modello.

Informazioni sul modello

Nel modello viene illustrata una distribuzione aziendale per una società fittizia denominata Fabrikam, Inc. La distribuzione comprende due server farm. Una server farm ospita la rete Intranet aziendale e il sito Web partner. La seconda farm ospita il sito Web aziendale (www.fabrikam.com).

Intranet

La rete Intranet aziendale include le applicazioni seguenti:

• Contenuto Intranet pubblicato (ad esempio HRweb).

• Siti del team di collaborazione.

• Siti personali.

Queste applicazioni costituiscono nell'insieme i siti di contenuto e collaborazione che i dipendenti utilizzeranno quotidianamente. Ogni applicazione rappresenta singolarmente un tipo diverso di contenuto. Ogni tipo di contenuto:

• Pone in risalto caratteristiche diverse di Microsoft Office SharePoint Server 2007.

• Ospita dati con caratteristiche diverse.

• È soggetto a un profilo utente diverso.

• Richiede una diversa strategia di gestione delle autorizzazioni.

Le scelte di progettazione per tali applicazioni hanno pertanto lo scopo di ottimizzare le prestazioni e la protezione di ogni applicazione.

L'utilizzo di un unico provider di servizi condivisi consente di raggruppare queste tre applicazioni per offrire le funzionalità seguenti:

• Spostamento tra le applicazioni.

• Ricerca a livello aziendale.

• Dati dei profili condivisi.

Nella figura seguente vengono illustrate le tre applicazioni che costituiscono la rete Intranet aziendale.

Web partner

L'applicazione Web per i partner ospita siti disponibili esternamente per la collaborazione protetta con i dipendenti delle società partner. Questa applicazione consente ai dipendenti di creare con facilità siti per la collaborazione protetta. I fattori chiave che indirizzano le scelte di progettazione per questa applicazione includono:

• **Isolamento del contenuto   **Ai partner non è consentito accedere ad altri tipi di contenuto ospitati nella server farm. Con un provider di servizi condivisi dedicato è inoltre possibile isolare ulteriormente il contenuto nei modi seguenti:

  • Mediante la definizione di ambiti di ricerca solo a livello del sito.

  • Mediante il divieto di spostamento tra le raccolte siti.

  • Mediante la non disponibilità dei dati dei profili tra le raccolte siti.

• **Autenticazione separata degli account partner   **Gli account partner vengono gestiti tramite l'autenticazione Forms e non vengono aggiunti alla directory aziendale.

• **Gestione delle autorizzazioni   **I proprietari dei singoli siti gestiscono le autorizzazioni per i relativi siti, invitando a collaborare solo i partecipanti necessari.

Nel modello l'applicazione Web per i partner viene ospitata dalla stessa farm che ospita il contenuto della rete Intranet.

Sito Internet aziendale

Il sito Internet aziendale costituisce la presenza in Internet della società. Il contenuto viene reso disponibile per i clienti mediante la configurazione dell'accesso anonimo con autorizzazioni di sola lettura. I fattori chiave che indirizzano le scelte di progettazione per questa applicazione includono:

• Isolamento del contenutoAi clienti non è consentito accedere ad altri tipi di contenuto ospitati nella server farm.

• Gestione assegnata   L'accesso autenticato viene fornito ai dipendenti che gestiscono il sito Web e che svolgono, ad esempio, attività di amministrazione e di creazione e modifica.

• Creazione e modifica e pubblicazione di contenuto protetto   Raccolte siti distinte vengono ospitate nella farm A nell'applicazione Web per i partner per la creazione e modifica e la gestione temporanea, consentendo in tal modo la collaborazione protetta e lo sviluppo di contenuto sia ai dipendenti interni sia a quelli remoti, nonché ai partner editoriali specializzati nello sviluppo di siti Web o nella creazione e modifica di contenuto. La pubblicazione del contenuto viene configurata in modo che il contenuto della raccolta siti di creazione e modifica venga pubblicato automaticamente nella raccolta siti di gestione temporanea (nella farm A) e il contenuto della raccolta siti di gestione temporanea nella farm A venga pubblicato automaticamente nella raccolta siti di produzione nella farm B. Nella figura seguente viene illustrato il processo di pubblicazione.

Obiettivi di progettazione globali

Nel modello viene illustrata un'implementazione pratica delle caratteristiche di Microsoft Office SharePoint Server 2007 in alcuni tipi comuni di applicazioni. In questo articolo vengono descritte le implementazioni di progettazione per ogni singola applicazione. Gli obiettivi di progettazione chiave per il modello includono:

• Utilizzo di un numero minimo di server farm per ospitare i tipi più comuni di siti Web richiesti in genere da un'organizzazione, ovvero siti Intranet, Extranet e Internet.

• Creazione di un framework per la progettazione di un ambiente ampliabile. Le decisioni di progettazione prese per le singole applicazioni non devono impedire l'aggiunta di altre applicazioni. Ad esempio, una distribuzione iniziale potrebbe includere solo i siti del team di collaborazione oppure solo le tre applicazioni che costituiscono una rete Intranet, ovvero i siti del team, i siti personali e il contenuto Intranet pubblicato. L'utilizzo di una simile progettazione dell'architettura logica consente di aggiungere applicazioni alla soluzione senza modificare la progettazione delle applicazioni iniziali. In altri termini, la progettazione non comprende scelte di progettazione che limitano le possibilità di utilizzo dell'ambiente.

• Disponibilità dell'accesso per diverse classi di utenti senza compromettere la protezione del contenuto all'interno delle varie applicazioni. Gli utenti di aree della rete diverse, sia interni sia esterni, con provider di autenticazione diversi possono partecipare alla collaborazione. Gli utenti possono inoltre accedere solo al contenuto al quale sono destinati. La scelta di una progettazione dell'architettura logica di questo tipo consente di creare l'opportunità di fornire accesso agli utenti in più posizioni e con obiettivi diversi. La progettazione iniziale potrebbe ad esempio essere prevista solo per l'accesso di dipendenti interni. L'utilizzo di questo tipo di progettazione offre tuttavia l'opportunità di consentire l'accesso anche a dipendenti remoti, dipendenti partner e clienti.

• Garanzia dell'utilizzabilità della progettazione in un ambiente Extranet. Le scelte di progettazione adottate vengono prese per assicurare che le server farm possano essere distribuite in modo protetto in una rete perimetrale.

Nella restante parte di questo articolo viene descritto ogni componente logico presente nel modello (dall'alto verso il basso) e vengono illustrate le scelte di progettazione applicate al modello. Lo scopo di questo approccio è illustrare i diversi modi in cui è possibile configurare i componenti dell'architettura logica in base all'applicazione.

Server farm

Il modello include l'utilizzo di due server farm. In questa sezione vengono descritti i requisiti relativi alle licenze che influiscono sul numero di server farm richiesto in un ambiente aziendale e vengono indicate le topologie delle server farm illustrate nel modello.

Requisiti relativi alle licenze

Per Microsoft Office SharePoint Server 2007 sono disponibili due licenze server. È possibile combinare queste licenze nello stesso computer server o nella stessa server farm:

• Microsoft Office SharePoint Server 2007, licenza server   Si tratta della licenza appropriata per contenuto Intranet. Questa licenza richiede l'utilizzo di Licenze di accesso client (CAL). Se si creano siti per la collaborazione con partner, sarà necessario assicurarsi di acquistare il numero di licenze CAL necessario per i dipendenti partner.

• **Microsoft Office SharePoint Server 2007 per siti Internet   **Questa licenza è destinata esclusivamente ai siti Web esposti a Internet e non richiede l'utilizzo di licenze CAL. Se si creano siti per la collaborazione con partner, non sarà necessario acquistare licenze CAL aggiuntive. Non è tuttavia possibile creare siti destinati esclusivamente all'utilizzo da parte dei dipendenti.

Se si intende distribuire contenuto interno per l'organizzazione e contenuto esposto a Internet per i non dipendenti dalla stessa farm, è necessario acquistare entrambi i tipi di licenza per la farm. Per includere tutti gli scenari di distribuzione possibili, i clienti che desiderano consolidare le proprie esigenze di utilizzo di Office SharePoint Server 2007 in un'unica distribuzione possono acquistare licenze per entrambi i prodotti, assegnare tali licenze allo stesso server e utilizzare la stessa istanza in esecuzione del software contemporaneamente con entrambe le licenze. In base ai diritti sull'utilizzo di Office SharePoint Server 2007, tuttavia, i clienti devono acquistare licenze CAL per gli utenti e i dispositivi che accedono a contenuto mediante modalità non consentite dai diritti sull'utilizzo di Office SharePoint Server 2007 per i siti Internet.

Per ulteriori informazioni su come i requisiti relativi alle licenze influiscono sul numero di server farm necessarie, vedere Pianificare le server farm.

Sebbene sia necessaria una sola server farm, nel modello viene illustrato l'utilizzo di due server farm, una per il contenuto interno e l'altra per il contenuto pubblico. Se si sceglie di implementare due farm distinte, la scelta di progettazione più importante consiste nel decidere quale farm ospiterà l'applicazione Web per i partner. Nel modello la server farm A ospita il contenuto Intranet e la server farm B ospita il sito Internet aziendale. In base ai termini del Contratto di licenza, entrambe le farm possono ospitare l'applicazione Web per i partner.

Data la necessità di scegliere tra le due farm, le indicazioni di progettazione generali per la determinazione della farm che ospiterà un'applicazione Web per i partner prevedono la valutazione degli elementi seguenti:

• Natura della collaborazione   Se lo scopo principale di un sito Extranet per i partner è la comunicazione protetta delle informazioni a molti partner, una server farm Internet è la scelta più economica. Al contrario, se lo scopo principale è collaborare con un numero limitato di dipendenti partner, una server farm Intranet potrebbe rappresentare una scelta più adeguata. Scegliere l'opzione che consente di ottimizzare la farm in base al ruolo a cui è destinata, ovvero collaborazione rispetto a contenuto di sola lettura.

• Numero di dipendenti partner   Se si collabora con molti dipendenti partner ed è importante ridurre al minimo i costi, sarà possibile ospitare in modo protetto sia il contenuto per la collaborazione sia il contenuto anonimo in una farm esposta a Internet con la licenza per siti Internet.

Nel modello l'applicazione Web per i partner è destinata alla collaborazione con le società partner, inclusi lo sviluppo e la gestione temporanea del sito Internet aziendale. L'inserimento dell'applicazione Web per i partner nella farm A consente all'organizzazione di ottimizzare entrambe le farm a seconda dell'utilizzo a cui sono destinate, ovvero collaborazione rispetto a contenuto di sola lettura.

Per ulteriori informazioni sulla scelta del numero appropriato di farm per l'organizzazione, incluse ulteriori informazioni sui requisiti relativi alle licenze, vedere Pianificare le server farm.

Topologia delle server farm

Ogni server farm inclusa nel modello è composta da cinque server con la topologia seguente:

• Due server Web front-end.

• Un server applicazioni.

• Due server database in cluster o in mirroring.

Nel modello viene illustrata l'architettura logica di Microsoft Office SharePoint Server 2007 indicando che:

• Tutti i siti sono in mirroring nei siti Web front-end.

• Il sito Amministrazione centrale è installato in un server applicazioni per impedire l'accesso diretto degli utenti.

Il numero di computer server e la topologia della server farm non sono in realtà importanti per l'architettura logica, se non per migliorare la capacità e le prestazioni, se necessario. L'architettura logica può essere progettata in modo indipendente dalla topologia della server farm. Il processo di pianificazione della capacità e delle prestazioni consentirà di creare server farm con le dimensioni necessarie per soddisfare gli obiettivi stabiliti in termini di prestazioni e capacità. Per ulteriori informazioni, vedere Pianificare le prestazioni e la capacità (Office SharePoint Server).

Utenti, aree e autenticazione

Nel modello vengono illustrate cinque classi di utenti diverse, ognuna delle quali è assegnata a un'area diversa. All'interno di ogni applicazione Web è possibile creare fino a cinque aree utilizzando uno dei nomi di area disponibili, ovvero Predefinita, Intranet, Internet, Personalizzata o Extranet. Una farm che ospita più applicazioni Web può supportare le richieste degli utenti da più di cinque aree di rete (fino a cinque aree per ogni applicazione Web). Nel modello vengono tuttavia illustrate solo cinque aree.

Utenti e autenticazione

Nel modello vengono illustrati utenti di aree della rete diverse o, nel caso di amministratori, utenti che hanno requisiti di autorizzazione molto diversi. Nel modello viene illustrata la modalità di applicazione dell'autenticazione agli utenti. Nelle tabelle seguenti viene descritta la modalità di autenticazione degli utenti per ogni area.

Area	Utenti	Autenticazione
Personalizzata	Amministratori	Kerberos (autenticazione integrata di Windows)
Intranet	Dipendenti interni	NTLM (autenticazione integrata di Windows)
Predefinita	Dipendenti remoti	NTLM (autenticazione integrata di Windows) o autenticazione Forms con LDAP (Lightweight Directory Access Protocol).
Extranet	Dipendenti partner	Autenticazione Forms
Internet	Clienti	Anonima

Non tutti gli utenti nel modello dispongono dell'accesso a entrambe le server farm. Di conseguenza, nessuna delle due farm utilizza tutte e cinque le aree.

Amministratori

L'area personalizzata viene utilizzata per l'accesso amministrativo protetto ai siti. Questo approccio offre l'opportunità di:

• Implementare un insieme indipendente di URL e criteri. Gli amministratori possono ad esempio utilizzare gli URL associati all'area personalizzata per eseguire attività di amministrazione in base ai criteri dell'area. Gli amministratori possono utilizzare gli URL Intranet per tutte le altre attività in base ai criteri configurati per le applicazioni che costituiscono la rete Intranet. Questo approccio consente di separare i due contesti e di garantire che non si verifichino conflitti tra le autorizzazioni concesse tramite i criteri.

• Implementare un metodo di autenticazione più sicuro per gli amministratori per una maggiore protezione della soluzione complessiva.

• Eseguire l'autenticazione in un provider diverso negli scenari in cui il supporto per i siti viene reso disponibile da un fornitore esterno.

In questo modello si presuppone che gli amministratori siano dipendenti di Fabrikam e che dispongano dell'accesso interno alla rete. Nel modello è incluso l'utilizzo dell'autenticazione integrata di Windows per gli amministratori, ovvero l'autenticazione Kerberos o NTLM.

Dipendenti interni

L'area Intranet viene utilizzata per l'accesso dei dipendenti interni. Viene utilizzata l'autenticazione integrata di Windows.

Dipendenti remoti

L'area predefinita viene utilizzata per l'accesso dei dipendenti remoti. Gli obiettivi di progettazione del modello sono i seguenti:

• Eseguire l'autenticazione nell'ambiente del servizio directory Active Directory interno.

• Semplificare la gestione delle autorizzazioni utilizzando l'autenticazione di Windows sia per i dipendenti interni sia per i dipendenti remoti. Questo obiettivo è importante, in quanto se gli utenti si collegano ai siti tramite due provider di autenticazione diversi, in Microsoft Office SharePoint Server 2007 verranno creati due account diversi per ogni utente e ogni account dovrà disporre di autorizzazioni.

Nel modello vengono presentate due opzioni diverse per l'autenticazione dei dipendenti remoti. La prima opzione, ovvero l'autenticazione integrata di Windows con NTLM, consente di raggiungere entrambi gli obiettivi. La seconda opzione, ovvero l'autenticazione Forms, soddisfa il primo obiettivo, ma non il secondo. La prima opzione rappresenta quindi il metodo preferito.

Nella tabella seguente vengono riepilogate le differenze tra questi due approcci.

Metodo di autenticazione	Autenticazione integrata di Windows con NTLM	Autenticazione Forms con un provider LDAP
Modalità di funzionamento	Questo metodo si basa sull'utilizzo di Internet Security and Acceleration (ISA) Server 2006 o Intelligente Application Gateway (IAG 2007) per l'autenticazione degli utenti e il successivo invio delle credenziali utente a Microsoft Office SharePoint Server 2007. Questi server utilizzano l'autenticazione Forms per autenticare gli utenti nell'ambiente Active Directory. Inoltrano quindi le credenziali di Windows a Microsoft Office SharePoint Server 2007. Per ulteriori informazioni sull'autenticazione in ISA Server 2006 e sulla configurazione avanzata di IAG, vedere le risorse seguenti: Authentication in ISA Server 2006 (informazioni in lingua inglese) (https://technet.microsoft.com/it-it/library/bb794722(it-it).aspx). Pianificazione dell'autenticazione e autorizzazione in IAG (informazioni in lingua inglese) (https://technet.microsoft.com/it-it/library/dd278059(it-it).aspx). Poiché l'area corrisponde all'area predefinita, l'autenticazione NTLM viene utilizzata per soddisfare un requisito del componente di indicizzazione. Per ulteriori informazioni, vedere "Configurazione dei requisiti dell'area predefinita" più avanti in questo articolo.	Microsoft Office SharePoint Server 2007 utilizza l'autenticazione Forms con un provider LDAP per autenticare i dipendenti remoti nell'ambiente Active Directory interno. Se si sceglie questo metodo, assicurarsi che il componente di indicizzazione sia in grado di eseguire l'autenticazione tramite un'area alternativa. Per ulteriori informazioni, vedere "Configurazione dei requisiti dell'area predefinita" più avanti in questo articolo.
Vantaggi	In Microsoft Office SharePoint Server 2007 non vengono creati due account diversi per gli utenti che lavorano sia internamente sia da postazioni remote, consentendo una notevole semplificazione della gestione delle autorizzazioni.	Non è richiesto un server proxy per l'autenticazione degli utenti e l'inoltre delle credenziali.
Svantaggi	È richiesto il coordinamento e la configurazione aggiuntivi di ISA Server 2006 o di un altro prodotto server proxy.	Se gli utenti si connettono a Microsoft Office SharePoint Server 2007 sia internamente sia da postazioni remote, in Microsoft Office SharePoint Server 2007 verranno creati due account utente diversi. Entrambi gli account dovranno pertanto disporre delle autorizzazioni necessarie per siti e documenti. I dipendenti possono potenzialmente creare due siti personali. È necessario che i dipendenti gestiscano le autorizzazioni di entrambi gli account per i propri siti personali e documenti nel caso prevedano di lavorare sia internamente sia da postazioni remote.

Dipendenti partner

I dipendenti partner accedono alla rete tramite la zona Extranet e vengono autenticati mediante l'autenticazione Forms. Questo metodo richiede l'utilizzo di una directory e di un provider distinti, ad esempio un database e un provider Microsoft SQL Server, per l'archiviazione degli account partner nella rete Extranet. I vantaggi di questo approccio sono rappresentati dalla possibilità di gestire gli account partner in modo separato e dal fatto che non è necessario aggiungere gli account partner alla directory dei dipendenti interni.

In alternativa, è possibile utilizzare Single Sign-On (SSO) Web per eseguire l'autenticazione in una directory personale del partner. Questo approccio richiede tuttavia un'area separata per ogni directory partner.

Poiché nel modello si presuppone che Fabrikam stia collaborando con i partner di diverse società all'interno della stessa applicazione partner, viene utilizzata l'autenticazione Forms. La directory e il provider non vengono specificati.

Clienti

L'area Internet viene utilizzata per l'accesso dei clienti. Quest'area è configurata per consentire l'accesso anonimo con autorizzazioni di sola lettura.

Aree

Per la progettazione delle aree alcune decisioni chiave relative alla progettazione e alla configurazione delle aree seguenti determinano la buona riuscita della distribuzione:

• L'area predefinita.

• Aree per l'accesso esterno.

Nelle sezioni seguenti vengono descritte le decisioni incluse nel modello.

Requisiti di configurazione dell'area predefinita

L'area che deve essere considerata con maggiore attenzione è l'area predefinita. Microsoft Office SharePoint Server 2007 pone i requisiti seguenti rispetto alla modalità di configurazione dell'area predefinita:

• Quando la richiesta di un utente non può essere associata a un'area, vengono applicati l'autenticazione e i criteri dell'area predefinita. Di conseguenza, l'area predefinita deve essere l'area più sicura.

• Il componente di indicizzazione richiede l'accesso al contenuto almeno tramite un'area per eseguire la ricerca per indicizzazione del contenuto. Per impostazione predefinita, il componente di indicizzazione utilizza l'autenticazione NTLM. L'amministratore del provider di servizi condivisi può configurare le regole di ricerca per indicizzazione per utilizzare l'autenticazione di base o un certificato client durante la ricerca per indicizzazione di un determinato intervallo di URL. Di conseguenza, per eseguire la ricerca per indicizzazione del contenuto, è necessario che almeno una delle aree sia configurata per l'utilizzo dell'autenticazione NTLM, dell'autenticazione di base o dei certificati. Il crawler esegue inoltre il polling delle aree nell'ordine riportato di seguito fino a quando non viene individuata un'area tramite la quale eseguire l'autenticazione, ovvero l'area predefinita, l'area Intranet, l'area Internet, l'area personalizzata o l'area Extranet. Tuttavia, se il crawler individua prima un'area configurata per l'utilizzo dell'autenticazione Kerberos, il crawler non eseguirà l'autenticazione e non tenterà di accedere all'area successiva. Assicurarsi pertanto che la configurazione delle aree che utilizzano l'autenticazione Kerberos non impedisca al componente di indicizzazione di eseguire la ricerca per indicizzazione del contenuto. Per ulteriori informazioni sui requisiti di autenticazione correlati al contenuto per la ricerca per indicizzazione, vedere Pianificare i metodi di autenticazione (Office SharePoint Server).

• Vengono inviati messaggi di posta elettronica amministrativi con collegamenti relativi all'area predefinita. Sono inclusi messaggi di posta elettronica ai proprietari di siti che stanno raggiungendo i limiti di quota. Di conseguenza, gli utenti che ricevono questi tipi di messaggi di posta elettronica e avvisi devono essere in grado di accedere ai collegamenti tramite l'area predefinita. Questo è particolarmente importante per i proprietari di siti.

• Le raccolte siti con nome basato sull'host sono disponibili solo tramite l'area predefinita. Per accedere alle raccolte siti con nome basato sull'host, gli utenti devono utilizzare l'area predefinita.

Nel modello l'area predefinita viene utilizzata per l'accesso dei dipendenti remoti per i motivi seguenti:

• I dipendenti possono accedere ai collegamenti nei messaggi di posta elettronica amministrativi indipendentemente dalla posizione in cui si trovano.

• I nomi dei server e gli URL interni non vengono esposti quando la zona associata a una richiesta dell'utente non può essere determinata. Poiché l'area predefinita è gia configurata per i dipendenti remoti, gli URL non consentono l'esposizione di dati riservati quando è applicata quest'area.

Configurazione di aree per un ambiente Extranet

In un ambiente Extranet la progettazione delle aree è importante per i due motivi seguenti:

• Le richieste degli utenti possono essere avviate da reti diverse. Nel modello gli utenti avviano richieste dalla rete interna, da Internet e dalle società partner.

• Gli utenti utilizzano contenuto in più applicazioni Web. Nel modello la rete Intranet è composta da tre applicazioni Web diverse. Inoltre, i dipendenti interni e remoti possono potenzialmente amministrare e contribuire al contenuto in tutte le applicazione Web: Intranet, Web partner e il sito Internet aziendale.

In un ambiente Extranet verificare che vengano seguiti i principi di progettazione seguenti:

• Configurare le aree in più applicazioni Web in modo che venga eseguito il mirroring reciproco. La configurazione dell'autenticazione e gli utenti previsti devono corrispondere. I criteri associati alle aree possono tuttavia differire tra le applicazioni Web. Assicurarsi ad esempio che l'area Intranet venga utilizzata per gli stessi dipendenti in tutte le applicazioni Web. In altri termini, non configurare l'area Intranet per i dipendenti interni in un'applicazione Web e per i dipendenti remoti in un'altra.

• Configurare i mapping di accesso alternativo in modo corretto e accurato per ogni area e risorsa.

Nel modello l'area predefinita per ogni applicazione Web è configurata in modo identico per l'accesso dei dipendenti remoti. L'area Intranet è inoltre configurata in modo identico in tutte le applicazioni Web per l'accesso dei dipendenti interni. L'area Extranet e l'area Internet sono configurate solo per un'unica applicazione Web.

I mapping di accesso alternativo vengono creati automaticamente quando si crea l'area. È tuttavia possibile configurare Microsoft Office SharePoint Server 2007 per la ricerca per indicizzazione del contenuto di risorse esterne, ad esempio una condivisione di file. I collegamenti a queste risorse esterne devono essere creati manualmente per ogni area tramite i mapping di accesso alternativo. Una condivisione di file può ad esempio essere esposta agli utenti interni con un URL interno (file://). La stessa condivisione di file può essere esposta come collegamento FTP agli utenti esterni (ftp://). In questo modo si assicura la disponibilità di queste risorse per gli utenti in base al contesto della rispettiva area. Quando gli utenti ricevono i collegamenti a queste risorse nei risultati di ricerca, i collegamenti risultano accessibili.

Se le aree tra le applicazioni Web non sono in mirroring reciproco e i collegamenti alle risorse esterne non sono appropriati, potrebbero presentarsi i rischi seguenti:

• Nomi di server, nomi DNS (Domain Name System) e indirizzi IP potrebbero essere esposti all'esterno della rete interna.

• Gli utenti potrebbero non essere in grado di accedere a siti Web e altre risorse.

Provider di servizi condivisi

Un provider di servizi condivisi fornisce un insieme comune di servizi e dati dei servizi a un raggruppamento logico di applicazioni Web e relativi siti associati. I servizi e i dati dei servizi includono:

• Servizi di personalizzazione

• Gruppi di destinatari

• Catalogo dati business

• Servizi di Excel

• Servizio di ricerca di Office SharePoint Server

• Creazione di report sull'utilizzo del portale

Il criterio più importante per determinare se sono necessari uno o più provider di servizi condivisi nell'architettura logica è la necessità o meno di isolare contenuto. Ad esempio, se la server farm ospita applicazioni per più classi di utenti, l'utilizzo di provider di servizi condivisi distinti può contribuire a creare l'isolamento tra queste due classi di utenti.

Nel modello viene incluso un provider di servizi condivisi distinto per ogni applicazione seguente:

• Intranet

• Web partner

• Sito Web Internet del cliente

  

Intranet

Le tre singole applicazioni che costituiscono l'applicazione Intranet, ovvero contenuto Intranet pubblicato, siti personali e siti del team, vengono raggruppate da un provider di servizi condivisi. L'applicazione Intranet illustrata nel modello fornisce un esempio di equilibrio tra isolamento protetto e la necessità aziendale di condividere informazioni e utilizzare dati dei profili tra le applicazioni.

• Le singole applicazioni vengono isolate per applicazioni Web e pool di applicazioni. I pool di applicazioni distinti forniscono il processo di isolamento, mentre le applicazioni Web dedicate offrono l'opportunità di implementare criteri di autorizzazione diversi per ogni tipo di contenuto.

• L'unificazione delle tre applicazioni illustrate di seguito un unico provider di servizi condivisi consente la personalizzazione e la ricerca a livello aziendale in tutte le applicazioni.

  

Web partner

L'utilizzo di un provider di servizi condivisi separato per l'applicazione Web per i partner assicura che gli utenti partner non possono accedere a informazioni riservate o eseguire ricerche in tali informazioni all'interno dell'ambiente Intranet. Il provider di servizi condivisi può essere configurato in modo da isolare ulteriormente il contenuto tra le raccolte siti nei modi seguenti:

• Limitare gli ambiti di ricerca alle singole raccolte siti.

• Utilizzare gruppi di destinatari per assegnare contenuto a determinati gruppi di utenti.

• Utilizzare lo strumento da riga di comando Stsadm per configurare il controllo Selezione utenti in modo da visualizzare solo gli utenti che sono membri della raccolta siti. In questa configurazione è possibile aggiungere un utente dalla directory se il nome dell'utente è noto. In Selezione utenti vengono tuttavia visualizzati solo gli utenti già aggiunti alla raccolta siti. In questo modo gli utenti partner non sono in grado di esplorare la directory degli utenti tramite il controllo Selezione utenti.

  Per attivare questa configurazione, utilizzare il comando seguente:

  Stsadm.exe -o setproperty –url https://server –pn “peoplepicker-onlysearchwithinsitecollection” –pv yes

  Per disattivare questa configurazione, utilizzare il comando seguente:

  Stsadm.exe -o setproperty –url https://server –pn “peoplepicker-onlysearchwithinsitecollection” –pv no

Oltre a configurare i servizi all'interno del provider di servizi condivisi per ottenere l'isolamento, prendere in considerazione la possibilità di configurare le autorizzazioni nei modi seguenti:

• Limitare l'accesso ai siti a utenti o gruppi specifici.

• Utilizzare i gruppi di SharePoint per autorizzare l'accesso al contenuto.

Sito Internet aziendale

Nel modello il sito Internet aziendale è disponibile per gli utenti anonimi. I siti destinati agli utenti anonimi devono essere sempre isolati dai siti destinati agli utenti autenticati. Nel modello vengono utilizzati i metodi di isolamento seguenti per il sito Internet aziendale:

• Pool di applicazioni distinti che garantiscono il processo di isolamento.

• Applicazioni Web distinte che offrono la possibilità di assegnare criteri.

• Provider di servizi condivisi dedicato che assicura che i risultati della ricerca sono limitati all'applicazione anonima.

Siti di amministrazione

Nel modello ogni sito di amministrazione è ospitato all'interno di un pool di applicazioni e di applicazioni Web dedicati. Nell'elenco seguente viene descritto ogni sito Web di amministrazione:

• Siti Web di amministrazione di servizi condivisi   Nel modello è illustrato un sito di amministrazione dedicato per ogni provider di servizi condivisi. I siti di amministrazione di servizi condivisi non possono essere isolati in un singolo server o insieme di server. Di questi siti viene eseguito automaticamente il mirroring in tutti i server Web front-end.

• Siti Web Amministrazione centrale   Nel modello il sito Amministrazione centrale per ogni server farm è ospitato in un server applicazioni. Il sito viene in tal modo protetto dal contatto diretto con gli utenti. Se un collo di bottiglia delle prestazioni o una violazione della protezione influisce sulla disponibilità dei server Web front-end, il sito Amministrazione centrale rimarrà disponibile.

Gli URL con carico bilanciato per siti di amministrazione non vengono indicati in questo modello o in questo articolo. I suggerimenti includono i seguenti:

• Se negli URL amministrativi vengono utilizzati numeri di porta, utilizzare porte non standard. I numeri di porta vengono inclusi negli URL per impostazione predefinita. Mentre i numeri di porta non vengono in genere utilizzati negli URL pubblici, l'utilizzo di numeri di porta per siti amministrativi può migliorare la protezione limitando l'accesso a tali siti su porte non standard.

• Consentire l'accesso a siti di amministrazione solo da un dominio amministrativo.

• Creare voci DNS distinte per siti di amministrazione.

Oltre a questi suggerimenti, è possibile bilanciare il carico del sito Amministrazione centrale tra più server applicazioni per ottenere la ridondanza.

Pool di applicazioni

Vengono in genere implementati pool di applicazioni Internet Information Services (IIS) separati per ottenere l'isolamento dei processi dal contenuto. I pool di applicazioni offrono un metodo per eseguire più siti nello stesso computer server, disponendo tuttavia dei relativi processi di lavoro e identità. In questo modo viene attenuato un exploit in un sito che offre un'opportunità a chi effettua un attacco di inserire codice nel server per attaccare altri server.

In termini pratici, prendere in considerazione l'utilizzo di un pool di applicazioni dedicato per ogni scenario seguente:

• Per separare il contenuto autenticato dal contenuto anonimo.

• Per isolare applicazioni che memorizzano password e interagire con applicazioni aziendali esterne, ad esempio connessioni al Catalogo dati business.

• Per isolare applicazioni in cui gli utenti hanno ampia libertà di creazione e amministrazione di siti e di collaborazione sul contenuto.

Nel modello vengono utilizzati pool di applicazioni nel modo seguente:

• Ogni sito di amministrazione è ospitato in un pool di applicazioni dedicato. Questo è un requisito di Microsoft Office SharePoint Server 2007.

• Il contenuto Intranet è suddiviso in due pool di applicazioni diversi. Il contenuto per la collaborazione (siti personali e siti del team) è ospitato in un pool di applicazioni. Il contenuto Intranet pubblicato è ospitato in un pool di applicazioni distinto. Questa configurazione consente l'isolamento dei processi per il contenuto Intranet pubblicato in cui è più probabile che vengano utilizzate le connessioni a dati business. Ad esempio, molti siti di risorse umane (HR, Human Resources) utilizzano connessioni a dati business per consentire ai dipendenti di accedere ai propri dati personali.

• L'applicazione Web per i partner è ospitata in un pool di applicazioni dedicato.

• Il sito Internet aziendale è ospitato in un pool di applicazioni dedicato nella farm B. Se questa farm dovesse inoltre ospitare il contenuto per la collaborazione con i partner, questi due tipi di contenuto (Internet e partner) verrebbero ospitati in due pool di applicazioni diversi.

Applicazioni Web

Un'applicazione Web è un sito Web IIS creato e utilizzato da Prodotti e tecnologie SharePoint. Ogni applicazione Web è rappresentata da un sito Web diverso in IIS e a ogni applicazione Web viene assegnato un nome di dominio univoco che contribuisce a impedire attacchi di cross-site scripting (XSS).

È in generale consigliabile utilizzare applicazioni Web dedicate per:

• Separare il contenuto anonimo dal contenuto autenticato. Nel modello il sito Internet aziendale è ospitato in un'applicazione Web e in un pool di applicazioni dedicati.

• Isolare utenti. Nel modello l'applicazione Web per i partner è ospitata in un'applicazione Web e in un pool di applicazioni dedicati per garantire che i partner non abbiano accesso al contenuto Intranet.

• Applicare autorizzazioni. Un'applicazione Web dedicata offre l'opportunità di applicare autorizzazioni mediante criteri utilizzando la pagina Criteri per l'applicazione Web in Amministrazione centrale. È ad esempio possibile creare criteri per un sito Internet aziendale per negare in modo esplicito l'accesso in scrittura a uno o più gruppi di utenti. I criteri per un'applicazione Web vengono applicati indipendentemente dalle autorizzazioni configurate nei singoli siti o documenti all'interno dell'applicazione Web.

• Ottimizzare le prestazioni. Le applicazioni offrono prestazioni migliori se vengono inserite in applicazioni Web con altre applicazioni con caratteristiche dei dati simili. Ad esempio, le caratteristiche dei dati di siti personali includono un numero elevato di siti di dimensioni contenute. Al contrario, i siti del team comprendono in genere un numero limitato di siti di dimensioni molto grandi. Se questi due tipi di siti vengono inseriti in applicazioni Web distinte, i database risultanti saranno composti da dati con caratteristiche simili, con conseguente ottimizzazione delle prestazioni dei database. Nel modello i siti personali e i siti del team non dispongono di requisiti di isolamento dei dati univoci, in quanto condividono lo stesso pool di applicazioni. I siti personali e i siti del team sono stati tuttavia inseriti in applicazioni Web distinte per ottimizzare le prestazioni.

• Ottimizzare la gestibilità. Poiché la creazione di applicazioni Web separate determina la creazione di siti e database distinti, è possibile implementare limiti per i siti diversi (Cestino, scadenza e dimensioni) e negoziare contratti di servizio diversi. È ad esempio possibile che si consenta più tempo per il ripristino del contenuto dei siti personali se questo non è il tipo di contenuto più importante all'interno dell'organizzazione. In questo modo sarà possibile ripristinare il contenuto più importante prima del contenuto dei siti personali. Nel modello i siti personali sono inseriti in un'applicazione Web distinta per consentire agli amministratori per gestirne la crescita in modo più efficace rispetto ad altre applicazioni.

Raccolte siti

Le raccolte siti rappresentano il collegamento tra l'architettura logica e l'architettura delle informazioni. Gli obiettivi di progettazione per le raccolte siti nel modello consentono di soddisfare i requisiti per la progettazione di URL e creare divisioni logiche del contenuto.

Per soddisfare i requisiti per la progettazione di URL, ogni applicazione Web include una raccolta siti al livello principale. I percorsi gestiti vengono utilizzati per incorporare un secondo livello di raccolte siti principali. Per ulteriori informazioni sui requisiti degli URL e l'utilizzo di percorsi gestiti, vedere "Aree e URL" più avanti in questo articolo. Oltre il secondo livello di raccolte siti, ogni sito è un sito secondario.

Nella figura seguente viene illustrata la gerarchia dei siti del team.

Dato il requisito per una raccolta siti principale, le decisioni di progettazione vertono intorno al secondo livello di raccolte siti. Nel modello sono incluse scelte prese in base alla natura dell'applicazione.

Contenuto Intranet pubblicato

Il presupposto per l'applicazione di contenuto Intranet pubblicato consiste nel fatto che più divisioni all'interno dell'azienda ospiteranno il contenuto pubblicato. Nel modello il contenuto di ogni divisione viene ospitato in una raccolta siti separata offrendo i vantaggi seguenti:

• Ogni divisione può gestire e autorizzare il proprio contenuto in modo indipendente.

• Il contenuto di ogni divisione può essere archiviato in un database dedicato.

Gli svantaggi derivanti dall'utilizzo di più raccolte siti includono:

• Pagine master, layout di pagina, modelli, web part e struttura di spostamento non possono essere condivisi tra le raccolte siti.

• Risulta più difficile coordinare le personalizzazioni e lo spostamento tra le raccolte siti.

In base all'architettura delle informazioni e alla progettazione dell'applicazione Intranet, il contenuto pubblicato può essere visualizzato all'utente come un'applicazione seamless. In alternativa, ogni raccolta siti può essere visualizzata come un sito Web distinto.

Siti personali

I siti personali presentano caratteristiche peculiari e i suggerimenti per la distribuzione di siti personali sono piuttosto semplici. Nel modello l'applicazione per i siti personali include un sito principale con l'URL http://personali. La prima raccolta siti principale creata utilizza il modello Host siti personali. Mediante l'inclusione di caratteri jolly, viene incorporato un percorso gestito che consente un numero indefinito di siti creati dall'utente. Tutti i siti al di sotto del percorso gestito sono raccolte siti indipendenti che ereditano il modello Host siti personali. Il nome utente viene aggiunto all'URL nella forma http://personale/nomeutente. Nella figura seguente viene illustrata l'applicazione per i siti personali.

Per ulteriori informazioni sulla progettazione di un'applicazione per i siti personali, vedere Progettare l'architettura dei siti personali.

Siti del team

Per la progettazione di raccolte siti all'interno di un'applicazione per i siti del team, è possibile utilizzare uno dei due approcci seguenti:

• Consentire ai team di creare raccolte siti mediante la creazione di siti in modalità self-service. Questo approccio offre ai team il vantaggio di creare un sito con estrema facilità, se necessario, senza l'assistenza di un amministratore, ma presenta anche numerosi svantaggi, inclusi i seguenti:

  • Si perde la possibilità di implementare una tassonomia ad-hoc.

  • L'applicazione può diventare difficile da gestire.

  • I siti vengono abbandonati facilmente.

  • Non è possibile condividere modelli e spostamento tra progetti o team che invece potrebbero condividere una raccolta siti.

• Creare un numero limitato di raccolte siti per l'organizzazione in base al modo in cui opera l'organizzazione. In questo approccio le raccolte siti vengono create da un amministratore di SharePoint. Dopo la creazione della raccolta siti, i team possono creare siti all'interno della raccolta siti in base alle necessità. Questo approccio offre l'opportunità di implementare una tassonomia ad-hoc che fornisce una struttura per la modalità di gestione e sviluppo dei siti del team. Offre inoltre maggiori opportunità di condividere i modelli e la struttura di spostamento tra i progetti e i team che condividono una raccolta siti.

Nel modello viene utilizzato il secondo approccio, che determina la creazione di una gerarchia di raccolte siti simili per i siti del team e per il contenuto Intranet pubblicato. La sfida per gli architetti informatici consiste nel creare un secondo livello di raccolte siti efficaci per l'organizzazione. Nella tabella seguente vengono elencati alcuni suggerimenti per diversi tipi di organizzazioni.

Tipo di organizzazione	Tassonomie di raccolte siti consigliate
Sviluppo prodotto	Creare una raccolta siti per ogni prodotto in fase di sviluppo. Consentire ai team di collaborazione di creare siti all'interno della raccolta siti. Per ogni progetto di sviluppo a lungo termine, creare una raccolta siti per ogni team di grandi dimensioni che contribuisce al prodotto. Creare ad esempio una raccolta siti per ogni team: progettisti, ingegneri e sviluppatori di contenuto.
Ricerca	Creare una raccolta siti per ogni progetto di ricerca a lungo termine. Creare una raccolta siti per ogni categoria di progetti di ricerca.
Istituto di istruzione superiore	Creare una raccolta siti per ogni dipartimento accademico.
Ufficio affari legislativi	Creare una raccolta siti per ogni partito politico. I funzionari che condividono un'affiliazione politica possono condividere modelli e struttura di spostamento. Creare una raccolta siti per ogni comitato. In alternativa, creare una raccolta siti per tutti i comitati.
Ufficio legale aziendale	Creare una raccolta siti per ogni cliente aziendale.
Produzione	Creare una raccolta siti per ogni linea di prodotti.

Web partner

L'applicazione Web per i partner è destinata alla collaborazione con partner esterni su progetti con ambiti limitati o durate limitate. In base alla progettazione, i siti all'interno dell'applicazione Web per i partner non sono destinati a essere correlati. I requisiti per l'applicazione Web per i partner prevedono la verifica degli aspetti seguenti:

• I proprietari dei progetti possono creare con facilità siti per la collaborazione con il partner.

• I partner e gli altri collaboratori hanno accesso solo al progetto su cui lavorano.

• Le autorizzazioni vengono gestite dai proprietari del sito.

• I risultati delle ricerche eseguite dall'interno di un progetto non determinano l'esposizione del contenuto di altri progetti.

• Gli amministratori possono identificare con facilità i siti che non vengono più utilizzati e quindi eliminarli.

Per soddisfare questi requisiti, nel modello è inclusa una raccolta siti per ogni progetto. In questo modo, si ottengono i vantaggi seguenti:

• Singole raccolte siti offrono il livello appropriato di isolamento tra i progetti.

• Può essere implementata la creazione di siti in modalità self-service.

Poiché l'applicazione Web per i partner ospita inoltre le raccolte siti per lo sviluppo di contenuto per il sito Internet aziendale, vengono create raccolte siti distinte per la creazione e la modifica e la gestione temporanea.

Sito Internet aziendale

Il sito Internet aziendale include un'unica raccolta siti principale. Tutti i siti sottostanti a questa raccolta siti sono siti secondari. Questa struttura consente di semplificare gli URL per le pagine all'interno del sito. Nella figura seguente viene illustrata l'architettura del sito Internet aziendale.

Database del contenuto

Per includere database del contenuto nella progettazione, è possibile utilizzare i due approcci seguenti (nel modello vengono utilizzati entrambi gli approcci):

• Stabilire le dimensioni di destinazione per i database del contenuto con valori di soglia degli avvisi per le dimensioni appropriati. Creare un nuovo database quando si raggiungono i valori di soglia degli avvisi per le dimensioni. Con questo approccio, le raccolte siti vengono aggiunte automaticamente al database o ai database disponibili esclusivamente in base agli obiettivi di dimensione.

• Associare raccolte siti a database del contenuto specifici. Questo approccio consente di inserire una o più raccolte siti in un database dedicato che può essere gestito in modo indipendente dagli altri.

Se si sceglie di associare le raccolte siti a database del contenuto specifici, sarà possibile utilizzare i metodi seguenti:

• Utilizzare lo strumento da riga di comando Stsadm per creare una raccolta siti in un database specifico.

• Dedicare un database a una singola raccolta siti mediante l'applicazione delle impostazioni seguenti relative alla capacità del database:

  • Numero di siti prima della generazione di un evento di avviso = 1

  • Numero massimo di siti che possono essere creati in questo database = 1

• Aggiungere un gruppo di raccolte siti a un database dedicato completando i passaggi seguenti:

  1. All'interno dell'applicazione Web creare il database e impostare lo stato del database su Pronto.

  2. Impostare lo stato di tutti gli altri database su Non in linea. Mentre i database del contenuto sono non in linea, non è possibile creare nuove raccolte siti. Le raccolte siti esistenti nei database non in linea sono tuttavia accessibili sia per le operazioni di lettura che di scrittura.

  3. Creare le raccolte siti. Verranno aggiunte automaticamente al database.

  4. Reimpostare lo stato di tutti gli altri database su Pronto.

Contenuto Intranet pubblicato

Per il contenuto Intranet pubblicato, nel modello viene incluso un database dedicato per le raccolte siti di ogni reparto.

Questo approccio consente a ogni reparto di gestire il relativo contenuto in modo indipendente.

Siti personali

Per i siti personali, il modello raggiunge l'efficienza della scalabilità mediante la gestione dei database fino alla dimensione di destinazione massima. Per raggiungere questo obiettivo, vengono configurate le impostazioni seguenti:

• Dimensioni massime spazio di archiviazione del sito   Questa impostazione, che è possibile configurare nella pagina Modelli quote in Amministrazione centrale, consente di limitare le dimensioni di un sito personale.

• Cestino secondario   Questa impostazione, che è possibile configurare nella pagina Impostazioni generali applicazione Web, consente di determinare la quantità di spazio aggiuntivo assegnata al cestino secondario.

• Numero massimo di siti che possono essere creati in questo database   Questa impostazione viene configurata al momento della creazione del database. Calcolare la dimensione totale consentita di siti utilizzando i numeri specificati per i due valori precedenti. Quindi, in base all'obiettivo di dimensione per ogni database, determinare il numero di siti che rientreranno nel database.

Nel modello sono incluse le impostazioni relative alle dimensioni di esempio seguenti in base a una dimensione di destinazione del database di 100 gigabyte (GB) e una dimensione di destinazione dei siti personali di 500 megabyte (MB):

• Limiti di dimensione del sito per ogni sito = 500 MB

• Dimensione di destinazione del database = 100 GB

• Numero massimo di siti = 200

• Avviso numero siti = 150

Quando si raggiunge il valore relativo all'avviso per il numero di siti, creare un nuovo database. Dopo aver creato il nuovo database, i nuovi siti personali verranno aggiunti alternativamente al nuovo database e al database esistente fino a quando non verrà raggiunto il numero massimo di siti per uno dei database.

Per ulteriori informazioni sulla progettazione delle impostazioni del database per i siti personali, vedere Progettare l'architettura dei siti personali.

Siti del team

Per i siti del team, nel modello è incluso un database dedicato per ogni raccolta siti del team. Questo approccio consente di gestire ogni database del team in modo indipendente per scopi di backup, ripristino e migrazione. Quando un progetto viene completato, risulta inoltre più facile archiviare il database associato al progetto.

Web partner

Analogamente ai siti personali, l'applicazione Web per i partner raggiunge l'efficienza della scalabilità mediante la gestione dei database fino alla dimensione di destinazione massima. Nel modello l'applicazione Web per i partner ospita tuttavia le raccolte siti di creazione e modifica e di gestione temporanea per il sito Internet aziendale. La progettazione del database prevede di conseguenza entrambi gli approcci:

• Ogni raccolta siti di creazione e modifica e di gestione temporanea è ospitata in un database dedicato.

• Le impostazioni del database e delle dimensioni sono configurate per gestire tutti gli altri siti e database.

Poiché l'applicazione Web per i partner è ospitata in un'applicazione Web dedicata, è possibile creare i limiti per le dimensioni più appropriati per i tipi di dimensioni creati. Nel modello vengono utilizzate le impostazioni di esempio seguenti relative alle dimensioni:

• Dimensione di destinazione del database = 100 GB

• Quota di spazio di archiviazione per ogni sito = 5 GB

• Numero massimo di siti = 20

• Raccolte siti di creazione e modifica e di gestione temporanea ospitate in database dedicati

Sito Internet aziendale

L'utilizzo di un'unica raccolta siti nella progettazione del sito Internet aziendale consente di utilizzare un unico database per l'applicazione Web.

Aree e URL

Nel modello viene illustrato come coordinare gli URL tra più applicazioni all'interno di una distribuzione aziendale.

Obiettivi di progettazione

Gli obiettivi seguenti influenzano le decisioni di progettazione per gli URL:

• Le convenzioni URL non consentono di limitare le aree tramite le quali è possibile accedere il contenuto.

• Le porte HTTP e HTTPS (80 e 443) standard possono essere utilizzate in tutte le applicazioni del modello.

• I numeri di porta non sono inclusi negli URL. In effetti, i numeri di porta non vengono in genere utilizzati negli ambienti di produzione.

Principi di progettazione

Per raggiungere gli obiettivi di progettazione illustrati, vengono applicati i principi di progettazione seguenti:

• Le raccolte siti con nome basato sull'host non vengono utilizzate. Si noti che le raccolte siti con nome basato sull'host sono diverse dalle intestazioni host di IIS. Le raccolte siti con nome basato sull'host non utilizzano la caratteristica di mapping di accesso alternativo. La caratteristica di mapping di accesso alternativo è necessaria per accedere allo stesso contenuto tramite più URL di dominio. Di conseguenza, quando vengono utilizzati siti con nome basato sull'host, tali siti sono disponibili solo tramite l'area predefinita. La caratteristica di mapping di accesso alternativo fornisce il supporto per la terminazione off-box di SSL (Secure Sockets Layer), che consente l'utilizzo di SSL (https) in scenari di accesso di dipendenti remoti e partner.

• Ogni applicazione include un'unica raccolta siti principale, requisito necessario per l'utilizzo di mapping di accesso alternativo. Se all'interno di un'applicazione Web sono necessarie più raccolte siti principali e si prevede di utilizzare solo l'area predefinita per l'accesso degli utenti, le raccolte siti con nome basato sull'host rappresentano una soluzione valida.

• Per le applicazioni che includono più raccolte siti di alto livello in cui ogni raccolta siti rappresenta un team o un progetto di alto livello (ad esempio siti del team), il modello include percorsi gestiti. I percorsi gestiti consentono di esercitare un maggiore controllo sugli URL per questi tipi di siti.

Compromessi di progettazione

Il conseguimento degli obiettivi di progettazione comporta alcuni compromessi, inclusi i seguenti:

• Gli URL sono troppo lunghi.

• Le raccolte siti con nome basato sull'host non vengono utilizzate.

Progettazione di URL con carico bilanciato

Quando si crea un'applicazione Web, è necessario scegliere un URL con carico bilanciato da assegnare all'applicazione. È inoltre necessario creare un URL con carico bilanciato per ogni area che si crea all'interno di un'applicazione Web. L'URL con carico bilanciato include il protocollo, lo schema, il nome host e la porta, se utilizzata. L'URL con carico bilanciato deve essere univoco in tutte le applicazioni Web e aree. Di conseguenza, ogni applicazione e ogni area all'interno di ogni applicazione richiede un URL univoco nel modello.

Intranet

Ognuna delle tre applicazioni che compongono la rete Intranet richiede un URL univoco. Nel modello i gruppi di destinatari per il contenuto Intranet sono i dipendenti interni e i dipendenti remoti. Nella tabella seguente vengono elencati gli URL per l'accesso dei dipendenti interni e remoti a ogni applicazione.

Applicazione	URL dipendente interno	URL dipendente remoto
Contenuto Intranet pubblicato	http://fabrikam	https://intranet.fabrikam.com
Siti del team	http://team	https://team.fabrikam.com
Siti personali	http://personali	https://personali.fabrikam.com

Web partner

All'applicazione Web per i partner illustrata nel modello accedono i dipendenti interni, i dipendenti remoti e i dipendenti del partner. Sebbene sia i dipendenti remoti sia i dipendenti esterni accedono all'applicazione Web per i partner esternamente utilizzando SSL (https), per usufruire dei vantaggi derivanti dall'utilizzo di aree separate, ovvero metodi di autenticazione diversi e criteri per le aree diversi, è necessario un URL diverso per ogni dipendente. Nella tabella seguente vengono elencati gli URL utilizzati dai dipendenti interni, dai dipendenti remoti e dai dipendenti partner per l'accesso all'applicazione Web per i partner.

Area	URL
URL dipendente interno	http://webpartner
URL dipendente remoto	https://webpartnerremoto.fabrikam.com
URL partner	https://webpartner.fabrikam.com

Sito Internet aziendale

Il sito Internet aziendale è un sito pubblico accessibile da qualsiasi utente mediante l'URL: https://www.microsoft.com/it/it/default.aspx predefinito al quale sono stati applicati i criteri per l'area Internet, ovvero accesso anonimo e protezione da scrittura.

Per supportare le attività di amministrazione e di creazione e modifica nel sito pubblico, nel modello vengono tuttavia inclusi gli URL per i dipendenti interni e remoti. I criteri per queste aree limitano le autorizzazioni superiori all'accesso in lettura per i gruppi di protezione di destinazione. Nella tabella seguente vengono elencati gli URL per ogni area.

Area	URL
URL dipendente interno	http://sitofabrikam
URL dipendente remoto	https://sitofabrikam.fabrikam.com
URL cliente	https://www.microsoft.com/it/it/default.aspx

Utilizzo di inclusioni esplicite o di caratteri jolly per i percorsi URL

Mediante la definizione di percorsi gestiti è possibile specificare le parti dello spazio dei nomi URL di un'applicazione Web da utilizzare per una raccolta siti. È possibile specificare che una raccolta siti o più raccolte siti esistono in corrispondenza di un percorso distinto sotto il sito principale. Senza percorsi gestiti, tutti i siti creati sotto la raccolta siti principale fanno parte della raccolta siti principale.

È possibile creare i due tipi di percorsi gestiti seguenti:

• Inclusione esplicita   Una raccolta siti a cui è stato assegnato l'URL esplicito. Un'inclusione esplicita viene applicata solo a una raccolta siti. È possibile creare molte inclusioni esplicite sotto una raccolta siti principale. Un URL di esempio per una raccolta siti creata con questo metodo è http://fabrikam/risorseumane.

• Inclusione di caratteri jolly   Un percorso aggiunto all'URL. Questo percorso indica che tutti i siti che vengono specificati direttamente dopo il nome del percorso sono raccolte siti univoche. Questa opzioni viene in genere utilizzata per le applicazioni che supportano la creazione di siti in modalità self-service, ad esempio siti personali. Un URL di esempio per una raccolta siti creata con questo metodo è http://personali/personale/utente1.

Nel modello vengono utilizzati entrambi i tipi come descritto nelle sezioni seguenti.

Inclusioni esplicite: siti del team e contenuto Intranet pubblicato

Nel modello l'applicazione dei siti del team e le applicazioni del contenuto Intranet pubblicato includono l'utilizzo di inclusioni esplicite.

Siti del team

All'interno dell'applicazione per i siti del team viene utilizzata un'inclusione esplicita per ogni raccolta siti del team. Il limite per le dimensioni delle raccolte siti create con un'inclusione esplicita è di circa 100 siti. Le procedure di governance ottimali prevedono di mantenere il numero di siti del team principali entro un valore gestibile. È inoltre necessario che la tassonomia per i siti del team sia coerente con la modalità operativa dell'azienda. Un limite di 100 siti risulta adeguato per molte organizzazioni. Se l'organizzazione necessita di dimensioni maggiori per i siti del team, utilizzare un'inclusione con caratteri jolly.

Nel modello l'utilizzo di inclusioni esplicite determina la creazione degli URL riportati nella tabella seguente.

Dipendente interno (area Intranet)	Dipendente remoto (area predefinita)
http://team/Team1	https://team.fabrikam.com/Team1
http://team/Team2	https://team.fabrikam.com/Team2
http://team/Team3	https://team.fabrikam.com/Team3

In questo esempio la raccolta siti principale, ovvero http://team, non ospita necessariamente il contenuto per gli utenti.

Contenuto Intranet pubblicato

All'interno dell'applicazione per il contenuto Intranet pubblicato viene utilizzata un'inclusione esplicita per ogni sito secondario, ovvero Risorse umane, Servizi e Acquisti. In questo modo ogni sito può essere gestito in modo indipendente. È possibile associare ogni raccolta siti a un database del contenuto diverso, se necessario, in modo da gestire l'espansione e offrire l'opportunità di eseguire il backup e il ripristino dei siti in modo separato.

Nel modello l'utilizzo di inclusioni esplicite determina la creazione degli URL riportati nella tabella seguente.

Dipendente interno (area Intranet)	Dipendente remoto (area predefinita)
http://fabrikam	https://intranet.fabrikam.com
http://fabrikam/risorseumane	https://intranet.fabrikam.com/risorseumane
http://fabrikam/servizi	https://intranet.fabrikam.com/servizi
http://fabrikam/acquisti	https://intranet.fabrikam.com/acquisti

In questo esempio la raccolta siti principale, ovvero http://fabrikam, rappresenta la home page predefinita per la rete Intranet. Questo sito è destinato ospitare il contenuto per gli utenti.

Inclusioni di caratteri jolly: Web partner e i siti personali

Sia nell'applicazione Web per i partner sia in quella per i siti personali viene utilizzata un'inclusione di caratteri jolly. Le inclusioni di caratteri jolly sono ideali per le applicazioni che consentono agli utenti di creare raccolte siti personali. Un'inclusione di caratteri jolly indica che l'elemento successivo al carattere jolly corrisponde a un sito principale di una raccolta siti.

Siti personali

L'applicazione per i siti personali consente la creazione di siti in modalità self-service. Quando un utente consulta la rete Intranet e fa clic su Siti personali, viene creato automaticamente un sito personale per l'utente. Nel modello l'applicazione per i siti personali contiene un'inclusione di caratteri jolly denominata /personale (http://personali/personale). La caratteristica Siti personali determina l'aggiunta automatica del nome dell'utente all'URL.

Verranno creati URL nei formati illustrati nella tabella seguente.

Dipendente interno (area Intranet)	Dipendente remoto (area predefinita)
http://personali/siti/utente1	https://personali.fabrikam.com/personale/utente1
http://personali/siti/utente2	https://personali.fabrikam.com/personale/utente2
http://personali/siti/utente3	https://personali.fabrikam.com/personale/utente3

Web partner

L'applicazione Web per i partner è progettata per consentire ai dipendenti di creare con facilità siti protetti per la collaborazione con partner esterni. Per supportare questo obiettivo, è consentita la creazione di siti in modalità self-service.

Nel modello l'applicazione Web per i partner contiene un'inclusione di caratteri jolly denominata /siti (http://webpartner/siti). Verranno creati URL nei formati illustrati nella tabella seguente.

Dipendente interno (area Intranet)	Dipendente remoto (area predefinita)
http://webpartner/siti/progetto1	https://webpartnerremoto.fabrikam.com/siti/progetto1
http://webpartner/siti/progetto2	https://webpartnerremoto.fabrikam.com/siti/progetto2
http://webpartner/siti/progetto3	https://webpartnerremoto.fabrikam.com/siti/progetto3

I collaboratori dei partner possono accedere ai siti Web per i partner utilizzando gli URL elencati nella tabella seguente.

Partner (area Extranet)
https://webpartner.fabrikam.com/siti/progetto1
https://webpartner.fabrikam.com/siti/progetto2
https://webpartner/fabrikam.com/siti/progetto3

L'eccezione per l'applicazione Web per i partner, come illustrato nel modello, è rappresentata dalle due raccolte siti dedicate alla creazione e modifica e alla gestione temporanea del contenuto per il sito Internet aziendale. Per queste due raccolte siti è stata utilizzata un'inclusione esplicita. Questo costituisce un esempio di utilizzo di inclusioni esplicite e di inclusioni di caratteri jolly nella stessa applicazione Web.

URL di amministrazione

Nella tabella seguente vengono elencati gli URL per l'area di amministrazione di ogni applicazione ospitata nella server farm.

Applicazione	URL
Contenuto Intranet pubblicato	http://fabrikam.amministrazione
Siti del team	http://team.amministrazione
Siti personali	http://personali.amministrazione
Web partner	http://webpartner.amministrazione
Sito Internet aziendale	http://sitofabrikam.amministrazione

Nel modello si presuppone che gli amministratori dispongano dell'accesso interno alla rete aziendale.

Criteri per le aree

È possibile creare un criterio per un'applicazione Web per applicare autorizzazioni al livello dell'applicazione Web. È possibile definire un criterio per l'applicazione Web in generale o solo per un'area specifica. L'utilizzo di un criterio determina l'applicazione delle autorizzazioni a tutto il contenuto all'interno dell'applicazione Web o dell'area. Le autorizzazioni applicate tramite criteri sostituiscono tutte le altre impostazioni di protezione configurate per i siti e il contenuto. È possibile configurare i criteri in base a utenti o gruppi di utenti, ma non in base a gruppi di SharePoint.

Nel modello vengono forniti alcuni esempi di criteri per il raggiungimento degli scopi seguenti:

• Consentire agli amministratori di accedere a tutto il contenuto.

• Negare l'accesso in scrittura al contenuto pubblicato.

• Verificare che autori e tester dispongano dell'accesso appropriato al contenuto pubblicato.

Scaricare il manuale

Questo argomento è incluso nel manuale seguente, che può essere scaricato per una lettura e una stampa più agevoli:

• Pianificazione di un ambiente Extranet per Office SharePoint Server (informazioni in lingua inglese)

Per un elenco completo dei manuali disponibili che è possibile scaricare per Office SharePoint Server 2007, vedere Downloadable content for Office SharePoint Server 2007 (informazioni in lingua inglese).