Zasada kontroli dostępu

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Co

Zasada kontroli dostępu pozwala zezwalać na dostęp do interfejsów API lub go blokować przez określone adresy IP.

Chociaż możesz dołączyć tę zasadę w dowolnym miejscu procesu serwera proxy interfejsu API, najprawdopodobniej najlepiej będzie sprawdzić adresy IP na początku tego procesu ( Request / ProxyEndpoint / PreFlow), nawet przed uwierzytelnianiem lub sprawdzeniem limitu.

Sample

Wartości maski w poniższych przykładach IPv4 określają, które z 4 oktetów (8, 16, 24, 32 bitów) uwzględnia reguła dopasowania przy dopuszczaniu lub blokowaniu dostępu. Wartością domyślną jest 32. Więcej informacji znajdziesz w opisie atrybutu mask w dokumentacji 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

Zasada kontroli dostępu nie tylko zabezpiecza interfejsy API przed szkodliwymi adresami IP, ale zapewnia też kontrolę nad dozwolonym dostępem do adresów IP. Jeśli na przykład chcesz, aby tylko komputery będące pod kontrolą Twojej firmy miały dostęp do interfejsów API dostępnych w środowisku testowym, możesz zezwolić na zakres adresów IP sieci wewnętrznej. Deweloperzy pracujący z domu mogą uzyskać dostęp do tych interfejsów API za pomocą sieci VPN.

Konfiguracja i wykonanie zasady kontroli dostępu obejmuje:

• Zdefiniuj zestaw reguł dopasowania z jednym z 2 powiązanych działań (ZEZWÓL lub ODRZUĆ).
• Dla każdej reguły dopasowania podaj adres IP (element SourceAddress).
  • Zobacz, jak zasada wybiera adres IP do oceny, aby określić, które adresy IP w wiadomości, do których konfigurujesz reguły, dowiesz się z artykułu.
  • Skonfiguruj maskę dla każdego adresu IP. Możesz zezwalać na dostęp lub go blokować na podstawie wartości maski w adresie IP. Zapoznaj się z artykułem Maskowanie adresów IP w notacji CIDR (w języku angielskim).
• 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 zarówno z działaniami ZEZWALAJ, jak i DENY, uruchomi się reguła zdefiniowana jako pierwsza w kolejności, a kolejna reguła (z innym działaniem) zostanie pominięta.

W jaki sposób zasada wybiera 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. Z tej sekcji dowiesz się, jak skonfigurować zasadę AccessControl, aby ocenić dokładne adresy IP, które ma ona oceniać.

Oto logika, której używa zasada AccessControl do określania adresu IP do oceny:

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, zasada go ocenia.

2. Nagłówek X-Forwarded-For

Jeśli nie ma nagłówka True-Client-IP lub element <IgnoreTrueClientIPHeader> ma wartość Prawda, 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 połączenia TCP (np. adresem IP klienta lub routerem). Jeśli w nagłówku znajduje się wiele adresów IP, są to prawdopodobnie łańcuchy serwerów, które przetworzyły żądanie. Lista adresów może też zawierać sfałszowany adres IP. Skąd polityka określa, które adresy sprawdzać?

Konfiguracja Twojej organizacji i konfiguracja zasad określają, które adresy(X-Forwarded-For) oceniane przez zasadę.

Najpierw sprawdź, czy w organizacji jest ustawiona właściwość feature.enableMultipleXForwardCheckForACL. Możesz to sprawdzić za pomocą interfejsu API Pobierz organizację. To:

• Jeśli nie widzisz feature.enableMultipleXForwardCheckForACL na liście usług w organizacji, oznacza to, że ma ona wartość false (fałsz). Gdy ta właściwość ma wartość Fałsz, zasada ocenia ostatni adres w nagłówku (widoczny w narzędziu śledzenia), czyli adres IP otrzymany w ramach ostatniego zewnętrznego uzgadniania połączenia TCP.
• Jeśli feature.enableMultipleXForwardCheckForACL w Twojej organizacji ma wartość Prawda, skonfiguruj element <ValidateBasedOn>, aby określać, które adresy IP oceniane przez zasadę.

Zmienianie właściwości feature.enableMultipleXForwardCheckForACL

Administratorzy organizacji Edge mogą ustawić właściwość feature.enableMultipleXForwardCheckForACL za pomocą interfejsu API Aktualizowanie właściwości organizacji.

Poniższy przykładowy interfejs API ustawia właściwość w Edge dla Private Cloud. Jeśli w Twojej organizacji są ustawione inne usługi, pamiętaj, aby je uwzględnić. W przeciwnym razie zostaną 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 dla Private Cloud po zmianie wartości właściwości feature.enableMultipleXForwardCheckForACL musisz ponownie uruchomić procesory wiadomości zgodnie z opisem w sekcji Uruchamianie, zatrzymywanie i ponowne uruchamianie poszczególnych komponentów.

X-Forwarded-For wymiarów w Apigee Analytics

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 dokumentacji danych, wymiarów i filtrów Analytics.

Informacje o maskowaniu adresów IP w notacji CIDR

Notacja CIDR (Classless Inter-Domain Routing) służy do wskazywania zakresu adresów IP przez maskowanie. Dotyczy zarówno IPv4, jak i IPv6. Działa to w następujący sposób: Dla uproszczenia w naszych przykładach użyjemy protokołu IPv4.

Adresy IP to grupy numerów oddzielonych kropkami. W zapisie dwójkowym każda grupa to określona liczba bitów (8 dla IPv4 i 16 dla IPv6). Adres IPv4 198.51.100.1 w zapisie binarnym wygląda tak:

11000110.00110011.01100100.00000001

To 4 grupy po 8 bitów, czyli łącznie 32 bity. W CIDR możesz wskazać zakres, dodając do adresu IP /number (1–32) w ten sposób:

198.51.100.1/24

W tym przypadku 24 to liczba, której użyjesz dla wartości atrybutu mask w tej zasadzie.

Ten zapis oznacza: „Zachowaj pierwsze 24 bity dokładnie tak, jak są. Pozostałe bity mogą mieć dowolną wartość od 0 do 255”. Na przykład:

Zwróć uwagę, że maska występuje na końcu grupy 3. Dzięki temu wszystko jest ładne i schludne.W zasadzie można utworzyć maskę w postaci takiej: 198.51.100*. W większości przypadków użycie wielokrotności liczby 8 (IPv4) i 16 (IPv6) pozwala uzyskać pożądany 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ć bardziej precyzyjną kontrolę, co wymaga wykonania niewielkich obliczeń binarnych. Oto przykład z użyciem maski o wartości 30, np. 198.51.100.1/30, gdzie ostatnie 1 to 00000001 w zapisie dwójkowym:

W tym przykładzie, jeśli konfiguracja to <SourceAddress mask="30">198.51.100.1</SourceAddress>, te adresy IP będą dozwolone (lub odrzucone – 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 elementów opisuje elementy i atrybuty zasady 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"> 

Tabela poniżej zawiera opis atrybutów wspólnych dla wszystkich elementów nadrzędnych zasad:

Element <DisplayName>

Użyj oprócz atrybutu name, aby oznaczyć zasadę w edytorze serwera proxy interfejsu zarządzania inną nazwą w języku naturalnym.

<DisplayName>Policy Display Name</DisplayName>

Element <ignoreTrueClientIPHeader>

Jeśli zasada ma wartość Prawda, zasada ignoruje nagłówek True-Client-IP i ocenia adresy IP w nagłówku X-Forwarded-For zgodnie ze skonfigurowanym działem oceny 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 blokują. Atrybut noRuleMatchAction pozwala określić sposób obsługi adresów IP, których nie obejmują reguły dopasowania.

<IPRules noRuleMatchAction = "ALLOW">

Atrybuty

Element <IPRules>/<MatchRule>

Działanie, które ma zostać wykonane (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). Aby zachować zgodność z symbolami wieloznacznymi, 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 możesz ustawiać wartości za pomocą zmiennych, które są obecnie dostępne w procesie serwera proxy interfejsu API.

Możesz na przykład zapisać adres IP w mapie par klucz-wartość (KVM) i użyć zasady KeyValueMapOperations do pobrania adresu IP i przypisania go do zmiennej (takiej jak 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 pozwala zmieniać 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 są oceniane.

Dzięki tej metodzie możesz oceniać adresy IP tylko wtedy, gdy masz pewność, że są one prawidłowe. Jeśli na przykład zdecydujesz się ocenić wszystkie adresy IP w nagłówku X-Forwarded-For, musisz ufać ich poprawności tych adresów lub skonfigurować kompleksowe reguły odrzucania i zezwolenia, aby umożliwić wywoływanie serwera proxy interfejsu API tylko zaufanym adresom IP.

Adres IP najdalej z lewej w nagłówku należy do klienta. Serwer po prawej stronie przekierował żądanie do bieżącej usługi. Najbardziej prawy lub ostatni adres IP to adres otrzymany Edge podczas ostatniego zewnętrznego uzgadniania połączenia TCP.

Wartość podana w tym elemencie pozwala określić, czy mają być sprawdzane wszystkie adresy IP w nagłówku (domyślnie), tylko pierwszy adres IP czy tylko ostatni.

<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 definiowany przez schemat XML (.xsd). Schematy zasad są dostępne na GitHubie.

Informacje o błędach

W tej sekcji opisujemy kody błędów i komunikaty o błędach, które są zwracane, oraz zmienne błędów ustawiane przez Edge, gdy ta zasada wywołuje błąd. Te informacje są ważne, jeśli opracowujesz reguły dotyczące błędów do obsługi takich błędów. Więcej informacji znajdziesz w sekcjach Co musisz wiedzieć o błędach zasad i Postępowanie w przypadku błędów.

Błędy w czasie wykonywania

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

Zmienne błędów

Te zmienne są ustawiane, gdy wystąpi błąd środowiska wykonawczego. Więcej informacji znajdziesz w artykule Zmienne związane z błędami dotyczącymi zasad.

Przykładowa odpowiedź o błędzie

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