Program Continent TLS pomaga użytkownikom uzyskać bezpieczny dostęp do niektórych zasobów sieciowych. Kluczowe informacje są przechowywane w bezpiecznym pojemniku.
Stosowanie
Użytkownicy sieci korporacyjnej mogą teraz uzyskać zdalny i bezpieczny dostęp do określonych zasobów w Internecie. Podczas nawiązywania połączenia zapewniane jest wzajemne uwierzytelnianie z serwerem. Aby uzyskać dostęp należy wpisać w przeglądarce adres strony. W rezultacie klient przetwarza i wysyła żądanie do serwera w celu nawiązania bezpiecznego połączenia. Uwierzytelnianie odbywa się w oparciu o kluczowe certyfikaty.
Możliwości klienta
Protokół połączenia pomiędzy serwerem a Klientem to TLSv1. Zasób, dla którego nawiązano bezpieczny kontakt, musi zawierać w nazwie serwera wartość TLS. Jeżeli wszystko zostało wykonane poprawnie, na wyświetlaczu pojawi się certyfikat, który można zaktualizować naciskając odpowiedni przycisk. Istnieje możliwość automatycznego zapamiętania loginu i hasła podczas logowania do systemu. Warto zaznaczyć, że jeśli w procesie autoryzacji 5 razy z rzędu wprowadzisz fałszywe dane, system zostanie automatycznie zablokowany. Ponowne wprowadzenie danych będzie możliwe dopiero po 10 minutach.
Kluczowe cechy
- program jest w pełni kompatybilny ze wszystkimi wersjami systemu Windows;
- podczas użytkowania zapewniona jest niezawodna ochrona między użytkownikami korporacyjnymi;
- taki Klient jest optymalnym rozwiązaniem w sytuacji, gdy dochodzi do wymiany danych i niedopuszczalny jest wyciek informacji;
- Aby się zalogować należy podać swoje dane (login i hasło) oraz uruchomić certyfikowany klucz;
- praca odbywa się wyłącznie z serwerami obsługującymi protokoły TLSv1 i TLSv1.2.
Ostatnio coraz częściej mówi się o TLS i SSL, coraz bardziej istotne staje się stosowanie certyfikatów cyfrowych, a nawet pojawiły się firmy, które są gotowe udostępnić każdemu bezpłatne certyfikaty cyfrowe, aby zapewnić szyfrowanie ruchu pomiędzy odwiedzanymi witrynami a przeglądarką klienta. Jest to oczywiście konieczne ze względów bezpieczeństwa, aby nikt w sieci nie mógł odebrać danych przesyłanych od klienta do serwera i z powrotem. Jak to wszystko działa i jak z tego korzystać? Aby to zrozumieć, być może musimy zacząć od teorii, a następnie pokazać to w praktyce. A więc SSL i TLS.
Co to jest SSL i czym jest TLS?
SSL - Secure Socket Layer, warstwa bezpiecznych gniazd. TLS - Transport Layer Security, bezpieczeństwo warstwy transportowej. SSL to wcześniejszy system, TLS pojawił się później i jest oparty na specyfikacji SSL 3.0 opracowanej przez Netscape Communications. Protokoły te mają jednak jedno zadanie – zapewnić bezpieczny transfer danych pomiędzy dwoma komputerami w Internecie. Ten transfer jest używany w przypadku różnych stron internetowych, poczty e-mail, wiadomości i wielu innych. W zasadzie można w ten sposób przekazać dowolną informację, o czym poniżej.
Bezpieczną transmisję zapewnia uwierzytelnianie i szyfrowanie przesyłanych informacji. Zasadniczo te protokoły, TLS i SSL, działają tak samo; nie ma zasadniczych różnic. Można powiedzieć, że TLS jest następcą SSL, chociaż można z nich korzystać jednocześnie, nawet na tym samym serwerze. Takie wsparcie jest niezbędne, aby zapewnić współpracę zarówno z nowymi klientami (urządzeniami i przeglądarkami), jak i starszymi, nie obsługującymi TLS. Kolejność występowania tych protokołów wygląda następująco:
SSL 1.0 - nigdy nie opublikowany
SSL 2.0 – luty 1995
SSL 3.0 – 1996
TLS 1.0 – styczeń 1999 r
TLS 1.1 – kwiecień 2006
TLS 1.2 – sierpień 2008
Jak działają SSL i TLS
Zasada działania SSL i TLS, jak powiedziałem, jest taka sama. Na protokole TCP/IP tworzony jest szyfrowany kanał, w ramach którego dane przesyłane są za pośrednictwem protokołu aplikacji - HTTP, FTP i tak dalej. Oto jak można to przedstawić graficznie:
Protokół aplikacji jest „owinięty” w protokół TLS/SSL, który z kolei jest opakowany w protokół TCP/IP. Zasadniczo dane protokołu aplikacji są przesyłane przez protokół TCP/IP, ale są szyfrowane. I tylko maszyna, która nawiązała połączenie, może odszyfrować przesyłane dane. Dla wszystkich innych osób odbierających przesyłane pakiety informacja ta będzie bez znaczenia, jeśli nie będzie w stanie jej odszyfrować.
Połączenie jest nawiązywane w kilku etapach:
1) Klient nawiązuje połączenie z serwerem i żąda bezpiecznego połączenia. Można to osiągnąć albo nawiązując połączenie z portem, który początkowo ma współpracować z SSL/TLS, np. 443, albo dodatkowo prosząc klienta o nawiązanie bezpiecznego połączenia po nawiązaniu zwykłego.
2) Klient nawiązując połączenie podaje listę algorytmów szyfrowania, które „zna”. Serwer sprawdza otrzymaną listę z listą algorytmów, które sam serwer „zna” i wybiera najbardziej niezawodny algorytm, po czym informuje klienta, jakiego algorytmu użyć
3) Serwer przesyła klientowi swój certyfikat cyfrowy podpisany przez urząd certyfikacji oraz klucz publiczny serwera.
4) Klient może skontaktować się z serwerem zaufanego urzędu certyfikacji, który podpisał certyfikat serwera i sprawdzić, czy certyfikat serwera jest ważny. Ale może nie. W systemie operacyjnym zazwyczaj są już zainstalowane certyfikaty główne urzędów certyfikacji, względem których weryfikowane są podpisy certyfikatów serwerów np. przez przeglądarki.
5) Generowany jest klucz sesji dla bezpiecznego połączenia. Odbywa się to w następujący sposób:
— Klient generuje losową sekwencję cyfrową
— Klient szyfruje go kluczem publicznym serwera i wysyła wynik do serwera
— Serwer odszyfrowuje otrzymaną sekwencję za pomocą klucza prywatnego
Biorąc pod uwagę, że algorytm szyfrowania jest asymetryczny, tylko serwer może odszyfrować sekwencję. W przypadku szyfrowania asymetrycznego stosowane są dwa klucze – prywatny i publiczny. Wiadomość wysłana publicznie jest szyfrowana, a wiadomość wysyłana prywatnie jest odszyfrowywana. Nie da się odszyfrować wiadomości, jeśli posiadasz klucz publiczny.
6) Spowoduje to nawiązanie szyfrowanego połączenia. Przesyłane za jego pośrednictwem dane są szyfrowane i deszyfrowane do momentu zakończenia połączenia.
Certyfikat główny
Tuż powyżej wspomniałem o certyfikacie głównym. Jest to certyfikat centrum autoryzacji, którego podpis potwierdza, że podpisywany certyfikat jest tym, który należy do odpowiedniej usługi. Sam certyfikat zazwyczaj zawiera szereg pól informacyjnych, w których znajdują się informacje o nazwie serwera, na który certyfikat został wystawiony oraz okresie ważności tego certyfikatu. Jeżeli ważność certyfikatu wygasła, zostaje ona unieważniona.
Prośba o podpis (CSR, prośba o podpisanie certyfikatu)
Aby uzyskać podpisany certyfikat serwera należy wygenerować żądanie podpisu (CSR, Certyfikat Sign Request) i wysłać to żądanie do centrum autoryzacyjnego, które zwróci podpisany certyfikat zainstalowany bezpośrednio na serwerze. Poniżej zobaczymy jak to zrobić w praktyce. W pierwszej kolejności generowany jest klucz szyfrujący, następnie na podstawie tego klucza generowana jest prośba o podpis, czyli plik CSR.
Certyfikat klienta
Certyfikat klienta można wygenerować zarówno do użytku urządzenia, jak i użytkownika. Zazwyczaj takie certyfikaty są używane w weryfikacji dwukierunkowej, gdzie klient weryfikuje, czy serwer jest tym, za kogo się podaje, a serwer robi to samo w zamian. Ta interakcja nazywana jest uwierzytelnianiem dwukierunkowym lub uwierzytelnianiem wzajemnym. Uwierzytelnianie dwukierunkowe podnosi poziom bezpieczeństwa w porównaniu do uwierzytelniania jednokierunkowego, a także może zastąpić uwierzytelnianie za pomocą loginu i hasła.
Łańcuch działań generowania certyfikatów
Przyjrzyjmy się jak od samego początku przebiegają czynności związane z generowaniem certyfikatów oraz w praktyce.
Pierwszą rzeczą do zrobienia jest wygenerowanie certyfikatu głównego. Certyfikat główny jest z podpisem własnym. A potem tym certyfikatem będą podpisane inne certyfikaty.
$ openssl genrsa -out root.key 2048 Generowanie klucza prywatnego RSA, moduł o długości 2048 bitów ......+++ ...... ............... ...........+++ e to 65537 (0x10001) $ openssl req -new -key root.key -out root.csr Zostaniesz poproszony o wprowadzenie informacji, które zostaną uwzględnione w Twoim żądaniu certyfikatu . To, co zamierzasz wprowadzić, to tak zwana nazwa wyróżniająca lub nazwa wyróżniająca. Jest sporo pól, ale możesz zostawić niektóre puste. W przypadku niektórych pól będzie to wartość domyślna. Jeśli wpiszesz „.”, pole pozostanie puste. ----- Nazwa kraju (2-literowy kod):RU Nazwa stanu lub prowincji (pełna nazwa):nie dotyczy Nazwa miejscowości (np. miasto):Sankt-Petersburg Nazwa organizacji (np. firma) :Nazwa jednostki organizacyjnej mojej firmy (np. sekcja): Nazwa zwyczajowa usługi IT (np. nazwa FQDN serwera lub TWOJA nazwa): Adres e-mail certyfikatu głównego mojej firmy: [e-mail chroniony] Wprowadź następujące „dodatkowe” atrybuty, które mają zostać przesłane wraz z żądaniem certyfikatu. Hasło wezwania: Opcjonalna nazwa firmy: Moja firma $ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem Podpis ok topic=/C=RU/ST=N/A/L=Sankt-Petersburg/O=Moja firma/OU=Usługa IT/CN=Certyfikat główny mojej firmy/ [e-mail chroniony] Pobieranie klucza prywatnego
Tym samym najpierw wygenerowaliśmy klucz prywatny, potem prośbę o podpis, a następnie podpisaliśmy własnym kluczem własne żądanie i otrzymaliśmy własny certyfikat cyfrowy, wydawany na 10 lat. Podczas generowania certyfikatu nie musisz wprowadzać hasła wezwania.
Klucz prywatny MUSI być przechowywany w bezpiecznym miejscu, mając go możesz podpisać w swoim imieniu dowolny certyfikat. Powstały certyfikat główny można wykorzystać do sprawdzenia, czy certyfikat na przykład serwera został podpisany przez nas, a nie przez kogoś innego. Są to działania, jakie wykonują centra autoryzacyjne podczas generowania własnych certyfikatów. Po utworzeniu certyfikatu głównego możesz rozpocząć generowanie certyfikatu serwera.
Wyświetl informacje o certyfikacie
Treść certyfikatu można przeglądać w następujący sposób:
$ openssl x509 -noout -issuer -enddate -in root.pem wystawca= /C=RU/ST=N/A/L=Sankt-Petersburg/O=Moja firma/OU=Usługa IT/CN=Certyfikat główny mojej firmy/ [e-mail chroniony] notAfter=22 stycznia 11:49:41 2025 GMT
Widzimy, kto wystawił ten certyfikat i kiedy upływa jego data ważności.
Certyfikat serwera
Aby podpisać certyfikat dla serwera musimy wykonać następujące czynności:
1) Wygeneruj klucz
2) Wygeneruj prośbę o podpis
3) Wyślij plik CSR do centrum autoryzacyjnego lub podpisz go samodzielnie
Certyfikat serwera może zawierać łańcuch certyfikatów podpisujących certyfikat serwera, ale może być również przechowywany w oddzielnym pliku. W zasadzie wszystko wygląda mniej więcej tak samo, jak przy generowaniu certyfikatu głównego
$ openssl genrsa -out serwer.key 2048 Generowanie klucza prywatnego RSA, moduł o długości 2048 bitów ..................... ................................................. . +++........................+++ e to 65537 (0x10001) $ openssl req -new -key serwer.klucz - serwer wyjściowy .csr Zaraz zostaniesz poproszony o podanie informacji, które zostaną uwzględnione w Twoim żądaniu certyfikatu. To, co zamierzasz wprowadzić, to tak zwana nazwa wyróżniająca lub nazwa wyróżniająca. Jest sporo pól, ale możesz zostawić niektóre puste. W przypadku niektórych pól będzie to wartość domyślna. Jeśli wpiszesz „.”, pole pozostanie puste. ----- Nazwa kraju (2-literowy kod):RU Nazwa stanu lub prowincji (pełna nazwa):nie dotyczy Nazwa miejscowości (np. miasto):Sankt-Petersburg Nazwa organizacji (np. firma) :Nazwa jednostki organizacyjnej mojej firmy (np. sekcja): Nazwa zwyczajowa usługi IT (np. nazwa FQDN serwera lub TWOJA nazwa): www.mycompany.com Adres e-mail: [e-mail chroniony] Wprowadź następujące „dodatkowe” atrybuty, które mają zostać przesłane wraz z żądaniem certyfikatu. Hasło wezwania: Opcjonalna nazwa firmy: $ openssl x509 -req -in serwer.csr -CA root.pem -CAkey root.key -CAcreateserial -out serwer. pem -days 365 Podpis ok topic=/C=RU/ST=N/A/L=Saint-Petersburg/O=Moja firma/OU=IT Service/CN=www.mycompany.com/ [e-mail chroniony] Uzyskiwanie klucza prywatnego urzędu certyfikacji $ openssl x509 -noout -issuer -subject -enddate -in serwer.pem Issuer= /C=RU/ST=N/A/L=Sankt-Petersburg/O=Moja firma/OU=Usługa IT/CN =Certyfikat główny mojej firmy/ [e-mail chroniony] temat= /C=RU/ST=N/A/L=Sankt-Petersburg/O=Moja firma/OU=Usługa IT/CN=www.mojafirma.com/emailAd [e-mail chroniony] notAfter=25 stycznia 12:22:32 2016 GMT
W ten sposób certyfikat serwera zostanie podpisany i będziemy wiedzieć, która organizacja wystawiła ten certyfikat. Gotowy certyfikat po podpisaniu można wykorzystać zgodnie z jego przeznaczeniem, np. zainstalować na serwerze WWW.
Instalowanie certyfikatu SSL/TLS na serwerze z nginx
Aby zainstalować certyfikat SSL/TLS na serwerze WWW nginx, musisz wykonać kilka prostych kroków:
1) Skopiuj pliki .key i .pem na serwer. W różnych systemach operacyjnych certyfikaty i klucze mogą być przechowywane w różnych katalogach. Na przykład w Debianie jest to katalog /etc/ssl/certs dla certyfikatów i /etc/ssl/private dla kluczy. W CentOS jest to /etc/pki/tls/certs i /etc/pki/tls/private
2) Zapisz niezbędne ustawienia w pliku konfiguracyjnym hosta. Tak to mniej więcej powinno wyglądać (tylko przykład):
Serwer (słuchaj 443; nazwa_serwera www.mojafirma.com; root html; indeks indeks.html indeks.htm; ssl on; certyfikat_ssl serwer.pem; ssl_certificate_key serwer.key; ssl_session_timeout 5m; # SSLv3 nie jest zalecane!!! # Jest tutaj na przykład tylko ssl_protocols SSLv3 TLSv1; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP; ssl_prefer_server_ciphers on; lokalizacja / ( try_files $uri $uri/ =404; ) )
3) Uruchom ponownie Nginx
4) Wejdź za pomocą przeglądarki na port serwera 443 - https://www.mycompany.com i sprawdź jego funkcjonalność.
Instalowanie certyfikatu SSL/TLS na serwerze z uruchomionym Apache
Instalacja certyfikatu SSL/TLS na Apache wygląda podobnie.
1) Skopiuj pliki klucza i certyfikatu na serwer do odpowiednich katalogów
2) Włącz moduł ssl dla Apache za pomocą polecenia „a2enmod ssl”, jeśli nie jest jeszcze włączony
3) Utwórz hosta wirtualnego, który będzie nasłuchiwał portu 443. Konfiguracja będzie wyglądać mniej więcej tak:
Jednocześnie jest jeszcze coś do zrobienia. Znajdź w pliku httpd.conf, Apache2.conf lub ports.conf, w zależności od systemu, następującą sekcję konfiguracji:
Jeśli nie ma takiego warunku należy go dodać do config. I jeszcze jedno: musisz dodać linię
NazwaWirtualny Host *:443
Ta linia może znajdować się w pliku httpd.conf, Apache2.conf lub ports.conf
4) Uruchom ponownie serwer WWW Apache
Tworzenie certyfikatu klienta
Certyfikat klienta jest tworzony w podobny sposób jak certyfikat serwera.
$ openssl genrsa -out klient.key 2048 Generowanie klucza prywatnego RSA, moduł o długości 2048 bitów ..............+++ ..... .............................+++ e to 65537 (0x10001) $ openssl req -new -key klient.klucz -out klient.csr Zostaniesz poproszony o wprowadzenie informacji, które zostaną uwzględnione w Twoim żądaniu certyfikatu. To, co zamierzasz wprowadzić, to tak zwana nazwa wyróżniająca lub nazwa wyróżniająca. Jest sporo pól, ale możesz zostawić niektóre puste. W przypadku niektórych pól będzie to wartość domyślna. Jeśli wpiszesz „.”, pole pozostanie puste. ----- Nazwa kraju (2-literowy kod):RU Nazwa stanu lub prowincji (pełna nazwa):Saint-Petersburg Nazwa miejscowości (np. miasto):^C mnorin@mnorin-work:~/Temp/certs/CA$ openssl req -new -key klient.klucz -out klient.csr Zostaniesz poproszony o wprowadzenie informacji, które zostaną uwzględnione w Twoim żądaniu certyfikatu. To, co zamierzasz wprowadzić, to tak zwana nazwa wyróżniająca lub nazwa wyróżniająca. Jest sporo pól, ale możesz zostawić niektóre puste. W przypadku niektórych pól będzie to wartość domyślna. Jeśli wpiszesz „.”, pole pozostanie puste. ----- Nazwa kraju (2-literowy kod):RU Nazwa stanu lub prowincji (pełna nazwa):nie dotyczy Nazwa miejscowości (np. miasto):Saint-Petrersburg Nazwa organizacji (np. firma):Nazwa jednostki organizacyjnej mojej firmy (np. sekcja):Engineering Nazwa zwyczajowa (np. nazwa FQDN serwera lub TWOJA nazwa):Ivan Ivanov Adres e-mail: [e-mail chroniony] Wprowadź następujące „dodatkowe” atrybuty, które mają zostać przesłane wraz z żądaniem certyfikatu. Hasło wezwania: Opcjonalna nazwa firmy: $ openssl x509 -req -in klient.csr -CA root.pem -CAkey root.key -CAcreateserial -out klient. pem -days 365 Podpis ok temat=/C=RU/ST=N/A/L=Sankt-Petrersburg/O=Moja firma/OU=Inżynieria/CN=Iwan Iwanow/ [e-mail chroniony] Uzyskiwanie klucza prywatnego urzędu certyfikacji $ openssl x509 -noout -issuer -subject -enddate -in client.pem Issuer= /C=RU/ST=N/A/L=Sankt-Petersburg/O=Moja firma/OU=Usługa IT/CN =Certyfikat główny mojej firmy/ [e-mail chroniony] topic= /C=RU/ST=N/A/L=Sankt-Petrersburg/O=Moja firma/OU=Inżynieria/CN=Iwan Iwanow/e-mail [e-mail chroniony] notAfter=25 stycznia 13:17:15 2016 GMT
Jeżeli potrzebujesz certyfikatu klienta w formacie PKCS12 utwórz go:
$ openssl pkcs12 -export -in klient.pem -inkey klient.klucz -certfile root.pem -out iivanov.p12 Wprowadź hasło eksportu: Weryfikacja - wprowadź hasło eksportu:
Teraz możesz używać certyfikatu klienta do pracy z naszym serwerem.
Konfigurowanie nginx do korzystania z certyfikatów klienta
Najczęściej, jak już mówiłem, stosuje się uwierzytelnianie jednokierunkowe, zwykle sprawdzany jest tylko certyfikat serwera. Zobaczmy, jak zmusić serwer WWW Nginx do weryfikacji certyfikatu klienta. Aby pracować z certyfikatami klienta, konieczne jest dodanie opcji do sekcji serwera:
# Certyfikaty główne, którymi podpisany jest klient. ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Możliwe opcje: na | wyłączone | opcjonalne | opcjonalny_no_ca ssl_verify_client opcjonalny; # Głębokość weryfikacji łańcucha certyfikatów, którymi podpisany jest klient ssl_verify_ głębokość 2;
Następnie należy ponownie uruchomić ustawienia lub cały serwer i sprawdzić działanie.
Konfigurowanie Apache do korzystania z certyfikatów klienta
Apache można również skonfigurować, dodając dodatkowe opcje w sekcji hosta wirtualnego:
# Katalog zawierający certyfikaty główne do weryfikacji klienta SSLCARevocationPath /etc/apache2/ssl.crl/ # lub plik zawierający certyfikaty SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Opcja weryfikacji klienta. Możliwe opcje: # brak, opcjonalne, wymagają i opcjonalne_no_ca SSLVerifyClient require # Wyświetl głębokość łańcucha podpisów. Domyślnie 1 SSLVerifyDepth 2
Jak widać, opcje są w przybliżeniu takie same jak w przypadku nginx, ponieważ proces weryfikacji jest zorganizowany jednolicie.
Słuchanie informacji o certyfikacie za pomocą openssl
Aby przetestować interakcję serwera z certyfikatami klienta, możesz sprawdzić, czy połączenie jest nawiązywane przy użyciu protokołu TLS/SSL.
Po stronie serwera zaczynamy nasłuchiwać na porcie za pomocą openssl:
Openssl s_server -accept 443 -cert serwer.pem -key serwer.klucz -stan
Po stronie klienta uzyskujemy dostęp do serwera na przykład za pomocą culr:
Zwiń -k https://127.0.0.1:443
W konsoli po stronie serwera możesz obserwować proces wymiany informacji pomiędzy serwerem a klientem.
Możesz także użyć opcji -verify [głębokość weryfikacji] i -Verify [głębokość weryfikacji]. Opcja small-case prosi klienta o certyfikat, ale jego dostarczenie nie jest wymagane. Pisane wielką literą — jeśli certyfikat nie zostanie podany, wystąpi błąd. Zacznijmy nasłuchiwać po stronie serwera w ten sposób:
Openssl s_server -accept 443 -cert serwer.pem -key serwer.klucz -stan -Sprawdź 3
Od strony serwera błąd wygląda następująco:
140203927217808:błąd:140890C7:Procedury SSL:SSL3_GET_CLIENT_CERTIFICATE:peer nie zwrócił certyfikatu:s3_srvr.c:3287:
Od strony klienta tak:
Curl: (35) błąd:14094410:Procedury SSL:SSL3_READ_BYTES:Błąd uzgadniania alertu sslv3
Dodajmy certyfikat i nazwę domeny po stronie klienta (możesz wpisać nazwę hosta dla adresu 127.0.0.1 w pliku /etc/hosts w celu sprawdzenia):
Curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key klient.key
Teraz połączenie się powiedzie i będziesz mógł zainstalować certyfikat serwera na serwerze WWW, przekazać klientowi certyfikat klienta i pracować z nim.
Bezpieczeństwo
W przypadku korzystania z protokołu SSL/TLS jedną z głównych metod jest metoda MITM (Man In The Middle). Metoda ta opiera się na użyciu certyfikatu serwera i klucza w jakimś węźle, który będzie nasłuchiwał ruchu i deszyfrował informacje wymieniane pomiędzy serwerem a klientem. Aby uporządkować słuchanie, możesz użyć na przykład programu sslsniff. Dlatego zazwyczaj zaleca się przechowywanie certyfikatu głównego i klucza na komputerze, który nie jest podłączony do sieci; w celu podpisania należy przynieść prośby o podpis na dysku flash, podpisać i również je zabrać. I oczywiście rób kopie zapasowe.
Najogólniej tak właśnie wykorzystywane są certyfikaty cyfrowe oraz protokoły TLS i SSL. Jeśli masz pytania/dodatki, napisz w komentarzach.
Wpis został opublikowany przez autora w kategorii oznaczonej , .Nawigacja po wpisach
: 29 komentarzy
cl-service.com
Klient sam generuje CSR zamawiając certyfikat, przy czym decyduje również o przechowywaniu klucza prywatnego, do wystawienia certyfikatu nie jest nam potrzebny klucz prywatny, a klient w żaden sposób go nam nie przekazuje. Naturalnie, jeśli dzieje się to na zwykłym serwerze wirtualnym, wówczas administratorzy z dostępem root do serwera mają również dostęp do przechowywanych tam kluczy.
- Życzący.
Temat cycków nie jest poruszany, gdyż opisana technologia PKI nie ma nic wspólnego z tytułem tematu. Przynajmniej nie bez powodu podałem linki do RFC.
P.S. Był taki dowcip o psie i pchle. - Życzący.
Nie chciałem Cię w żaden sposób urazić. Szukałem informacji na temat różnicy w praktyce pomiędzy SSl a TLS i Twój link był pierwszy w Google. Zaintrygował mnie tytuł tematu. Wszystko super, tak trzymaj!
- DrAibolit
Dziękujemy za wnikliwe wyjaśnienia dotyczące certyfikacji cyfrowej. Jestem w tym nowy =)
Mam nadzieję, że możesz wyjaśnić następujące pytanie.
Ponieważ temat oszustw jest bardzo rozwinięty w branży internetowej, chciałbym dowiedzieć się, jak samodzielnie rozpoznać „wszy” stron, które odwiedzam (zwłaszcza tam, gdzie znajdują się środki pieniężne i płatnicze, inwestycje itp.) i na ich podstawie to określa stopień mojego zaufania (często muszę się rejestrować, zostawiać dane osobowe, dokonywać zakupów, transakcji, inwestycji). Jeśli dobrze rozumiem, posiadanie tego certyfikatu pozwala na dokonanie takiej oceny. Cóż, z drugiej strony zdobycie go nie stanowi problemu i jest nawet bezpłatne.
Jak lub za pomocą jakiego programu można sprawdzić, czy witryna posiada certyfikat cyfrowy? i najlepiej jego kategorię, która jest nadawana w przypadku wystawienia przez specjalny organ SSL DV (certyfikat wydawany jest z weryfikacją tylko domeny), SSL OV (z weryfikacją organizacji), EV (z rozszerzoną weryfikacją osoby prawnej). Oszukańcze witryny najprawdopodobniej nie będą korzystać z najnowszej opcji certyfikacji.
Byłbym szczęśliwy, gdybyś powiedział mi więcej sposobów określania wiarygodności witryn))- mnorin Autor posta
Nie natknąłem się jeszcze na żaden konkretny program do tych celów, ale mogę dać kilka wskazówek w tej kwestii.
Możesz użyć na przykład Chromium lub Google Chrome. Weźmy na przykład stronę https://www.thawte.com/ – firmy, która faktycznie zajmuje się certyfikatami cyfrowymi.
Pasek adresu będzie zawierał nazwę firmy i zieloną kłódkę. Oznacza to, że organizacja jest zweryfikowana, jest to co najmniej SSL OV.
Jeśli klikniesz na kłódkę, a w rozwijanym oknie „Szczegóły”, a następnie „Wyświetl certyfikat”, zobaczysz informacje o certyfikacie. W przypadku Thawte certyfikat jest podpisany następującym certyfikatem: „thawte Extended Validation SHA256 SSL CA”, a certyfikat dla click.alfabank.ru również jest podpisany przez Thawte, ale innym certyfikatem. Jest to „thawte EV SSL CA - G3”, czyli one również przeszły rozszerzoną weryfikację.
Coś takiego.
- mnorin Autor posta
- Rusłan
Sekcja „Jak działają SSL i TLS”, „Klient generuje losową sekwencję cyfrową”.
Byłem pewien, że klient generuje sesyjne klucze prywatne i odpowiednio klucze publiczne (które oczywiście nazwałeś „sekwencją cyfrową”). Klucz publiczny jest przekazywany do serwera, a serwer szyfruje pakiety do klienta za pomocą publicznego klucza sesji klienta.
Proszę o wyjaśnienie.
- Nowicjusz
Artykuł jest bardzo przydatny! Są nawet praktyczne przykłady =) Ale jednego nie rozumiem - jaka jest różnica między certyfikatem głównym a certyfikatem serwera? czy to to samo?
- Witalij
Cześć.
Hoster zaoferował usługę - SSL dla serwerów wirtualnych. Skorzystaliśmy z tego. Okazało się, że dla poziomu trzeciego, tj. Certyfikat http://www.site.ru jest nieprawidłowy, tylko dla site.ru. Co więcej, odwiedzający stale przełączają się na protokół https, niezależnie od tego, czy odwiedzają site.ru, czy http://www.site.ru. Oczywiście w drugim przypadku przeglądarka zaczyna przeklinać rozdzierająco, a odwiedzający w ogóle nie trafia na stronę.
Jednak dla tych, którym udało się wejść na tę witrynę, witryna zaczęła wyglądać krzywo, część menu zniknęła, a niektóre obrazy w wynikach wyszukiwania przestały być wyświetlane przez niektóre komponenty.
Oprogramowanie Kontynent TLS VPN– system zapewniający bezpieczny zdalny dostęp do aplikacji internetowych wykorzystujący algorytmy szyfrowania GOST. Continent TLS VPN zapewnia kryptograficzną ochronę ruchu HTTP na poziomie sesji. Informacje są szyfrowane przy użyciu algorytmu GOST 28147–89.
Identyfikacja i uwierzytelnianie użytkowników zdalnych
Identyfikacja i uwierzytelnianie użytkowników odbywa się przy użyciu certyfikatów klucza publicznego standardu x.509v3 (GOST R 31.11–94, 34.10–2001). Continent TLS VPN sprawdza kluczowe certyfikaty względem list odwołanych certyfikatów (CRL). Certyfikaty wydawane są przez zewnętrzny urząd certyfikacji.
Jeżeli procedury uwierzytelnienia zakończą się pomyślnie, żądanie użytkownika zostaje przekierowane poprzez protokół HTTP do bezpiecznej sieci na odpowiedni serwer WWW. W takim przypadku do sesji HTTP każdego użytkownika dodawane są specjalne identyfikatory (identyfikator klienta i identyfikator IP).
Kryptograficzna ochrona przesyłanych informacji
Continent TLS VPN zapewnia kryptograficzną ochronę ruchu HTTP na poziomie sesji. Informacje są szyfrowane przy użyciu algorytmu GOST 28147–89. Funkcję skrótu oblicza się za pomocą algorytmu GOST R 34.11–94, GOST R 34.11–2012. Generowanie i weryfikacja podpisu elektronicznego odbywa się zgodnie z algorytmem GOST R 34.10–2001, GOST R 34.10–2012.
Ukrywanie chronionych serwerów i tłumaczenie adresów
Continent TLS VPN filtruje żądania i przesyła adresy żądań do serwerów internetowych w sieci firmowej. Tłumaczenie adresów odbywa się zgodnie z zasadami ustalonymi przez administratora „Continent TLS VPN”.
Tolerancja błędów i skalowalność
Continent TLS VPN obsługuje działanie w wysokowydajnej konstrukcji klastra z równoważeniem obciążenia (zewnętrzny moduł równoważenia obciążenia). Zwiększoną odporność na awarie osiąga się poprzez dodanie do klastra redundantnego węzła. Jednocześnie rozbudowa elementów klastra bilansującego może być prowadzona w sposób nieograniczony. Awaria elementu klastra nie powoduje zerwania połączeń, ponieważ obciążenie rozkłada się równomiernie na pozostałe elementy.
Monitorowanie i rejestrowanie zdarzeń
W Continent TLS VPN administrator zawsze może uzyskać informację operacyjną o aktualnym stanie nawiązanych połączeń oraz statystyki dotyczące jego działania. Zdarzenia związane z bezpieczeństwem informacji są rejestrowane na serwerze. Wszystkie zdarzenia mogą zostać przesłane na wskazany serwer w formacie syslog w celu dalszej analizy, co maksymalnie upraszcza integrację z systemami SIEM.
Wygodne narzędzia do zarządzania
Połączenie narzędzi lokalnych i zdalnych z interfejsem WWW oraz wygodną graficzną konsolą zarządzania zapewnia elastyczną konfigurację Continent TLS VPN zgodnie z wymogami polityk bezpieczeństwa.
Obsługiwane protokoły
Continent TLS VPN obsługuje protokoły TLS v.1, TLS v.2.
Doświadczenie użytkownika za pośrednictwem dowolnej przeglądarki internetowej
Korzystając z aplikacji klienta Continent TLS VPN, użytkownicy mogą uzyskać dostęp do chronionych zasobów z dowolnej przeglądarki internetowej. Klient Continent TLS VPN to lokalny serwer proxy, przechwytujący ruch przeglądarki do chronionych serwerów internetowych i pakuje go do tunelu http. Dzięki temu użytkownik może pracować z dowolną przeglądarką internetową zainstalowaną na swoim urządzeniu.
Korzystanie z przyjaznego dla użytkownika oprogramowania klienckiego
Korzystanie z przyjaznego dla użytkownika oprogramowania klienckiego Continent TLS VPN Client lub CryptoPro CSP w wersji 3.6.1 może być używane jako klient na urządzeniu użytkownika.
Aby zainstalować oprogramowanie klienta Continent TLS, potrzebujesz:
Rysunek 33. Okno startowe kreatora instalacji oprogramowania „Continent TLS Client”.
Rysunek 34. Okno umowy licencyjnej na oprogramowanie Continent TLS Client.
3. Zaznacz pole „Akceptuję warunki umowy licencyjnej” i kliknij przycisk „Dalej”. Na ekranie pojawi się okno umożliwiające wprowadzenie klucza licencyjnego dostarczonego z oprogramowaniem Continent TLS Client na nośniku papierowym lub elektronicznym.
Rysunek 35. Okno do wprowadzenia klucza licencyjnego oprogramowania Continent TLS Client.
4. Wprowadź klucz licencyjny i kliknij Dalej. Na ekranie pojawi się okno dialogowe umożliwiające wybór ścieżki instalacji oprogramowania klienta Continent TLS.
Rysunek 36. Okno wyboru ścieżki instalacji oprogramowania Continent TLS Client.
5. Pozostaw domyślną ścieżkę instalacji. Kliknij Następny". Na ekranie pojawi się okno dialogowe „Uruchom konfigurator”.
Rysunek 37. Okno uruchamiania konfiguratora oprogramowania Continent TLS Client.
6. Zaznacz checkbox „Uruchom konfigurator po zakończeniu instalacji”.
Rysunek 38. Okno gotowości do instalacji oprogramowania klienta Continent TLS.
8. Kliknij przycisk „Zainstaluj”. Rozpocznie się instalacja komponentu.
Rysunek 39. Proces instalacji oprogramowania klienta Continent TLS.
9. Na ekranie wyświetli się okno dialogowe ustawień oprogramowania „Continent TLS Client”.
Rysunek 40. Konfigurowanie oprogramowania klienta Continent TLS.
Aby skonfigurować oprogramowanie, którego potrzebujesz:
a) W sekcji „Ustawienia klienta Continent TLS” pozostaw wartość „Port” na domyślnej wartości 8080.
b) W sekcji „Ustawienia serwera chronionego”, w polu „Adres” ustaw nazwę serwera TLS: lk.budget.gov.ru.
c) W sekcji „Ustawienia serwera chronionego”, w polu „Certyfikat” określ plik certyfikatu serwera TLS skopiowany do katalogu lokalnego w punkcie 3.1 niniejszego Przewodnika.
Rysunek 41. Konfigurowanie oprogramowania klienta Continent TLS. Wybór certyfikatu.
d) Jeżeli stacja robocza użytkownika nie korzysta z zewnętrznego serwera proxy, kliknij przycisk „OK”.
e) W przeciwnym razie podaj adres i port używanego zewnętrznego serwera proxy organizacji.
Rysunek 42. Konfigurowanie usługi oprogramowania Continent TLS Client. Konfigurowanie zewnętrznego serwera proxy.
f) Kliknij przycisk „OK”.
10. Na ekranie wyświetli się okno dialogowe umożliwiające zakończenie instalacji oprogramowania klienta Continent TLS.
Rysunek 43. Okno dialogowe zakończenia instalacji oprogramowania klienta Continent TLS.
11. Kliknij przycisk „Gotowe”.
12. Na ekranie pojawi się dialog o konieczności ponownego uruchomienia stacji roboczej użytkownika.
Rysunek 44. Dialog o konieczności ponownego uruchomienia stacji roboczej Użytkownika.
13. Kliknij przycisk „Nie”.
Kontynent TLS VPN- certyfikowane rozwiązanie chroniące dostęp zdalnych użytkowników do chronionych zasobów.
Continent TLS VPN ma architekturę klient-serwer i składa się z CIPF „Continent TLS VPN Server”, który jest instalowany na granicy sieci, oraz klienta VPN CIPF „Continent TLS VPN Client”, zainstalowanego na komputerach użytkowników zdalnych. „Continent TLS VPN Server” zapewnia poufność, integralność i imitację ochrony przesyłanych informacji oraz realizuje następujące funkcje:
- uwierzytelnianie użytkowników przy użyciu certyfikatów klucza publicznego standardu x.509v3 (GOST R 31.11–94, 34.10–2001);
- sprawdzenie certyfikatu użytkownika z listą unieważnionych list CRL;
- nawiązywanie bezpiecznych, szyfrowanych połączeń z wykorzystaniem protokołu HTTPS;
- rozsyłanie żądań do serwerów sieciowych sieci korporacyjnych i innych.
Serwer Continent TLS VPN IPC-3000F (S021), 2014
CIPF „Continent TLS VPN Client” to lokalna, przejrzysta usługa proxy, która zapewnia wzajemne uwierzytelnianie z serwerem, ustanawianie bezpiecznego połączenia i wymianę zaszyfrowanych danych z serwerem. Jest także kompatybilny z większością istniejących przeglądarek internetowych. Ponadto użytkownicy mogą pracować za pośrednictwem „Continent TLS VPN Server” bez konieczności instalowania oprogramowania klienckiego CIPF „Continent TLS VPN Client”. W takim przypadku na komputerze użytkownika musi być zainstalowana przeglądarka MS Internet Explorer z zainstalowanym dostawcą usług kryptograficznych „CryptoPro CSP” (wersja 3.6 lub 3.9), który zapewnia obsługę kryptoalgorytmów GOST.
Produkt przeznaczony jest dla:
- bezpiecznie łącz użytkowników z portalami usług rządowych, elektronicznymi platformami handlowymi, systemami bankowości internetowej lub aplikacjami korporacyjnymi za pośrednictwem przeglądarki internetowej.
- kryptograficzna ochrona ruchu http podczas przesyłania danych otwartymi kanałami sieci publicznych.
Kluczowe cechy
- Ochrona kryptograficzna
- Zastosowanie protokołu TLS z szyfrowaniem zgodnie z GOST 28147–89 zapewnia niezawodną ochronę ruchu HTTP na poziomie transportu
- Monitorowanie i rejestrowanie zdarzeń związanych z bezpieczeństwem informacji
- Pozyskiwanie informacji eksploatacyjnych o statystykach pracy i bieżących połączeniach serwera „Continent TLS VPN”.
- Identyfikacja i uwierzytelnianie użytkownika
- Identyfikacja i uwierzytelnianie użytkowników za pomocą certyfikatów klucza publicznego standardu x.509. Przesyłanie danych uwierzytelniających użytkownika na serwer WWW.
- Współpraca z zewnętrznymi urzędami certyfikacji (CA)
- Aby utworzyć certyfikaty x.509, „Continent TLS VPN” korzysta z zewnętrznego urzędu certyfikacji „CryptoPro”
- Transparentne proxy ruchu HTTP
- Aby bezpiecznie zalogować się do serwisu wystarczy, że w pasku adresu przeglądarki wpiszesz adres IP lub nazwę domeny.
- Skalowalność i odporność na błędy
- Obsługa trybu pracy w schemacie klastra o wysokiej wydajności z równoważeniem obciążenia (zewnętrzny moduł równoważenia obciążenia). Zwiększoną odporność na awarie osiąga się poprzez dodanie do klastra redundantnego węzła.
Osobliwości
- Wysoka wydajność – do 20 000 jednoczesnych połączeń na węzeł (IPC-3000F).
- Kompatybilny z dowolną przeglądarką internetową.
- Łatwość zarządzania – wszystkich ustawień dokonuje administrator poprzez przeglądarkę internetową.
- Nieograniczona skalowalność wydajności - możliwość łączenia w klaster o wysokiej wydajności w celu osiągnięcia wydajności ponad 100 tysięcy jednoczesnych połączeń.
- Łatwość wdrożenia i obsługi – gotowe rozwiązanie eliminuje konieczność osadzania modułów kryptograficznych w serwerze WWW i przechodzenia przez procedurę monitorowania integracji ochrony informacji kryptograficznej.
- Łatwa integracja z zewnętrznymi systemami SIEM.
Certyfikaty
- Certyfikat FSTEC Rosji na zgodność z wymogami dotyczącymi braku niezgodności z 4. poziomem kontroli. Służy do ochrony AC do klasy 1G włącznie, ISPDn do UZ 1 włącznie i GIS do klasy 1 włącznie.
- Certyfikaty FSB Rosji „Continent TLS VPN Server” dla CIPF klasy KS2 i „Continent TLS VPN Client” dla CIPF klasy KS2 i KS1.
2018: Wydanie „Continent TLS Server” w wersji 2.1
Klienci Continent TLS Server 2.1 mogli centralnie aktualizować część kliencką kompleksu na komputerach użytkowników zdalnych. Dodatkowo w prezentowanej wersji uproszczono system licencjonowania produktów: w przypadku klastra kilku urządzeń wymagana jest tylko jedna licencja na maksymalną liczbę jednoczesnych połączeń. Zdecydowano się także na połączenie licencji na połączenie z serwerem proxy z licencjami na połączenie przez tunel TLS. Wszystko to ułatwia obsługę i wybór odpowiedniej architektury rozwiązania.
W lipcu 2018 r. „Continent TLS Server” 2.1 został zgłoszony do certyfikacji FSB Rosji. Po pozytywnym przejściu testów wyrób będzie certyfikowany w klasach KS1 i KS2.
| Ta wersja produktu Continent TLS Server ma za zadanie ułatwić pracę administratorom w okresie zmiany standardów szyfrowania oraz zapewnić możliwość wygodnego monitorowania. Zmiany w polityce licencyjnej i możliwość wydzielenia osobnego portu do zarządzania produktem powinny rozszerzyć zakres jego zastosowania. Obsługa szerokiej gamy klientów TLS pozwoli Ci szybko zbudować system bezpiecznego dostępu do aplikacji internetowej, w której korzystają już zewnętrzni dostawcy kryptowalut. Teraz nasz produkt obsługuje „CryptoPro”, „Validata” i zaufaną przeglądarkę „Sputnik”. |
2016
Wysoką dynamikę wykazały także stosunkowo nowe (wydane w 2015 roku) produkty linii „Continent” – „Continent TLS VPN” oraz kryptoprzełącznik „Continent”. Ich wielkość sprzedaży wyniosła 71 milionów rubli. i 62 miliony rubli. odpowiednio. Zapotrzebowanie na „Continent TLS VPN” wynikało z rosnącego zainteresowania klientów wykorzystaniem rosyjskich algorytmów szyfrujących do ochrony dostępu do portali rządowych, a także organizowaniem bezpiecznego zdalnego dostępu przy użyciu algorytmów GOST. Czynnikiem wzrostu sprzedaży przełączników kryptograficznych Continent była potrzeba ochrony kanałów komunikacyjnych w rozproszonych geograficznie centrach danych.
Wydano wersję techniczną „Continent TLS VPN” 1.0.9 z portalem aplikacji
Firma Security Code ogłosiła w kwietniu 2016 wydanie wersji technicznej produktu „Continent TLS VPN”, zaprojektowanego w celu zapewnienia bezpiecznego zdalnego dostępu do systemów informatycznych przetwarzających dane osobowe (ISPD) i rządowych systemów informacyjnych (GIS). Produkt posiada szereg nowych funkcji.
Jedna z najważniejszych zmian w „Kontynent TLS VPN” 1.0.9 to utworzenie portalu aplikacyjnego z możliwością uwierzytelniania i autoryzacji przy użyciu poświadczeń z Active Directory. Ulepszenie to znacznie upraszcza proces zarządzania dostępem do korporacyjnych serwisów WWW dla różnych kategorii użytkowników. Przykładowo za pomocą portalu można zapewnić jeden punkt dostępu pracownikom firmy i jej kontrahentom. W tym przypadku zestaw dostępnych aplikacji będzie zależny od kategorii i uprawnień użytkownika.
Kolejną różnicą jest dodanie możliwości utworzenia strony startowej serwera, dostępnej poprzez otwarty protokół HTTP. Pozwala znacznie obniżyć koszty utrzymania bezpiecznej aplikacji internetowej.
Wersja 1.0.9 dodaje także możliwość obsługi produktu w trybie tunelowym TLS, co pozwala użytkownikowi zdalnemu usunąć ograniczenia w interakcji poprzez kanał szyfrowany przy użyciu protokołu TLS. Takie połączenie pozwala na zapewnienie dostępu nie tylko do zasobów sieciowych, ale także do innych typów aplikacji, na przykład serwerów terminalowych (poprzez protokół RDP) czy „grubych klientów” dla aplikacji korporacyjnych (ERP, CRM itp.). Takie podejście znacznie zwiększa liczbę scenariuszy dostępu zdalnego, w których można zastosować Continent TLS VPN.
„Kodeks bezpieczeństwa” ocenił moment przejścia agencji rządowych na rosyjskie narzędzia szyfrujące
16 lipca 2016 r. na kremlowskiej stronie internetowej opublikowano zarządzenie Prezydenta skierowane do szefa rządu w sprawie konieczności przygotowania do 1 grudnia 2017 r. przejścia organów władzy na stosowanie rosyjskich algorytmów kryptograficznych i narzędzi szyfrujących. W szczególności rząd musi zapewnić opracowanie i wdrożenie zestawu środków niezbędnych do stopniowego przejścia na stosowanie rosyjskich algorytmów kryptograficznych i narzędzi szyfrowania, a także zapewnić obywatelom Federacji Rosyjskiej swobodny dostęp do korzystania z rosyjskiego szyfrowania narzędzia.
Opublikowany dokument będzie obejmował określone kroki mające na celu dostosowanie infrastruktury IT agencji rządowych do określonych wymagań. W szczególności oczekuje się masowych instalacji krajowych narzędzi ochrony informacji kryptograficznej (CIPF), oprócz istniejących rozwiązań, w agencjach rządowych.
Więcej szczegółów:
- Ustawa Yarovaya (w sprawie zmian w Kodeksie karnym i Kodeksie postępowania karnego Federacji Rosyjskiej w zakresie ustanowienia dodatkowych środków zwalczania terroryzmu)
Eksperci ds. Kodeksu Bezpieczeństwa zauważają, że innowacja będzie dotyczyć przede wszystkim portali usług rządowych departamentów federalnych i regionalnych. Jednocześnie realizacja tego zadania wpływa na dwa aspekty: wdrożenie CIPF po stronie serwera WWW i po stronie użytkownika. Jeśli założymy, że użytkownicy osadzą w przeglądarce certyfikowaną bibliotekę kryptograficzną, to problem po stronie serwera WWW można rozwiązać na dwa sposoby.
Jednym z nich jest integracja CIPF z serwerami internetowymi, drugim jest wdrożenie kompleksu oprogramowania i sprzętu (SHC) z implementacją TLS VPN (jednym z takich produktów jest „Continent TLS VPN Server”, opracowany przez „ Security Code”), który przechwyci ruch HTTP/HTTPS i zaszyfruje go zgodnie z algorytmem szyfrowania zgodnym z GOST (28147-89). Każda z opcji ma swoją własną charakterystykę - zarówno z punktu widzenia realizacji technicznej, jak i z punktu widzenia harmonogramu projektu.
Zdaniem analityków Security Code, w pierwszym przypadku (osadzanie) etapy pracy będą wyglądać następująco:
- Opracowanie dokumentacji organizacyjno-administracyjnej (ORD) – 2 miesiące;
- Wdrożenie - 0,5 miesiąca;
- Monitorowanie integracji CIPF z FSB Rosji - 7 miesięcy;
Dzięki temu taki projekt można zrealizować w ciągu 1 roku.
Wybierając opcję instalacji PAC, projekt zostanie podzielony na następujące etapy:
- Opracowanie dokumentacji operacyjnej - 2 miesiące;
- Przeprowadzenie otwartego konkursu poniżej 44-FZ - 2,5 miesiąca;
- Dostawa sprzętu i oprogramowania - 1,5 miesiąca;
- Wdrożenie - 0,5 miesiąca.
Całkowity czas trwania projektu w tym przypadku wyniesie około 7 miesięcy.
Eksperci Kodeksu Bezpieczeństwa zauważają, że zgodnie z ogólnie przyjętą praktyką od wydania instrukcji rządowi do rozpoczęcia przez firmy prac nad projektami (biorąc pod uwagę konieczność opracowania i przyjęcia regulaminów) upływają co najmniej trzy miesiące. W związku z tym istnieje ryzyko, że organizacje, które zdecydują się na osadzenie CIPF na serwerach internetowych, będą miały trudności z dotrzymaniem wyznaczonych przez prezydenta terminów. A jeśli przyjęcie regulaminu opóźni się o ponad trzy miesiące, terminy jego wdrożenia mogą zostać przekroczone.
„Oprócz trudności z synchronizacją, pierwsza ścieżka – osadzanie – wiąże się z innymi trudnościami. Są to dodatkowe koszty pracy, najpierw za przygotowanie i zatwierdzenie pakietu dokumentów dla laboratorium testującego, a następnie za wprowadzenie zmian w kodzie i debugowanie aplikacji w oparciu o wyniki analizy laboratorium testującego. Jednak główną zaletą drugiej opcji jest to, że wybierając PAK, klient otrzymuje wydajne, wydajne rozwiązanie przemysłowe przeznaczone dla dużych organizacji. Jest skalowalny, łatwy w zarządzaniu, kompatybilny z dowolną przeglądarką internetową i łatwo integruje się z zewnętrznymi systemami SIEM” – powiedział Pavel Korostelev, menadżer ds. marketingu produktów w Code Security.
Biorąc pod uwagę powyższe, „Kodeks Bezpieczeństwa” zaleca, aby klienci rządowi wybrali optymalny algorytm pod kątem spełnienia wymogów prawnych i podążali ścieżką wdrożenia systemu programowo-sprzętowego (SHC) wraz z wdrożeniem TLS VPN. W celu bezpiecznego dostępu zdalnych użytkowników do zasobów sieciowych wykorzystywany jest kompleks oprogramowania i sprzętu „Continent TLS VPN” certyfikowany przez FSB Rosji. Jest łatwy we wdrożeniu, ma darmowego klienta TLS dla użytkowników końcowych i może obsługiwać ponad 100 tys. jednoczesnych połączeń.
Rosja z dnia 30 lipca 2015 r. SF/124–2676 na CIPF „Continent TLS VPN Server” i SF/525-2677, SF/525-2678 na CIPF „Continent TLS VPN Client” (wersja 1 i 2) potwierdzają zgodność z wymagania FSB Rosja dotyczące środków szyfrujących (kryptograficznych) klasy KS2 i KS1. Certyfikaty FSB Rosji upoważniają do stosowania CIPF „Continent TLS VPN” do kryptograficznej ochrony informacji, które nie zawierają informacji stanowiących tajemnicę państwową.
Certyfikat FSTEC Rosji nr 3286, wydany 2 grudnia 2014 r. dla CIPF „Continent TLS VPN Server”, potwierdza zgodność produktu z wymaganiami dokumentów regulujących 4. poziom kontroli pod kątem braku niezgodności -zgodność i umożliwia jego zastosowanie przy tworzeniu systemów do klasy bezpieczeństwa 1G włącznie oraz do ochrony informacji w ISPDn i GIS do 1 stopnia włącznie.
