Criterio AccessControl

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

Cosa

Il criterio di controllo dell'accesso consente di consentire o negare l'accesso alle API in base a IP specifici indirizzi IP esterni.

Sebbene sia possibile collegare questo criterio in qualsiasi punto del flusso del proxy API, ti consigliamo verifica gli indirizzi IP all'inizio del flusso ( Richiesta / ProxyEndpoint / PreFlow), anche prima l'autenticazione o il controllo delle quote.

Esempi

I valori di maschera negli esempi IPv4 seguenti identificano quale dei quattro ottetti (8, 16, 24, 32 bit) che la regola di corrispondenza prende in considerazione quando consente o nega l'accesso. Il valore predefinito è 32. Consulta le Attributo mask nel riferimento dell'elemento per ulteriori informazioni informazioni.

<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 dà il controllo sull'accesso IP legittimo. Ad esempio, se vuoi che i computer si trovino nella della tua azienda per accedere alle API esposte nell'ambiente di test, puoi consentire l'intervallo di indirizzi IP per la rete interna. Gli sviluppatori che lavorano da casa possono e accedere a queste API tramite la VPN.

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

• Definisci un insieme di regole di corrispondenza con una delle due azioni associate (ALLOW o DENY) con ciascuno.
• Per ogni regola di corrispondenza, specifica l'indirizzo IP (elemento SourceAddress).
  • Consulta In che modo il criterio sceglie l'indirizzo IP da valutare. per determinare quali indirizzi IP nel messaggio che stai configurando con le regole da gestire.
  • Configura una maschera per ogni indirizzo IP. Puoi consentire o negare l'accesso in base a un valore di maschera su l'indirizzo IP. Consulta 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 seguenti regole di corrispondenza vengono ignorate.
  • Se la stessa regola è configurata con le azioni ALLOW e DENY, la regola che definita per prima nell'ordine e viene attivata la regola successiva (con l'altra azione) 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 può contenere uno o più indirizzi IP. Questa sezione descrive come configurare il criterio AccessControl per valutare gli indirizzi IP esatti che che deve essere valutato.

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

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, viene valutato dal criterio.

2. Intestazione X-Forwarded-For

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

Edge compila automaticamente l'intestazione X-Forwarded-For con l'indirizzo IP che ha ricevuto dall'ultimo handshake TCP esterno (ad esempio l'IP client o router). Se nell'intestazione sono presenti più indirizzi IP, questi indirizzi sono probabilmente la catena di server che ha elaborato una richiesta. Tuttavia, l'elenco degli indirizzi potrebbe contenere anche un indirizzo IP falsificato. Quindi come fa la norma a sapere quali indirizzi valutare?

La configurazione dell'organizzazione e quella dei criteri determinano X-Forwarded-For indirizzo/i valutato/i dal criterio.

Innanzitutto, controlla se la proprietà feature.enableMultipleXForwardCheckForACL è configurato nella tua organizzazione. Puoi utilizzare lo Richiedi l'API Organization per controllare. Quindi:

• Se non vedi l'icona feature.enableMultipleXForwardCheckForACL nel tuo nell'elenco di proprietà dell'organizzazione, significa che la proprietà è impostata su false (valore predefinito). Quando questa proprietà è impostata su false, il criterio valuta la ultimo indirizzo nell'intestazione (visibile nella strumento Traccia), che corrisponde all'indirizzo IP Edge ricevuto dall'ultimo handshake TCP esterno.
• Se feature.enableMultipleXForwardCheckForACL nella tua organizzazione è impostato su true, configurare <ValidateBasedOn> per determinare gli indirizzi IP valutati dal criterio.

Modifica della proprietà feature.enableMultipleXForwardCheckForACL

Gli Amministratori dell'organizzazione perimetrale possono utilizzare Aggiorna l'API delle proprietà dell'organizzazione per impostare proprietà feature.enableMultipleXForwardCheckForACL.

L'esempio di API seguente imposta la proprietà in Edge per il cloud privato. Se nella tua organizzazione sono impostate altre proprietà, assicurati di includere anche queste. 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 il cloud privato, dopo aver modificato il valore feature.enableMultipleXForwardCheckForACL proprietà, è necessario riavviare i processori dei messaggi, come descritto in Avviare/interrompere/riavviare i singoli componenti.

Dimensioni Inoltrate con X nelle analisi di Apigee

L'analisi perimetrale 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 in ax_true_client_ip ax_resolved_client_ip dimensioni. Consulta Metriche, dimensioni, e filtri per saperne di più.

Informazioni sul mascheramento degli indirizzi IP con la notazione CIDR

La notazione CIDR (routing tra domini senza classe) è un modo per indicare un intervallo di indirizzi IP attraverso il mascheramento. Si applica sia a IPv4 che a IPv6. Ecco come funziona. Utilizzeremo IPv4 nella per semplificare le cose.

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

11000110.00110011.01100100.00000001

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

198.51.100.1/24

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

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

Nota che la maschera si verifica alla fine del gruppo 3. In questo modo tutto è pulito e ordinato, essence creando una maschera come questa: 198.51.100.*. Nella maggior parte dei casi, utilizzando multipli di 8 (IPv4) e 16 (IPv6) fornisce il livello di mascheramento desiderato:

IPv4: 8, 16, 24, 32

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

Tuttavia, puoi usare altri numeri per avere un controllo più granulare, cosa che richiede calcolo. Di seguito è riportato un esempio di utilizzo di una maschera di 30, come in 198.51.100.1/30, dove l'ultima 1 è 00000001 in binario:

In questo esempio, se la configurazione è impostata su <SourceAddress mask="30">198.51.100.1</SourceAddress>, saranno consentiti i seguenti IP (oppure negata, in base alle tue 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 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>

<AccessControl> attributi

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

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

<IgnoreTrueClientIPHeader> elemento

Se lo imposti su true, il criterio ignora l'intestazione True-Client-IP e valuta gli indirizzi IP nell'intestazione X-Forwarded-For, seguendo le 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>

<IPRules> elemento

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

<IPRules noRuleMatchAction = "ALLOW">

Attributi

<IPRules>/<MatchRule> elemento

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

<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

<IPRules>/<MatchRule>/<SourceAddress> elemento

L'intervallo di indirizzi IP di un client.

Valore valido: indirizzo IP valido (notazione decimale puntata). Per il comportamento dei caratteri jolly, utilizza la 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 Modelli di messaggio per mask o indirizzo IP, 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 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 senza dover modificare ed eseguire nuovamente il deployment del proxy API.

Attributi

<ValidateBasedOn> elemento

Quando l'intestazione HTTP X-Forwarded-For contiene più indirizzi IP di destinazione, usa questo elemento ValidateBasedOn per controllare quali indirizzi IP vengono viene valutato.

Utilizza questo approccio per valutare un indirizzo IP solo se hai la certezza della validità degli indirizzi IP che vuoi valutare. Ad esempio, se scegli di valutare tutte indirizzi IP nell'intestazione X-Forwarded-For, devi poter considerare attendibile la validità di tali indirizzi e/o configurare regole DENY o ALLOW complete per consentire Gli IP chiamano il proxy API.

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

Il valore inserito in questo elemento consente di determinare se controllare tutti gli indirizzi IP in l'intestazione (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 criterio viene definito da uno schema XML (.xsd). Per riferimento, gli schemi dei criteri 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>