Białe listy adresów IP dla kluczy API

Ptak

19 sie 2015

Email

1 min read

Białe listy adresów IP dla kluczy API

Najważniejsze informacje

    • Klucze API to potężne poświadczenia - jeśli zostaną skompromitowane, napastnicy mogą wysyłać e-maile, kraść dane lub podszywać się pod Twoją markę.

    • Wykonanie ataku siłowego na 40-znakowy klucz szesnastkowy jest zasadniczo niemożliwe; prawdziwe zagrożenia pochodzą z ekspozycji (ataków MITM, niezabezpieczonych repozytoriów kodu, wyciekających poświadczeń).

    • Zawsze używaj HTTPS i weryfikuj certyfikaty SSL, aby zapobiec przechwytywaniu Twoich kluczy API.

    • Whitelistowanie adresów IP dodaje krytyczną warstwę ochrony, ograniczając użycie klucza do konkretnych adresów IP lub zakresów adresów IP.

    • Nawet jeśli napastnik ukradnie Twój klucz API, nie będzie mógł z niego korzystać, chyba że łączy się z zatwierdzonego adresu IP.

    • Wsparcie CIDR ułatwia autoryzację całych sieci bez wymieniania każdego serwera.

    • Unikaj osadzania kluczy API w kodzie - zamiast tego używaj zmiennych środowiskowych lub bezpiecznych rozwiązań do zarządzania sekretami.

    • Twórz wiele kluczy API o wąskim zakresie, a nie jeden „wszystko-da-jedn” klucz - każdy z ograniczonymi uprawnieniami i własną białą listą.

    • Dla integracji zewnętrznych, twórz dedykowane klucze z ograniczonymi przywilejami i ograniczonymi adresami IP.

    • Włącz 2FA na swoim koncie, ponieważ klucze API można tworzyć tylko przez interfejs użytkownika.

    • Regularnie przeglądaj, rotuj i wygaszaj klucze, aby utrzymać silne bezpieczeństwo operacyjne.

Podsumowanie pytań i odpowiedzi

  • Czym jest whitelistowanie adresów IP?

    To jest funkcja zabezpieczająca, która ogranicza użycie klucza API do określonych adresów IP lub zakresów adresów IP.

  • Dlaczego SparkPost/Bird używa kluczy API do uwierzytelniania?

    Klucze API są proste, szeroko stosowane i działają płynnie z API REST i SMTP.

  • Co się stanie, jeśli ktoś ukradnie mój klucz API?

    Mogli wysyłać maile w Twoim imieniu, pobierać listy odbiorców, modyfikować szablony lub wysyłać phishing/spam, który szkodzi Twojej marce.

  • Czy klucze API mogą być łamane przez brute force?

    Praktycznie niemożliwe. 40-znakowy ciąg szesnastkowy ma ~1.46e48 kombinacji — łamanie go metodą brute-force zajęłoby więcej czasu niż wiek wszechświata.

  • Jak zatem atakujący zwykle zdobywają klucze API?

    Ataki typu man-in-the-middle (jeśli SSL nie jest weryfikowane), ujawnione klucze w publicznych repozytoriach GitHub lub logi przypadkowo ujawniające klucze.

  • Jak pomaga biała lista adresów IP?

    Nawet jeśli napastnik ukradnie twój klucz, nie będzie działał, chyba że łączy się z zatwierdzonego adresu IP.

  • Czy mogę dodać całe sieci do białej listy?

    Tak, za pomocą notacji CIDR - idealne dla serwerów z równoważeniem obciążenia, VPN-ów lub statycznych zakresów biurowych.

  • Czy dodanie do białej listy dotyczy zarówno REST, jak i SMTP?

    Tak, adres IP nadchodzącego żądania musi odpowiadać twojej liście dozwolonych.

  • Ile adresów IP lub zakresów mogę dodać do listy dozwolonej?

    Ile tylko potrzebujesz — wiele indywidualnych adresów IP lub bloków.

  • Czy powinienem używać jednego klucza API do wszystkiego?

    Nie. Utwórz oddzielne klucze dla różnych systemów, zespołów lub dostawców. Poprawia to bezpieczeństwo i ułatwia rotację lub unieważnienie kluczy.

  • Gdzie powinienem przechowywać klucze API?

    Używaj zmiennych środowiskowych — nigdy nie wprowadzaj jawnie kluczy do plików źródłowych lub publicznych repozytoriów.

  • Jakie dodatkowe najlepsze praktyki w zakresie bezpieczeństwa?

    Zawsze włączaj 2FA na swoim koncie SparkPost/Bird i twórz dedykowane klucze dla podmiotów trzecich z minimalnymi uprawnieniami i własnymi listami dozwolonymi.

Istnieje wiele sposobów na zbudowanie uwierzytelniania w produkcie opartym na API, takim jak SparkPost, a tym, który wybraliśmy na początku, jest użycie kluczy API. Wstrzykiwanie klucza API jako surowego nagłówka Authorization lub za pomocą standardowego uwierzytelniania HTTP Basic sprawia, że korzystanie z naszych interfejsów API jest bardzo proste. Klucze API tego typu są powszechnym standardem dla usług internetowych, ale jak bezpieczny jest ten system?

Istnieje wiele sposobów na zbudowanie uwierzytelniania w produkcie opartym na API, takim jak SparkPost, a tym, który wybraliśmy na początku, jest użycie kluczy API. Wstrzykiwanie klucza API jako surowego nagłówka Authorization lub za pomocą standardowego uwierzytelniania HTTP Basic sprawia, że korzystanie z naszych interfejsów API jest bardzo proste. Klucze API tego typu są powszechnym standardem dla usług internetowych, ale jak bezpieczny jest ten system?

Istnieje wiele sposobów na zbudowanie uwierzytelniania w produkcie opartym na API, takim jak SparkPost, a tym, który wybraliśmy na początku, jest użycie kluczy API. Wstrzykiwanie klucza API jako surowego nagłówka Authorization lub za pomocą standardowego uwierzytelniania HTTP Basic sprawia, że korzystanie z naszych interfejsów API jest bardzo proste. Klucze API tego typu są powszechnym standardem dla usług internetowych, ale jak bezpieczny jest ten system?

Ryzyka

Kiedy korzystasz z dowolnej usługi sieciowej, jeśli atakujący zdobędzie twój klucz API, mogą działać w twoim imieniu i robić takie rzeczy jak (w naszym przypadku):

  • wysyłać swoje e-maile za darmo przez twoje konto

  • pobierać listę twoich odbiorców i przekazywać je spamerom (jeśli sami nie są spamerami)

  • edytować twoje szablony, aby wstrzykiwać linki phishingowe

  • wysyłać spam lub phishing w twoim imieniu

Każdy z tych rezultatów może być bardzo szkodliwy dla twojej reputacji i twojego biznesu, a w przypadku phishingu potencjalnie bezpośrednio zaszkodzić twoim użytkownikom końcowym.  Dlatego bardzo ważne jest, aby upewnić się, że nikt nie może odkryć twojego klucza API.

Kiedy korzystasz z dowolnej usługi sieciowej, jeśli atakujący zdobędzie twój klucz API, mogą działać w twoim imieniu i robić takie rzeczy jak (w naszym przypadku):

  • wysyłać swoje e-maile za darmo przez twoje konto

  • pobierać listę twoich odbiorców i przekazywać je spamerom (jeśli sami nie są spamerami)

  • edytować twoje szablony, aby wstrzykiwać linki phishingowe

  • wysyłać spam lub phishing w twoim imieniu

Każdy z tych rezultatów może być bardzo szkodliwy dla twojej reputacji i twojego biznesu, a w przypadku phishingu potencjalnie bezpośrednio zaszkodzić twoim użytkownikom końcowym.  Dlatego bardzo ważne jest, aby upewnić się, że nikt nie może odkryć twojego klucza API.

Kiedy korzystasz z dowolnej usługi sieciowej, jeśli atakujący zdobędzie twój klucz API, mogą działać w twoim imieniu i robić takie rzeczy jak (w naszym przypadku):

  • wysyłać swoje e-maile za darmo przez twoje konto

  • pobierać listę twoich odbiorców i przekazywać je spamerom (jeśli sami nie są spamerami)

  • edytować twoje szablony, aby wstrzykiwać linki phishingowe

  • wysyłać spam lub phishing w twoim imieniu

Każdy z tych rezultatów może być bardzo szkodliwy dla twojej reputacji i twojego biznesu, a w przypadku phishingu potencjalnie bezpośrednio zaszkodzić twoim użytkownikom końcowym.  Dlatego bardzo ważne jest, aby upewnić się, że nikt nie może odkryć twojego klucza API.

Szanse

Czy usłyszałem bruteforce? Nasze klucze API są losowo generowanymi 40-znakowymi ciągami szesnastkowymi. Daje to łączną liczbę 1.4615e+48 kluczy API. Gdyby wszystkie 3 miliardy komputerów i smartfonów na świecie próbowały 100 kluczy API na sekundę, zakładając, że nasze serwery na to pozwolą, przebrnięcie przez wszystkie możliwe klucze API zajęłoby więcej niż 150 000 000 000 000 000 000 000 000 000 lat. Dlatego brutalne łamanie klucza API po prostu nie ma sensu.

Jak więc można znaleźć swój klucz API? Ponieważ klucz jest przekazywany jako nagłówek, można go odczytać za pomocą ataków typu man-in-the-middle, więc zawsze powinieneś upewnić się, że twój klient sprawdza certyfikaty SSL podczas łączenia z naszymi API (to jest główny powód, dla którego wymagamy https do połączeń API). Ponadto, jeśli nieostrożnie korzystasz z publicznych repozytoriów kodu, takich jak github, twój klucz API może łatwo zostać ujawniony w sieci. To nie jest problem akademicki: istnieją znane boty skanujące github w poszukiwaniu kluczy API, a przez ten wektor miały miejsce udane ataki.

Czy usłyszałem bruteforce? Nasze klucze API są losowo generowanymi 40-znakowymi ciągami szesnastkowymi. Daje to łączną liczbę 1.4615e+48 kluczy API. Gdyby wszystkie 3 miliardy komputerów i smartfonów na świecie próbowały 100 kluczy API na sekundę, zakładając, że nasze serwery na to pozwolą, przebrnięcie przez wszystkie możliwe klucze API zajęłoby więcej niż 150 000 000 000 000 000 000 000 000 000 lat. Dlatego brutalne łamanie klucza API po prostu nie ma sensu.

Jak więc można znaleźć swój klucz API? Ponieważ klucz jest przekazywany jako nagłówek, można go odczytać za pomocą ataków typu man-in-the-middle, więc zawsze powinieneś upewnić się, że twój klient sprawdza certyfikaty SSL podczas łączenia z naszymi API (to jest główny powód, dla którego wymagamy https do połączeń API). Ponadto, jeśli nieostrożnie korzystasz z publicznych repozytoriów kodu, takich jak github, twój klucz API może łatwo zostać ujawniony w sieci. To nie jest problem akademicki: istnieją znane boty skanujące github w poszukiwaniu kluczy API, a przez ten wektor miały miejsce udane ataki.

Czy usłyszałem bruteforce? Nasze klucze API są losowo generowanymi 40-znakowymi ciągami szesnastkowymi. Daje to łączną liczbę 1.4615e+48 kluczy API. Gdyby wszystkie 3 miliardy komputerów i smartfonów na świecie próbowały 100 kluczy API na sekundę, zakładając, że nasze serwery na to pozwolą, przebrnięcie przez wszystkie możliwe klucze API zajęłoby więcej niż 150 000 000 000 000 000 000 000 000 000 lat. Dlatego brutalne łamanie klucza API po prostu nie ma sensu.

Jak więc można znaleźć swój klucz API? Ponieważ klucz jest przekazywany jako nagłówek, można go odczytać za pomocą ataków typu man-in-the-middle, więc zawsze powinieneś upewnić się, że twój klient sprawdza certyfikaty SSL podczas łączenia z naszymi API (to jest główny powód, dla którego wymagamy https do połączeń API). Ponadto, jeśli nieostrożnie korzystasz z publicznych repozytoriów kodu, takich jak github, twój klucz API może łatwo zostać ujawniony w sieci. To nie jest problem akademicki: istnieją znane boty skanujące github w poszukiwaniu kluczy API, a przez ten wektor miały miejsce udane ataki.

Biała lista adresów IP w akcji

Kiedy tworzysz klucz API, możesz teraz określić listę adresów IP, które mają prawo do korzystania z tego klucza. Możesz określić kilka adresów IP, a także bloki adresów IP, używając notacji CIDR, aby nie musieć wymieniać swoich serwerów indywidualnie. Gdy klucz API jest używany, dla API REST lub SMTP, dopasujemy łączący adres IP do tej listy, aby zezwolić lub odmówić dostępu.

Dzięki tej funkcji, nawet jeśli twój klucz API zostanie znaleziony lub skradziony, tylko twoje serwery będą mogły z niego korzystać.

Typowe zagrożenia związane z kluczem API i ich ograniczenia

Zagrożenie

Opis

Zalecane ograniczenie

Ekspozycja klucza w publicznych repozytoriach kodu

Klucze API zatwierdzone w GitHubie mogą być zbierane przez boty

Przechowuj klucze w zmiennych środowiskowych; natychmiast wymień skradzione klucze

Przechwycenie typu man-in-the-middle

Klucz API odczytywany podczas nieszyfrowanych połączeń

Zawsze stosuj HTTPS i weryfikuj certyfikaty SSL

Skradziony klucz API używany z infrastruktury atakującego

Atakujący może wysyłać maile, kradnąć dane lub modyfikować szablony

Użyj białej listy IP, aby ograniczyć, które adresy IP mogą korzystać z klucza

Zbyt uprawnione klucze API typu „szwajcarski scyzoryk”

Pojedynczy klucz przyznaje zbyt wiele uprawnień, jeśli zostanie skompromitowany

Twórz wiele kluczy o wąskim zakresie z ograniczonymi uprawnieniami

Integracje zewnętrzne nadużywające wspólnego klucza

Zewnętrzni partnerzy mogą przypadkowo ujawnić lub nadużywać twojego klucza

Generuj dedykowane klucze dla każdego partnera z ograniczonymi adresami IP i uprawnieniami


Kiedy tworzysz klucz API, możesz teraz określić listę adresów IP, które mają prawo do korzystania z tego klucza. Możesz określić kilka adresów IP, a także bloki adresów IP, używając notacji CIDR, aby nie musieć wymieniać swoich serwerów indywidualnie. Gdy klucz API jest używany, dla API REST lub SMTP, dopasujemy łączący adres IP do tej listy, aby zezwolić lub odmówić dostępu.

Dzięki tej funkcji, nawet jeśli twój klucz API zostanie znaleziony lub skradziony, tylko twoje serwery będą mogły z niego korzystać.

Typowe zagrożenia związane z kluczem API i ich ograniczenia

Zagrożenie

Opis

Zalecane ograniczenie

Ekspozycja klucza w publicznych repozytoriach kodu

Klucze API zatwierdzone w GitHubie mogą być zbierane przez boty

Przechowuj klucze w zmiennych środowiskowych; natychmiast wymień skradzione klucze

Przechwycenie typu man-in-the-middle

Klucz API odczytywany podczas nieszyfrowanych połączeń

Zawsze stosuj HTTPS i weryfikuj certyfikaty SSL

Skradziony klucz API używany z infrastruktury atakującego

Atakujący może wysyłać maile, kradnąć dane lub modyfikować szablony

Użyj białej listy IP, aby ograniczyć, które adresy IP mogą korzystać z klucza

Zbyt uprawnione klucze API typu „szwajcarski scyzoryk”

Pojedynczy klucz przyznaje zbyt wiele uprawnień, jeśli zostanie skompromitowany

Twórz wiele kluczy o wąskim zakresie z ograniczonymi uprawnieniami

Integracje zewnętrzne nadużywające wspólnego klucza

Zewnętrzni partnerzy mogą przypadkowo ujawnić lub nadużywać twojego klucza

Generuj dedykowane klucze dla każdego partnera z ograniczonymi adresami IP i uprawnieniami


Kiedy tworzysz klucz API, możesz teraz określić listę adresów IP, które mają prawo do korzystania z tego klucza. Możesz określić kilka adresów IP, a także bloki adresów IP, używając notacji CIDR, aby nie musieć wymieniać swoich serwerów indywidualnie. Gdy klucz API jest używany, dla API REST lub SMTP, dopasujemy łączący adres IP do tej listy, aby zezwolić lub odmówić dostępu.

Dzięki tej funkcji, nawet jeśli twój klucz API zostanie znaleziony lub skradziony, tylko twoje serwery będą mogły z niego korzystać.

Typowe zagrożenia związane z kluczem API i ich ograniczenia

Zagrożenie

Opis

Zalecane ograniczenie

Ekspozycja klucza w publicznych repozytoriach kodu

Klucze API zatwierdzone w GitHubie mogą być zbierane przez boty

Przechowuj klucze w zmiennych środowiskowych; natychmiast wymień skradzione klucze

Przechwycenie typu man-in-the-middle

Klucz API odczytywany podczas nieszyfrowanych połączeń

Zawsze stosuj HTTPS i weryfikuj certyfikaty SSL

Skradziony klucz API używany z infrastruktury atakującego

Atakujący może wysyłać maile, kradnąć dane lub modyfikować szablony

Użyj białej listy IP, aby ograniczyć, które adresy IP mogą korzystać z klucza

Zbyt uprawnione klucze API typu „szwajcarski scyzoryk”

Pojedynczy klucz przyznaje zbyt wiele uprawnień, jeśli zostanie skompromitowany

Twórz wiele kluczy o wąskim zakresie z ograniczonymi uprawnieniami

Integracje zewnętrzne nadużywające wspólnego klucza

Zewnętrzni partnerzy mogą przypadkowo ujawnić lub nadużywać twojego klucza

Generuj dedykowane klucze dla każdego partnera z ograniczonymi adresami IP i uprawnieniami


Ostatnie słowa

Kilka osobistych zaleceń dotyczących bezpieczeństwa:

  • Nie przechowuj swoich kluczy API w kodzie. Jest wiele korzyści z trzymania ich jako zmienne środowiskowe, jak robi to Heroku

  • Możesz stworzyć nieograniczoną liczbę kluczy API, a dla bezpieczeństwa najlepiej jest podzielić odpowiedzialności między kilka kluczy API, zamiast mieć tylko jeden uniwersalny klucz. To również pozwoli Ci mieć różne białe listy IP dla każdego klucza, aby jeszcze lepiej oddzielić różne zagadnienia

  • Jeśli pracujesz z osobami trzecimi, nie udostępniaj swojego klucza API, ale stwórz nowy dla nich, z tylko wymaganymi uprawnieniami, i przypisz go do ich adresów IP

  • Ponieważ klucze API mogą być tworzone tylko przez interfejs użytkownika, włączenie uwierzytelniania dwuetapowego w swoim koncie SparkPost jest koniecznością i zajmuje tylko 2 minuty

Kilka osobistych zaleceń dotyczących bezpieczeństwa:

  • Nie przechowuj swoich kluczy API w kodzie. Jest wiele korzyści z trzymania ich jako zmienne środowiskowe, jak robi to Heroku

  • Możesz stworzyć nieograniczoną liczbę kluczy API, a dla bezpieczeństwa najlepiej jest podzielić odpowiedzialności między kilka kluczy API, zamiast mieć tylko jeden uniwersalny klucz. To również pozwoli Ci mieć różne białe listy IP dla każdego klucza, aby jeszcze lepiej oddzielić różne zagadnienia

  • Jeśli pracujesz z osobami trzecimi, nie udostępniaj swojego klucza API, ale stwórz nowy dla nich, z tylko wymaganymi uprawnieniami, i przypisz go do ich adresów IP

  • Ponieważ klucze API mogą być tworzone tylko przez interfejs użytkownika, włączenie uwierzytelniania dwuetapowego w swoim koncie SparkPost jest koniecznością i zajmuje tylko 2 minuty

Kilka osobistych zaleceń dotyczących bezpieczeństwa:

  • Nie przechowuj swoich kluczy API w kodzie. Jest wiele korzyści z trzymania ich jako zmienne środowiskowe, jak robi to Heroku

  • Możesz stworzyć nieograniczoną liczbę kluczy API, a dla bezpieczeństwa najlepiej jest podzielić odpowiedzialności między kilka kluczy API, zamiast mieć tylko jeden uniwersalny klucz. To również pozwoli Ci mieć różne białe listy IP dla każdego klucza, aby jeszcze lepiej oddzielić różne zagadnienia

  • Jeśli pracujesz z osobami trzecimi, nie udostępniaj swojego klucza API, ale stwórz nowy dla nich, z tylko wymaganymi uprawnieniami, i przypisz go do ich adresów IP

  • Ponieważ klucze API mogą być tworzone tylko przez interfejs użytkownika, włączenie uwierzytelniania dwuetapowego w swoim koncie SparkPost jest koniecznością i zajmuje tylko 2 minuty

Inne wiadomości

Przeczytaj więcej z tej kategorii

A person is standing at a desk while typing on a laptop.

Kompletna platforma oparta na sztucznej inteligencji, która rośnie wraz z Twoim biznesem.

A person is standing at a desk while typing on a laptop.

Kompletna platforma oparta na sztucznej inteligencji, która rośnie wraz z Twoim biznesem.