Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

מדיניות 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 ולהסתרת כתובות IP במהלך זמן הריצה, בלי שתצטרכו לעדכן ולפרוס מחדש את ה-proxy ל-API. אתם יכולים להשתמש במדיניות KeyValueMapOperations כדי לאחזר את המשתנים שמכילים את הערכים של kvm.mask.value ושל kvm.ip.value (בהנחה שזה השם שנתתם למשתנים במדיניות KVM שמכילים את הערכים של המסכה ושל כתובות ה-IP מ-KVM). אם הערכים שאחזרתם היו 24 עבור המסכה ו-198.51.100.1 עבור כתובת ה-IP, מדיניות AccessControl תדחה את כל הבקשות מכתובת ה-IP: 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).
- כדי לקבוע אילו כתובות IP בהודעה אתם מגדירים כללים לטיפול בהן, כדאי לעיין במאמר איך המדיניות בוחרת איזו כתובת IP להעריך.
- מגדירים מסכה לכל כתובת IP. אתם מאשרים או דוחים גישה על סמך ערך מסכה בכתובת ה-IP. מידע נוסף זמין במאמר מידע על אנונימיזציה של כתובות IP באמצעות סימון CIDR.
מציינים את הסדר שבו הכללים נבדקים.
כל כללי ההתאמה מופעלים לפי הסדר שמופיע. כשכלל מתאים, הפעולה המתאימה מבוצעת וכללים נוספים שמתאימים להודעה נדלגים.
- אם אותו כלל מוגדר עם הפעולות 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 המדויקות שרוצים להעריך.

ב-Apigee hybrid, מומלץ להגדיר מאזן עומסים לפני אשכול Kubernetes. מאזן העומסים יכול להיות L7 (מודע ל-HTTP) או L4 (מודע ל-TCP). מאזני עומסים ברמה 7 יכולים להוסיף את כתובת ה-IP של מקור הלקוח לכותרת X-Forwarded-For (XFF). צריך להגדיר את מאזני העומסים ברמה L4 לשימוש בפרוטוקול PROXY. כדי להפעיל תמיכה בפרוטוקול PROXY, צריך לעיין במדריך של מאזן העומסים. הוראות להפעלת פרוטוקול ה-PROXY ב-Ingress מופיעות במאמר כתובת ה-IP של המקור של הלקוח המקורי במסמכי התיעוד של Istio.

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

כותרת X-Forwarded-For

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

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

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

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

הערה: פורמט הכותרת X-Forwarded-For תלוי בטופולוגיית הרשת (הנתיב שבו הבקשה עוברת ברשת).

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

הערה: אפשר להשתמש במשתנה הזרימה client.resolved.ip כדי לקבל את כתובת ה-IP של הלקוח. מידע על האופן שבו נקבעת כתובת ה-IP של הלקוח עבור המשתנה הזה מופיע במאמר בנושא Client IP resolution.

נניח שמשתנה הזרימה מוגדר ל-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>

ברירת מחדל	לא רלוונטי
נוכחות	אופציונלי
סוג	משתנה בתהליך

אלמנט <IgnoreTrueClientIPHeader>

הערה: אם לא כוללים את הרכיב הזה או מגדירים אותו כ-false, בשלב הזה Apigee לא מעריך את הכותרת True-Client-IP בצורה נכונה.

אלמנט <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	אישור	חובה

מאפיין

תיאור

סוג

ברירת מחדל

נוכחות

פעולה

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

ערך תקין: 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}"`	מספר שלם	לא רלוונטי	חובה

המאפיין 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.

הערה: אפשר להשתמש במשתנה הזרימה client.resolved.ip כדי לקבל את כתובת ה-IP של הלקוח ב-<clientIPVariable> במקום להשתמש ב-<ValidateBasedOn>. מידע נוסף על האלמנט<ClientIPVariable>

כתובת ה-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_ALL_IP` (ברירת מחדל) `X_FORWARDED_FOR_FIRST_IP` `X_FORWARDED_FOR_LAST_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` הוא שם התקלה, כפי שמופיע בטבלה Runtime errors שלמעלה. שם התקלה הוא החלק האחרון של קוד התקלה.	`fault.name Matches "IPDeniedAccess"`
`acl.policy_name.failed`	‫`policy_name` הוא השם שהמשתמש הגדיר למדיניות שגרמה לשגיאה.	`acl.AC-AllowAccess.failed = true`

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

הערה: כדי לטפל בשגיאות, מומלץ ללכוד את החלק errorcode בתגובה לשגיאה. אל תסתמכו על הטקסט ב-faultstring כי הוא עשוי להשתנות.

{
   "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>

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

דוגמאות

דחייה של 198.51.100.1

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

דחייה של 198.51.100.*

‪198.51.*.*

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

Allow 198.51.*.*

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

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

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

הערות שימוש

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

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

כותרת X-Forwarded-For

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

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

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

הפניה לרכיב

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

רכיב <ClientIPVariable>

אלמנט <IgnoreTrueClientIPHeader>

אלמנט <IPRules>

מאפיינים

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

מאפיינים

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

מאפיינים

אלמנט <ValidateBasedOn>

סכימות

הפניה לשגיאה

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

משתני תקלות

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

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

מדיניות AccessControl

‪198.51..

Allow 198.51..