במדריך הזה מוצגות שיטות מומלצות להפעלת Active Directory ב- Google Cloud. המדריך מתמקד בשיטות עבודה ספציפיות ל- Google Cloud או Google Cloud, או בשיטות עבודה חשובות במיוחד כשפורסים את Active Directory ב- Google Cloud. המדריך הזה הוא תוספת לשיטות המומלצות הכלליות לאבטחת Active Directory שפורסמו על ידי מיקרוסופט.
ארכיטקטורה
בקטעים הבאים מפורטות שיטות מומלצות שקשורות לארכיטקטורה.
שימוש בתבנית הארכיטקטורה שהכי מתאימה לדרישות שלכם
כדי לפרוס את Active Directory ב- Google Cloud, צריך קודם להחליט באיזו ארכיטקטורה של דומיין ויער להשתמש. אם אתם כבר משתמשים ב-Active Directory, אתם צריכים גם להחליט אם ואיך לשלב בין שתי הסביבות.
העיצוב שהכי מתאים למצב שלכם תלוי במספר גורמים, כולל העיצוב של הרשת המקומית, האופן שבו משאבים מקומיים ומשאביGoogle Cloud יעבדו יחד, וגם הדרישות שלכם לגבי זמינות ואוטונומיה אדמיניסטרטיבית. כדי להבין איך הגורמים האלה צריכים להשפיע על התכנון שלכם, מומלץ לעיין בדפוסי השימוש ב-Active Directory בסביבה היברידית.
אם רוצים לשמור על גבול מהימן בין Google Cloud לסביבה המקומית, כדאי להטמיע את התבנית resource forest. בדפוס הזה, אתם פורסים יער נפרד ב- Google Cloud ומשתמשים ביער מהימן חד-כיווני כדי לשלב את יער Google Cloud עם יער Active Directory הקיים שלכם בפריסה מקומית.
הפרדה בין בדיקות לבין סביבת הייצור
בהתאם לשימוש שלכם ב-Active Directory, יכול להיות שיהיה צורך לבצע שינויים תכופים ב-Active Directory במהלך הפיתוח והבדיקה של אפליקציות. יכול להיות שמפתחים יצטרכו ליצור ולשנות חשבונות Active Directory, לשנות את החברות בקבוצות אם האפליקציות משתמשות בקבוצות כדי לטפל בהרשאות, או להוסיף מחשבים ולהסיר אותם.
כדי למנוע השפעה של עבודות פיתוח ובדיקה על עומסי עבודה בייצור או על אבטחת הפריסה, מומלץ לפרוס יער או דומיין נפרדים של Active Directory לפיתוח ולבדיקה.
אם יש לכם דומיין או יער נפרדים לפיתוח ולבדיקות, תוכלו גם לאמת שינויים אדמיניסטרטיביים לפני שתחילים אותם על סביבת הייצור. דוגמאות לשינויים כאלה כוללות ניסויים במדיניות קבוצתית, בדיקות של סקריפטים לאוטומציה או פעולות שעלולות להיות מסוכנות, כמו העלאה של רמת הפונקציונליות של יער.
הגדרת איחוד של Cloud Identity בנוסף לפריסה של Active Directory ב- Google Cloud
פריסת Active Directory ב- Google Cloud מאפשרת לכם לנהל מכונות וירטואליות של Windows ב- Google Cloud, יכולה לאפשר למשתמשים להתחבר למכונות וירטואליות של Windows באמצעות חשבונות המשתמשים הקיימים שלהם, ותומכת באפליקציות שמסתמכות על Kerberos, NTLM או LDAP לאימות.
עם זאת, כדי להשתמש בGoogle Cloud מסוף, בכלי שורת הפקודה gcloud או בכלים אחרים של Google ו- Google Cloud , צריך לבצע אימות באמצעות חשבון Google. לכן, פריסת Active Directory ב- Google Cloud לא מחליפה את הפדרציה של Active Directory הקיים עםGoogle Cloud אם אתם מתכוונים להשתמש ב-Active Directory כמערכת העיקרית לניהול משתמשים.
לדוגמה, אם פורסים יער נפרד ב- Google Cloud, אפשר להגדיר איחוד מול Active Directory המקומי, כמו שמוצג בתרשים הבא. משתמשים עם חשבונות ב-Active Directory מקומי יכולים להשתמש בכלים שדורשים זהות ב-Google, וגם באפליקציות שלכם שמסתמכות על Active Directory לאימות.
אם במקום זאת תחליטו להרחיב את היער הקיים או את הדומיין ל- Google Cloud, תוכלו גם להשתמש בבקרי דומיין ובשרתי AD FS שנפרסו ב- Google Cloud כדי להגדיר את האיחוד.
הפדרציה מאפשרת גם לאכוף מחזור חיים משותף לחשבונות Google ולחשבונות Active Directory, כך שכאשר משביתים חשבון משתמש ב-Active Directory המקומי, גם משתמש Google התואם מושעה.
Networking
בקטע הבא מפורטות שיטות מומלצות שקשורות לרשת.
פריסת Active Directory ברשת VPC משותפת
כדי לאפשר שימוש ב-Active Directory בכמה פרויקטים, צריך לפרוס בקרי דומיין ברשת VPC משותפת. לשימוש ברשת VPC משותפת יש כמה יתרונות:
כל אפליקציה שעשויה לדרוש גישה ל-Active Directory יכולה להיות פרוסה בפרויקט נפרד. שימוש בפרויקטים נפרדים עוזר לבודד משאבים ומאפשר לנהל את הגישה לכל פרויקט בנפרד.
אפשר להשתמש בפרויקט ייעודי לבקרי דומיין של Active Directory, כדי לקבוע בצורה פרטנית לאילו משתמשים תהיה גישה ל Google Cloud משאבים קשורים.
רשתות VPC משותפות מאפשרות לכם לרכז את הניהול של כתובות ה-IP ואת ההגדרה של חומת האש, וכך לוודא שיש עקביות בכמה פרויקטים.
מכיוון ש-VPC הם משאב גלובלי, אפשר להשתמש באותה רשת VPC משותפת בכמה אזורים.
לא לחשוף בקרי דומיין חיצוניים
כדי לצמצם את שטח הפנים של Active Directory, מומלץ להימנע מהקצאת כתובות IP חיצוניות לבקרי דומיין.
למופעי מכונות וירטואליות ללא כתובות IP חיצוניות אין גישה לאינטרנט כברירת מחדל, ולכן צריך לבצע פעולות נוספות כדי לוודא שההפעלה של Windows ועדכוני Windows לא ייפגעו בבקרי הדומיין.
כדי לתמוך בהפעלת Windows, צריך להפעיל את הגישה הפרטית ל-Google ברשת המשנה שבה מתכננים לפרוס את בקרי הדומיין, ולוודא שמופעי מכונות וירטואליות יכולים לגשת אל kms.windows.googlecloud.com. כך אפשר להפעיל את Windows בלי גישה ישירה לאינטרנט.
יש כמה אפשרויות לתמיכה בעדכוני Windows:
אם יש לכם שרת WSUS מקומי, אתם יכולים להגדיר קישוריות היברידית ולהגדיר את בקרי הדומיין כך שישתמשו בשרת WSUS כמקור לעדכונים.
כדי להפעיל גישה לאינטרנט דרך שער NAT, צריך לפרוס Cloud NAT.
אם הגדרתם קישוריות היברידית, אתם יכולים גם לנתב תנועה יוצאת דרך שער NAT מקומי או שרת proxy.
שמירת כתובות IP סטטיות מראש לבקרי דומיין
בקרי הדומיין משמשים כשרתי DNS, ולכן צריך להקצות להם כתובת IP שלא משתנה. כדי לעשות את זה, צריך להגדיר כתובות IP פנימיות סטטיות למכונות הווירטואליות של בקרי הדומיין.
כשמזמינים כתובת IP, ברירת המחדל היא שכתובת לא בשימוש נבחרת באופן אוטומטי. כדי שיהיה קל לזכור את כתובות ה-IP של בקרי הדומיין, שומרים כתובת IP פנימית סטטית.
בבקרי הדומיין, מגדירים את כתובת ה-IP של מתאם הרשת לאותה כתובת. השלב הזה הוא אופציונלי, אבל הוא מונע מ-Active Directory להציג הודעות אזהרה שמציינות שכתובת ה-IP של המחשב עדיין מוקצית באופן דינמי.
פריסת בקרי דומיין בכמה אזורים
כדי לשפר את הזמינות, מומלץ לפרוס לפחות שני בקרי דומיין ולפזר אותם על פני כמה אזורים. מכיוון שתת-רשתות וכתובות IP לא קשורות לאזור, אפשר לפרוס את כל בקרי הדומיין בתת-רשת אחת.
אם אתם מתכננים לפרוס עומסי עבודה בכמה אזורים, כדאי לפרוס בקרי דומיין בכל אזור רלוונטי. מכיוון שתת-רשתות הן משאב אזורי, פריסה באזור נוסף תדרוש תת-רשת נוספת.
יצירת אתר אחד לכל אזור
כשלקוח מנסה לאתר בקר דומיין, הוא יחפש קודם בקר דומיין באתר Active Directory שתואם לכתובת ה-IP של הלקוח. אם אין בשרת הזה בקר דומיין זמין, הלקוח ימשיך וינסה לאתר בקר דומיין באתר אחר.
כדי לנצל את ההתנהגות הזו, אפשר ליצור אתר נפרד לכל אזור שבו פורסים בקרי דומיין או לקוחות דומיין. לאחר מכן, הלקוחות יעדיפו באופן אוטומטי להשתמש בבקרי דומיין שנמצאים באותו אזור, מה שיכול לעזור להפחית את זמן האחזור ואת העלות של העברת נתונים יוצאים בין אזורים.
אם יש לכם לקוחות באזורים שאין בהם בקר דומיין, אתם יכולים להשפיע על בחירת בקר הדומיין של הלקוחות האלה על ידי שינוי העלויות של קישורי האתרים כך שישקפו את הקרבה הגיאוגרפית של האזורים, והפעלת ההגדרה Try Next Closest Site.
השימוש בכמה אתרים משפיע על התנהגות השכפול בין בקרי הדומיין. חיסרון אחד בשימוש בכמה אתרים הוא שהשכפול בין האתרים מתבצע בתדירות נמוכה יותר מאשר שכפול בתוך אתר.
עם זאת, אי אפשר ליצור אתרים של Active Directory בשירות מנוהל ל-Microsoft AD כי הוא לא תומך בתכונה Active Directory Sites and Services.
שימוש באזורי העברה פרטיים ב-Cloud DNS
כשיוצרים מכונת VM חדשה ב-Compute Engine, מערכת ההפעלה מוגדרת מראש לשימוש בשרת DNS שמוגדר כברירת מחדל ומספק גישה ל-DNS פנימי ול-DNS ציבורי.
לפני שמצטרפים למחשב לדומיין של Active Directory, צריך לוודא שהמחשב יכול לפתור את רשומות ה-DNS שמנוהלות על ידי Active Directory. שרת ה-DNS שמוגדר כברירת מחדל ב-Compute Engine עבור מכונת VM מספק גישה ל-DNS פנימי ול-DNS ציבורי, אבל לא יוכל להחזיר את כתובות ה-IP של שמות DNS שמנוהלים על ידי Active Directory.
יוצרים אזור פרטי להעברת DNS ב-Cloud DNS כדי לאפשר ללקוחות לפתור רשומות DNS שמנוהלות על ידי Active Directory. מגדירים את האזור להעברת שאילתות שתואמות לדומיין Active Directory לבקרי הדומיין.
לשימוש באזור העברה פרטי של DNS יש כמה יתרונות על פני הגדרת לקוחות לשימוש ישיר בבקרי הדומיין של Active Directory כשרתי DNS:
אין צורך לשנות את הגדרת הרשת של מכונות וירטואליות. כך התהליך של יצירת מכונות וירטואליות חדשות הופך לפשוט יותר.
כשמקדמים או מורידים את הרמה של בקר דומיין, צריך רק לעדכן את ההגדרה של אזור העברת ה-DNS הפרטי, ולא צריך לשנות הגדרות של לקוחות.
למכונות וירטואליות עדיין יש גישה ל-DNS פנימי.
כל רשומות ה-DNS שלא תואמות לדומיין Active Directory יטופלו על ידי Cloud DNS, וכך העומס על בקרי הדומיין יפחת.
אם אתם משתמשים בכמה דומיינים, אתם צריכים ליצור אזור נפרד להעברת DNS פרטי לכל דומיין של Active Directory.
תחומים פרטיים להעברה ב-Cloud DNS מוגבלים ל-VPC יחיד. אם אתם משתמשים בכמה רשתות VPC שמחוברות באמצעות peering, אתם יכולים לחשוף את אזורי ההעברה הפרטיים לרשתות VPC אחרות על ידי הגדרת DNS peering.
עדיין צריך להגדיר ידנית את הגדרות ה-DNS בבקרי הדומיין. משתמשים ב-127.0.0.1 כשרת ה-DNS הראשי, ואם רוצים, משתמשים בכתובת ה-IP של בקר דומיין אחר כשרת ה-DNS המשני. מידע נוסף מופיע במאמר הגדרות DNS מומלצות ואפשרויות חלופיות.
Hybrid Connectivity
בקטע הבא מפורטות שיטות מומלצות שקשורות לקישוריות היברידית.
שימוש בהעברה נכנסת של DNS כדי לפתור Google Cloud שמות DNS משרתים מקומיים
יכול להיות שהלקוחות ברשת המקומית שלכם יצטרכו להיות מסוגלים לפענח את שמות ה-DNS של משאבים שנפרסו ב- Google Cloud. אם מרחיבים את היער או פורסים יער משאבים ב-Google Cloud, צריך להשתמש בהעברה פנימית של DNS כדי לאפשר ללקוחות מקומיים לחפש רשומות DNS של משאבים שנפרסו ב- Google Cloud. כדי להשתמש בהעברה נכנסת, צריך ליצור מדיניות של שרת DNS כדי להקצות כתובת IP של מעביר נכנס, ולהפוך את הכתובת הזו לנגישה לרשת המקומית.
אם דומיין ה-DNS שמשמש ב- Google Cloud (לדוגמה, cloud.example.com) הוא תת-דומיין של דומיין ה-DNS שמשמש בפריסה המקומית (לדוגמה, example.com), צריך להגדיר העברת סמכות של DNS. יוצרים רשומת NS בדומיין המקומי שמצביעה על כתובת ה-IP של שרת העברת האימייל הנכנס. רשומת NS גורמת להפניה אוטומטית של לקוחות שמנסים לחפש שם DNS בדומיין המתארח Google Cloudלכתובת ה-IP של המפנה הנכנס.
אם דומייני ה-DNS שבהם נעשה שימוש ב- Google Cloud וב-Active Directory המקומי שונים (לדוגמה, cloud.example.com ו-corp.example.com), צריך להגדיר העברת DNS מותנית בדומיינים המקומיים ולהשתמש בכתובת ה-IP של מעביר הנתונים הנכנס כיעד. כשמתבקשת המרה של שם DNS בדומיין שמארח את Google Cloud, בקשות מועברות מבקרי הדומיין המקומיים לכתובת ה-IP של המעביר הנכנס.
כשמשתמשים בהעברת DNS נכנס, צריך לוודא שחומות האש מוגדרות בצורה מתאימה.
לא נדרשת העברה קדימה של DNS נכנס אם מרחיבים את הדומיין הקיים ל-Active Directory. בתרחיש הזה, כל רשומות ה-DNS של הדומיין משוכפלות אוטומטית ב- Google Cloud ובסביבה המקומית שלכם, וזמינות לחיפוש בשתי הסביבות.
שימוש בהעברה יוצאת של DNS כדי לפתור שמות DNS מקומיים מ Google Cloud
לקוחות שפועלים ב- Google Cloud צריכים להיות מסוגלים לפענח את השמות של משאבים שנפרסו בפריסה מקומית. אם מרחיבים את היער או פורסים יער משאבים ב- Google Cloud, צריך ליצור אזור פרטי להעברת נתונים ב-Cloud DNS כדי להעביר שאילתות DNS עבור הדומיינים המקומיים לשרתי ה-DNS המקומיים.
כשמשתמשים בהפניה אוטומטית של DNS לדואר יוצא, צריך לוודא שחומות האש מוגדרות בצורה מתאימה.
לא נדרש העברה של DNS יוצא אם מרחיבים את הדומיין הקיים ל-Active Directory. בתרחיש הזה, כל רשומות ה-DNS של הדומיין משוכפלות אוטומטית ב- Google Cloud ובסביבה המקומית שלכם, וזמינות לחיפוש בשתי הסביבות.
שימוש במנהרות VPN לאבטחת תעבורת LDAP
ב-Active Directory נעשה שימוש נרחב בפרוטוקול LDAP. בניגוד לרוב הפרוטוקולים האחרים שמשמשים את Active Directory, LDAP לא מוצפן כברירת מחדל.
Google Cloud מוודא שהתנועה בין מכונות וירטואליות מוצפנת, ולכן אפשר להשתמש ב-LDAP לא מוצפן בתוך ה-VPC. אם מחברים את ה-VPC לרשת מקומית, צריך לוודא שהתנועה של LDAP מועברת רק בערוצים מהימנים.
אם משתמשים ב-Cloud VPN כדי להתחבר Google Cloud לרשת המקומית, התעבורה מוצפנת באופן אוטומטי באמצעות IPSec ביןGoogle Cloud לבין נקודת הקצה של ה-VPN המקומי.
Cloud Interconnect ו-Partner Interconnect לא מספקים הצפנה. כדי להבטיח תקשורת מאובטחת, צריך ליצור מנהרת VPN על גבי חיבור ה-Interconnect באמצעות מכשיר VPN מ-Google Cloud Marketplace.
שימוש באימות סלקטיבי וב-AES עבור יחסי אמון בין יערות
כשיוצרים יחסי אמון בין יערות של Active Directory, עדיף להשתמש באמון יערות במקום באמון חיצוני, ומומלץ להשתמש בתכונות הבאות כדי לשפר את האבטחה:
מפעילים אימות סלקטיבי בטראסטים יוצאים ביער המשאבים. אימות סלקטיבי מבטיח שמשתמשים מהיער הארגוני לא יוכלו לגשת למשאבים ביער המשאבים, אלא אם ניתנה להם הרשאה מפורשת.
מפעילים את האפשרות enforcement for forest boundary for Kerberos full delegation (אכיפה של גבולות היער להענקת הרשאות מלאות של Kerberos) בנאמנויות נכנסות ביער הארגוני. התכונה הזו עוזרת למנוע מתקפות של העלאת רמת הרשאות, כי היא לא מאפשרת למשאבים ביער המשאבים לבקש כרטיסי TGT ממשתמשים ביער הארגוני.
כשיוצרים יחסי אמון, צריך להפעיל את האפשרות הדומיין השני תומך בהצפנת Kerberos AES. האפשרות הזו מבטיחה שהכרטיסים שמשמשים לאימות בין יערות יוצפנו באמצעות AES במקום באמצעות אלגוריתם RC4 הפחות מאובטח.
אבטחה
בקטע הבא מפורטות שיטות מומלצות שקשורות לאבטחה.
איך Google Cloud מונעים הפרעה של אבטחה לאבטחה של Active Directory
ב-Active Directory יש לכם שליטה מדויקת על המשתמשים שמורשים לגשת למשאבים מסוימים. כשמכונות נפרסות כמופעים של מכונות וירטואליות ב-Compute Engine ולמשתמשים יש גישה לפרויקט הבסיסי Google Cloud, צריך לקחת בחשבון נתיבים נוספים שעשויים לאפשר למשתמש גישה למכונה:
חבר בפרויקט שהוקצה לו התפקיד אדמין של מכונת Compute בפרויקט Google Cloud יכול להשתמש בפונקציונליות של איפוס סיסמה כדי ליצור חשבונות אדמין מקומיים. חשבונות אדמין מקומיים מהווים איום על האבטחה של דומיין Active Directory, כי אפשר להשתמש בהם כדי לערער על מדיניות קבוצתית או כדי להתקין תוכנה זדונית שעלולה ללכוד את פרטי הכניסה לדומיין של משתמשים אחרים שמחוברים.
אם מוסיפים סקריפט לטעינה בזמן ההפעלה, חבר פרויקט עם הרשאות יכול להחדיר קוד זדוני למכונה וירטואלית שמופעלת כ-
nt authority\systemבפעם הבאה שהמכונה מופעלת מחדש.באמצעות המסוף הטורי, חבר פרויקט עם הרשאות יכול גם לגשת למסוף הניהול המיוחד (SAC) של Windows. מערכת Windows מתייחסת לכניסות דרך SAC ככניסות מקומיות. לכן, אפשר לנצל לרעה את ה-SAC כדי לעקוף מדיניות שמונעת כניסה באמצעות RDP, אבל לא מונעת כניסה מקומית.
חבר פרויקט עם הרשאות יכול להשתמש ב-SAC כדי להנפיק פקודה
crashdump, שיכולה לגרום לכתיבת dump של הזיכרון לדיסק. יכול להיות שקובץ dump של הזיכרון יכלול מידע רגיש ופרטי כניסה.על ידי צירוף דיסק אחסון מתמיד (persistent disk) למכונה וירטואלית אחרת או שימוש בתמונות מצב, יכול להיות שלחבר פרויקט עם הרשאות מיוחדות תהיה גישה לתוכן הדיסק, כולל קבצי dump של הזיכרון, ממכונות שלמשתמש לא הייתה הרשאה להתחבר אליהן בדרך אחרת.
כשמשתמשים בשירות מנוהל ל-Microsoft AD, יש הגנה טובה יותר מפני נתיבי הגישה הנוספים האלה כברירת מחדל. השירות לא מאפשר למשתמשים עם הרשאות מיוחדות בפרויקט לאפס את הסיסמה של אדמין הדומיין, להריץ סקריפטים של הפעלה או לגשת למסוף הטורי במכונות הווירטואליות של בקר הדומיין ב-AD.
כדי לצמצם עוד יותר את הסיכונים האלה, חשוב לוודא שהרשאות ה-IAM של פרויקטים שמכילים מכונות וירטואליות שמצורפות לדומיין מנוהלות על בסיס הרשאות מינימליות. כדי לצמצם עוד יותר את הסיכון, אפשר להשתמש במדיניות הארגון, במדיניות הקבוצה ובמכונות וירטואליות מוגנות:
משתמשים במדיניות ארגונית כדי להשבית את הגישה ליציאות טוריות.
אפשר להחיל מדיניות קבוצתית שמונעת יצירה של חשבונות אדמין מקומיים על ידי השבתה של מנהל החשבונות. מגדירים העדפה של קובצי INI במדיניות הקבוצה (הגדרת המחשב > העדפות > הגדרות Windows > קובצי Ini) כדי להחיל את ההגדרה הבאה:
- פעולה: עדכון
- נתיב הקובץ:
C:\Program Files\Google\Compute Engine\instance_configs.cfg - שם הקטע:
accountManager - שם הנכס:
disable - ערך המאפיין:
true
החלת מדיניות קבוצתית שמסירה חשבונות אדמין מקומיים ממופעי מכונות וירטואליות. משתמשים בפונקציונליות של משתמשים וקבוצות מקומיים (הגדרת המחשב > העדפות > הגדרות לוח הבקרה > משתמשים וקבוצות מקומיים) כדי להסיר את החברות בקבוצה מהקבוצה Administrators ומקבוצות רגישות אחרות.
כדאי להשתמש במכונות וירטואליות מוגנות בשילוב עם הצפנת דיסק של BitLocker כדי למנוע ממשתמשים לא מורשים לקרוא נתונים בדיסק אחסון מתמיד או בקובצי snapshot.
הימנעות מהפרעה של אבטחת Active Directory ל Google Cloud אבטחה
בדומיין Active Directory, המחשבים סומכים על בקרי הדומיין שיטפלו באימות ובהרשאה בשמם. אלא אם הגישה מוגבלת על ידי מדיניות קבוצתית, מדיניות אבטחה מקומית של מכונה או אימות סלקטיבי, משתמש שהוכיח את הזהות שלו לאחד מבקרי הדומיין יכול להתחבר לכל מכונה בדומיין.
היכולת של משתמשי Active Directory להתחבר לכל מכונה עשויה לאפשר לתוקפים לבצע תנועות לרוחב בתוך דומיין. תנועות רוחביות כאלה עלולות להוביל להרחבת הרשאות אם מכונות וירטואליות מסוימות פטורות מהגבלות חומת האש או משתמשות ב Google Cloud חשבונות שירות: פרטי הכניסה של חשבון שירות נגישים לכל התהליכים והמשתמשים במכונה וירטואלית. לכן כל משתמש שיכול להשתמש ב-Active Directory כדי להיכנס למכונה יכול לגשת לפרטי הכניסה של חשבון השירות כדי לקבל גישה לכל המשאבים שחשבון השירות קיבל גישה אליהם. Google Cloud
כשמגדירים שירות מנוהל ל-Microsoft AD, השירות יוצר קבוצה כדי לאפשר למשתמשים ספציפיים להתחבר למכונות וירטואליות שמצורפות לדומיין באמצעות RDP.
כדי להפחית את הסיכון לתנועות לרוחב, אפשר לארגן את המשתמשים בשכבות אדמיניסטרטיביות ולהשתמש במדיניות הקבוצתית Deny access to this computer from the network (דחיית הגישה למחשב הזה מהרשת) ובמדיניות הקבוצתית Deny logon through Remote Desktop Services (דחיית הכניסה דרך שירותי שולחן עבודה מרוחק) כדי להגביל את הגישה למכונות הווירטואליות על סמך רמת השכבה.
בטופולוגיה של יער משאבים, אפשר להשתמש באימות סלקטיבי כדי להגביל עוד יותר את קבוצת המשתמשים מיערות אחרים שמורשים להיכנס למכונות הווירטואליות שלכם. כדי לפשט את ניהול ההרשאות של אימות סלקטיבי, אפשר להתאים את מבני המשאבים שלGoogle Cloud ושל Active Directory: אם היחידות הארגוניות של Active Directory ממופות לפרויקטים של Google Cloud , אפשר להעניק למשתמשים את הזכות לבצע אימות ברמה שתואמת לפרויקט שלGoogle Cloud .
במקרים שבהם אי אפשר להשתמש באימות סלקטיבי או במדיניות קבוצתית, צריך ליצור חשבון שירות נפרד, לייצא את המפתחות של חשבון השירות, לשמור אותם בדיסק המקומי של המכונה הווירטואלית או בהתקן רשת לשיתוף קבצים, ולהגן עליהם באמצעות ACL של NTFS כדי שרק משתמשים מורשים ב-Active Directory יוכלו לקרוא את המפתחות ולהשתמש בהם.
שימוש בפרויקטים ייעודיים לבקרי דומיין
לבקרי הדומיין יש תפקיד חשוב באבטחה של דומיין Active Directory, ופריצה לבקר דומיין יחיד עלולה להוביל לפריצה של כל יער Active Directory.
כדי להקטין את הסיכון לגישה לא מורשית, מומלץ להשתמש בפרויקט Google Cloud נפרד כדי לפרוס בקרי דומיין ולהעניק גישה לפרויקט הזה על בסיס הרשאות מינימליות. כשיוצרים את הפרויקט, חשוב לזכור שחלק מההרשאות עשויות להיות מוּרשות מתיקיות אב. כדי להימנע ממתן גישה בטעות באמצעות ירושה, כדאי ליצור את הפרויקט מחוץ להיררכיית התיקיות הרגילה.
כשמגדירים מדיניות IAM לפרויקט, חשוב במיוחד להגביל את הגישה למופעי VM, לדיסקים הקבועים שמכילים את מסד הנתונים ntds.dit ולכל מיקום אחסון שעשוי להכיל גיבויים.
בנוסף לשימוש במדיניות IAM כדי להגביל את הגישה לפרויקט, מומלץ להגן על הפרויקט מפני מחיקה בטעות.
שימוש במכונות וירטואליות ובפרויקטים נפרדים לניהול Active Directory
כדי לנהל את Active Directory, צריך לדעת להשתמש בכלים כמו Active Directory Users and Computers או Active Directory Administrative Center. הכלים האלה דורשים התחברות באמצעות חשבון דומיין עם הרשאות מיוחדות, ולכן המחשב שבו מריצים את הכלים האלה הוא יעד אטרקטיבי לגניבת פרטי כניסה או לרישום הקשות.
כדי לצמצם את הסיכון שפורץ ישיג פרטי כניסה של דומיין עם הרשאות, כדאי להשתמש במכונות וירטואליות ייעודיות לניהול הדומיין, ולטפל במכונות וירטואליות כאלה כמו בתחנות עבודה עם גישה מורחבת:
משתמשים במדיניות קבוצתית כדי לוודא שרק קבוצת משנה נבחרת של משתמשים תוכל להיכנס למכונות וירטואליות לניהול. אם הטמעתם ניהול בהיררכיה, קבוצת המשתמשים הזו תואמת לרמה 0.
בדומה לבקרי דומיין, חברי פרויקט יכולים לסכן מכונות וירטואליות אדמיניסטרטיביות על ידי יצירת חשבונות אדמין מקומיים, התחברות דרך המסוף הטורי או שינוי של הדיסקים הקבועים שלהן. כדי להקטין את הסיכון לגישה לא מורשית, כדאי להשתמש בGoogle Cloud פרויקט נפרד למכונות וירטואליות של אדמינים ולהעניק גישה לפרויקט הזה על בסיס הרשאות מינימליות.
אם אתם מתכננים לגשת למכונות VM אדמיניסטרטיביות מרשת מקומית באמצעות קישוריות היברידית, כדאי לפרוס את המכונות האדמיניסטרטיביות ברשת משנה ייעודית של VPC. רשת משנה שמוקדשת למכונות וירטואליות לניהול מאפשרת להבחין טוב יותר בין מכונות וירטואליות לניהול לבין מכונות וירטואליות אחרות כשמגדירים את חומות האש המקומיות. אם אתם משתמשים ב-VPC משותף, אתם צריכים להשתמש בהרשאות ברמת רשת המשנה כדי לוודא שרק לאדמינים עם הרשאות מיוחדות מותר לפרוס מכונות וירטואליות ברשת המשנה לניהול. השיטה הזו עוזרת לוודא שאם חומות אש מקומיות מחילות כללים שונים על מכונות וירטואליות לניהול מאשר על מכונות וירטואליות אחרות, משתמשים לא יכולים לעקוף את כללי חומת האש על ידי הצבת מכונות וירטואליות שאינן לניהול ברשת המשנה לניהול.
בנוסף, כדאי להגביל את מדיניות הקבוצה שמנהלת את ההגבלות על הכניסה למכונות וירטואליות לניהול, לרשת המשנה לניהול. השיטה הזו מאפשרת לאכוף התאמה בין הגבלות הכניסה (על סמך מדיניות קבוצתית) לבין כללי חומת האש (על סמך רשת משנה או כתובת IP).
בנוסף לשימוש במדיניות IAM כדי להגביל את הגישה לפרויקט, מומלץ להגן על הפרויקט מפני מחיקה בטעות.
שימוש בכללי חומת אש לאבטחת בקרי דומיין ושרתים
בקרי דומיין חושפים מספר שירותים, כולל LDAP, DNS, Kerberos ו-RPC. בהתאם לתרחישי השימוש, יכול להיות שמכונות וירטואליות שנפרסו ב- Google Cloud, וגם מכונות שפועלות בפריסה מקומית, יצטרכו גישה לקבוצות משנה שונות של השירותים האלה כדי להשתמש ב-Active Directory.
כשמשתמשים בשירות מנוהל ל-Microsoft AD, בקרי הדומיין של AD נפרסים בפרויקט ייעודי של דייר. הרשת שמארחת את בקרי הדומיין של AD מוגנת באופן אוטומטי באמצעות כללי חומת אש מחמירים שספציפיים ל-AD.
כדי לצמצם את שטח הפנים של בקרים של דומיין ושל מכונות וירטואליות, משתמשים בחומות אש כדי למנוע תקשורת ברשת שלא נדרשת באופן מוחלט. במדריך שלנו בנושא שימוש ב-Active Directory בחומות אש מפורטות הגדרות חומת האש שנדרשות כדי לגשת ל-Active Directory מתוך ה-VPC או מרשתות מקומיות.
ארגון משאבים ומשתמשים של Active Directory בשכבות ניהול
חלק מהמכונות ביער Active Directory חשובות יותר לאבטחה הכוללת של Active Directory מאחרות. בקרי דומיין ומכונות וירטואליות אדמיניסטרטיביות הן שתי דוגמאות למכונות שחיוניות במיוחד ולכן רגישות במיוחד למתקפות פוטנציאליות.
כדי לזהות את רמת הקריטיות של כל מכונה, צריך להשתמש בטקסונומיה של רמות. מספר הרמות הנכון תלוי בהגדרה הספציפית שלכם, אבל אפשר להתחיל בהבחנה בין שלוש רמות:
שכבה 0 (קריטית מאוד): השכבה הזו כוללת את כל המכונות שקריטיות לאבטחה של יער Active Directory. אם מכונה ברמה 0 נפגעת, צריך להניח שכל היער נפגע.
רמה 1 (קריטית): הרמה הזו כוללת את רוב השרתים בסביבה שלכם, כולל שרתי אפליקציות ושרתי מסדי נתונים. פריצה לשרת ברמה 1 עלולה להשפיע באופן משמעותי על העסק, אבל היא לא מהווה איום מיידי על כל היער.
רמה 2 (רגילה): הרמה הזו כוללת תחנות עבודה או מכונות אחרות לשימוש כללי. ההשפעה של פריצה למכונה ברמה 2 על העסק ועל האבטחה הכוללת צפויה להיות מוגבלת.
יכול להיות שההשפעה המיידית של מחשב ברמה 2 שנפרץ תיראה מוגבלת, אבל יש סיכון להשפעות משניות: אם משתמש שיש לו גישת אדמין למחשבים ברמה 0 או ברמה 1 יתפתה להתחבר למחשב ברמה 2 שנפרץ, הוא עלול ליפול קורבן לתוכנת מעקב אחר הקלדות או לצורות אחרות של גניבת פרטי כניסה. אחרי שההאקרים ישיגו את פרטי הכניסה, הם יוכלו להשתמש בהם כדי לתקוף מכונות ברמות גבוהות יותר, וכך להגדיל את ההשפעה הכוללת של המתקפה.
כדי למנוע השפעות כאלה, חשוב לא רק לסווג מכונות, אלא גם חשבונות משתמשים, ולהגביל את הגישה של המשתמשים האלה למכונות:
רמה 0 (קריטית מאוד): משתמשים שיש להם גישה למכונות ברמה 0.
רמה 1 (קריטית): משתמשים שיש להם גישה למכונות ברמה 1.
רמה 2 (רגילה): משתמשים שיש להם גישה למכונות ברמה 2.
הטבלה הבאה מציגה הנחיות לגבי המשתמשים שצריכה להיות להם גישה למשאבים מסוימים:
| קבוצה | רמה | גישה לדומיין | גישה למחשב ברמה 0 | גישה למחשב ברמה 1 | גישה למחשב ברמה 2 |
|---|---|---|---|---|---|
| מנהלי מערכת של Active Directory | 0 | מנהל מערכת | משתמש מוגבל | חסום | חסום |
| מנהלי שרת הניהול | 0 | משתמש מוגבל | מנהל מערכת | חסום | חסום |
| אדמינים של שרתים | 1 | משתמש מוגבל | חסום | מנהל מערכת | חסום |
| אדמינים של תחנות עבודה ב-VDI | 2 | משתמש מוגבל | חסום | חסום | מנהל מערכת |
| משתמשי תחנות עבודה ב-VDI | 2 | משתמש מוגבל | חסום | חסום | משתמש מוגבל |
מידע נוסף ושיטות מומלצות להטמעה של מודל שכבת ניהול ב-Active Directory זמינים במסמכי התיעוד של Microsoft.
כשמשתמשים במודל של רמות ניהול ביער Active Directory, חשוב לוודא שקשרי האמון ביער לא פוגעים בשלמות שלו. אם גם ביער המהימן מוחל מודל ניהול מדורג, צריך להשתמש באימות סלקטיבי כדי לוודא שלמשתמשים מהיער המהימן תהיה גישה רק למשאבים באותה רמה:
אם ביער המהימן לא מיושם ניהול מדורג, צריך למפות את היער המהימן לרמה מסוימת ולהשתמש באימות סלקטיבי כדי לוודא שלמשתמשים מהיער המהימן תהיה גישה רק למשאבים של הרמה הספציפית הזו.
שימוש ב-VPC Service Controls ובגישה פרטית ל-Google למארחים מקומיים
ממשקי API של שירות מנוהל ל-Microsoft AD מאפשרים לאפס את סיסמת האדמין ולבצע פעולות רגישות אחרות. לפריסות קריטיות בסביבת ייצור, מומלץ להפעיל VPC Service Controls ולהשתמש ב-גישה פרטית ל-Google למארחים מקומיים כדי לשפר את האבטחה.
ניהול
בקטע הבא מפורטות שיטות מומלצות שקשורות לניהול של Active Directory.
התאמה Google Cloud של מבני משאבים ב-Active Directory
כשפורסים יער או דומיין חדש של Active Directory ב-Google Cloud, צריך להגדיר מבנה של יחידות ארגוניות (OU) כדי לארגן את המשאבים באמצעות דומיין Active Directory. במקום לתכנן מבנה חדש לגמרי או להחיל את המבנה שבו אתם משתמשים בסביבה המקומית, כדאי ליצור מבנה של יחידות ארגוניות שתואם לGoogle Cloud היררכיית המשאבים:
אם אתם משתמשים במודל ניהול היררכי, היחידות הארגוניות ברמה העליונה צריכות לשקף את רמות הניהול שלכם.
לכל רמה, יוצרים יחידות ארגוניות למשתמשים ולקבוצות. אם אתם מתכננים לנהל מספר גדול של משתמשים וקבוצות, כדאי ליצור יחידות ארגוניות משנה לפי הצורך.
לכל רמה, יוצרים
Projectsיחידה ארגונית ויוצרים יחידות ארגוניות משנה לכלGoogle Cloud פרויקט שמכיל משאבי Active Directory. משתמשים ביחידה הארגונית המשנית הספציפית לפרויקט כדי לנהל חשבונות מחשב, חשבונות שירות או משאבים אחרים של Active Directory שתואמים למשאבים של הפרויקט הרלוונטי. Google Cloudמוודאים שיש מיפוי של 1:1 בין היחידות הארגוניות לבין הפרויקטים.
התרשים הבא מציג היררכיה לדוגמה שפועלת לפי העקרונות האלה:
אם מספר הפרויקטים שמכילים משאבי Active Directory הוא בינוני, אפשר ליצור מבנה שטוח של יחידות ארגוניות מתחת ליחידה הארגונית Projects. אם אתם מתכננים לנהל מספר גדול של פרויקטים ותכננתם אתGoogle Cloud היררכיית המשאבים כך שתכלול כמה רמות של תיקיות, כדאי לשקול לשקף את מבנה התיקיות הזה מתחת ליחידה הארגונית Projects.
יש כמה יתרונות להתאמה בין מבנה ה-OU של Active Directory לבין היררכיית המשאבים Google Cloud :
כשמייפים הרשאות אדמין ל Google Cloud פרויקט באמצעות כללי מדיניות של IAM, יכול להיות שתצטרכו גם להעניק למשתמשי הפרויקט הרשאות מסוימות ב-Active Directory. לדוגמה, יכול להיות שאדמינים של Compute Engine יצטרכו להצטרף למכונות בדומיין במסגרת יחידה ארגונית מסוימת. התאמה בין יחידות ארגוניות ובין פרויקטים ב- Google Cloud מאפשרת להעניק הרשאות כאלה באותה רמת פירוט ב-Active Directory כמו ב- Google Cloud.
אם אתם מתכננים להשתמש באובייקטים של מדיניות קבוצתית (GPO) כדי לנהל מחשבים, מבנה של יחידה ארגונית שמשקף את Google Cloud היררכיית המשאבים עוזר לכם לוודא שאובייקטים של מדיניות קבוצתית מוחלים באופן עקבי על כל המכונות הווירטואליות של פרויקט או תיקייה מסוימים.
אם אתם משתמשים באמון בין יערות עם אימות מותנה, אתם יכולים להשתמש ביחידות הארגוניות שתואמות ל Google Cloud פרויקטים כדי להעניק את ההרשאה Allowed to authenticate על בסיס כל פרויקט בנפרד.
כשמוחקים פרויקט ב- Google Cloud, אפשר פשוט למחוק את היחידה הארגונית המשויכת, וכך להקטין את הסיכון להשארת משאבים לא פעילים בספרייה.
אם אתם מרגישים שמבנה היחידות הארגוניות צריך להיות שונה ממבנה הפרויקט, יכול להיות שמבנה הפרויקט מפורט מדי או גס מדי.
שימוש בשרתי זמן של Google
אימות Kerberos מסתמך על חותמות זמן כחלק מהפרוטוקול שלו. כדי שהאימות יצליח, השעונים של המכונה של הלקוח ושל השרת צריכים להיות מסונכרנים בטווח מסוים. כברירת מחדל, ב-Active Directory אין אפשרות להגדיר הבדל של יותר מ-5 דקות.
בסביבת Active Directory בארגון, אלה הגדרות ברירת המחדל לסנכרון הזמן:
- מחשבים שמצורפים לדומיין מסנכרנים את השעה שלהם עם בקר הדומיין.
- בקרי הדומיין מסנכרנים את השעה שלהם עם אמולטור ה-PDC של הדומיין.
- אמולטורי PDC של כל הדומיינים מסנכרנים את השעה שלהם עם אמולטור ה-PDC של דומיין הבסיס של היער.
בהגדרה הזו, אמולטור ה-PDC של דומיין הבסיס של היער הוא המקור האולטימטיבי של השעה עבור Active Directory, ובדרך כלל מגדירים את המחשב הזה לשימוש בשרת NTP חיצוני כמקור השעה.
ב-Compute Engine, ההגדרה שמוגדרת כברירת מחדל למכונות וירטואליות של Windows היא שימוש בשרת המטא-נתונים (metadata.google.internal) כשרת NTP, שבתורו מסתמך על שרתי ה-NTP של Google כדי לקבל את השעה הנכונה. הצטרפות של מכונה וירטואלית לדומיין Active Directory לא משנה את הגדרת ברירת המחדל הזו.
משאירים את הגדרות ברירת המחדל של Compute Engine, אלא אם אמולטור ה-PDC של דומיין השורש של היער פרוס מחוץ ל- Google Cloud.
אם אמולטור ה-PDC שלכם נפרס מחוץ ל- Google Cloud, צריך להגדיר אותו לשימוש ב-time.google.com כמקור NTP.
אפשרות אחרת היא לשחזר את התנהגות ברירת המחדל של Active Directory של סנכרון הזמן עם אמולטור ה-PDC, על ידי הגדרה מחדש של מכונות וירטואליות ב-Compute Engine לשימוש במקור ה-NTP DOMHIER והגדרת כללי חומת אש שיאפשרו תעבורת NTP נכנסת (UDP/123) לבקרי הדומיין.
איחוד ומעקב של יומני ביקורת
כשפורסים את Active Directory ב- Google Cloud, האבטחה של יער Active Directory והפרויקטים שלכם קשורים זה לזה: פעילות חשודה ב-Active Directory וב-Windows עלולה לסכן את האבטחה של משאבים אחרים באותו אופן שבו פעילות חשודה ב- Google Cloud עלולה לסכן את Active Directory. Google Cloud
יומני ביקורת עקביים הם כלי חשוב לזיהוי מוקדם של איומים או הגדרות שגויות, והם מאפשרים לשחזר ולבדוק פעילות קודמת. בעזרת Cloud Audit Logging תוכלו לתעד ולנתח יומני פעילות של אדמינים ויומני גישה לנתונים. באופן דומה, אפשר להשתמש ברישום ביומן של כללי חומת אש וביומנים לתיעוד מידע על תעבורת ה-IP של ענן וירטואלי פרטי (VPC) כדי לנתח את תעבורת הרשת. עם זאת, שירותי הפלטפורמה האלה לא מודעים לאירועים שקשורים לאבטחה שמתרחשים ב-Active Directory. כדי ליצור נתיב ביקורת עקבי שכולל אירועי ביקורת שקשורים לפלטפורמה ואירועי ביקורת שקשורים ל-Active Directory, צריך להתקין את הסוכן של Cloud Logging בבקרי דומיין ובמכונות שמצורפות לדומיין כדי לייצא יומני אירועי אבטחה של Windows אל Cloud Logging.
כברירת מחדל, יומן אירועי האבטחה של Windows לא כולל את כל האירועים שאתם צריכים לצורכי ביקורת. כדי לוודא שתתעדו את כל אירועי הביקורת הרלוונטיים, מומלץ לעיין בהמלצות של מיקרוסופט בנושא הגדרת מדיניות ביקורת ומעקב אחר Active Directory כדי לזהות סימנים לפשרה.
כשמטפלים בנפח גדול של אירועים, קל לפספס אירועים קריטיים. כדי לא לפספס אירועים קריטיים, כדאי ליצור מדדים מבוססי-יומנים לאירועים שעשויים להיות קריטיים או חשודים במיוחד, ומומלץ להגדיר התראות כדי לקבל הודעה אם קצב האירועים משתנה או חורג מספי קבלה.
המאמרים הבאים
כדאי לברר איזה דפוס לשימוש ב-Active Directory בסביבה היברידית מתאים לכם הכי טוב.
איך מגדירים Active Directory למכונות וירטואליות כדי שיצטרפו אוטומטית לדומיין
מוזמנים לנסות בעצמכם תכונות אחרות של Google Cloud . מומלץ לעיין במדריכים שלנו.