Jak zarządzać ochroną klucza prywatnego SSL serwera WWW (hasło kontra brak hasła)?

W grupie bezpieczeństwa mojej firmy dyskutujemy o tym, co gorszego z poniższych opcji zarządzania kluczem prywatnym SSL.

Serwer sieciowy potrzebuje dostępu do klucza prywatnego do operacji szyfrowania. Ten plik powinien być chroniony przed nieautoryzowanym dostępem. Jednocześnie serwer powinien uruchomić się automatycznie, bez interwencji człowieka (jeśli jest wystarczająco bezpieczny).

Omawiamy trzy opcje:

1. Chroń klucz za pomocą perms systemu plików.

2. Użyj klucza chronionego hasłem i wprowadź klucz ręcznie przy każdym ponownym uruchomieniu.

3. Użyj klucza chronionego hasłem i zapisz klucz w systemie plików, aby zautomatyzować ponowne uruchomienie.

Nasze obawy są następujące:

1. W przypadku opcji 1 ponowne uruchomienie jest automatyczne, ale kompromis może skopiować klucz prywatny i, jako że nie jest chroniony, może zostać wykorzystany do rozszyfrowania komunikacji lub podszywania się pod nasze serwery.

2. Opcja 2 wydaje się bezpieczniejsza, ale wymaga interwencji człowieka, a administratorzy są zaniepokojeni, jeśli zdarzy się to poza godzinami pracy. Ponadto hasło powinno być współdzielone z kilkoma administratorami systemu i wiadomo, że wspólny sekret nie jest już tajemnicą.

3. Opcja 3 ma najlepsze z obu poprzednich opcji, ale jeśli ktoś ma dostęp do klucza, może również mieć dostęp do hasła :(, więc nie wydaje się wcale tak bezpieczny.

Jak zarządzasz bezpieczeństwem kluczy prywatnych serwerów? Czy są jakieś (bezpieczniejsze) opcje?

Myślę, że wariant 1 to przyjęty standard.

Jeśli jednak naprawdę chcesz dodatkowych zabezpieczeń, dlaczego nie masz skonfigurowanego bezpiecznego serwera (nie w Twojej strefie DMZ) do monitorowania twojego serwera WWW, a jeśli apache ulegnie awarii, może automatycznie zalogować się zdalnie i ponownie uruchomić apache , dostarczając hasło.

Tak więc hasło jest przechowywane na komputerze, ale nie na tym samym, na którym działa apache, a nie w DMZ. Zyskujesz dodatkowe bezpieczeństwo dzięki użyciu hasła i zachowujesz możliwość automatycznego restartu.

Jeśli ktoś ma wystarczający dostęp do serwera, aby odczytać klucz, najprawdopodobniej ma również wystarczający dostęp do dołączenia debuggera i pobrania klucza z pamięci.

Jeśli naprawdę nie lubisz budzić się w środku nocy, aby wpisać hasła, wybierz opcję 1. Gdy masz wiele serwerów, chcesz automatycznie uruchomić się ponownie po awarii, a opcja 2 nie pozwala na to.

Jedną z możliwości uzyskania wyższego poziomu bezpieczeństwa niż 1., ale mniej przestojów niż 2., jest tworzenie kluczy prywatnych o krótkiej ważności i regularne ich odzyskiwanie. W ten sposób możesz przechowywać je bez hasła, ale zmniejszyć okno podatności.

Jak zauważyłeś, opcja 3. nie zapewnia żadnych dodatkowych zabezpieczeń w stosunku do 1.

Praktyczność nakazuje, że w prawie wszystkich sytuacjach ostatecznie skorzystasz z opcji (1). Perms systemu plików są najlepszym sposobem na uzyskanie większego bezpieczeństwa niż praktyczne scenariusze.

W systemie * nix możesz ograniczyć klucz prywatny tylko do rootowania, ponieważ większość dobrych serwerów WWW (takich jak apache) uruchomi się jako root, ale obniżysz swoje uprawnienia do ograniczonego użytkownika, gdy będą miały potrzebne uprzywilejowane porty (80, 443 itp.) .

Jak wspomniałeś, opcja (3) jest z punktu widzenia bezpieczeństwa taka sama jak opcja (1).