שילוב של Apigee עם Google SecOps

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

במאמר הזה מוסבר איך לשלב את Apigee עם Google Security Operations (Google SecOps). אם אתם משתמשים ב-Google SecOps כפתרון SIEM, אתם יכולים לפעול לפי השלבים במאמר הזה כדי להגדיר את Apigee לשליחת נתוני יומן ל-SecOps.

כדי להקל על השילוב הזה, Google SecOps תומך במנתח Apigee לצריכת נתוני יומן של Apigee. אפשר גם לעיין במאמר העברת נתונים מ-Google Cloud אל Google Security Operations. אחרי שתשלימו את שלבי ההגדרה שמתוארים במסמך הזה, נתוני היומן של Apigee יועברו אל Google SecOps.

במאמר שילוב של Apigee עם פתרון SIEM מוסבר איך לשלב את SecOps עם פתרונות SIEM אחרים.

קהל

הקהל שאליו מיועד המסמך הזה כולל:

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

סקירה כללית של ההגדרה

ההגדרה שמתוארת במסמך הזה משתמשת במדיניות MessageLogging של Apigee כדי לשלוח ל-SecOps מגוון רחב של נתוני יומן של Apigee, כולל משתני זרימה ספציפיים.

‫Google SecOps מספק מסנן מיוחד של Cloud Logging שיכול לשלוח סוגים ספציפיים של יומנים, כולל יומני Apigee, אל Google SecOps בזמן אמת. ‫Google SecOps תומך בניתוח Apigee לצורך הטמעה של נתוני יומן Apigee ב-Google SecOps. אפשר גם לעיין במאמר העברת נתונים מ-Google Cloud אל Google Security Operations.

דרישות מוקדמות

אחרי שמוודאים שכל התנאים המוקדמים האלה מתקיימים, פועלים לפי ההוראות במסמך הזה כדי לשלב את Apigee עם מופע SecOps. לפני שמתחילים בשילוב, חשוב לוודא שיש לכם:

  • חשבון Apigee או Apigee Hybrid עם הרשאות אדמין לפיתוח ולפריסה של שרתי proxy של API
  • חשבון Google SecOps
  • ‫Cloud Logging מופעל, והתנסות בהגדרה ובשימוש ב-Cloud Logging
  • הבנה של משתני זרימה ב-Apigee
  • הבנה של המדיניות MessageLogging של Apigee ושל השימוש במדיניות וההגדרה שלה באופן כללי
  • (אופציונלי) הבנה של אופן השימוש בכלי הניתוח של Google SecOps כדי לפרש יומנים שהועברו. מנתחי SecOps מובנים כברירת מחדל כדי לנתח ולהבין יומנים של Apigee שמוזנים על ידי המדיניות MessageLogging.
  • הרשאות Cloud IAM ב-Google Cloud לשימוש ב-Cloud Logging API ולהקצאת תפקידי IAM לחשבון השירות של SecOps

שילוב של Apigee עם SecOps

אם אתם משתמשים ב-Google SecOps כפתרון SIEM, אתם יכולים לפעול לפי השלבים הבאים כדי לשלוח נתוני יומן של Apigee אל SecOps. יש שני שלבים בסיסיים:

  • הגדרת מדיניות MessageLogging לשליחת נתוני יומן של Apigee אל Cloud Logging
  • צירוף המדיניות MessageLogging לשרת proxy של Apigee

אחרי שמסיימים את ההגדרה של מדיניות MessageLogging שמתוארת בקטע הזה, נתוני היומן של Apigee שנשלחים אל Cloud Logging מנותחים על ידי SecOps. למידע מפורט על מנתח הנתונים ועל אופן המיפוי של נתוני משתני זרימה של Apigee לשדות נתונים של SecOps, אפשר לעיין במאמר שילוב של Apigee עם Google SecOps SIEM. אפשר לעיין גם במאמר איסוף יומנים של Apigee.

כדי לשלב בין Apigee לבין SecOps באמצעות מדיניות MessageLogging, פועלים לפי השלבים הבאים:

  1. מגדירים מדיניות חדשה של MessageLogging. הוספה והגדרה של כללי מדיניות בממשק המשתמש

    הדוגמה הבאה היא מדיניות MessageLogging ששולחת נתונים אל Cloud Logging. המדיניות מציינת מספר גדול של משתני זרימה שיישלחו אל Cloud Logging. אתם יכולים להוסיף או להסיר משתני זרימה לפי הצורך, בהתאם לשדות שקבעתם כחשובים לניתוח SecOps. במאמר שילוב של Apigee עם Google SecOps SIEM מוסבר איך נתוני משתני זרימה של Apigee ממופים לשדות נתונים של SecOps.

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <MessageLogging continueOnError="false" enabled="true" name="ML-CloudLoggingSecOps">
   <DisplayName>ML-CloudLoggingSecOps</DisplayName>
   <CloudLogging>
     <LogName>projects/{organization.name}/logs/apigee-secops-integration-{environment.name}</LogName>
     <Message contentType="application/json">{
   "apiproduct.name": "{apiproduct.name}",
   "app.name": "{developer.app.name}",
   "cachehit":"{cachehit}",
   "client.country": "{client.country}",
   "client.cn": "{client.cn}",
   "client.ip": "{proxy.client.ip}",
   "client.locality": "{client.locality}",
   "client.port": "{client.port}",
   "client.scheme": "{client.scheme}",
   "client.state": "{client.state}",
   "developer.email": "{developer.email}",
   "environment.name": "{environment.name}",
   "error":"{is.error}",
   "error.state":"{error.state}",
   "error.message":"{escapeJSON(error.message)}",
   "fault.name":"{fault.name}",
   "messageid":"{messageid}",
   "organization.name": "{organization.name}",
   "proxy.name": "{apiproxy.name}",
   "proxy.basepath": "{proxy.basepath}",
   "proxy.pathsuffix": "{proxy.pathsuffix}",
   "proxy.proxyendpoint.name": "{proxy.name}",
   "proxy.revision":"{apiproxy.revision}",
   "request.content-length":"{request_msg.header.content-length}",
   "request.content-type":"{request_msg.header.content-type}",
   "request.host":"{request_msg.header.host}",
   "request.httpversion": "{request.version}",
   "request.url": "{client.scheme}://{request_msg.header.host}{request_msg.uri}",
   "request.user-agent":"{request.header.user-agent}",
   "request.verb": "{request.verb}",
   "request.x-b3-traceid": "{request.header.x-b3-traceid}",
   "request.x-cloud-trace-context": "{request.header.x-cloud-trace-context}",
   "response.content-length":"{response.header.content-length}",
   "response.content-type":"{response.header.content-type}",
   "response.status.code": "{message.status.code}",
   "system.region.name": "{system.region.name}",
   "system.timestamp": "{system.timestamp}",
   "system.uuid": "{system.uuid}",
   "target.cn": "{target.cn}",
   "target.country": "{target.country}",
   "target.host": "{target.host}",
   "target.ip": "{target.ip}",
   "target.locality": "{target.locality}",
   "target.organization": "{target.organization}",
   "target.port": "{target.port}",
   "target.scheme": "{target.scheme}",
   "target.state": "{target.state}",
   "target.url": "{request.url}"
  }
     </Message>
     <ResourceType>api</ResourceType>
   </CloudLogging>
  </MessageLogging>

  2. מצרפים את המדיניות כשלב מותנה בשרת proxy ל-API. אפשרות אחת היא לצרף את המדיניות ל-FaultRule ב-PostFlow, שבו בדרך כלל מועלות תקלות שקשורות לאבטחה. לדוגמה:

    <PostFlow name="PostFlow">
  <Request>
    <Step>
      <Condition>flow.isError == true)</Condition>
      <Name>ML-CloudLoggingSecOps</Name>
    </Step>
  </Request>
</PostFlow>

    מעכשיו, כש-proxy ל-API שמשתמש במדיניות הזו יופעל, נתוני היומן של Apigee יועברו אל Google SecOps.

    שיטה נפוצה נוספת היא להציב את מדיניות MessageLogging ב-PostClientFlow של תגובת ProxyEndpoint.

    כדאי לפעול לפי העצות הבאות כשמצרפים את מדיניות MessageLogging ל-proxy ל-API:

    • מציבים את המדיניות ב-FaultRule. מומלץ להשתמש ב-FaultRule כדי לתעד חריגים באבטחה והפרות מדיניות.
    • ממקמים את המדיניות ב-PostFlow. PostFlow הוא מיקום מתאים נוסף לרישום בעיות אבטחה.
    • לא כדאי לרשום ביומן בקשות שמושלמות בהצלחה. לניטור לצורכי אבטחה שמתמקד באיומים, בדרך כלל מתעדים פרטים כשמשהו משתבש (מוצגת תקלה). רישום ביומן של כל בקשה מוצלחת עם תוכן ההודעה המלא עלול ליצור יומנים גדולים מדי ולהגדיל את העלויות.
    • כדאי להשתמש במשתנים מותאמים אישית בתרחישים מסוימים. לדוגמה, אם אתם צריכים לתעד את ה-URI של הבקשה המקורית בתהליך של תקלה, אתם יכולים להשתמש במדיניות AssignMessage ב-PreFlow של הבקשה כדי להעתיק אותו למשתנה מותאם אישית (כמו original.request.uri), ואז לרשום את המשתנה הזה ביומן במדיניות MessageLogging.

שיטות מומלצות

כדאי לפעול לפי השיטות המומלצות הבאות כשמגדירים את Apigee עם Google SecOps:

  • התמקדות בהקשר האבטחה: רישום ביומן רק של משתני הזרימה שמספקים הקשר חשוב לניטור לצורכי אבטחה ולזיהוי איומים. מומלץ להימנע מרישום יתר ביומן של נתונים שלא קשורים לאבטחה.
  • שימוש בפורמט עקבי של רישום ביומן: חשוב לשמור על פורמט עקבי של רישום ביומן בכל שרתי ה-proxy של ה-API שמשתמשים ב-SecOps.
  • שימוש בחשבונות שירות מאובטחים: חשוב לפעול לפי השיטות המומלצות לאבטחה ולניהול של חשבון השירות ב-Google Cloud שמשמש להעברת נתונים ל-SecOps. אם אפשר, כדאי להגביל את ההרשאה ל'מציג היומנים'.
  • מעקב אחרי פיד SecOps: חשוב לעקוב באופן קבוע אחרי התקינות והסטטוס של פיד SecOps כדי לוודא שהיומנים מוזנים בהצלחה וללא שגיאות.
  • שימוש בכללים ובלוחות בקרה של SecOps: אחרי שהיומנים שרלוונטיים לאבטחה נמצאים ב-SecOps, אפשר לפתח כללים ולוחות בקרה ספציפיים כדי לזהות איומי אבטחה ולהציג אותם באופן חזותי על סמך המידע המפורט שאתם מתעדים ביומן.

פתרון בעיות

בקטע הזה מתוארות כמה בעיות אפשריות שאתם עשויים להיתקל בהן כשמגדירים את Apigee עם SecOps, וגם דברים שכדאי לבדוק.

בעיה: יומני אירועי אבטחה לא מופיעים ב-Cloud Logging

מה צריך לבדוק:

  • חשוב לבדוק שהמדיניות MessageLogging מוגדרת בצורה נכונה עם התג Condition כדי להפעיל אותה כשמתרחש אירוע אבטחה.
  • מוודאים שמדיניות MessageLogging מצורפת להקשר המתאים של זרימת הנתונים, כמו FaultRule או PostFlow.
  • מוודאים ש-Cloud Logging מופעל בפרויקט שלכם ב-Google Cloud.
  • בודקים את הודעות השגיאה ביומני ה-proxy של Apigee שקשורות למדיניות MessageLogging.

בעיה: יומני אירועי אבטחה לא מופיעים ב-SecOps

  • מוודאים שפיד SecOps מוגדר בצורה נכונה עם מזהה הפרויקט הנכון, מסנן היומנים (כדי לוודא שהוא מתעד את היומנים ממדיניות רישום הפעולות לאבטחה) ופרטי הכניסה של חשבון השירות.
  • בודקים את הסטטוס של פיד SecOps בממשק המשתמש של SecOps כדי לראות אם יש הודעות שגיאה או בעיות בהעברה.
  • מוודאים שלחשבון השירות שבו משתמשים ב-SecOps יש את התפקיד 'מציג היומנים' בפרויקט בענן של Google.
  • בודקים את מבנה ה-JSON של היומנים ב-Cloud Logging כדי לוודא שהם בפורמט תקין ומכילים את שמות השדות הצפויים.
  • מוודאים שהכלי המתאים לניתוח נתונים ב-Google Cloud מופעל.
  • אם אתם חושדים בבעיה בניתוח, כדאי לבדוק רשומה לדוגמה ביומן בנתונים הגולמיים של SecOps כדי לראות איך היא נקלטה לפני הניתוח. אם שדות ספציפיים לא מחולצים כמצופה, יכול להיות שתצטרכו לעיין במסמכי התיעוד של כלי הניתוח של SecOps או לשקול אם נדרש כלי ניתוח מותאם אישית.

שילוב Apigee עם Google SecOps SIEM

בטבלה הבאה מפורטים שמות של משתני Apigee flow ושמות השדות המקבילים ב-Google SecOps SIEM. לדוגמה, כשמציגים נתוני יומן של Apigee ב-Cloud Logging, המשתנה client.id flow ממופה לשדה SecOps SIEM שנקרא principle_ip. אפשר לעיין גם במאמר איסוף יומנים של Apigee.

משתנה של זרימת נתונים ב-Apigee שם השדה ב-SIEM ב-SecOps תיאור
client.country principal.hostname כתובת ה-IP של מארח ה-HTTP שמשויכת לבקשה שהתקבלה ב-ProxyEndpoint.
client.host principal.location.country_or_region המדינה באישור TLS/SSL שמוצג על ידי אפליקציית הלקוח. בקשת פרוקסי principal.location.country_or_region.
client.ip principle.ip כתובת ה-IP של הלקוח או המערכת ששולחים את ההודעה למאזן העומסים. לדוגמה, יכולה להיות כתובת ה-IP של הלקוח המקורי או כתובת ה-IP של מאזן העומסים.
client.locality principal.location.city הרשות המוניציפאלית (העיר) באישור TLS/SSL שהלקוח מציג.
client.port principal.port יציאת ה-HTTP שמשויכת לבקשת הלקוח המקורית אל ProxyEndpoint.
client.state principal.location.state המצב באישור TLS/SSL שמוצג על ידי הלקוח.
organization.name intermediary.cloud.project.name שם הארגון ב-Apigee.
proxy.client.ip src.ip כתובת X-Forwarded-For של השיחה הנכנסת, שהיא כתובת ה-IP ש-Apigee קיבלה מתוך לחיצת היד האחרונה של TCP חיצוני. יכול להיות שמדובר בלקוח שמתקשר או במאזן עומסים.
proxy.name intermediary.resource.name מאפיין השם שהוגדר עבור ProxyEndpoint.
proxy.pathsuffix intermediary.resource.attribute.labels[pathsuffix] ‫"The value of the path suffix in the URL that is sent from the client and received at the ProxyEndpoint. ‫basepath הוא רכיב הנתיב הכי שמאלי שמזהה באופן ייחודי proxy ל-API בתוך קבוצת סביבות. נניח שיש לכם נקודת קצה של proxy ל-API שהוגדרה עם נתיב בסיס של ‎/v2/weatherapi. במקרה כזה, אם תישלח בקשה אל https://myhost.example.net/v2/weatherapi/forecastrss?w=12797282, המשתנה proxy.pathsuffix יכיל את המחרוזת /forecastrss.
proxy.url intermediary.url ‫"Gets the complete URL associated with the proxy request received by the ProxyEndpoint, including any query parameters present. לדוגמה, כדי ליצור כתובת URL של בקשה באמצעות המארח של הבקשה המקורית (ולא המארח של הנתב שמשמש ב-proxy.url), אפשר לעיין במאמר בנושא גישה להודעות של בקשות.
request.uri target.resource.name שם הדומיין של שירות היעד שמחזיר את התגובה ל-proxy ל-API.
request.verb network.http.method פועל ה-HTTP שמשמש לבקשה. לדוגמה, GET,‏ PUT ו-DELETE.
response.content security_result.description תוכן המטען הייעודי (payload) של הודעת התגובה שהוחזרה על ידי היעד.
response.status.code network.http.response_code קוד התגובה שמוחזר לבקשה. אפשר להשתמש במשתנה הזה כדי לבטל את קוד הסטטוס של התגובה, שמאוחסן ב-message.status.code. מידע נוסף זמין בהודעה.
system.region.name intermediary.location.name שם האזור של מרכז הנתונים שבו ה-proxy פועל.
system.timestamp additional.fields[jsonPayload_system_timestamp] מספר שלם (long) של 64 ביט שמייצג את הזמן שבו המשתנה הזה נקרא. הערך הוא מספר אלפיות השנייה שחלפו מאז חצות, ב-1 בינואר 1970 UTC. לדוגמה, 1534783015000.
system.uuid intermediary.process.pid או intermediary.process.product_specific_process_id ה-UUID של מעבד ההודעות שמטפל ב-Proxy.
target.country target.location.country_or_region המדינה שבה הונפק אישור ה-TLS/SSL שמוצג על ידי שרת היעד
target.host target.hostname שם הדומיין של שירות היעד שמחזיר את התגובה ל-proxy ל-API.
target.ip target.ip כתובת ה-IP של שירות היעד שמחזיר את התגובה ל-proxy ל-API.
target.locality target.location.city המיקום (העיר) של אישור ה-TLS/SSL שמוצג על ידי שרת היעד
target.organization target.resource_ancestors.name הארגון של אישור ה-TLS/SSL שמוצג על ידי שרת היעד.
target.port target.port מספר היציאה של שירות היעד שמחזיר את התגובה ל-proxy ל-API.
target.scheme target.network.application_protocol מחזירה HTTP או HTTPS בהתאם להודעת הבקשה.
target.state target.location.state המצב של אישור ה-TLS/SSL שמוצג על ידי שרת היעד.
target.url target.url כתובת ה-URL שמוגדרת בקובץ ה-XML של TargetEndpoint או כתובת היעד הדינמית (אם target.url מוגדר במהלך זרימת ההודעה). המשתנה לא כולל רכיבי נתיב נוספים או פרמטרים של שאילתה. הפונקציה מחזירה ערך null אם היא מופעלת מחוץ לתחום או אם היא לא מוגדרת.

הערה: כדי להגדיר את המשתנה הזה, צריך להשתמש במדיניות JavaScript שמצורפת ל-TargetEndpoint.