שרת קבצים עם רפליקציה - DFS << קורס אונליין חינם
Menu
עברית Русский Srbija العربية
מכללת פרקטיקיו
קורסים אונליין בעברית
עם הסרטונים שלנו פשוט להיות מקצוען

שרת קבצים עם רפליקציה - DFS

קורסים למנהלי רשת מנהל רשת מוסמך מיקרוסופט - טכנאי מחשבים ושרתים התמחות בווירטואליזציה מומחה בתקשורת מוסמך סיסקו מומחה לינוקס, ענן ו-DevOps האקינג - סייבר התקפי התמחות באבטחת מידע - סייבר הגנתי שרתי מיקרוסופט נוספים לארגונים גדולים - Exchange - SCCM התמחות במסדי נתונים - SQL התמחות ב-Storage קורסים נוספים למנהלי רשת
קורסי תכנות מפתח תוכנות לוונדוס - WinForms מפתח Front End - בניית אתרי אינטרנט ותכנות בתוך דפדפן מפתח Back End - תכנות ובניית אתרי אינטרנט בצד שרת מפתח אפליקציות לאנדרואיד מפתח אפליקציות לאייפון מפתח משחקים קורס DBA - התמחות במסדי נתונים – SQL קורסים מתקדמים בתכנות בדיקות תוכנה - QA




בס"ד


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

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

וזהו רק קצה הקרחון...

שרתי 2008 מציעים לנו מנגנון שיתוף חכם ופשוט המאפשר גישה וזמינות נתונים גובהה וכמובן גישה מקומית.
תארו לכם שבמקום שמשתמש יקיש את שם המחשב והתיקייה יוכל המשתמש להקיש את שם החברה והמחלקה ובכך לפשט את הגישה בצורה משמעותית לדוגמה:
במקום ido-pc-75itdocs המשתמש יקיש idosoft.comIT ויקבל גישה לכלל התיקיות השייכות למחלקה זו (כמובן בכפוף להרשאות).

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

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

אז איך גורמים לקסם הזה להתרחש... פשוט מאוד:

הדבר הראשון שיהיה עלינו לבצע הוא התקנת התפקידים הדרושים לטובת המערך ניגש ל-SERVER MANAGER ונבחר ADD ROLE
• מתוך רשימת התפקידים נבצע בחירה של תפקיד שרותי הקבצים file services
• בחלון ה- Role services נסמן – Distributed file system
• נגדיר שם למרחב השמי שלנו בהתאם לתפקיד שלו ישמש, לדוגמה: IT
• בבחירת סוג המרחב השמי נוכל לבחור האם מדובר במרחב שמי הנמצא בתוך דומיין או לחלופין חיצוני (מומלץ לבחור מרחב שמי המשוייך לדומיין במידה ואפשר).
• בחלון הגדרת המרחב השמי נקיש הבא ולא נגדיר תיקיות המשוייכות למרחב זה אלא נבצע זאת בצורה ידנית לאחר מכן.
לאחר סיום התהליך נבצע את התהליך על כלל השרתים האחרים שיקחו חלק במערך השיתוף החכם אך לא ניצור מרחב שמי חדש אלא נצטרף למרחב קיים על שימוש בכפתור האופציה – Create name space latter.
בשרת הראשי ניגש לכלי הניהול דרך תפריט ההתחל ונבחר – DFS MANAGEMENT

נוכל לראות כי תחת NAME SPACES המרחב השמי IT" " מופיע.

כל שנותר הוא לשייך תיקיות ומידע למרחב שמי זה, בכדי לעשות זאת בצורה חכמה:
• ניגש לכלי הניהול ונבחר – Share and management storage .
• תחת Action נבחר את אופציית ה- provision share
• נבחר מיקום ושם לתיקייה שאותה נרצה לצרף למערך השיתוף החכם לדוגמה: ITdocuments" "
• בחלון הבא נוכל להגדיר את הגדרות ה-NTFS לתיקיית השיתוף ממש כמו שהיינו עושים במידה והינו עושים שיתוף רגיל.
• בחלון ה-SHARE PROTOCOLS נבחר את פרוטוקול השיתוף SMB למיקרוסופט (פרוטוקול ה-NFS נועד למערכות UNIX ובכי לאפשרו יש להתקין את תת התפקיד NFS).
• בחלון ה-SMB SETTINGS נוכל להגדיר הגדרות שיתוף מתקדמות כגון שיתוף לא מקוון או הגבלת מספר המשתמשים היכולים לגשת במקביל לשיתוף זה.
• תחת חלון הרשאות השיתוף – SMB PERMISSIONS נגדיר את הרשאות השיתוף ממש כמו שהינו עושים אם היינו משתפים תיקייה בצורה רגילה.
• החלון הבא שיופיע הינו החלון החשוב ביותר מיכוון שעד שלב זה היינו יכולים פשוט ליצור תיקיית שיתוף רגילה לגמרי מבלי לעשות שימוש בכל האשף ולצרפה בצורה ידנית למרחב השמי. בחלון זה חלון ה- DFS NAMESPACE PUBLISHING נוכל להגדיר האם תיקייה זו תשוייך למרחב שמי, כמובן שנרצה בכך, נסמן את תיבת הסימון ונבחר את המרחב השמי הרצוי ונעניק שם ייצוגי שוב- ITdocuments" (מטעמי נוחות בלבד).
• לאחר סיום התהליך ניגש חזרה לכלי ה- DFS ונוכל לראות (לאחר רענון שהתיקייה הופיעה תחת המרחב השמי).

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

• בכדי לצרף שרתים שונים למרחב שמי זה ניגש ל- NAMESPACES ונבחר את המרחב הרצוי.
• נקיש על הלחצן הימני ונבחר - add namespace server.
• נבחר את השרת הרצוי ונאשר במידה והתהליך נכשל בידקו שאכן ה- SERVICE פעיל בשרת שאותו ברצונכם לצרף. (התהליך יכול להתבצע משני הכיוונים).
• תחת הגדרות ה-NAMESPACES נבחר את כרטיסיית ה- NAMESPACE SERVERS ונבדוק שאכן השרתים הרצויים מופיעים.
לאחר ששלב זה הסתיים בהצלחה יהיה עלינו ליצור תיקיות מטרה שיזרימו ויעתיקו נתונים מ- ITdocuments:

• את שלב זה ניתן לבצע על ידי חזרה על שלב יצירת השיתוף שבצענו קודם אך ללא צירוף למרחב שמי או לחלופין יצירה ידנית וסטנדרטית של תיקיות שיתוף בשרתים השונים (המלצה יש ליצור תיקיות בעלות שם זהה מטעמי ארגון וסדר).
• לאחר יצירת התיקיות כל שיהיה עלינו לעשות הוא לגשת ל- ITdocuments תחת המרחב השמי ועל ידי הלחצן הימני לבצע בחירה של – ADD folder target .
• נבחר את השרת הרצוי ואת תקיית השיתוף שיצרנו בו ונאשר את התהליך.
• מיד בסיום התהליך יפתח לפנינו אשף הגדרת הרפליקציה ונתבקש להזין שם לטובת קבוצת רפליקציה זו (השאירו את הנתונים ללא שינוי – המלצה) .
• בחלון ה-PRIMARY MEMBER נבחר את השרת הרצוי – השרת הראשי.
• לאחר מכן נבצע בחירה של טופולוגית הרפליקציה
• נוכל להגדיר סנכרון מלא או מותאם אישית ואף לשלוט בזמני הרפליקציה עד רמת היום והשעה כמו כן נוכל לשלוט בצורה מלאה בכמות רוחב הפס שתוקצה לכך.
• לאחר סיום התהליך נוכל להקיש על ITdocuments ולצפות בכלל התיקיות המזרימות אליה מידע ומהוות מקור הזנה למרחב זה.
• כעת כל משתמש בארגון שלו ניתנה הרשאה אשר יקיש :
• ido.localIT
יגיע בצורה ישירה למרחב השמי המכיל את כל המידע הדרוש למחלקה זו, חשוב לציין שביכולתינו להקים תיקיות נוספות ומרחבי שם נוספים בהתאם למחלקות הקיימות בחברה, כמובן שההמלצה הרווחת היא לבצע מיפוי כונן לכל מרחב שמי אך הדבר אינו מחייב.

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

מאמר זה נכתב על ידי מר. עידו שדדי מרצה במכללת PRACTICU





בס"ד




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


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

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

באם יאבד המשתמש שהצפין את המידע את מפתחות ההצפנה גם אותו המשתמש לא יוכל לגשת למידע זה ובהחלט יהיה ניתן להגיד שמידע זה מוגדר כאבוד!

*מסיבה זו בדיוק נובעת האזהרה המופיעה בעת איפוס ססמה למשתמש.

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

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

רק תארו לעצמכם מה היה עלול להתרחש במצב מסוג זה...

בכדי למנוע זאת חברת מיקרוסופט סיפקה לנו את מנגנון ה- "Data Recovery Agent- DRA" שכל תפקידו הוא לספק לנו רשת אבטחה בדיוק למצבים מסוג זה.

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

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

בכדי ליצור – DRA נבצע את הפעולות הבאות:

• דרך קונסולת ה- Server manager נבצע את הוספת תפקיד ה- Active directory CS

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

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

• נצרף את חשבון זה לקבוצות Domain Admins על ידי כניסה למאפייני המשתמש ולחיצה על שדה ה- Member Of, נקיש על Add ונבצע את הצרוף לקבוצה.

• לאחר סיום התהליך נבצע התחברות מקומית למערכת עם חשבון ה-DRA .

• ניגש לקונסולת ה- Server manager ומשם ל- Features .

• נבחר את כלי ה- Group Policy וניגש לפוליסת הדומיין (ניתן גם ליצור פוליסה חדשה לגמרי ברמת דומיין).

• על ידי הקשה על הלחצן הימני נבחר Edit.

• לפנינו תפתח קונסולת ה- GPME.

ניגש ונבצע ניווט והגדרה של שתי הפוליסות הבאות:

• Computer configuration – Polices – windows settings – security – Public key polices – Certificate Service client auto-enrollment.

• נקיש על הפוליסה ונגדירה כפעילה - Enable

נבחר את האופציה הבאה:

• Computer configuration – Polices – windows settings – security – Public key polices – encrypting file system.

• על ידי הקשה על הלחצן הימני בעכבר נבחר את אפשרות ה- Create data recovery agent.

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

נסגור את הקונסולה והנה סיימנו.

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

מספר הערות חשובות:

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




מאמר זה נכתב על ידי מר. עידו שדדי מרצה במכללת PRACTICU.




סקר שוק נכון לתאריך – 01/09/2011