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?
Odpowiedzi:
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.
źródło
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.
źródło
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 ...
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło