خط مشی AccessControl

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

چه

سیاست کنترل دسترسی به شما امکان می‌دهد دسترسی به APIهای خود را توسط آدرس‌های IP خاص مجاز یا غیرمجاز کنید.

اگرچه می‌توانید این سیاست را در هر جایی از جریان پروکسی API پیوست کنید، اما به احتمال زیاد می‌خواهید آدرس‌های IP را در ابتدای جریان (Request / ProxyEndpoint / PreFlow) حتی قبل از احراز هویت یا بررسی سهمیه بررسی کنید.

نمونه‌ها

مقادیر ماسک در نمونه‌های IPv4 زیر مشخص می‌کنند که قانون تطبیق کدام یک از چهار اکتت (8، 16، 24، 32 بیتی) را هنگام اجازه یا رد دسترسی در نظر می‌گیرد. مقدار پیش‌فرض 32 است. برای اطلاعات بیشتر به ویژگی mask در مرجع Element مراجعه کنید.

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

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

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

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

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

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

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

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

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

یادداشت‌های استفاده

علاوه بر محافظت از APIهای شما در برابر IPهای مخرب، سیاست کنترل دسترسی به شما امکان کنترل دسترسی به IPهای قانونی را نیز می‌دهد. به عنوان مثال، اگر فقط می‌خواهید کامپیوترهای تحت کنترل شرکت شما به APIهای موجود در محیط آزمایشی شما دسترسی داشته باشند، می‌توانید محدوده آدرس IP را برای شبکه داخلی خود مجاز کنید. توسعه‌دهندگانی که از خانه کار می‌کنند می‌توانند با استفاده از VPN به این APIها دسترسی پیدا کنند.

پیکربندی و اجرای یک سیاست کنترل دسترسی شامل موارد زیر است:

• مجموعه‌ای از قوانین تطبیق را با یکی از دو اقدام (اجازه دادن یا رد کردن) مرتبط با هر یک تعریف کنید.
• برای هر قانون تطابق، آدرس IP (عنصر SourceAddress) را مشخص کنید.
  • ببینید چگونه این سیاست، آدرس IP مورد نظر را برای ارزیابی انتخاب می‌کند تا مشخص شود کدام آدرس IP در پیامی که شما در حال پیکربندی قوانین برای رسیدگی به آن هستید، قرار دارد.
  • برای هر آدرس IP یک ماسک پیکربندی کنید. شما بر اساس مقدار ماسک روی آدرس IP، دسترسی را مجاز یا غیرمجاز می‌کنید. به بخش «درباره ماسک IP با نماد CIDR» مراجعه کنید.
• ترتیب آزمایش قوانین را مشخص کنید.
• تمام قوانین تطبیق به ترتیب داده شده اجرا می‌شوند. وقتی یک قانون تطبیق می‌یابد، عمل مربوطه اجرا می‌شود و قوانین تطبیق بعدی نادیده گرفته می‌شوند.
  • اگر یک قانون واحد با هر دو اقدام ALLOW و DENY پیکربندی شده باشد، قانونی که در ترتیب اول تعریف شده است، اجرا می‌شود و قانون بعدی (با اقدام دیگر) نادیده گرفته می‌شود.

چگونه سیاست، آدرس IP مورد ارزیابی را انتخاب می‌کند

آدرس‌های IP می‌توانند از منابع مختلفی در یک درخواست وارد شوند. برای مثال، هدر پیام True-Client-IP ممکن است حاوی یک آدرس IP باشد و هدر X-Forwarded-For ممکن است حاوی یک یا چند آدرس IP باشد. این بخش نحوه پیکربندی سیاست AccessControl را برای ارزیابی آدرس‌های IP دقیقی که می‌خواهید ارزیابی کنید، شرح می‌دهد.

منطق مورد استفاده‌ی سیاست AccessControl برای تصمیم‌گیری در مورد اینکه کدام آدرس IP ارزیابی شود، به شرح زیر است:

۱. هدر True-Client-IP

این سیاست ابتدا وجود یک آدرس IP را در هدر True-Client-IP بررسی می‌کند. اگر هدر حاوی یک آدرس IP معتبر باشد، سیاست آن آدرس را ارزیابی می‌کند.

۲. هدر X-Forwarded-For

اگر هدر True-Client-IP وجود نداشته باشد، یا اگر عنصر <IgnoreTrueClientIPHeader> را روی true تنظیم کرده باشید، این خط‌مشی آدرس(های) IP موجود در هدر X-Forwarded-For را ارزیابی می‌کند.

Edge به طور خودکار هدر X-Forwarded-For را با آدرس IP که از آخرین TCP handshake خارجی (مانند IP کلاینت یا روتر) دریافت کرده است، پر می‌کند. اگر چندین آدرس IP در هدر وجود داشته باشد، آن آدرس‌ها احتمالاً زنجیره‌ای از سرورهایی هستند که یک درخواست را پردازش کرده‌اند. با این حال، لیست آدرس‌ها می‌تواند شامل یک آدرس IP جعلی نیز باشد. بنابراین، این سیاست چگونه می‌داند کدام آدرس‌ها را ارزیابی کند؟

پیکربندی سازمان و پیکربندی سیاست شما تعیین می‌کند که کدام آدرس (آدرس‌های) X-Forwarded-For سیاست ارزیابی شود.

ابتدا بررسی کنید که آیا ویژگی feature.enableMultipleXForwardCheckForACL روی سازمان شما تنظیم شده است یا خیر. می‌توانید از Get organization API برای بررسی این موضوع استفاده کنید. سپس:

• اگر feature.enableMultipleXForwardCheckForACL را در فهرست ویژگی‌های سازمان خود نمی‌بینید، به این معنی است که این ویژگی روی false (پیش‌فرض) تنظیم شده است. با تنظیم این ویژگی روی false، سیاست آخرین آدرس موجود در هدر (که در ابزار Trace قابل مشاهده است) را ارزیابی می‌کند، که همان آدرس IP دریافتی Edge از آخرین handshake TCP خارجی است.
• اگر feature.enableMultipleXForwardCheckForACL در سازمان شما روی true تنظیم شده است، عنصر <ValidateBasedOn> را پیکربندی کنید تا مشخص شود کدام آدرس‌های IP توسط این سیاست ارزیابی می‌شوند.

تغییر feature.enableMultipleXForwardCheckForACL

مدیران سازمان Edge می‌توانند از API مربوط به Update organization properties برای تنظیم ویژگی feature.enableMultipleXForwardCheckForACL استفاده کنند.

مثال API زیر، ویژگی را در Edge برای Private Cloud تنظیم می‌کند. اگر ویژگی‌های دیگری در سازمان شما تنظیم شده است، حتماً آنها را نیز وارد کنید. در غیر این صورت، حذف خواهند شد .

curl -u email:password -X POST -H "Content-type:application/xml" http://host:8080/v1/o/myorg -d \
"<Organization type="trial" name="MyOrganization">
    <DisplayName>MyOrganization</DisplayName>
    <Properties>
        <Property name="feature.enableMultipleXForwardCheckForACL">true</Property>
        <!-- Include other existing properties as well. -->
    </Properties>
</Organization>"

در Edge برای Private Cloud، پس از تغییر مقدار feature.enableMultipleXForwardCheckForACL ، باید پردازنده‌های پیام خود را مجدداً راه‌اندازی کنید، همانطور که در Start/stop/restart individual components توضیح داده شده است.

ابعاد X-Forwarded-For در تجزیه و تحلیل Apigee

Edge Analytics مقدار هدر X-Forwarded-For را در بُعد x_forwarded_for_ip می‌نویسد. برای تعیین IP کلاینتی که درخواست را به Edge ارسال کرده است، از مقادیر موجود در بُعدهای ax_true_client_ip یا ax_resolved_client_ip استفاده کنید. برای اطلاعات بیشتر به مرجع معیارها، ابعاد و فیلترهای Analytics مراجعه کنید.

درباره پوشش IP با نماد CIDR

نمادگذاری CIDR (مسیریابی بین دامنه‌ای بدون کلاس) روشی برای نشان دادن طیف وسیعی از آدرس‌های IP از طریق ماسک کردن است. این نمادگذاری هم برای IPv4 و هم برای IPv6 اعمال می‌شود. نحوه کار آن به این صورت است. ما برای سادگی در مثال‌های خود از IPv4 استفاده خواهیم کرد.

آدرس‌های IP گروه‌هایی از اعداد هستند که با نقطه از هم جدا شده‌اند. به صورت دودویی، هر گروه تعداد مشخصی از بیت‌ها را تشکیل می‌دهد (۸ برای IPv4 و ۱۶ برای IPv6). آدرس IPv4 به صورت دودویی به شکل ۱۹۸.۵۱.۱۰۰.۱ است:

11000110.00110011.01100100.00000001

این ۴ گروه ۸ بیتی یا در مجموع ۳۲ بیت است. با CIDR، می‌توانید با اضافه کردن /number (1-32) به آدرس IP، یک محدوده را مشخص کنید، مانند این:

198.51.100.1/24

در این حالت، عدد ۲۴ عددی است که برای مقدار ویژگی mask در این خط‌مشی استفاده خواهید کرد.

این نمادگذاری به این معنی است که «۲۴ بیت اول را دقیقاً همانطور که هست نگه دارید، بیت‌های باقی‌مانده می‌توانند هر مقداری از ۰ تا ۲۵۵ داشته باشند.» برای مثال:

توجه داشته باشید که ماسک در انتهای گروه سه قرار می‌گیرد. این باعث می‌شود همه چیز مرتب و زیبا شود، در اصل ماسکی مانند این ایجاد می‌شود: 198.51.100.*. در بیشتر موارد، استفاده از مضرب‌های 8 (IPv4) و 16 (IPv6) سطح ماسک مورد نظر شما را به شما می‌دهد:

آی‌پی نسخه ۴: ۸، ۱۶، ۲۴، ۳۲

IPv6: 16، 32، 48، 64، 80، 96، 112، 128

با این حال، می‌توانید از اعداد دیگری برای کنترل دقیق‌تر استفاده کنید که شامل محاسبات دودویی کمی می‌شود. در اینجا مثالی با استفاده از ماسک 30، مانند 198.51.100.1/30 ، آورده شده است که در آن آخرین 1 برابر با 00000001 در دودویی است:

در این مثال، با تنظیم پیکربندی روی <SourceAddress mask="30">198.51.100.1</SourceAddress> ، IP های زیر مجاز (یا ممنوع، بسته به قوانین شما) خواهند بود:

• ۱۹۸.۵۱.۱۰۰.۰
• ۱۹۸.۵۱.۱۰۰.۱
• ۱۹۸.۵۱.۱۰۰.۲
• ۱۹۸.۵۱.۱۰۰.۳

مرجع عنصر

مرجع عنصر، عناصر و ویژگی‌های سیاست کنترل دسترسی را توصیف می‌کند.

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

جدول زیر ویژگی هایی را توصیف می کند که برای همه عناصر اصلی خط مشی مشترک هستند:

عنصر <DisplayName>

علاوه بر ویژگی name برای برچسب‌گذاری خط‌مشی در ویرایشگر پروکسی رابط کاربری مدیریت با نامی متفاوت و به زبان طبیعی، از آن استفاده کنید.

<DisplayName>Policy Display Name</DisplayName>

عنصر <نادیده گرفتن TrueClientIPHead>

وقتی این را روی true تنظیم می‌کنید، این خط‌مشی هدر True-Client-IP را نادیده می‌گیرد و آدرس‌های IP موجود در هدر X-Forwarded-For را ارزیابی می‌کند، که از رفتار ارزیابی X-Forwarded-For که پیکربندی کرده‌اید، پیروی می‌کند.

<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1">
    <DisplayName>Access Control-1</DisplayName>
    <IgnoreTrueClientIPHeader>true</IgnoreTrueClientIPHeader>
    ...
</AccessControl>

عنصر <IPRules>

عنصر والد حاوی قوانینی که آدرس‌های IP را مجاز یا غیرمجاز می‌کنند. ویژگی noRuleMatchAction به شما امکان می‌دهد نحوه برخورد با هر آدرس IP که تحت پوشش قوانین تطبیق شما نیست را تعریف کنید.

<IPRules noRuleMatchAction = "ALLOW">

ویژگی‌ها

عنصر <IPRules>/<MatchRule>

اقدامی که باید انجام شود (اجازه دسترسی یا عدم دسترسی) اگر آدرس IP با SourceAddress(es) تعریف شده شما مطابقت داشته باشد.

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

ویژگی‌ها

عنصر <IPRules>/<MatchRule>/<SourceAddress>

محدوده آدرس IP یک کلاینت.

مقدار معتبر: آدرس IP معتبر (نماد اعشاری نقطه‌ای). برای رفتار wildcard، از ویژگی 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 نیز پشتیبانی می‌کند، به این معنی که می‌توانید مقادیر را با استفاده از متغیرهایی که در حال حاضر در جریان پروکسی API در دسترس هستند، تنظیم کنید.

برای مثال، می‌توانید یک آدرس IP را در یک نقشه مقدار کلیدی (KVM) ذخیره کنید و از سیاست KeyValueMapOperations برای بازیابی آدرس IP و اختصاص آن به یک متغیر (مانند kvm.ip.value ) استفاده کنید. سپس می‌توانید از آن متغیر برای آدرس IP استفاده کنید:

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

تنظیم ماسک و/یا آدرس IP با یک متغیر به شما این انعطاف‌پذیری را می‌دهد که مقادیر را در زمان اجرا تغییر دهید، بدون اینکه نیاز به تغییر و استقرار مجدد پروکسی API خود داشته باشید.

ویژگی‌ها

عنصر <ValidateBasedOn>

وقتی هدر HTTP مربوط به X-Forwarded-For شامل چندین آدرس IP باشد، از این عنصر ValidateBasedOn برای کنترل اینکه کدام آدرس‌های IP ارزیابی شوند، استفاده کنید.

فقط در صورتی از این رویکرد برای ارزیابی آدرس‌های IP استفاده کنید که از اعتبار آدرس‌های IP مورد نظر خود مطمئن هستید. برای مثال، اگر تصمیم دارید تمام آدرس‌های IP موجود در هدر X-Forwarded-For را ارزیابی کنید، باید بتوانید به اعتبار آن آدرس‌ها اعتماد کنید و/یا قوانین جامع DENY یا ALLOW را تنظیم کنید تا فقط IPهای مورد اعتماد بتوانند با پروکسی API شما تماس بگیرند.

سمت چپ‌ترین آدرس IP در هدر متعلق به کلاینت است و سمت راست‌ترین آدرس، سروری است که درخواست را به سرویس فعلی ارسال کرده است. سمت راست‌ترین یا آخرین آدرس IP، آدرسی است که Edge از آخرین TCP handshake خارجی دریافت کرده است.

مقداری که در این عنصر وارد می‌کنید به شما امکان می‌دهد تعیین کنید که آیا تمام آدرس‌های 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>

طرحواره‌ها

هر نوع سیاست توسط یک طرح XML (.xsd) تعریف می‌شود. برای مرجع، طرح‌های سیاست در GitHub موجود است.

مرجع خطا

این بخش کدهای خطا و پیام‌های خطایی را که برگردانده می‌شوند و متغیرهای خطا را که توسط Edge تنظیم می‌شوند، هنگامی که این خط‌مشی خطا را راه‌اندازی می‌کند، توضیح می‌دهد. این اطلاعات برای دانستن اینکه آیا در حال توسعه قوانین خطا برای رسیدگی به خطاها هستید، مهم است. برای کسب اطلاعات بیشتر، آنچه را که باید در مورد خطاهای خط مشی و مدیریت خطاها بدانید را ببینید.

خطاهای زمان اجرا

این خطاها ممکن است هنگام اجرای سیاست رخ دهند.

متغیرهای خطا

این متغیرها زمانی تنظیم می شوند که یک خطای زمان اجرا رخ دهد. برای اطلاعات بیشتر، متغیرهای مخصوص خطاهای خط مشی را ببینید.

نمونه پاسخ خطا

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

مثال قانون خطا

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

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

چه

سیاست کنترل دسترسی به شما امکان می‌دهد دسترسی به APIهای خود را توسط آدرس‌های IP خاص مجاز یا غیرمجاز کنید.

اگرچه می‌توانید این سیاست را در هر جایی از جریان پروکسی API پیوست کنید، اما به احتمال زیاد می‌خواهید آدرس‌های IP را در ابتدای جریان (Request / ProxyEndpoint / PreFlow) حتی قبل از احراز هویت یا بررسی سهمیه بررسی کنید.

نمونه‌ها

مقادیر ماسک در نمونه‌های IPv4 زیر مشخص می‌کنند که قانون تطبیق کدام یک از چهار اکتت (8، 16، 24، 32 بیتی) را هنگام اجازه یا رد دسترسی در نظر می‌گیرد. مقدار پیش‌فرض 32 است. برای اطلاعات بیشتر به ویژگی mask در مرجع Element مراجعه کنید.

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

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

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

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

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

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

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

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

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

یادداشت‌های استفاده

علاوه بر محافظت از APIهای شما در برابر IPهای مخرب، سیاست کنترل دسترسی به شما امکان کنترل دسترسی به IPهای قانونی را نیز می‌دهد. به عنوان مثال، اگر فقط می‌خواهید کامپیوترهای تحت کنترل شرکت شما به APIهای موجود در محیط آزمایشی شما دسترسی داشته باشند، می‌توانید محدوده آدرس IP را برای شبکه داخلی خود مجاز کنید. توسعه‌دهندگانی که از خانه کار می‌کنند می‌توانند با استفاده از VPN به این APIها دسترسی پیدا کنند.

پیکربندی و اجرای یک سیاست کنترل دسترسی شامل موارد زیر است:

• مجموعه‌ای از قوانین تطبیق را با یکی از دو اقدام (اجازه دادن یا رد کردن) مرتبط با هر یک تعریف کنید.
• برای هر قانون تطابق، آدرس IP (عنصر SourceAddress) را مشخص کنید.
  • ببینید چگونه این سیاست، آدرس IP مورد نظر را برای ارزیابی انتخاب می‌کند تا مشخص شود کدام آدرس IP در پیامی که شما در حال پیکربندی قوانین برای رسیدگی به آن هستید، قرار دارد.
  • برای هر آدرس IP یک ماسک پیکربندی کنید. شما بر اساس مقدار ماسک روی آدرس IP، دسترسی را مجاز یا غیرمجاز می‌کنید. به بخش «درباره ماسک IP با نماد CIDR» مراجعه کنید.
• ترتیب آزمایش قوانین را مشخص کنید.
• تمام قوانین تطبیق به ترتیب داده شده اجرا می‌شوند. وقتی یک قانون تطبیق می‌یابد، عمل مربوطه اجرا می‌شود و قوانین تطبیق بعدی نادیده گرفته می‌شوند.
  • اگر یک قانون واحد با هر دو اقدام ALLOW و DENY پیکربندی شده باشد، قانونی که در ترتیب اول تعریف شده است، اجرا می‌شود و قانون بعدی (با اقدام دیگر) نادیده گرفته می‌شود.

چگونه سیاست، آدرس IP مورد ارزیابی را انتخاب می‌کند

آدرس‌های IP می‌توانند از منابع مختلفی در یک درخواست وارد شوند. برای مثال، هدر پیام True-Client-IP ممکن است حاوی یک آدرس IP باشد و هدر X-Forwarded-For ممکن است حاوی یک یا چند آدرس IP باشد. این بخش نحوه پیکربندی سیاست AccessControl را برای ارزیابی آدرس‌های IP دقیقی که می‌خواهید ارزیابی کنید، شرح می‌دهد.

منطق مورد استفاده‌ی سیاست AccessControl برای تصمیم‌گیری در مورد اینکه کدام آدرس IP ارزیابی شود، به شرح زیر است:

۱. هدر True-Client-IP

این سیاست ابتدا وجود یک آدرس IP را در هدر True-Client-IP بررسی می‌کند. اگر هدر حاوی یک آدرس IP معتبر باشد، سیاست آن آدرس را ارزیابی می‌کند.

۲. هدر X-Forwarded-For

اگر هدر True-Client-IP وجود نداشته باشد، یا اگر عنصر <IgnoreTrueClientIPHeader> را روی true تنظیم کرده باشید، این خط‌مشی آدرس(های) IP موجود در هدر X-Forwarded-For را ارزیابی می‌کند.

Edge به طور خودکار هدر X-Forwarded-For را با آدرس IP که از آخرین TCP handshake خارجی (مانند IP کلاینت یا روتر) دریافت کرده است، پر می‌کند. اگر چندین آدرس IP در هدر وجود داشته باشد، آن آدرس‌ها احتمالاً زنجیره‌ای از سرورهایی هستند که یک درخواست را پردازش کرده‌اند. با این حال، لیست آدرس‌ها می‌تواند شامل یک آدرس IP جعلی نیز باشد. بنابراین، این سیاست چگونه می‌داند کدام آدرس‌ها را ارزیابی کند؟

پیکربندی سازمان و پیکربندی سیاست شما تعیین می‌کند که کدام آدرس (آدرس‌های) X-Forwarded-For سیاست ارزیابی شود.

ابتدا بررسی کنید که آیا ویژگی feature.enableMultipleXForwardCheckForACL روی سازمان شما تنظیم شده است یا خیر. می‌توانید از Get organization API برای بررسی این موضوع استفاده کنید. سپس:

• اگر feature.enableMultipleXForwardCheckForACL را در فهرست ویژگی‌های سازمان خود نمی‌بینید، به این معنی است که این ویژگی روی false (پیش‌فرض) تنظیم شده است. با تنظیم این ویژگی روی false، سیاست آخرین آدرس موجود در هدر (که در ابزار Trace قابل مشاهده است) را ارزیابی می‌کند، که همان آدرس IP دریافتی Edge از آخرین handshake TCP خارجی است.
• اگر feature.enableMultipleXForwardCheckForACL در سازمان شما روی true تنظیم شده است، عنصر <ValidateBasedOn> را پیکربندی کنید تا مشخص شود کدام آدرس‌های IP توسط این سیاست ارزیابی می‌شوند.

تغییر feature.enableMultipleXForwardCheckForACL

مدیران سازمان Edge می‌توانند از API مربوط به Update organization properties برای تنظیم ویژگی feature.enableMultipleXForwardCheckForACL استفاده کنند.

مثال API زیر، ویژگی را در Edge برای Private Cloud تنظیم می‌کند. اگر ویژگی‌های دیگری در سازمان شما تنظیم شده است، حتماً آنها را نیز وارد کنید. در غیر این صورت، حذف خواهند شد .

curl -u email:password -X POST -H "Content-type:application/xml" http://host:8080/v1/o/myorg -d \
"<Organization type="trial" name="MyOrganization">
    <DisplayName>MyOrganization</DisplayName>
    <Properties>
        <Property name="feature.enableMultipleXForwardCheckForACL">true</Property>
        <!-- Include other existing properties as well. -->
    </Properties>
</Organization>"

در Edge برای Private Cloud، پس از تغییر مقدار feature.enableMultipleXForwardCheckForACL ، باید پردازنده‌های پیام خود را مجدداً راه‌اندازی کنید، همانطور که در Start/stop/restart individual components توضیح داده شده است.

ابعاد X-Forwarded-For در تجزیه و تحلیل Apigee

Edge Analytics مقدار هدر X-Forwarded-For را در بُعد x_forwarded_for_ip می‌نویسد. برای تعیین IP کلاینتی که درخواست را به Edge ارسال کرده است، از مقادیر موجود در بُعدهای ax_true_client_ip یا ax_resolved_client_ip استفاده کنید. برای اطلاعات بیشتر به مرجع معیارها، ابعاد و فیلترهای Analytics مراجعه کنید.

درباره پوشش IP با نماد CIDR

نمادگذاری CIDR (مسیریابی بین دامنه‌ای بدون کلاس) روشی برای نشان دادن طیف وسیعی از آدرس‌های IP از طریق ماسک کردن است. این نمادگذاری هم برای IPv4 و هم برای IPv6 اعمال می‌شود. نحوه کار آن به این صورت است. ما برای سادگی در مثال‌های خود از IPv4 استفاده خواهیم کرد.

آدرس‌های IP گروه‌هایی از اعداد هستند که با نقطه از هم جدا شده‌اند. به صورت دودویی، هر گروه تعداد مشخصی از بیت‌ها را تشکیل می‌دهد (۸ برای IPv4 و ۱۶ برای IPv6). آدرس IPv4 به صورت دودویی به شکل ۱۹۸.۵۱.۱۰۰.۱ است:

11000110.00110011.01100100.00000001

این ۴ گروه ۸ بیتی یا در مجموع ۳۲ بیت است. با CIDR، می‌توانید با اضافه کردن /number (1-32) به آدرس IP، یک محدوده را مشخص کنید، مانند این:

198.51.100.1/24

در این حالت، عدد ۲۴ عددی است که برای مقدار ویژگی mask در این خط‌مشی استفاده خواهید کرد.

این نمادگذاری به این معنی است که «۲۴ بیت اول را دقیقاً همانطور که هست نگه دارید، بیت‌های باقی‌مانده می‌توانند هر مقداری از ۰ تا ۲۵۵ داشته باشند.» برای مثال:

توجه داشته باشید که ماسک در انتهای گروه سه قرار می‌گیرد. این باعث می‌شود همه چیز مرتب و زیبا شود، در اصل ماسکی مانند این ایجاد می‌شود: 198.51.100.*. در بیشتر موارد، استفاده از مضرب‌های 8 (IPv4) و 16 (IPv6) سطح ماسک مورد نظر شما را به شما می‌دهد:

آی‌پی نسخه ۴: ۸، ۱۶، ۲۴، ۳۲

IPv6: 16، 32، 48، 64، 80، 96، 112، 128

با این حال، می‌توانید از اعداد دیگری برای کنترل دقیق‌تر استفاده کنید که شامل محاسبات دودویی کمی می‌شود. در اینجا مثالی با استفاده از ماسک 30، مانند 198.51.100.1/30 ، آورده شده است که در آن آخرین 1 برابر با 00000001 در دودویی است:

در این مثال، با تنظیم پیکربندی روی <SourceAddress mask="30">198.51.100.1</SourceAddress> ، IP های زیر مجاز (یا ممنوع، بسته به قوانین شما) خواهند بود:

• ۱۹۸.۵۱.۱۰۰.۰
• ۱۹۸.۵۱.۱۰۰.۱
• ۱۹۸.۵۱.۱۰۰.۲
• ۱۹۸.۵۱.۱۰۰.۳

مرجع عنصر

مرجع عنصر، عناصر و ویژگی‌های سیاست کنترل دسترسی را توصیف می‌کند.

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

جدول زیر ویژگی هایی را توصیف می کند که برای همه عناصر اصلی خط مشی مشترک هستند:

عنصر <DisplayName>

علاوه بر ویژگی name برای برچسب‌گذاری خط‌مشی در ویرایشگر پروکسی رابط کاربری مدیریت با نامی متفاوت و به زبان طبیعی، از آن استفاده کنید.

<DisplayName>Policy Display Name</DisplayName>

عنصر <نادیده گرفتن TrueClientIPHead>

وقتی این را روی true تنظیم می‌کنید، این خط‌مشی هدر True-Client-IP را نادیده می‌گیرد و آدرس‌های IP موجود در هدر X-Forwarded-For را ارزیابی می‌کند، که از رفتار ارزیابی X-Forwarded-For که پیکربندی کرده‌اید، پیروی می‌کند.

<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1">
    <DisplayName>Access Control-1</DisplayName>
    <IgnoreTrueClientIPHeader>true</IgnoreTrueClientIPHeader>
    ...
</AccessControl>

عنصر <IPRules>

عنصر والد حاوی قوانینی که آدرس‌های IP را مجاز یا غیرمجاز می‌کنند. ویژگی noRuleMatchAction به شما امکان می‌دهد نحوه برخورد با هر آدرس IP که تحت پوشش قوانین تطبیق شما نیست را تعریف کنید.

<IPRules noRuleMatchAction = "ALLOW">

ویژگی‌ها

عنصر <IPRules>/<MatchRule>

اقدامی که باید انجام شود (اجازه دسترسی یا عدم دسترسی) اگر آدرس IP با SourceAddress(es) تعریف شده شما مطابقت داشته باشد.

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

ویژگی‌ها

عنصر <IPRules>/<MatchRule>/<SourceAddress>

محدوده آدرس IP یک کلاینت.

مقدار معتبر: آدرس IP معتبر (نماد اعشاری نقطه‌ای). برای رفتار wildcard، از ویژگی 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 نیز پشتیبانی می‌کند، به این معنی که می‌توانید مقادیر را با استفاده از متغیرهایی که در حال حاضر در جریان پروکسی API در دسترس هستند، تنظیم کنید.

برای مثال، می‌توانید یک آدرس IP را در یک نقشه مقدار کلیدی (KVM) ذخیره کنید و از سیاست KeyValueMapOperations برای بازیابی آدرس IP و اختصاص آن به یک متغیر (مانند kvm.ip.value ) استفاده کنید. سپس می‌توانید از آن متغیر برای آدرس IP استفاده کنید:

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

تنظیم ماسک و/یا آدرس IP با یک متغیر به شما این انعطاف‌پذیری را می‌دهد که مقادیر را در زمان اجرا تغییر دهید، بدون اینکه نیاز به تغییر و استقرار مجدد پروکسی API خود داشته باشید.

ویژگی‌ها

عنصر <ValidateBasedOn>

وقتی هدر HTTP مربوط به X-Forwarded-For شامل چندین آدرس IP باشد، از این عنصر ValidateBasedOn برای کنترل اینکه کدام آدرس‌های IP ارزیابی شوند، استفاده کنید.

فقط در صورتی از این رویکرد برای ارزیابی آدرس‌های IP استفاده کنید که از اعتبار آدرس‌های IP مورد نظر خود مطمئن هستید. برای مثال، اگر تصمیم دارید تمام آدرس‌های IP موجود در هدر X-Forwarded-For را ارزیابی کنید، باید بتوانید به اعتبار آن آدرس‌ها اعتماد کنید و/یا قوانین جامع DENY یا ALLOW را تنظیم کنید تا فقط IPهای مورد اعتماد بتوانند با پروکسی API شما تماس بگیرند.

سمت چپ‌ترین آدرس IP در هدر متعلق به کلاینت است و سمت راست‌ترین آدرس، سروری است که درخواست را به سرویس فعلی ارسال کرده است. سمت راست‌ترین یا آخرین آدرس IP، آدرسی است که Edge از آخرین TCP handshake خارجی دریافت کرده است.

مقداری که در این عنصر وارد می‌کنید به شما امکان می‌دهد تعیین کنید که آیا تمام آدرس‌های 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>

طرحواره‌ها

هر نوع سیاست توسط یک طرح XML (.xsd) تعریف می‌شود. برای مرجع، طرح‌های سیاست در GitHub موجود است.

مرجع خطا

این بخش کدهای خطا و پیام‌های خطایی را که برگردانده می‌شوند و متغیرهای خطا را که توسط Edge تنظیم می‌شوند، هنگامی که این خط‌مشی خطا را راه‌اندازی می‌کند، توضیح می‌دهد. این اطلاعات برای دانستن اینکه آیا در حال توسعه قوانین خطا برای رسیدگی به خطاها هستید، مهم است. برای کسب اطلاعات بیشتر، آنچه را که باید در مورد خطاهای خط مشی و مدیریت خطاها بدانید را ببینید.

خطاهای زمان اجرا

این خطاها ممکن است هنگام اجرای سیاست رخ دهند.

متغیرهای خطا

این متغیرها زمانی تنظیم می شوند که یک خطای زمان اجرا رخ دهد. برای اطلاعات بیشتر، متغیرهای مخصوص خطاهای خط مشی را ببینید.

نمونه پاسخ خطا

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

مثال قانون خطا

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