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

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

Что

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

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

Образцы

Значения маски в приведенных ниже примерах 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>

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

Помимо защиты ваших 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/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 необходимо перезапустить обработчики сообщений, как описано в разделе «Запуск/остановка/перезапуск отдельных компонентов» .

Измерения 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" 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>

<IgnoreTrueClientIPHeader> элемент

Если установить этот параметр в значение 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-адрес совпадает с указанным вами адресом источника (адресами).

<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-адрес (в десятичной записи с точками). Для использования символов подстановки используйте атрибут 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, чтобы разрешить вызов вашего API-прокси только с доверенных IP-адресов.

Самый левый IP-адрес в заголовке принадлежит клиенту, а самый правый — серверу, который перенаправил запрос текущему сервису. Самый правый, или последний, IP-адрес — это адрес, полученный Edge в результате последнего внешнего 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>

Схемы

Каждый тип политики определяется 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.info

Что

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

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

Образцы

Значения маски в приведенных ниже примерах 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>

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

Помимо защиты ваших 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/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 необходимо перезапустить обработчики сообщений, как описано в разделе «Запуск/остановка/перезапуск отдельных компонентов» .

Измерения 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" 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>

<IgnoreTrueClientIPHeader> элемент

Если установить этот параметр в значение 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-адрес совпадает с указанным вами адресом источника (адресами).

<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-адрес (в десятичной записи с точками). Для использования символов подстановки используйте атрибут 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, чтобы разрешить вызов вашего API-прокси только с доверенных IP-адресов.

Самый левый IP-адрес в заголовке принадлежит клиенту, а самый правый — серверу, который перенаправил запрос текущему сервису. Самый правый, или последний, IP-адрес — это адрес, полученный Edge в результате последнего внешнего 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>

Схемы

Каждый тип политики определяется 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>