מדיניות AccessControl

מדיניות רגילה

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

לעיון במסמכי התיעוד של Apigee Edge

המדיניות AccessControl מאפשרת לתת או לשלול גישה לממשקי ה-API שלכם לפי כתובות IP ספציפיות.

אפשר לצרף את המדיניות הזו לכל מקום בתהליך של proxy ל-API, אבל כדאי לבדוק את כתובות ה-IP בתחילת התהליך ( Request / ProxyEndpoint / PreFlow), עוד לפני האימות או בדיקת המכסה.

אפשר גם להשתמש ב-Google Cloud Armor עם Apigee כדרך חלופית לאבטח את ממשקי ה-API.

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

דוגמאות

ערכי המסכה בדוגמאות הבאות של IPv4 מזהים את האוקטט (8, ‏ 16, ‏ 24, ‏ 32 ביטים) שהכלל להתאמה מתייחס אליו כשמאשרים או דוחים גישה. ערך ברירת המחדל הוא 32. מידע נוסף מופיע במאמר בנושא המאפיין mask בהפניה לרכיב.

דחייה של 198.51.100.1

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "DENY">
      <SourceAddress mask="32">198.51.100.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

דחיית כל הבקשות מכתובת הלקוח: 198.51.100.1

אפשר לאשר בקשות מכל כתובת של לקוח אחר.

דחיית השימוש במשתנים

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "DENY">
      <SourceAddress mask="{kvm.mask.value}">{kvm.ip.value}</SourceAddress>
    </MatchRule>
    </IPRules>
</AccessControl>

נניח שאתם משתמשים במיפוי של זוגות מפתח/ערך (KVM) כדי לאחסן ערכים להסתרת כתובות IP. זו גישה נוחה לשינוי כתובות IP ולהסתרתן במהלך זמן הריצה, בלי שתצטרכו לעדכן ולפרוס מחדש את proxy ל-API. אפשר להשתמש במדיניות KeyValueMapOperations כדי לאחזר את המשתנים שמכילים את הערכים של kvm.mask.value ושל kvm.ip.value (בהנחה שזה השם שנתתם למשתנים במדיניות KVM שמכילים את הערכים של המסכה ושל כתובות ה-IP מ-KVM). אם הערכים שאחזרתם היו 24 למסכה ו-198.51.100.1 לכתובת ה-IP, מדיניות AccessControl תדחה את כל הבקשות מ: 198.51.100.*

כל שאר כתובות הלקוחות יורשו.

דחייה של 198.51.100.*

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "DENY">
      <SourceAddress mask="24">198.51.100.1</SourceAddress>
    </MatchRule>
    </IPRules>
</AccessControl>

דחיית כל הבקשות מכתובת הלקוח: ‎198.51.100.*‎

אפשר לאשר בקשות מכל כתובת של לקוח אחר.

‫198.51.*.*

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "DENY">
       <SourceAddress mask="16">198.51.100.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

דחיית כל הבקשות מכתובת הלקוח: ‎198.51.*.*

אפשר לאשר בקשות מכל כתובת של לקוח אחר.

דחייה של 198.51.100.*, הרשאה של 192.0.2.1

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "ALLOW">
      <SourceAddress mask="32">192.0.2.1</SourceAddress>
    </MatchRule>
    <MatchRule action = "DENY">
      <SourceAddress mask="24">198.51.100.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

דחיית כל הבקשות מכתובת הלקוח: 198.51.100.*, אבל התרת הבקשה 192.0.2.1.

אפשר לאשר בקשות מכל כתובת של לקוח אחר.

Allow 198.51.*.*

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "DENY">
    <MatchRule action = "ALLOW">
      <SourceAddress mask="16">198.51.100.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

התרת כל הבקשות מהכתובת: 198.51.*.*

לדחות בקשות מכל כתובת לקוח אחרת.

הרשאת שימוש בכמה כתובות IP

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "DENY">
    <MatchRule action = "ALLOW">
      <SourceAddress mask="24">198.51.100.1</SourceAddress>
      <SourceAddress mask="24">192.0.2.1</SourceAddress>
      <SourceAddress mask="24">203.0.113.1</SourceAddress>
     </MatchRule>
  </IPRules>
</AccessControl>

התרת בקשות מכתובות לקוח: 198.51.100.* ‪192.0.2.* 203.0.113.*

דחיית כל הכתובות האחרות.

דחיית כמה כתובות IP

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "DENY">
      <SourceAddress mask="24">198.51.100.1</SourceAddress>
      <SourceAddress mask="24">192.0.2.1</SourceAddress>
      <SourceAddress mask="24">203.0.113.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

דחיית בקשות מכתובות לקוח: 198.51.100.* ‪192.0.2.* 203.0.113.*

לאפשר גישה לכל הכתובות האחרות.

אפשר להשתמש בכמה כתובות IP, אי אפשר להשתמש בכמה כתובות IP

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "DENY">
    <MatchRule action = "DENY">
      <SourceAddress mask="24">198.51.100.1</SourceAddress>
      <SourceAddress mask="24">192.0.2.1</SourceAddress>
      <SourceAddress mask="24">203.0.113.1</SourceAddress>
    </MatchRule>
    <MatchRule action = "ALLOW">
      <SourceAddress mask="16">198.51.100.1</SourceAddress>
      <SourceAddress mask="16">192.0.2.1</SourceAddress>
      <SourceAddress mask="16">203.0.113.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

Allow: 198.51.*.* ‪192.0.*.* 203.0.*.*

דחיית קבוצת משנה של הרשימה: 198.51.100.* ‪192.0.2.* 203.0.113.*

הערות שימוש

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

ההגדרה והביצוע של מדיניות AccessControl כוללים את הפעולות הבאות:

  • מגדירים קבוצה של כללי התאמה עם אחת משתי פעולות (ALLOW או DENY) שמשויכות לכל כלל.
  • לכל כלל התאמה, מציינים את כתובת ה-IP (רכיב SourceAddress).
  • מציינים את הסדר שבו הכללים נבדקים.
  • כל כללי ההתאמה מופעלים לפי הסדר שמוגדר. כשכלל מתאים, הפעולה המתאימה מבוצעת וכללים נוספים שמתאימים להודעה נדלגים.
    • אם אותו כלל מוגדר עם הפעולות ALLOW ו-DENY, הכלל שמוגדר ראשון בסדר מופעל והכלל הבא (עם הפעולה האחרת) מדלג.

טיפול בכתובות IP לא תקינות

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

  • מבוסס-כותרת (ללא <ClientIPVariable>): כשכללי המדיניות מנתחים ישירות את הכותרת X-Forwarded-For (XFF), המערכת מתעלמת בשקט מכל מחרוזת שאינה כתובת IP (לדוגמה, pwned) בכותרת שנבדקת. המדיניות ממשיכה כאילו מחרוזת כתובת ה-IP לא תאמה לאף כלל, והפעולה שצוינה על ידי <noRuleMatchAction> מתבצעת. הגדרה כזו עלולה להוות בעיה אבטחתית אם <noRuleMatchAction> מוגדר ל-ALLOW, כי אפשר להשתמש בה כדי לעקוף את הכללים של blocklist.
  • מבוסס-משתנים (נעשה שימוש ב-<ClientIPVariable>): אם משתנה שצוין ב-<ClientIPVariable> מכיל פורמט לא תקין של כתובת IP, המדיניות תחזיר שגיאה (לדוגמה, accesscontrol.InvalidIPAddressInVariable). כך מתקבלת שגיאה מפורשת יותר, וזו הגישה המומלצת לאימות מחמיר יותר של כתובות IP.

איך המדיניות בוחרת איזו כתובת IP להעריך

כתובות IP יכולות להגיע ממקורות שונים בבקשה. לדוגמה, הכותרת X-Forwarded-For עשויה להכיל כתובת IP אחת או יותר. בקטע הזה מוסבר איך להגדיר את מדיניות AccessControl כדי להעריך את כתובות ה-IP המדויקות שרוצים להעריך.

הלוגיקה שבה מדיניות AccessControl משתמשת כדי להחליט איזו כתובת IP להעריך:

כותרת X-Forwarded-For

‫Apigee מאכלס באופן אוטומטי את הכותרת X-Forwarded-For עם כתובת ה-IP שהתקבלה מהלחיצת יד האחרונה של TCP חיצוני (כמו כתובת ה-IP של הלקוח או הנתב). אם יש כמה כתובות IP בכותרת, סביר להניח שהכתובות האלה הן שרשרת השרתים שעיבדו את הבקשה. עם זאת, רשימת הכתובות יכולה להכיל גם כתובת IP מזויפת. אז איך המדיניות יודעת אילו כתובות להעריך?

מפרט Apigee להתנהגות של כותרת XFF

ב-Apigee, הנוכחות של מאזני עומסים (GCLB) של Google Cloud משפיעה על המבנה של כותרת X-Forwarded-For (XFF). הפורמט הטיפוסי של הכותרת הוא כדלקמן:

X-Forwarded-For: <client_ip>, <GCLB1_ip>, <internal_ingress_ip>

חשוב להבין את ההשלכות של המבנה הזה כשמשתמשים ברכיב ValidateBasedOn:

  • X_FORWARDED_FOR_LAST_IP: ב-Apigee, אם משתמשים בהגדרה הזו, כתובת ה-IP הפנימית של ה-GCLB השני תיבדק, ולא כתובת ה-IP המקורית של הלקוח. זה עלול להוביל להתנהגות לא צפויה של המדיניות.
  • X_FORWARDED_FOR_FIRST_IP: ההגדרה הזו מעריכה נכון את <client_ip> המקורי, אבל חשוב לדעת שקל לזייף את <client_ip> על ידי הלקוח, ולכן היא פחות אמינה לתרחישי שימוש שבהם האבטחה חשובה.

מאפייני X-Forwarded-For בניתוח הנתונים של Apigee

מערכת Apigee Analytics כותבת את הערך של הכותרת X-Forwarded-For למאפיין x_forwarded_for_ip. כדי לקבוע את כתובת ה-IP של הלקוח ששלח את הבקשה אל Apigee, צריך להשתמש בערכים של מאפיין ax_resolved_client_ip, אבל להחריג את ax_true_client_ip, שלא נתמך במדיניות AccessControl. אפשר לעיין במאמר בנושא מדדים, מאפיינים ומסננים ב-Analytics.

מידע על אנונימיזציה של כתובות IP באמצעות סימון CIDR

סימון CIDR‏ (Classless Inter-Domain Routing) הוא דרך לציין טווח של כתובות IP באמצעות מיסוך. ההגדרה רלוונטית גם ל-IPv4 וגם ל-IPv6. כך זה עובד: בדוגמאות שלנו נשתמש ב-IPv4 כדי לפשט את הדברים.

כתובות IP הן קבוצות של מספרים שמופרדים בנקודות. במונחים בינאריים, כל קבוצה היא מספר ספציפי של ביטים (8 ל-IPv4 ו-16 ל-IPv6). כתובת ה-IPv4‏ 198.51.100.1 נראית כך בפורמט בינארי:

11000110.00110011.01100100.00000001

כלומר 4 קבוצות של 8 ביט, או 32 ביט בסך הכול. ב-CIDR, אפשר לציין טווח על ידי הוספה של ‎/number (1-32) לכתובת ה-IP, כך:

198.51.100.1/24

במקרה הזה, המספר 24 הוא הערך שבו צריך להשתמש במדיניות הזו עבור המאפיין mask.

הסימון הזה אומר: 'שומרים את 24 הביטים הראשונים בדיוק כמו שהם, והביטים הנותרים יכולים להיות כל ערך מ-0 עד 255'. לדוגמה:

לא לשנות את ההגדרות האלה ערכים אפשריים לקבוצה האחרונה
‫198.51.100. 0 - 255

שימו לב שהמסכה מופיעה בסוף קבוצה שלוש. כך הכל מסודר וברור, ובעצם נוצרת מסכה כזו: 198.51.100.*. ברוב המקרים, שימוש בכפולות של 8 (IPv4) ו-16 (IPv6) ייתן לכם את רמת המיסוך הרצויה:

IPv4: ‏ 8, ‏ 16, ‏ 24, ‏ 32

IPv6: ‏ ‎16, 32, 48, 64, 80, 96, 112, 128

אבל אפשר להשתמש במספרים אחרים כדי לקבל שליטה מדויקת יותר, שכוללת חישוב בינארי. דוגמה לשימוש במסכה של 30, כמו ב-198.51.100.1/30, שבה הספרה האחרונה 1 היא 00000001 בפורמט בינארי:

לא לשנות את ההגדרות האלה ערכים אפשריים
11000110.00110011.01100100.000000 (ה-30 ביטים הראשונים) ‫00000000,‏ 00000001,‏ 00000010 או 00000011
198.51.100. ‫0, 1, 2 או 3

בדוגמה הזו, כשההגדרה היא <SourceAddress mask="30">198.51.100.1</SourceAddress>, כתובות ה-IP הבאות יקבלו אישור (או יידחו, בהתאם לכללים):

  • 198.51.100.0
  • 198.51.100.1
  • 198.51.100.2
  • 198.51.100.3

הפניה לרכיב

הפניה לרכיב מתארת את הרכיבים והמאפיינים של מדיניות AccessControl.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1">
    <DisplayName>Access Control 1</DisplayName>
    <IPRules noRuleMatchAction = "ALLOW">
        <MatchRule action = "ALLOW">
            <SourceAddress mask="32">198.51.100.1</SourceAddress>
        </MatchRule>
        <MatchRule action = "DENY">
            <SourceAddress mask="24">198.51.100.1</SourceAddress>
        </MatchRule>
    </IPRules>
    <ValidateBasedOn>X_FORWARDED_FOR_ALL_IP</ValidateBasedOn>
</AccessControl>

מאפיינים של <AccessControl>

<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1">

אלמנט <ClientIPVariable>

מציין משתנה של זרימה שמכיל כתובת IP שהמדיניות בודקת מול ה-IPRules. אם משתנה הזרימה לא מכיל כתובת IP תקינה (ipv4 או ipv6), הכלל יחזיר שגיאה.

נניח שמשתנה הזרימה מוגדר ל-12.31.34.52. בדוגמה הבאה, הגישה נדחית. אם המשתנה מוגדר לערך 10.11.12.13, תינתן גישה.

<AccessControl name='ACL'>
   <ClientIPVariable>FLOW_VARIABLE</ClientIPVariable>
   <IPRules noRuleMatchAction = 'DENY'>
     <MatchRule action = 'ALLOW'>
       <SourceAddress mask='32'>10.11.12.13</SourceAddress>
     </MatchRule>
   </IPRules>
</AccessControl>
ברירת מחדל לא רלוונטי
נוכחות אופציונלי
סוג משתנה Flow

אלמנט <IgnoreTrueClientIPHeader>

אלמנט <IPRules>

רכיב האב שמכיל את הכללים שמאפשרים או דוחים כתובות IP. המאפיין noRuleMatchAction מאפשר להגדיר איך לטפל בכתובות IP שלא נכללות בכללי ההתאמה.

<IPRules noRuleMatchAction = "ALLOW">
ברירת מחדל לא רלוונטי
נוכחות אופציונלי
סוג לא רלוונטי

מאפיינים

מאפיין תיאור סוג ברירת מחדל נוכחות
noRuleMatchAction
הפעולה שיש לבצע (לאשר או לדחות גישה) אם כלל ההתאמה שצוין לא נפתר (לא נמצאה התאמה).
ערך תקין: ALLOW או DENY
String אישור חובה

אלמנט <IPRules>/<MatchRule>

הפעולה שיש לבצע (לאפשר או לדחות גישה) אם כתובת ה-IP תואמת לכתובות המקור שהגדרתם.

<IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "ALLOW">
        <SourceAddress mask="32">198.51.100.1</SourceAddress>
    </MatchRule>
    <MatchRule action = "DENY">
        <SourceAddress mask="24">198.51.100.1</SourceAddress>
    </MatchRule>
</IPRules>
ברירת מחדל לא רלוונטי
נוכחות אופציונלי
סוג לא רלוונטי

מאפיינים

מאפיין תיאור סוג ברירת מחדל נוכחות
פעולה

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

ערך תקין: ALLOW או DENY

String אישור חובה

אלמנט <IPRules>/<MatchRule>/<SourceAddress>

טווח כתובות ה-IP של לקוח.

ערך תקין: כתובת IP תקינה (בפורמט עשרוני מופרד בנקודות). כדי להשתמש בתו כללי, צריך להשתמש במאפיין mask.

<IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "ALLOW">
        <SourceAddress mask="{variable}">198.51.100.1</SourceAddress>
    </MatchRule>
    <MatchRule action = "DENY">
        <SourceAddress mask="24">{variable}</SourceAddress>
    </MatchRule>
</IPRules>

כמו בדוגמה הקודמת, רכיב SourceAddress תומך גם בתבניות הודעות עבור המאפיין mask או כתובת ה-IP, מה שאומר שאפשר להגדיר את הערכים באמצעות משתנים שזמינים כרגע בתהליך של proxy ל-API.

לדוגמה, אפשר לאחסן כתובת IP במיפוי של זוגות מפתח/ערך (KVM) ולהשתמש במדיניות KeyValueMapOperations כדי לאחזר את כתובת ה-IP ולהקצות אותה למשתנה (למשל, kvm.ip.value). לאחר מכן אפשר להשתמש במשתנה הזה לכתובת ה-IP:

<SourceAddress mask="24">{kvm.ip.value}</SourceAddress>

הגדרת מסכה או כתובת IP באמצעות משתנה מאפשרת לכם לשנות ערכים בזמן הריצה בלי שתצטרכו לשנות ולפרוס מחדש את proxy ל-API שלכם.

ברירת מחדל לא רלוונטי
נוכחות אופציונלי
סוג מחרוזת (כתובת IP יחידה בלבד)

מאפיינים

מאפיין תיאור סוג ברירת מחדל נוכחות
מסכה

המאפיין mask מציין את טווח כתובות ה-IP שרוצים לאשר או לדחות. המסכה שקולה לשימוש בסימון CIDR (Classless Inter-Domain Routing). לדוגמה:

<SourceAddress mask="24">198.51.100.1</SourceAddress>

שווה לסימון ה-CIDR הבא:

198.51.100.1/24

הערכים האפשריים:

‫IPv4: ‏ 1-32

‫IPv6: ‏ 1-128

הערך אפס (0) תקף רק לכתובת ה-IP‏ 0.0.0.0, ולכן הוא לא מעשי.

הגדרת המסכה באמצעות משתנה

מאפיין mask תומך גם בתבניות של הודעות, כלומר אפשר להגדיר את הערך באמצעות משתנה שזמין כרגע בתהליך של proxy ל-API. לדוגמה, אפשר לאחסן ערך של מסכה ב-KVM ולהשתמש במדיניות KeyValueMapOperations כדי לאחזר את המסכה ולהקצות אותה למשתנה. כדי להגדיר את מסכת ה-IP באמצעות המשתנה, משתמשים בפורמט הבא, בהנחה שהמשתנה נקרא kvm.mask.value:

mask="{kvm.mask.value}"

מספר שלם לא רלוונטי חובה

אלמנט <ValidateBasedOn>

כשכותרת ה-HTTP‏ X-Forwarded-For מכילה כמה כתובות IP, משתמשים ברכיב ValidateBasedOn הזה כדי לקבוע אילו כתובות IP ייבדקו.

כדאי להשתמש בגישה הזו להערכת כתובות IP רק אם אתם בטוחים בתוקף של כתובות ה-IP שאתם רוצים להעריך. לדוגמה, אם בוחרים להעריך את כל כתובות ה-IP בכותרת X-Forwarded-For, צריך להיות בטוחים בתוקף של הכתובות האלה, או להגדיר כללי DENY או ALLOW מקיפים כדי לאפשר רק לכתובות IP מהימנות לקרוא ל-proxy ל-API.

כתובת ה-IP הכי שמאלית בכותרת שייכת ללקוח, והכי ימנית היא השרת שהעביר את הבקשה לשירות הנוכחי. כתובת ה-IP הכי שמאלית, או האחרונה, היא הכתובת ש-Apigee קיבלה מהלחיצת יד האחרונה של TCP חיצוני.

הערך שמזינים ברכיב הזה מאפשר לקבוע אם לבדוק את כל כתובות ה-IP בכותרת (ברירת מחדל), רק את כתובת ה-IP הראשונה או רק את כתובת ה-IP האחרונה.

<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1">
    <DisplayName>Access Control 1</DisplayName>
    <IPRules noRuleMatchAction = "ALLOW">
        <MatchRule action = "DENY">
            <SourceAddress mask="32">198.51.100.1</SourceAddress>
        </MatchRule>
    </IPRules>
    <ValidateBasedOn>X_FORWARDED_FOR_ALL_IP</ValidateBasedOn>
</AccessControl>
ברירת מחדל X_FORWARDED_FOR_ALL_IP
נוכחות אופציונלי
ערכים אפשריים

X_FORWARDED_FOR_ALL_IP (ברירת מחדל)

X_FORWARDED_FOR_FIRST_IP

X_FORWARDED_FOR_LAST_IP

סכימות

כל סוג מדיניות מוגדר על ידי סכימת XML ‏ (.xsd). לעיון, סכימות המדיניות זמינות ב-GitHub.

הפניה לשגיאה

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

שגיאות זמן ריצה

השגיאות האלה יכולות להתרחש כשהמדיניות מופעלת.

קוד תקלה סטטוס HTTP מטרה תיקון
accesscontrol.IPDeniedAccess 403 כתובת ה-IP של הלקוח, או כתובת IP שמועברת בבקשת ה-API, תואמת לכתובת IP שצוינה באלמנט <SourceAddress> בתוך האלמנט <MatchRule> של מדיניות בקרת הגישה, והמאפיין action של האלמנט <MatchRule> מוגדר לערך DENY.
accesscontrol.InvalidIPAddressInVariable 500 משתנה הזרימה ב-<ClientIPVariable> מכיל כתובת IP לא תקינה.

משתני תקלות

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

משתנים כאשר: דוגמה
fault.name="fault_name" fault_name הוא שם התקלה, כפי שמופיע בטבלה שגיאות בזמן ריצה שלמעלה. שם התקלה הוא החלק האחרון של קוד התקלה. fault.name Matches "IPDeniedAccess"
acl.policy_name.failed policy_name הוא השם שהמשתמש נתן למדיניות שגרמה לשגיאה. acl.AC-AllowAccess.failed = true

דוגמה לתגובה על תקלה

{
   "fault":{
     "faultstring":"Access Denied for client ip : 52.211.243.3"
      "detail":{
         "errorcode":"steps.accesscontrol.IPDeniedAccess"
      }
   }
}

דוגמה לכלל שגיאה

<FaultRule name="IPDeniedAccess">
    <Step>
        <Name>AM-IPDeniedAccess</Name>
        <Condition>(fault.name Matches "IPDeniedAccess") </Condition>
    </Step>
    <Condition>(acl.failed = true) </Condition>
</FaultRule>