ארכיטקטורה לדוגמה של פתרון: פריסת תכונות מבוססות-AI גנרטיבי של Elastic Stack ב-GDC עם air gap

סקירה כללית

בארכיטקטורה הזו מוגדר העיצוב הקונספטואלי לפריסת Elastic Stack‏ (Elasticsearch ו-Kibana) ב-Google Distributed Cloud (GDC) עם air gap, ולשילוב שלו עם שירות של מודל שפה גדול (LLM) כדי להפעיל את התכונות של Elastic שמבוססות על AI גנרטיבי.

‫Elastic Stack היא פלטפורמה פופולרית לחיפוש, לתצפית ולניתוח אבטחה. הגרסאות האחרונות של Elastic מוסיפות יכולות מבוססות-AI גנרטיבי ל-Kibana, כולל Elastic AI Agent, סוכני AI בהתאמה אישית שנוצרו באמצעות Agent Builder ו-Attack Discovery. התכונות האלה מסתמכות על מודל שפה גדול (LLM) כדי לתרגם בקשות בשפה טבעית לשאילתות Elasticsearch, לתזמר קריאות לכלי בכמה שלבים ולקשר בין התראות אבטחה.

בארכיטקטורה הזו, Elastic Stack נפרס באמצעות מפעיל Elastic Cloud on Kubernetes (ECK) הרשמי שזמין ב-Marketplace של GDC עם air gap, ומחבר את Kibana לנקודת קצה להסקת LLM שמתארחת בתוך גבולות GDC, או לשירות Gemini המנוהל ב-GDC או לשרת הסקה בניהול עצמי שתואם ל-OpenAI כמו Ollama או vLLM.

תכונות ויכולות

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

  • ניהול מחזור חיים מבוסס-Marketplace: מתקינים את מפעיל ה-ECK מ-Marketplace של GDC עם air gap במרחב השמות של הפרויקט באשכול משותף, ומאפשרים לו לבצע אוטומציה של ההקצאה, ההגדרה וההתאמה של המשאבים המותאמים אישית של Elasticsearch ו-Kibana.
  • חקירת נתונים בשפה טבעית: שימוש בסוכן Elastic AI כדי לחקור נתונים ב-Elasticsearch בשפה טבעית. הנציג מגלה אינדקסים ומיפויים, יוצר ומריץ שאילתות ES|QL ומסנתז ממצאים בלי לדרוש ידע קודם על הסכימה הבסיסית.
  • סוכנים בהתאמה אישית ותהליכי עבודה אוטומטיים: אתם יכולים להשתמש ב-Agent Builder כדי ליצור סוכנים ייעודיים שמשלבים הוראות בהתאמה אישית עם כלים מובנים, כלי ES|QL בהתאמה אישית ותהליכי עבודה של Kibana (לדוגמה, פתיחה אוטומטית של Kibana Security Cases עם ממצאי חקירה).
  • התאמה בין התראות אבטחה באמצעות AI: אתם יכולים להשתמש ב-Attack Discovery כדי לנתח התראות פתוחות של Elastic Security, למפות אותן למסגרת MITRE ATT&CK ולהתאים בין התראות, כתובות IP וחשבונות משתמשים קשורים לשרשראות של מתקפות.
  • תאימות ל-Air-Gap: קובצי האימג' של הקונטיינרים של מפעיל ה-ECK, של Elasticsearch ושל Kibana נשלפים מהמרשם המקומי של GDC Harbor, וכל תנועת ההסקה של ה-LLM נשארת ברשת הפנימית של GDC.
  • ממשקי קצה עורפי של LLM שניתנים לחיבור: מחברים את Kibana ל-Gemini מנוהל ב-GDC או לכל שרת הסקה בניהול עצמי שחושף ממשק API של /v1/chat/completions שתואם ל-OpenAI דרך מחבר OpenAI של Kibana.

עקרונות ארכיטקטוניים

  • מודל אחריות משותפת: GDC מספק את האשכול המשותף, חבילת שטחי פרסום ייעודית לזירות מסחר, מרשם Harbor ורשתות. הלקוח מפעיל את פריסת Elastic Stack, מנהל את הרישוי של Elastic ואחראי לבחירה ולהפעלה של שירות ה-LLM בניהול עצמי (אם משתמשים בו).
  • ריבונות הנתונים: כל נתוני התפעול והאבטחה, ההנחיות והתשובות של המודל נשארים בגבולות של GDC עם air gap. לא נשלחת תנועה לשירותי LLM ציבוריים או לשירותים שמתארחים ב-Elastic.
  • פעולות מבוססות-ענן: שימוש בתבנית של אופרטור Kubernetes כדי לנהל עומסי עבודה של Elastic עם שמירת מצב (stateful) באופן הצהרתי, וכך להבטיח פריסות עקביות וניתנות לשחזור.
  • תקנון פרוטוקולים: מתבסס על ה-API להשלמת צ'אט שתואם ל-OpenAI ונתמך באופן נרחב, עם קריאה להפעלת פונקציות מקוריות, ומפריד את Kibana מכל מנוע היקש או ספק מודלים ספציפי.

ארכיטקטורה

הארכיטקטורה מורכבת מפריסת Elastic Stack שמנוהלת על ידי מפעיל ECK בתוך מרחב שמות של פרויקט באשכול משתמשים משותף של GDC. ‫Kibana מתקשרת דרך הרשת הפנימית של GDC עם נקודת קצה להסקת LLM.

דיאגרמת ארכיטקטורה של Elastic Stack.

הרכיבים העיקריים בארכיטקטורה הזו:

  • אשכול משותף ב-GDC: אשכול Kubernetes משותף ברמת הארגון שמצורף לכמה פרויקטים, ומארח חבילות תוכנה ועומסי עבודה של אפליקציות ב-GDC Marketplace.
  • פרויקט GDC: מרחב השמות של הפרויקט באשכול המשותף שמבודד את מפעיל ה-ECK, אשכול Elasticsearch, מכונת Kibana, ו-Kubernetes Secrets ו-NetworkPolicies המשויכים.
  • ‫Elastic Cloud on Kubernetes (ECK) operator: מותקן מ-GDC Marketplace במרחב השמות של הפרויקט. האופרטור מנהל את המשאבים המותאמים אישית Elasticsearch ו-Kibana, ומתאים את רישיון Elastic שנדרש לתכונות מבוססות-AI גנרטיבי ולמחברים חיצוניים של מודלי שפה גדולים (LLM).
  • ‫Elasticsearch: מאחסן ומאנדקס נתונים תפעוליים ונתוני אבטחה, ומריץ שאילתות חיפוש ושאילתות ES|QL שנוצרו על ידי סוכנים ותכונות מבוססות-AI של Kibana.
  • ‫Kibana: מארח את התכונות מבוססות-ה-AI הגנרטיבי של Elastic (סוכן ה-AI של Elastic,‏ Agent Builder ו-Attack Discovery) ומנהל את מחברי הפעולות של ה-LLM, שמתזמרים קריאות לכלי בכמה שלבים בין המשתמש, Elasticsearch ושירות ה-LLM.
  • שירות LLM: שירות LLM מנוהל (כמו Gemini ב-GDC) או שרת הסקה בניהול עצמי (כמו Ollama או vLLM) שמספק ל-Kibana יכולות של השלמת צ'אט והפעלת כלים ברשת הפנימית של GDC.

מושגים וטכנולוגיות

בקטע הזה מפורטים הרכיבים הפונקציונליים, האחריות שלהם והאופן שבו הם מתקשרים בתוך המערכת.

תשתית ופלטפורמה

  • אשכול משותף של GDC: סביבת המחשוב הראשית שבה נמצאים ה-pods של מפעיל ה-ECK, של Elasticsearch ושל Kibana במרחב שמות של פרויקט.
  • ‫GDC Marketplace: הקטלוג שמשמש להתקנה ולשדרוג של חבילת Elastic Marketplace, שרושמת את Elastic CustomResourceDefinitions ומבצעת פריסה של elastic-operator StatefulSet.
  • ‫Harbor Registry: המקור המאובטח והמקומי לנתונים של קובצי האימג' של הקונטיינרים של ECK operator,‏ Elasticsearch ו-Kibana בסביבה עם air gap.
  • אחסון מתמיד: PersistentVolumeClaims שמוקצים דרך Elasticsearch volumeClaimTemplates מספקים אחסון בלוקים עמיד לנתוני Elasticsearch.
  • רשת GDC: שירותי LoadBalancer חושפים את Elasticsearch (יציאה 9200) ואת Kibana (יציאה 5601), ומשאבי NetworkPolicy ו-ProjectNetworkPolicy גלובליים של Kubernetes מנהלים את התנועה הנכנסת ואת התנועה בין פרויקטים, כולל קישוריות לשירות LLM.

שירותים ולוגיקה

  • ‫ECK operator: הבקר שצופה במשאבים בהתאמה אישית של Elasticsearch ו-Kibana ומתאים אותם ל-StatefulSets, ל-Deployments, ל-Services ול-Secrets. ה-license-controller שלו מתאים באופן רציף בין רישיון האשכול לבין סודות הרישיון במרחב השמות של המפעיל.
  • ‫Elastic AI Agent: הסוכן בממשק שיחה שמוגדר כברירת מחדל ב-Kibana. הוא משתמש בכלים מובנים של Agent Builder‏ (platform.core.list_indices,‏ platform.core.get_index_mapping,‏ platform.core.search ו-platform.core.execute_esql) כדי לגלות נתונים, ליצור ES|QL ולסכם תוצאות.
  • ‫Agent Builder: המסגרת ליצירת סוכנים בהתאמה אישית שמשלבים הוראות מערכת בהתאמה אישית עם כלים מובנים וכלים שהוגדרו על ידי המשתמש (esql,‏ index_search,‏ workflow ו-mcp).
  • ‫Kibana Workflows: תהליכי אוטומציה דקלרטיביים שמוגדרים ב-YAML (לדוגמה, cases.createCase) שאפשר לרשום ככלים של Agent Builder כדי לאפשר לסוכנים לבצע פעולות כמו פתיחת Kibana Security Cases.
  • ‫Attack Discovery: אמצעי אבטחה של Elastic Security ששולח הקשר אנונימי של התראות ל-LLM כדי לקשר בין התראות מהאינדקס של .alerts-security.alerts-default לשרשראות של מתקפות שממופות לטקטיקות של MITRE ATT&CK.
  • שירות LLM: מספק השלמות צ'אט מותאמות להוראות עם תמיכה מובנית בקריאה לפונקציות. המודל צריך ליצור באופן מהימן קריאות תקינות לכלים, שאילתות ES|QL ו-JSON מובנה.

זרימת נתונים וממשקים

  • ‫OpenAI-compatible chat completions API (/v1/chat/completions): הממשק בין המחבר של OpenAI (.gen-ai) ב-Kibana לבין שירות ה-LLM, שמוגדר עם הספק Other (OpenAI Compatible Service), עם קריאה להפעלת פונקציות מותאמות ועם סטרימינג של אירועים שנשלחים מהשרת.
  • ממשקי API של Elasticsearch REST ו-ES|QL: משמשים את Kibana והסוכנים שלה כדי לבדוק מיפויים, להריץ חיפושים ולבצע צבירות של ES|QL.
  • ‫Kibana REST APIs: משמש לניהול תוכנות מחשב של מחברים (/api/actions), סוכנים וכלים (/api/agent_builder), תהליכי עבודה (/api/workflows), כללי זיהוי (/api/detection_engine) וזיהוי התקפות (/api/attack_discovery).
  • ‫HTTPS עם אימות מובנה: נקודות הקצה של Elasticsearch ו-Kibana מוגשות דרך TLS באמצעות אישורים שנוצרו על ידי ECK, עם פרטי כניסה שמאוחסנים ב-Kubernetes Secrets שמנוהלים על ידי ECK.

לתשומת ליבכם

  • יכולת התאמה לעומס וביצועים:
    • צריך להתאים את בקשות המשאבים, המגבלות, מספר הצמתים וגודלי האחסון של Elasticsearch ו-Kibana מערכי ברירת המחדל של ההערכה, כך שיתאימו לנפחי הנתונים בסביבת הייצור ולמספר השאילתות בו-זמנית.
    • המחבר של Kibana ל-OpenAI אוכף זמן קצוב לתפוגה של 60 שניות כברירת מחדל לכל סבב סטרימינג. כדי שכל תור יהיה במסגרת המגבלה הזו, שירות ה-LLM צריך לפעול בהאצת GPU עם אופטימיזציות כמו Flash Attention.
    • תור אחד של נציג יכול להפעיל קריאות משנה מקוננות של LLM. שרת ההסקה צריך לנהל כמה משבצות מקבילות של מטמון KV (לדוגמה, OLLAMA_NUM_PARALLEL=2) כדי למנוע מקריאות משנה להסיר את ההקשר שנשמר במטמון של השיחה הראשית.
  • דרישות ממודל ה-LLM:
    • המודל צריך להיות מכוונן לפי הוראות עם תמיכה מובנית בקריאה להפעלת פונקציות. צריך להפעיל קריאה להפעלת פונקציות מקוריות במחבר של Kibana, כי קריאה להפעלת פונקציות מדומה שמבוססת על הנחיות פחות אמינה לקריאות לכלים בתצוגת עץ.
    • מומלץ מאוד להשתמש בחלון הקשר של 128,000 טוקנים לפחות, כי חקירות מרובות שלבים שמשלבות הגדרות של כלים, סכימות של אינדקסים, תיעוד של ES|QL ותוצאות חיפוש יכולות לחרוג מ-70,000 טוקנים.
    • מומלץ להגדיר מגבלת טוקנים של לפחות 8,192 טוקנים בפלט וקנס קל על חזרה, כי Kibana מתייחס לסיבת סיום length כשגיאה חמורה ומשתמש בפיענוח חמדני.
    • כדי לסנתז באופן מהימן פלטים מובְנים של כמה התראות, Attack Discovery דורש מודל מסוג 30B או גדול יותר (כמו gemma4:31b).
  • אבטחה ותאימות:
    • כל ההנחיות, הנתונים שאוחזרו והתשובות של המודל נשארים ברשת הפנימית של GDC.
    • כדאי להחמיר את מדיניות הרשת ב-Kubernetes מהגדרות הערכה מתירניות, כדי להגביל את הגישה הנכנסת ל-Elasticsearch ול-Kibana ללקוחות מורשים, ולהגביל את היציאה לנקודת הקצה של שירות ה-LLM.
    • הגישה ל-Kibana ול-Elasticsearch צריכה להיות מנוהלת באמצעות אמצעי בקרת גישה מבוססי-תפקידים של Elastic, ולא באמצעות משתמש-העל elastic.
  • ניהול משאבים ורישוי:
    • כדי להשתמש בתכונות מבוססות-AI גנרטיבי של Elastic ובמחברים החיצוניים של LLM, צריך רישיון Enterprise (או תקופת ניסיון פעילה של 30 יום ב-Enterprise). צריך להקצות את הרישיון באמצעות סוד של רישיון ECK כדי שהוא יישמר במחזורי ההתאמה של המפעיל.
  • זמינות ואמינות:
    • בפריסות בסביבת ייצור, כדאי להשתמש בכמה צומתי Elasticsearch עם פיצולי רפליקה ובכמה מכונות Kibana כדי להימנע מנקודות כשל בודדות.
    • הזמינות של תכונות ה-AI תלויה בזמינות ובזמן האחזור של שירות ה-LLM.
  • ניהול תפעולי:
    • הלקוח אחראי לשדרוג של חבילת Elastic Marketplace ושל גרסאות Elastic Stack, לניהול הרישיונות ולגיבוי של נתוני Elasticsearch.
    • כשמשתמשים בשירות LLM בניהול עצמי, הלקוח אחראי לפריסה, לתכנון הקיבולת של ה-GPU, לעדכוני המודל ולכוונון שלו.

החלטה לגבי העיצוב

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

מפעיל ECK מ-GDC Marketplace

האופרטור של ECK מותקן מ-Marketplace של GDC עם air gap, ולא נפרס באופן ידני. החבילה של Marketplace מוגדרת מראש כדי למשוך קובצי אימג' של קונטיינרים מהמרשם המקומי של Harbor, רושמת את ה-CustomResourceDefinitions הנדרשים ומשתלבת עם תפקידי IAM ברמת הפרויקט של GDC. כך אפשר להפחית את המאמץ שנדרש כדי לשכפל את קובצי האימג' ולשמור על התאמה בין הפריסה לבין מחזור החיים של התוכנה ב-GDC.

פריסת אשכול משותף

הפתרון פורס את Elastic Stack במרחב שמות של פרויקט באשכול משותף של GDC. כך הלקוחות יכולים להשתמש בתוכנה של Marketplace לצד עומסי עבודה אחרים בפרויקט, בלי להקצות ולהפעיל אשכול ייעודי, ומרחב השמות של הפרויקט מספק בידוד של משאבים, סודות ומדיניות רשת ב-Kubernetes.

אפשרויות שירות של LLM

אם יש לכם אפשרות להשתמש ב-Gemini מנוהל ב-GDC, כדאי לבחור בה, כי היא מסירה את הנטל התפעולי של אירוח תשתית ההסקה. אם הוא לא זמין, או אם הלקוחות צריכים מודל פתוח ספציפי, Kibana יכול להתחבר לכל שרת הסקה בניהול עצמי שחושף נקודת קצה (endpoint) של /v1/chat/completions שתואמת ל-OpenAI. התקנון של ה-API הזה שומר על ההגדרה של Elastic ללא תלות במנוע ההסקה (כמו Ollama או vLLM).

קריאה להפעלת פונקציות מובנות

הקריאה להפעלת פונקציות מובנות מופעלת במחבר של Kibana, כך שהעיצוב של קריאות הכלים מועבר לפרוטוקול OpenAI tools של שרת ההסקה. הקריאה המדומה לפונקציות שמבוססת על הנחיות כברירת מחדל ב-Kibana פחות אמינה במהלך קריאות לכלים בתצוגת עץ, ויכולה להיכשל עם שגיאות ניתוח.

התאמת רישיונות בניהול ECK

הרישיון ל-Enterprise (או לגרסת הניסיון) מוגדר כ-Secret של רישיון ECK, במקום להיות מופעל ישירות דרך ה-API של רישיון Elasticsearch. מכיוון ש-ECK מתאים באופן רציף את רישיון האשכול, רישיונות שהוחלו מחוץ ל-ECK חוזרים ל-basic במחזור ההתאמה הבא.

הנחות ומגבלות

הנחות

  • אשכול משותף של GDC ופרויקט מצורף זמינים, עם מספיק קיבולת מחשוב ואחסון מתמיד בשביל מפעיל ECK,‏ Elasticsearch ו-Kibana.
  • חבילת Elastic Marketplace וקובצי האימג' התואמים של קונטיינר Elasticsearch ו-Kibana זמינים ב-Marketplace של GDC עם air gap ובמרשם המקומי של Harbor.
  • למשתמשים יש את התפקידים הנדרשים בפרויקט (namespace-admin,‏ project-viewer,‏ marketplace-editor ו-project-networkpolicy-admin).
  • שירות LLM (שירות Gemini מנוהל ב-GDC או שרת הסקה בניהול עצמי שתואם ל-OpenAI) נפרס ונגיש מה-Pod של Kibana דרך הרשת הפנימית של GDC.
  • רישיון Elastic Enterprise זמין, או שמשתמשים בתקופת הניסיון של Enterprise למשך 30 יום לצורך הערכה.

מגבלות

  • שירות LLM מחוץ להיקף: פריסה והפעלה של שירות LLM בניהול עצמי, כולל תשתית GPU, לא נכללות בארכיטקטורה הזו.
  • אין שירותי AI שמתארחים ב-Elastic: מודלי LLM מנוהלים של Elastic ושירותי AI אחרים של Elastic שמתארחים בענן לא זמינים בסביבה עם air gap.
  • איכות שתלויה במודל: הדיוק והאמינות של התוצאות של סוכן ה-AI, של Agent Builder ושל Attack Discovery תלויים ביכולות של המודל שנבחר ובהגדרות שלו בזמן הריצה.
  • הגדרות ברירת מחדל ברמת הערכה: הטמעת העזר משתמשת באשכול Elasticsearch עם צומת יחיד, אישורים בחתימה עצמית ומדיניות רשת ב-Kubernetes מתירנית, שצריך להקשיח לשימוש בסביבת ייצור.
  • גרסאות ספציפיות: הפתרון אומת עם Elastic בגרסה 9.4.0, עם Elastic Kubernetes Operator בגרסה 3.4.0 ועם GDC בגרסה 1.16.2. יכול להיות שבגרסאות אחרות תצטרכו לבצע התאמות.

חומרים נוספים

הטמעת פתרון לדוגמה (SRI): פריסת תכונות מבוססות-AI גנרטיבי של Elastic Stack ב-GDC עם air gap