Gdzie firmy zazwyczaj przechowują certyfikaty SSL do wykorzystania w przyszłości?

26

Niedawno kupiliśmy certyfikat SSL z wieloznacznymi danymi dla naszej domeny. Przekształciliśmy wszystkie certyfikaty w magazyn kluczy Java, ale teraz zadajemy sobie pytanie, gdzie powinniśmy je przechowywać do późniejszego wykorzystania.

Czy ludzie używają kontroli źródła, takiej jak BitBucket, do tego rodzaju plików, czy po prostu generują za każdym razem, gdy jest to potrzebne, czy coś innego?

Zastanawiamy się, czy istnieje standardowe rozwiązanie lub jakieś „najlepsze praktyki” dotyczące przechowywania tych certyfikatów do przyszłego użytku.

ssl-certificate certificate best-practices AmericanKryptonite
źródło
Twórz kopie zapasowe zaszyfrowane w tradycyjnym rozwiązaniu do tworzenia kopii zapasowych. Nie przechowuj kluczy prywatnych niezaszyfrowanych u żadnego zewnętrznego dostawcy. Zazwyczaj dołączam datę wydania i datę wygaśnięcia do mojego certyfikatu i nazwy pliku klucza w celu różnicowania.
Andrew Domaszek,

Odpowiedzi:

22

Istnieje wiele rozwiązań:

Jedna aleja to konkretna przechowalnia kluczy albo sprzęt oparty na sprzęcie, moduł bezpieczeństwa sprzętowego lub ekwiwalent programowy.

Innym jest po prostu odwołanie starego klucza i wygenerowanie nowej pary kluczy prywatny / publiczny, gdy pojawi się sytuacja. To nieco zmienia problem z utrzymywania bezpieczeństwa klucza na zabezpieczenie nazwy użytkownika / hasła konta u dostawcy certyfikatu i procedur ponownego wystawienia. Zaletą jest to, że większość organizacji ma już uprzywilejowane rozwiązanie do zarządzania kontami, np. 1 2

Istnieje wiele sposobów przechowywania w trybie off-line, od wydrukowania kopii klucza prywatnego i publicznego, w tym hasła (ale będzie to pies do przywrócenia), po zwykłe przechowywanie ich na nośnikach cyfrowych przeznaczonych do długotrwałego przechowywania. .

Naprawdę złymi miejscami są GitHub, Twój zespół WiKi lub udział sieciowy (i masz pomysł).

Aktualizacja 2015/4/29: Keywhiz również wydaje się interesującym podejściem.

HBruijn
źródło
Jestem ciekawy, co rozumiesz przez „oprogramowanie równoważne” dla HSM?
Niektórzy dostawcy sprzętu komputerowego obecnie sprzedają swoje urządzenia również w postaci urządzenia wirtualnego - maszyny wirtualnej. Istnieją również takie rzeczy, jak przechowalnia kluczy Oracle i OpenHS SoftHSM, aby wymienić niektóre.
HBruijn
Więc w zasadzie pozwala to zamienić standardowy komputer w HSM ...
1
„ale to będzie pieska do przywrócenia” -> Ten sprawił, że mój dzień! Żarty na bok, należy je zaszyfrować przed zapisaniem.
Ismael Miguel
Z definicji będziesz udostępniać swój klucz publiczny wszystkim. Nie ma powodu, aby to szyfrować. Ale nie jest to również powód do niechlujstwa. Bezpieczeństwo dotyczy przede wszystkim klucza prywatnego, który zazwyczaj powinien być zaszyfrowany / chroniony hasłem. Powinieneś starać się mieć jak najmniej kopii tego.
HBruijn,
21

Nie, certyfikaty SSL nie podlegają kontroli źródła, przynajmniej nie części klucza prywatnego.

Traktuj je jak hasło. Nasze są przechowywane tak samo jak nasze hasła - w KeePass. Pozwala na załączanie plików i jest szyfrowany.

Dotacja
źródło
3

Jeśli poddasz klucz prywatny kontroli źródła, każdy, kto ma do niego dostęp, będzie mógł podszyć się pod twój serwer. Jeśli twój serwer nie używa PFS (idealna tajemnica przekazywania), możliwe jest również odszyfrowanie przechwyconego ruchu SSL za pomocą powszechnie dostępnych narzędzi open source, takich jak Wireshark.

Możesz zabezpieczyć klucz za pomocą szyfrowania DES lub AES za pomocą hasła przy użyciu OpenSSL. OpenSSL jest dostępny dla systemów Linux, OSX i Windows.

OpenSSL może również usunąć hasło, gdy hasło jest niewygodne (np. Na serwerze internetowym, który uruchamia się automatycznie, ale nie obsługuje automatycznego wprowadzania haseł).

Dodanie hasła przy użyciu szyfrowania AES (bezpieczniejsze niż DES): -

openssl rsa -aes256 -in private.key -out encrypted.private.key

Usuwanie hasła (pojawi się monit o podanie hasła): -

openssl rsa -in encrypted.private.key -out decrypted.private.key
Zdradliwy
źródło
1
Jeśli robisz wszystko poprawnie, to nawet ujawnienie klucza prywatnego nie powinno prowadzić do kompromisu z przeszłym ruchem, chociaż z pewnością ułatwiłoby to MITM, aby skompromitować przyszły ruch.
CVn
Cześć @Michael, Teoretycznie, ale niestety byłem w stanie odszyfrować wiele przechwyconych Apache i IIS, więc mogę tylko założyć, że PFS jest domyślnie wyłączony. Nawet wiele IPSEC VPN ma to wyłączone.
Tricky
PFS domyślnie nie jest tak bardzo obniżony, ponieważ nie jest obsługiwany przez wiele zestawów szyfrów. Spróbuj trochę czasu przetestować serwer SSL Labs; wskazuje, które zestawy szyfrów obsługują FS. Oczywiście wyłączenie wszystkich pakietów szyfrów spoza FS prawdopodobnie spowoduje, że wielu klientów pozostanie na lodzie, ponieważ nie obsługują pakietów szyfrów FS. Preferencyjne traktowanie pakietów FS powinno jednak działać (ale zdecydowanie odradzam ręczne zamawianie pakietów szyfrów, chyba że wiesz, co robisz i jakie są ich mocne i słabe strony).
CVn
Dziękujemy za polecenie w SSL Labs @Michael. Niestety moje serwery nie mają dostępu do Internetu, ale bawiłem się z włączonymi szyframi i, jak sugerujesz, PFS jest obsługiwany tylko przez niektóre szyfry. PFS rzeczywiście uniemożliwia mi dekodowanie śladów pakietów. Zaktualizuję odpowiednio swoją odpowiedź.
Tricky,
1

Inną opcją, po przeczytaniu o KeyWhiz, była Krypta HashiCorp. To nie tylko menedżer haseł, ale sklep Secrets, uważam, że jest trochę podobny do KeyWhiz. Jest napisany w GO, a klient działa również jako serwer i łączy się z wieloma backendami i metodami uwierzytelniania. Vault jest również oprogramowaniem typu open source, z opcją Enterprise.

Ponieważ klucze i certyfikaty SSL są tylko plikami tekstowymi, można je zakodować w standardzie base64 i zapisać jako ciąg znaków w Vault, a nawet sam tekst w Vault. Nie ma interfejsu WebUI ani graficznego interfejsu użytkownika, a wszystkie jego wiersze poleceń lub skrypty są sterowane i ma bardzo dobry, stabilny interfejs API sieci Web do uruchomienia.

  1. https://www.vaultproject.io/
  2. https://github.com/hashicorp/vault
Pred
źródło
0

Polecam zajrzeć do HSM offline (takiego jak token szyfrujący sprzęt lub CAC), aby przechowywać klucz prywatny i certyfikat. To nie tylko chroni klucz prywatny przed przypadkowym naruszeniem, ale także zapewnia pewne podstawowe odciążenie kryptograficzne.

Jeśli masz więcej zasobów kryptograficznych do zarządzania, zaleciłbym zapoznanie się z oprogramowaniem Enterprise Key & Certificate Management, które może zautomatyzować odnawianie, śledzić cykl życia, zautomatyzować przydzielanie do punktów końcowych itp. Większość z nich przechowuje zasób zaszyfrowany w spoczynku jako CLOB w bazie danych.

DTK
źródło
Dlaczego opinie negatywne? Nie narzekać; ciekawy, co jest nie tak z tą odpowiedzią.
Matt
Nie jestem pewien, dlaczego zagłosował. HSM są specjalnie zaprojektowane do bezpiecznego przechowywania kluczy i szybkiego szyfrowania. Mogę tylko zgadywać, że jest to związane z wydatkami lub bardziej złożonym zarządzaniem. Wszystkie główne banki używają HSM do kluczowych operacji w transakcjach typu Chip & Pin.
Tricky