Política AccessControl

Estás viendo la documentación de Apigee Edge.
Ve a la Documentación de Apigee X. información

Qué

La política de control de acceso permite o rechaza el acceso a tus APIs a través de IP direcciones IP del proveedor.

Si bien puedes adjuntar esta política en cualquier lugar del flujo de proxy de API, es probable que quieras verificar las direcciones IP al comienzo del flujo (solicitud/ProxyEndpoint/PreFlow), incluso antes de la autenticación o la verificación de cuotas.

Muestras

Los valores de la máscara en las siguientes muestras de IPv4 identifican cuáles de los cuatro octetos (8, 16, 24, 32 bits) considera la regla de coincidencia cuando permite o rechaza el acceso. El valor predeterminado es 32. Consulta el atributo mask en la referencia de elemento para obtener más información.

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

Notas de uso

Además de proteger tus APIs contra IP maliciosas, la política de control de acceso también te permite controlar el acceso legítimo de IP. Por ejemplo, si solo quieres que las computadoras bajo el control de tu empresa accedan a las API expuestas en tu entorno de pruebas, puedes permitir el rango de direcciones IP para la red interna. Los desarrolladores que trabajan desde casa pueden acceder a estas API mediante VPN.

La configuración y la ejecución de una política de control de acceso implica lo siguiente:

• Define un conjunto de reglas de coincidencia con una de dos acciones (PERMITIR o RECHAZAR) asociadas con cada una.
• Para cada regla de coincidencia, especifica la dirección IP (elemento SourceAddress).
  • Consulta Cómo la política elige qué dirección IP evaluar a fin de determinar para qué direcciones IP configurar reglas en el mensaje.
  • Configure una máscara para cada dirección IP. Permite o rechaza el acceso en función de un valor de máscara en la dirección IP. Consulta Información acerca del enmascaramiento de IP con la notación de CIDR.
• Especifica el orden en el que se prueban las reglas.
• Todas las reglas de coincidencia se ejecutan en el orden especificado. Cuando una regla coincide, se ejecuta la acción correspondiente y se omiten las siguientes reglas de coincidencia.
  • Si la misma regla se configura con acciones PERMITIR y RECHAZAR, la regla que se define primero en el orden se activa y se omite la regla posterior (con la otra acción).

Cómo elige la política qué direcciones IP se evaluarán

Las direcciones IP pueden provenir de varias fuentes en una solicitud. Por ejemplo, el encabezado del mensaje True-Client-IP puede contener una dirección IP, y el encabezado X-Forwarded-For puede contener una o más direcciones IP. En esta sección, se describe cómo configurar la política AccessControl para evaluar las direcciones IP exactas que deseas evaluar.

A continuación, se muestra la lógica que usa la política de AccessControl para decidir qué dirección IP evaluar:

1. Encabezado True-Client-IP

La política primero verifica si hay una dirección IP en el encabezado True-Client-IP. Si el encabezado contiene una dirección IP válida, la política la evalúa.

2. Encabezado X-Forwarded-For

Si no hay encabezado True-Client-IP o si configuró el elemento <IgnoreTrueClientIPHeader> verdadero, la política evalúa las direcciones IP en el X-Forwarded-For.

Edge propaga automáticamente el encabezado X-Forwarded-For. con la dirección IP que recibió del último protocolo de enlace TCP externo (como la IP de cliente o router). Si existen varias direcciones IP en el encabezado, es probable que esas direcciones sean la cadena de servidores que procesaron una solicitud. Sin embargo, la lista de direcciones también puede contener una dirección IP de falsificación de identidad. ¿Cómo sabe la política qué direcciones debe evaluar?

La configuración de tu organización y la de políticas determinan qué X-Forwarded-For direcciones que evalúa la política.

Primero, comprueba si la propiedad feature.enableMultipleXForwardCheckForACL que esté establecida en tu organización. Puedes usar la Obtén la API de la organización para comprobarlo. Luego:

• Si no ves feature.enableMultipleXForwardCheckForACL en la lista de propiedades de tu organización, significa que la propiedad se configura como falsa (el valor predeterminado). Si estableces esta propiedad como falsa, la política evaluará last del encabezado (visible en Herramienta de seguimiento), que es la dirección IP Edge recibido del último protocolo de enlace TCP externo.
• Si el feature.enableMultipleXForwardCheckForACL de tu organización se establece como verdadero, configura el elemento <ValidateBasedOn> para determinar qué direcciones IP evalúa la política.

Cambia la propiedad feature.enableMultipleXForwardCheckForACL

Los administradores de la organización de Edge pueden usar el Actualiza la API de propiedades de la organización para establecer la propiedad feature.enableMultipleXForwardCheckForACL.

En el siguiente ejemplo de la API, se configura la propiedad en Edge para la nube privada. Si hay otras propiedades establecidas en tu organización, asegúrate de incluirlas también. De lo contrario, se quitarán.

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

En Edge for Private Cloud, después de cambiar el valor del propiedad feature.enableMultipleXForwardCheckForACL, debes reiniciar los procesadores de mensajes, tal como se describe en Inicia, detén o reinicia componentes individuales.

Dimensiones X-Forwarded-For en las estadísticas de Apigee

Edge Analytics escribe el valor del encabezado X-Forwarded-For en Dimensión x_forwarded_for_ip. Para determinar la IP de cliente que hizo la solicitud a Edge, usa los valores de ax_true_client_ip o ax_resolved_client_ip dimensiones Consulta Las métricas, las dimensiones y filtros para obtener más información.

Información acerca del enmascaramiento de IP con la notación de CIDR

La notación CIDR (enrutamiento entre dominios sin clases) es una forma de indicar un rango de direcciones IP a través del enmascaramiento. Se aplica a IPv4 y .IPv6 Así es cómo funciona. Usaremos IPv4 en nuestros ejemplos para simplificar.

Las direcciones IP son grupos de números separados por puntos. En términos binarios, cada grupo es una cantidad específica de bits (8 para IPv4 y 16 para IPv6). La dirección IPv4 198.51.100.1 se ve de esta manera en el objeto binario:

11000110.00110011.01100100.00000001

Son 4 grupos de 8 bits o 32 bits en total. Con CIDR, puedes indicar un rango si agregas un /number (1-32) a la dirección IP, de la siguiente manera:

198.51.100.1/24

En este caso, el valor 24 es el número que se usa para el valor del atributo mask en esta política.

Esta notación significa “mantiene los primeros 24 bits exactamente como están, los bits restantes pueden ser cualquier valor entre 0 y 255”. Por ejemplo:

Observa que la máscara ocurre al final del grupo tres. Esto hace que todo sea agradable y ordenado, en esencia mediante la creación de una máscara como esta: 198.51.100.* En la mayoría de los casos, el uso de múltiplos de 8 (IPv4) y de 16 (IPv6) te brindará el nivel de enmascaramiento que deseas:

IPv4: 8, 16, 24, 32

IPv6: 16, 32, 48, 64, 80, 96, 112, 128

Sin embargo, puedes usar otros números para un control más detallado, lo que implica un pequeño cálculo del objeto binario. A continuación, puedes ver un ejemplo con una máscara de 30, como en 198.51.100.1/30, en la que el último 1 es 00000001 en el objeto binario:

En este ejemplo, con la configuración establecida en <SourceAddress mask="30">198.51.100.1</SourceAddress>, se permitirán (o se rechazarán según tus reglas) las siguientes IP:

• 198.51.100.0
• 198.51.100.1
• 198.51.100.2
• 198.51.100.3

Referencia de elementos

La referencia de los elementos describe los elementos y atributos de la política de control de acceso.

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

Atributos <AccessControl>

<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1"> 

En la siguiente tabla, se describen los atributos que son comunes a todos los elementos principales de las políticas:

Elemento <DisplayName>

Se usan además del atributo name para etiquetar la política en el editor de proxy de la IU de administración con un nombre de lenguaje natural diferente.

<DisplayName>Policy Display Name</DisplayName>

Elemento <IgnoreTrueClientIPHeader>

Cuando se establece esto como verdadero, la política ignora el encabezado True-Client-IP y evalúa las direcciones IP en el encabezado X-Forwarded-For, con el comportamiento de evaluación X-Forwarded-For que hayas configurado.

<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1">
    <DisplayName>Access Control-1</DisplayName>
    <IgnoreTrueClientIPHeader>true</IgnoreTrueClientIPHeader>
    ...
</AccessControl>

Elemento <IPRules>

El elemento superior que contiene las reglas que permiten o rechazan las direcciones IP. El atributo noRuleMatchAction te permite definir cómo manejar cualquier dirección IP que tus reglas coincidentes no cubran.

<IPRules noRuleMatchAction = "ALLOW">

Atributos

Elemento <IPRules>/<MatchRule>

La acción que se debe tomar (permitir o denegar el acceso) si la dirección IP coincide con las SourceAddress que defines.

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

Atributos

Elemento <IPRules>/<MatchRule>/<SourceAddress>

El rango de direcciones IP de un cliente.

Valor válido: Dirección IP válida (notación decimal con puntos). Para el comportamiento comodín, usa el atributo 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>

Como se muestra en el ejemplo anterior, el elemento SourceAddress también admite plantillas de mensajes para el atributo mask o la dirección IP, lo que significa que puedes establecer los valores que usan variables que están disponibles actualmente en el flujo del proxy de API.

Por ejemplo, puedes almacenar una dirección IP en un mapa de valor clave (KVM) y usar la política KeyValueMapOperations para recuperar la dirección IP y asignarla a una variable (como kvm.ip.value). Luego, podrás usar esa variable para la dirección IP:

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

Configura la máscara o la dirección IP con una variable te brinda la flexibilidad para cambiar los valores en el entorno de ejecución sin tener que modificar y volver a implementar el proxy de API

Atributos

Elemento <ValidateBasedOn>

Cuando el encabezado HTTP X-Forwarded-For contiene varias direcciones IP, usa este elemento ValidateBasedOn para controlar qué direcciones IP se evalúan.

Usa este enfoque para evaluar una dirección IP solo si estás seguro de la validez de las direcciones IP que deseas evaluar. Por ejemplo, si eliges evaluar todas las direcciones IP en el encabezado X-Forwarded-For, debes poder confiar en la validez de esas direcciones o configurar las reglas DENY o ALLOW para permitir que solo las IP de confianza llaman al proxy de API.

La dirección IP que se encuentra más a la izquierda del encabezado pertenece al cliente, y la que está más a la derecha es el servidor que reenvió la solicitud al servicio actual. La última dirección IP, es la dirección que Edge recibió del último protocolo de enlace TCP externo.

El valor que ingreses en este elemento te permite determinar si se deben verificar todas las direcciones IP en el encabezado (predeterminado), solo la primera dirección IP o solo la última dirección 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>

Esquemas

Un esquema XML (.xsd) define cada tipo de política. Como referencia, los esquemas de políticas están disponibles en GitHub.

Referencia de errores

En esta sección, se describen los códigos y mensajes de error que se muestran, y las variables de error que establece Edge cuando esta política activa un error. Esta información es importante para saber si estás desarrollando reglas de fallas con el propósito de manejar fallas. Para obtener más información, consulta Qué debes saber sobre los errores de políticas y Cómo solucionar fallas.

Errores de entorno de ejecución

Estos errores pueden producirse cuando se ejecuta la política.

Variables con fallas

Estas variables se configuran cuando se genera un error de entorno de ejecución. Para obtener más información, consulta Variables específicas de los errores de política.

Ejemplo de respuesta de falla

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

Ejemplo de regla de falla

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