Η ΕΝΗΜΕΡΩΜΈΝΗ ΈΚΔΟΣΗ 11/03/08: Να είστε βέβαιος να διαβάσει το σχόλιο εξαιρετική και λεπτομερή από Ντέσιε Lunsford σε αυτήν την ανάρτηση.

Έχω εργαστεί σε ένα μυστικό τεχνολογίας επεξεργασίας project για μια επικείμενη βιβλίο και αυτό αναφορές αυτήν την είσοδο blog από Tyler μπάτλερ για το MSDN ECM blog. Αυτό είναι η πρώτη φορά που διάβασα προσωπικά ένα σαφή ορισμό της έννοιας της περιορισμένης πρόσβασης. Εδώ είναι το κρέας του ορισμού:

Στο SharePoint, ανώνυμοι χρήστες’ δικαιώματα καθορίζονται από το επίπεδο δικαιωμάτων περιορισμένης πρόσβασης. Περιορισμένη πρόσβαση είναι μια ειδική άδεια επίπεδο που μπορεί να αντιστοιχιστεί σε ένα χρήστη ή μια ομάδα άμεσα. Ο λόγος που υπάρχει είναι επειδή εάν έχετε μια βιβλιοθήκη ή μια δευτερεύουσα τοποθεσία που έχει σπάσει δικαιώματα μεταβίβαση, και μπορείτε να δώσετε ένα πρόσβαση χρήστη/ομάδα στη μόνο ότι βιβλιοθήκη/δευτερεύουσα τοποθεσία, για να δείτε τα περιεχόμενά, το χρήστη/ομάδα πρέπει να έχουν κάποια πρόσβαση στο Web ρίζας. Αλλιώς το χρήστη/ομάδα θα είναι σε θέση να περιηγηθείτε τη βιβλιοθήκη/δευτερεύουσα τοποθεσία, ακόμα και αν έχουν δικαιώματα εκεί, επειδή υπάρχουν πράγματα στο web ρίζας που απαιτούνται για να καταστήσει την περιοχή ή τη βιβλιοθήκη. Ως εκ τούτου, Όταν δίνετε μια ομάδα δικαιώματα μόνο για μια δευτερεύουσα τοποθεσία ή τη βιβλιοθήκη που είναι το σπάσιμο δικαιώματα μεταβίβαση, SharePoint θα αυτόματα περιορισμένη πρόσβαση σε ότι ομάδας ή του χρήστη στο web ρίζας.

Το ερώτημα που τίθεται τώρα και στη συνέχεια για το φόρουμ MSDN και πάντα ήμουν περίεργος (αλλά δεν είναι αρκετά περίεργος να το λογαριάσω έξω πριν από σήμερα :)).

</Τέλος>

Εγγραφείτε στο blog μου.

Συνέχεια μου για Twitter σε http://www.twitter.com/pagalvin

Σε μια ένδειξη ότι επόμενο εργαλείο επιχειρησιακής νοημοσύνης αρχίζει να απογειωθεί με SharePoint, Βλέπω έναν αυξημένο αριθμό μου Site τύπου ερωτήσεις. Μια κοινή ερώτηση πηγαίνει κάτι παρεμφερή:

"Είμαι διαχειριστής και πρέπει να είμαι σε θέση να έχουν πρόσβαση σε κάθε τοποθεσία μου. Πώς μπορώ να κάνω αυτό?"

Το κόλπο εδώ είναι ότι η κάθε τοποθεσία μου είναι δική της συλλογή τοποθεσιών. SharePoint ασφαλείας χορηγείται κανονικά σε επίπεδο συλλογής τοποθεσιών και αυτό ταξίδια μέχρι πολλά διαχειριστής SharePoint. Κανονικά, έχει ήδη πρόσβαση για να ρυθμίσετε την ασφάλεια στην κύρια"" site συλλογές και δεν μπορούν να συνειδητοποιήσουν ότι αυτό δεν λειτουργεί αυτόματα για τοποθεσίες μου.

Συλλογές τοποθεσιών συλλογικά ζουν μέσα σε ένα μεγαλύτερο δοχείο, που είναι η εφαρμογή web. Αγρόκτημα admins μπορούν να ρυθμίσετε τις παραμέτρους ασφαλείας σε επίπεδο web app και αυτό είναι το πώς admins μπορούν να παραχωρούν στους εαυτούς τους πρόσβαση σε οποιαδήποτε συλλογή τοποθεσιών στην εφαρμογή web. Αυτό το ιστολόγιο εισόδου περιγράφει ένα από την προσωπική εμπειρία μου με πολιτικές εφαρμογής web. Ι ορίζεται μια web εφαρμογή πολιτικής από ατύχημα: http://paulgalvin.spaces.live.com/Blog/cns!1CC1EDB3DAA9B8AA!255.entry.

Πολιτικές εφαρμογής Web μπορεί να είναι επικίνδυνη και προτείνω να χρησιμοποιείται με φειδώ. Αν ήμουν ένας admin (και δόξα τω Θεώ δεν είμαι), Θα δημιουργήσει έναν ξεχωριστό λογαριασμό Διαφημίσεων που ονομάζεται κάτι σαν "διαχειριστής SharePoint Web App" και να δώσει αυτό έναν λογαριασμό ο ρόλος ασφαλείας εφαρμογής web χρειάζεται. Δεν θα διαμορφώσω κάτι τέτοιο για το admin τακτική αγρόκτημα ή admins συλλογή μεμονωμένης τοποθεσίας. Αυτό θα τείνουν να κρύψει πιθανά προβλήματα, επειδή ο ρόλος app web υπερισχύει κάθε χαμηλότερο επίπεδο ασφαλείας ρυθμίσεις.

</Τέλος>

Εγγραφείτε στο blog μου.

Συνέχεια μου για Twitter σε http://www.twitter.com/pagalvin

Η ΕΝΗΜΕΡΩΜΈΝΗ ΈΚΔΟΣΗ (02/29/08): Το νέο αυτό σχέδιο codeplex φαίνεται να παρέχει μια μέθοδο για την εξασφάλιση μεμονωμένες στήλες: http://www.codeplex.com/SPListDisplaySetting. Αν έχετε οποιαδήποτε εμπειρία εργασίας με το, Παρακαλώ αφήστε ένα σχόλιο.

Αφίσες φόρουμ συχνά να κάνω μια ερώτηση όπως αυτό: "Έχω μια άποψη του διαχειριστή και και ένα προσωπικό προβολή μιας λίστας. Πώς ασφαλή την άποψη του διαχειριστή έτσι ώστε το προσωπικό δεν μπορεί να το χρησιμοποιήσει?"

Ζητούν επίσης συχνά ένα σχετικό ερώτημα: "Θέλω να εξασφαλίσει μια στήλη ειδικών μεταδεδομένων, έτσι ώστε μόνο οι διαχειριστές μπορεί να επεξεργαστείτε αυτήν τη στήλη, ενώ άλλοι μπορεί να δεν δούμε αυτό."

Απαντήσεις αυτές ισχύουν για δύο WSS 3.0 και ΒΡΎΑ:

• SharePoint παρέχει υποστήριξη out-of-the-box για εξασφάλιση εμφανίσεις.
• SharePoint παρέχει υποστήριξη out-of-the-box για στήλες ασφαλείας.

Υπάρχουν διάφορες τεχνικές που ένας να ακολουθήσετε για να συναντήσει τα είδη αυτών των απαιτήσεων ασφαλείας. Εδώ είναι τι μπορώ να σκεφτώ:

• Χρησιμοποιήστε το επίπεδο ασφαλείας του στοιχείου out-of-the-box. Θέα τηρούν πάντοτε το στοιχείο ρύθμιση παραμέτρων επιπέδου ασφάλειας. Εκδήλωση δέκτες ή/και ροή εργασίας μπορεί να αυτοματοποιήσει ασφαλείας ανάθεσης.
• Χρησιμοποιούν προσωπικές απόψεις για «το προνόμιο" θέα. Αυτά είναι αρκετά εύκολο να δημιουργηθεί. Ωστόσο, λόγω τις προσωπικές τους"" φύση, αυτά πρέπει να ρυθμιστούν για κάθε χρήστη. Ρύθμιση παραμέτρων χρήσης πρότυπο ασφάλειας, να αποτρέψουν τρίτους από το να δημιουργήσει μια προσωπική άποψη.
• Χρησιμοποιήσετε ένα τμήμα web προβολής δεδομένων και εφαρμογή κάποιας λύσης κόψιμο AJAXy ασφαλείας.
• Κυλήστε τη δική σας λίστα Εμφάνιση λειτουργικότητα και να ενσωματώσει κλάδεμα ασφαλείας σε επίπεδο στηλών.
• Τροποποιήσετε οι φόρμες καταχώρησης δεδομένων και τη χρήση JavaScript σε συνδυασμό με το μοντέλο ασφαλείας για να εφαρμοστεί ασφάλεια σε επίπεδο στήλης Τακτοποίηση.
• Χρησιμοποιήστε μια φόρμα του InfoPath για εισαγωγή δεδομένων. Εφαρμογή ασφάλειας σε επίπεδο στήλης Τακτοποίηση μέσω κλήσεις της υπηρεσίας web του SharePoint και υπό όρους Απόκρυψη πεδίων ανάλογα με τις ανάγκες.
• Ρολό δική σας λειτουργία εισόδου δεδομένων ASP.NET που υλοποιεί στήλη επίπεδο ασφαλείας κλάδεμα.

Καμία από αυτές τις επιλογές είναι πραγματικά τόσο μεγάλη, αλλά υπάρχει τουλάχιστον μια πορεία που θα ακολουθήσει, αν χρειαστεί να, ακόμα κι αν είναι δύσκολο.

ΣΗΜΕΊΩΣΗ: Αν πάτε κάτω από οποιοδήποτε από αυτά τα μονοπάτια, μην ξεχάστε για "ενέργειες-> Άνοιγμα με την εξερεύνηση των Windows". Θέλετε να είστε σίγουροι ότι μπορείτε να δοκιμάσετε με αυτό το χαρακτηριστικό για να βεβαιωθείτε ότι δεν λειτουργεί ως μια «κερκόπορτα" και να νικήσει σας ασφάλιση.

Εάν έχετε άλλες ιδέες για ή εμπειρίες με εξασφάλιση στήλες ή απόψεις, Παρακαλώ email μου ή αφήστε ένα σχόλιο και θα ενημερώσω αυτήν την καταχώρηση κατά περίπτωση.

</Τέλος>

Εγγραφείτε στο blog μου.

Η ΕΝΗΜΕΡΩΜΈΝΗ ΈΚΔΟΣΗ: I δημοσιεύτηκε το ζήτημα να MSDN εδώ (http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2808543&SiteID=1&mode=1) και Michael Washam της Microsoft απάντησε με μια συνοπτική απάντηση.

Δημιούργησα μια υπηρεσία web να ενεργεί ως ένα Φιλικές προς το BDC πρόσοψη σε μια λίστα του SharePoint. Όταν αυτό χρησιμοποιείται από το περιβάλλον ανάπτυξης μου, λειτούργησε άψογα. Όταν εγώ μετεγκατάσταση αυτό σε νέο διακομιστή, Αντιμετώπισα αυτό το σφάλμα:

Εδώ είναι γραμμή 69:

χρήση (Τοποθεσία της SPSite = νέα SPSite("http://localhost/sandbox"))

Προσπάθησα διαφορετικές παραλλαγές σχετικά με τη διεύθυνση URL, συμπεριλαμβανομένων των χρησιμοποιώντας το πραγματικό όνομα του διακομιστή, τη διεύθυνση IP, στο τέλος καθέτους για το URL, κλπ. Πήρα πάντα αυτό το σφάλμα.

Χρησιμοποίησα Το Google να την έρευνα. Πολλοί άνθρωποι αντιμετωπίζουν αυτό το ζήτημα, ή παραλλαγές του, αλλά κανείς δεν φαινόταν να επιλυθεί.

Tricksy MOSS προβλέπεται τέτοια λεπτομερή σφάλμα που αυτό δεν προκύψει μου για τον έλεγχο της 12 Κυψέλη κούτσουρα. Τελικά, σχετικά με την 24 ώρες μετά ο συνάδελφός μου Συνιστάται αυτό το κάνω, Έλεγξα το 12 Hive καταγραφής και βρήκε αυτό:

Παρουσιάστηκε μια εξαίρεση κατά την προσπάθεια να αποκτήσει το τοπικό αγρόκτημα:
System.Security.SecurityException: Δεν επιτρέπεται η πρόσβαση στο μητρώο ζητήθηκε.
στο System.ThrowHelper.ThrowSecurityException(ExceptionResource πόρου) στο Microsoft.Win32.RegistryKey.OpenSubKey(Συμβολοσειρά όνομα, Boolean εγγράψιμο) στο Microsoft.Win32.RegistryKey.OpenSubKey(Συμβολοσειρά όνομα) στο Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_RegistryConnectionString() στο Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_Local() στο Microsoft.SharePoint.Administration.SPFarm.FindLocal(SPFarm& αγρόκτημα, Δυαδική τιμή& isJoined)
Ήταν η ζώνη του συγκροτήματος που απέτυχε:  "Ο_Υπολογιστής_μου"

Αυτό άνοιξε νέους δρόμους της έρευνας, Έτσι, ήταν πίσω στο The Google. Που με οδήγησε σε αυτό μήνυμα στο φόρουμ: http://forums.CodeCharge.com/Posts.php?post_id = 67135. Που πραγματικά δεν με βοήθησε αλλά άρχισες μου κάνει πως υπήρχε μια βάση δεδομένων ή/και την ασφάλεια θέμα. Εγώ soldiered και Του Andrew Connell μετά το τέλος ενεργοποιείται η σκέψη ότι εγώ θα πρέπει να βεβαιωθείτε ότι ο λογαριασμός ταυτότητας του χώρου συγκέντρωσης εφαρμογών είχε κατάλληλη πρόσβαση στη βάση δεδομένων. Σκέφτηκα ότι το έκανε ήδη. Ωστόσο, ο συνάδελφός μου πήγε και έδωσε το app χώρου συγκέντρωσης ταυτότητα λογαριασμού πλήρη πρόσβαση σε SQL.

Μόλις έκανε την αλλαγή, τα πάντα άρχισε να εργάζεται.

Τι συνέβη επόμενο καλύτερο εκφράζεται ως ένα haiku ποίημα:

Προβλήματα σηκώσουν τα χέρια τους.
Σας swing και Μις. Δοκίμασε ξανά.
Επιτυχία! Αλλά πώς? Γιατί?

Δεν θέλει να αφήσει τα πράγματα μόνο όπως αυτή, προτιμώντας να δώσει τα ελάχιστα απαιτούμενα δικαιώματα (και πιθανώς γνώμονα την εγγραφή καταχώρηση ιστολογίου; Εγώ beat της να το διατρητικό, muhahahahaha!).

Αυτή αφαιρούνται διαδοχικές δικαιώματα από το λογαριασμό της ταυτότητα χώρου συγκέντρωσης app μέχρι … δεν υπήρχε πλέον ρητή άδεια για το app ο λογαριασμός ταυτότητα χώρου συγκέντρωσης σε όλα. Η υπηρεσία web συνέχισε να δουλεύει μια χαρά.

Πήγαμε και επανεκκίνηση διακομιστές. Τα πάντα που συνέχισαν να δουλεύουν μια χαρά.

Έτσι, για να ξεκαθαρίσω: δώσαμε το app ταυτότητα πλήρη πρόσβαση σε πισίνα και στη συνέχεια πήρε μακριά. Η υπηρεσία web άρχισε να εργάζεται και ποτέ δεν σταμάτησε να λειτουργεί. Παράξενη.

Αν γνωρίζει για ποιο λόγο που θα πρέπει να έχουν εργαστεί, Παρακαλώ αφήστε ένα σχόλιο.

</Τέλος>

Χρειαζόμουν μια ασφάλεια η απαίτηση για μια φόρμα του InfoPath σήμερα. Σε αυτήν την κατάσταση επιχειρήσεων, ένας σχετικά μικρός αριθμός ατόμων επιτρέπονται για να δημιουργήσετε μια νέα φόρμα του InfoPath και σε πολύ ευρύτερο κοινό έχουν τη δυνατότητα να επεξεργαστείτε. (Πρόκειται για νέα μίσθωση για την επιβίβαση μορφή χρησιμοποιείται από το ανθρώπινο δυναμικό που ξεκινά μια ροή εργασίας).

Να εκπληρώσει αυτό το στόχο, Δημιούργησα δημιουργήθηκαν δύο νέα επίπεδα δικαιωμάτων ("δημιουργία και ενημέρωση" και "μόνο για ενημέρωση"), έσπασε την κληρονομιά για τη βιβλιοθήκη φορμών και να εκχωρηθούν σε αυτές δικαιώματα για την "δημιουργία, η ενημερωμένη έκδοση" χρήστη και ένα ξεχωριστό "ενημέρωση μόνο" χρήστης. Όλες οι μηχανικοί εργάστηκαν, όμως, αποδείχθηκε για να είναι λίγο πιο συμμετέχουν από το αναμενόμενο. (Εάν αισθάνεστε λίγο επισφαλής για τα δικαιώματα του SharePoint, Ελέγξτε έξω αυτό το blog post). Η απαιτούμενη ασφάλεια ρύθμιση για το επίπεδο δικαιωμάτων δεν ήταν το προφανές σύνολο δικαιωμάτων σε κόκκους. Για να δημιουργήσετε ένα επίπεδο δικαιωμάτων μόνο για ενημέρωση για μια φόρμα του InfoPath, Έκανα τα εξής:

1. Δημιουργήσετε ένα νέο επίπεδο δικαιωμάτων.
2. Απομακρύνετε όλες τις επιλογές.
3. Είχαν επιλεγεί μόνο η μετά από "Δικαιώματα λίστας":

• Επεξεργασία στοιχείων
• Προβολή στοιχείων
• Εφαρμογή προβολής σελίδων

Ενεργοποιήσετε αυτές τις επιλογές επιτρέπει στο χρήστη να ενημερώσετε μια μορφή, αλλά δεν θα είχε δημιουργήσει.

Το κόλπο ήταν να ενεργοποιήσετε την "Προβολή εφαρμογή σελίδων". Δεν υπάρχει οποιαδήποτε verbage σχετικά με το επίπεδο δικαιωμάτων που δείχνει που είναι αναγκαία για την ενημέρωση μόνο φόρμες του InfoPath, αλλά εκ περιτροπής έξω αυτό είναι.

Δημιουργία και ενημέρωση ήταν ακόμη και ξένος. Έχω ακολουθήσει τα ίδια βήματα, 1 μέσω 3 πάνω από. Είχα να προσθέσω συγκεκριμένα μια άδεια τοποθεσίας"" επιλογή: "Χρήση χαρακτηριστικά γνωρίσματα ολοκλήρωσης του προγράμματος-πελάτη". Και πάλι, η περιγραφή του εκεί δεν το κάνουν να φανεί σαν πρέπει να απαιτηθεί για μια φόρμα του InfoPath, αλλά υπάρχει.

</Τέλος>

Η ΕΝΗΜΕΡΩΜΈΝΗ ΈΚΔΟΣΗ 01/28/08: Το έργο αυτό codeplex αντιμετωπίζει αυτό το ζήτημα: http://www.codeplex.com/AccessChecker. Δεν έχω χρησιμοποιήσει, αλλά φαίνεται πολλά υποσχόμενη, αν αυτό είναι ένα θέμα που θα χρειαστεί να αντιμετωπίσετε στο περιβάλλον σας.

Η ΕΝΗΜΕΡΩΜΈΝΗ ΈΚΔΟΣΗ 11/13/08: Joel Oleson ετοίμασε μια πολύ καλή θέση για το μεγαλύτερο θέμα διαχείρισης ασφαλείας εδώ: http://www.sharepointjoel.com/ Lists/Posts/Post.aspx?Λίστα = 0cd1a63d % 2D183c % 2D4fc2 %2 D 8320% 2Dba5369008acb&ID = 113. Συνδέει σε μια σειρά από άλλες χρήσιμες πηγές.

Οι χρήστες του φόρουμ και πελάτες συχνά να θέσω ένα ερώτημα προς αυτή την κατεύθυνση: "Πώς δημιουργήσω μια λίστα όλων των χρηστών με πρόσβαση σε μια τοποθεσία" ή "Πώς μπορεί να σας ειδοποιεί αυτόματα όλους τους χρήστες με πρόσβαση στη λίστα σχετικά με αλλαγές που έγιναν στον κατάλογο?"

Δεν υπάρχει καμία έξω από το box λύση για αυτό. Εάν σκεφτείτε για μια στιγμή, δεν είναι δύσκολο να καταλάβω γιατί.

Ασφαλείας του SharePoint είναι πολύ ευέλικτο. Υπάρχουν τουλάχιστον τέσσερις μεγάλες κατηγορίες των χρηστών:

• Ανώνυμοι χρήστες.
• SharePoint χρήστες και ομάδες.
• Χρήστες του Active Directory.
• Φόρμες που βασίζονται σε έλεγχο ταυτότητας (FBA) οι χρήστες.

Η ευελιξία που σημαίνει από την άποψη της ασφάλειας, οποιαδήποτε δεδομένη τοποθεσία SharePoint θα είναι πολύ διαφορετικό από το άλλο. Για να δημιουργήσετε μια αναφορά λίστα πρόσβασης, κάποιος πρέπει να εξακριβώσει πώς εξασφαλίζεται το site, ερώτημα πολλαπλών διαφορετικό χρήστη προφίλ αποθετήρια και μετά να το παρουσιάσουμε σε ένα χρήσιμο τρόπο. Αυτό είναι ένα σκληρό πρόβλημα που λύνει γενικά.

Πώς είναι οργανώσεις που ασχολούνται με αυτό? Θα ήθελα πολύ να ακούσουμε από εσάς στα σχόλια ή ηλεκτρονικό ταχυδρομείο.

</Τέλος>

Η ΕΝΗΜΕΡΩΜΈΝΗ ΈΚΔΟΣΗ 12/18/07: Δείτε το άρθρο του Paul Liebrand για κάποιες τεχνικές συνέπειες της αφαίρεση ή τροποποίηση στα προεπιλεγμένα ονόματα ομάδας (Δείτε το παρακάτω σχόλιο καθώς και).

Επισκόπηση:

Ασφαλείας του SharePoint είναι εύκολο να ρυθμίσετε και να διαχειριστείτε. Ωστόσο, έχει αποδειχθεί ότι είναι δύσκολο για κάποιο πρώτους διαχειριστές να πραγματικά να τυλίξει τα χέρια τους γύρω από αυτό. Δεν είναι μόνο ότι, Έχω δει μερικοί διοικητές που έρχονται σε μια τέλεια κατανόηση τη Δευτέρα μόνο για να έχουν χάσει μέχρι την Παρασκευή επειδή δεν έχουν να κάνουν οποιαδήποτε ρύθμιση παραμέτρων στο μεσοδιάστημα. (Ομολογώ να έχουν αυτό το πρόβλημα ο ίδιος). Αυτό το ιστολόγιο εισόδου Ας ελπίσουμε ότι παρέχει έναν χρήσιμο SharePoint ασφαλείας εγχυτήρα και σημεία προς ορισμένες βέλτιστες πρακτικές ρυθμίσεις ασφαλείας.

Σημαντική σημείωση:

Αυτή η περιγραφή είναι με βάση έξω από το πλαίσιο ασφαλείας του SharePoint. Η προσωπική μου εμπειρία είναι προσανατολισμένη γύρω από τα ΒΡΎΑ, έτσι μπορεί να υπάρξει κάποια το ΒΡΎΟ συγκεκριμένα πράγματα εδώ, αλλά πιστεύω ότι είναι ακριβή για WSS. Ελπίζω ότι βλέποντας οποιαδήποτε λάθη ή παραλείψεις θα επισημάνω ότι στα σχόλια ή email μου. Θα σας κάνω διορθώσεις ειπείν.

Βασικές αρχές:

Για τους σκοπούς αυτής της επισκόπησης, Υπάρχουν τέσσερις θεμελιώδεις πτυχές ασφάλειας: Οι χρήστες/ομάδες, ασφαλιζόμενα αντικείμενα, επίπεδα δικαιωμάτων και κληρονομικότητα.

Χρήστες και ομάδες σπάσει προς τα κάτω για να:

• Μεμονωμένους χρήστες: Τράβηξε από ενεργό κατάλογο ή δημιουργήθηκε απευθείας στο SharePoint.
• Ομάδες: Αντιστοιχισμένα απευθείας από την υπηρεσία καταλόγου active directory ή δημιουργήθηκε το SharePoint. Ομάδες είναι μια συλλογή των χρηστών. Ομάδες είναι παγκόσμια σε μια συλλογή τοποθεσιών. Ποτέ δεν «δετική" σε ένα συγκεκριμένο ασφαλιζόμενο αντικείμενο.

Ασφαλιζόμενα αντικείμενα σπάσει προς τα κάτω για τουλάχιστον:

• Τοποθεσίες
• Βιβλιοθήκες εγγράφων
• Μεμονωμένα στοιχεία σε λίστες και βιβλιοθήκες εγγράφων
• Φάκελοι
• Διάφορες ρυθμίσεις BDC.

Υπάρχουν άλλα ασφαλιζόμενα αντικείμενα, αλλά μπορείτε να πάρετε την εικόνα.

Επίπεδα δικαιωμάτων: Μια δέσμη των κοκκώδη / χαμηλό επίπεδο πρόσβασης δικαιωμάτων που περιλαμβάνουν τέτοια πράγματα όπως Δημιουργήστε/Διαβάστε/διαγράψτε καταχωρήσεις σε λίστες.

Κληρονομικότητα: Από προεπιλογή, οντότητες κληρονομούν τις ρυθμίσεις ασφαλείας από τους αντικειμένου που περιέχει. Δευτερεύουσες τοποθεσίες που κληρονομούν δικαιώματα από το γονικό τους. Βιβλιοθήκες εγγράφων που κληρονομούν από το site τους. Ούτω καθεξής και ούτω καθεξής.

Χρήστες και ομάδες που σχετίζονται με ασφαλιζόμενα αντικείμενα μέσω επίπεδα δικαιωμάτων και κληρονομικότητα.

Τους σημαντικότερους κανόνες ασφαλείας για την κατανόηση, Ever 🙂 :

1. Ομάδες είναι απλώς συλλογές των χρηστών.
2. Ομάδες, είναι παγκόσμια μέσα σε μια συλλογή τοποθεσιών (ήτοι. δεν υπάρχει κανένα τέτοιο πράγμα όπως μια ομάδα που ορίζονται σε επίπεδο τοποθεσίας).
3. Όνομα ομάδας, δεν αντέχουν, ομάδες δεν, μέσα και τον εαυτό τους, έχουν τις ειδικές επίπεδο ασφαλείας.
4. Ομάδες έχουν ασφάλεια στο πλαίσιο της ένα συγκεκριμένο ασφαλιζόμενο αντικείμενο.
5. Μπορεί να μπορείτε να αντιστοιχίσετε διαφορετικά επίπεδα δικαιωμάτων στην ίδια ομάδα για κάθε ασφαλιζόμενο αντικείμενο.
6. Πολιτικές εφαρμογής Web ατού όλα αυτά (Δείτε παρακάτω).

Οι διαχειριστές ασφαλείας που χάνεται σε μια θάλασσα των λιστών χρηστών και ομάδας χρηστών μπορεί πάντα να βασίζεται στην αυτά τα αξιώματα για να διαχειριστεί και να κατανοήσουν τους ρύθμιση παραμέτρων ασφαλείας.

Κοινές παγίδες:

• Ονόματα ομάδων υπονοεί άδεια: Από το κουτί, SharePoint καθορίζει ένα σύνολο των ομάδων, των οποίων το όνομα υπονοεί μια εγγενή επίπεδο ασφάλειας. Θεωρούν την ομάδα "Συνεργάτη". Καλά, ένα δεν είναι εξοικειωμένοι με το SharePoint ασφαλείας μπορεί να εξετάσουμε αυτό το όνομα και να υποθέσουμε ότι κάθε μέλος αυτής της ομάδας μπορεί να «συμβάλει" σε κάθε site/λίστα/βιβλιοθήκη στην πύλη. Που μπορεί να είναι αλήθεια αλλά όχι επειδή το όνομα της ομάδας που συμβαίνει να είναι "συνεργάτη". Αυτό ισχύει μόνο από το κουτί γιατί η ομάδα έχει προσφέρει ένα επίπεδο δικαιωμάτων που τους δίνει τη δυνατότητα να προσθέσετε/επεξεργαστείτε/διαγράψετε περιεχόμενο στην περιοχή ρίζας. Μέσω κληρονομιάς, Οι συνεισφέροντες"" ομάδα μπορεί επίσης να προσθέσετε/επεξεργαστείτε/διαγράψετε περιεχόμενο σε κάθε υπο-site. Μπορεί να "σπάσει κάποιος" την κληρονομιά αλυσίδα και αλλαγή το επίπεδο δικαιωμάτων από μια δευτερεύουσα τοποθεσία ότι μέλη του το λεγόμενο "συνεισφέρων" Ομάδα δεν μπορεί να συμβάλει σε όλα, αλλά μόνο διαβάσει (για παράδειγμα). Αυτό δεν θα ήταν μια καλή ιδέα, προφανώς, Δεδομένου ότι θα είναι πολύ συγκεχυμένη.
• Ομάδες δεν έχουν οριστεί σε επίπεδο τοποθεσίας. Είναι εύκολο να μπερδευτείτε από το περιβάλλον εργασίας χρήστη. Η Microsoft παρέχει μια βολική σύνδεση με το χρήστη/ομάδα διαχείρισης μέσω κάθε περιοχή "άτομα και ομάδες" σύνδεση. Είναι εύκολο να πιστέψει κανείς ότι όταν είμαι στο site "xyzzy" και μπορώ να δημιουργήσω μια ομάδα μέσω του xyzzy άνθρωποι και ομάδες σύνδεση που έχω μόλις δημιουργήσει μια ομάδα που υπάρχει μόνο στο xyzzy. Αυτό δεν συμβαίνει. Πραγματικά έχω δημιουργήσει μια ομάδα για τη συλλογή του ολόκληρο το site.
• Ομάδες μελών να μην αποκλίνει από την ιστοσελίδα (ήτοι. το ίδιο είναι παντού Ομίλου χρησιμοποιείται): Εξετάσει η ομάδα ιδιοκτήτης"" και δύο τοποθεσίες, "HR" και "Logistics". Θα ήταν φυσιολογικό να σκεφτείτε ότι δύο άτομα ξεχωριστά θα ιδίων αυτές τις τοποθεσίες — ιδιοκτήτης ΥΕ και ένας ιδιοκτήτης Logistics. Το περιβάλλον εργασίας χρήστη το καθιστά εύκολο για ένα διαχειριστή για την ασφάλεια να χειρίζομαι αυτό το σενάριο. Αν δεν ήξερα καλύτερα, Μπορεί να έχω πρόσβαση σε συνδεσμους άτομα και ομάδες, μέσω της ιστοσελίδας του HR, Επιλέξτε "ιδιοκτήτες" ομάδα και να προσθέσετε μου HR ιδιοκτήτης σε αυτή την ομάδα. Ένα μήνα αργότερα, Logistics έρχεται στη γραμμή. Έχω πρόσβαση άτομα και ομάδες από το χώρο των Logistics, Προσθέστε έλξης μέχρι οι ιδιοκτήτες"" Ομάδα. Δείτε τον ιδιοκτήτη HR εκεί και να απομακρύνει, σκέφτεται ότι είμαι απομάκρυνση της από ιδιοκτήτες επί του τόπου της εφοδιαστικής. Στην πραγματικότητα, Είμαι απομάκρυνση της από την παγκόσμια ομάδα ιδιοκτητών. Ακολουθεί ιλαρότητα.
• Παραλείποντας να όνομα ομάδες με βάση το συγκεκριμένο ρόλο: Οι υπεύθυνοι έγκρισης"" ομάδα είναι ένα τέλειο παράδειγμα. Τι μπορώ να μέλη του αυτή έγκριση ομάδας? Όπου μπορεί να την επικυρώνουν? Θέλω πραγματικά τμήμα Logistics τους ανθρώπους να είναι σε θέση να εγκρίνει έγγραφα της HR? Φυσικά δεν. Πάντα το όνομα ομάδες με βάση το ρόλο τους μέσα στην οργάνωση. Αυτό θα μειώσει τον κίνδυνο ότι η ομάδα έχει εκχωρηθεί ένα επίπεδο ακατάλληλη δικαιωμάτων για ένα συγκεκριμένο ασφαλιζόμενο αντικείμενο. Όνομα ομάδες με βάση την προβλεπόμενη ρόλο τους. Στο προηγούμενο σενάριο HR/Logistics, Θα πρέπει να έχουν δημιουργηθεί δύο νέες ομάδες: "HR ιδιοκτήτες" και «Logistics ιδιοκτήτες" και να αναθέσετε επίπεδα για κάθε τεχνολογία λογική άδεια και το ελάχιστο ποσό που απαιτείται για εκείνους τους χρήστες να κάνουν τη δουλειά τους.

Άλλες χρήσιμες αναφορές:

• Web εφαρμογή πολιτικής gotcha: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!255.entry
• Γραφείο συμψηφισμού για SharePoint ασφαλείας: http://www.sharepointsecurity.com/
• Συνδέσεις από Joel Oleson: http://blogs.msdn.com/joelo/archive/2007/08/23/sharepoint-security-and-compliance-resources.aspx

Αν έχετε κάνει αυτό μακριά:

Παρακαλώ επιτρέψτε μου να γνωρίζω τις σκέψεις σας μέσω σχόλια ή email μου. Αν γνωρίζετε άλλες καλές αναφορές, παρακαλώ να κάνει το ίδιο!