תשתית ואבטחה Azure OpenAI
המאמר, תשתית ואבטחה Azure OpenAI הוא מאמר המשך למאמר הקודם של ״היבטי אבטחה בתשתית Azure OpenAI״ ונגיעה בפרטיות, שימוש ברעה, מעט על הצפנות ועוד מספר נושאים. כמו המאמר הקודם גם המאמר נוכחי מגיע מהיבטי אבטחה בלבד ולא ארכיקטורה.
https://atomic-temporary-126860513.wpcomstaging.com/azure-open-ai-security-intro/
כמו כל ספק ענן, Microsoft פועלת במסגרת מודל האחריות המשותף שבו Microsoft אחראית לאבטחת הענן, והלקוח, אחראי לאבטחה בתוך הענן. במילים פשוטות, יש בקרות שמיקרוסופט מנהלת מאחורי הקלעים ויש בקרות שמיקרוסופט שמה בידי הלקוח, ובאחריות הלקוח לאפשר את הבקרות הנדרשות.
כמו ברכיבים ומקרים אחרים בענן, גם כאן, Microsoft מתארת כיצד הנתונים מעובדים ומאובטחים עבור שירות Azure OpenAI בתיעוד הציבורי. בנוסף, כדאי לשים לב למאמרים והנספחים שנוגעים בהגנת הנתונים של המוצרים והסרוויסים, וכן, בתנאי מוצר ספציפיים. וכן במשאב לסקירה שמתועד בפורטל יחסי האמון של Microsoft Services.
בפורטל יחסי האמון, ניתן למצוא תיעוד הקשור לתאימות, כגון SOC-2 Type II, שמספק פרטים לגבי התהליכים והבקרות של Microsoft שבהם עושים שימוש בכדי להגן על נתונים. לצלילה עמוקה הרבה יותר, ניתן לסקור את FedRAMP SSP.
בכל הזדמנות אפשרית אני מעדיף להסתכל על דברים מנקודת מבט ארכיטקטונית ברמה גבוהה וכללית ומשם לרדת לרזולוציות הקטנות. לאחר שקראתי את התיעוד, סידרתי את נוף האבטחה של Azure יחד עם רכיבי מפתח הנדרשים בכל יישום Azure OpenAI כזה או אחר.
רכיבים בארכיטקטורה – מבט כללי
הרכיב הראשון הוא Azure OpenAI Service שהוא שירות במעטפת של השירותים הקוגניטיביים. Azure Cognitive Services כולל שירותים קיימים כגון אודיו לטקסט, ניתוח תמונות ועוד. זה מאפשר לקבוצת המוצר המנהלת את Azure OpenAI למנף תקנים קיימים שכבר אומצו עבור שירותים אחרים תחת המעטפת של השירותים הקוגניטיביים.
הרכיב הבא הוא Azure Key Vault (הכספת) – בתוך המופע הזה של Azure OpenAI, ישנם שלושה סוגים של נתונים שניתן לאחסן ברמת הלקוח. נתונים אלה מאוחסנים רק אם נבחרו להשתמש בתכונות ספציפיות ויכולות של השירות. נתונים אלה כוללים נתוני אימון שמוזנים למערכת כדי לכוונן מודלים מדויקים, ואת המודלים עצמם שמכוונים יחד עם ההנחיות (prompts) בכדי שנתוני האימון יהיו מאוחסנים רק אם בוחרים לאמן מודלים באופן עצמאי.
טיפ: ניתן להסיר את נתוני האימון ברגע שהמודל מכוון היטב.
אחוז קטן של לקוחות יצטרכו לעשות זאת מכיוון שהדגמים הכלולים כבר מאומנים בצורה יעילה שיכולה לתאים למצבים רבים. הנחיות והשלמות (prompts/completion) נשמרות כברירת מחדל למשך שלושים יום להערכה' וזאת בכדי להבטיח שהמודלים אינם משמשים למטרות שאינן הולמות. כמו גם, ישנה אפשרות לבטל את הסכמתם לסינון התוכן באמצעות התהליך המתואר בתיעוד ציבורי זה. במידה והסכמה זאת מבוטלת, נתונים אלה אינם מאוחסנים.
במידה ולקוח בוחר להשתמש בתכונה שיוצרת נתונים אלה, הנתונים מוצפנים במנוחה כברירת מחדל באמצעות מפתחות המנוהלים ע״י Microsoft. משמעות הדבר היא ש Microsoft מנהלת את ההרשאה והרוטציה של המפתחות. ללקוחות מוסדרים רבים יש דרישות רגולטוריות או מדיניות פנימית המחייבות לנהל הרשאות ורוטציה של כל המפתחות המשמשים להצפנת נתונים בסביבה שלהם. מסיבה זו, ספקי ענן כגון Microsoft מספקים את האפשרות להשתמש באפשרויות מסוג CMK (מפתחות מנוהלים ע״י לקוח). במצב CMK הם מאוחסנים בתוך Azure Key Vault בתוך חשבון לקוח, ולכן הלקוח שולט בהרשאה ובגישה למפתחות.
שירות Azure OpenAI תומך בשימוש של CMK כדי להגן על לפחות שתיים מתוך שלוש ערכות נתונים אלה. התיעוד אינו ברור אם ניתן להצפין את ההנחיות וההשלמות באמצעות CMK. כדאי לדעת שעדיין צריך לבקש גישה כדי לאשר את החשבון עבור CMK באמצעות שירות Azure OpenAI.
השלב הבא הוא תקשורת, נקודות קצה ושירות Azure Private DNS וכמו שאר השירותים במעטפת השירותים הקוגניטיביים, שירות OpenAI תומך בנקודות קצה פרטיות כאמצעי לנעילת גישה לרשת למרחב ה IP הפרטי בחשבון.
טיפ: מרחב השמות של DNS עבור השירות יהיה privatelink.openai.azure.com.
ראוי לציין כי שירות Azure Open AI תומך גם באפשרות של Firewall ברמת השירות. הדבר מאפשר להגביל את הגישה לשירות לקבוצה ספציפית של כתובות IP ציבוריות, כגון פרוקסי או לרשת וירטואלית ספציפית באמצעות נקודת קצה מסוג Service Endpoint.
רכיב נוסף הוא Azure Storage – כאשר בוחרים לבנות מודל הדרכה מכוונן היטב, ניתן להעלות נתוני הדרכה לרכיב Azure Storage בתוך החשבון. לאחר מכן, שירות Azure OpenAI יכול לאחזר את הנתונים.
לאחר מכן מגיע החלק של זהויות מנוהלות ובפרט Azure RBAC – עבור השירות, זהויות מנוהלות משמשות כדי לגשת לרכיבי CMK המאוחסנים בכספת. Azure RBAC ישמש לשליטה בגישה אל Azure OpenAI Services ולמפתחות המשמשים לקריאה לממשקי API של השירות.
עבור Azure OpenAI Service שבו פועלים המודלים, כדאי לנעול את השירות באמצעות Azure RBAC. אימות לשירות נתמך באמצעות קבוצה של מפתחות API שמצריכים לנהל את הרוטציה. לחלופין, אפשר להשתמש באימות Azure AD כדי להשיג אימות מול השירות.
צריך לזכור שאנו נדרשים לאבטח את הגישה לרשת ע״י הגבלת גישה לשירות באמצעות נקודות קצה פרטיות. הנתונים מוצפנים באופן אופציונלי באמצעות CMK המאוחסנים בכספת כדי לאפשר ללקוח לשלוט בגישה למפתחות, ולבצע רוטציה של המפתח. שירות Azure OpenAI מציע גם תיעוד ברמת יומנים ומדדים שניתן לספק ל Azure Storage, לסביבת עבודה של Log Analytics או בפרט אל Microsoft Sentinel באמצעות Diagnostic שהוגדר מראש.
טיפ: התיעוד של יומני הרישום הספציפיים לאבטחה יכולים להיות Audit וכן Prompts והשלמות.
כדאי לשים לב כי Azure Key Vault משמש למצבים בהם בוחרים להשתמש ב CMK ומשם ניתן לקבל גישה למפתחות הנשלטים באמצעות Azure RBAC וזהויות מנוהלות. במצב כזה, השירות של Azure OpenAI ניגש אל CMK באמצעות הזהות המנוהלת שהוקצתה לשירות. נכון לכתיבת המאמר, לא ניתן להשתמש באפשרות של Firewall ברמת הכספת כדי להגביל את הגישה.
טיפ: בהיבט אבטחה, השירות של Azure Cognitive Services אינו נחשב לשירות Azure מהימן עבור הכספת, ולכן לא אין אפשרות גישה לרשת כאשר Firewall של השירות זמין.
במידה ובוחרים לאחסן נתוני הדרכה ב Azure Storage לפני העלאה לשירות, ניתן לאבטח את הגישת באמצעות Azure RBAC או SAS. מכיוון שטוקנים מבוססי SAS הם מאתגרים לניהול, כדאי לשלוט בגישה לנתונים באמצעות Azure RBAC. נכון לכתיבת מאמר זה, שירות Azure OpenAI עצמו אינו תומך בשימוש בזהות מנוהלת עבור גישה אל Azure Storage, ולכן, משמעות הדבר היא שצריך לאבטח את הנתונים באמצעות SAS לגישה לא אנושית לנתונים במהלך ההעלאה.
שירות Azure OpenAI עדיין אינו תומך בזהות מנוהלת עבור גישה אל Azure Storage, ואין באפשרותו לנצל את כללי ההרשאה של השירות. משמעות הדבר היא שצריך לאפשר לכל הרשת הציבורית גישה לאחסון. האמצעים לאבטחת נתונים אלה יהיו SAS בעיקר עבור הגישה שמגיעה משירות Azure OpenAI.
ארכיטקטורה אופציונלית של Azure OpenAI – איך יכולה להיראות ארכיטקטורה אופציונלית? במצב כזה, כל הרכיבים הקשורים לפריסה ימוקמו בחשבון ייעודי מול וורקלואד ספציפי אחד או יותר הקשורים בינהם. הדבר כולל את התקשורת המכילה את נקודת הקצה הפרטית של Azure OpenAI, הזהות המנוהלת שהוקצתה לו, הכספת עם ההרשאות הספציפיות של אותו וורקלואד וזאת שמכילה את ה CMK. אותם מפתחות ישמשו להצפנת הנתונים המוחזקים בשירות Azure OpenAI וכן ברכיב Azure Storage שישמש להעלאת נתוני הדרכה לשירות.
שירות Azure OpenAI יאבטח את הגישה לרשת על סמך נקודת הקצה הפרטית. הן מול הכספת והן ברמת Azure Storage. הגישה לרשת תהיה פתוחה לרשתות ציבוריות. הגישה לנתונים עבור Azure Key Vault תהיה מאובטחת באמצעות אימות Azure AD ומדיניות מול השירות תהיה מבוססת על סמך Azure RBAC לצורך הרשאה. רכיב Azure Storage ישתמש באימות Azure AD וכן ב Azure RBAC כדי לשלוט בגישה עבור משתמשים אנושיים וב SAS כדי לשלוט בגישה מול Azure OpenAI.
מאמרים נוספים
