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

Вы просматриваете документацию 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-адресу /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> , следующие 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.

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

В этом разделе описаны коды ошибок и сообщения об ошибках, которые возвращаются, а также переменные ошибок, которые устанавливаются 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>