במסמך הזה מפורטות הדרישות שצריך לקחת בחשבון כשפורסים את Active Directory ב- Google Cloud , והוא עוזר לבחור את הארכיטקטורה המתאימה.
אם מאחדים את Active Directory עם Cloud Identity או Google Workspace (ראו דפוסים לאימות משתמשים בכוח העבודה בסביבה היברידית), אפשר לאפשר למשתמשים מהדומיינים הקיימים של Active Directory לעבור אימות ולגשת למשאבים ב- Google Cloud. אפשר גם לפרוס את Active Directory ב- Google Cloud אם אתם מתכננים להשתמש ב-Active Directory כדי לנהל שרתי Windows ב- Google Cloud או אם אתם מסתמכים על פרוטוקולים שלא נתמכים על ידי Google Cloud.
לפני שמפעילים את Active Directory ב- Google Cloud, צריך להחליט באיזו ארכיטקטורת דומיין ויער להשתמש ואיך לשלב אותה עם יער Active Directory הקיים.
בדיקת הדרישות
Active Directory תומך במגוון ארכיטקטורות של דומיינים ויערות. בסביבה היברידית, אפשרות אחת היא להרחיב דומיין יחיד של Active Directory למספר סביבות. אפשר גם להשתמש בדומיינים או ביערות נפרדים ולקשר ביניהם באמצעות יחסי אמון. הארכיטקטורה הכי טובה תלויה בדרישות שלכם.
כדי לבחור את הארכיטקטורה הטובה ביותר, כדאי לבדוק את הגורמים הבאים:
- התאמה לאזורי אבטחה קיימים
- אינטראקציה בין משאבים מקומיים לבין משאבים של Google Cloud
- עצמאות אדמיניסטרטיבית
- זמינות
בקטעים הבאים נדון בגורמים האלה.
התאמה לאזורי אבטחה קיימים
מתחילים בסקירת העיצוב של הרשת המקומית.
בסביבה המקומית שלכם, יכול להיות שפילחתם את הרשת לאזורי אבטחה מרובים – למשל, באמצעות רשתות VLAN או רשתות משנה נפרדות. ברשת שמפולחת לאזורי אבטחה, התקשורת בתוך אזור אבטחה היא בלתי מוגבלת או כפופה רק למדיניות קלה של חומת אש וביקורת. לעומת זאת, כל תקשורת בין אזורי אבטחה כפופה למדיניות קפדנית של חומת אש, ביקורת או בדיקת תנועה.
הכוונה של אזורי אבטחה היא רחבה יותר מאשר רק הגבלה ובדיקה של תקשורת ברשת – אזורי אבטחה צריכים להטמיע גבולות של אמון.
גבולות אמון
כל מכונה ברשת מפעילה כמה תהליכים. התהליכים האלה יכולים לתקשר זה עם זה באופן מקומי באמצעות תקשורת בין תהליכים, והם יכולים לתקשר בין מכונות באמצעות פרוטוקולים כמו HTTP. במערכת התקשורת הזו, עמיתים לא תמיד סומכים אחד על השני באותה מידה. לדוגמה, תהליכים עשויים לתת אמון רב יותר בתהליכים שפועלים באותה מכונה מאשר בתהליכים שפועלים במכונות אחרות. יכול להיות שחלק מהמכונות ייחשבו למהימנות יותר מאחרות.
גבולות אמון מאפשרים להבחין בין הצדדים בתקשורת – לתת אמון בקבוצה אחת של צדדים בתקשורת יותר מאשר בקבוצה אחרת של צדדים.
גבולות אמון הם קריטיים כדי לצמצם את ההשפעה של מתקפה. מתקפות מסתיימות לעיתים רחוקות אחרי פריצה למערכת אחת – בין אם המערכת היא תהליך יחיד או מכונה שלמה. במקום זאת, סביר להניח שתוקף ינסה להרחיב את המתקפה למערכות אחרות. מכיוון שמערכות בגבול אמון לא מבחינות ביניהן, קל יותר להפיץ מתקפה בתוך גבול אמון מאשר לתקוף מערכות מעבר לגבול אמון.
אם מערכת בתוך גבול מהימן נפגעה, צריך להניח שכל המערכות האחרות בתוך הגבול המהימן הזה נפגעו גם כן. ההנחה הזו יכולה לעזור לכם לזהות גבולות של אמון או לאמת אם גבול מערכת מסוים הוא גבול של אמון, למשל:
נניח שלתוקף יש את רמת הגישה הגבוהה ביותר למטרה א' (לדוגמה, גישת אדמין או גישת root למכונה או לאפליקציה). אם הם יכולים להשתמש בהרשאות האלה כדי לקבל את אותה רמת גישה ליעד B, אז A ו-B נמצאים, בהגדרה, באותו גבול אמון. אחרת, גבול האמון נמצא בין A ל-B.
הגבלת התקשורת ברשת באמצעות אזורי אבטחה יכולה לעזור בהטמעה של גבולות אמון. עם זאת, כדי שאזור אבטחה יהפוך לגבול אמון אמיתי, עומסי העבודה בכל צד של הגבול צריכים להבחין בין בקשות שמקורן באותו אזור אבטחה לבין בקשות שמקורן באזורי אבטחה שונים – ולבדוק את האחרונות בצורה מדוקדקת יותר.
מודל אפס אמון
מודל אפס האמון הוא מודל הרשת המועדף ב- Google Cloud.
אם יש מערכת אחת שנפרצה בגבול האמון, אפשר להניח שכל המערכות בגבול הזה נפרצו. ההנחה הזו מצביעה על כך שעדיף להשתמש בגבולות אמון קטנים יותר. ככל שגבול האמון קטן יותר, כך פחות מערכות נפרצות והתוקף צריך לעבור יותר גבולות כדי שהמתקפה תתפשט.
מודל אפס האמון לוקח את הרעיון הזה למסקנה הלוגית שלו: כל מכונה ברשת נחשבת לאזור אבטחה ייחודי ולגבול אמון. כל התקשורת בין המכונות נבדקת באותה צורה ועוברת דרך חומת אש, וכל בקשות הרשת נחשבות כבקשות שמקורן לא מהימן.
ברמת הרשת, אפשר להטמיע מודל של אפס אמון באמצעות כללי חומת אש כדי להגביל את התעבורה, ויומני זרימה של VPC ורישום ביומן של כללי חומת אש כדי לנתח את התעבורה. ברמת האפליקציה, צריך לוודא שכל האפליקציות מטפלות באימות, בהרשאה ובביקורת באופן עקבי ומאובטח.
גבולות הרשאות שיתוף ב-Active Directory
בדומיין Active Directory, המחשבים סומכים על בקרי הדומיין שיטפלו באימות ובמתן הרשאות בשמם. אחרי שמשתמש מוכיח את הזהות שלו לאחד מבקרי הדומיין, הוא יכול להתחבר כברירת מחדל לכל המכונות באותו דומיין. כל זכויות הגישה שהמשתמש מקבל מבקר הדומיין (בצורה של הרשאות וחברות בקבוצות) חלות על הרבה מכונות בדומיין.
באמצעות מדיניות קבוצתית, אתם יכולים למנוע ממשתמשים לגשת למכונות מסוימות או להגביל את הזכויות שלהם במכונות מסוימות. אבל אם מכונה נפרצה, תוקף יכול לגנוב סיסמאות, גיבובים של סיסמאות או טוקנים של Kerberos של משתמשים אחרים בדומיין שנכנסו לאותה מכונה. לאחר מכן התוקף יכול להשתמש באישורים האלה כדי להפיץ את המתקפה לדומיינים אחרים ביער.
בהתחשב בגורמים האלה, מומלץ להניח שכל המכונות ביער נמצאות בגבול אבטחה של יחסי אמון.
בהשוואה לגבולות דומיין, שהמטרה שלהם היא לשלוט בשכפול ולהעניק אוטונומיה ניהולית לחלקים שונים בארגון, גבולות יער יכולים לספק בידוד חזק יותר. יערות יכולים לשמש כגבול אמון.
התאמה בין יערות Active Directory ואזורי אבטחה
ההנחה שהיער הוא גבול האמון משפיעה על התכנון של אזורי אבטחה. אם יער משתרע על פני שני אזורי אבטחה, קל יותר לתוקף לעבור את הגבול בין אזורי האבטחה האלה. כתוצאה מכך, שני אזורי האבטחה הופכים למעשה לאזור אחד ויוצרים גבול אמון יחיד.
במודל אפס אמון, כל מכונה ברשת נחשבת לאזור אבטחה נפרד. פריסת Active Directory ברשת כזו פוגעת במושג הזה ומרחיבה את גבולות האבטחה כך שיכללו את כל המכונות ביער Active Directory.
כדי שאזור אבטחה ישמש כגבול מהימנות, צריך לוודא שכל יער Active Directory נמצא באזור האבטחה.
ההשפעה על הרחבת Active Directory אל Google Cloud
כשמתכננים פריסה של Google Cloud שדורשת Active Directory, צריך לבחור בין שתי אפשרויות כדי להתאים את הפריסה לאזורי האבטחה הקיימים:
הרחבת אזור אבטחה קיים ל Google Cloud. אפשר להרחיב אזור אבטחה קיים אחד או יותר אל Google Cloud על ידי הקצאת VPC משותף ב Google Cloud וחיבורו לאזור הקיים באמצעות Cloud VPN או Cloud Interconnect.
משאבים שמוצבים בפריסה מקומית וב- Google Cloud , שמשתפים אזור משותף, יכולים גם לשתף יער Active Directory משותף, כך שאין צורך לפרוס יער נפרד ב- Google Cloud . Google Cloud
לדוגמה, נניח שיש רשת קיימת עם רשת היקפית לפיתוח ורשת היקפית לייצור כאזורי אבטחה, ועם יער Active Directory נפרד בכל אזור אבטחה. אם מרחיבים את אזורי האבטחה ל-Google Cloud, כל הפריסות ב- Google Cloud הן גם חלק מאחד משני אזורי האבטחה האלה, ויכולות להשתמש באותם יערות של Active Directory.
הוספת אזורי אבטחה חדשים. יכול להיות שהרחבת אזור אבטחה לא מתאימה לכם – או כי אתם לא רוצים להרחיב עוד יותר אזור, או כי דרישות האבטחה של אזורי האבטחה הקיימים לא תואמות לדרישות של פריסות Google Cloud. אפשר להתייחס אל Google Cloud כאל אזורי אבטחה נוספים.
לדוגמה, סביבה מקומית שיש לה רשת היקפית, אבל לא מבחינה בין עומסי עבודה של פיתוח וייצור. כדי להפריד בין עומסי העבודה האלה ב- Google Cloud, אפשר ליצור שני VPC משותפים ולראות בהם אזורי אבטחה חדשים. לאחר מכן, פורסים שני יערות נוספים של Active Directory אל Google Cloud, אחד לכל אזור אבטחה. אם צריך, אפשר ליצור יחסי אמון בין יערות כדי לאפשר אימות בין אזורי אבטחה.
אינטראקציה בין משאבים מקומיים לבין משאבים של Google Cloud
הגורם השני שצריך לקחת בחשבון כשמרחיבים את Active Directory אלGoogle Cloud הוא האינטראקציה של משתמשים ומשאבים בין המיקום המקומי לבין Google Cloud. בהתאם לתרחיש השימוש, האינטראקציה הזו יכולה להיות קלה או כבדה.
אינטראקציה קלה
אם המטרה היחידה של השימוש ב-Active Directory ב- Google Cloud היא לנהל קבוצה של שרתי Windows ולאפשר לאדמינים להיכנס לשרתים האלה, רמת האינטראקציה בין הסביבות היא נמוכה:
- קבוצת העובדים שיש להם אינטראקציה עם משאבים ב- Google Cloud מוגבלת לצוות האדמיניסטרציה.
- יכול להיות שאפליקציות שמופעלות ב- Google Cloud לא יבצעו אינטראקציה עם אפליקציות מקומיות בכלל, או שיבצעו אינטראקציה בלי להסתמך על אמצעי אימות של Windows כמו Kerberos ו-NTLM.
בתרחיש קל, אפשר לשלב את הסביבות המקומיות ואת סביבות הענן באחת משתי הדרכים הבאות:Google Cloud
שני יערות נפרדים של Active Directory: אפשר לבודד את שתי הסביבות באמצעות שני יערות נפרדים של Active Directory שלא חולקים יחסי אמון. כדי לאפשר לאדמינים לבצע אימות, אתם צריכים לשמור עבורם קבוצה נפרדת של חשבונות משתמשים ב Google Cloudיער.
שמירה של קבוצה כפולה של חשבונות משתמשים מגדילה את המאמץ הניהולי ויוצרת סיכון לשכוח להשבית חשבונות כשעובדים עוזבים את החברה. גישה טובה יותר היא הקצאת הרשאות אוטומטית לחשבונות האלה.
אם חשבונות המשתמשים ב-Active Directory המקומי שלכם מוקצים על ידי מערכת מידע משאבי אנוש (HRIS), יכול להיות שתוכלו להשתמש במנגנון דומה כדי להקצות ולנהל חשבונות משתמשים ביערGoogle Cloud . לחלופין, אפשר להשתמש בכלים כמו Microsoft Identity Manager כדי לסנכרן חשבונות משתמשים בין סביבות.
שני יערות של Active Directory עם יחסי אמון בין היערות: אם משתמשים בשני יערות של Active Directory ומקשרים ביניהם באמצעות יחסי אמון בין היערות, אפשר להימנע מהצורך לתחזק חשבונות כפולים. האדמינים משתמשים באותו חשבון משתמש כדי לבצע אימות בשתי הסביבות. למרות שאפשר לטעון שרמת הבידוד בין הסביבות חלשה יותר, שימוש ביערות נפרדים מאפשר לשמור על גבולות אמון בין הסביבה המקומית לבין סביבת Google Cloud .
אינטראקציה מתונה
יכול להיות שתרחיש השימוש שלכם מורכב יותר. לדוגמה:
- יכול להיות שמנהלים שנכנסים לשרתי Windows שנפרסו ב-Google Cloud יצטרכו לגשת לשיתופי קבצים שמתארחים בפריסה מקומית.
- יכול להיות שאפליקציות ישתמשו ב-Kerberos או ב-NTLM כדי לבצע אימות ולתקשר בין גבולות הסביבה.
- יכול להיות שתרצו לאפשר לעובדים להשתמש באימות Windows משולב (IWA) כדי לבצע אימות לאפליקציות אינטרנט שפרוסות ב- Google Cloud.
בתרחיש מתון, הפעלה של שני יערות נפרדים של Active Directory עלולה להיות מגבילה מדי: אי אפשר להשתמש ב-Kerberos כדי לבצע אימות בשני היערות, ושימוש ב-NTLM באימות מעבר מחייב לשמור על סנכרון של חשבונות משתמשים וסיסמאות.
במקרה כזה, מומלץ להשתמש בשני יערות של Active Directory עם יחסי אמון בין היערות.
אינטראקציה אינטנסיבית
עומסי עבודה מסוימים, כולל פריסות של תשתית מחשבים וירטואליים (VDI), עשויים לדרוש אינטראקציה רבה בין משאבים מקומיים לבין משאבים שנפרסו ב- Google Cloud. כשמשאבים בסביבות שונות קשורים זה לזה באופן הדוק, יכול להיות שלא יהיה מעשי לשמור על גבולות הרשאות בין הסביבות, והשימוש בשני יערות עם הרשאות בין היערות עלול להיות מגביל מדי.
במקרה כזה, מומלץ להשתמש ביער Active Directory יחיד ולשתף אותו בין הסביבות.
עצמאות אדמיניסטרטיבית
הגורם השלישי שצריך להביא בחשבון כשמרחיבים את Active Directory אלGoogle Cloud הוא אוטונומיה אדמיניסטרטיבית.
אם אתם מתכננים לבזר עומסי עבודה בין תשתית מקומית לבין Google Cloud, יכול להיות שעומסי העבודה שתפעילו ב- Google Cloud יהיו שונים מאוד מעומסי העבודה שתשאירו בתשתית המקומית. יכול להיות שתחליטו שצוותים שונים ינהלו את שתי הסביבות.
כדי להפריד בין האחריות של צוותים שונים, צריך להעניק לכל צוות אוטונומיה ניהולית מסוימת. ב-Active Directory, אפשר להעניק לצוותים את הסמכות לנהל משאבים באמצעות ניהול בהרשאה או באמצעות דומיינים נפרדים.
העברת סמכויות ניהול היא דרך קלה להעביר סמכויות ניהול ולהעניק לצוותים אוטונומיה מסוימת. שימוש בדומיין יחיד יכול גם לעזור לכם לשמור על עקביות בין סביבות וצוותים.
עם זאת, אי אפשר להעביר את כל היכולות האדמיניסטרטיביות, ושיתוף של דומיין יחיד עלול להגדיל את העומס האדמיניסטרטיבי של תיאום בין צוותים. במקרה כזה, מומלץ להשתמש בדומיינים נפרדים.
זמינות
הגורם האחרון שצריך לקחת בחשבון כשמרחיבים את Active Directory אלGoogle Cloud הוא הזמינות. לכל דומיין ביער Active Directory, בקר הדומיין משמש כספק הזהויות של המשתמשים בדומיין הזה.
כשמשתמשים ב-Kerberos לאימות, המשתמש צריך ליצור אינטראקציה עם בקר הדומיין של Active Directory בנקודות שונות:
- אימות ראשוני (קבלת כרטיס למתן הרשאה).
- אימות מחדש תקופתי (רענון של כרטיס שמאפשר גישה).
- אימות באמצעות משאב (קבלת כרטיס שירות).
כדי לבצע את האימות הראשוני ואת האימות מחדש התקופתי, צריך לתקשר רק עם בקר דומיין אחד – בקר דומיין של הדומיין שהמשתמש חבר בו.
כשמבצעים אימות באמצעות משאב, יכול להיות שיהיה צורך באינטראקציה עם כמה בקרי דומיין, בהתאם לדומיין שבו נמצא המשאב:
- אם המשאב נמצא באותו דומיין כמו המשתמש, המשתמש יכול להשתמש באותו בקר דומיין (או בבקר דומיין אחר של אותו דומיין) כדי להשלים את תהליך האימות.
- אם המשאב נמצא בדומיין אחר, אבל יש יחסי אמון ישירים עם הדומיין של המשתמש, המשתמש צריך ליצור אינטראקציה עם לפחות שני בקרי דומיין: אחד בדומיין של המשאב ואחד בדומיין של המשתמש.
- אם המשאב והמשתמש הם חלק מדומיינים שונים ויש רק קשר אמון עקיף בין הדומיינים האלה, כדי שהאימות יצליח צריך ליצור קשר עם בקרי הדומיין של כל דומיין בנתיב האמון.
איתור משתמשים ומשאבים בדומיינים או ביערות שונים של Active Directory יכול להגביל את הזמינות הכוללת. תהליך האימות דורש אינטראקציה עם כמה דומיינים, ולכן הפסקת פעולה בדומיין אחד יכולה להשפיע על הזמינות של משאבים בדומיינים אחרים.
בהתחשב בהשפעה הפוטנציאלית של טופולוגיית Active Directory על הזמינות, מומלץ להתאים את טופולוגיית Active Directory לאסטרטגיה ההיברידית שלכם.
עומסי עבודה מבוזרים
כדי לנצל את היכולות הייחודיות של כל סביבת מחשוב, אפשר להשתמש בגישה היברידית כדי לפזר את עומסי העבודה בין הסביבות האלה. במקרה כזה, עומסי העבודה שפורסים ב- Google Cloud תלויים כנראה בתשתית או באפליקציות אחרות שפועלות בפריסה מקומית, ולכן קישוריות היברידית עם זמינות גבוהה היא דרישה קריטית.
אם פורסים יער או דומיין נפרדים של Active Directory כדי Google Cloud להשתמש ביחסי אמון כדי לחבר אותו ל-Active Directory המקומי, מוסיפים עוד תלות בין Google Cloudלסביבה המקומית. Google Cloud להסתמכות הזו יש השפעה מינימלית על הזמינות.
עומסי עבודה מיותרים
אם אתם משתמשים ב- Google Cloud כדי להבטיח המשכיות עסקית, עומסי העבודה שלכם ב- Google Cloud משקפים חלק מעומסי העבודה בסביבה המקומית שלכם. ההגדרה הזו מאפשרת לסביבה אחת להשתלט על התפקיד של הסביבה השנייה אם מתרחש כשל. לכן צריך לבדוק כל תלות בין הסביבות האלה.
אם אתם פורסים יער או דומיין נפרדים של Active Directory כדי Google Cloud להשתמש ב-trust כדי לחבר אותו ל-Active Directory המקומי, יכול להיות שתיצרו תלות שתפגע במטרה של ההגדרה. אם Active Directory המקומי לא יהיה זמין, יכול להיות שגם כל עומסי העבודה שנפרסו ב-Google Cloud שמסתמכים על אימות חוצה-דומיין או חוצה-יער לא יהיו זמינים.
אם המטרה שלכם היא להבטיח את המשכיות העסקית, אתם יכולים להשתמש ביערות נפרדים של Active Directory בכל סביבה שלא מחוברים זה לזה. אפשרות נוספת היא להרחיב דומיין קיים של Active Directory אל Google Cloud. פריסת בקרי דומיין נוספים ב-Google Cloud ושכפול תוכן הספריות בין הסביבות מבטיחים שהסביבות יפעלו בבידוד.
דפוסי אינטגרציה
אחרי שמעריכים את הדרישות, אפשר להיעזר בעץ ההחלטות הבא כדי לזהות ארכיטקטורה מתאימה של יער ודומיין.
בקטעים הבאים מתואר כל דפוס.
יערות מסונכרנים
בתבנית יערות מסונכרנים, פורסים יער Active Directory נפרד ל- Google Cloud. אתם משתמשים ביער הזה כדי לנהל את כל המשאבים שנפרסו ב- Google Cloud , וגם את חשבונות המשתמשים שנדרשים לניהול המשאבים האלה.
במקום ליצור יחסי אמון בין היער החדש לבין יער קיים מקומי, אתם מסנכרנים חשבונות. אם אתם משתמשים במערכת HRIS כמערכת הראשית לניהול חשבונות משתמשים, אתם יכולים להגדיר את מערכת ה-HRIS כך שתקצה חשבונות משתמשים ביער Active Directory שמארח את Google Cloud. אפשר גם להשתמש בכלים כמו Microsoft Identity Manager כדי לסנכרן חשבונות משתמשים בין סביבות.
כדאי להשתמש בדפוס של יערות מסונכרנים אם מתקיים אחד או יותר מהתנאים הבאים:
- השימוש המיועד שלך ב- Google Cloud מתאים לאחד מדפוסי הפריסה המיותרים, ואתה רוצה להימנע מתלות בזמן ריצה בין הסביבה המקומית שלך לבין Google Cloud.
- אתם רוצים לשמור על גבול אמון בין סביבת Active Directory המקומית לבין סביבת Active Directory שמארחת את Google Cloud– או כאמצעי הגנה לעומק, או כי אתם בוטחים בסביבה אחת יותר מאשר בשנייה.
- אתם מצפים לאינטראקציה מועטה או לאינטראקציה בכלל בין משאבים שמנוהלים על ידי Active Directory במקום לבין משאבים ב- Google Cloud.
- מספר חשבונות המשתמשים שאתם צריכים בסביבת Active Directory שמארחת Google Cloudקטן.
היתרונות:
- התבנית של יערות מסונכרנים מאפשרת לשמור על בידוד חזק בין שני סביבות Active Directory. תוקף שפרץ לסביבה אחת לא יקבל יתרון משמעותי בהתקפה על הסביבה השנייה.
- כדי להפעיל את Active Directory, לא צריך להגדיר קישוריות היברידית בין הרשתות המקומיות ובין רשתות Google Cloud .
- Active Directory שמתארח ב- Google Cloudלא מושפע מהפסקת חשמל ב-Active Directory בארגון. הדפוס הזה מתאים מאוד לתרחישי שימוש של המשכיות עסקית או לתרחישים אחרים שבהם נדרשת זמינות גבוהה.
- אתם יכולים להעניק רמה גבוהה של אוטונומיה אדמיניסטרטיבית לצוותים שמנהלים את יער Active Directory שמתארח ב- Google Cloud.
- התבנית הזו נתמכת על ידי שירות מנוהל ל-Microsoft Active Directory.
שיטות מומלצות:
- לא לסנכרן סיסמאות של חשבונות משתמשים בין שני יערות Active Directory. פעולה כזו פוגעת בבידוד בין הסביבות.
- לא כדאי להסתמך על אימות באמצעות העברה, כי הוא מחייב סנכרון של הסיסמאות של חשבונות המשתמשים.
- חשוב לוודא שכאשר עובד עוזב את החברה, החשבונות שלו בשני סביבות Active Directory מושבתים או מוסרים.
יער משאבים
בתבנית יער המשאבים, פורסים יער Active Directory נפרד כדי Google Cloud. אתם משתמשים ביער הזה כדי לנהל את כל המשאבים שפריסתם ב-Google Cloud , וגם קבוצה מינימלית של חשבונות משתמשים עם הרשאות אדמין שנדרשים לניהול היער. יצירת יחסי אמון בין יערות לבין יער Active Directory קיים מקומי מאפשרת למשתמשים מהיער הקיים לבצע אימות ולגשת למשאבים שמנוהלים על ידי יער Active Directory שמארחGoogle Cloud.
אם צריך, אפשר להפוך את התבנית הזו לטופולוגיה של רכזת וחישורים, עם יער Active Directory הקיים במרכז, שמחובר ליערות רבים של משאבים.
כדאי להשתמש בתבנית של יער משאבים אם אחת מהאפשרויות הבאות מתקיימת:
- השימוש המיועד שלך ב- Google Cloud מתאים לאחד מדפוסי הפריסה המבוזרת, ותלות בין הסביבה המקומית שלך לבין Google Cloudמקובלת.
- אתם רוצים לשמור על גבול אמון בין סביבת Active Directory המקומית לבין סביבת Active Directory שמארחת את Google Cloud—כאמצעי הגנה מקיף או כי אתם רואים בסביבה אחת מהימנה יותר מאשר בסביבה השנייה.
- אתם מצפים לרמת אינטראקציה מתונה בין משאבים שמנוהלים על ידי Active Directory במקום לבין משאבים ב- Google Cloud.
- יש לכם מספר גדול של משתמשים שצריכים לגשת למשאבים שנפרסו ב- Google Cloud– לדוגמה, לאפליקציות אינטרנט שמשתמשות ב-IWA לאימות.
היתרונות:
- הדפוס של יער המשאבים מאפשר לשמור על גבול אמון בין שתי סביבות Active Directory. בהתאם לאופן שבו מוגדר יחס האמון, תוקף שפרץ לסביבה אחת עשוי לקבל גישה מוגבלת מאוד לסביבה השנייה, או לא לקבל גישה בכלל.
- התבנית הזו נתמכת באופן מלא על ידי Managed Microsoft AD.
- אתם יכולים להעניק רמה גבוהה של אוטונומיה אדמיניסטרטיבית לצוותים שמנהלים את יער Active Directory שמתארח ב- Google Cloud.
שיטות מומלצות:
- מחברים בין שני יערות Active Directory באמצעות אמון חד-כיווני, כך ש-Active Directory שמארח את Google Cloudסומך על Active Directory הקיים, אבל לא להפך.
- משתמשים באימות סלקטיבי כדי להגביל את המשאבים ב-Active Directory שמארח Google Cloud, שהמשתמשים מ-Active Directory המקומי יכולים לגשת אליהם.
- כדי להבטיח קישוריות רשת עם זמינות גבוהה בין הרשת המקומית לבין Google Cloud, אפשר להשתמש בחיבורים מיותרים של Dedicated Interconnect, Partner Interconnect או Cloud VPN.
דומיין מורחב
בדפוס extended domain, מרחיבים אחד או יותר מהדומיינים הקיימים של Active Directory ל- Google Cloud. בכל דומיין, אתם פורסים ב- Google Cloudבקר דומיין אחד או יותר, וכתוצאה מכך כל נתוני הדומיין וגם הקטלוג הגלובלי משוכפלים וזמינים ב-Google Cloud. אם משתמשים באתרי Active Directory נפרדים עבור רשתות המשנה המקומיות ורשתות המשנה של Google Cloud , הלקוחות יוכלו לתקשר עם בקרי הדומיין שהכי קרובים אליהם.
כדאי להשתמש בתבנית דומיין מורחבת אם אחת מהאפשרויות הבאות מתקיימת:
- השימוש המיועד שלכם ב- Google Cloud מתאים לאחד מדפוסי הפריסה המיותרים, ואתם רוצים להימנע מתלות בזמן ריצה בין הסביבה המקומית שלכם לבין Google Cloud . Google Cloud
- אתם מצפים לאינטראקציה ענפה בין משאבים שמנוהלים על ידי Active Directory במקום לבין משאבים ב-Google Cloud.
- אתם רוצים לזרז את האימות של אפליקציות שמסתמכות על LDAP לאימות.
היתרונות:
- Active Directory שמתארח ב- Google Cloudלא מושפע מהפסקת חשמל ב-Active Directory בארגון. הדפוס הזה מתאים מאוד לתרחישי שימוש של המשכיות עסקית או לתרחישים אחרים שבהם נדרשת זמינות גבוהה.
- אתם יכולים להגביל את התקשורת בין הרשת המקומית שלכם לביןGoogle Cloud. כך אפשר לחסוך ברוחב הפס ולשפר את זמן האחזור.
- כל התוכן של הקטלוג הגלובלי משוכפל ל-Active Directory, ואפשר לגשת אליו ביעילות ממשאבים שמארחים ב- Google Cloud.
שיטות מומלצות:
- אם משכפלים את כל הדומיינים, התקשורת בין הרשת המקומית לבין רשת Google Cloud מוגבלת לשכפול של Active Directory בין בקרי הדומיין. אם משכפלים רק קבוצת משנה של הדומיינים ביער, יכול להיות ששרתים שמצורפים לדומיין ופועלים ב-Google Cloud עדיין יצטרכו לתקשר עם בקרי דומיין של דומיינים שלא שוכפלו. צריך לוודא שכללי חומת האש שחלים על התקשורת בין המערכות המקומיות לבין Google Cloud מתייחסים לכל המקרים הרלוונטיים.
- חשוב לדעת שהשכפול בין אתרים מתבצע רק במרווחי זמן מסוימים, ולכן עדכונים שמבוצעים בבקר דומיין מקומי מופיעים ב-Google Cloud רק אחרי עיכוב (ולהפך).
- אפשר להשתמש בבקרי דומיין לקריאה בלבד (RODC) כדי לשמור עותק לקריאה בלבד של נתוני הדומיין ב- Google Cloud, אבל צריך לזכור שיש לכך השלכות על שמירת סיסמאות המשתמשים במטמון. אם מאפשרים ל-RODC לשמור סיסמאות במטמון ולאכלס מראש את מטמון הסיסמאות, משאבים שנפרסו ב- Google Cloud לא יושפעו מהפסקת חשמל של בקרי דומיין מקומיים. עם זאת, היתרונות של שימוש ב-RODC על פני בקר דומיין רגיל מבחינת אבטחה הם מוגבלים. אם משביתים את השמירה במטמון של הסיסמאות, יכול להיות שבקר RODC שנפרץ יציב סיכון מוגבל בלבד לשאר Active Directory, אבל מאבדים את היתרון שלGoogle Cloud שלא מושפע מהשבתה של בקרי דומיין מקומיים.
יער רחב
בתבנית extended forest, אתם פורסים דומיין חדש של Active Directory ב-Google Cloud, אבל משלבים אותו ביער הקיים. אתם משתמשים בדומיין החדש כדי לנהל את כל המשאבים שנפרסו ב- Google Cloud וכדי לשמור על קבוצה מינימלית של חשבונות משתמשים עם הרשאת אדמין לניהול הדומיין.
כשמרחיבים את יחסי האמון המרומזים לדומיינים אחרים ביער, מאפשרים למשתמשים קיימים מדומיינים אחרים לעבור אימות ולגשת למשאבים שמנוהלים על ידי דומיין Active Directory שמארח את Google Cloud.
כדאי להשתמש בתבנית של יער מורחב אם אחת מהאפשרויות הבאות מתקיימת:
- השימוש המיועד שלך ב- Google Cloud מתאים לאחד מדפוסי הפריסה המבוזרים, ותלות בין הסביבה המקומית שלך לבין Google Cloud מקובלת.
- המשאבים שאתם מתכננים לפרוס Google Cloud דורשים הגדרה או מבנה שונים של דומיין מאלה שקיימים בדומיינים שלכם, או שאתם רוצים לתת רמה גבוהה של אוטונומיה אדמיניסטרטיבית לצוותים שמנהלים את הדומיין Google Cloudהמתארח.
- אתם מצפים לאינטראקציה בינונית עד כבדה בין משאבים שמנוהלים על ידי Active Directory במקום ובין משאבים ב- Google Cloud.
- יש לכם הרבה משתמשים שצריכים לגשת למשאבים שנפרסו ב- Google Cloud– לדוגמה, לאפליקציות אינטרנט שמשתמשות ב-IWA לאימות.
היתרונות:
- כל התוכן של הקטלוג הגלובלי ישוכפל ל-Active Directory, ותהיה גישה יעילה למשאבים שמארח Google Cloud.
- תעבורת נתונים בזמן שכפול בין הרשת המקומית לביןGoogle Cloud מוגבלת לרפליקציה של הקטלוג הגלובלי. הפעולה הזו עשויה לעזור לכם לצמצם את צריכת רוחב הפס הכוללת.
- אתם יכולים להעניק רמה גבוהה של אוטונומיה אדמיניסטרטיבית לצוותים שמנהלים את דומיין Active Directory שמתארח ב- Google Cloud.
שיטות מומלצות:
- כדי להבטיח קישוריות רשת עם זמינות גבוהה בין הרשת המקומית לבין Google Cloud, אפשר להשתמש בחיבורים מיותרים של Dedicated Interconnect, Partner Interconnect או Cloud VPN.
יער משאבים עם דומיין מורחב
התבנית resource forest with extended domain היא הרחבה של התבנית resource forest. התבנית של יער המשאבים מאפשרת לשמור על גבול אמון בין סביבות ולספק אוטונומיה ניהולית. מגבלה של יער המשאבים היא שהזמינות הכוללת שלו תלויה בזמינות של בקרי דומיין מקומיים ובקישוריות רשת אמינה למרכז הנתונים המקומי.
אפשר לעקוף את המגבלות האלה על ידי שילוב של התבנית של יער המשאבים עם התבנית של דומיין מורחב. העתקת הדומיין מאפשרת למקם את חשבונות המשתמשים ב- Google Cloud, ולוודא שהמשתמשים יוכלו לבצע אימות למשאבים שמארח Google Cloudגם אם בקרי הדומיין המקומיים לא זמינים או אם הקישוריות לרשת אבדה.
כדאי להשתמש ביער המשאבים עם תבנית דומיין מורחבת אם אחת מהאפשרויות הבאות מתקיימת:
- אתם רוצים לשמור על גבול אמון בין יער Active Directory הראשי לבין יער המשאבים.
- אתם רוצים למנוע מצב שבו הפסקת חשמל בבקרי דומיין מקומיים או אובדן של קישוריות לרשת בסביבה המקומית ישפיעו על עומסי העבודה המתארחים ב-Google Cloud.
- אתם מצפים לאינטראקציה מתונה בין משאבים שמנוהלים על ידי Active Directory במקום ובין משאבים ב- Google Cloud.
- יש לכם הרבה משתמשים מדומיין Active Directory יחיד שצריכים לגשת למשאבים שנפרסו ב- Google Cloud– לדוגמה, לאפליקציות אינטרנט שמשתמשות ב-IWA לאימות.
היתרונות:
- משאבים שמתארחים ב-Google Cloudלא מושפעים מהפסקת חשמל ב-Active Directory בארגון. הדפוס מתאים מאוד לתרחישי שימוש של המשכיות עסקית או לתרחישים אחרים שבהם נדרשת זמינות גבוהה.
- התבנית מאפשרת לשמור על גבול מהימנות בין שני יערות Active Directory. בהתאם לאופן שבו מוגדר יחסי האמון, תוקף שפורץ לסביבה אחת עשוי לקבל גישה מוגבלת או לא לקבל גישה לסביבה השנייה.
- התקשורת בין הרשת המקומית שלכם לבין רשת Google Cloudמוגבלת לשכפול של Active Directory בין בקרי דומיין. אפשר להטמיע כללים של חומת אש כדי לאסור את כל התקשורת האחרת, וכך לחזק את הבידוד בין הסביבות.
- אתם יכולים להעניק רמה גבוהה של אוטונומיה אדמיניסטרטיבית לצוותים שמנהלים את יער Active Directory שמארח את Google Cloud.
- אפשר להשתמש ב-שירות מנוהל ל-Microsoft AD עבור יער המשאבים.
שיטות מומלצות:
- כדי להפריד בין הרכיבים האלה לבין הרכיבים של יער המשאבים, צריך לפרוס בקרי דומיין עבור הדומיין המורחב בGoogle Cloud פרויקט VPC נפרד.
- משתמשים בקישור (peering) בין רשתות VPC שכנות כדי לקשר את ה-VPC ל-VPC משותף או ל-VPC שבו נעשה שימוש ביער המשאבים, ומגדירים חומות אש כדי להגביל את התקשורת לאימות משתמשים ב-Kerberos וליצירת יחסי אמון בין יערות.
- מחברים בין שני יערות Active Directory באמצעות אמון חד-כיווני, כך ש-Active Directory באירוח Google Cloudסומך על יער Active Directory הקיים, אבל לא להפך.
- משתמשים באימות סלקטיבי כדי להגביל את המשאבים ביער המשאבים שהמשתמשים מיערות אחרים יכולים לגשת אליהם.
- חשוב לדעת שהשכפול בין אתרים מתבצע רק במרווחי זמן מסוימים, ולכן עדכונים שמבוצעים בבקר דומיין מקומי מופיעים ב-Google Cloud רק אחרי השהיה (ולהפך).
- כדאי להשתמש ב-RODC עבור הדומיין המורחב, אבל חשוב לאפשר שמירת סיסמאות במטמון כדי לשמור על היתרונות של הזמינות בהשוואה לדפוס של יער המשאבים.
המאמרים הבאים
- מידע נוסף על שירות מנוהל ל-Microsoft AD
- שיטות מומלצות לפריסת יער משאבים של Active Directory ב- Google Cloud
- איך פורסים סביבת Active Directory עמידה בכשלים ב- Google Cloud
- מומלץ לעיין בשיטות המומלצות לתכנון VPC.
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.