Jak mogę zniechęcić do udostępniania wewnętrznych kluczy API w firmie?

37

Pracujemy nad nową usługą - ta usługa będzie potencjalnie wywoływana bezpośrednio z aplikacji na urządzeniach użytkowników. Aplikacje te będą opracowywane i obsługiwane przez wiele zespołów programistycznych z całej organizacji, wszystko w zależności od dostarczanych danych.

Chcemy określić, które aplikacje wysyłają które żądania, abyśmy mogli zidentyfikować wzorce użytkowania i odpowiedzialnych programistów. (Aby uniknąć wątpliwości, uwierzytelnianie użytkownika jest obsługiwane osobno).

Nasze rozwiązanie wymaga kluczy API, po jednym na aplikację - wtedy mamy dane kontaktowe do zespołu programistów.

Nie chcemy, aby klucze API były źródłem tarć, ale obawiamy się, że programiści udostępnią je kolegom z innych zespołów, co oznacza, że ​​nie będziemy już w stanie zidentyfikować ruchu tylko dla jednej aplikacji.

Jak możemy zachęcić programistów do nieudostępniania kluczy API wewnętrznie?

Oli
źródło
5
W jaki sposób te zespoły uzyskają dostęp do interfejsu API? Przez sieć wewnętrzną? Zasadniczo różne zespoły są umieszczane w różnych podsieciach, abyś mógł wymusić użycie określonego klucza API przez sieć ... W każdym razie rozwiązaniem społecznościowym jest powiedzenie im: „ważne jest, aby nie udostępniać tego klucza API nie ze względów bezpieczeństwa, ale ponieważ potrzebujemy wskaźników różnych użytkowników, aby go ulepszyć. Jeśli ktoś poprosi, po prostu powiedz mu, aby nas zapytał, a my z przyjemnością i skutecznie dostarczymy mu klucz API ”.
Giacomo Alzetta
3
Jeśli nie chcesz, aby inni współużytkowali klucze z kolegami, ułatw dołączenie pliku konfiguracyjnego, który jest ignorowany przez system kontroli wersji (aby klucz nigdy nie był zatwierdzany), a także ułatwiaj tworzenie nowych kluczy. Nikt nie będzie kłopotał się udostępnianiem tajnego klucza, jeśli inny programista może łatwo samodzielnie utworzyć nowy klucz. Problem z udostępnianiem kluczy osobistych jest zwykle problemem spowodowanym tym, że zdobywanie nowych kluczy wymaga czasu.
Sulthan
Czy rozważałeś potrzebę rejestracji przy pierwszym uruchomieniu aplikacji? Może wyświetlić ekran powitalny z pytaniem o dane kontaktowe użytkownika (lub dowolne potrzebne informacje), a następnie wydać klucz API na miejscu.
John Wu
„Jak możemy zachęcić programistów do nieudostępniania kluczy API wewnętrznie?” Mówiąc prosto, powiązaj każdy klucz z adresem MAC karty (kart) sieciowej w komputerach, które je obsługują. Protokoły sieciowe zapobiegają używaniu tych samych adresów MAC w tej samej sieci, dzięki czemu ludzie nie mogą używać tych samych kluczy w kółko. Uczyniłbym to odpowiedzią, ale obecnie nie mam jej przedstawiciela.
Blerg
Co ciekawe, w tej chwili nie widzę nigdzie słowa „rotacja” (jak w rotacji klawiszy - wygaśnięcie / rotacja poświadczeń). Kiedy ktoś zdobędzie klucz, czy ma on skończony okres użytkowania, po którym musi zostać wycofany z użycia i zastąpiony nowym? Jeśli nie, dlaczego nie?
Michael - sqlbot

Odpowiedzi:

76

Aby udostępnić te klucze między zespołami, zespoły muszą ze sobą rozmawiać, zgodzić się na udostępnienie, a następnie udostępnić je. To wymaga czasu. Jeśli więc zespół może prosić o klucze API szybciej i łatwiej, nie ma motywacji do udostępniania.

A najłatwiejszym sposobem zażądania tych kluczy jest uprzedzenie ich. Zakładając, że znasz wszystkie inne zespoły, które będą potrzebować kluczy API, utwórz je i udostępnij przed udostępnieniem im usługi.

Jest jeszcze jedna zachęta, którą możesz zaoferować: wsparcie debugowania. Zespoły te będą potrzebować Twojej pomocy, gdy coś nie będzie działać poprawnie, gdy zintegrują swoją pracę z Twoją usługą. Te klucze API umożliwiają śledzenie ich konkretnych żądań, a tym samym pomagają w debugowaniu tego, co się dzieje. Więc sprzedaj to jako przyczynę kluczy, zamiast „ identyfikuj wzorce użytkowania i odpowiedzialni programiści ”, co brzmi, jakbyś szpiegował ich działania.

David Arno
źródło
2
Re: dzielenie się, w idealnym świecie masz rację - ale zakładasz, że mają doskonałe informacje (chociaż mogę pomóc, kierując ich do dokumentów ze schematu, katalogu głównego punktu końcowego i wszelkich błędów) oraz zarządzania współpracą, a także nie rzeczywistość, w której wszystko, co mogą mieć, to punkt końcowy i jakiś kod skopiowany z innego zespołu, który został przekazany przez kierownika wyższego szczebla.
Oli
3
Re: uprzedzając, masz absolutną rację, powinniśmy agresywnie tworzyć i wysyłać klucze do zainteresowanych stron. Nie wspomniałem o tym, że niektóre z tych aplikacji używają wspólnego frameworka / interfejsu i być może moglibyśmy półautomatycznie wstrzykiwać lub egzekwować unikalne klucze na tej warstwie, ale nie dotyczy to wszystkich aplikacji.
Oli
1
@Ewan, jeśli po prostu wyłączysz dostęp do danego klucza, wszyscy użytkownicy będą do Ciebie biegać - nie musisz ich ścigać. A potem możesz dać im unikalne klucze :)
Aleksiej Lewenkow
15
Wstępne opróżnianie powinno mieć następującą postać: dostęp do interfejsu API bez klucza powoduje wyświetlenie komunikatu o błędzie z linkiem do strony, na której aplikujesz o klucz. Nie oczekuj, że ktokolwiek przeczyta dokumentację. Zachęty nie działają, gdy nikt o nich nie wie.
candied_orange
1
Jeśli komunikaty o błędach lub dzienniki debugowania były automatycznie wysyłane pocztą e-mail na adres powiązany z kluczem, każdy, kto chciałby mieć dane, miałby motywację do korzystania z własnego klucza - a każdy, kto udostępnił klucz, miałby motywację do wyśledzenia osoby, która go udostępniła i każ im przestać.
Robin Bennett
20

Dobre odpowiedzi już, pomyślałem tylko o innym podejściu, które może, ale nie musi, działać dla ciebie.

Zamiast wydawać klucze, które mają być dołączone, możesz wymagać, aby nagłówek żądań zawierał nazwę aplikacji frontonu, która zostanie utworzona i sformatowana przez programistę aplikacji frontonu, tak jak robią to przeglądarki internetowe. W ten sposób interfejsy mogą nadal udawać inną aplikację, ale nie przyniosłoby to korzyści, więc wydaje się to mało prawdopodobne. Po prostu pozwól, aby interfejs sam się zidentyfikował i zaakceptował niepusty łańcuch.

Martin Maat
źródło
Utrudniłoby to życie, gdyby zmieniła się własność aplikacji - na przykład moglibyśmy po prostu zaktualizować szczegóły klucza API przechowywane na naszym końcu, ale jeśli zaakceptujemy dowolny tekst, który wymaga zmiany kodu w aplikacji.
Oli
1
@Oli Jeśli własność aplikacji ulegnie zmianie, a (nowy) programista uzna za stosowną aktualizację tożsamości aplikacji (którą tak naprawdę ma, ponieważ ktoś inny ją utrzymuje), jaki byłby problem? Możesz rozróżnić między zmianą przed i po zmianie własności, po prostu traktuj je jako dwie różne aplikacje. Nie spodziewałbym się jednak, że jakikolwiek nowy właściciel zauważy wkrótce nazwę w nagłówku.
Martin Maat
3
Tym się właśnie zajmuję. niech klient ma parametr konstrukcyjny, który jest nazwą aplikacji i / lub użyj refleksji, aby pobrać inne rzeczy, takie jak maszyna, na której działa, jej wersja itp. Kluczową sprawą jest umożliwienie Ci zgłaszania, kiedy ludzie NIE podążają za twoim API polityka
Ewan
1
Jeśli organizacja ma wspólne podejście do kontroli wersji, np. Wszyscy przechowują kod na serwerze GitHub organizacji, każda aplikacja wysyła adres URL do repozytorium i skrót zatwierdzenia, z którego został zbudowany. Skrót zatwierdzenia może być zawarty w kodzie jako część procesu kompilacji, więc programiści nie muszą niczego aktualizować. Posiadanie adresu URL repozytorium pozwala zobaczyć, kto jest właścicielem, a uzyskanie określonych zatwierdzeń pozwoli zauważyć różnice w zachowaniu między wersjami.
Caleb
@Caleb Gdyby takie rzeczy były scentralizowane, OP prawdopodobnie nie miałby tego problemu. Z tego, co rozumiem, twórcy aplikacji front-end są anonimowi do OP, z prywatnymi sposobami tworzenia oprogramowania.
Martin Maat
16

W skrócie:

Po pierwsze: ułatwienia i świadczenia; W razie potrzeby: tarcie i policja.

Więcej słów

Ułatwienie : Po pierwsze, ułatw zespołowi zdobycie nowego klucza API. Na przykład dodaj przypomnienie w procedurach korporacyjnych dotyczących uruchamiania nowych projektów i zaoferuj łatwą w użyciu usługę, aby poprosić o nowe klucze, bez pytania o uzasadnienie.

Korzyści : Spraw, aby korzystanie z własnego klucza API było korzyścią dla zespołu lub właściciela produktu. Na przykład zaproponuj opinie na temat korzystania z aplikacji na podstawie tego klucza.

Tarcie : w zależności od kluczowej funkcji możesz tworzyć tarcie, na przykład jeśli klucz jest powiązany z domeną zdefiniowaną przez aplikację somme (tzn. Ponowne użycie kluczy niekoniecznie zapewni dostęp do wszystkich pożądanych usług).

Kontrola : Wreszcie, może być konieczne przewidzenie pewnych środków policyjnych. Na przykład, możesz monitorować użycie funkcji API po kluczu API i po określonym czasie, aby ustalić linię bazową, zapytaj o użycie części interfejsu API, które nie jest oczekiwane ze względu na linię bazową. Lub jeśli nie jest to realistyczne, wystarczy dołączyć do list kontrolnych przeglądu projektu firmy, czy użyto prawidłowego klucza.

Uwaga : być może będziesz musiał bardzo jasno określić zasady dotyczące kluczy API: Czy nowa wersja główna wymaga własnego klucza API? Co z widelcem lub jeśli aplikacja jest podzielona? co jeśli inny zespół jest odpowiedzialny, itp ...

Christophe
źródło
6

Zasadniczo najprostszym sposobem, aby zachęcić programistów do „robienia właściwych rzeczy”, jest ułatwienie im tego.

W tym celu sugerowałbym zbudowanie strony / strony wydającej klucz API. W najprostszej formie może to być tylko login (najlepiej powiązany z korporacyjnym AD / LDAP) i strona, która prosi tylko o nazwę aplikacji i wydaje klucz.

Na koniec dnia możesz zawsze odwołać klucze później, więc wszystko, co naprawdę musisz zrobić, to zarejestrować, kto (nazwa użytkownika) poprosił o klucz i co (nazwa aplikacji) chcą z nim zrobić - wraz z wszelkimi informacjami potrzebnymi do unieważnij klucz później.

Możesz zrobić coś podobnego z systemem biletowym, ale pod koniec dnia bardzo łatwo jest mi skopiować i wkleić klucz z jednej aplikacji do drugiej, więc bardzo łatwo jest poprosić o nowy klucz, aby uniknąć złego zachowanie.

DavidT
źródło
1

Bądź proaktywny.

Zidentyfikuj prawdopodobnych programistów i DAJ im unikatowe klucze API w bezpiecznym kanale z wyprzedzeniem. Zapewniają łatwy sposób żądania nowych kluczy API. Zapewnij łatwy sposób nowym osobom żądającym nowych kluczy API. Gdy nowi stażyści lub pracownicy dołączą do zespołu, daj im bilet JIRA lub podobny komunikat „Poproś o klucz API”, wykonując czynności opisane w opisie.

Śledź, które klucze API zostały użyte, a które nie. Jeśli Bob przesłał bilety w projekcie, ale nie używał swoich kluczy API, prawdopodobnie pożyczył cudzy.

Mieć wsparcie kierownictwa. Nie bądź wścibską Nancy, która wymyśla zasady, które nie mają znaczenia. Dosłownie przekonaj kierownictwo, że to ważne, a potem to oni przekonają grupę, że jest ważna. Nie pracuj nad przekonaniem wszystkich.

I najbardziej denerwująca i podatna na tyranię sugestia: bądź świadomy niewłaściwego użycia i rozpraw się tego samego dnia. Najlepsza jest ta sama godzina. Nie mów „Bad Naughty Developer” powiedz „Oto właściwe kroki”. Jeśli robią to wielokrotnie, wyłącz niewłaściwie używany klucz. Jest to kłopotliwe zarówno dla Akcjonariusza, jak i dla Tego, który pożyczył, a akcjonariusz powie w przyszłości „Nie, rób to poprawnie”. Unikaj wyłączania kluczy w projektach na żywo.

Christopher Hostage
źródło
1

Jak możemy zachęcić programistów do nieudostępniania kluczy API wewnętrznie?

  • Generuj klucze w wyniku samoobsługowej rejestracji aplikacji .
  • Wymagaj punktu kontaktowego, zanim klucze staną się aktywne.
  • I poproś ich, aby się nie dzielili. (Tworzenie warunków korzystania z usług i / lub im powiedzieć, dlaczego lepiej jest dla nich nie do udziału).

Powinieneś również wdrożyć ograniczenie stawek . To samo w sobie może zniechęcić do dzielenia się kluczami. W pewnym stopniu chroni Twój system przed niewłaściwymi aplikacjami. (I wręcz złośliwe.) I, zapewnia to, że będziesz nieco informowany przed ogromnym wzrostem ruchu serwisowalnego. (Mam nadzieję, że zyskasz czas na zwiększenie pojemności!)

A przy ograniczeniu prędkości, gdy aplikacja wymaga wyższego limitu, otwiera okno dialogowe z zarejestrowanym POC dla klucza. Otrzymasz okazję, aby zapytać, czy klucze są udostępniane, wyjaśnić, dlaczego jest to szkodliwe i tak dalej, i możesz zaoferować dodatkowe klucze, gdy jest to właściwe, zamiast żądanych zmian limitu prędkości. Itp.

svidgen
źródło
0

Jednym ze sposobów robienia rzeczy, zwłaszcza jeśli zespoły korzystają ze wspólnego systemu kompilacji (lub przynajmniej wystarczająco powszechnego), jest skonfigurowanie wewnętrznego serwera, który tworzy i wydaje klucze API (biorąc pod uwagę kilka podstawowych informacji o produkcie, który go używa) ). Następnie użyj skryptu, który pobiera nowy klucz API z serwera dla każdej kompilacji lub każdej aktualizacji wersji. Pozwól programistom uruchomić skrypt, aby uzyskać także inny klucz do ich lokalnych wersji. (Tam, gdzie to możliwe, zautomatyzuj to jako część kompilacji, aby nawet nie musieli o tym myśleć.)

To pozwoli ci powiedzieć, czy było to coś w produkcji, QA, czy w dev, i przy jakiej wersji / kompilacji zaczęły się problemy.

Miral
źródło
0

Pierwszą i najlepszą rzeczą, jaką możesz zrobić, to sformatować klucze, tak aby zawierały nazwę aplikacji w czytelnej formie i nie działały, jeśli ją zmienisz.

Jeśli to oczywiste, że drużyny używają niewłaściwego klucza, starają się tego nie robić.

Następnie okresowo wygasają klucze. Należy to zrobić w każdym razie , a gdy klucz jest bliski wygaśnięcia można wysłać nowego do zespołu, który jest jej właścicielem. Zespół, który korzysta z klucza, zostanie następnie zmotywowany do upewnienia się, że jest to zespół, który jest jego właścicielem, tak że otrzyma nowy po wygaśnięciu.

Matt Timmermans
źródło
1
w praktyce jednak wygasające klucze mogą stanowić zbyt dużą przeszkodę dla aplikacji - widzę, że menedżerowie mówią „fuggetaboutit”, ponieważ później będą to kłopoty.
davidbak