Criterio AccessControl

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Cosa

La policy di controllo dell'accesso ti consente di consentire o negare l'accesso alle tue API in base a indirizzi IP specifici.

Anche se puoi collegare questa policy in qualsiasi punto del flusso del proxy API, è più probabile che tu voglia controllare gli indirizzi IP all'inizio del flusso ( Request / ProxyEndpoint / PreFlow), prima ancora dell'autenticazione o del controllo della quota.

Esempi

I valori della maschera nei seguenti esempi IPv4 identificano quale dei quattro ottetti (8, 16, 24, 32 bit) viene preso in considerazione dalla regola di corrispondenza quando consente o nega l'accesso. Il valore predefinito è 32. Per ulteriori informazioni, consulta l'attributo mask nel riferimento agli elementi.

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

Note sull'utilizzo

Oltre a proteggere le API da IP dannosi, la policy Controllo dell'accesso ti consente anche di controllare l'accesso IP legittimo. Ad esempio, se vuoi che solo i computer sotto il controllo della tua azienda accedano alle API esposte nel tuo ambiente di test, puoi consentire l'intervallo di indirizzi IP per la tua rete interna. Gli sviluppatori che lavorano da casa possono accedere a queste API utilizzando la VPN.

La configurazione e l'esecuzione di un criterio di controllo dell'accesso prevede quanto segue:

• Definisci un insieme di regole di corrispondenza con una delle due azioni (ALLOW o DENY) associate a ciascuna.
• Per ogni regola di corrispondenza, specifica l'indirizzo IP (elemento SourceAddress).
  • Consulta la sezione Come la policy sceglie l'indirizzo IP da valutare per determinare gli indirizzi IP nel messaggio per cui stai configurando le regole di gestione.
  • Configura una maschera per ogni indirizzo IP. Consenti o nega l'accesso in base a un valore di maschera sull'indirizzo IP. Consulta la sezione Informazioni sul mascheramento degli indirizzi IP con la notazione CIDR.
• Specifica l'ordine in cui vengono testate le regole.
• Tutte le regole di corrispondenza vengono eseguite nell'ordine specificato. Quando una regola corrisponde, viene eseguita l'azione corrispondente e le regole di corrispondenza successive vengono ignorate.
  • Se la stessa regola è configurata con le azioni CONSENTI e NEGA, viene attivata la regola definita per prima nell'ordine e la regola successiva (con l'altra azione) viene ignorata.

Come la policy sceglie l'indirizzo IP da valutare

Gli indirizzi IP possono provenire da varie fonti in una richiesta. Ad esempio, l'intestazione del messaggio True-Client-IP potrebbe contenere un indirizzo IP e l'intestazione X-Forwarded-For potrebbe contenere uno o più indirizzi IP. Questa sezione descrive come configurare la policy AccessControl per valutare gli indirizzi IP esatti che vuoi che valuti.

Di seguito è riportata la logica utilizzata dal criterio AccessControl per decidere quale indirizzo IP valutare:

1. Intestazione True-Client-IP

Il criterio verifica innanzitutto la presenza di un indirizzo IP nell'intestazione True-Client-IP. Se l'intestazione contiene un indirizzo IP valido, il criterio valuta questo indirizzo.

2. Intestazione X-Forwarded-For

Se non è presente un'intestazione True-Client-IP o se hai impostato l'elemento <IgnoreTrueClientIPHeader> su true, il criterio valuta gli indirizzi IP nell'intestazione X-Forwarded-For.

Edge compila automaticamente l'intestazione X-Forwarded-For con l'indirizzo IP ricevuto dall'ultimo handshake TCP esterno (ad esempio l'IP client o il router). Se nell'intestazione sono presenti più indirizzi IP, questi indirizzi corrispondono probabilmente alla catena di server che hanno elaborato una richiesta. Tuttavia, l'elenco di indirizzi potrebbe contenere anche un indirizzo IP falsificato. Quindi, in che modo il criterio sa quali indirizzi valutare?

La configurazione dell'organizzazione e la configurazione delle policy determinano quali indirizzi X-Forwarded-For vengono valutati dalla policy.

Innanzitutto, controlla se la proprietà feature.enableMultipleXForwardCheckForACL è impostata nella tua organizzazione. Puoi utilizzare l'API Get organization per eseguire il controllo. Quindi:

• Se non vedi feature.enableMultipleXForwardCheckForACL nell'elenco delle proprietà della tua organizzazione, significa che la proprietà è impostata su false (valore predefinito). Se questa proprietà è impostata su false, il criterio valuta l'indirizzo ultimo nell'intestazione (visibile nello strumento Trace), ovvero l'indirizzo IP ricevuto da Edge dall'ultimo handshake TCP esterno.
• Se feature.enableMultipleXForwardCheckForACL nella tua organizzazione è impostato su true, configura l'elemento <ValidateBasedOn> per determinare quali indirizzi IP vengono valutati dai criteri.

Modifica della proprietà feature.enableMultipleXForwardCheckForACL

Gli amministratori dell'organizzazione Edge possono utilizzare l'API Aggiorna proprietà dell'organizzazione per impostare la proprietà feature.enableMultipleXForwardCheckForACL.

L'esempio di API seguente imposta la proprietà in Edge for Private Cloud. Se nella tua organizzazione sono impostate altre proprietà, assicurati di includerle. In caso contrario, verranno rimossi.

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

In Edge for Private Cloud, dopo aver modificato il valore della proprietà feature.enableMultipleXForwardCheckForACL, devi riavviare i processori di messaggi, come descritto in Avviare/arrestare/riavviare singoli componenti.

Dimensioni X-Forwarded-For in Apigee Analytics

Edge Analytics scrive il valore dell'intestazione X-Forwarded-For nella dimensione x_forwarded_for_ip. Per determinare l'IP client che ha effettuato la richiesta a Edge, utilizza i valori nelle dimensioni ax_true_client_ip o ax_resolved_client_ip. Per saperne di più, consulta Riferimento per metriche, dimensioni e filtri di Analytics.

Informazioni sul mascheramento degli indirizzi IP con la notazione CIDR

La notazione CIDR (Classless Inter-Domain Routing) è un modo per indicare un intervallo di indirizzi IP tramite mascheramento. Si applica sia a IPv4 sia a IPv6. Ecco come funziona. Per semplicità, utilizzeremo IPv4 nei nostri esempi.

Gli indirizzi IP sono gruppi di numeri separati da punti. In termini binari, ogni gruppo è un numero specifico di bit (8 per IPv4 e 16 per IPv6). L'indirizzo IPv4 198.51.100.1 ha il seguente aspetto in formato binario:

11000110.00110011.01100100.00000001

Si tratta di 4 gruppi di 8 bit, per un totale di 32 bit. Con CIDR, puoi indicare un intervallo aggiungendo un /numero (1-32) all'indirizzo IP, in questo modo:

198.51.100.1/24

In questo caso, 24 è il numero che utilizzeresti per il valore dell'attributo mask in queste norme.

Questa notazione significa: "Mantieni i primi 24 bit esattamente come sono, i bit rimanenti possono assumere qualsiasi valore da 0 a 255". Ad esempio:

Nota che la maschera si trova alla fine del gruppo 3. In questo modo, tutto è ordinato e pulito, creando una maschera come questa: 198.51.100.*. Nella maggior parte dei casi, l'utilizzo di multipli di 8 (IPv4) e 16 (IPv6) ti fornirà il livello di mascheramento che desideri:

IPv4: 8, 16, 24, 32

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

Tuttavia, puoi utilizzare altri numeri per un controllo più granulare, che comporta un piccolo calcolo binario. Ecco un esempio che utilizza una maschera di 30, come in 198.51.100.1/30, dove l'ultimo 1 è 00000001 in formato binario:

In questo esempio, con la configurazione impostata su <SourceAddress mask="30">198.51.100.1</SourceAddress>, gli IP seguenti sarebbero consentiti (o negati, a seconda delle regole):

• 198.51.100.0
• 198.51.100.1
• 198.51.100.2
• 198.51.100.3

Riferimento elemento

Il riferimento agli elementi descrive gli elementi e gli attributi della policy di controllo dell'accesso.

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

Attributi <AccessControl>

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

La tabella seguente descrive gli attributi comuni a tutti gli elementi principali del criterio:

&lt;DisplayName&gt; elemento

Da utilizzare in aggiunta all'attributo name per etichettare il criterio in editor proxy della UI di gestione con un nome diverso e in linguaggio naturale.

<DisplayName>Policy Display Name</DisplayName>

Elemento <IgnoreTrueClientIPHeader>

Se lo imposti su true, il criterio ignora l'intestazione True-Client-IP e valuta gli indirizzi IP nell'intestazione X-Forwarded-For, seguendo il comportamento di valutazione X-Forwarded-For che hai configurato.

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

Elemento <IPRules>

L'elemento principale contenente le regole che consentono o negano gli indirizzi IP. L'attributo noRuleMatchAction ti consente di definire come gestire gli indirizzi IP non coperti dalle regole di corrispondenza.

<IPRules noRuleMatchAction = "ALLOW">

Attributi

Elemento <IPRules>/<MatchRule>

L'azione da intraprendere (consentire o negare l'accesso) se l'indirizzo IP corrisponde a SourceAddress(es) che definisci.

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

Attributi

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

L'intervallo di indirizzi IP di un client.

Valore valido: indirizzo IP valido (notazione decimale puntata). Per il comportamento jolly, utilizza l'attributo 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>

Come mostrato nell'esempio precedente, l'elemento SourceAddress supporta anche i modelli di messaggio per l'attributo mask o l'indirizzo IP, il che significa che puoi impostare i valori utilizzando le variabili attualmente disponibili nel flusso del proxy API.

Ad esempio, puoi archiviare un indirizzo IP in una mappa chiave-valore (KVM) e utilizzare il criterio KeyValueMapOperations per recuperare l'indirizzo IP e assegnarlo a una variabile (ad esempio kvm.ip.value). Puoi quindi utilizzare questa variabile per l'indirizzo IP:

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

L'impostazione della maschera e/o dell'indirizzo IP con una variabile ti offre la flessibilità di modificare i valori in fase di runtime senza dover modificare e ridistribuire il proxy API.

Attributi

Elemento <ValidateBasedOn>

Quando l'intestazione HTTP X-Forwarded-For contiene più indirizzi IP, utilizza questo elemento ValidateBasedOn per controllare quali indirizzi IP vengono valutati.

Utilizza questo approccio per valutare gli indirizzi IP solo se hai la certezza della validità degli indirizzi IP che vuoi valutare. Ad esempio, se scegli di valutare tutti gli indirizzi IP nell'intestazione X-Forwarded-For, devi essere in grado di fidarti della validità di questi indirizzi e/o configurare regole DENY o ALLOW complete per consentire solo agli IP attendibili di chiamare il tuo proxy API.

L'indirizzo IP più a sinistra nell'intestazione appartiene al client, mentre quello più a destra al server che ha inoltrato la richiesta al servizio attuale. L'indirizzo IP più a destra o l'ultimo è l'indirizzo ricevuto da Edge dall'ultimo handshake TCP esterno.

Il valore che inserisci in questo elemento ti consente di determinare se controllare tutti gli indirizzi IP nell'intestazione (impostazione predefinita), solo il primo indirizzo IP o solo l'ultimo indirizzo 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>

Schemi

Ogni tipo di policy è definito da uno schema XML (.xsd). Per riferimento, gli schemi delle policy sono disponibili su GitHub.

Messaggi di errore

Questa sezione descrive i codici e i messaggi di errore restituiti, nonché le variabili di errore impostate da Edge quando questo criterio attiva un errore. È importante sapere se stai sviluppando regole di errore per per gestire gli errori. Per saperne di più, consulta Cosa devi sapere sugli errori relativi ai criteri e sulla gestione di errore.

Errori di runtime

Questi errori possono verificarsi quando il criterio viene eseguito.

Variabili di errore

Queste variabili vengono impostate quando si verifica un errore di runtime. Per ulteriori informazioni, consulta Variabili specifiche per gli errori dei criteri.

Esempio di risposta all'errore

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

Esempio di regola di errore

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