ארכיטקטורה לדוגמה של פתרון: פריסת תכונות מבוססות-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, לתזמר קריאות API לכלי בכמה שלבים ולקשר בין התראות אבטחה.

בארכיטקטורה הזו, 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 עם נקודת קצה (endpoint) להסקת מסקנות של LLM.

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

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

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

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

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

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

  • אשכול משותף של GDC: סביבת המחשוב הראשית שבה נמצאים ה-pods של מפעיל ה-ECK, של Elasticsearch ושל Kibana במרחב השמות של הפרויקט.
  • ‫GDC Marketplace: הקטלוג שמשמש להתקנה ולשדרוג של חבילת שטחי פרסום ייעודית לזירות מסחר של Elastic, שרושמת את ה-CustomResourceDefinitions של Elastic ופורסת את ה-StatefulSet של elastic-operator.
  • ‫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: תהליכי אוטומציה דקלרטיביים שמוגדרים ב-YAML (לדוגמה, cases.createCase) שאפשר לרשום ככלים של Agent Builder כדי לאפשר לסוכנים לבצע פעולות כמו פתיחת מקרים של Kibana Security.
  • ‫Attack Discovery: אמצעי אבטחה של Elastic Security ששולח הקשר אנונימי של התראות ל-LLM כדי לקשר בין התראות מהאינדקס של .alerts-security.alerts-default לשרשראות של מתקפות שממופות לטקטיקות של MITRE ATT&CK.
  • שירות LLM: מספק השלמות צ'אט מותאמות להוראות עם תמיכה מובנית בקריאות API לכלי. המודל צריך ליצור באופן מהימן קריאות תקינות לכלים, שאילתות ES|QL ו-JSON מובנה.

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

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

לתשומת ליבכם

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

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

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

מפעיל ECK מ-GDC Marketplace

האופרטור של ECK מותקן מ-GDC עם air gap Marketplace ולא נפרס באופן ידני. החבילה של 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, כך שהעיצוב של קריאת API לכלי מועבר לפרוטוקול OpenAI tools של שרת ההסקה. ההדמיה של קריאה להפעלת פונקציות שמבוססת על פרומפטים כברירת מחדל ב-Kibana פחות אמינה במהלך קריאות API לכלי בתצוגת עץ, ויכולה להיכשל עם שגיאות ניתוח.

התאמת רישיונות שמנוהלים על ידי ECK

הרישיון ל-Enterprise (או לגרסת הניסיון) מוגדר כסוד של רישיון 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