Najlepszy sposób na ukrycie klucza API w kodzie źródłowym

Potrzebuję pomysłów na ochronę prywatnego klucza API w aplikacji, szczególnie w aplikacji ac # .NET.

Po pierwsze, rozumiem, że teoretycznie niemożliwe jest ukrycie czegokolwiek w kodzie źródłowym, więc wpadłem na inny pomysł, ale nie jestem pewien, czy jest to prawdopodobne. W każdym razie, czy da się w jakiś sposób skomunikować z serwerem internetowym w celu zweryfikowania klucza prywatnego, a następnie oddzwonić do aplikacji, aby potwierdzić, że jest to uzasadniony uścisk dłoni?

Mam dwa klucze do pracy: klucz publiczny (jak sama nazwa wskazuje, nie musi być traktowany z taką samą ostrożnością jak prywatny) i klucz prywatny, który należy chronić przed innymi.

Wszelkie pomysły dotyczące tego, jak to zrobić, byłyby bardzo mile widziane.

Podsumowując:

• Masz klucz API wydany przez dostawcę, abyś mógł korzystać z jego interfejsu API, a także masz obowiązek zapobiegać znajomości tego klucza przez kogokolwiek innego
• Wywołujesz połączenia z interfejsem API tego dostawcy (który wymaga klucza API) w kodzie aplikacji
• Wdrażasz aplikację w systemach, w których klienci mają dostęp do plików binarnych, a zatem może potencjalnie zdekompilować / odszyfrować kod lub przechwycić ruch

Najlepszym sposobem na uniknięcie kompromisu tego klucza jest utrzymanie nad nim kontroli. Oznacza to, że nigdy nie należy go wdrażać na serwerze, na którym ktokolwiek poza tobą może czytać pliki binarne i nigdy nie przechodzić przez łącze komunikacyjne, którego nie kontrolujesz.

Ostatecznie, jeśli pliki binarne są poza twoją kontrolą, wszystko w nich jest poza twoją kontrolą. Podobnie, jeśli ktoś może przechwycić ruch, może przechwycić klucz API ( potencjalnie nawet jeśli używasz SSL ).

Widzę dwa podstawowe sposoby osiągnięcia tego celu, które nie obejmują twojego prywatnego klucza API we wdrożonej aplikacji:

Uzyskaj unikalny klucz API dla każdego wdrożenia

Wymagałoby to dodatkowej relacji z dostawcą, gdzie można uzyskać klucze lub poprosić klientów o uzyskanie kluczy.

Jest to w rzeczywistości dość powszechne na przykład w produktach korzystających z interfejsu API Map Google. Twórca oprogramowania ma własny klucz, którego używają podczas opracowywania / uruchamiania kopii, ale nie włączają go do oprogramowania, a zamiast tego wymagają, aby użytkownik instalujący wspomniane oprogramowanie udał się do Google i uzyskał własny interfejs API klucz. Oprogramowanie ma jedynie opcję konfiguracji umożliwiającą użycie klucza API Map Google.

W rzeczywistości wielu dostawców, którzy wydają klucze API zgodnie z umową, wymaga tego, abyś robił to w ten sposób, więc i tak możesz znaleźć się na złej ścieżce, i może to być jedyne rozwiązanie, którego możesz użyć zgodnie z Warunkami świadczenia usług dostawcy i / lub wszelkie umowy prawne, które możesz z nimi zawrzeć.

Użyj proxy

Skonfiguruj interfejs API serwera proxy, w którym aplikacja wywołuje interfejs API (na serwerach), a z kolei interfejs API wywołuje interfejs API dostawcy przy użyciu klucza.

Możesz potrzebować dodatkowej ochrony interfejsu API, np. Aby upewnić się, że używa go tylko Twoja aplikacja. Można to zrobić przez:

• dzięki czemu funkcjonalność jest tak specyficzna, że ​​tylko aplikacja może z niej korzystać
• Białe listy IP
• Niektóre istniejące mechanizmy licencjonowania / autoryzacji, które już masz dla swoich serwerów
• Twój własny system kluczy API, w którym możesz wydawać klucze swoim klientom

Należy pamiętać, że możesz nie mieć takiej możliwości. Twój sprzedawca może mieć Warunki świadczenia usług lub umowy prawne, które uniemożliwiają Ci zbudowanie „usługi agregacji” lub serwera proxy, więc musisz to sprawdzić.

Postępowanie w przypadku niewłaściwego zachowania

Nawet jeśli twój klucz nie zostanie naruszony, jeśli jeden z twoich klientów robi coś, co powoduje, że sprzedawca blokuje klucz, nagle WSZYSCY klienci zostają wyłączeni, a jedyną poprawką jest aktualizacja wszystkich innych.

Podobnie, jeśli ty chcesz zablokować jednego ze swoich klientów (np przestali płacić, mają pirackie oprogramowanie, itp) to nie można zrobić bez wydawania aktualizacji do każdego innego, a następnie wyłączyć klucz.

Logistyka tego wszystkiego poza garstką klientów szybko stanie się nie do utrzymania.

Niezależnie od tego, czy działasz jako serwer proxy, czy masz unikalny klucz dla każdej instalacji, możesz poradzić sobie z dowolną z tych sytuacji stosunkowo łatwo (i bez wpływu na nikogo innego).

Próba ochrony klucza, gdy jest on wbudowany w oprogramowanie, jest ostatecznie daremnym wysiłkiem. Bez względu na to, co robisz, każdy atakujący, który ma dostęp do plików binarnych, źródła i / lub kanału komunikacyjnego i jest wystarczająco zdeterminowany, aby uzyskać klucz, będzie mógł to zrobić.

Więc nie osadzaj tego. „Jedynym zwycięskim ruchem jest nie grać”.

Jeśli masz klucz w kodzie obiektowym, jest on z definicji publiczny. Wokół obfuscatorów są włamania, które szybko dekompilują kod obiektowy. Klucz prywatny znajdowałby się poza kodem obiektowym i w innym pliku. Trudność polega na udostępnieniu tego klucza prywatnego użytkownikowi. Po dostarczeniu można użyć podpisu klucza prywatnego, przyczepionego na końcu pliku oraz klucza publicznego w aplikacji, aby zweryfikować integralność klucza prywatnego. Serwer internetowy może również przeprowadzić tę weryfikację, jeśli masz bezpieczny kanał komunikacji.