הארכיטקטורה שגרמה ל-CISO לאשר צ׳אט AI בפגישה אחת

בקצרה: CISO מסקטור הביטחון עבר על הארכיטקטורה פעם אחת ואישר. VNet אחד, Private Endpoints בכל מקום, שבע שכבות אבטחה לכל בקשה, אפס סיסמאות מאוחסנות. ככה בנינו את זה.

הפער בין "דמו של AI" ל"מאושר על ידי CISO"

כל ארגון רוצה AI. רוב צוותי האבטחה לא יכולים לאשר את מה שמונח על השולחן. זה לא שהטכנולוגיה לא בשלה — GPT-4o באמת מרשים. הפער הוא במה שיושב מסביב למודל: הרשת, שכבת הזהויות, גבולות הנתונים, מסלול הביקורת.

CISO שמעריך פריסת AI צריך לענות על שלוש שאלות: לאן הנתונים הולכים? למי יש גישה לפרומפטים? מה קורה כשמישהו מדביק מסמך פנימי בצ׳אט? לקבל את התשובות הנכונות זה קשה. זה דורש החלטות ארכיטקטוניות שרוב מימושי ה-AI לא תוכננו לטפל בהן — כי הם נבנו למהירות עד לדמו, לא למהירות עד לפרודקשן.

בתחילת השנה, לקוח מסקטור הביטחון ביקש מאיתנו לסגור את הפער. הבריף: צ׳אט AI פנימי שמנהלי אבטחה יחתמו עליו לפני שהוא נוגע במשתמש אחד. לא בסופו של דבר. לא אחרי ספרינט הקשחה. לפני ההשקה.

ככה הארכיטקטורה נראית, ולמה כל החלטה חשובה.

הסטאק: מה נמצא בתוך הפרימטר

המערכת רצה על Azure. הבחירה נבעה מכך שתשתית הזהויות של הלקוח כבר הייתה על Microsoft Entra ID, והם דרשו ערבויות לשמירת נתונים באזור ספציפי.

הרכיבים המרכזיים:

• Next.js 14 (App Router) כפריימוורק האפליקציה, עם streaming SSE לתגובות צ׳אט בזמן אמת
• Azure AI Foundry עם GPT-4o ו-text-embedding-3-small, דרך ה-API הארגוני של Azure (לא ה-endpoint הציבורי של OpenAI)
• Azure Cosmos DB (Serverless) לשמירת שיחות
• Azure AI Search עם דירוג סמנטי ל-RAG על המסמכים הפנימיים של הלקוח
• Tavily API לחיפוש אינטרנט בזמן אמת כשהמודל צריך מידע עדכני, מגודר על ידי AI Policy Guard
• Microsoft Entra ID עם MSAL PKCE ל-SSO מול ספריית הארגון הקיימת
• 100% Terraform (azurerm ~> 4.0) לכל פיסת תשתית, מה-VNet ועד אזורי ה-DNS

ההחלטה הארכיטקטונית המרכזית: הכל רץ בתוך VNet אחד של Azure (10.0.0.0/16). בלי חריגים.

רשת Zero-Trust: למה זה חשוב יותר מהמודל

כששואלים ספקי AI ארגוניים על אבטחה, הם מדברים על פילטרי התוכן של המודל. זה כמו לשאול על הכספת של הבנק ולקבל תשובה על איכות המנעולים של ארונות התיוק.

ארכיטקטורת הרשת היא המקום שבו אבטחה ארגונית אמיתית חיה. ככה שלנו נראית.

מבנה ה-VNet

ארבעה Subnets, כל אחד עם מטרה ספציפית:

• snet-app — איפה אפליקציית ה-Next.js רצה
• snet-private-endpoints — subnet ייעודי לכל ה-Private Endpoints
• snet-agw — ה-subnet של Application Gateway WAF v2
• AzureBastionSubnet — גישה ניהולית מאובטחת (בלי SSH מהאינטרנט)

Private Endpoints לכל שירות

כל שירות PaaS — AI Foundry, Cosmos DB, AI Search, Key Vault, Container Registry — נגיש אך ורק דרך Azure Private Endpoints. גישה ציבורית מבוטלת בכל שירות.

מה זה אומר בפועל: כשהאפליקציה קוראת ל-GPT-4o, הבקשה עוברת דרך רשת השדרה של Microsoft עם כתובת IP פרטית. היא אף פעם לא נוגעת באינטרנט הציבורי. אותו דבר חל על שאילתות לבסיס הנתונים, בקשות חיפוש ושליפת סודות.

CISO יכול להסתכל על הארכיטקטורה הזו ולצייר קו אחד מסביבה. הכל בתוך הקו פרטי. הרכיב הציבורי היחיד הוא ה-Application Gateway עם WAF v2 שמריץ כללי OWASP 3.2. זו הדלת היחידה לתוך המערכת, והיא בודקת כל בקשה לפני שנכנסת.

למה זה חשוב לארגון שלכם

רוב פריסות ה-AI ה"ארגוניות" מנתבות קריאות API באינטרנט הציבורי עם הצפנת TLS. זה מאובטח בתעבורה, אבל הפרומפטים שלכם — שאולי מכילים מידע קנייני, מסמכים פנימיים או תוכניות אסטרטגיות — עוברים דרך תשתית שאתם לא שולטים בה. Private Endpoints מבטלים את החשיפה הזו לחלוטין.

צינור אבטחה בשבע שכבות

בידוד רשת שומר על איומים בחוץ. צינור האבטחה מטפל באיומים שנכנסים דרך הדלת הראשית — משתמשים מאומתים שמדביקים מידע רגיש, מנסים prompt injection, או מפעילים הפרות של מדיניות תוכן.

כל בקשה עוברת שבע שכבות לפני שמודל ה-AI רואה אותה:

שכבה 1: הגבלת קצב

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

שכבה 2: DLP קלט

לפני שפרומפט כלשהו מגיע למודל, סריקת דפוסים אוטומטית מחפשת מידע רגיש — מספרי כרטיסי אשראי, פורמטים של תעודות זהות, סמנים של מסמכים מסווגים. התאמות נחסמות עם הודעת שגיאה ברורה למשתמש, והאירוע נרשם.

שכבה 3: זיהוי Prompt Injection

מנוע זיהוי עם מעל תריסר דפוסי regex מזהה ניסיונות prompt injection נפוצים — "ignore previous instructions", התקפות החלפת תפקיד, מניפולציית מפרידים. בקשות שמסומנות נחסמות ונרשמות לסקירת אבטחה.

שכבה 4: AI Policy Guard

השכבה הזו אוכפת מדיניות ארגונית על מה שה-AI יכול ומה שלא יכול לדון. בקשות שעוברות DLP ובדיקות injection נבדקות מול סט מדיניות מוגדר לפני שמגיעות למודל. גם בקשות חיפוש אינטרנט (דרך Tavily) עוברות דרך השער הזה.

שכבה 5: DLP פלט

תגובת המודל מקבלת את אותו טיפול DLP כמו הקלט. אם המודל מייצר פלט שמכיל דפוסים רגישים (מה שיכול לקרות עם RAG על מסמכים פנימיים), התגובה נחסמת לפני שמגיעה למשתמש.

שכבה 6: כותרות CSP

Content Security Policy מונעות התקפות XSS ומגבילות אילו משאבים חיצוניים האפליקציה יכולה לטעון. זו הגנה ברמת הדפדפן.

שכבה 7: הגנת CSRF

טוקני CSRF על כל בקשה שמשנה מצב מונעים מתוקפים להערים על משתמשים מאומתים לבצע קריאות API לא מכוונות.

הצינור מסודר בכוונה. בדיקות זולות (הגבלת קצב, התאמת דפוסים) רצות ראשונות. בדיקות יקרות (AI Policy Guard) רצות אחרונות. התקפת brute-force נעצרת בשכבה 1, בלי להגיע לשכבות שעולות זמן חישוב.

זהויות, גישה, ולמה אנחנו לא מאחסנים סיסמאות

אימות דרך Microsoft Entra ID עם MSAL PKCE — אותו SSO שעובדי הלקוח משתמשים בו לכל מערכת פנימית אחרת. בלי סיסמאות חדשות, בלי מאגר זהויות נפרד.

בתוך האפליקציה, תפקידי Entra ID שולטים על מי ניגש למה. מנהלים רואים אנליטיקות שימוש. משתמשים רגילים רואים את הצ׳אט. התפקידים ממופים למבנה הארגוני הקיים.

לאימות שירות-לשירות, כל משאב Azure משתמש ב-Managed Identities. האפליקציה מתקשרת עם Cosmos DB, AI Search ו-AI Foundry עם גישה מבוססת זהות. בלי connection strings עם סיסמאות. בלי מפתחות API בקבצי config. Azure Key Vault מחזיק את הסודות הספורים של צד שלישי (כמו מפתח ה-Tavily API), וגם ל-Key Vault ניגשים דרך Managed Identity.

התוצאה: אפס סיסמאות מאוחסנות בכל מקום בקוד או בתצורת הפריסה. אם מישהו מכפיל את הריפו, הוא לא מקבל כלום שימושי.

מסלול ביקורת (ומה אנחנו בכוונה לא רושמים)

כל אירוע רלוונטי לאבטחה — אימות, החלטות הרשאה, פגיעות בהגבלת קצב, חסימות DLP, הפעלות Policy Guard — נרשם כאירוע מובנה ב-Application Insights. צוותי אבטחה יכולים לשלוח שאילתות, לבנות התראות ולחקור אירועים.

מה אנחנו לא רושמים: טקסט שיחות. זו החלטת עיצוב מכוונת של פרטיות מובנית. תוכן שיחות נשאר ב-Cosmos DB, מוגן באותם בידוד רשת ובקרות גישה. הלוגים תופסים את המטא-נתונים (מי, מתי, מה סוג הפעולה, איזו שכבת אבטחה ירתה) בלי לתפוס את התוכן. אנליסט אבטחה יכול לראות שמשתמש X הפעיל חסימת DLP ב-14:32 בלי לראות מה הוא הקליד.

שימושיות: RAG על מסמכים ארגוניים

אבטחה בלי שימושיות זה פשוט פיירוול יקר. המערכת שימושית בגלל RAG — retrieval-augmented generation על מאגר המסמכים הפנימי של הלקוח.

Azure AI Search עם דירוג סמנטי מנדקס את מסמכי הלקוח. כשמשתמש שואל שאלה, המערכת מריצה צינור מקבילי: חיפוש סמנטי על אינדקס המסמכים, דחיסת היסטוריה להקשר שיחה, ואינפרנס של המודל. התוצאות מתכנסות לתגובה מעוגנת בנתונים האמיתיים של הארגון.

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

חיפוש אינטרנט דרך Tavily מוסיף מידע בזמן אמת כשהמודל קובע שהוא צריך נתונים עדכניים. כל בקשת חיפוש אינטרנט עוברת דרך שער ה-AI Policy Guard. המודל לא יכול לחפש שום דבר שהארגון לא אישר כנושא ניתן לחיפוש.

מה מבדיל את זה מ"סתם להשתמש ב-Azure OpenAI"

זו השאלה שאנחנו מקבלים הכי הרבה. Azure OpenAI Service כבר מציע Private Endpoints וסינון תוכן. למה לבנות את כל זה מעל?

ההשוואה:

הפער בין "להשתמש ב-Azure OpenAI" לבין "לבנות מערכת AI מאובטחת על Azure" הוא כמו ההבדל בין לקנות מנעול לבין לבנות מערכת אבטחה. המנעול הוא רכיב. המערכת היא הארכיטקטורה שמסביבו.

פריסה ושחזור

כל התשתית נפרסת מ-`terraform apply` יחיד. כל משאב — VNet, subnets, אזורי Private DNS, Private Endpoints, App Service, Cosmos DB, AI Search, Key Vault, Application Gateway, מדיניות WAF — מוגדר בקוד ומנוהל בגרסאות.

CI/CD רץ דרך GitHub Actions עם פדרציית OIDC. בלי credentials ארוכי חיים ב-pipeline. זהות הפריסה מתאמתת ל-Azure עם טוקנים פדרטיביים שפוגעים אוטומטית.

למה זה חשוב: אם הלקוח צריך לבנות מחדש את כל הסביבה באזור Azure אחר (DR, ציות, או הרחבה גאוגרפית), זה שינוי פרמטר והרצת Terraform. הארכיטקטורה מתועדת בקוד, לא בזיכרון של מישהו או בדף wiki שלא עודכן מאז הפריסה הראשונית.

שאלות נפוצות

כמה זמן לוקח לבנות ארכיטקטורה כזו? הפרויקט שלנו ארך כ-10 שבועות מתחילת עבודה ועד פרודקשן, עם צוות של שני מהנדסים בכירים. רוב הזמן בלוח השנה הלך על סבבי סקירת אבטחה עם הצוות של הלקוח, לא על כתיבת קוד. תשתית ה-Terraform לוקחת בערך שבוע. האפליקציה וצינור האבטחה לוקחים 4-6 שבועות. בדיקות, הקשחה ותיעוד ממלאים את השאר.

זה עובד עם AWS או GCP במקום Azure? דפוסי הארכיטקטורה — בידוד VNet, Private Endpoints, Managed Identities, אבטחה שכבתית — קיימים בכל שלושת העננים. המימוש הספציפי ישתנה (AWS PrivateLink במקום Azure Private Endpoints, IAM Roles במקום Managed Identities, Bedrock במקום AI Foundry), אבל מודל האבטחה מתרגם ישירות. בחרנו Azure כאן כי תשתית הזהויות והציות של הלקוח כבר הייתה מבוססת Microsoft.

לאילו מסגרות ציות הארכיטקטורה מתאימה? השילוב של בידוד רשת, לוגים לביקורת, DLP, בקרות גישה ותשתית כקוד מספק את הבקרות הטכניות הנדרשות ל-SOC 2, ISO 27001 ודרישות אבטחה ביטחוניות. גישת הפרטיות המובנית (בלי רישום טקסט שיחות בדיאגנוסטיקה) תומכת גם בציות ל-GDPR ו-CCPA.

אפשר להשתמש במודלים בקוד פתוח במקום GPT-4o? כן. הארכיטקטורה לא תלויה במודלים של OpenAI. Azure AI Foundry תומך במספר משפחות מודלים, וצינור האבטחה (DLP, זיהוי prompt injection, סריקת פלט) עובד ללא תלות באיזה מודל מעבד את הבקשה.

כמה זה עולה בהשוואה למנוי ChatGPT Enterprise? ChatGPT Enterprise עולה בערך 60 דולר למשתמש לחודש. הארכיטקטורה הזו עולה יותר מראש (תשתית, הנדסה, פריסה) אבל נותנת שליטה מלאה על הנתונים, מדיניות האבטחה וההתנהגות של ה-AI. לארגונים שמטפלים במידע מסווג או מפוקח, ההשוואה היא לא באמת עלות — אלא האם אפשר בכלל להשתמש ב-AI בלי הרמה הזו של שליטה. רוב הארגונים בביטחון, בריאות ופיננסים לא יכולים. אם אתם מעריכים פריסת AI מאובטחת לארגון שלכם, נשמח לשיחה.