AccessControl नीति

आपको Apigee Edge का दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी

क्या

ऐक्सेस कंट्रोल की नीति की मदद से, कुछ आईपी पतों को अपने एपीआई का ऐक्सेस दिया जा सकता है या उनसे ऐक्सेस वापस लिया जा सकता है.

इस नीति को एपीआई प्रॉक्सी फ़्लो में कहीं भी अटैच किया जा सकता है. हालांकि, आपको फ़्लो की शुरुआत में ( Request / ProxyEndpoint / PreFlow) आईपी पतों की जांच करनी चाहिए. यह जांच, पुष्टि करने या कोटे की जांच से पहले भी की जा सकती है.

सैंपल

नीचे दिए गए IPv4 के सैंपल में मौजूद मास्क वैल्यू से पता चलता है कि मैच करने का नियम, ऐक्सेस की अनुमति देते या अस्वीकार करते समय, चार ऑक्टेट (8, 16, 24, 32 बिट) में से किस ऑक्टेट पर विचार करता है. डिफ़ॉल्ट वैल्यू 32 होती है. ज़्यादा जानकारी के लिए, एलिमेंट रेफ़रंस में mask एट्रिब्यूट देखें.

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

इस्तेमाल की जानकारी

ऐक्सेस कंट्रोल की नीति, आपके एपीआई को नुकसान पहुंचाने वाले आईपी पतों से सुरक्षित रखती है. साथ ही, यह आपको सही आईपी पतों के ऐक्सेस को कंट्रोल करने की सुविधा भी देती है. उदाहरण के लिए, अगर आपको सिर्फ़ अपनी कंपनी के कंट्रोल वाले कंप्यूटरों को, टेस्ट एनवायरमेंट में दिखाए गए एपीआई ऐक्सेस करने की अनुमति देनी है, तो अपने इंटरनल नेटवर्क के लिए आईपी पते की रेंज को अनुमति दी जा सकती है. घर से काम करने वाले डेवलपर, वीपीएन का इस्तेमाल करके इन एपीआई को ऐक्सेस कर सकते हैं.

ऐक्सेस कंट्रोल की नीति को कॉन्फ़िगर और लागू करने के लिए, ये काम करने होते हैं:

• मिलान के नियमों का एक सेट तय करें. इसमें हर नियम के लिए, दो कार्रवाइयों (ALLOW या DENY) में से कोई एक कार्रवाई तय करें.
• हर मैच के नियम के लिए, आईपी पता (SourceAddress एलिमेंट) तय करें.
  • यह तय करने के लिए कि मैसेज में मौजूद किन आईपी पतों के लिए नियमों को कॉन्फ़िगर करना है, नीति यह कैसे तय करती है कि किस आईपी पते का आकलन करना है लेख पढ़ें.
  • हर आईपी पते के लिए मास्क कॉन्फ़िगर करें. आपके पास आईपी पते पर मास्क वैल्यू के आधार पर, ऐक्सेस देने या न देने का विकल्प होता है. सीआईडीआर नोटेशन के साथ आईपी मास्किंग के बारे में जानकारी लेख पढ़ें.
• नियमों की जांच करने का क्रम तय करें.
• मैच करने के सभी नियमों को दिए गए क्रम में लागू किया जाता है. जब कोई नियम मैच होता है, तो उससे जुड़ी कार्रवाई लागू हो जाती है. इसके बाद, मैच होने वाले नियमों को स्किप कर दिया जाता है.
  • अगर एक ही नियम को 'अनुमति दें' और 'अनुमति न दें' कार्रवाइयों के साथ कॉन्फ़िगर किया जाता है, तो क्रम में सबसे पहले तय किया गया नियम ट्रिगर होता है. इसके बाद, अन्य कार्रवाई वाले दूसरे नियम को छोड़ दिया जाता है.

नीति यह कैसे तय करती है कि किस आईपी पते का आकलन करना है

अनुरोध में आईपी पते अलग-अलग सोर्स से मिल सकते हैं. उदाहरण के लिए, True-Client-IP मैसेज हेडर में आईपी पता हो सकता है. साथ ही, X-Forwarded-For हेडर में एक या उससे ज़्यादा आईपी पते हो सकते हैं. इस सेक्शन में, AccessControl नीति को कॉन्फ़िगर करने का तरीका बताया गया है, ताकि यह उन आईपी पतों का आकलन कर सके जिनका आपको आकलन करना है.

ऐक्सेस कंट्रोल की नीति, यह तय करने के लिए इस लॉजिक का इस्तेमाल करती है कि किस आईपी पते का आकलन करना है:

1. True-Client-IP हेडर

यह नीति सबसे पहले True-Client-IP हेडर में आईपी पते की जांच करती है. अगर हेडर में मान्य आईपी पता मौजूद है, तो नीति उस पते का आकलन करती है.

2. X-Forwarded-For हेडर

अगर True-Client-IP हेडर मौजूद नहीं है या आपने <IgnoreTrueClientIPHeader> एलिमेंट को सही पर सेट किया है, तो नीति X-Forwarded-For हेडर में मौजूद आईपी पते का आकलन करती है.

Edge, X-Forwarded-For हेडर में अपने-आप वह आईपी पता भर देता है जो उसे आखिरी बाहरी टीसीपी हैंडशेक (जैसे कि क्लाइंट का आईपी या राउटर) से मिला था. अगर हेडर में एक से ज़्यादा आईपी पते हैं, तो हो सकता है कि ये पते उन सर्वर की चेन के हों जिन्होंने किसी अनुरोध को प्रोसेस किया है. हालांकि, पतों की सूची में स्पूफ़ किया गया आईपी पता भी शामिल हो सकता है. इसलिए, नीति को यह कैसे पता चलता है कि किन पतों का आकलन करना है?

आपके संगठन के कॉन्फ़िगरेशन और नीति के कॉन्फ़िगरेशन से यह तय होता है कि नीति किन X-Forwarded-For पतों का आकलन करती है.

सबसे पहले, यह देखें कि आपके संगठन के लिए feature.enableMultipleXForwardCheckForACL प्रॉपर्टी सेट की गई है या नहीं. इसकी जांच करने के लिए, Get organization एपीआई का इस्तेमाल किया जा सकता है. इसके बाद:

• अगर आपको अपनी कंपनी की प्रॉपर्टी की सूची में feature.enableMultipleXForwardCheckForACL नहीं दिखता है, तो इसका मतलब है कि उस प्रॉपर्टी के लिए false (डिफ़ॉल्ट) वैल्यू सेट की गई है. इस प्रॉपर्टी को false पर सेट करने पर, नीति हेडर में मौजूद आखिरी पते का आकलन करती है. यह पता ट्रेस टूल में दिखता है. यह आईपी पता है, जो Edge को आखिरी बाहरी टीसीपी हैंडशेक से मिला था.
• अगर आपके संगठन के लिए feature.enableMultipleXForwardCheckForACL की वैल्यू सही पर सेट है, तो <ValidateBasedOn> एलिमेंट को कॉन्फ़िगर करें. इससे यह तय किया जा सकेगा कि नीति किन आईपी पतों का आकलन करती है.

feature.enableMultipleXForwardCheckForACL प्रॉपर्टी बदलना

Edge संगठन के एडमिन, feature.enableMultipleXForwardCheckForACL प्रॉपर्टी सेट करने के लिए, संगठन की प्रॉपर्टी अपडेट करें एपीआई का इस्तेमाल कर सकते हैं.

यहां दिए गए एपीआई के उदाहरण में, Private Cloud के लिए Edge में प्रॉपर्टी सेट की गई है. अगर आपके संगठन के लिए अन्य प्रॉपर्टी सेट की गई हैं, तो उन्हें भी शामिल करना न भूलें. ऐसा न करने पर, उन्हें हटा दिया जाएगा.

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 for Private Cloud में, feature.enableMultipleXForwardCheckForACL प्रॉपर्टी की वैल्यू बदलने के बाद, आपको अपने मैसेज प्रोसेसर को फिर से चालू करना होगा. इसके बारे में अलग-अलग कॉम्पोनेंट को शुरू/बंद/फिर से शुरू करना लेख में बताया गया है.

Apigee Analytics में X-Forwarded-For डाइमेंशन

Edge Analytics, X-Forwarded-For हेडर की वैल्यू को x_forwarded_for_ip डाइमेंशन में लिखता है. जिस क्लाइंट आईपी ने Edge को अनुरोध भेजा है उसका पता लगाने के लिए, ax_true_client_ip या ax_resolved_client_ip डाइमेंशन में मौजूद वैल्यू का इस्तेमाल करें. ज़्यादा जानकारी के लिए, Analytics मेट्रिक, डाइमेंशन, और फ़िल्टर का रेफ़रंस देखें.

सीआईडीआर नोटेशन का इस्तेमाल करके आईपी पते को मास्क करने के बारे में जानकारी

सीआईडीआर नोटेशन (क्लासलैस इंटर-डोमेन रूटिंग), मास्किंग के ज़रिए आईपी पतों की रेंज दिखाने का एक तरीका है. यह IPv4 और IPv6, दोनों पर लागू होता है. यह इस तरह से काम करता है. हम अपने उदाहरणों में आईपीवी4 का इस्तेमाल करेंगे, ताकि इन्हें आसानी से समझा जा सके.

आईपी पते, संख्याओं के ऐसे ग्रुप होते हैं जिन्हें डॉट से अलग किया जाता है. बाइनरी के हिसाब से, हर ग्रुप में कुछ बिट होते हैं. IPv4 के लिए 8 और IPv6 के लिए 16 बिट होते हैं. IPv4 पता 198.51.100.1, बाइनरी में ऐसा दिखता है:

11000110.00110011.01100100.00000001

यह 8 बिट के चार ग्रुप या कुल 32 बिट होते हैं. सीआईडीआर की मदद से, आईपी पते में /number (1-32) जोड़कर रेंज दिखाई जा सकती है. जैसे:

198.51.100.1/24

इस मामले में, 24 वह संख्या है जिसका इस्तेमाल इस नीति में mask एट्रिब्यूट की वैल्यू के लिए किया जाएगा.

इस नोटेशन का मतलब है, "पहले 24 बिट को ठीक वैसा ही रखें जैसा वे हैं. बाकी बिट की वैल्यू 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 है:

इस उदाहरण में, कॉन्फ़िगरेशन को <SourceAddress mask="30">198.51.100.1</SourceAddress> पर सेट करने पर, इन आईपी पतों को अनुमति दी जाएगी (या आपके नियमों के आधार पर अनुमति नहीं दी जाएगी):

• 198.51.100.0
• 198.51.100.1
• 198.51.100.2
• 198.51.100.3

एलिमेंट का रेफ़रंस

तत्व के रेफ़रंस में, ऐक्सेस कंट्रोल की नीति के एलिमेंट और एट्रिब्यूट के बारे में बताया गया है.

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

यहां दी गई टेबल में, ऐसे एट्रिब्यूट के बारे में बताया गया है जो नीति के सभी पैरंट एलिमेंट में एक जैसे होते हैं:

&lt;DisplayName&gt; एलिमेंट

इस कॉलम में नीति को लेबल करने के लिए, name एट्रिब्यूट के साथ-साथ इस्तेमाल करें मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर, जिसका नाम अलग और सामान्य भाषा में है.

<DisplayName>Policy Display Name</DisplayName>

<IgnoreTrueClientIPHeader> एलिमेंट

इस नीति को 'सही है' पर सेट करने पर, यह True-Client-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> एलिमेंट

यह पैरंट एलिमेंट है. इसमें ऐसे नियम होते हैं जिनसे आईपी पतों को अनुमति दी जाती है या उन्हें अस्वीकार किया जाता है. noRuleMatchAction एट्रिब्यूट की मदद से, यह तय किया जा सकता है कि मैचिंग के नियमों के दायरे में न आने वाले आईपी पतों को कैसे हैंडल किया जाए.

<IPRules noRuleMatchAction = "ALLOW">

विशेषताएं

<IPRules>/<MatchRule> एलिमेंट

अगर आईपी पता, आपके तय किए गए 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> एलिमेंट

क्लाइंट के आईपी पते की रेंज.

मान्य वैल्यू: मान्य आईपी पता (डॉटेड डेसिमल नोटेशन). वाइल्डकार्ड बिहेवियर के लिए, 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 एट्रिब्यूट या आईपी पते के लिए मैसेज टेंप्लेट का भी इस्तेमाल किया जा सकता है. इसका मतलब है कि एपीआई प्रॉक्सी फ़्लो में फ़िलहाल उपलब्ध वैरिएबल का इस्तेमाल करके, वैल्यू सेट की जा सकती हैं.

उदाहरण के लिए, किसी आईपी पते को कुंजी वैल्यू मैप (केवीएम) में सेव किया जा सकता है. साथ ही, आईपी पते को वापस पाने और उसे किसी वैरिएबल (जैसे कि kvm.ip.value) को असाइन करने के लिए, KeyValueMapOperations नीति का इस्तेमाल किया जा सकता है. इसके बाद, उस वैरिएबल का इस्तेमाल आईपी पते के लिए किया जा सकता है:

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

वैरिएबल के साथ मास्क और/या आईपी पता सेट करने से, आपको एपीआई प्रॉक्सी में बदलाव किए बिना और उसे फिर से डिप्लॉय किए बिना, रनटाइम पर वैल्यू बदलने की सुविधा मिलती है.

विशेषताएं

<ValidateBasedOn> एलिमेंट

जब X-Forwarded-For एचटीटीपी हेडर में एक से ज़्यादा आईपी पते मौजूद हों, तब इस ValidateBasedOn एलिमेंट का इस्तेमाल करके यह कंट्रोल करें कि किन आईपी पतों का आकलन किया जाए.

आईपी पतों का आकलन करने के लिए, इस तरीके का इस्तेमाल सिर्फ़ तब करें, जब आपको उन आईपी पतों की वैधता के बारे में पक्का पता हो जिनका आपको आकलन करना है. उदाहरण के लिए, अगर आपको X-Forwarded-For हेडर में मौजूद सभी आईपी पतों का आकलन करना है, तो आपको उन पतों की वैधता पर भरोसा करना होगा. इसके अलावा, आपको DENY या ALLOW के नियमों का पूरा सेट अप करना होगा, ताकि सिर्फ़ भरोसेमंद आईपी पते आपकी एपीआई प्रॉक्सी को कॉल कर सकें.

हेडर में सबसे बाईं ओर मौजूद आईपी पता क्लाइंट का होता है. वहीं, सबसे दाईं ओर मौजूद आईपी पता उस सर्वर का होता है जिसने मौजूदा सेवा को अनुरोध भेजा है. सबसे दाईं ओर या आखिरी आईपी पता, वह पता होता है जो Edge को आखिरी बाहरी टीसीपी हैंडशेक से मिला था.

इस एलिमेंट में डाली गई वैल्यू से यह तय किया जा सकता है कि हेडर में मौजूद सभी आईपी पतों (डिफ़ॉल्ट), सिर्फ़ पहले आईपी पते या सिर्फ़ आखिरी आईपी पते की जांच करनी है या नहीं.

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

स्कीमा

नीति के हर टाइप को एक्सएमएल स्कीमा (.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>