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

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

Что

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

Хотя вы можете прикрепить эту политику в любом месте потока прокси-сервера API, вам, скорее всего, потребуется проверять IP-адреса в начале потока (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>

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

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

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

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

Как политика выбирает 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 будут оцениваться политикой.

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

• Если вы не видите 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 для частного облака после изменения значения свойства feature.enableMultipleXForwardCheckForACL необходимо перезапустить обработчики сообщений, как описано в разделе Запуск/остановка/перезапуск отдельных компонентов .

Измерения X-Forwarded-For в аналитике Apigee

Edge Analytics записывает значение заголовка X-Forwarded-For в измерение x_forwarded_for_ip . Чтобы определить IP-адрес клиента, отправившего запрос к Edge, используйте значения в измерениях ax_true_client_ip или ax_resolved_client_ip . Дополнительные сведения см . в справочнике по показателям, параметрам и фильтрам Google 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 , где последняя 1 — это 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-адрес соответствует заданному вами SourceAddress(ам).

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

Крайний левый 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.

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

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>