Zasada kontroli dostępu

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

Co

Zasady kontroli dostępu umożliwiają przyznawanie lub odmawianie dostępu do interfejsów API na podstawie określonych adresów IP.

Tę zasadę możesz dołączyć w dowolnym miejscu przepływu proxy interfejsu API, ale najprawdopodobniej będziesz sprawdzać adresy IP na początku przepływu ( Request / ProxyEndpoint / PreFlow), jeszcze przed uwierzytelnianiem lub sprawdzaniem limitu.

Przykłady

Wartości maski w poniższych przykładach adresów IPv4 określają, które z 4 oktetów (8, 16, 24, 32 bity) są brane pod uwagę przez regułę dopasowania podczas zezwalania na dostęp lub odmawiania go. Wartością domyślną jest 32. Więcej informacji znajdziesz w opisie atrybutu mask w dokumentacji referencyjnej elementu.

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

Zastosowanie

Oprócz ochrony interfejsów API przed złośliwymi adresami IP zasady kontroli dostępu umożliwiają też kontrolowanie dostępu z prawidłowych adresów IP. Jeśli na przykład chcesz, aby dostęp do interfejsów API udostępnianych w środowisku testowym miały tylko komputery pod kontrolą Twojej firmy, możesz zezwolić na zakres adresów IP sieci wewnętrznej. Deweloperzy pracujący w domu mogą uzyskać dostęp do tych interfejsów API za pomocą VPN.

Konfigurowanie i wykonywanie zasad kontroli dostępu obejmuje te czynności:

• Zdefiniuj zestaw reguł dopasowania, z którymi powiązane są 2 działania (ZEZWÓL lub ODMÓW).
• W przypadku każdej reguły dopasowania określ adres IP (element SourceAddress).
  • Aby określić, które adresy IP w wiadomości mają być objęte regułami, zobacz Jak zasada wybiera adres IP do oceny.
  • Skonfiguruj maskę dla każdego adresu IP. Dostęp jest przyznawany lub odrzucany na podstawie wartości maski adresu IP. Więcej informacji znajdziesz w artykule Maskowanie adresów IP za pomocą notacji CIDR.
• Określ kolejność testowania reguł.
• Wszystkie reguły dopasowania są wykonywane w podanej kolejności. Gdy reguła jest zgodna, wykonywane jest odpowiednie działanie, a kolejne reguły dopasowania są pomijane.
  • Jeśli ta sama reguła jest skonfigurowana z działaniami ZEZWÓL i ODRZUĆ, zostanie wywołana reguła, która jest zdefiniowana jako pierwsza w kolejności, a następna reguła (z innym działaniem) zostanie pominięta.

Sposób, w jaki zasady wybierają adres IP do oceny

Adresy IP mogą pochodzić z różnych źródeł w żądaniu. Na przykład nagłówek wiadomości True-Client-IP może zawierać adres IP, a nagłówek X-Forwarded-For może zawierać co najmniej 1 adres IP. W tej sekcji opisujemy, jak skonfigurować zasadę AccessControl, aby oceniała dokładnie te adresy IP, które chcesz poddać ocenie.

Zasady AccessControl używają tej logiki, aby określić, który adres IP ma być oceniany:

1. Nagłówek True-Client-IP

Zasada najpierw sprawdza adres IP w nagłówku True-Client-IP. Jeśli nagłówek zawiera prawidłowy adres IP, zasady oceniają ten adres.

2. Nagłówek X-Forwarded-For

Jeśli nie ma nagłówka True-Client-IP lub element <IgnoreTrueClientIPHeader> ma wartość true, zasada ocenia adresy IP w nagłówku X-Forwarded-For.

Edge automatycznie wypełnia nagłówek X-Forwarded-For adresem IP otrzymanym z ostatniego zewnętrznego uzgadniania TCP (np. adresem IP klienta lub routera). Jeśli w nagłówku jest wiele adresów IP, prawdopodobnie są to adresy serwerów, które przetworzyły żądanie. Lista adresów może jednak zawierać sfałszowany adres IP. Skąd zasady wiedzą, które adresy mają oceniać?

Konfiguracja organizacji i konfiguracja zasad określają, które adresy X-Forwarded-For są oceniane przez zasady.

Najpierw sprawdź, czy w Twojej organizacji jest ustawiona właściwość feature.enableMultipleXForwardCheckForACL. Możesz to sprawdzić za pomocą interfejsu Get organization API. Następnie:

• Jeśli nie widzisz ikony feature.enableMultipleXForwardCheckForACL na liście usług organizacji, oznacza to, że ta usługa ma wartość fałsz (domyślną). Jeśli ta właściwość ma wartość false, zasada ocenia ostatni adres w nagłówku (widoczny w narzędziu do śledzenia), czyli adres IP, który Edge otrzymał z ostatniego zewnętrznego uzgadniania TCP.
• Jeśli wartość parametru feature.enableMultipleXForwardCheckForACL w Twojej organizacji jest ustawiona na „true”, skonfiguruj element <ValidateBasedOn>, aby określić, które adresy IP mają być oceniane przez zasadę.

Zmiana usługi feature.enableMultipleXForwardCheckForACL

Administratorzy organizacji Edge mogą używać interfejsu API Aktualizowanie właściwości organizacji, aby ustawić właściwość feature.enableMultipleXForwardCheckForACL.

Ten przykładowy interfejs API ustawia właściwość w Edge for Private Cloud. Jeśli w organizacji są ustawione inne usługi, pamiętaj, aby je również uwzględnić. W przeciwnym razie zostaną one usunięte.

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

W Edge for Private Cloud po zmianie wartości właściwości feature.enableMultipleXForwardCheckForACL musisz ponownie uruchomić procesory wiadomości zgodnie z opisem w artykule Uruchamianie, zatrzymywanie i ponowne uruchamianie poszczególnych komponentów.

Wymiary X-Forwarded-For w analityce Apigee

Edge Analytics zapisuje wartość nagłówka X-Forwarded-For w wymiarze x_forwarded_for_ip. Aby określić adres IP klienta, który wysłał żądanie do Edge, użyj wartości w wymiarach ax_true_client_ip lub ax_resolved_client_ip. Więcej informacji znajdziesz w artykule Wymiary, dane i filtry w Analytics.

Maskowanie adresów IP za pomocą notacji CIDR

Notacja CIDR (Classless Inter-Domain Routing) to sposób wskazywania zakresu adresów IP za pomocą maskowania. Dotyczy to zarówno IPv4, jak i IPv6. Jak to działa: W przykładach użyjemy adresów IPv4, aby uprościć wyjaśnienia.

Adresy IP to grupy liczb oddzielone kropkami. W systemie binarnym każda grupa to określona liczba bitów (8 w przypadku IPv4 i 16 w przypadku IPv6). Adres IPv4 198.51.100.1 w formie binarnej wygląda tak:

11000110.00110011.01100100.00000001

To 4 grupy po 8 bitów, czyli łącznie 32 bity. W notacji CIDR możesz wskazać zakres, dodając do adresu IP znak / i liczbę (1–32), np.:

198.51.100.1/24

W tym przypadku wartość 24 to liczba, której użyjesz w zasadach jako wartości atrybutu mask.

Ten zapis oznacza: „Pierwsze 24 bity pozostaw bez zmian, a pozostałe bity mogą mieć dowolną wartość od 0 do 255”. Na przykład:

Zwróć uwagę, że maska znajduje się na końcu grupy 3. Dzięki temu wszystko będzie uporządkowane, a w zasadzie utworzy się maska w postaci 198.51.100.*. W większości przypadków użycie wielokrotności 8 (IPv4) i 16 (IPv6) zapewni Ci odpowiedni poziom maskowania:

IPv4: 8, 16, 24, 32

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

Możesz jednak używać innych liczb, aby uzyskać większą kontrolę, co wymaga niewielkich obliczeń binarnych. Oto przykład użycia maski 30, jak w przypadku adresu 198.51.100.1/30, gdzie ostatnia cyfra 1 to 00000001 w systemie binarnym:

W tym przykładzie, gdy konfiguracja jest ustawiona na <SourceAddress mask="30">198.51.100.1</SourceAddress>, te adresy IP będą dozwolone (lub zabronione, w zależności od reguł):

• 198.51.100.0
• 198.51.100.1
• 198.51.100.2
• 198.51.100.3

Odwołanie do elementu

Dokumentacja elementu opisuje elementy i atrybuty zasad kontroli dostępu.

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

Atrybuty <AccessControl>

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

W tej tabeli opisano atrybuty wspólne dla wszystkich elementów nadrzędnych zasad:

&lt;DisplayName&gt; element

Używaj oprócz atrybutu name do oznaczania zasady w edytor proxy interfejsu zarządzania z inną nazwą w języku naturalnym.

<DisplayName>Policy Display Name</DisplayName>

Element <IgnoreTrueClientIPHeader>

Jeśli ustawisz tę wartość na „true”, zasada zignoruje nagłówek True-Client-IP i oceni adresy IP w nagłówku X-Forwarded-For zgodnie z skonfigurowanym przez Ciebie sposobem oceny nagłówka X-Forwarded-For.

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

Element <IPRules>

Element nadrzędny zawierający reguły, które zezwalają na adresy IP lub je odrzucają. Atrybut noRuleMatchAction umożliwia określenie sposobu obsługi adresów IP, które nie są objęte regułami dopasowywania.

<IPRules noRuleMatchAction = "ALLOW">

Atrybuty

Element <IPRules>/<MatchRule>

Działanie, które należy podjąć (zezwolenie na dostęp lub odmowa dostępu), jeśli adres IP pasuje do zdefiniowanych przez Ciebie adresów źródłowych.

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

Atrybuty

Element <IPRules>/<MatchRule>/<SourceAddress>

Zakres adresów IP klienta.

Prawidłowa wartość: prawidłowy adres IP (notacja dziesiętna z kropkami). W przypadku symbolu wieloznacznego użyj atrybutu 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>

Jak pokazano w poprzednim przykładzie, element SourceAddress obsługuje też szablony wiadomości dla atrybutu mask lub adresu IP, co oznacza, że wartości można ustawiać za pomocą zmiennych, które są obecnie dostępne w przepływie proxy interfejsu API.

Możesz na przykład zapisać adres IP w mapie par klucz-wartość (KVM) i użyć zasady KeyValueMapOperations, aby pobrać adres IP i przypisać go do zmiennej (np. kvm.ip.value). Następnie możesz użyć tej zmiennej dla adresu IP:

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

Ustawienie maski lub adresu IP za pomocą zmiennej daje możliwość zmiany wartości w czasie działania bez konieczności modyfikowania i ponownego wdrażania serwera proxy interfejsu API.

Atrybuty

Element <ValidateBasedOn>

Jeśli nagłówek HTTP X-Forwarded-For zawiera wiele adresów IP, użyj tego elementu ValidateBasedOn, aby określić, które adresy IP mają być oceniane.

Używaj tej metody oceny adresów IP tylko wtedy, gdy masz pewność co do ich ważności. Jeśli na przykład zdecydujesz się oceniać wszystkie adresy IP w nagłówku X-Forwarded-For, musisz mieć pewność, że te adresy są prawidłowe, lub skonfigurować kompleksowe reguły DENY lub ALLOW, aby tylko zaufane adresy IP mogły wywoływać Twój serwer proxy interfejsu API.

Najbardziej po lewej stronie nagłówka znajduje się adres IP klienta, a najbardziej po prawej – serwera, który przekazał żądanie do bieżącej usługi. Najbardziej po prawej stronie lub ostatni adres IP to adres, który Edge otrzymał z ostatniego zewnętrznego uzgadniania TCP.

Wartość wpisana w tym elemencie pozwala określić, czy należy sprawdzić wszystkie adresy IP w nagłówku (domyślnie), tylko pierwszy adres IP czy tylko ostatni adres 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>

Schematy

Każdy typ zasady jest zdefiniowany przez schemat XML (.xsd). Schematy zasad są dostępne na GitHubie.

Odwołanie do błędu

W tej sekcji opisano kody błędów i komunikaty o błędach, które są zwracane, oraz zmienne błędów ustawiane przez Edge, gdy ta zasada wyzwala błąd. Warto o tym wiedzieć, jeśli rozwijasz reguły błędów, aby obsługi błędów. Więcej informacji znajdziesz w artykule Co musisz wiedzieć o błędach związanych z zasadami i postępowaniu z błędami

Błędy w czasie wykonywania

Te błędy mogą wystąpić podczas wykonywania zasady.

Zmienne błędów

Te zmienne są ustawiane po wystąpieniu błędu działania. Więcej informacji znajdziesz w artykule Zmienne związane z błędami związanymi z zasadami.

Przykładowa odpowiedź na błąd

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

Przykładowa reguła błędu

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