W jaki sposób należy obsługiwać tajne wartości w projekcie w kontroli źródła?

Question

Moje pytanie jest zasadniczo takie samo jak this one, ale dla aplikacji Windows Store, C# i Visual Studio. Chcę mieć łatwy sposób na zachowanie tajnych wartości w projekcie, w pliku, który można zignorować w kontrolce źródła (niezaznaczonej). W jaki sposób powinienem uporządkować swój projekt, aby przechowywać sekret aplikacji w sposób ułatwiający sterowanie budynkiem/źródłem?

Mój pierwszy pomysł polegał na zapisaniu go w pliku XML (niezaznaczonym) i załadowaniu go w środowisku wykonawczym, ale pozostawia to użytkownikowi, który je instaluje, więc powinien być wykonany w czasie kompilacji. Jak mogę przechowywać kilka tajnych wartości i czy studio graficzne zastąpi je w moim kodzie, gdy mój projekt zostanie zbudowany?

Answer 1

W mojej firmie decydujemy się na rozwiązanie. W pliku konfiguracyjnym łączymy sekcje z "tajnymi" wartościami w zewnętrznych konfiguracjach. Zewnętrzne konfiguracje są kontrolowane przez źródło. Po pierwsze nie było, ale po problemie, gdy nasz serwer kompilacji zgubił dysk, zdecydowaliśmy, że bezpieczniej jest go przechowywać w miejscu, które ma kopię zapasową. Folder w kontroli źródła (może być również na serwerze plików) jest naprawdę ograniczony do odczytu i zapisu tylko dla osób, które tego potrzebują. Buduj konto procesu "folder projektu" plus folder "konfiguracja" i buduj. Po zakończeniu kompilacji folder "konfiguracja" zostaje usunięty. Dostęp do serwera kompilacji jest również ograniczony.

Answer 2

Jedną z opcji jest przechowywanie sekretów w kontroli kodu źródłowego, ale zapisywanie ich w postaci zaszyfrowanej. W środowisku programistycznym lub kompilacji użyj zmiennej środowiskowej do przechowywania klucza i odszyfrowywania w locie. W ten sposób uzyskasz korzyści z kontroli źródła, zachowując bezpieczeństwo informacji.

Jest to możliwe, nawet jeśli używasz app.config lub web.config, po prostu musisz zmodyfikować konfigurację z kodu przy starcie.

Erick

Answer 3

Updated
Jeśli umieścisz w tajemnicy w niezaufanym obszarze (np kontroli źródła publiczne), jest zagrożone. Nawet jeśli jest zaszyfrowany, z dostateczną starannością można go odzyskać.

Jedynym sposobem na utrzymanie go poza zasięgiem jest posiadanie usługi zewnętrznej, która współdziała z interfejsem API innej firmy. Ma to swoje własne kompromisy (np. Uwierzytelnienie użytkownika, o którym wspomniałeś w komentarzach). Zwłaszcza jeśli programiści muszą korzystać z interfejsu API strony trzeciej podczas testowania, nie widzę innej alternatywy, która ograniczy ekspozycję tajemnicy.

Answer 4

Utwórz nowy plik klasy w projekcie, który ma gniazda dla wszystkich tajnych wartości i przechowuje wartości pozorowane/testowe dla wszystkich z nich. Sprawdź to w kontrolerze źródłowym wraz z resztą projektu, aby ktokolwiek budując go bez dostępu do sekretów dostał jakąś wersję testową.

Następnie utwórz kopię tego pliku klasy z prawdziwymi tajnymi wartościami i umieść go poza kontrolą źródła. Napisz skrypt wsadowy w zdarzeniu pre-build, które szuka tego pliku klasy, a jeśli go znajdziesz, zastępuje go plikiem dummy zawartym w projekcie.

W ten sposób Twój projekt może nadal być w kontroli źródła i każdy może go sprawdzić, zbudować i uruchomić w trybie testowym. Twoje tajne pliki/wartości są przechowywane tylko na serwerze budowania, więc tylko podczas budowania projektu będą miały prawdziwe wartości.

Pamiętaj, aby gdzieś utworzyć kopię zapasową pliku tajnego. Pamiętaj też, że kod .NET może być łatwo dekompilowany, więc twoje sekrety mogą nie być tak tajne, jak ci się wydaje - każdy użytkownik z reflektorem .NET może zobaczyć cały kod w zespole zwalniającym, w tym tajną klasę.