Политика контроля доступа

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info

Что

Политика контроля доступа позволяет разрешать или запрещать доступ к вашим API для определенных IP-адресов.

Хотя вы можете прикрепить эту политику в любом месте потока API-прокси, скорее всего, вам потребуется проверять IP-адреса в начале потока (Запрос / Конечная точка прокси / Предварительный поток), даже до аутентификации или проверки квот.

Образцы

Значения маски в приведенных ниже примерах IPv4 определяют, какой из четырех октетов (8, 16, 24, 32 бит) правило соответствия учитывает при разрешении или запрете доступа. Значение по умолчанию — 32. Дополнительную информацию см. в описании атрибута mask в справочнике элементов.

<AccessControl name=">;AC<L"
  IPRules noRuleMatchAction> = &q<uot;ALLOW"
    Match>Rule ac<tion = "DENY">
      Sourc<eAddress mask=>"<;32"1>98.<51.100.1>/<SourceAddress
>    /MatchRule
  /IPRules
/AccessControl

<AccessControl name=">;AC<L"
  IPRules noRuleMatchAction> = &q<uot;ALLOW"
    Match>Rule ac<tion = "DENY"
      SourceA>ddress mask=&q<uot;{kvm.mask.>value<}"{kv>m.ip.<value}/S>o<urceAddress
  >  /MatchRule
    /IPRules
/AccessControl

<AccessControl name=">;AC<L"
  IPRules noRuleMatchAction> = &q<uot;ALLOW"
    Match>Rule ac<tion = "DENY">
      Sourc<eAddress mask=>"<;24"1>98.51<.100.1/S>o<urceAddress
  >  /MatchRule
    /IPRules
/AccessControl

<AccessControl name=">;AC<L"
  IPRules noRuleMatchAction> = &q<uot;ALLOW"
    Match>Rule act<ion = "DENY"
>       Sourc<eAddress mask=>"<;16"1>98.<51.100.1>/<SourceAddress
>    /MatchRule
  /IPRules
/AccessControl

<AccessControl name=">;AC<L"
  IPRules noRuleMatchAction> = &q<uot;ALLOW"
    MatchR>ule act<ion = "ALLOW">
      So<urceAddress ma>sk=&q<uot;32&quo>t;192<.0.2.1/SourceAddress
    >/MatchR<ule
    MatchRule actio>n = "DE<NY"
     > Sour<ceAddress >mas<k=">2<4"198.51.>100.1/SourceAddress
    /MatchRule
  /IPRules
/AccessControl

<AccessControl name=">;AC<L"
  IPRules noRuleMatchActio>n = &<quot;DENY"
    MatchR>ule act<ion = "ALLOW">
      Sourc<eAddress mask=>"<;16"1>98.<51.100.1>/<SourceAddress
>    /MatchRule
  /IPRules
/AccessControl

<AccessControl name=">;AC<L"
  IPRules noRuleMatchActio>n = &<quot;DENY"
    MatchR>ule act<ion = "ALLOW">
      Sourc<eAddress mask=>"2<4"198.51.100.1/Sou>rceAddres<s
      Source>Address< mask="24"192>.0.2.1/Sour<ceAddress
    >  Sour<ceAddress >mas<k=">2<4"203.0.1>13.1/SourceAddress
     /MatchRule
  /IPRules
/AccessControl

<AccessControl name=">;AC<L"
  IPRules noRuleMatchAction> = &q<uot;ALLOW"
    Match>Rule ac<tion = "DENY">
      Sourc<eAddress mask=>"2<4"198.51.100.1/Sou>rceAddres<s
      Source>Address< mask="24"192>.0.2.1/Sour<ceAddress
    >  Sou<rceAddress> ma<sk=">;<24"203.0.>113.1/SourceAddress
    /MatchRule
  /IPRules
/AccessControl

<AccessControl name=">;AC<L"
  IPRules noRuleMatchActio>n = &<quot;DENY"
    Match>Rule ac<tion = "DENY">
      Sourc<eAddress mask=>"2<4"198.51.100.1/Sou>rceAddres<s
      Source>Address< mask="24"192>.0.2.1/Sour<ceAddress
    >  Sou<rceAddress> mask<="24"203.0.113.1>/Source<Address
    /MatchRule
>    MatchRul<e action = &qu>ot;ALLO<W"
      SourceAdd>ress mask<="16">;198.51<.100.1/SourceAddress
  >    SourceA<ddress mask=&q>uot;1<6"192>.0.<2.1/Sour>c<eAddress
     > SourceAddress mask="16"203.0.113.1/SourceAddress
    /MatchRule
  /IPRules
/AccessControl

Примечания по использованию

Помимо защиты ваших API от вредоносных IP-адресов, политика контроля доступа также позволяет контролировать доступ по легитимным IP-адресам. Например, если вы хотите, чтобы доступ к API, предоставляемым в вашей тестовой среде, имели только компьютеры, находящиеся под управлением вашей организации, вы можете разрешить диапазон IP-адресов для вашей внутренней сети. Разработчики, работающие из дома, могут получить доступ к этим API, используя VPN.

Настройка и выполнение политики контроля доступа включает в себя следующее:

• Определите набор правил сопоставления , каждому из которых соответствует одно из двух действий (РАЗРЕШИТЬ или ЗАПРЕТИТЬ).
• Для каждого правила соответствия укажите IP-адрес (элемент SourceAddress).
  • См. раздел «Как политика выбирает, какой IP-адрес следует проверить , чтобы определить, какой IP-адрес (или адреса) в сообщении вы настраиваете для обработки».
  • Настройте маску для каждого IP-адреса. Вы разрешаете или запрещаете доступ на основе значения маски для IP-адреса. См. раздел «О маскировании IP-адресов с использованием нотации CIDR» .
• Укажите порядок проверки правил.
• Все правила соответствия выполняются в заданном порядке. При совпадении правила выполняется соответствующее действие, а следующие правила соответствия пропускаются.
  • Если одно и то же правило настроено с действиями ALLOW и DENY, срабатывает правило, определенное первым в порядке, а последующее правило (с другим действием) пропускается.

Как политика выбирает, какой IP-адрес следует проверить

IP-адреса могут поступать из различных источников в запросе. Например, заголовок сообщения True-Client-IP может содержать IP-адрес, а заголовок X-Forwarded-For один или несколько IP-адресов. В этом разделе описывается, как настроить политику AccessControl для оценки именно тех IP-адресов, которые вы хотите оценить.

Ниже приведена логика, которую использует политика AccessControl для определения того, какой IP-адрес следует проверить:

1. Заголовок True-Client-IP

Сначала политика проверяет наличие IP-адреса в заголовке True-Client-IP . Если заголовок содержит действительный IP-адрес, политика оценивает этот адрес.

2. Заголовок X-Forwarded-For

Если заголовок True-Client-IP отсутствует или если вы установили элемент <IgnoreTrueClientIPHeader> в значение true, политика оценивает IP-адрес(а) в заголовке X-Forwarded-For .

Edge автоматически заполняет заголовок X-Forwarded-For IP-адресом, полученным в результате последнего внешнего TCP-рукопожатия (например, IP-адресом клиента или маршрутизатора). Если в заголовке несколько IP-адресов, то, скорее всего, это адреса цепочек серверов, обработавших запрос. Однако список адресов также может содержать поддельный IP-адрес. Так как же политика определяет, какие адреса следует проверять?

Конфигурация вашей организации и конфигурация политики определяют, какие адреса, X-Forwarded-For For), будут оцениваться.

Сначала проверьте, задано ли свойство feature.enableMultipleXForwardCheckForACL для вашей организации. Для этого можно использовать API Get organization . Затем:

• Если вы не видите параметр feature.enableMultipleXForwardCheckForACL в списке свойств вашей организации, это означает, что для этого параметра установлено значение false (по умолчанию). При установке этого параметра в значение false политика оценивает последний адрес в заголовке (видимый в инструменте трассировки ), который представляет собой IP-адрес, полученный Edge в результате последнего внешнего TCP-рукопожатия.
• Если для параметра feature.enableMultipleXForwardCheckForACL в вашей организации установлено значение true, настройте элемент <ValidateBasedOn> , чтобы определить, какие IP-адреса будут оцениваться политикой.

Изменение свойства feature.enableMultipleXForwardCheckForACL

Администраторы пограничных организаций могут использовать API обновления свойств организации для установки свойства feature.enableMultipleXForwardCheckForACL .

В приведенном ниже примере API задается свойство в Edge для частного облака. Если в вашей организации заданы и другие свойства, обязательно укажите и их. В противном случае они будут удалены .

curl -u email:password -X POST -H "Content-type:application/xml" http://host:8080/v1/o/my<org -d \
"Organization type="trial&qu>ot; n<ame="M>yOrganization&<quot;
    Di>splay<NameMyOrga>nization/<DisplayName
    Properties
        Property name="fe>atur<e.enableM>ultipleXF<orwardCheckForACL"true/Property
        !-- >Inclu<de other ex>i<sting propert>ies as well. --
    /Properties
/Organization"

В Edge for Private Cloud после изменения значения свойства feature.enableMultipleXForwardCheckForACL необходимо перезапустить обработчики сообщений, как описано в разделе «Запуск/остановка/перезапуск отдельных компонентов» .

Измерения X-Forwarded-For в Apigee Analytics

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-адреса представляют собой группы чисел, разделённые точками. В двоичной системе каждая группа соответствует определённому количеству битов (8 для IPv4 и 16 для IPv6). IPv4-адрес 198.51.100.1 в двоичном виде выглядит так:

11000110.00110011.01100100.00000001

Это 4 группы по 8 бит, или всего 32 бита. В CIDR диапазон можно указать, добавив к IP-адресу /число (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 , где последняя единица в двоичном представлении равна 00000001:

В этом примере, при настройке конфигурации на <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

Ссылка на элемент

В справочном разделе по элементам описываются элементы и атрибуты политики контроля доступа.

<?xml version="1.0" encoding="UTF-8&quo>t<; standalone="yes"?
AccessControl async="false" continueOnError=">false<" enab>led="true&q<uot; name=&q>uot;A<ccess-Control-1"
    DisplayNa>meAccess <Control 1/DisplayName
    >IPRules noRul<eMatchAction = "AL>LOW"
  <      MatchRul>e action <= "AL>LOW"<
            SourceAddres>s mask="<32"198.51.100.1/So>urceAddress
<        /Match>Rule
    <    MatchR>ule a<ction = >"<;DENY"
   >         SourceAddress< mask="24&q>u<ot;198.51.100.>1/SourceAddress
        /MatchRule
    /IPRules
    ValidateBasedOnX_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>

<IgnoreTrueClientIPHeader> элемент

Если установить этот параметр в значение true, политика будет игнорировать заголовок True-Client-IP и оценивать IP-адреса в заголовке X-Forwarded-For в соответствии с настроенным вами поведением оценки X-Forwarded-For .

<AccessControl async="false" continueOnError="false" enabled="true>"<; name=&quo>t;Access-Control<-1"
   > Disp<layNameAccess Control-1/>Disp<layName
    IgnoreTrueCli>entIPHead<ertrue/IgnoreT>rueClientIPHeader
    ...
/AccessControl

<IPRules> элемент

Родительский элемент, содержащий правила, разрешающие или запрещающие использование IP-адресов. Атрибут noRuleMatchAction позволяет определить, как обрабатывать любые IP-адреса, не охваченные вашими правилами соответствия.

<IPRules noRuleMatchAction = "A>LLOW"

Атрибуты

<IPRules>/<MatchRule> элемент

Действие, которое необходимо выполнить (разрешить или запретить доступ), если IP-адрес совпадает с указанным вами адресом источника (адресами).

<IPRules noRuleMatchAction = "A>LLOW&<quot;
    MatchRule action> = "<ALLOW"
        Sou>rceAddress m<ask="32&q>uot;1<98.51.100.>1/Sou<rceAddress
    /MatchRule>
    Matc<hRule action = "DE>NY"
   <     SourceAdd>ress <mask=">;<24">198.51.100.1/SourceAddress
    /MatchRule
/IPRules

Атрибуты

элемент <IPRules>/<MatchRule>/<SourceAddress>

Диапазон IP-адресов клиента.

Допустимое значение: Действительный IP-адрес (в десятичной записи с точками). Для использования символов подстановки используйте атрибут mask .

<IPRules noRuleMatchAction = "A>LLOW&<quot;
    MatchRule action> = "<ALLOW"
        SourceAddre>ss mask=&quo<t;{variable}&q>uot;1<98.51.100.>1/Sou<rceAddress
    /MatchRule>
    Matc<hRule action = "DE>NY"</span>
 <       SourceA>ddres<s mask=&qu>o<t;24&quo>t;{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, чтобы разрешить вызов вашего API-прокси только с доверенных IP-адресов.

Самый левый IP-адрес в заголовке принадлежит клиенту, а самый правый — серверу, который перенаправил запрос текущему сервису. Самый правый, или последний, IP-адрес — это адрес, полученный Edge в результате последнего внешнего TCP-рукопожатия.

Значение, которое вы вводите в этот элемент, позволяет определить, следует ли проверять все IP-адреса в заголовке (по умолчанию), только первый IP-адрес или только последний IP-адрес.

<AccessControl async="false" continueOnError="false" enabled="true>"<; name=&quo>t;Access-Control<-1"
   > Disp<layNameAccess Control 1/DisplayName>
    IPRu<les noRuleMatchAction = &>quot;ALLOW&qu<ot;
        MatchRule a>ction = &quo<t;DENY"
 >         <  SourceAd>dress< mask=&q>uot;3<2"198.51.1>00.1/SourceAddress
   <     /MatchRule
> <   /IPRules
  >  ValidateBasedOnX_FORWARDED_FOR_ALL_IP/ValidateBasedOn
/AccessControl

Схемы

Каждый тип политики определяется XML-схемой (.xsd). Для справки, схемы политик доступны на GitHub.

Ссылка на ошибку

This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Runtime errors

These errors can occur when the policy executes.

Fault variables

These variables are set when a runtime error occurs. For more information, see Variables specific to policy errors.

Example fault response

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

Example fault rule

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

Что

Политика контроля доступа позволяет разрешать или запрещать доступ к вашим API для определенных IP-адресов.

Хотя вы можете прикрепить эту политику в любом месте потока API-прокси, скорее всего, вам потребуется проверять IP-адреса в начале потока (Запрос / Конечная точка прокси / Предварительный поток), даже до аутентификации или проверки квот.

Образцы

Значения маски в приведенных ниже примерах IPv4 определяют, какой из четырех октетов (8, 16, 24, 32 бит) правило соответствия учитывает при разрешении или запрете доступа. Значение по умолчанию — 32. Дополнительную информацию см. в описании атрибута mask в справочнике элементов.

<AccessControl name=">;AC<L"
  IPRules noRuleMatchAction> = &q<uot;ALLOW"
    Match>Rule ac<tion = "DENY">
      Sourc<eAddress mask=>"<;32"1>98.<51.100.1>/<SourceAddress
>    /MatchRule
  /IPRules
/AccessControl

<AccessControl name=">;AC<L"
  IPRules noRuleMatchAction> = &q<uot;ALLOW"
    Match>Rule ac<tion = "DENY"
      SourceA>ddress mask=&q<uot;{kvm.mask.>value<}"{kv>m.ip.<value}/S>o<urceAddress
  >  /MatchRule
    /IPRules
/AccessControl

<AccessControl name=">;AC<L"
  IPRules noRuleMatchAction> = &q<uot;ALLOW"
    Match>Rule ac<tion = "DENY">
      Sourc<eAddress mask=>"<;24"1>98.51<.100.1/S>o<urceAddress
  >  /MatchRule
    /IPRules
/AccessControl

<AccessControl name=">;AC<L"
  IPRules noRuleMatchAction> = &q<uot;ALLOW"
    Match>Rule act<ion = "DENY"
>       Sourc<eAddress mask=>"<;16"1>98.<51.100.1>/<SourceAddress
>    /MatchRule
  /IPRules
/AccessControl

<AccessControl name=">;AC<L"
  IPRules noRuleMatchAction> = &q<uot;ALLOW"
    MatchR>ule act<ion = "ALLOW">
      So<urceAddress ma>sk=&q<uot;32&quo>t;192<.0.2.1/SourceAddress
    >/MatchR<ule
    MatchRule actio>n = "DE<NY"
     > Sour<ceAddress >mas<k=">2<4"198.51.>100.1/SourceAddress
    /MatchRule
  /IPRules
/AccessControl

<AccessControl name=">;AC<L"
  IPRules noRuleMatchActio>n = &<quot;DENY"
    MatchR>ule act<ion = "ALLOW">
      Sourc<eAddress mask=>"<;16"1>98.<51.100.1>/<SourceAddress
>    /MatchRule
  /IPRules
/AccessControl

<AccessControl name=">;AC<L"
  IPRules noRuleMatchActio>n = &<quot;DENY"
    MatchR>ule act<ion = "ALLOW">
      Sourc<eAddress mask=>"2<4"198.51.100.1/Sou>rceAddres<s
      Source>Address< mask="24"192>.0.2.1/Sour<ceAddress
    >  Sour<ceAddress >mas<k=">2<4"203.0.1>13.1/SourceAddress
     /MatchRule
  /IPRules
/AccessControl

<AccessControl name=">;AC<L"
  IPRules noRuleMatchAction> = &q<uot;ALLOW"
    Match>Rule ac<tion = "DENY">
      Sourc<eAddress mask=>"2<4"198.51.100.1/Sou>rceAddres<s
      Source>Address< mask="24"192>.0.2.1/Sour<ceAddress
    >  Sou<rceAddress> ma<sk=">;<24"203.0.>113.1/SourceAddress
    /MatchRule
  /IPRules
/AccessControl

<AccessControl name=">;AC<L"
  IPRules noRuleMatchActio>n = &<quot;DENY"
    Match>Rule ac<tion = "DENY">
      Sourc<eAddress mask=>"2<4"198.51.100.1/Sou>rceAddres<s
      Source>Address< mask="24"192>.0.2.1/Sour<ceAddress
    >  Sou<rceAddress> mask<="24"203.0.113.1>/Source<Address
    /MatchRule
>    MatchRul<e action = &qu>ot;ALLO<W"
      SourceAdd>ress mask<="16">;198.51<.100.1/SourceAddress
  >    SourceA<ddress mask=&q>uot;1<6"192>.0.<2.1/Sour>c<eAddress
     > SourceAddress mask="16"203.0.113.1/SourceAddress
    /MatchRule
  /IPRules
/AccessControl

Примечания по использованию

Помимо защиты ваших API от вредоносных IP-адресов, политика контроля доступа также позволяет контролировать доступ по легитимным IP-адресам. Например, если вы хотите, чтобы доступ к API, предоставляемым в вашей тестовой среде, имели только компьютеры, находящиеся под управлением вашей организации, вы можете разрешить диапазон IP-адресов для вашей внутренней сети. Разработчики, работающие из дома, могут получить доступ к этим API, используя VPN.

Настройка и выполнение политики контроля доступа включает в себя следующее:

• Определите набор правил сопоставления , каждому из которых соответствует одно из двух действий (РАЗРЕШИТЬ или ЗАПРЕТИТЬ).
• Для каждого правила соответствия укажите IP-адрес (элемент SourceAddress).
  • См. раздел «Как политика выбирает, какой IP-адрес следует проверить , чтобы определить, какой IP-адрес (или адреса) в сообщении вы настраиваете для обработки».
  • Настройте маску для каждого IP-адреса. Вы разрешаете или запрещаете доступ на основе значения маски для IP-адреса. См. раздел «О маскировании IP-адресов с использованием нотации CIDR» .
• Укажите порядок проверки правил.
• Все правила соответствия выполняются в заданном порядке. При совпадении правила выполняется соответствующее действие, а следующие правила соответствия пропускаются.
  • Если одно и то же правило настроено с действиями ALLOW и DENY, срабатывает правило, определенное первым в порядке, а последующее правило (с другим действием) пропускается.

Как политика выбирает, какой IP-адрес следует проверить

IP-адреса могут поступать из различных источников в запросе. Например, заголовок сообщения True-Client-IP может содержать IP-адрес, а заголовок X-Forwarded-For один или несколько IP-адресов. В этом разделе описывается, как настроить политику AccessControl для оценки именно тех IP-адресов, которые вы хотите оценить.

Ниже приведена логика, которую использует политика AccessControl для определения того, какой IP-адрес следует проверить:

1. Заголовок True-Client-IP

Сначала политика проверяет наличие IP-адреса в заголовке True-Client-IP . Если заголовок содержит действительный IP-адрес, политика оценивает этот адрес.

2. Заголовок X-Forwarded-For

Если заголовок True-Client-IP отсутствует или если вы установили элемент <IgnoreTrueClientIPHeader> в значение true, политика оценивает IP-адрес(а) в заголовке X-Forwarded-For .

Edge автоматически заполняет заголовок X-Forwarded-For IP-адресом, полученным в результате последнего внешнего TCP-рукопожатия (например, IP-адресом клиента или маршрутизатора). Если в заголовке несколько IP-адресов, то, скорее всего, это адреса цепочек серверов, обработавших запрос. Однако список адресов также может содержать поддельный IP-адрес. Так как же политика определяет, какие адреса следует проверять?

Конфигурация вашей организации и конфигурация политики определяют, какие адреса, X-Forwarded-For For), будут оцениваться.

Сначала проверьте, задано ли свойство feature.enableMultipleXForwardCheckForACL для вашей организации. Для этого можно использовать API Get organization . Затем:

• Если вы не видите параметр feature.enableMultipleXForwardCheckForACL в списке свойств вашей организации, это означает, что для этого параметра установлено значение false (по умолчанию). При установке этого параметра в значение false политика оценивает последний адрес в заголовке (видимый в инструменте трассировки ), который представляет собой IP-адрес, полученный Edge в результате последнего внешнего TCP-рукопожатия.
• Если для параметра feature.enableMultipleXForwardCheckForACL в вашей организации установлено значение true, настройте элемент <ValidateBasedOn> , чтобы определить, какие IP-адреса будут оцениваться политикой.

Изменение свойства feature.enableMultipleXForwardCheckForACL

Администраторы пограничных организаций могут использовать API обновления свойств организации для установки свойства feature.enableMultipleXForwardCheckForACL .

В приведенном ниже примере API задается свойство в Edge для частного облака. Если в вашей организации заданы и другие свойства, обязательно укажите и их. В противном случае они будут удалены .

curl -u email:password -X POST -H "Content-type:application/xml" http://host:8080/v1/o/my<org -d \
"Organization type="trial&qu>ot; n<ame="M>yOrganization&<quot;
    Di>splay<NameMyOrga>nization/<DisplayName
    Properties
        Property name="fe>atur<e.enableM>ultipleXF<orwardCheckForACL"true/Property
        !-- >Inclu<de other ex>i<sting propert>ies as well. --
    /Properties
/Organization"

В Edge for Private Cloud после изменения значения свойства feature.enableMultipleXForwardCheckForACL необходимо перезапустить обработчики сообщений, как описано в разделе «Запуск/остановка/перезапуск отдельных компонентов» .

Измерения X-Forwarded-For в Apigee Analytics

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-адреса представляют собой группы чисел, разделённые точками. В двоичной системе каждая группа соответствует определённому количеству битов (8 для IPv4 и 16 для IPv6). IPv4-адрес 198.51.100.1 в двоичном виде выглядит так:

11000110.00110011.01100100.00000001

Это 4 группы по 8 бит, или всего 32 бита. В CIDR диапазон можно указать, добавив к IP-адресу /число (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 , где последняя единица в двоичном представлении равна 00000001:

В этом примере, при настройке конфигурации на <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

Ссылка на элемент

В справочном разделе по элементам описываются элементы и атрибуты политики контроля доступа.

<?xml version="1.0" encoding="UTF-8&quo>t<; standalone="yes"?
AccessControl async="false" continueOnError=">false<" enab>led="true&q<uot; name=&q>uot;A<ccess-Control-1"
    DisplayNa>meAccess <Control 1/DisplayName
    >IPRules noRul<eMatchAction = "AL>LOW"
  <      MatchRul>e action <= "AL>LOW"<
            SourceAddres>s mask="<32"198.51.100.1/So>urceAddress
<        /Match>Rule
    <    MatchR>ule a<ction = >"<;DENY"
   >         SourceAddress< mask="24&q>u<ot;198.51.100.>1/SourceAddress
        /MatchRule
    /IPRules
    ValidateBasedOnX_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>

<IgnoreTrueClientIPHeader> элемент

Если установить этот параметр в значение true, политика будет игнорировать заголовок True-Client-IP и оценивать IP-адреса в заголовке X-Forwarded-For в соответствии с настроенным вами поведением оценки X-Forwarded-For .

<AccessControl async="false" continueOnError="false" enabled="true>"<; name=&quo>t;Access-Control<-1"
   > Disp<layNameAccess Control-1/>Disp<layName
    IgnoreTrueCli>entIPHead<ertrue/IgnoreT>rueClientIPHeader
    ...
/AccessControl

<IPRules> элемент

Родительский элемент, содержащий правила, разрешающие или запрещающие использование IP-адресов. Атрибут noRuleMatchAction позволяет определить, как обрабатывать любые IP-адреса, не охваченные вашими правилами соответствия.

<IPRules noRuleMatchAction = "A>LLOW"

Атрибуты

<IPRules>/<MatchRule> элемент

Действие, которое необходимо выполнить (разрешить или запретить доступ), если IP-адрес совпадает с указанным вами адресом источника (адресами).

<IPRules noRuleMatchAction = "A>LLOW&<quot;
    MatchRule action> = "<ALLOW"
        Sou>rceAddress m<ask="32&q>uot;1<98.51.100.>1/Sou<rceAddress
    /MatchRule>
    Matc<hRule action = "DE>NY"
   <     SourceAdd>ress <mask=">;<24">198.51.100.1/SourceAddress
    /MatchRule
/IPRules

Атрибуты

элемент <IPRules>/<MatchRule>/<SourceAddress>

Диапазон IP-адресов клиента.

Допустимое значение: Действительный IP-адрес (в десятичной записи с точками). Для использования символов подстановки используйте атрибут mask .

<IPRules noRuleMatchAction = "A>LLOW&<quot;
    MatchRule action> = "<ALLOW"
        SourceAddre>ss mask=&quo<t;{variable}&q>uot;1<98.51.100.>1/Sou<rceAddress
    /MatchRule>
    Matc<hRule action = "DE>NY"</span>
 <       SourceA>ddres<s mask=&qu>o<t;24&quo>t;{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, чтобы разрешить вызов вашего API-прокси только с доверенных IP-адресов.

Самый левый IP-адрес в заголовке принадлежит клиенту, а самый правый — серверу, который перенаправил запрос текущему сервису. Самый правый, или последний, IP-адрес — это адрес, полученный Edge в результате последнего внешнего TCP-рукопожатия.

Значение, которое вы вводите в этот элемент, позволяет определить, следует ли проверять все IP-адреса в заголовке (по умолчанию), только первый IP-адрес или только последний IP-адрес.

<AccessControl async="false" continueOnError="false" enabled="true>"<; name=&quo>t;Access-Control<-1"
   > Disp<layNameAccess Control 1/DisplayName>
    IPRu<les noRuleMatchAction = &>quot;ALLOW&qu<ot;
        MatchRule a>ction = &quo<t;DENY"
 >         <  SourceAd>dress< mask=&q>uot;3<2"198.51.1>00.1/SourceAddress
   <     /MatchRule
> <   /IPRules
  >  ValidateBasedOnX_FORWARDED_FOR_ALL_IP/ValidateBasedOn
/AccessControl

Схемы

Каждый тип политики определяется XML-схемой (.xsd). Для справки, схемы политик доступны на GitHub.

Ссылка на ошибку

This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Runtime errors

These errors can occur when the policy executes.

Fault variables

These variables are set when a runtime error occurs. For more information, see Variables specific to policy errors.

Example fault response

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

Example fault rule

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