Jak zabezpieczyć klucze API OpenAI krok po kroku. Wygasanie i kontrola tworzenia

Problem: klucze API OpenAI bez terminu ważności

Klucz API bez daty wygaśnięcia działa, dopóki ktoś go nie unieważni. Jeśli trafi do repozytorium, logów albo pliku przekazanego podwykonawcy, może być używany miesiącami, a koszty zapytań obciążają konto organizacji. Nowe ustawienia OpenAI ograniczają ten czas i dają administratorom kontrolę nad tym, kto może tworzyć klucze.

OpenAI w przewodniku po dobrych praktykach produkcyjnych zdecydowanie zaleca ustawianie daty wygaśnięcia przy tworzeniu klucza projektowego oraz regularną rotację. Zmiany wprowadzano w dwóch etapach: 10 września 2026 roku wygasanie kluczy, a 15 września zasady ich tworzenia.

Przygotowanie przed zmianą ustawień

Zanim administrator włączy limity, powinien wiedzieć, które klucze są w użyciu i gdzie. Nowe zasady nie wyłączą starych kluczy, ale kolejne klucze będą już podlegać limitom, więc zespoły muszą znać nowy sposób pracy.

Według dokumentacji śledzenie użycia jest domyślnie włączone dla kluczy utworzonych po 20 grudnia 2023 roku. Dla starszych kluczy trzeba je włączyć ręcznie na stronie zarządzania kluczami, co ułatwia ustalenie, które klucze są jeszcze aktywne.

• Lista projektów i właścicieli kluczy w organizacji.
• Wykaz aplikacji, skryptów i potoków CI/CD korzystających z API OpenAI.
• Decyzja, które integracje mają działać na kontach serwisowych, a które na kluczach użytkowników.
• Miejsce przechowywania sekretów, np. menedżer sekretów lub zmienne środowiskowe.

Wygasanie kluczy API OpenAI krok po kroku

Poniższe kroki opierają się na changelogu OpenAI i przewodniku po dobrych praktykach produkcyjnych. Dokumentacja podaje, że ustawienia znajdują się w Platform settings, ale nie opisuje dokładnej ścieżki menu.

1. Ustaw w Platform settings maksymalny czas życia kluczy API na poziomie organizacji.
2. Jeśli projekt wymaga ostrzejszych zasad, ustaw krótszy limit dla projektu. Nie może on przekraczać limitu organizacji.
3. W sekcji API Key Governance wybierz typy kluczy, które wolno tworzyć: tylko konta serwisowe, tylko klucze użytkowników w projekcie albo blokadę tworzenia nowych kluczy.
4. Przy tworzeniu każdego nowego klucza projektowego ustaw datę wygaśnięcia mieszczącą się w limicie.
5. Przed wygaśnięciem klucza utwórz klucz zastępczy i wdróż go w aplikacjach.
6. Sprawdź, czy aplikacje działają na nowym kluczu, a dopiero potem unieważnij stary.

Które ustawienie wybrać

API Key Governance oferuje trzy warianty i każdy pasuje do innej organizacji. Wybór zależy od tego, czy integracje należą do konkretnych osób, czy do systemów firmy. Poniższe zestawienie to ocena redakcji dailyAI oparta na opisie funkcji w dokumentacji OpenAI.

Ustawienia można różnicować między projektami, ale limit czasu życia projektu nie może być dłuższy niż limit organizacji. Dlatego limit organizacji warto traktować jako górną granicę, a ostrzejsze zasady ustawiać w projektach z wrażliwymi danymi.

• Tylko konta serwisowe - dla firm, w których API obsługuje aplikacje produkcyjne i potoki CI/CD, a dostęp nie powinien zależeć od kont pracowników.
• Tylko klucze użytkowników w projekcie - dla zespołów badawczych i prototypów, gdzie liczy się przypisanie użycia do konkretnej osoby.
• Blokada tworzenia nowych kluczy - na czas audytu, po incydencie albo w projektach, które mają już komplet kluczy i nie powinny się rozrastać.

Przykład: rotacja w polskim software house

Firma z Katowic obsługuje pięć projektów klientów, każdy w osobnym projekcie OpenAI. Administrator ustawia dla organizacji limit czasu życia kluczy, a dla projektu z danymi klienta z sektora finansowego krótszy limit projektowy. W API Key Governance dopuszcza tylko klucze kont serwisowych, żeby dostęp nie zależał od kont pracowników.

Zespół zapisuje daty wygaśnięcia w kalendarzu wydań. Na kilka dni przed terminem tworzy nowy klucz, podmienia go w menedżerze sekretów, obserwuje ruch i unieważnia stary klucz. Odejście pracownika nie wymaga wtedy szukania kluczy przypisanych do jego konta.

Typowe błędy administratorów

Najczęstsze problemy wynikają z wdrożenia limitów bez planu rotacji. Wygaśnięcie klucza w działającej aplikacji wygląda dla użytkownika jak awaria usługi.

• Założenie, że nowe limity obejmą stare klucze. Dokumentacja wprost podaje, że istniejące klucze nie są objęte zmianą.
• Unieważnienie starego klucza przed sprawdzeniem, że nowy działa we wszystkich środowiskach.
• Całkowita blokada tworzenia kluczy bez procedury wyjątku dla pilnych wdrożeń.
• Klucze zapisane w kodzie, repozytorium lub aplikacji po stronie przeglądarki zamiast w zmiennych środowiskowych.
• Jeden wspólny klucz dla wielu projektów, który utrudnia śledzenie kosztów i szybkie odcięcie dostępu.

Koszt, bezpieczeństwo i podsumowanie

Changelog i dokumentacja, które sprawdziliśmy, nie wspominają o dodatkowych opłatach za wygasanie kluczy ani za zasady ich tworzenia. Realnym kosztem jest czas zespołu na rotację i ryzyko przestoju, jeśli klucz wygaśnie niezauważony.

W ocenie redakcji dailyAI wygasanie kluczy najbardziej pomaga firmom korzystającym z agentów i automatyzacji, gdzie jeden klucz obsługuje wiele narzędzi. Dla polskich firm ma to też znaczenie przy RODO: krótszy czas życia klucza zmniejsza skutki wycieku, choć źródła OpenAI nie odnoszą się do tego wprost. Warto połączyć nowe ustawienia z kontrolą historii bezpieczeństwa kont zespołu.

Wygasanie kluczy i API Key Governance to dwa proste ustawienia, które porządkują dostęp do API OpenAI. Najpierw inwentaryzacja i plan rotacji, potem limity organizacji i projektów, a na końcu zasady tworzenia kluczy.

Stare klucze bez daty wygaśnięcia nadal działają, więc samo włączenie limitów nie wystarczy. Po wdrożeniu nowych zasad trzeba stopniowo zastąpić dotychczasowe klucze nowymi, z terminem ważności.