SharePoint Security Fundamentals Primer / Evitare i trabocchetti comuni

AGGIORNAMENTO 12/18/07: Vedere l'articolo di Paul Liebrand per alcune conseguenze tecniche di rimuovere o modificare i nomi di gruppo predefinito (vedere pure suo commento qui sotto).

Panoramica:

Protezione di SharePoint è facile da configurare e gestire. Tuttavia, ha dimostrato di essere difficile per alcuni amministratori prima volta davvero avvolgere le mani intorno ad esso. Non solo che, Ho visto alcuni amministratori di giungere ad una comprensione perfetta il lunedì solo per avere perso di venerdì perché non avevano alcuna configurazione nel frattempo. (Ammetto di avere questo problema io). Questo Blog speriamo che fornisce un utile primer di protezione di SharePoint e punti verso alcune procedure ottimali di configurazione.

Nota importante:

Questa descrizione si basa su out of the box di protezione di SharePoint. La mia esperienza personale è orientato intorno a MOSS, così ci possono essere alcune cose specifiche MOSS qui, ma credo che è preciso per WSS. Spero che chiunque vedendo eventuali errori o omissioni che verrà segnalare nei commenti o email me. Farò le correzioni fretta post.

Fondamenti:

Ai fini di questa panoramica, ci sono quattro aspetti fondamentali per la sicurezza: utenti/gruppi, oggetti a protezione diretta, ereditarietà e livelli di autorizzazione.

Utenti e gruppi break down to:

  • Singoli utenti: Tirato da active directory o creato direttamente in SharePoint.
  • Gruppi: Mappata direttamente da active directory o creati in SharePoint. I gruppi sono un insieme di utenti. I gruppi sono globali in una raccolta siti. Non sono mai "legati" per un oggetto a protezione diretta specifico.

Oggetti a protezione diretta rottura verso il basso per almeno:

  • Siti
  • Raccolte documenti
  • Singoli elementi in elenchi e raccolte documenti
  • Cartelle
  • Varie impostazioni BDC.

Ci altri oggetti a protezione diretta, ma si ottiene l'immagine.

Livelli di autorizzazione: Un fascio di granulare / diritti di accesso a basso livello che includono tali cose come creare, leggere o eliminare voci negli elenchi.

Ereditarietà: Per impostazione predefinita le entità ereditano le impostazioni di protezione dal loro oggetto contenente. Siti secondari ereditano l'autorizzazione dai propri genitori. Raccolte documenti ereditano dal loro sito. E così via.

Gli utenti e i gruppi si riferiscono agli oggetti a protezione diretta tramite livelli di autorizzazione e l'eredità.

Norme di sicurezza più importanti per capire, mai :

  1. I gruppi sono semplicemente raccolte degli utenti.
  2. I gruppi sono globali all'interno di una raccolta siti (vale a dire. non non c'è nessuna tale cosa come un gruppo definito a livello di sito).
  3. Nome del gruppo non sopportare, gruppi non, in e di se stessi, avere un livello specifico di sicurezza.
  4. Gruppi hanno sicurezza nel contesto di uno specifico oggetto a protezione diretta.
  5. È possibile assegnare livelli di autorizzazione diversi per lo stesso gruppo per ogni oggetto a protezione diretta.
  6. Criteri di applicazione Web vincente tutto questo (vedi sotto).

Gli amministratori della protezione ha perduti in un mare di annunci gruppo e utente possono sempre contare su questi assiomi per gestire e capire la loro configurazione di sicurezza.

Trabocchetti comuni:

  • I nomi dei gruppi falsamente implica l'autorizzazione: Out of the box, SharePoint definisce un insieme di gruppi i cui nomi implicano un livello intrinseco di sicurezza. Si consideri il gruppo di "Collaboratore". Uno sconosciuto con protezione di SharePoint può ben guardare quel nome e si supponga che ogni membro del gruppo può "contribuire" a qualsiasi sito/elenco/libreria nel portale. Questo può essere vero, ma non perché il nome del gruppo sembra essere "collaboratore". Questo è vero, fuori dalla scatola solo perché il gruppo è stato fornito un livello di autorizzazione che permette loro di aggiungere/modificare/eliminare contenuto nel sito radice. Tramite l'ereditarietà, i contribuenti"" gruppo può anche aggiungere/modificare/eliminare contenuto in ogni sub-sito. Uno può "spezzare" la catena di ereditarietà e cambia il livello di autorizzazione di un sito secondario tali che i membri del cosiddetto "contributore" gruppo non può contribuire a tutti, ma solo leggere (per esempio). Questo non sarebbe una buona idea, ovviamente, poiché sarebbe molto confusa.
  • Gruppi non definiti a livello di sito. È facile essere confusi dall'interfaccia utente. Microsoft fornisce un comodo collegamento a gestione utente/gruppo via "utenti e gruppi di ogni sito" link. È facile credere che quando io sono al sito "xyzzy" e creare un gruppo attraverso persone di xyzzy e gruppi di link che ho appena creato un gruppo che esiste solo a xyzzy. Che non è il caso. In realtà ho creato un gruppo per l'intera raccolta siti.
  • Appartenenza a gruppi non variano da sito (vale a dire. è lo stesso ovunque che il gruppo viene utilizzato): Si consideri il gruppo "proprietario" e due siti, "HR" e "Logistica". Sarebbe normale pensare che due individui separati sarebbero proprio quei siti — un proprietario di HR e un proprietario di logistica. L'interfaccia utente rende facile per un amministratore di sicurezza di maltrattare questo scenario. Se non ti conoscessi bene, Potrei accedere a persone e gruppi di link tramite il sito HR, selezionare i proprietari"" gruppo e aggiungere il mio proprietario di HR a tale gruppo. Un mese più tardi, Logistica arriva sulla linea. Accedere a persone e gruppi dal sito logistica, Aggiungi pull-up i proprietari"" gruppo. Vedo il proprietario HR c'e rimuovere il suo, pensando che lei sto rimuovendo dai proprietari con il sito di logistica. Infatti, Io la rimuovo dal gruppo globale proprietari. Segue ilarità.
  • Mancanza di nome ai gruppi basati sul ruolo specifico: Responsabili dell'approvazione"" il gruppo è un perfetto esempio. Che cosa può membri di approvare questo gruppo? Dove essi possano approvarlo? Voglio davvero dipartimento di logistica di persone di essere in grado di approvare i documenti HR? Certo che no. Sempre un nome ai gruppi in base al loro ruolo all'interno dell'organizzazione. Questo ridurrà il rischio che il gruppo viene assegnato un livello di autorizzazione non corretti per un determinato oggetto a protezione diretta. Gruppi di nome basati sul loro ruolo previsto. Nello scenario precedente HR/logistica, Io dovrei aver creato due nuovi gruppi: "HR proprietari" e i proprietari di logistica"" e assegnare livelli di autorizzazione sensata per ciascuno e l'importo minimo richiesto per gli utenti di fare il loro lavoro.

Altri riferimenti utili:

Se hai fatto questo lontano:

Per favore fatemi sapere cosa ne pensate attraverso i commenti o email me. Se conoscete altre buone referenze, si prega di fare lo stesso!

Technorati Tags:

8 pensieri su "SharePoint Security Fundamentals Primer / Evitare i trabocchetti comuni

  1. Perry

    Maggiori insidie:

    * Ci sono alcune autorizzazioni speciali disponibili altrove nel provider di servizi condivisi e non visibile nella sezione utenti e gruppi: "Le personalizzazione servizi autorizzazioni" e "Catalogo dati Business"

    * Ho letto che ci sono anche speciali autorizzazioni di SharePoint Designer disponibile in alcuni xml arcano seppellito all'interno di html da qualche parte.

    * La primaria e secondaria gli amministratori per una raccolta di siti sono mantenuti altrove in impostazioni raccolta siti, e non è visibile nella sezione utenti e gruppi.

    * Alcuni conti sono magici (speciale) abilità indipendentemente da quello che si vede nell'area gruppi e persone: membri del gruppo Administrators incorporato nei server web, e l'Account del servizio Farm.

    (PS: Eliminare i commenti di spam migliorerebbe la leggibilità qui.)

    Risposta
  2. Jean Wright
    Questo è un post molto buono. Io sono caduto in questa trappola in alcune occasioni. Gestione della sicurezza può ottenere complessa quando si inizia a mescolare i metodi di autenticazione e protezione differenti metodi di raggruppamento. Questo deve essere considerato come parte del processo di pianificazione e non deve essere trascurato.
    Risposta
  3. Mark Miller ha scritto:
    (Nota da Paul: Mark mi ha chiesto di fare una piccola modifica al suo commento, ma non riesco a modificare i commenti live spaces così ho aggiunto di nuovo qui con il cambiamento e cancellato l'originale).
    Paul,
    L'approccio di sintesi per presentare questa info è venuto molto bene. Mi piaceva in particolare le insidie"" sezione, Poiché ho caduto un paio di quelli me stesso.
    Un'altra cosa che hai detto colpito a casa: apprendimento il Lunedi non necessariamente non significa che ti ricorderai di venerdì. Sono contento che qualcuno oltre a me sta usando il loro blog come un tickler"" sistema per quelle cose fondamentali che non sono fatto su base regolare.
    Buon lavoro.
    Per quanto riguarda,
    Mark
    EndUserSharePoint.com

    Novembre 27 9:04 AM
    (http://www.EndUserSharePoint.com)

    Risposta
  4. Paul Galvin
    Penso che probabilmente è una buona idea per rimuovere quei gruppi predefiniti, soprattutto il collaboratore e il proprietario. Sono estensivo e facilmente confuso. Io preferisco usare "tutti gli utenti autenticati" al posto di un visitatore"" gruppo pure. Se uno specifico insieme di utenti dovrebbero solo accesso in lettura, quindi vi consiglio di creare un gruppo di annunci o un gruppo di SharePoint con un nome descrittivo in modo appropriato, e. g. "Logistica visitatori".
    –Paul G
    Risposta
  5. Senza nome
    Sembra che la prima cosa che dovreste fare è semplicemente scaricare il visitatore, Gruppi di collaboratori e proprietario e sostituirli con propri gruppi logici. Questo avrebbe senso fare?
    Risposta

Lasciare una risposta

L'indirizzo email non verrà pubblicato. i campi richiesti sono contrassegnati *