עדכון 11/03/08: הקפד לקרוא את ההערה מצוין ומפורט דייזי Lunsford פוסט זה.

אני עובד על פרויקט סודי טק עריכה עבור ספר מתקרב והפניה הפוסט הזה בבלוג על ידי טיילר באטלר בבלוג MSDN ECM. זו הפעם הראשונה באופן אישי קראתי הגדרה ברורה של המשמעות של גישה מוגבלת. . זה הבשר של ההגדרה:

ב- SharePoint, משתמשים אנונימיים’ זכויות נקבעים על-ידי רמת ההרשאה ' גישה מוגבלת '. גישה מוגבלת היא רמת הרשאה מיוחדת אין אפשרות להקצות למשתמש או קבוצה ישירות. הסיבה שהיא קיימת היא כי אם יש לך ספריה או אתר המשנה-שבור הרשאות בירושה, ולתת לך גישה משתמש/קבוצה רק הספריה/שלאתר, כדי להציג את התוכן שלה, המשתמש/הקבוצה חייבת להיות קצת גישה לאתר הבסיס. אחרת המשתמש/הקבוצה לא תהיה אפשרות לעיין המשנה/ספריה, למרות שיש להם זכויות שם, כי יש דברים לאתר הבסיס הדרושים כדי להפוך את האתר או את הספריה. לכן, כשאתה נותן את הרשאות הקבוצה רק על אתר משנה או ספריית שנשבר הרשאות בירושה, SharePoint באופן אוטומטי ייתן גישה מוגבלת זה לקבוצה או למשתמש ברשת האינטרנט שורש.

שאלה זו עולה פעם בפורומים MSDN ולא תמיד הייתי סקרן (אבל אתה לא סקרן מספיק להבין את זה עד היום :)).

</קצה>

מנוי על הבלוג שלי.

עקוב אחרי הטוויטר ב http://www.twitter.com/pagalvin

בסימן כי מחשוב חברתי מתחיל להמריא עם SharePoint, אני רואה עלייה במספר שאלות מסוג ' האתר שלי '. שאלה נפוצה אחת הולך ככה:

"אני מנהל, אני צריך להיות מסוגל לגשת כל האתר שלי. איך עשית את זה?"

החוכמה כאן היא כי כל ' האתר שלי ' הוא אוסף אתרים משלו. SharePoint אבטחה מנוהל בדרך כלל ברמת אוסף האתר ואת זה טיולים למעלה רבים מנהל SharePoint. בדרך כלל, כבר יש לה גישה כדי לקבוע את תצורת האבטחה הראשי"" אוספי אתרים, לא מבינים זה לא יעבוד באופן אוטומטי עבור ' האתרים שלי '.

אוספי אתרים באופן קולקטיבי לחיות בתוך מיכל גדול יותר, איזו היא יישום האינטרנט. החווה מנהלים יכולים ניתן להגדיר אבטחה ברמת יישום האינטרנט וזה איך מנהלים יכולים להעניק לעצמם גישה בכל אוסף אתרים ביישום האינטרנט. הפוסט בבלוג הזה מתאר את אחת החוויות האישיות שלי עם מדיניות יישומים אינטרנט. אני הגדיר מדיניות יישום אינטרנט בטעות: http://paulgalvin.spaces.live.com/Blog/cns!1CC1EDB3DAA9B8AA!255.entry.

מדיניות יישום אינטרנט יכול להיות מסוכן ואני מציע כי הם לשמש במשורה. אם הייתי מנהל (תודה לאל אני לא), אני ליצור חשבון לספירה נפרד בשם משהו כמו "מנהל יישום אינטרנט של SharePoint" לתת חשבון אחד זה תפקיד האבטחה יישום אינטרנט שזה צריך. לא היה להגדיר את זה עבור מנהל החווה רגיל או מנהלי אוסף אתרים בודדים. זה נוטים להסתיר בעיות פוטנציאליות כי התפקיד web app עוקפת הגדרות אבטחה ברמה נמוכה יותר.

</קצה>

מנוי על הבלוג שלי.

עקוב אחרי הטוויטר ב http://www.twitter.com/pagalvin

עדכון (02/29/08): הפרוייקט החדש הזה codeplex נראה כדי לספק שיטה לאבטחת עמודות בודדות: http://www.codeplex.com/SPListDisplaySetting. אם יש לך ניסיון עבודה עם זה, אנא השאירו תגובה.

פורום פוסטרים לעתים קרובות לשאול שאלה כזאת: "יש לי מנהל תצוגה, ונוף צוות של רשימה. כיצד אוכל לאבטח את תצוגת מנהל הצוות לא יכול להשתמש בו?"

הם גם מרבה לשאול שאלה הקשורה: "אני רוצה לאבטח עמודה מטה-נתונים ספציפיים, כך שרק המנהלים רשאי לערוך עמודה זו, בעוד שאחרים אולי לא יראו את זה."

תשובות אלה חלות על שתי WSS 3.0 אזוב:

• SharePoint אינה מספקת תמיכה out-של--box לאבטחת צפיות.
• SharePoint אינה מספקת תמיכה-התקנים עבור עמודות אבטחה.

ישנן מספר טכניקות אחד יכול לעקוב אחר לפגוש סוגים אלה של דרישות אבטחה. . זה מה שעולה בדעתי:

• להשתמש באבטחה ברמת פריט out-של--box. נוף תמיד לכבד את תצורת אבטחה ברמת הפריט. מקלטי אירוע ו/או זרימת עבודה ניתן להפוך לאוטומטי אבטחה הקצאה.
• השתמש תצוגות אישיות "חסוי" נוף. . אלו קל מספיק להגדיר. עם זאת, בשל "האישי שלהם" טבע, אלה חייבת להיות מוגדרת עבור כל משתמש. שימוש בהגדרות אבטחה סטנדרטיות כדי למנוע מכל אדם אחר יצירת תצוגה אישית.
• Web part של תצוגת נתונים ולהשתמש ליישם איזשהו פתרון זמירה אבטחה AJAXy.
• רול פונקציונליות תצוגת הרשימה שלך ולשלב זמירה אבטחה ברמת עמודה.
• לשנות את טפסי הזנת נתונים ולהשתמש JavaScript בשילוב עם מודל האבטחה כדי ליישם אבטחה ברמת עמודה זמירה.
• השתמש בטופס של InfoPath עבור הזנת נתונים. ליישם אבטחה ברמת עמודה זמירה באמצעות שיחות שירות אינטרנט של SharePoint, מותנה הסתר שדות לפי הצורך.
• רול משלך הפונקציה הזנת נתונים של ASP.NET המיישם את זמירה אבטחה ברמת עמודה.

אף אחת מהאפשרויות האלה הם באמת כל כך טובה, אבל יש לפחות דרך לעקוב אחר אם אתה צריך, גם אם זה קשה.

הערה: אם אתה נופל כל הנתיבים האלה, אל תשכח "פעולות-> פתוח עם סייר Windows". אתה רוצה להיות בטוח. לבדוק עם תכונה זו כדי לוודא שזה לא עובד בתור "דלת אחורית" להביס את ערכת אבטחה.

אם יש לך רעיונות או חוויות עם אבטחת עמודות או נופים אחרים, בבקשה שלח לי דוא או השאירו תגובה, אני אעדכן את פרסום זה לפי הצורך.

</קצה>

מנוי על הבלוג שלי.

עדכון: פרסמתי שאלה זו ל- MSDN כאן (http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2808543&SiteID=1&mode=1) Michael Washam של מיקרוסופט הגיבו עם תשובה תמציתית.

יצרתי שירות אינטרנט לפעול חזית BDC ידידותי לרשימת SharePoint. כאשר השתמשתי בזה מסביבת הפיתוח שלי, זה עבד מצוין. כאשר אני היגרו זה לשרת חדש, בשגיאה זו:

הנה קו 69:

שימוש (אתר SPSite = SPSite חדש("http://localhost/sandbox"))

ניסיתי וריאציות שונות על כתובת ה-URL, כולל שימוש השם האמיתי של השרת, כתובת ה-IP שלו, חתכים נגרר על כתובת ה-URL, ועוד. תמיד קיבלתי שגיאה זו.

השתמשתי גוגל בולקן. הרבה אנשים להתמודד עם בעיה זו, או וריאציות על זה, אבל אף אחד לא נראה שהיא תיפתר.

מוס ערמומי סיפקה כל כך מפורטת שגיאה זה לא עלה לי לבדוק 12 יומני הכוורת. בסופו של דבר, אודות 24 שעות לאחר עמיתי מומלץ שלי לעשות זאת, . בדקתי 12 כוורת רישום ומצאנו את זה:

אירע חריג במהלך מנסה להשיג את המשק המקומי:
System.Security.SecurityException: הרישום המבוקש גישה אינה מותרת.
ב- System.ThrowHelper.ThrowSecurityException(משאבים ExceptionResource) ב- Microsoft.Win32.RegistryKey.OpenSubKey(שם המחרוזת, בוליאני הניתן לכתיבה) ב- Microsoft.Win32.RegistryKey.OpenSubKey(שם המחרוזת) ב- Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_RegistryConnectionString() ב- Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_Local() ב- Microsoft.SharePoint.Administration.SPFarm.FindLocal(SPFarm& החווה, בוליאני& isJoined)
ה-Zone של ההרכבה שנכשלה היה:  MyComputer

זה פתח אפיקים חדשים של מחקר, אז זה היה לחזור גוגל. זה הוביל אותי לזה בפורום: http://forums.codecharge.com/posts.php?post_id = 67135. זה לא ממש עזר לי, אבל זה התחיל לגרום לי לחשוב שיש בעיית מסד הנתונים ו/או אבטחה. אני soldiered ו של אנדרו קונל פוסט מופעלות בסופו של דבר המחשבה כי אני צריך לוודא שיש זהות לחשבון מאגר היישומים הגישה המתאימה במסד הנתונים. . חשבתי שכבר עשו. עם זאת, עמיתי הלך ונתן את האפליקציה בריכה זהות חשבון גישה מלאה ל- SQL.

ברגע שהיא עשתה את השינוי, הכל התחיל לעבוד.

מה קרה לאחר מכן היא הטובה ביותר לבטא האיקו השיר:

בעיות הרימו את הידיים שלהם.
לך לזוז ולפספס. נסה שוב.
הצלחה! אבל איך? ? למה?

היא לא רצתה לעזוב דברים כאלה, העדפת לתת את ההרשאה הנדרשת המינימלית (ואת בטח כדקה כתיבת ערך בלוג; אני להקדים אותה, muhahahahaha!).

היא הסרת הרשאות רצופים חשבון זהות מאגר app עד … . לא היה עוד כל הרשאה מפורשת עבור החשבון זהות מאגר app בכלל. שירות האינטרנט המשיך לעבוד מצוין.

הלך ואנו יאותחל מחדש את השרתים. הכל המשיך לעבוד בסדר.

כל כך, לסיכום: אנו נתנו את האפליקציה זהות מלאה לבריכה, ואז לקח אותו. שירות האינטרנט התחיל לעבוד, אף פעם לא הפסיק לעבוד. מוזר.

אם מישהו יודע למה זה צריך לעבוד, אנא השאירו תגובה.

</קצה>

הייתי צריך לפגוש דרישת אבטחה עבור טופס InfoPath היום. במצב זה עסקים, מספר קטן יחסית של אנשים יורשו ליצור צורה חדשה של InfoPath ואת קהל הרבה יותר רחב מותר לערוך אותו. (. זה חדש-לשכור בפנימייה טופס בשימוש על-ידי משאבי אנוש משיקה זרימת עבודה).

לפגוש את המטרה, יצרתי יצר שתי רמות הרשאה חדשות ("ליצור ולעדכן" ולעדכן "רק"), שבר ירושה עבור ספריית הטפסים ויש להקצות הרשאות "צור, עדכון" המשתמש ו- "עדכון נפרד רק" המשתמש. כל המכניקה עבד, אבל זה הפך להיות מעורבים יותר ממה שציפיתי. (אם אתה מרגיש קצת לא ברורים על SharePoint הרשאות, בדוק בבלוג זה). תצורת האבטחה הנדרשים עבור רמת ההרשאה לא היה ברור ערכת ההרשאות פרטנית. כדי ליצור רמת הרשאה עדכון בלבד עבור טופס InfoPath, . עשיתי את הדברים הבאים:

1. יצירת רמת הרשאה חדשה.
2. לסלק את כל האפשרויות.
3. נבחר רק הבאות מתפריט "רשימת ההרשאות":

• עריכה של פריטים
• הצגת פריטים
• תצוגת יישום עמודים

בחירה באפשרויות אלה מאפשר למשתמש לעדכן טופס, אבל לא ליצור אותו.

הטריק היה כדי לאפשר את "דפי תצוגת יישום". אין שום verbage על רמת ההרשאה המציין הנדרש עבור טפסים של InfoPath עדכון בלבד, אבל מתברר החוצה זה הוא.

צור-ועדכון היה אפילו מוזר. עקבתי אחרי הפעולות, 1 דרך 3 מעל. הייתי צריך להוסיף במפורש הרשאה באתר"" אפשרות: "השתמש הלקוח שילוב תכונות". שוב, התיאור שם לא עושה את זה נראה כמו שהוא צריך להיות נדרש טופס InfoPath, אבל זהו זה.

</קצה>

עדכון 01/28/08: הפרויקט codeplex פותר בעיה זו: http://www.codeplex.com/AccessChecker. לא השתמשתי בו, אבל הוא נראה מבטיח, אם זה בעיה שאתה צריך כתובת בסביבה שלך.

עדכון 11/13/08: ג'ואל אולסן כתבו פוסט טוב מאוד על גדול יותר ניהול בעיית האבטחה כאן: http://www.sharepointjoel.com/ Lists/Posts/Post.aspx?רשימת = 0cd1a63d % 2D183c % 2D4fc2 %2 D 8320% 2Dba5369008acb&ID = 113. זה קישורים למספר משאבים שימושיים אחרים.

פורום משתמשים ולקוחות מרבים לשאול שאלה לאורך שורות אלה: "כיצד אוכל ליצור רשימה של כל המשתמשים בעלי גישה לאתר" או "איך יכול אני אוטומטית להתריע לכל המשתמשים בעלי גישה לרשימת על שינויים שבוצעו ברשימה?"

אי אפשר לצאת של הפתרון תיבת בשביל זה. אם אתה חושב על זה לרגע, זה לא קשה להבין למה.

SharePoint ביטחון הוא מאוד גמיש. יש לפחות ארבע הקטגוריות העיקריות של משתמשים:

• משתמשים אנונימיים.
• SharePoint משתמשים וקבוצות.
• מדריך משתמשים פעילים.
• טפסים מבוסס אימות (FBA) משתמשים.

הגמישות אומר הרי מנקודת ראות ביטחונית, בכל אתר SharePoint נתון יהיה שונה באופן משמעותי אחר. על מנת ליצור דוח רשימה ב- access, צריך לברר איך האתר מאובטח, שאילתה מספר מאגרים פרופיל משתמש אחר ולאחר מכן להציג את זה בצורה שימושית. זו בעיה קשה לפתרון כללי.

איך מתמודדים ארגונים עם זה? אשמח לשמוע ממך הערות או דוא.

</קצה>

עדכון 12/18/07: עיין במאמר פול Liebrand עבור כמה השלכות טכניות של הסרה או שינוי של שמות קבוצות ברירת מחדל (ראה גם את ההערה למטה).

מבט כולל:

אבטחה SharePoint קל להגדיר ולנהל. עם זאת, זה הוכיח להיות קשה עבור מנהלים מסוימים בפעם הראשונה באמת לעטוף את ידיהם סביבו. לא רק זה, . ראיתי כמה מנהלי לבוא הבנה מושלמת ביום שני רק לאבד אותה עד יום שישי. כי הם לא היו צריכים לעשות בכל תצורה הזמן להתערב. (אני מודה שיש בעיה זו בעצמי). את הבלוג בתקווה מספק פריימר אבטחה שימושי SharePoint, מצביע לעבר האבטחה תצורה מומלצות.

הערה חשובה:

תיאור זה מבוסס על מהקופסה SharePoint אבטחה. את הניסיון האישי שלי הוא מונחה סביב מוס אז שיהיה מוס מסוים פה דברים, אבל אני מאמין שזה מדויק עבור WSS. אני מקווה כי מישהו רואה שגיאות שגיאות או השמטות ניתן להצביע זה בהערות או שלח לי דוא. אני אכין תיקונים לכתוב בחיפזון.

יסודות:

למטרות של סקירה זו, ישנם ארבעה ההיבטים הבסיסיים לבטחון: משתמשים/קבוצות, האובייקטים שניתנים לאבטחה, רמות הרשאה וירושה.

משתמשים וקבוצות לבשר למטה:

• למשתמשים בודדים: שלף מתוך active ספריות או שנוצר ישירות ב- SharePoint.
• קבוצות: שמופו ישירות מ- active directory או שנוצר ב- SharePoint. קבוצות הן אוסף של משתמשים. קבוצות הן כלליות באוסף אתרים. הם אף פעם לא "קשורות" לאובייקט ניתן לאבטחה מסוים.

האובייקטים שניתנים לאבטחה לבשר למטה לפחות:

• אתרים
• ספריות מסמכים
• פריטים בודדים בתוך רשימות וספריות מסמכים
• תיקיות
• הגדרות BDC שונות.

שם שאר האובייקטים שניתנים לאבטחה, . אבל הבנתם את התמונה.

רמות הרשאה: צרור פרטנית / זכויות גישה ברמה נמוכה כוללים דברים כמו ליצור/קריאה/מחיקת ערכים ברשימות.

ירושה: כברירת מחדל בישויות יורשים את הגדרות האבטחה שלהם אובייקט מכיל. אתרי המשנה יירשו הרשאות מהאב שלהם. ספריות מסמכים בהורשה מאתר שלהם. הלאה וכן הלאה.

המשתמשים והקבוצות מתייחסות האובייקטים שניתנים לאבטחה באמצעות רמות הרשאה וירושה.

הכללים החשובים ביותר אבטחה כדי להבין, אי פעם 🙂 :

1. קבוצות הן פשוט אוספים של משתמשים.
2. קבוצות הן כלליות בתוך אוסף אתרים (כלומר. אין דבר כזה כמו קבוצה מוגדרים ברמת האתר).
3. שם הקבוצה למרות, קבוצות אינם, בולטים של עצמם, יש רמה מסוימת של אבטחה.
4. קבוצות יש אבטחה בהקשר של אובייקט ניתן לאבטחה מסוים.
5. ייתכן שתקצה רמות הרשאה שונות לאותה קבוצה עבור כל אובייקט ניתן לאבטחה.
6. מדיניות יישום אינטרנט טראמפ מכל זה (ראה להלן).

מנהלי אבטחה לאיבוד בתוך ים של רישומים משתמש וקבוצה תמיד אפשר להסתמך על אלה אקסיומות לנהל ולהבין את תצורת האבטחה שלהם.

מלכודות נפוצות:

• שמות קבוצות לרמוז באופן כוזב הרשאה: מחוץ לקופסה, SharePoint מגדיר סדרה של קבוצות ששמם מרמז על רמה הטבועה של אבטחה. שקול את קבוצת "משתתפים". אחד לא מוכר עם SharePoint אבטחה ייתכן ובכן תסתכל על השם הזה ונניח כי כל חבר בקבוצה זו יכול "לתרום" לספריית בכל אתר/רשימת/בפורטל. יכול להיות שזה נכון, אבל לא בגלל השם של הקבוצה במקרה "משתתפים". הדבר נכון רק מחוץ לקופסה כי הקבוצה סופק רמת הרשאה המאפשרת להם הוספת/עריכת/מחיקת התוכן באתר שורש. דרך ירושה, "התורמים" קבוצה עשוי גם הוספת/עריכת/מחיקת תוכן ב כל אתר משנה. אחד יכול "לשבור" שרשרת הורשה ושינוי רמת ההרשאה של תת אתר כזה כי חברי התורם"כביכול" קבוצה לא יכולה. לתרום בכלל, אבל קריאה בלבד (לדוגמה). זה לא יהיה רעיון טוב, . ברור, מאז זה יהיה מאוד מבלבל.
• קבוצות שאינם מוגדרים ברמת האתר. זה קל להתבלבל באמצעות ממשק המשתמש. Microsoft מספקת קישור נוח לניהול משתמש/קבוצה דרך "אנשים וקבוצות כל אתר" קישור. זה קל להאמין שכאשר אני נמצא באתר "xyzzy" ליצור קבוצה דרך של xyzzy ב האנשים ואת קבוצות לקשר את זה אני פשוט יצר קבוצה שקיים רק ב xyzzy. זה לא המקרה. למעשה יצרתי קבוצה עבור אוסף האתרים כולו.
• הקבוצות החברות אינו משתנה על ידי האתר (כלומר. זה אותו הדבר בכל מקום שהקבוצה משמשת): שקול את קבוצת "בעל" שני אתרים, "HR" ולוגיסטיקה "". יהיה נורמלי לחשוב כי שני אנשים נפרדים יהיו בעלי אתרים אלה — בעלים HR לבין בעל לוגיסטיקה. ממשק המשתמש מקל על מנהל אבטחה mishandle את התרחיש הזה. אם לא הייתי מכיר אותו, אני יכול לגשת הקישורים אנשים וקבוצות דרך האתר HR, בחרו הבעלים"" לקבץ ולהוסיף את הבעלים HR שלי לאותה קבוצה. חודש לאחר מכן, הלוגיסטיקה מגיע על הקו. לגשת אנשים וקבוצות מתוך אתר לוגיסטיקה, להוסיף להעלות. את הבעלים"" קבוצה. פנה לבעלים HR שם ולהסיר אותה, לחשוב כי אני משהה אותה מבעלי האתר לוגיסטיקה. למעשה, . מסירה אותה מהקבוצה בעלי גלובלית. עליצות מתפתח.
• אי-שם קבוצות המבוסס על תפקיד ספציפי: המאשרים"" הקבוצה היא דוגמה מושלמת. מה יכולים בני אשר קבוצה זו? איפה הם יכולים לאשר את זה? אני באמת רוצה אנשים מחלקת הלוגיסטיקה כדי שניתן יהיה לאשר מסמכים HR? . כמובן שלא. תמיד שם קבוצות על בסיס תפקידם בארגון. פעולה זו תקטין את הסיכון כי הקבוצה מוקצית רמת הרשאה לא הולם עבור אובייקט ניתן לאבטחה מסוים. שם קבוצות בהתבסס על תפקידו המיועד. בתרחיש הקודם של HR/לוגיסטיקה, אני צריך יצרתי שתי קבוצות חדשות: "בעלי HR" לוגיסטיקה בעלי "" ולהקצות רמות הרשאה הגיונית עבור כל אחד, הסכום המינימלי הנדרש עבור אותם משתמשים לעשות את העבודה שלהם.

הפניות שימושיות אחרות:

• תפסתי אותך אינטרנט יישום מדיניות: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!255.entry
• מסלקת עבור SharePoint אבטחה: http://www.sharepointsecurity.com/
• קישורים מאתרים ג'ואל אולסן: http://blogs.msdn.com/joelo/archive/2007/08/23/sharepoint-security-and-compliance-resources.aspx

אם כבר הגעת רחוק:

. בבקשה תן לי יודע את המחשבות שלך באמצעות ההערות או לשלוח לי אימייל.. אם אתה יודע אחרת המלצות טובות, בבקשה לעשות את אותו הדבר!