
lusrmgr.msc פותח את ניהול המשתמשים והקבוצות המקומיות.הטקסט המלא של הדקות הראשונות בהרצאה «שרת RMS - זכויות דיגיטליות» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם, היום אנחנו בהרצאת וידאו הזו נלמד על RMS, Right Management Services, 2008. אני עידו שדדי ובואו נתחיל.
אז מה זה בכלל ה-RMS? בואו נכיר קצת את הכלי הזה. RMS, Right Management Service, הינו מנגנון הנועד בבסיסו להגנה על תוכן ואכיפת הרשאות על מידע, גם כאשר מידע זה עוזב את גבולות האבטחה של החברה.
ובכן, מילים יפות, אבל מה זה אומר בפועל? אתם צריכים להבין, חברים, כשאנחנו ניגשים למידע בחברה שלנו כמו קובץ, תיקייה, מדפסת, יש הרשאות למי מותר לעשות שימוש בקובץ, למי מותר לכתוב, לשנות, למחוק.
כל זה נחמד וטוב כל עוד אתם נמצאים בתוך גבול החברה שלכם. אבל מה קורה אם אתם עשיתם העתק לקובץ? כידוע, אם אתם נותנים גישת הרשאה ל-read, משתמש יכול להדפיס את הקובץ ואפילו להעתיק אותו.
אז נניח ונתתם קריאה בלבד לקובץ, המשתמש בה העתיק את הקובץ אליו למחשב ולקח את המחשב הביתה, את הלפטופ של החברה. כידוע לכם, הקובץ שהמשתמש העתיק כרגע הינו קובץ חדש לגמרי, יש לו סיד משלו.
המשתמש יכול לשנות ולעשות מה שהוא רוצה. אז בפועל, לכאורה מה שקרה, המשתמש לקח מידע החוצה, למרות שרצינו קריאה בלבד. עכשיו, צריך להבין משהו מאוד מהותי לגבי המנגנון הזה.
במידה שהמידע מאוד מסווג ואתם לא רוצים שהמידע הזה יצא החוצה, שמשתמשים ועדיין יוכלו לעבוד עם המידע, אתם בבעיה מאוד רצינית, כי מצד אחד יש להם רידז, יש להם קופי, שזה מאוד בעייתי.
אז מה שאנחנו בעצם רוצים להשיג, מה שמייקרוסופט רצה להשיג ולתת מענה, זה בעצם היכולת לשלוט בהרשאות גם כשמדובר במחשבים פרטיים של אנשים.
מישהו שלח עכשיו קובץ במייל למשתמש בכלל בהודו, ועדיין אנחנו רוצים שההרשאות של החברה יתפסו. MS מספק יכולת אכיפה מוגברת הכוללת הרשאות שלא היו מוכרות וקיימות עד כה המהוות תוספת משמעותית לאבטחת המידע.
לדוגמה, אם ניכנס ל-ACL של קובץ AccessList נוכל לראות read/write וכן הלאה, אבל לא נראה למשל פרינט לצורך העניין, ולא נראה לדוגמה משתמש שיכול לקרוא את המסמך הזה לשבוע בלבד.
אם יש לך read אתה יכול להדפיס, אז פה אפשר להגיד דבר מאוד מאוד מהותי יש לך read אין לך קופי יש לך read אין לך הדפסה. אתה עכשיו רוצה לשנות את המסמך, את התוכן הפנימי שלו?
אתה לא יכול. אתה יכול רק לקרוא וזהו, ולא רק זה, אתה יכול לקרוא רק למשך זמן מסוים. לדוגמה, אני בא ואומר עכשיו, לאלי לדוגמה יש זכות קריאה למסמך הזה וי-און-לי למשך שבוע ימים.
כעבור שבוע ימים הוא לא יוכל לפתוח את המסמך יותר. בכללי, שמירה על הרשאות המידע הקיימות במתחם החברה, כאשר המשתמש לוקח את המידע איתו לסביבה הביתית או לעולם החיצון, זה אומר שולח את זה במייל, לוקח את זה בלייט-אופ הביתה, זה הרעיון של RMS. ליישם הרשאות ולשמור את ההרשאות האלה בכל מקום,
בכל זמן, לא משנה היכן המשתמש נמצא. עכשיו, בטח אתם שואלים את עצמכם בשלב הזה: איך זה יכול להיות? אם אני לא בחברה והקובץ אצלי בבית, מה גורם להרשאות להישמר? הרי אני לא עובד מול מערכת, הקובץ נמצא אצלי במחשב הלוקאלי.
הופכות לחלק מהקובץ עצמו. אז איך זה קורה? מה הסוד מאחורי הטכנולוגיה? כאשר משתמש יוצר תוכן מוגן. עכשיו, כשאני אומר תוכן מוגן, אני מתכוון לתוכן שמוגן עם RMS, ולא כל האפליקציות יודעות לעבוד עם זה.
בעבר, 2003, אופיס לדוגמה ידעה לעבוד. היום זה קצת שונה והוגבל. היום ממליצים לעבוד מאופיס 2007 ומעלה, או כל אפליקציה שהיא מודעת ומוכרת כאפליקציה תומכת RMS. אז כשמשתמש בא וניגש או יוצר תוכן מוגן על ידי תוכנה היודעת לעבוד עם תוכן מסוג זה, אופיס 2007, שרת ה-RMS מנפיק רישיון פרסום, זה אומר,
המשתמש בא ובא להגן על המסמך שלו, עכשיו שהוא כתב, והוא אומר למשתמש x, y, z, למשתמשים האלה, מותר לעשות פעולות כאלו וכאלו. ברגע שהמשתמש החליט למי מותר לעשות מה, הוא בא ולוקח את הרישיון פרסום הזה, והרישיון הזה מוטבע בתוך הקוד של הקובץ עצמו.
כשמשתמש אחר מנסה לבצע קריאה של אותו מסמך שהמשתמש הקודם בא והגן עליו על ידי ה-RMS, הוא פונה לשרת ה-RMS ומבקש ממנו רישיון שימוש, Use License.
כמובן, בהתאם להרשאות המשתמש מה שההגנות שיושמו על המסמך, בא המשתמש לקרוא את המסמך. אם יש לו גישה בכלל פנימה, הוא יקבל גישה בהתאם להרשאות שהמשתמש שפרסם את המסמך נתן לו.
אם המשתמש לא מאופשר גישה כמובן שיהיה לו דיניי אנחנו נניח שהמשתמש הוא מאופשר גישה אבל גישה מוגבלת סביר להניח שזה מה שיקרה ומה שקרה בסופו של דבר הוא קיבל use license ה-use license הזה הוגדר למשתמש בהתאם להגנות שיושמו על המסמך וברגע שזה קרה ההגדרות האלה מוחלות על המסמך הזה לצמיתות עבור המשתמש
מפה והלאה המשתמש לא יצטרך יותר לפנות לשרת כדי לקבל את ההרשאות מה מותר לו ומה אסור לו אבל נוכל לראות שאם למשתמש ספציפי אין מספיק הרשאות מתאימות לטובת איזו פעולה שהוא רוצה לבצע הוא תמיד יוכל לבקש הרשאות נוספות אם יותר לו או לא זה כבר עניין אחר לגמרי אוקיי עכשיו נניח במשתמש בא ואומר תקשיב המשתמש שיגן את שיצר את המסמך בא ואומר אני רוצה שכל פעם שמישהו עכשיו רוצה לגשת למסמך
הזה צריך לפנות אונליין לשרת ה rms ולבקש אישור מחדש אפשר לעשות את זה אבל זה לא מומלץ כי זה יגרום למצב שהמשתמשים חייבים לעבוד בצורה מקוונת זאת אומרת אונליין מול שרת ה-RMS בכל פעם שהם רוצים לעבוד על התוכן.
אם השרת למטה או שמשתמש להם גישה לתקשורת כדי להגיע לשרת הוא לא יכול לעבוד על המידע וזה באמת חבל אבל תדעו שזה אפשרי. עכשיו אני רוצה רק להרחיב משהו לגבי הנושא ולחדד פה משהו לגבי כל ה-issue הזה.
מאחורי הקלעים בפועל לפני בכלל שמונפק Publish License או Use License יש איזה תהליך שנקרא נתינה של תעודות דיגיטליות.
מספר תעודות דיגיטליות שמסתתרות פה מאחורי הקלעים בתהליך הזה. כשמשתמש מתחבר פעם ראשונה לתוכן מוגן, הוא פונה לשרת ה-RMS, וברגע שהוא פונה לשרת ה-RMS, שרת ה-RMS מנפיקה לו תעודה דיגיטלית שנקראת RAC. הרק הזה, בהתאם להצהרה של המשתמש, כלומר, אומר אני כרגע עובד ממחשב פרטי שלי,
או לחלופין אני עובד כרגע ממחשב ציבורי או ממחשב שאני לא מתכוון להמשיך לעבוד עליו בעתיד. אז אותו הר"ק ששרת ה-RMS מעניק לקליינט מתקבע בשתי צורות שונות.
אם המחשב הוא מחשב של היוזר הזה, מחשב קבוע שלו בהתאם להצהרת המשתמש, הר"ק מקבע את המשתמש והמחשב יחד ונותן למשתמש רק של 365 ימים, זאת אומרת שנה.
אבל אם המשתמש מצהיר שהוא עובד על מחשב ציבורי או לא מחשב שלו, הוא מקבל רק זמני שכוחו יפה by default ל-15 דקות.
אחרי שהמשתמש קיבל את הר"ק, הוא בא ופונה ברגע שהוא פותח אפליקציה שיודעת לעבוד עם תוכן מוגן, הוא בא ומקבל דבר שנקרא עוד תעודה בשם CLC.
ה-CLC הזה בסופו של דבר ייתן לנו את היכולת לקבל את ה-Published License או בסופו של דבר את ה-Used License. כרגע אני מתייחס ל-Published License.
ברגע שמשתמש קיבל את ה-CLC, זה נקרא Client Licenser Certificate, הוא יכול כרגע לבוא ולעבוד עם תוכן שהוא מוגן. כמובן, אם הוא ירצה ליצור תוכן הוא יעבוד עם Published License.
ואם הוא ירצה לפנות לתוכן הוא יצטרך לבקש use license רישיון שימוש. עכשיו חשוב לציין שאם הרק התעודה הראשונה שהמשתמש קיבל נפסלת עושים לה ריווק זאת אומרת מישהו עכשיו סיכן את התעודה קרה איזה שהיא התרחשה תקלת אבטחה צריך לפסול את התעודה מי שלא יודע מה זה לפסול תעודה שיראה בבקשת הסרטים על תעודות דיגיטליות של מר יונתן רבזין
ברגע שהרק נפסל גם הCLC מאבד את כוחו גם הוא נפסל באופן אוטומטי אז בכללי כמו שאמרתי כאשר משתמש יוצר תוכן מוגן על ידי תוכנה היודעת לעבוד עם תוכן מסוג Office 2007, שרת ה-RMS עצמו מנפיק לו את רישיון הפרסום Published License, הכולל בתוכו את שלל ההרשאות שהמשתמש ציין ואומר למי מותר לעשות מה על המסמך שאני בא וכותב עכשיו,
ומטביע את רישיון השימוש הזה בקובץ. כאשר המשתמש האחר מנסה לגשת למידע בפעם הראשונה, על ידי אפליקציה היודעת לעבוד עם תוכן זה, כמובן הוא צריך לעבור עימות, מתבצעת פנייה לשרת הרמס לטובת בקשת רישיון שימוש.
שרת הרמס מנפיק את רישיון השימוש, ה-Use License, למשתמש בהתאם להגנות שיושמו על המסמך על ידי אותו משתמש שיצר אותו. הוא מכיל אותן על המסמך לצמיתות עבור המשתמש, ללא צורך בפנייה עתידית לשרת.
כשהבנו את זה אפשר להתקדם הלאה. לפני שנתקין את שרת הרמס שלנו אנחנו נעשה כמה הכנות. כמובן ההכנות שאני בא וציינתי פה הן הכנות לסביבת מעבדה.
בסביבה אמיתית אם תעבדו עם שרת sql אנחנו לא נשתמש במסד נתונים פנימי כמו שאנחנו נראה אז נצטרך לעשות עוד כמה הכנות ונוכל להקים קבוצות ניהול אני די צמצמתי את זה לסביבת מעבדה by default זה לא צומצם בהרבה אבל זה בהחלט דברים שגם בסביבה פרודקטיבית אם תעשו זה גם יעבוד והכל יהיה תקין אבל הכל תלוי בתרחיש כמובן אם אתם רוצים יותר משרת אחד במערך של rms אתם תצטרכו לעשות עוד הכנות נוספות אוקיי
אז בואו באמת נראה מה צריך לעשות קודם כל אנחנו צריכים לפחות דומיין קונטרולר אחד שהוא מינימום 2000 Service Pack 3 שערת 2000 Service Pack 3 עד שערת 2008 ומעלה וכן הלאה גם R2 עובד אני אשתמש בהדגמה הזאת בשערת R2 אנחנו נצטרך ליצור חשבון שירות זה אומר Service Account שאיתו יעבוד ה-RMS נצרף אותו לאדמיניסטרטורים מקומיים במחשב במערכת
שמכילה את שערת ה-RMS ניצור חשבון מנהל לטובת ההתקנה והניהול של ה-RMS, הוא יהיה חבר ב-Enderprise Admin לטובת ההתקנה בלבד.
נצהיר על שירות ה-RMS שלנו ברשומת DNS מסוג CNAME. נקנפג בסביבה אמיתית, אם זה פרודקטיבי אתם תצטרכו לבקש סאן סרטיפיקט או תעודה בעלת שתי ערכים, זה אומר גם שם DNSי וגם URL. ניצור משתמשים וקבוצות בעלי כתובות דואר אלקטרוני, מכיוון שה-RMS מתבסס בצורה חזקה מאוד על כתובות דואר,
חייב שלכל מי שרוצה לעבוד עם שרת ה-RMS הזה תהיה כתובת דואר אלקטרוני. עמדות הקצה שלנו שיעבדו מול השרת הזה חייבות להיות מינימום XP Service Pack 2 ומעלה פלוס התוסף של ה-RMS Client.
אני ממליץ לעבוד עם Vista ומעלה, זאת אומרת Windows 7. By default כל הרכיבים נמצאים שם. אוקיי, אז אנחנו נתקדם כבר לשלב הבא של ההתקנה שלנו ונראה באמת איך הדברים עובדים.
לטובת ההתקמה הזאתי אני הרמתי כאן שלושה שרתים, שרת dc 2008 r2 שרת rms שרת חבר 2008 r2 גמור ולקוח קליינט עמדת קליינט מסוג windows 7 ואנחנו נתחיל את ההכנות כמובן בשרת הdc שלנו כמו שאמרנו סוויץ' עברנו למסך מלא הרבה יותר נוח לעבוד ככה אוקיי ראשית בואו
ניצור לנו באמת את הקבוצות הרלוונטיות ואת המשתמשים הרלוונטיים אני אגש פה לפרקטיקיו לאב אני גם מגדיל פה את התצוגה פרקטיקיו לאב אני מטעמי נוחות אצור לי או-יו חדש אני אקרא לו rms לטובת ההקדמה בתוך הרמס אני אצור לי כאן עוד או-יו אני אקרא לה rms-accounts האמת זה ספיק בינתיים ניצור את המשתמשים הרגילים
ביוזר אוקיי ב-rms-accounts אני אצור לי כאן שתי קבוצות לצורך העניין אני אצור לי כאן גרופ אני אקרא לזה לדוגמה itadvins שם בשביל הכיף שלי בנוסף אני אצור לי כאן עוד קבוצה ואני אקרא לה workers כמובן חבר'ה השמות לא משנים בכלל גם המיקום לא משנה, אני מתאר מן נוחות בא ועושה את זה בצורה הזאת. אין שום חשיבות לשמות או
למיקום של הקבוצות. בי דיפולט, בדרך כלל, מה שיקרה, אנחנו ניצור גם קבוצות ניהול לטובת ה-RMS בסביבה אמיתית. אוקיי, עכשיו, חבר'ה, יש לנו שתי קבוצות.
אני גם אצור לי כאן מספר משתמשים. המשתמש הזה הוא כן קריטי, הוא כן חשוב. זה בעצם יהיה משתמש ה-Service Account שלנו. אני אקרא לזה עכשיו RMS Service. חשבון השירות נקסט אני אתן לו סיסמה מכיוון שהוא חשבון שירות אנחנו נעשה לו סיסמה שאף פעם לא פג לה תוקף אמנם זה לא חובה אבל מומלץ לכל חשבונות השירות כבסט פרקטיס ואני אצור לי גם פה חשבון נוסף יוזר נוסף
בשם rms admin הופה הייתה לי פה איזושהי פיצונת אבל לא נורא בוא נטפל בזה יוזר rms admin מצוין אני אגש ליוזר לוגון שלו בוא ניתן לו גם יוזר לוגון פשוט יחסית לא צריך לסבך פה דברים