ארכיטקטורת Zero Trust לסביבות ענן והיברידיות

SEYA Group מתכננת גישת Zero Trust לסביבות ענן והיברידיות: כל בקשה נבדקת לפי זהות, מכשיר וההרשאה המינימלית שהמשימה דורשת, בין אם המבקש הוא אדם, Pipeline או workload. העבודה היא מפת דרכים בשלבים שהצוות שלכם יכול להריץ, לא מוצר שגורם לכם לקרוע את הרשת כדי להתקין אותו. הפרויקטים מובלים על ידי מהנדסים בכירים ממשרדנו ב-Vancouver.

למי זה מיועד

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

מה תקבלו

• זהות. מפת זהות כוח העבודה, תפקידים מורשים וחשבונות שירות, והמלצה אילו גישות צריכות להיות just-in-time ולא קבועות. אנחנו משתמשים במערכת הזהות שכבר יש לכם.
• מכשיר. האותות שאפשר לאסוף בפועל היום (מכשיר מנוהל, בדיקת מצב או בלי שניהם) ולאילו יישומים צריך לסרב לגישה ממכשיר שנכשל בהם. אנחנו לא ממציאים סביבת מכשירים שאתם לא מפעילים.
• פיצול רשת. אילו נתיבים צריכים להישאר, אילו צריכים להיות מודעים לזהות ואילו כללים רחבים כדאי לסגור. הפיצול נכתב מול החשבונות בהיקף, לא מול תרשים greenfield שמתעלם מה-VPC או ה-VNet הנוכחיים.
• זהות workload. איך Pipeline, Pod או שירות מוכיחים מי הם בלי מפתח ארוך-חיים במאגר. זה החלק שמחבר בין Zero Trust ל- DevSecOps.
• מפת דרכים בשלבים. מה משתנה בשלב הראשון בלי לעצור את המסירה, מה מחכה לבעלי יישום ומה דוחים במפורש.

איך פרויקט מתנהל

• שלב 1 — לראות את הגישה. מלאי של זהויות אנושיות ו-workload והנתיבים לסביבות שאתם מגדירים.
• שלב 2 — לסגור את הפערים הבולטים. הסרה או הגבלת זמן של admin קבוע, הגבלה של נתיבי ניהול ציבוריים, ואימות שרישום לוגים פועל. השינויים נסקרים עם המפעילים שלכם לפני הפריסה.
• שלב 3 — המודל היציב. מדיניות לחשבונות ול-workload חדשים כדי שהפרויקט הבא לא יחזור על התבנית הישנה. הגדרות שגויות שנמצאות בדרך מטופלות בסקירת מצב אבטחת הענן ולא נשארות רק בשקופית.

מה צריך להיות מוכן

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

הדוגמה הכי קרובה שפורסמה היא הבסיס של LiveRamp ב-Google Cloud, שהפריד סביבות והחיל IAM מפורט. זה היה תכנון בסיס לענן ראשון, והחלטות הזהות הן החלק ששייך לעמוד הזה.

שאלות נפוצות

האם חייבים להסיר את ה-VPN בשלב הראשון?

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

האם זה יישום של מוצר Zero Trust?

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

איך זה קשור לסקירת אבטחת ענן?

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

לתיאום הערכת אבטחת ענן אם נדרש מכם לענות על גישה עם הרשאות מורחבות או על ה-VPN המשרדי.