Criterio AccessControl

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

Cosa

Il criterio di controllo dell'accesso consente di consentire o negare l'accesso alle API da parte di indirizzi IP specifici.

Sebbene sia possibile collegare questo criterio in qualsiasi punto del flusso del proxy API, è probabile che tu voglia controllare gli indirizzi IP all'inizio del flusso ( Richiesta / proxyEndpoint / preflusso), anche prima dell'autenticazione o del controllo della quota.

Samples

I valori di maschera nei seguenti esempi IPv4 identificano quale dei quattro ottetti (8, 16, 24, 32 bit) prende in considerazione la regola di corrispondenza quando consente o nega l'accesso. Il valore predefinito è 32. Per saperne di più, consulta l'attributo mask nel riferimento dell'elemento.

<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, il criterio di controllo dell'accesso ti offre anche il controllo sugli accessi IP legittimi. Ad esempio, se vuoi che solo i computer sotto il controllo della tua azienda accedano alle API esposte nell'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 tramite la VPN.

La configurazione e l'esecuzione di un criterio di controllo dell'accesso riguarda 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 l'articolo In che modo il criterio sceglie l'indirizzo IP da valutare per determinare quali indirizzi IP nel messaggio per cui stai configurando le regole sono da gestire.
  • Configura una maschera per ciascun indirizzo IP. Puoi consentire o negare l'accesso in base a un valore di maschera nell'indirizzo IP. Vedi Informazioni sul mascheramento degli indirizzi IP con la notazione CIDR.
• Specifica l'ordine in cui vengono verificate le regole.
• Tutte le regole di corrispondenza vengono eseguite nell'ordine specificato. Quando una regola corrisponde, viene eseguita l'azione corrispondente e le seguenti regole di corrispondenza vengono ignorate.
  • Se la stessa regola è configurata con entrambe le azioni ALLOW e DENY, la regola definita per prima nell'ordine viene attivata e la regola successiva (con l'altra azione) viene saltata.

In che modo il criterio sceglie l'indirizzo IP da valutare

Gli indirizzi IP possono provenire da varie origini 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 il criterio AccessControl per valutare gli indirizzi IP esatti che vuoi che valuti.

Di seguito è riportata la logica utilizzata dal criterio di 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 quell'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 o il router del client). Se nell'intestazione sono presenti più indirizzi IP, questi indirizzi corrispondono probabilmente alla catena di server che ha elaborato una richiesta. Tuttavia, l'elenco di indirizzi potrebbe contenere anche un indirizzo IP oggetto di spoofing. In che modo le norme individuano gli indirizzi da valutare?

La configurazione dell'organizzazione e la configurazione dei criteri determinano quali X-Forwarded-For indirizzi vengono valutati dal criterio.

Innanzitutto, verifica se la proprietà feature.enableMultipleXForwardCheckForACL è impostata nella tua organizzazione. Per controllare, puoi utilizzare l'API Ottieni organizzazione. Quindi:

• Se non vedi feature.enableMultipleXForwardCheckForACL nell'elenco di proprietà della tua organizzazione, significa che la proprietà è impostata su false (impostazione predefinita). Se questa proprietà è impostata su false, il criterio valuta l'ultimo indirizzo 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 dal criterio.

Modifica della proprietà feature.enableMultipleXForwardCheckForACL

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

L'esempio API seguente imposta la proprietà in Edge per il cloud privato. Se nella tua organizzazione sono state impostate altre proprietà, assicurati di includere anche quelle. 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 per cloud privato, 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 nell'analisi Apigee

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 la documentazione di riferimento su 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 attraverso il mascheramento. Si applica sia a IPv4 sia a IPv6. Ecco come funziona. Utilizzeremo IPv4 nei nostri esempi per semplificare la procedura.

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

11000110.00110011.01100100.00000001

ovvero 4 gruppi di 8 bit, o 32 bit totali. Con il CIDR, puoi indicare un intervallo aggiungendo /number (1-32) all'indirizzo IP, in questo modo:

198.51.100.1/24

In questo caso, 24 è il numero che useresti per il valore dell'attributo mask in questo criterio.

Questa notazione significa che "Mantieni i primi 24 bit esattamente così come sono, i bit rimanenti possono essere qualsiasi valore compreso tra 0 e 255". Ad esempio:

Nota che la maschera si trova alla fine del gruppo tre. Questo rende le cose belle e ordinate, in sostanza 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 desiderato:

IPv4: 8, 16, 24, 32

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

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

In questo esempio, con la configurazione impostata su <SourceAddress mask="30">198.51.100.1</SourceAddress>, i seguenti IP 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 elemento descrive gli elementi e gli attributi del criterio 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 dei criteri:

Elemento <DisplayName>

Utilizzalo in aggiunta all'attributo name per etichettare il criterio nell'editor proxy dell'interfaccia utente di gestione con un nome diverso in linguaggio naturale.

<DisplayName>Policy Display Name</DisplayName>

Elemento <IgnoraTrueClientIPHeader>

Se imposti questo valore 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 consente di definire come gestire gli indirizzi IP che non sono coperti dalle regole di corrispondenza.

<IPRules noRuleMatchAction = "ALLOW">

Attributi

Elemento <IPRules>/<MatchRule>

L'azione da eseguire (consentire o negare l'accesso) se l'indirizzo IP corrisponde agli indirizzi SourceAddress definiti.

<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 con caratteri 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 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 ed eseguire nuovamente il deployment del proxy API.

Attributi

Elemento <ConvalidaBasedOn>

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 da valutare. Ad esempio, se scegli di valutare tutti gli indirizzi IP nell'intestazione X-Forwarded-For, devi poter considerare attendibili la validità di questi indirizzi e/o configurare regole complete DENY o ALLOW 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 è il server che ha inoltrato la richiesta al servizio attuale. L'indirizzo più a destra, o ultimo, è l'indirizzo Edge ricevuto 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 o solo l'ultimo.

<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 criterio è definito da uno schema XML (.xsd). Per riferimento, su GitHub sono disponibili schemi dei criteri.

Messaggi di errore

Questa sezione descrive i codici e i messaggi di errore restituiti e le variabili di errore impostate da Edge quando questo criterio attiva un errore. Queste informazioni sono importanti per sapere se si stanno sviluppando regole di errore per gestire gli errori. Per scoprire di più, consulta gli articoli Cosa devi sapere sugli errori relativi alle norme e Gestione degli errori.

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 saperne di più, consulta Variabili specifiche per gli errori delle norme.

Esempio di risposta di 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>