Tajemnice, takie jak klucze szyfrowania i dane uwierzytelniające, nie powinny być sprawdzane pod kontrolą źródła z kilku powodów. Pierwszy polega oczywiście na tym, że klucze szyfrujące i dane uwierzytelniające powinny zawsze opierać się na wiedzy, a kontrola źródła nie jest niezawodnym sposobem ochrony informacji przed ujawnieniem. Innym powodem, dla którego nie chcesz mieć takich sekretów w kontroli źródła, jest zazwyczaj to, że są one zazwyczaj (ale nie zawsze) specyficzne dla określonego atrybutu środowiska, w którym będzie działać Twoja aplikacja. (Np. Pozyskanie klucza prywatnego w celu utworzenia cyfrowego podpis wymagany do autoryzacji usługi internetowej, określony punkt końcowy tej usługi internetowej może być uruchomiony w środowisku kontroli jakości wymagającej podpisu kontroli jakości).
Prawidłowym sposobem traktowania środowiskowego (lub globalnego sekretu) jest traktowanie go tak, jak każdego innego atrybutu konfiguracji środowiskowej, z dodatkowymi kontrolami bezpieczeństwa dla lepszej oceny. Dobrze zaprojektowany, niezależny i umożliwiający aktualizację moduł kodu powinien być identyczny we wszystkich środowiskach, tak aby środowisko, w którym są one wdrażane, informowało aplikację o jego atrybutach (np. Szczegóły połączenia z bazą danych, poświadczenia, punkty końcowe usług sieciowych, ścieżki plików itp.) Teraz szczegóły konfiguracji istotne dla twojej aplikacji są uzewnętrzniane i stają się parametrami konfiguracyjnymi twojego środowiska.
Teraz, aby rozwiązać niektóre z twoich argumentów:
Ogólnie rzecz biorąc, czy nie po prostu przenosimy problem?
Nie ma czegoś takiego jak doskonałe bezpieczeństwo, jednak „przeniesienie” problemu do obszaru, w którym można zastosować dodatkowe środki i kontrole, poprawi trudność i zmniejszy prawdopodobieństwo przypadkowego lub złośliwego ujawnienia tajemnic. Dobrą zasadą, której należy przestrzegać przy projektowaniu systemu, w którym poufne dane muszą być chronione, jest zawsze łączenie kontroli. Rozumiem przez to, że aby nastąpiło przypadkowe lub złośliwe ujawnienie poufnych informacji lub incydent bezpieczeństwa, musiałaby nastąpić awaria lub dwie lub więcej kontroli.
Dobrym przykładem tego może być przechowywanie zaszyfrowanego pliku na serwerze. Mam również tajny klucz deszyfrujący, który muszę zachować jako poufny w innym pliku.
- Przechowuj klucz i zaszyfrowany plik na tym samym serwerze (0 Kontroli, każdy, kto ma dostęp do serwera, może w prosty sposób uzyskać poufne informacje)
- Wykonaj powyższe kroki i chroń dostęp do obu plików, aby mógł być odczytany tylko przez użytkownika środowiska wykonawczego aplikacji systemu operacyjnego (1 Kontrola, złamanie hasła użytkownika root lub użytkownika środowiska wykonawczego aplikacji pozwoli osobie atakującej na uzyskanie poufnych informacji)
- Przechowuj klucz w zewnętrznej przechowalni kluczy, zdobądź klucz z wieloma środkami bezpieczeństwa, takimi jak biała lista adresów IP, uwierzytelnianie certyfikatów i inne środki dla aplikacji, która może uzyskać dostęp do zaszyfrowanego pliku w swoim systemie plików. (Wiele kontroli, wielokrotne niepowodzenia kontroli bezpieczeństwa muszą wystąpić, aby dane poufne zostały naruszone)
Ponownie, nie ma czegoś takiego jak doskonałe bezpieczeństwo, ale cel posiadania wielu kontroli zapewnia, że wiele awarii musi wystąpić, aby nastąpiło ujawnienie.
Wydaje mi się, że produkty takie jak Azure KeyVault nie są lepsze i bezsensownie bardziej skomplikowane,
Skomplikowane tak, bezcelowe jest całkowicie subiektywne. Nie możemy dyskutować na temat bezcelowości dodatkowego bezpieczeństwa bez realistycznego uwzględnienia, jak poważne byłoby ujawnienie poufnych danych. Gdyby ktoś mógł wykorzystać poufne dane do wysyłania nielegalnych przelewów bankowych z instytucji finansowej, coś w rodzaju skarbca kluczowego jest najdalej od tego, co byłoby bezcelowe.
niż trzymanie swoich sekretów w osobnym pliku konfiguracyjnym i upewnianie się, że znajduje się w .gitignore lub równoważnym.
Dopóki ktoś nie sprawdzi przypadkowo kontroli źródła, sekret jest na zawsze osadzony w historii kontroli źródła.
Oczywiście ludzie zapewne niepewnie wyślą do siebie e-mailem ...
Bezpieczeństwo to nie tylko kwestia techniczna, to także kwestia ludzi. To byłoby nie na temat, ale wydaje mi się, że w tym momencie próbujesz oderwać się od robienia tego, co potrzebne.
Czy istnieje sposób na zarządzanie sekretami, który nie tylko poruszy problem? Uważam, że to pytanie ma jedną jasno określoną odpowiedź. Analogicznie, gdybym zapytał, w jaki sposób HTTPS nie tylko przenosi problem, odpowiedzią byłoby, że klucze CA są dystrybuowane wraz z twoim systemem operacyjnym i ufamy im, ponieważ ufamy metodzie dystrybucji systemu operacyjnego.
Bezpieczeństwo nie zawsze sprawia, że problemy znikają, przez większość czasu sprawuje kontrolę. Twoja analogia jest zwięzła, ponieważ tak właśnie działa kryptografia klucza publiczno-prywatnego. „Przenosimy problem” do urzędu certyfikacji, pokładając nieograniczone i pełne zaufanie w naszym urzędzie certyfikacji, aby zagwarantować tożsamość podmiotu będącego właścicielem certyfikatu publicznego. Zasadniczo nic nie mogłoby oznaczać katastrofalnego ciągu awarii (np. Utraty zaufania do urzędu certyfikacji), aby doprowadzić do problemu bezpieczeństwa.
Podobnie jak w przypadku wielu rzeczy, bezpieczeństwo to linia, którą należy narysować w oparciu o subiektywne kryteria, charakter danych, konsekwencje ujawnienia, apetyt na ryzyko, budżet itp.
