Zdefiniuj zakresy przed utworzeniem
Przyznaj kluczowi wyłącznie uprawnienia i zasoby wymagane przez jego zadanie. Integracja monitorująca może wymagać dostępu do odczytu; narzędzie wdrożeniowe może wymagać określonego zestawu operacji cyklu życia. W miarę możliwości oddziel uprawnienia rozliczeniowe.
Ujawniaj ostrożnie i przechowuj prywatnie
Prawdziwy klucz powinien być prezentowany przez bezpieczny proces tworzenia, chroniony w spoczynku i wykluczony z URL, pakietów przeglądarki i kontroli źródła. Zapisuj właściciela, cel i czas utworzenia bez ujawniania samego sekretu.
Uczyń odwołanie praktycznym
Wydawaj osobne poświadczenia dla każdej integracji, aby można było odwołać jedno bez zatrzymywania wszystkiego. Rotuj je świadomie i zweryfikuj, że stary klucz już nie działa. Badaj nieoczekiwane użycie za pomocą ograniczonych rekordów audytu.
Przetestuj limity
Przydatny test wdrożenia obejmuje dozwoloną operację, operację zabronioną, wygasły lub unieważniony klucz oraz żądanie poza granicą zasobów klucza. Samo uwierzytelnianie nie jest autoryzacją.
Zasady kluczy kandydujących
Umowa API opisuje do dziesięciu aktywnych kluczy na konto, z nazwanymi celami, opcjonalnym wygaśnięciem i ograniczeniami adresów źródłowych. Zakresy oddzielają odczyt, zarządzanie serwerem, rozliczenia i pełną kontrolę. Proces tworzenia powinien pokazać sekret jednokrotnie i zachować jedynie odpowiednio chronioną reprezentację weryfikacyjną.
Audytuj bez ujawniania żądania
Użyteczny zapis audytu może zawierać identyfikator klucza, trasę, czas i wynik bez przechowywania haseł lub całych treści żądań. Dostęp do zapisu nadal wymaga ochrony. Zdefiniuj retencję i eksport zamiast przechowywać wrażliwą historię operacyjną bezterminowo.
Nadaj każdej automatyzacji własne poświadczenia
Narzędzie sprawdzające kopie zapasowe, proces wdrożeniowy i integracja rozliczeniowa nie powinny współdzielić tego samego klucza pełnego dostępu. Nazwij klucz według jego zadania, przyznaj najmniejszy zakres i zapisz, kto jest jego właścicielem. Zamierzone grupy to odczyt, serwery, rozliczenia i pełny; ich dokładne mapowanie operacji musi zostać przetestowane, gdy API stanie się dostępny.
Tworzenie, przechowywanie i rotacja
Proponowany model konta pozwala na do dziesięciu aktywnych kluczy. Pokaż nowy sekret jednokrotnie, a następnie zachowaj jedynie weryfikator po stronie serwera potrzebny do jego uwierzytelnienia. Przechowuj kopię klienta w menedżerze sekretów lub chronionym środowisku usługi. Rotuj, wprowadzając zamiennik, sprawdzając zależnego pracownika, a następnie odwołując stary klucz; nigdy nie umieszczaj klucza w publicznym URL ani pakiecie przeglądarki.
Odwołaj dostęp, nie dowody
Wyłączenie klucza powinno zatrzymać przyszłe żądania, zachowując ograniczony zapis bezpieczeństwa jego wcześniejszego użycia. Jeśli dane uwierzytelniające mogły wyciec, unieważnij je niezwłocznie, zbadaj dotknięte zasoby i zastąp powiązane sekrety. Lista kluczy powinna pokazywać bezpieczny identyfikator i metadane ostatniego użycia, a nie odzyskiwalne sekrety w postaci jawnej.
Trochę więcej jasności.
Czy ta strona może utworzyć działający klucz API?
Nie. Tworzenie kluczy wymaga uwierzytelnionego backendu konta; ta strona informacyjna nie wydaje poświadczeń.