Nadchodzi 1 listopada - czy Twój serwer Exchange jest gotowy?

1 listopada 2015 r .: Nowe zasady wchodzą w życie

Twoi znajomi z SSL.com chcieliby poznać ten początek Listopad 1st, 2015, trochę bardzo ważne zmiany odnośnie tego, co może być objęte certyfikaty SSL zaczynają obowiązywać:

• Nowe certyfikaty zawierające nazwy wewnętrzne nie będą już wydawane przez żaden urząd certyfikacji zgodnie z wytycznymi forum CA / Browser Forum (tj. wszystkie renomowane)
  
  Zwróć uwagę, że od jakiegoś czasu SSL.com nie wydaje certyfikatów intranetowych dla nazw wewnętrznych z datami ważności przypadającymi po 1 listopada 2015 r., W związku z czym klienci SSL.com nie powinni napotykać żadnych bezpośrednich problemów - jednak zdecydowanie zalecamy dwukrotne sprawdzenie certyfikatów aby dowiedzieć się, jak te orzeczenia mogą wpłynąć na Ciebie.
• Istniejące certyfikaty zawierające nazwy wewnętrzne nie będą ponownie wydawane po 1 listopada 2015 r.
  
  Ponownie, SSL.com pracował, aby upewnić się, że nie będziesz mieć z tego powodu problemów - jednak poniżej przedstawiliśmy najgorszy scenariusz dla twojej edycji.
• Istniejące certyfikaty zawierające nazwy wewnętrzne zostaną AUTOMATYCZNIE ODWOŁANE 1 listopada 2016 r.
  
  Jest to zasada „catch-all”, ponieważ niektóre architektury bezpieczeństwa mogą mieć już istniejące starsze certyfikaty, które nie przestrzegają tych reguł.

Zmiany te oznaczają, że e-mail - pierwsze i wciąż najbardziej przydatne narzędzie internetowe - może zostać negatywnie dotknięty przez zmiany, szczególnie jeśli używasz serwera Microsoft Exchange (który według badań rynkowych stanowi 63% wszystkich). W ten sposób Twoja architektura bezpieczeństwa może zacząć podlegać wpływom już w nadchodzący Dzień Wszystkich Świętych.

Czy jesteś gotowy?

Co masz na myśli, mówiąc „nazwy wewnętrzne”?

Najprostszą definicją nazwy wewnętrznej jest dowolny identyfikator sieci część prywatnej sieci i nieosiągalny przy użyciu nazwy przy użyciu domeny najwyższego poziomu (TLD) lub unikalnego adresu IP. W konsekwencji każdy identyfikator sieci, który jest publicznie zarejestrowany w organie centralnym, takim jak ICAAN, będzie użyteczny w certyfikatach

We wcześniejszych, prostszych czasach internetu wewnętrzna architektura DNS musiała martwić się tylko o uniknięcie ograniczonego zestawu TLD - w ten sposób intranet AwfulBigCo.com mógł obsługiwać nie tylko ABC.nyc i ABC.londyn ale 1600.pensylwania.ave, Poczta i Gandalf. Ponadto, niektóre zakresy adresów IPv4 i IPv6 zostały odłożone wyłącznie do użytku lokalnego - te zarezerwowane zakresy obejmują „192.168. *. *” dla routingu i 10. *. *. * dla sieci lokalnych. Zabezpieczanie intranetów certyfikatami SSL jest oczywiście dobrym pomysłem i do czasu wydania nowego orzeczenia każdy administrator sieci mógł zażądać i otrzymać certyfikat zawierający którykolwiek z nich.

Od 1 listopada 2015 r. Nie będzie już tak - certyfikaty nie będą już wydawane - lub, co najważniejsze, wydane ponownie - które zawierają nazwy wewnętrzne. Te nowe reguły mają na celu zarówno poprawę bezpieczeństwa, jak i umożliwienie właściwego użycia nowych nazw domen najwyższego poziomu (na przykład zarówno .london, jak i .nyc są teraz publicznymi domenami TLD). Jednak wymagają one od każdego użytkownika Exchange dokładnego przyjrzenia się konfiguracji sieci i zabezpieczeń oraz wprowadzenia zmian w celu zapoznania się z nowymi regułami. Ponieważ wiele projektów zabezpieczeń Exchange w przeszłości korzystało z nazw wewnętrznych, może to powodować poważne problemy z usługą pocztową po wygaśnięciu certyfikatów i po ich wygaśnięciu, ponieważ nowych certyfikatów z nazwami wewnętrznymi nie można wydać w celu zastąpienia istniejących - co gorsza, żadnego certyfikatu wielodomenowego zawierająca choćby jedną nazwę wewnętrzną nie powiedzie się podczas odnowienia, potencjalnie narażając ruch pocztowy na złośliwe exploity.

Niezastosowanie się do tego może negatywnie wpłynąć na ruch pocztowy, firmę i / lub reputację.

Brzmi strasznie.

Może tak być - to naprawdę zależy od tego, jak jesteś przygotowany. To może być bardzo łatwy problem do przeoczenia, a konsekwencje mogą być absolutnie śmiertelne dla Twojej firmy - if nie działasz z wyprzedzeniem.

Widzisz, dostawca certyfikatu AwfulBigCo przesłał żądanie poza swoje roboty, wykrył te nazwy wewnętrzne i (zgodnie z regułami forum CA / B) odmówił odnowienia.

To jest problem. UCC NIE zostanie odnowione i nie tylko usługi korzystające z dozwolonych nazw wewnętrznych (tj. Cała poczta firmowa i kopie zapasowe FTP) nie będą już chronione - podobnie jak inne domeny objęte UCC, takie jak podstawowa i .co. domeny uk dla AwfulBigCo.

Jasne, to skrajny najgorszy scenariusz - ale naprawdę wierzymy, że pełne bezpieczeństwo zależy od przygotowania się właśnie na to.

Dobrze, boję się - co mam teraz zrobić?

Jeśli używasz wewnętrznych nazw w swoich certyfikatach SSL, będziesz musiał podjąć kroki, aby rozwiązać ten problem, a im szybciej, tym lepiej.

Zasadniczo istnieje kilka opcji, które możesz wybrać:

1. Ponownie skonfiguruj system, aby używał tylko publicznie zarejestrowanych nazw domen.
   Jest to prawdopodobnie najlepsze rozwiązanie - sprawia, że ​​kwestia nazwy wewnętrznej jest dyskusyjna i będzie ogólnie prostsza w utrzymaniu i rozszerzaniu w przyszłości. Niestety, ta opcja prawdopodobnie będzie wymagać znacznej pracy z góry, ale można skonfigurować serwery Microsoft Exchange używać w pełni kwalifikowanych nazw domen publicznych (oraz to forum CA / Browser biały papier mówi więcej o wdrażaniu nazw FQDN w sieciach Active Directory). Administracja po zmianie prawie na pewno będzie tak samo prosta lub prostsza niż wcześniej (duży plus dla Boba), a w przyszłości AwfulBigCo będzie w stanie używać publicznie zaufanych certyfikatów do zabezpieczania całego ruchu zarówno wewnętrznie, jak i zewnętrznie. Możliwą wadą tej metody jest to, że umożliwia ona wykrycie informacji o wewnętrznej infrastrukturze firmy za pośrednictwem DNS, ale przemyślana konfiguracja stref DNS może pomóc w rozwiązaniu tego problemu - na przykład za pomocą subdomen, takich jak „wewnętrzne” lub oddzielne nazwy domen, i ograniczanie rozdzielczości z nich poza sieciami firmowymi.
2. Zarejestruj nazwy wewnętrzne jako nazwy FQDN.
   Niestety, nie ma opcji dla tego zarezerwowanego adresu IP, a „Mail” i „Gandalf” są oczywiście dostępne. (Ze względu na zdrowy rozsądek Boba założymy, że domeny .com i .co.uk są już bezpiecznie zarejestrowane - i tak jego dzień jest wystarczająco ciężki).
   Także, nawet jeśli abc. wymiana jest dostępny - i pamiętaj, że .exchange to jedna z nowych domen najwyższego poziomu, której wprowadzenie pomaga wpłynąć na zmianę tej zasady - może być przysadzona i dostępna tylko za wygórowaną cenę - prawdopodobnie dostępne są łatwiejsze i tańsze alternatywy.
3. Skonfiguruj urząd certyfikacji przedsiębiorstwa
   Jest to metoda stosowana już przez naprawdę duże podmioty, które muszą zabezpieczyć przede wszystkim komunikację wewnętrzną. Korporacyjny urząd certyfikacji służy jako korporacyjny urząd certyfikacji - zasadniczo zamiast łańcucha zaufania biegnącego do zewnętrznego urzędu certyfikacji wszystkie certyfikaty są ostatecznie zabezpieczane przez wygenerowany wewnętrznie certyfikat główny. Chociaż zapewnia to większe możliwości dostosowania (i pozwoliłoby Bobowi na zachować starszą strukturę nazewnictwa, którą AwfulBigCo ma na swoim miejscu) należy wziąć pod uwagę poważne problemy z bezpieczeństwem - włamanie w stylu Sony może ujawnić certyfikat główny przedsiębiorstwa i / lub klucz prywatny, umożliwiając niemal nieograniczone wykorzystanie sieci. Ponadto certyfikaty wydane we własnym zakresie NIE będą zaufane w innym miejscu - jest to metoda, która zabezpiecza komunikację wewnętrzną, ale nie może rozszerzyć zaufania poza mury sieci biznesowej. Wreszcie, utworzenie korporacyjnego urzędu certyfikacji nie jest bynajmniej rozwiązaniem z dnia na dzień i może być znacznie trudniejsze niż inne wymienione tutaj opcje, a zatem możliwe tylko w przypadku bardzo dużych (lub rozwijających się) sieci.
   
   SSL.com z przyjemnością oferuje usługi konsultingowe i usługi zarządzania, które pomogą Ci wynegocjować ścieżkę do utworzenia własnego Enterprise CA - po prostu wyślij wiadomość do Enterpriseca@ssl.com a jeden z naszych starszych administratorów wkrótce się z Tobą skontaktuje.
4. Użyj certyfikatów z podpisem własnym
   Ta opcja ma podobne wady jak Enterprise CA, ale nie skaluje się dobrze - ponieważ każdy certyfikat z podpisem własnym nie ma poza sobą łańcucha zaufania, każdy indywidualny certyfikat musiałby być zainstalowany na każdym kliencie, aby uniknąć komunikatów o błędach . Zarządzanie w rozległej sieci stworzyłoby również zupełnie nowy ból głowy dla biednego Boba - coś tak prostego, jak automatyczne aktualizacje przeglądarki, mogłoby spowodować spustoszenie, chyba że na każdym urządzeniu zostanie utrzymana ciągła czujność.

Jak zawsze, skontaktuj się z nami na SSL.com, jeśli masz jakieś pytania. Pamiętaj - bezpieczniejszy internet to lepszy internet.