Jak zachować poufność klucza ssl dla naszej witryny?

Chcę zachować poufność naszego klucza SSL do naszej witryny. Jest przechowywany na 2 dyskach USB, jednym w sejfie i jednym, który przechowuję. A potem jestem jedynym, który stosuje go do serwera WWW, aby był całkowicie bezpieczny.

Z wyjątkiem...

Przynajmniej w IIS możesz wyeksportować klucz. Tak więc każdy, kto jest administratorem, może otrzymać kopię klucza. Czy jest na to jakiś sposób? Czy z definicji wszyscy administratorzy mają pełny dostęp do wszystkich kluczy?

Aktualizacja: Mam sysadminów, którym w pełni ufam. Doprowadziło to do tego, że jeden z nich zrezygnował (mieli godzinę dojazdy do naszej firmy, 5 minut do nowej). Chociaż ufam tej osobie, podobnie jak wyłączamy jej konto Active Directory, gdy ktoś odchodzi, pomyślałem, że powinniśmy mieć sposób, aby upewnić się, że nie zachowają możliwości korzystania z naszego SSL.

A najłatwiejsze było to, że jestem jedynym, który to ma. Nasz certyfikat wygasa w styczniu, więc był to czas, aby zmienić praktykę, jeśli moglibyśmy. Na podstawie odpowiedzi wygląda na to, że nie możemy.

Prowadzi to do nowego pytania - kiedy ktoś, kto ma dostęp do certyfikatu, odchodzi, czy standardową praktyką jest zdobycie nowego certyfikatu i cofnięcie istniejącego. A jeśli osoba, która odeszła, jest godna zaufania, to czy kontynuujemy posiadanie certyfikatu, który mamy?

Osoba z administracyjnym (lub często nawet fizycznym) dostępem do serwera będzie mogła wyodrębnić klucz prywatny. Czy to poprzez eksport, wąchanie pamięci lub inne podobne oszustwa.

Administratorzy mają dostęp do kluczy prywatnych serwerów internetowych. Zaakceptuj to jako fakt i obejdź to. Jeśli twoi administratorzy nie są godni zaufania, możesz potrzebować lepszych administratorów lub przynajmniej mniej administratorów z dostępem do serwerów sieciowych. Jeśli chodzi o paranoję bezpieczeństwa zarządzania, może istnieć głębszy problem dotyczący ich zaufania do sysadmin.

Nie oznacza to, że każdy powinien mieć dostęp do klucza prywatnego. Przed udzieleniem dostępu zawsze powinna istnieć potrzeba dostępu. Mając to na uwadze, czy zamierzasz podjąć ekstremalne środki, aby upewnić się, że sysadmin z pełną kontrolą strony internetowej nie może wyeksportować klucza prywatnego, ale nadal może manipulować samą stroną internetową na wiele niemożliwych do wykrycia sposobów? Wróciliśmy do zaufania i myślę, że to jest sedno problemu, który należy rozwiązać.

Podczas importowania klucza możesz zaznaczyć go jako nieeksportowalny. Zapobiegnie to użyciu IIS lub certyfikatu MMC do jego wyeksportowania. Przynajmniej czyni to trochę trudniejszym.

Jeśli jednak mają konto administratora na komputerze lub fizyczny dostęp do niego - nadal będą mogli uzyskać klucz w inny sposób.

Tutaj może pomóc „pośredni urząd certyfikacji”.

„Główny urząd certyfikacji” w tym przykładzie poniżej jest własnością firmy SSL, a nie ciebie.

Nie masz bezpośredniej kontroli nad kluczami utworzonymi przez główny urząd certyfikacji, więc jeśli klucz podpisany przez główny urząd certyfikacji zostanie naruszony, musisz je przejrzeć, aby go unieważnić.

Ale:

Root CA (SSL company)
 |
 +-Intermediate CA (You)
   |
   +-Server Key for site

Jeśli umieścisz inny urząd certyfikacji pośrodku i sprawisz, że kupiony certyfikat SSL podpisze własny certyfikat urzędu certyfikacji zamiast bezpośrednio podpisywać certyfikat serwera, możesz zachować kontrolę nad certyfikatami serwera poniżej i wydawać certyfikaty unieważnienia lub zrobić cokolwiek innego, jeśli sprawy poniżej nie zostaną naruszone .

Trzymasz prywatny klucz pośredniego urzędu certyfikacji dla siebie, a administratorzy nie muszą go widzieć.

Możesz także to zrobić:

Root CA (SSL company)
 |
 +-Intermediate CA (You)
   |
   +-Server Key 1 for site
   +-Server Key 2 for site 
   +-Server Key 3 for site

Możesz przygotować się na kompromis i wygenerować certyfikaty z wyprzedzeniem, abyś mógł szybko przełączać się w przypadku odwołania pojedynczego klucza. Administratorzy nie otrzymują kluczy do 2 lub 3, dopóki nie pójdą na kompromis 1. Możesz umieścić w swojej witrynie powiadomienie o tym schemacie, a to również poinformuje administratorów, że jesteś gotowy w przypadku kompromisu i tego śmiesznego biznesu na ich koniec nie zniszczy twojej strony.

Istnieje wiele artykułów sugerujących przechowywanie kluczy prywatnych w innym miejscu niż serwer, ale te klucze prywatne służą do certyfikatów do podpisywania kodu . Wyobraź sobie, że masz klucze na komputerze offline, do którego tylko Ty masz dostęp, niektóre oprogramowanie jest napisane, dostajesz klucz prywatny z serwera offline, podpisujesz kod, a potem nie potrzebujesz klucza prywatnego, dopóki nie będziesz musiał podpisać kod ponownie.

Najlepszym rozwiązaniem zawsze było i nadal będzie przechowywać klucz w trybie offline. To, jak to zrobisz, zależy wyłącznie od Ciebie (istnieje kilka metod), pamiętaj tylko, aby dobrze go chronić w bezpiecznym biurze lub w innym miejscu, w którym nie jest łatwo kogoś schować.

Czytaj więcej na: https://www.thesslstore.com/blog/heres-what-happens-when-your-private-key-gets-compromised/

Natomiast certyfikaty SSL są przeznaczone dla stron internetowych, aby umożliwić komunikację HTTPS: Klucz prywatny jest potrzebny podczas każdego uzgadniania przez serwer WWW. Dlatego przechowywanie go w trybie offline nie będzie działać.