במדריך הזה מוצגות שיטות מומלצות להרצת Active Directory ב- Trusted Cloud by S3NS. המדריך מתמקד בשיטות ספציפיות ל- Trusted Cloud או בשיטות שחשובות במיוחד כשפורסים את Active Directory ב- Trusted Cloud. המדריך הזה משלים את השיטות המומלצות הכלליות לאבטחת Active Directory שפורסמו על ידי Microsoft.
ארכיטקטורה
בקטעים הבאים מפורטות שיטות מומלצות שקשורות לארכיטקטורה.
שימוש בתבנית הארכיטקטורה שמתאימה ביותר לדרישות שלכם
כדי לפרוס את Active Directory ב- Trusted Cloud, קודם צריך להחליט באיזה ארכיטקטורה של יער ודומיין להשתמש. אם אתם כבר משתמשים ב-Active Directory, תצטרכו גם להחליט אם לשלב את שתי הסביבות ואיך לעשות זאת.
העיצוב שמתאים לכם ביותר תלוי במספר גורמים, כולל העיצוב של הרשת המקומית, האופן שבו המשאבים המקומיים והמשאבים ב-Trusted Cloud יתקשרו ביניהם, וכן הדרישות שלכם לגבי זמינות ואוטונומיה מנהלית. בדוגמאות לשימוש ב-Active Directory בסביבה היברידית מוסבר איך הגורמים האלה קובעים את העיצוב.
אם אתם רוצים לשמור על גבול אמון ביןTrusted Cloud לבין הסביבה המקומית, כדאי ליישם את התבנית יער משאבים. בתבנית הזו, פורסים יער נפרד ב- Trusted Cloud ומשתמשים באמון יער חד-כיווני כדי לשלב את היער ב- Trusted Cloud עם היער הקיים של Active Directory בארגון.
הפרדה בין סביבת הבדיקה לסביבת הייצור
בהתאם לאופן השימוש שלכם ב-Active Directory, יכול להיות שתצטרכו לבצע שינויים תכופים ב-Active Directory במהלך הפיתוח והבדיקה של האפליקציות. יכול להיות שמפתחים יצטרכו ליצור ולשנות חשבונות Active Directory, לשנות את החברות בקבוצות אם האפליקציות משתמשות בקבוצות לצורך טיפול באימות, או להצטרף למחשבים ולהסיר אותם.
כדי למנוע מעבודות הפיתוח והבדיקה להשפיע על עומסי העבודה בסביבת הייצור או לפגוע באבטחה של הפריסה, מומלץ לפרוס יער או דומיין נפרד של Active Directory לצורכי פיתוח ובדיקה.
שימוש ביער או בדומיין נפרדים לפיתוח ובדיקה מאפשר גם לאמת שינויים ניהוליים לפני שמחילים אותם בסביבת הייצור. דוגמאות לשינויים כאלה כוללות ניסויים במדיניות הקבוצה, בדיקת סקריפטים של אוטומציה או פעולות שעלולות להיות מסוכנות, כמו העלאת הרמה הפונקציונלית של יער.
הגדרת איחוד שירותי אימות הזהות של Cloud בנוסף לפריסה של Active Directory ב- Trusted Cloud by S3NS
פריסה של Active Directory ב- Trusted Cloud מאפשרת לנהל מכונות וירטואליות של Windows ב- Trusted Cloud, מאפשרת למשתמשים להתחבר למכונות וירטואליות של Windows באמצעות חשבונות המשתמש הקיימים שלהם ותומכת באפליקציות שמסתמכות על Kerberos, NTLM או LDAP לצורך אימות.
עם זאת, כדי להשתמש במסוףTrusted Cloud , בכלי שורת הפקודה gcloud או בכלים אחרים של Google ו- Trusted Cloud , צריך לבצע אימות באמצעות זהות ב-Google. לכן, פריסה של Active Directory ב- Trusted Cloud היא לא תחליף לאיחוד של Active Directory הקיים עםTrusted Cloud אם אתם מתכוונים להשתמש ב-Active Directory כמערכת הראשית לניהול משתמשים.
לדוגמה, אם פורסים יער נפרד ב- Trusted Cloud, אפשר להגדיר איחוד מול Active Directory המקומי, כפי שמתואר בתרשים הבא. משתמשים שיש להם חשבונות ב-Active Directory המקומי יוכלו להשתמש בכלים שדורשים זהות של Google, וגם באפליקציות שלכם שמסתמכות על Active Directory לאימות.
אם במקום זאת תחליטו להרחיב את היער הקיים או את הדומיין אל Trusted Cloud, תוכלו גם להשתמש בפקדי דומיין ובשרתי AD FS שנפרסו ב- Trusted Cloud כדי להגדיר את האיחוד.
איחוד מאפשר גם לאכוף מחזור חיים משותף לחשבונות Google ולחשבונות Active Directory, כך שכאשר משביתים חשבון משתמש ב-Active Directory המקומי, גם משתמש Google התואם מושעה.
Networking
בקטע הבא מפורטות שיטות מומלצות שקשורות לרשתות.
פריסה של Active Directory ברשת VPC משותפת
כדי לאפשר שימוש ב-Active Directory במספר פרויקטים, צריך לפרוס את בקרי הדומיינים ברשת VPC משותפת. לשימוש ברשת VPC משותפת יש כמה יתרונות:
כל אפליקציה שעשויה לדרוש גישה ל-Active Directory יכולה להיות פרוסה בפרויקט נפרד. שימוש בפרויקטים נפרדים עוזר לבודד משאבים ומאפשר לנהל את הגישה בנפרד.
אפשר להשתמש בפרויקט ייעודי לפקדי דומיין של Active Directory, שמאפשר לכם לשלוט באופן פרטני באילו משתמשים תהיה גישה למשאבים Trusted Cloud הקשורים.
רשתות VPC משותפות מאפשרות לכם למרכז את ניהול כתובות ה-IP ואת הגדרת חומת האש, וכך להבטיח עקביות בכמה פרויקטים.
רשתות VPC הן משאבים גלובליים, כך שאפשר להשתמש באותה רשת VPC משותפת בכמה אזורים.
לא לחשוף את בקרי הדומיין באופן חיצוני
כדי לצמצם את שטח ההתקפה של Active Directory, מומלץ להימנע מקביעת כתובות IP חיצוניות לבקרי דומיינים.
מאחר שלמכונות וירטואליות ללא כתובות IP חיצוניות אין גישה לאינטרנט כברירת מחדל, צריך לבצע פעולות נוספות כדי לוודא שהפעלה של Windows ועדכוני Windows לא יושפעו במנהלי הדומיינים.
כדי לתמוך בהפעלה של Windows, מפעילים את Private Google Access ברשת המשנה שבה מתכננים לפרוס את בקרי הדומיין, ומוודאים שמכונות הווירטואליות יכולות לגשת לכתובת kms.windows.googlecloud.com. כך ניתן לבצע הפעלה ללא גישה ישירה לאינטרנט.
יש כמה אפשרויות לתמיכה בעדכוני Windows:
אם יש לכם שרת WSUS בארגון, תוכלו להגדיר קישוריות היברידית ולהגדיר את בקרי הדומיין להשתמש בשרת WSUS כמקור לעדכונים.
כדי להפעיל גישה לאינטרנט דרך שער NAT, אפשר לפרוס Cloud NAT.
אם הגדרתם קישוריות היברידית, תוכלו גם לנתב תנועה יוצאת דרך שרת proxy או שער NAT מקומי.
הזמנת כתובות IP סטטיות מראש לבקרי דומיינים
מאחר שמתגי דומיין משמשים כשרתי DNS, צריך להקצות להם כתובת IP שלא משתנה. כדי לעשות זאת, צריך להגדיר כתובות IP פנימיות סטטיות למכונות הווירטואליות של בקרי הדומיין.
כשמזמינים כתובת IP, ברירת המחדל היא שבוחרים באופן אוטומטי כתובת שלא בשימוש. כדי לוודא שקל לזכור את כתובות ה-IP של בקרי הדומיין, צריך להקצות כתובת IP פנימית סטטית.
בבקרי הדומיין, מגדירים את כתובת ה-IP של מתאם הרשת לאותה כתובת. השלב הזה הוא אופציונלי, אבל הוא מונע מ-Active Directory לשלוח הודעות אזהרה על כך שעדיין יכול להיות שכתובת ה-IP של המכונה תוקצה באופן דינמי.
פריסה של בקרי דומיין בכמה תחומים
כדי לשפר את הזמינות, כדאי לפרוס לפחות שני בקרי דומיינים ולחלק אותם בין כמה תחומים. מאחר שתת-רשתות וכתובות IP לא קשורות לאזור, אפשר לפרוס את כל בקרי הדומיינים בתת-רשת אחת.
אם אתם מתכננים לפרוס עומסי עבודה במספר אזורים, כדאי לפרוס פקדי דומיין בכל אזור רלוונטי. מכיוון שתת-רשתות הן משאבים אזוריים, כדי לפרוס באזור נוסף תצטרכו תת-רשת נוספת.
יצירת אתר אחד לכל אזור
כשלקוח מנסה לאתר בקר דומיין, הוא מחפש קודם בקר דומיין באתר Active Directory שתואם לכתובת ה-IP של הלקוח. אם לא נמצא באתר הזה שרת אבטחת דומיין, הלקוח ימשיך וינסה לאתר שרת אבטחת דומיין באתר אחר.
כדי לנצל את ההתנהגות הזו, אפשר ליצור אתר נפרד לכל אזור שבו פורסים בקרי דומיין או לקוחות דומיין. לאחר מכן, הלקוחות יעדיפו באופן אוטומטי להשתמש בפקדי דומיין שנמצאים באותו אזור, וכך ניתן לצמצם את זמן האחזור ואת העלות של העברת נתונים יוצאת בין אזורים.
אם יש לכם לקוחות באזורים שאין בהם בקר דומיין, אתם יכולים להשפיע על בקרי הדומיין שהלקוחות האלה יבחרו על ידי שינוי העלויות של קישורי האתר כך שישקפו את הקרבה הגיאוגרפית של האזורים, והפעלת ההגדרה Try Next Closest Site (ניסיון באתר הקרוב ביותר הבא).
שימוש בכמה אתרים משפיע על התנהגות הרפליקציה בין בקרי דומיין. אחד החסרונות של שימוש בכמה אתרים הוא שהשכפול בין אתרים מתבצע בתדירות נמוכה יותר מאשר שכפול בתוך האתר.
עם זאת, אי אפשר ליצור אתרים של Active Directory ב-Managed Microsoft AD כי אין ב-Managed Microsoft AD תמיכה בתכונה'אתרים ושירותים של Active Directory'.
שימוש בתחומי העברה פרטיים ב-Cloud DNS
כשיוצרים מכונה וירטואלית חדשה ב-Compute Engine, מערכת ההפעלה מוגדרת מראש להשתמש בשרת DNS שמוגדר כברירת מחדל, שמספק גישה ל-DNS פנימי ול-DNS ציבורי.
לפני שאפשר לצרף מכונה לדומיין של Active Directory, צריך לוודא שהמכונה מסוגלת לפתור את רשומות ה-DNS שמנוהלות על ידי Active Directory. שרת ה-DNS שמוגדר כברירת מחדל ב-Compute Engine למכונה וירטואלית מספק גישה ל-DNS פנימי ול-DNS ציבורי, אבל לא יוכל לפתור שמות 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 אחרות על ידי הגדרת קישור (peering) של DNS.
עדיין צריך להגדיר את הגדרות ה-DNS באופן ידני במסופי הבקרה של הדומיינים. משתמשים ב-127.0.0.1 כשרת ה-DNS הראשי, ואם רוצים, משתמשים בכתובת ה-IP של בקר דומיין אחר כשרת ה-DNS המשני. מידע נוסף זמין במאמר הגדרות DNS מומלצות ואפשרויות חלופיות.
Hybrid Connectivity
בקטע הבא מפורטות שיטות מומלצות שקשורות לקישוריות היברידית.
שימוש בהעברה נכנסת של DNS כדי לפתור Trusted Cloud שמות DNS מהארגון
יכול להיות שללקוחות ברשת המקומית תהיה צורך לפתור את שמות ה-DNS של המשאבים שנפרסו ב- Trusted Cloud. אם מרחיבים את היער או פורסים יער משאבים ב-Trusted Cloud, צריך להשתמש בהעברה נכנסת של DNS כדי לאפשר ללקוחות מקומיים לחפש רשומות DNS של משאבים שנפרסו ב- Trusted Cloud. כדי להשתמש בהעברה נכנסת, צריך ליצור מדיניות של שרת DNS כדי להקצות כתובת IP של מעביר נכנס ולהפוך את הכתובת הזו לנגישה לרשת המקומית.
אם דומיין ה-DNS שמשמש ב- Trusted Cloud (לדוגמה, cloud.example.com) הוא תת-דומיין של דומיין ה-DNS שמשמש אונליין (לדוגמה, example.com), צריך להגדיר הענקת גישה ל-DNS. יוצרים רשומת NS בדומיין המקומי שמצביעה על כתובת ה-IP של המעביר הנכנס. רשומת NS גורמת לכך שלקוחות שמנסים לחפש שם DNS בדומיין שמתארח ב- Trusted Cloudיופנו לכתובת ה-IP של המעביר הנכנס.
אם הדומיינים של ה-DNS שבהם נעשה שימוש ב- Trusted Cloud וב-Active Directory המקומי שונים (לדוגמה, cloud.example.com ו-corp.example.com), צריך להגדיר העברה מותנית של DNS בדומיינים המקומיים ולהשתמש בכתובת ה-IP של המעביר הנכנס בתור היעד. כשמתקבלת בקשה לפתור שם DNS בדומיין המתארח ב- Trusted Cloud, בקרי הדומיין המקומיים מעבירים את הבקשה לכתובת ה-IP של המעביר הנכנס.
כשמשתמשים בהעברת DNS נכנסת, חשוב לוודא שחומת האש מוגדרת בצורה מתאימה.
לא נדרשת העברה נכנסת של DNS אם מרחיבים את הדומיין הקיים ל-Active Directory. בתרחיש הזה, כל רשומות ה-DNS של הדומיין מוכפלות באופן אוטומטי ב- Trusted Cloud ובסביבה המקומית, וזמינות לחיפוש בשתי הסביבות.
שימוש בהפניה יוצאת של DNS כדי לפתור שמות DNS מקומיים מ- Trusted Cloud
יכול להיות שללקוחות שפועלים ב- Trusted Cloud תהיה צורך לפתור את השמות של המשאבים שנפרסו בארגון. אם מרחיבים את היער או פורסים יער משאבים ב- Trusted Cloud, צריך ליצור אזור העברה פרטי ב-Cloud DNS כדי להעביר שאילתות DNS של הדומיינים המקומיים לשרתי ה-DNS המקומיים.
כשמשתמשים בהעברת DNS יוצאת, חשוב לוודא שחומות האש מוגדרות בצורה מתאימה.
לא נדרשת העברה יוצאת של DNS אם מרחיבים את הדומיין הקיים ל-Active Directory. בתרחיש הזה, כל רשומות ה-DNS של הדומיין משוכפלות באופן אוטומטי ב- Trusted Cloud ובסביבה המקומית, וזמינות לחיפוש בשתי הסביבות.
שימוש במנהרות VPN לאבטחת תעבורת LDAP
מערכת Active Directory משתמשת באופן נרחב בפרוטוקול LDAP. בניגוד לרוב הפרוטוקולים האחרים שבהם Active Directory משתמש, הנתונים ב-LDAP לא מוצפנים כברירת מחדל.
Trusted Cloud מוודא שתעבורת הנתונים בין מכונות וירטואליות מוצפנת, כך ששימוש ב-LDAP לא מוצפן ב-VPC מקובל. אם מחברים את ה-VPC לרשת מקומית, צריך לוודא שתנועת ה-LDAP מוחלפת רק בערוצים מהימנים.
אם משתמשים ב-Cloud VPN כדי לחבר את Trusted Cloud הרשת המקומית, תעבורת הנתונים מוצפנת באופן אוטומטי באמצעות IPSec ביןTrusted Cloud לנקודת הקצה של ה-VPN המקומית.
Cloud Interconnect ו-Partner Interconnect לא מספקים הצפנה. כדי להבטיח תקשורת מאובטחת, צריך ליצור מנהרת VPN בחיבור Interconnect באמצעות מכשיר VPN מ-Google Cloud Marketplace.
שימוש באימות סלקטיבי וב-AES לצורך אמון ביערות
כשיוצרים יחסי אמון בין יער Active Directory, עדיף להשתמש ביחסי אמון בין יערות במקום ביחסי אמון חיצוניים ולהשתמש בתכונות הבאות כדי לשפר את האבטחה:
מפעילים אימות סלקטיבי ביחסי אמון יוצאים ביער המשאבים. אימות סלקטיבי מבטיח שמשתמשים מהיער הארגוני לא יוכלו לגשת למשאבים ביער המשאבים, אלא אם ניתנה להם הרשאה מפורשת.
מפעילים אכיפה של גבולות היער להענקה מלאה של גישה ב-Kerberos באמונות נכנסות ביער הארגוני. התכונה הזו עוזרת למנוע התקפות של הסלמת הרשאות על ידי איסור על משאבים ביער המשאבים לבקש כרטיסי הענקת כרטיסים (TGT) ממשתמשים ביער הארגוני.
כשאתם יוצרים יחסי אמון, מפעילים את האפשרות הדומיין השני תומך בהצפנת AES של Kerberos. האפשרות הזו מבטיחה שהכרטיסים שמשמשים לאימות בין יערות יהיו מוצפנים באמצעות AES במקום האלגוריתם הפחות מאובטח RC4.
אבטחה
בקטע הבא מפורטות שיטות מומלצות שקשורות לאבטחה.
הימנעות מ Trusted Cloud הפרעה של אבטחה לאבטחת Active Directory
Active Directory מאפשר לכם לשלוט באופן מפורט באילו משתמשים תהיה גישה לאילו משאבים. כשמכונות נפרסות כמכונות וירטואליות ב-Compute Engine, ולמשתמשים יש גישה לפרויקט הבסיסי Trusted Cloud, צריך להביא בחשבון נתיבים נוספים שעשויים לאפשר למשתמש לגשת למכונה:
חברים בפרויקט שהוקצה להם התפקיד אדמין של מכונות Compute בפרויקט Trusted Cloud יכולים להשתמש בפונקציונליות של איפוס הסיסמה כדי ליצור חשבונות אדמין מקומיים. חשבונות אדמין מקומיים מהווים איום על האבטחה של הדומיין ב-Active Directory, כי אפשר להשתמש בהם כדי לפגוע בכללי המדיניות של הקבוצות או כדי להתקין תוכנה זדונית שעלולה לתעד את פרטי הכניסה לדומיין של משתמשים אחרים שמחוברים.
הוספת סקריפט לטעינה בזמן ההפעלה מאפשרת למשתמש בעל הרשאות בפרויקט להחדיר קוד זדוני למכונה וירטואלית, שיופעל בתור
nt authority\systemבפעם הבאה שהמכונה תופעל מחדש.באמצעות מסוף טורי, חברים בפרויקט עם הרשאות יכולים לגשת גם למסוף הניהול המיוחד של Windows (SAC). מערכת Windows מתייחסת להתחברות דרך SAC כהתחברות מקומית. לכן, אפשר להשתמש לרעה ב-SAC כדי לעקוף מדיניות שמבטלת כניסות באמצעות RDP, אבל לא מבטלת כניסות מקומיות.
חברים בפרויקט עם הרשאות יכולים להשתמש ב-SAC כדי להנפיק פקודה
crashdump, שעלולה לגרום לכתיבה של תמונת זיכרון (dump) בדיסק. דיווח כזה על זיכרון עשוי לכלול מידע רגיש ופרטי כניסה.אם מחברים את הדיסק הקבוע למכונה וירטואלית אחרת או משתמשים בתמונות מצב, חברים בפרויקט עם הרשאות יכולים לגשת לתוכן הדיסק, כולל אולי דיווחים על זיכרון (dumps), ממכונות שבהן למשתמש אין הרשאה להתחבר.
כשמשתמשים ב-Managed Microsoft AD, אתם מוגנים יותר מפני נתיבי הגישה הנוספים האלה כברירת מחדל. השירות לא מאפשר למשתמשים עם הרשאות בפרויקט לאפס את הסיסמה של האדמין בדומיין, להריץ סקריפטים לטעינה בזמן ההפעלה או לגשת למסוף הטורי במכונות הווירטואליות של בקרי הדומיין של AD.
כדי לצמצם עוד יותר את הסיכונים האלה, חשוב לוודא שההרשאות של IAM בפרויקטים שמכילים מכונות וירטואליות שצורפו לדומיין מנוהלות על בסיס הרשאות מינימליות. אפשר לצמצם עוד יותר את הסיכון באמצעות מדיניות הארגון, מדיניות הקבוצה ומכונות וירטואליות מוגנות:
משביתים את הגישה ליציאות הטורי באמצעות מדיניות ארגונית.
כדי למנוע יצירה של חשבונות אדמין מקומיים, משביתים את מנהל החשבון ומחילים מדיניות קבוצתית. מגדירים העדפה של קבצי INI במדיניות הקבוצה (Computer Configuration > Preferences > Windows Settings > Ini Files) כדי להחיל את ההגדרה הבאה:
- פעולה: עדכון
- נתיב הקובץ:
C:\Program Files\Google\Compute Engine\instance_configs.cfg - שם הקטע:
accountManager - שם הנכס:
disable - ערך המאפיין:
true
מחילים מדיניות קבוצה שמסירה חשבונות אדמין מקומיים ממכונות וירטואליות. משתמשים בפונקציונליות של משתמשים וקבוצות מקומיים (הגדרות המחשב > העדפות > הגדרות לוח הבקרה > משתמשים וקבוצות מקומיים) כדי להסיר את החברות בקבוצה אדמינים וקבוצות רגישות אחרות.
כדאי להשתמש במכונות וירטואליות מוגנות בשילוב עם הצפנת דיסק של BitLocker כדי למנוע ממשתמשים לא מורשים לקרוא קובצי snapshot או דיסק אחסון מתמיד.
הימנעות מהפרעה של אבטחת Active Directory לאבטחה של Trusted Cloud
בדומיין של Active Directory, המחשבים סומכים על בקרי הדומיין לטפל באימות ובהרשאה בשמם. אלא אם חלה עליו הגבלה של מדיניות קבוצה, מדיניות האבטחה המקומית של המכונה או אימות סלקטיבי, משתמש שהצליח להוכיח את הזהות שלו לאחד מאמצעי הבקרה של הדומיין יכול להתחבר לכל מכונה בדומיין.
היכולת של משתמשי Active Directory להתחבר לכל מכונה עשויה לאפשר לתוקפים לבצע תנועות רוחביות בדומיין. תנועה רוחבית כזו יכולה להוביל להסלמת הרשאות אם מכונות וירטואליות מסוימות פטורות מהגבלות חומת האש או משתמשות ב Trusted Cloud חשבונות שירות: פרטי הכניסה של חשבון שירות זמינים לכל התהליכים והמשתמשים במכונה וירטואלית. לכן, כל משתמש שיכול להשתמש ב-Active Directory כדי להתחבר למכונה יכול לגשת לפרטי הכניסה של חשבון השירות הזה כדי לקבל גישה לכל המשאבים Trusted Cloudשחשבון השירות קיבל גישה אליהם.
כשמגדירים את Managed Microsoft AD, השירות יוצר קבוצה כדי לאפשר למשתמשים ספציפיים להשתמש ב-RDP במכונות וירטואליות שמצורפות לדומיין.
כדי לצמצם את הסיכון לתנועה רוחבית, צריך לארגן את המשתמשים לפי רמות ניהול ולהשתמש בכללי המדיניות של הקבוצות דחיית הגישה למחשב הזה מהרשת ודחיית ההתחברות דרך שירותי שולחן עבודה מרוחק כדי להגביל את הגישה למכונות הווירטואליות לפי רמת הרמה.
בתצורה של יער משאבים, אפשר להשתמש באימות סלקטיבי כדי להגביל עוד יותר את קבוצת המשתמשים מיערים אחרים שמותר להם להתחבר למכונות הווירטואליות. כדי לפשט את ניהול ההרשאות לאימות סלקטיבי, תוכלו להתאים בין Trusted Cloud לבין מבני המשאבים של Active Directory: אם יחידות ארגוניות ב-Active Directory ממפות לפרויקטים ב- Trusted Cloud , תוכלו להעניק למשתמשים את הזכות לבצע אימות ברמה שתואמת לפרויקטTrusted Cloud .
במקרים שבהם אימות סלקטיבי או מדיניות קבוצות לא רלוונטיים, יוצרים חשבון שירות נפרד, מייצאים את המפתחות של חשבון השירות, שומרים אותם בדיסק המקומי של המכונה הווירטואלית או בספריית שיתוף קבצים, ומגינים עליהם באמצעות ACL של NTFS, כך שרק משתמשים מורשים ב-Active Directory יוכלו לקרוא את המפתחות ולהשתמש בהם.
שימוש בפרויקטים ייעודיים לבקרים של דומיינים
בקרי דומיינים ממלאים תפקיד קריטי באבטחה של דומיין Active Directory, ופגיעה בבקר דומיין אחד עלולה לגרום לפגיעה בכל יער Active Directory.
כדי להגביל את הסיכון לגישה לא מורשית, כדאי להשתמש בפרויקט נפרד כדי לפרוס את בקרי הדומיין, ולהעניק גישה לפרויקט הזה על בסיס 'הרשאות מינימליות'. Trusted Cloud כשיוצרים את הפרויקט, חשוב לזכור שחלק מההרשאות עשויות לעבור בירושה מתיקיות הורה. כדי להימנע מהענקת גישה בטעות בירושה, מומלץ ליצור את הפרויקט מחוץ להיררכיית התיקיות הרגילה.
כשמגדירים את כללי מדיניות ה-IAM לפרויקט, חשוב להקפיד להגביל את הגישה למכונות וירטואליות, לדיסקים הקבועים שמכילים את מסד הנתונים ntds.dit, ולכל מיקומי האחסון שעשויים להכיל גיבויים.
בנוסף לשימוש בכללי מדיניות IAM כדי להגביל את הגישה לפרויקט, הגנו על הפרויקט מפני מחיקה בטעות.
שימוש במכונות וירטואליות ובפרויקטים נפרדים לניהול Active Directory
כדי לנהל את Active Directory, צריך להיות לכם גישה לכלים כמו Active Directory Users and Computers או Active Directory Administrative Center. כדי להשתמש בכלים האלה, צריך להתחבר באמצעות חשבון דומיין בעל הרשאות, ולכן המכונה שבה מריצים את הכלים האלה היא יעד אטרקטיבי לגניבה של פרטי כניסה או לרישום הקשות.
כדי לצמצם את הסיכון שמתקפה תקבל פרטי כניסה עם הרשאות לדומיין, צריך להשתמש במכונות וירטואליות ייעודיות לניהול הדומיין ולנהל מכונות וירטואליות כאלה לניהול כמו תחנות עבודה עם הרשאות גישה:
משתמשים בכללי מדיניות קבוצה כדי לוודא שרק לקבוצת משנה נבחרת של משתמשים יש הרשאה להתחבר למכונות וירטואליות לניהול. אם הטמעתם ניהול מדורג, קבוצת המשתמשים הזו תואמת לרמה 0.
בדומה למסופי בקרת דומיינים, מכונות וירטואליות ניהוליות עלולות להיות בסיכון אם חברי הפרויקט יוצרים חשבונות אדמין מקומיים, נכנסים לחשבון דרך מסוף הטורי או משבשים את הדיסקים הקבועים שלהן. כדי להגביל את הסיכון לגישה לא מורשית, מומלץ להשתמש בפרויקטTrusted Cloud נפרד למכונות וירטואליות ניהוליות ולהעניק גישה לפרויקט הזה על בסיס הרשאות מינימליות.
אם אתם מתכננים לגשת למכונות וירטואליות ניהוליות מרשת מקומית באמצעות קישוריות היברידית, כדאי לפרוס מכונות וירטואליות ניהוליות ברשת משנה ייעודית של VPC. תת-רשת ייעודית למכונות וירטואליות לניהול מאפשרת להבחין טוב יותר בין מכונות וירטואליות ניהוליות לבין מכונות וירטואליות אחרות כשמגדירים את חומות האש המקומיות. אם אתם משתמשים ב-VPC משותף, השתמשו בהרשאות ברמת תת-הרשת כדי לוודא שרק לאדמינים עם הרשאות מוגברות מותר לפרוס מכונות וירטואליות ברשת המשנה לניהול. השיטה הזו עוזרת לוודא שאם חומות אש מקומיות מחילות כללים שונים על מכונות וירטואליות לניהול מאשר על מכונות וירטואליות אחרות, המשתמשים לא יוכלו לעקוף את כללי חומת האש על ידי הוספת מכונות וירטואליות ללא ניהול לרשת המשנה לניהול.
בנוסף, מומלץ להגביל את מדיניות הקבוצה שמנהלת את הגבלות הכניסה למכונות הווירטואליות לניהול לרשת המשנה לניהול. השיטה הזו אוכפת התאמה בין הגבלות הכניסה לחשבון (על סמך מדיניות קבוצה) לבין כללי חומת האש (על סמך תת-רשת/כתובת IP).
בנוסף לשימוש בכללי מדיניות IAM כדי להגביל את הגישה לפרויקט, הגנו על הפרויקט מפני מחיקה בטעות.
שימוש בכללי חומת אש לאבטחת שרתי בקרי דומיין
בקרי דומיינים חושפים מספר שירותים, כולל LDAP, DNS, Kerberos ו-RPC. בהתאם לתרחישי לדוגמה שלכם, יכול להיות שמכונות וירטואליות שנפרסו ב- Trusted Cloud, וגם מכונות שפועלות בארגון, יצטרכו גישה לקבוצות משנה שונות של השירותים האלה כדי לנצל את היתרונות של Active Directory.
כשמשתמשים ב-Managed 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 | משתמש מוגבל | חסום | חסום | משתמש מוגבל |
במסמכי העזרה של Microsoft מפורט מידע נוסף ושיטות מומלצות להטמעת מודל של רמה מנהלית ב-Active Directory.
כשמשתמשים במודל של רמה מנהלית ביער Active Directory, צריך לוודא שהשלמות שלו לא נפגעת מיחסי אמון ביער. אם יש ביער המהימן גם מודל ניהול מדורג, צריך להשתמש באימות סלקטיבי כדי לוודא שמשתמשים מהיער המהימן יורשו לגשת רק למשאבים באותו רמה:
אם לא הוטמעה ניהול מדורג ביער המהימן, צריך למפות את היער המהימן לרמה מסוימת ולהשתמש באימות סלקטיבי כדי לוודא שמשתמשים מהיער המהימן יורשו לגשת רק למשאבים ברמה הזו.
שימוש ב-VPC Service Controls ובגישה פרטית ל-Google למארחים מקומיים
ממשקי API מנוהלים של Microsoft AD מאפשרים לאפס את סיסמת האדמין ולבצע פעולות רגישות אחרות. לפריסות קריטיות בסביבת הייצור, מומלץ להפעיל את VPC Service Controls ולהשתמש ב-Private Google Access למארחים מקומיים כדי לשפר את האבטחה.
ניהול
בקטע הבא מפורטות שיטות מומלצות שקשורות לניהול Active Directory.
התאמה Trusted Cloud של מבני המשאבים ב-Active Directory
כשפורסים יער או דומיין חדשים של Active Directory ב-Trusted Cloud, צריך להגדיר מבנה של יחידה ארגונית (OU) כדי לארגן את המשאבים עם דומיין Active Directory. במקום לתכנן מבנה חדש לגמרי או להחיל את המבנה שבו אתם משתמשים בסביבה המקומית, כדאי ליצור מבנה של יחידה ארגונית שתואמת לTrusted Cloud היררכיית המשאבים:
אם אתם משתמשים במודל ניהול מדורג, ה-OU ברמה העליונה צריך לשקף את רמות הניהול שלכם.
בכל רמה, יוצרים OUs למשתמשים ולקבוצות. אם אתם מתכננים לנהל מספר גדול של משתמשים וקבוצות, כדאי ליצור קבוצות משנה של OU בהתאם.
לכל רמה, יוצרים OU
Projectsויוצרים OU משניים לכלTrusted Cloud פרויקט שמכיל משאבים של Active Directory. משתמשים ב-OU המשני הספציפי לפרויקט כדי לנהל חשבונות מחשב, חשבונות שירות או משאבים אחרים ב-Active Directory שתואמים למשאבים Trusted Cloudשל הפרויקט הרלוונטי. מוודאים שיש מיפוי אחד לאחד בין ה-OU לבין הפרויקטים.
התרשים הבא מציג היררכיה לדוגמה בהתאם לעקרונות האלה:
אם מספר הפרויקטים שמכילים משאבים של Active Directory הוא בינוני, תוכלו ליצור מבנה שטוח של יחידה ארגונית (OU) מתחת ל-OU Projects. אם אתם מתכוונים לנהל מספר גדול של פרויקטים ותכננתם את היררכיית המשאבים שלTrusted Cloud כך שתכלול כמה רמות של תיקיות, כדאי לשקף את מבנה התיקיות הזה מתחת ל-OU Projects.
יש כמה יתרונות להתאמה בין המבנה של ה-OU ב-Active Directory לבין היררכיית המשאבים: Trusted Cloud
כשמקצים הרשאות אדמין לפרויקט Trusted Cloud באמצעות כללי מדיניות IAM, יכול להיות שתצטרכו גם להעניק למשתמשים בפרויקט הרשאות מסוימות ב-Active Directory. לדוגמה, יכול להיות שאדמינים של Compute Engine יצטרכו להצטרף למכונות לדומיין במסגרת OU מסוימת. התאמה בין OU לבין Trusted Cloud פרויקטים מאפשרת להקצות הרשאות כאלה באותה רמת פירוט ב-Active Directory כמו ב- Trusted Cloud.
אם אתם מתכננים להשתמש באובייקטים של מדיניות קבוצה (GPO) כדי לנהל מחשבים, מבנה OU שמשקף את Trusted Cloud היררכיית המשאבים יעזור לכם לוודא ש-GPOs חלים באופן עקבי על כל המכונות הווירטואליות של פרויקט או תיקייה נתונים.
אם אתם משתמשים באמון בין יערות עם אימות מותנה, תוכלו להשתמש ב-OUs שתואמים ל Trusted Cloud פרויקטים כדי להעניק את ההרשאה Allowed to authenticate (מותר לבצע אימות) על בסיס פרויקט.
כשאתם מוחקים פרויקט ב- Trusted Cloud, אתם יכולים פשוט למחוק את ה-OU המשויך, וכך להפחית את הסיכון להשארת משאבים לא עדכניים בספרייה.
אם אתם מרגישים שצריך לשנות את מבנה ה-OU כך שלא יתאים למבנה הפרויקט, יכול להיות שזה סימן שמבנה הפרויקט שלכם מפורט מדי או מורכב מדי.
שימוש בשרתי הזמן של 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 של דומיין הבסיס של היער פורס מחוץ ל- Trusted Cloud.
אם מעבד ה-PDC מופעל מחוץ ל- Trusted Cloud, צריך להגדיר אותו להשתמש ב-time.google.com כמקור NTP.
לחלופין, אפשר לשחזר את התנהגות ברירת המחדל של Active Directory בנוגע לסנכרון הזמן עם אמולטור ה-PDC. לשם כך, צריך להגדיר מחדש את המכונות הווירטואליות ב-Compute Engine כך שישתמשו במקור ה-NTP DOMHIER ולהגדיר כללי חומת אש שיאפשרו תעבורת נתונים נכנסת של NTP (UDP/123) לבקרי הדומיינים.
איחוד של יומני ביקורת ומעקב אחריהם
כשפורסים את Active Directory ב- Trusted Cloud, האבטחה של יער Active Directory ושל הפרויקטים ב- Trusted Cloud קשורה זו לזו: פעילות חשודה ב-Active Directory וב-Windows עלולה לסכן את האבטחה של משאבים אחרים, באותו אופן שבו פעילות חשודה ב- Trusted Cloud עלולה לסכן את Active Directory.
יומני ביקורת עקביים הם כלי חשוב לזיהוי איומים או הגדרות שגויות בשלב מוקדם, ומאפשרים לשחזר ולבדוק פעילות קודמת. Cloud Audit Logging מאפשר לכם לתעד ולנתח יומני פעילות של אדמינים ויומני גישה לנתונים. באופן דומה, אפשר להשתמש ברישום ביומן של כללי חומת אש וביומני זרימה של VPC כדי לנתח את תעבורת הרשת. עם זאת, שירותי הפלטפורמה האלה לא מודעים לאירועים שקשורים לאבטחה שמתרחשים ב-Active Directory. כדי ליצור נתיב ביקורת עקבי שכולל גם אירועי ביקורת שקשורים לפלטפורמה וגם אירועי ביקורת שקשורים ל-Active Directory, צריך להתקין את הסוכן של Cloud Logging במסופי בקרת דומיין ובמכונות שצורפו לדומיין כדי לייצא יומני אירועי אבטחה של Windows אל Cloud Logging.
כברירת מחדל, יכול להיות שיומן אירועי האבטחה של Windows לא יתעד את כל האירועים שנחוצים לכם למטרות הביקורת. כדי לוודא שכל אירועי הביקורת הרלוונטיים מתועדים, כדאי לעיין בהמלצות של Microsoft לגבי הגדרת מדיניות ביקורת ומעקב אחר Active Directory כדי לזהות סימנים לפריצה.
כשעובדים עם נפח גדול של אירועים, קל לפספס אירועים קריטיים. כדי לא לפספס אירועים קריטיים, כדאי ליצור מדדים שמבוססים על יומנים לאירועים שעשויים להיות קריטיים או חשודים במיוחד, ולהגדיר התראות שיודיעו לכם כששיעור האירועים ישתנה או יעלה על ערכי הסף הקבילים.
המאמרים הבאים
כדאי לבדוק איזה דפוס לשימוש ב-Active Directory בסביבה היברידית מתאים לכם ביותר.
איך מגדירים את Active Directory למכונות וירטואליות כך שיצטרפו לדומיין באופן אוטומטי
כדאי לנסות Trusted Cloud תכונות אחרות. במדריכים שלנו.