Przegląd: Oprogramowanie kontra sprzęt

Google Authenticator to programowy generator haseł jednorazowych. Działa na smartfonach, generując kody czasowe w celu weryfikacji tożsamości użytkownika. Natomiast YubiKey to sprzętowy klucz bezpieczeństwa. Użytkownicy fizycznie wkładają klucz lub przystawiają go do czytnika NCF w celu uwierzytelnienia.

Wiele organizacji korzysta z obu rozwiązań do uwierzytelniania logowań pracowników i klientów. Obie opcje są dostępne w popularnych platformach MFA, takich jak Rublon MFA, która usprawnia bezpieczny dostęp do systemów korporacyjnych dzięki solidnemu uwierzytelnianiu wieloskładnikowemu.

Google Authenticator vs. YubiKey: Jaka jest różnica?

Główna różnica tkwi w sposobie działania i cenie. Google Authenticator to darmowe oprogramowanie na urządzenia mobilne, natomiast YubiKey to płatny klucz fizyczny, który podłącza się do urządzenia lub łączy z nim bezprzewodowo. Różnic jest jednak więcej.

Oto przydatna tabela porównująca oba rozwiązania.

YubiKey vs. Google Authenticator: Tabela różnic

Zalety YubiKey w porównaniu z Google Authenticator

1. Silniejsze bezpieczeństwo fizyczne: YubiKey to namacalny token. Atakujący muszą go posiadać fizycznie, aby włamać się do systemu. Zmniejsza to ryzyko zagrożeń, takich jak złośliwe oprogramowanie, i udaremnia wiele rodzajów ataków.
2. Odporność na phishing: Klucze YubiKey są odporne na phishing, co umożliwia zastosowanie niezwykle bezpiecznego uwierzytelniania wieloskładnikowego (MFA) odpornego na phishing.
3. Zgodność z rygorystycznymi przepisami: YubiKey jest uważany za najbezpieczniejszy rodzaj uwierzytelniania, zapewniając tym samym lepszą zgodność nawet z najbardziej rygorystycznymi przepisami dotyczącymi cyberbezpieczeństwa, takimi jak Federal Zero Trust Strategy Memorandum i NIST SP 800-63B AAL3.
4. Szerszy zestaw opcji uwierzytelniania: Nowsze modele YubiKey obsługują wiele standardów uwierzytelniania. Mogą to być Yubico OTP, FIDO U2F i FIDO2. Ta elastyczność oferuje więcej opcji dla wdrożeń korporacyjnych.

Zalety Google Authenticator w porównaniu z YubiKey

1. Brak kosztów sprzętu: Google Authenticator jest darmowy i wymaga jedynie smartfona lub tabletu. Dzięki temu jest opłacalny dla mniejszych zespołów i oszczędnych użytkowników domowych.
2. Szeroka popularność: Chociaż popularność kluczy YubiKey rośnie z roku na rok, Google Authenticator jest nadal szerzej wspieraną opcją.
3. Natychmiastowa dostępność: Użytkownicy mogą pobrać aplikację i od razu rozpocząć zabezpieczanie kont, bez konieczności czekania na przesyłkę czy fizycznego zarządzania kluczami.

Kwestie dotyczące przedsiębiorstw

Zarówno Google Authenticator, jak i YubiKey mogą zabezpieczać aplikacje biznesowe, ale wybór często zależy od budżetu, przeszkolenia użytkowników i wymogów zgodności.

1. Integracja MFA: Wybierz dostawcę MFA, który obsługuje obie opcje. Na przykład Rublon MFA umożliwia firmom zarządzanie metodami uwierzytelniania Google Authenticator i YubiKey w ramach jednej platformy. Administratorzy uzyskują scentralizowaną kontrolę nad wdrażaniem użytkowników, egzekwowaniem zasad i rejestrami użytkowania.
2. Złożoność wdrożenia: Uwierzytelnianie programowe może skalować się szybciej w rozproszonej kadrze, ponieważ pracownicy posiadają już smartfony. Klucze sprzętowe, takie jak YubiKey, są znacznie bezpieczniejsze, ale wymagają dystrybucji do wszystkich użytkowników, a tym samym dodatkowej logistyki.
3. Koszt w czasie: Google Authenticator nie generuje bezpośrednich kosztów poza potencjalną konserwacją telefonu. Jednak niższy poziom bezpieczeństwa może prowadzić do naruszenia bezpieczeństwa, które może okazać się kosztowne dla organizacji, zarówno pod względem finansowym, jak i reputacyjnym. Z kolei YubiKey wymaga początkowej inwestycji, ale oferuje wyjątkowo silną ochronę przed phishingiem, znacznie zmniejszając prawdopodobieństwo naruszenia bezpieczeństwa.

Którą opcję wybrać?

Wybór między Google Authenticator a YubiKey zależy od kilku czynników. Chociaż budżet ma znaczenie, kluczowe jest bezpieczeństwo. Rozwiązania programowe są łatwiejsze i tańsze we wdrożeniu. YubiKey oferuje jednak wyższy poziom bezpieczeństwa. To sprawia, że ​​YubiKey jest preferowany przez każdą organizację dbającą o bezpieczeństwo i zgodność z przepisami.

Rozwiązania dla przedsiębiorstw, takie jak Rublon MFA, upraszczają jednoczesne korzystanie z obu metod. Może to być idealne rozwiązanie dla organizacji poszukujących silnej ochrony MFA dla kont uprzywilejowanych (za pośrednictwem YubiKey), oferując jednocześnie przyjazną dla użytkownika alternatywę (za pośrednictwem Google Authenticator) dla pozostałych pracowników.

Szukasz kluczy bezpieczeństwa FIDO2? Mamy je!

Potrzebujesz niezawodnych kluczy bezpieczeństwa FIDO2 dla swoich pracowników lub klientów? Pomożemy Ci wybrać odpowiednie modele.

Rozpocznij bezpłatny okres próbny Rublon MFA już dziś

Wypróbuj 30 dni bezpłatnego uwierzytelniania wieloskładnikowego Rublon.

Wzmocnij swoje zabezpieczenia dzięki logowaniu odpornemu na phishing, wdróż klucze bezpieczeństwa FIDO2 i korzystaj z Google Authenticator (i innych aplikacji mobilnych MFA), aby bezproblemowo podnieść poziom bezpieczeństwa swojej organizacji.

Aby rozpocząć bezpłatny okres próbny, kliknij poniższy przycisk.

The post Google Authenticator vs. YubiKey: czym się różnią? appeared first on Rublon.

Uwierzytelnianie wieloskładnikowe (MFA) dla usługi SOGo zapewnia dodatkową warstwę bezpieczeństwa podczas logowania do SOGo. Użytkownicy muszą przejść zarówno uwierzytelnianie podstawowe (login/hasło), jak i dodatkowe (np. Powiadomienie mobilne). Nawet jeśli cyberprzestępca zna hasło użytkownika, nie uzyska dostępu bez ukończenia drugiego kroku.

Omówienie uwierzytelniania MFA dla usługi SOGo

W tej dokumentacji opisano, jak zintegrować Rublon MFA z usługą SOGo przy użyciu protokołu LDAP(S), aby włączyć uwierzytelnianie wieloskładnikowe dla logowań użytkowników.

Rublon MFA dla SOGo integruje się za pośrednictwem usługi Rublon Authentication Proxy, obsługującej protokół LDAP(S). Dzięki temu tylko autoryzowani użytkownicy mogą wykonać dodatkową metodę uwierzytelniania, uniemożliwiając dostęp potencjalnym intruzom.

Wspierane metody uwierzytelniania

Metoda uwierzytelniania	Czy wspierana	Komentarz
Powiadomienie mobilne		N/A
Klucz bezpieczeństwa WebAuthn/U2F	–	N/A
Kod dostępu		N/A
Kod SMS	–	N/A
Link SMS		N/A
Połączenie telefoniczne		N/A
Kod QR	–	N/A
Link e-mail		N/A
Klucz bezpieczeństwa YubiKey OTP		N/A

Zanim zaczniesz konfigurować uwierzytelnianie MFA dla usługi SOGo

Przed skonfigurowaniem uwierzytelniania Rublon MFA dla SOGo:

• Upewnij się, że wszystkie wymagane komponenty są gotowe.
• Utwórz aplikację w konsoli Rublon Admin Console.
• Zainstaluj aplikację mobilną Rublon Authenticator.

Wymagane komponenty

1. Dostawca tożsamości (IdP) — potrzebujesz zewnętrznego dostawcy tożsamości, takiego jak Microsoft Active Directory, OpenLDAP czy FreeIPA.

2. Rublon Authentication Proxy – zainstaluj usługę Rublon Authentication Proxy, jeśli jeszcze nie jest zainstalowana oraz skonfiguruj usługę Rublon Authentication Proxy jako serwer proxy LDAP.

3. SOGo – Poprawnie zainstalowany i skonfigurowany serwer SOGo.

Utwórz aplikację w konsoli Rublon Admin Console

1. Zarejestruj się w konsoli Rublon Admin Console. Oto jak to zrobić.

2. W konsoli Rublon Admin Console przejdź do zakładki Applications (Aplikacje) i kliknij Add Application (Dodaj aplikację).

3. Wprowadź nazwę swojej aplikacji (np. SOGo), a następnie ustaw jej typ na Rublon Authentication Proxy.

4. Kliknij przycisk Save (Zapisz), aby dodać nową aplikację w konsoli Rublon Admin Console.

5. Skopiuj i zapisz wartości System Token i Secret Key. Te wartości będą Ci potrzebne później.

Zainstaluj aplikację Rublon Authenticator

Niektórzy użytkownicy końcowi prawdopodobnie skorzystają z aplikacji mobilnej Rublon Authenticator. Dlatego też, jako osoba konfigurująca uwierzytelnianie MFA dla usługi SOGo, zdecydowanie zalecamy Ci zainstalowanie aplikacji mobilnej Rublon Authenticator. Dzięki temu możliwe będzie przetestowanie uwierzytelniania MFA dla usługi SOGo za pomocą metody uwierzytelniania Powiadomienie mobilne.

Pobierz aplikację Rublon Authenticator dla systemu:

• Android
• iOS
• HarmonyOS

Konfiguracja uwierzytelniania wieloskładnikowego (MFA) dla usługi SOGo

Rublon Authentication Proxy

1. Edytuj plik konfiguracyjny usługi Rublon Auth Proxy i wklej wcześniej skopiowane wartości System Token i Secret Key odpowiednio w opcjach system_token i secret_key.

2. Przykładowa konfiguracja w pliku YAML:

log:
  debug: true

rublon:
  api_server: https://core.rublon.net
  system_token: YOURSYSTEMTOKEN
  secret_key: YOURSECRETKEY

proxy_servers:
- name: LDAP-Proxy
  type: LDAP
  ip: 0.0.0.0
  port: 636
  auth_source: LDAP_SOURCE_1
  auth_method: push, email
  rublon_section: rublon
  cert_path: /etc/ssl/certs/ca.crt
  pkey_path: /etc/ssl/certs/key.pem

auth_sources:
- name: LDAP_SOURCE_1
  type: LDAP
  ip: 192.0.2.0
  port: 636
  transport_type: ssl
  search_dn: dc=example,dc=org
  access_user_dn: cn=admin,dc=example,dc=org
  access_user_password: CHANGE_ME
  ca_certs_dir_path: /etc/ssl/certs/

Zobacz: Jak skonfigurować certyfikaty LDAPS w Rublon Authentication Proxy?

SOGo

Otwórz plik sogo.conf i dodaj blok „SOGoUserSources =” z danymi LDAP. Zapoznaj się z poniższym blokiem i tabelą.

SOGoUserSources = (
  {
    type = ldap;
    CNFieldName = cn;
    UIDFieldName = sAMAccountName;
    bindFields = (sAMAccountName, userPrincipalName);
    baseDN = "ou=Users,dc=my,dc=organization,dc=domain";
    bindDN = "CN=rublonadmin,OU=Rublon,DC=rublondemo,DC=local";
    bindPassword = "eHJFKF5jC5QqM6ci";
    canAuthenticate = YES;
    hostname = "ldaps://192.0.2.0:636";
    filter = "objectClass='user'";
    id = directory;
  }
);

Więcej informacji można znaleźć w oficjalnej dokumentacji SOGo dotyczącej uwierzytelniania LDAP.

Testowanie uwierzytelniania wieloskładnikowego (MFA) dla usługi SOGo

Ten przykład przedstawia logowanie wieloskładnikowe do usługi SOGo. Metoda uwierzytelniania Powiadomienie mobilne została ustawiona jako drugi czynnik w konfiguracji usługi Rublon Authentication Proxy (Parametr AUTH_METHOD został ustawiony na Push).

1. Otwórz panel SOGo, wprowadź nazwę użytkownika oraz hasło i wciśnij Enter.

2. Otrzymasz żądanie uwierzytelniania za pomocą metody Powiadomienie mobilne na swój telefon. Wybierz ZATWIERDŹ.

3. Otrzymasz dostęp do usługi SOGo.

Rozwiązywanie problemów z uwierzytelnianiem MFA dla usługi SOGo

Jeśli napotkasz jakiekolwiek problemy z integracją Rublon, skontaktuj się z pomocą techniczną Rublon Support.

Powiązane posty

Rublon Authentication Proxy

Rublon Authentication Proxy – Integracje

The post Uwierzytelnianie wieloskładnikowe (2FA/MFA) dla SOGo appeared first on Rublon.

API a SDK: czym się różnią?

Główną różnicą między API a SDK jest ich cel i zawartość. API to zestaw protokołów i definicji służących do tworzenia i integrowania oprogramowania aplikacyjnego. Natomiast SDK to kompleksowy zestaw narzędzi zawierający biblioteki, dokumentację i przykłady kodu do tworzenia aplikacji na określoną platformę.

Jednak różnic jest znacznie więcej.

Oto przydatna tabela przedstawiająca najważniejsze różnice między interfejsami API a zestawami SDK.

API vs. SDK: Tabela różnic

Praktyczne przykłady interfejsów API i zestawów SDK

Aby lepiej zrozumieć różnice, przyjrzyjmy się praktycznym przykładom.

API w akcji:

• Aplikacja pogodowa używa API do pobierania danych pogodowych w czasie rzeczywistym z serwisu pogodowego.
• Platformy mediów społecznościowych udostępniają API, które umożliwiają programistom integrację funkcji logowania lub udostępniania w swoich aplikacjach.
• Rublon korzysta z API, takich jak Rublon Admin API i Rublon REST API.

SDK w akcji:

• Zestaw Android SDK umożliwia programistom tworzenie aplikacji na Androida za pomocą narzędzi i bibliotek specyficznych dla platformy Android.
• Twórcy gier używają Unreal Engine SDK do tworzenia gier z zaawansowaną grafiką i fizyką.
• Rublon wykorzystuje SDK do dodawania zaawansowanego uwierzytelniania wieloskładnikowego (MFA) do aplikacji napisanych w Javie, PHP i .NET.

Zalety zestawów SDK w porównaniu z interfejsami API

Oto powody, dla których zestaw SDK może być lepszym wyborem:

• Zestawy SDK zapewniają wszystkie niezbędne narzędzia do tworzenia oprogramowania, skracając czas i zmniejszając nakład pracy.
• Zawierają przykładowy kod i dokumentację, upraszczając proces nauki.
• Zestawy SDK oferują narzędzia do debugowania i testowania, poprawiając jakość kodu.
• Umożliwiają bezproblemową integrację z platformą docelową.

Zalety interfejsów API w porównaniu z zestawami SDK

Oto dlaczego API może być lepszym wyborem:

• Interfejsy API umożliwiają interakcję z istniejącymi usługami bez konieczności tworzenia ich od podstaw.
• Są lekkie i nie wymagają instalowania dużych zestawów narzędzi.
• Interfejsy API oferują elastyczność w różnych językach programowania.
• Umożliwiają integrację z usługami innych firm, rozszerzając ich funkcjonalność.

Kiedy wybrać które rozwiązanie

• Wybierz API, jeśli potrzebujesz wykorzystać istniejące dane lub funkcje.
• Wybierz SDK, gdy musisz stworzyć, przetestować i dostarczyć oprogramowanie przeznaczone na konkretną platformę lub urządzenie.

Wnioski

API służy do integrowania oprogramowania, a SDK do jego tworzenia. Podejmowanie decyzji o tworzeniu lub integracji w oparciu o aktualne statystyki, rzeczywiste studia przypadków i uznane standardy pozwala osiągnąć szybsze, bezpieczniejsze i łatwiejsze w utrzymaniu rozwiązania.

Rozpocznij bezpłatny okres próbny Rublon MFA już dziś

Wypróbuj Rublon MFA za darmo przez 30 dni

Chroń swoją organizację dzięki odpornemu na phishing uwierzytelnianiu MFA, wykorzystując intefejs Rublon API i pakiety Rublon SDK dla różnych języków programowania. Zwiększ bezpieczeństwo bez komplikacji i kosztów.

Aby rozpocząć bezpłatny okres próbny, kliknij poniższy przycisk.

The post API vs. SDK: czym się różnią? appeared first on Rublon.

Co to jest szyfrowanie?

Szyfrowanie polega na ukryciu informacji w formie zakodowanej, dostępnej jedynie osobom posiadającym właściwy klucz. Istnieją dwa główne rodzaje szyfrowania: szyfrowanie symetryczne, w którym ten sam klucz jest używany zarówno do szyfrowania, jak i deszyfrowania, oraz szyfrowanie asymetryczne, które wykorzystuje parę kluczy, z których jeden jest publiczny, a drugi prywatny.

Co to jest AES?

AES (Advanced Encryption Standard) to symetryczny algorytm szyfrowania, który używa tego samego klucza do szyfrowania i deszyfrowania. Jest szeroko stosowany do zabezpieczania danych w spoczynku i w trakcie transmisji ze względu na swoją szybkość i silne zabezpieczenia.

Co to jest RSA?

RSA (Rivest–Shamir–Adleman) to asymetryczny algorytm szyfrowania, który wykorzystuje klucz publiczny do szyfrowania danych i klucz prywatny do ich odszyfrowania. Jest powszechnie używany do bezpiecznej wymiany kluczy, podpisów cyfrowych i szyfrowania niewielkich ilości poufnych danych.

RSA kontra AES: jaka jest różnica?

Główna różnica między AES a RSA leży w metodologii szyfrowania. AES to algorytm szyfrowania symetrycznego, co oznacza, że ​​używa tego samego klucza do szyfrowania i deszyfrowania. Z kolei RSA to algorytm szyfrowania asymetrycznego, który wykorzystuje parę kluczy – klucz publiczny do szyfrowania i klucz prywatny do deszyfrowania.

AES vs. RSA: Tabela różnic

Praktyczne przykłady AES i RSA

Aby lepiej zrozumieć różnice, przyjrzyjmy się praktycznym przykładom.

AES w akcji:

• Szyfrowanie plików na dysku twardym w celu ochrony przed nieautoryzowanym dostępem.
• Zabezpieczanie danych przesyłanych przez sieci Wi-Fi.
• Ochrona poufnych danych w transakcjach online.

RSA w akcji:

• Nawiązywanie bezpiecznego połączenia między przeglądarką internetową a serwerem za pośrednictwem protokołu HTTPS.
• Wysyłanie zaszyfrowanych wiadomości e-mail, które może odszyfrować tylko zamierzony odbiorca.
• Generowanie kluczowych komponentów (np. dużych liczb pierwszych) stanowiących podstawę operacji kryptograficznych w uwierzytelnianiu wieloskładnikowym (MFA).

Zalety AES w porównaniu z RSA

1. Szybkość i wydajność: AES jest szybszy i wymaga mniejszej mocy obliczeniowej, dzięki czemu idealnie nadaje się do szyfrowania dużych ilości danych.
2. Prostota: Używa tego samego klucza do szyfrowania i deszyfrowania, upraszczając proces szyfrowania.
3. Silne zabezpieczenia danych w spoczynku: Doskonały do szyfrowania przechowywanych danych, aby zapobiec nieautoryzowanemu dostępowi.

Zalety RSA w porównaniu z AES

1. Bezpieczna wymiana kluczy: Umożliwia bezpieczną transmisję danych bez udostępniania klucza prywatnego.
2. Podpisy cyfrowe: Obsługuje uwierzytelnianie za pomocą podpisów cyfrowych, weryfikując tożsamość nadawcy.
3. Integralność danych: Zapewnia, że ​​dane nie zostały zmodyfikowane podczas transmisji.

Który algorytm wybrać?

To zależy od zastosowania:

• Wybierz AES, jeśli potrzebujesz szybkiego i wydajnego szyfrowania dużych wolumenów danych, na przykład do zabezpieczania plików, baz danych, ruchu VPN lub szyfrowania całego dysku. To idealne rozwiązanie, gdy zarówno nadawca, jak i odbiorca mogą bezpiecznie korzystać z tego samego klucza.
• Wybierz RSA, gdy wymagana jest bezpieczna wymiana kluczy, podpisy cyfrowe lub weryfikacja tożsamości, szczególnie w scenariuszach takich jak połączenia HTTPS/TLS, szyfrowana poczta e-mail lub infrastruktura certyfikatów cyfrowych, gdzie kryptografia klucza publicznego jest niezbędna.

Wnioski

AES i RSA pełnią różne, ale uzupełniające się role we współczesnej kryptografii. AES oferuje szybkość i wydajność szyfrowania dużych zbiorów danych, podczas gdy RSA zapewnia bezpieczne mechanizmy wymiany kluczy i uwierzytelniania. Zrozumienie ich mocnych stron pomoże Ci wybrać odpowiednie podejście do szyfrowania, dostosowane do Twoich specyficznych wymagań w zakresie bezpieczeństwa i wydajności.

Rozpocznij bezpłatny okres próbny Rublon MFA już dziś

Aby w pełni chronić swoją organizację, potrzebujesz czegoś więcej niż tylko silnego szyfrowania. Musisz zapewnić, że dostęp do danych mają wyłącznie uprawnione osoby.

W tym miejscu z pomocą przychodzi uwierzytelnianie wieloskładnikowe (MFA).

Wypróbuj Rublon MFA za darmo przez 30 dni, aby zabezpieczyć loginy pracowników, wdrożyć klucze bezpieczeństwa i klucze dostępu FIDO2 w ciągu kilku minut i szybko wzmocnić bezpieczeństwo swojej organizacji.

Aby rozpocząć bezpłatny okres próbny, kliknij przycisk poniżej.

The post AES vs. RSA: czym się różnią? appeared first on Rublon.

Omówienie uwierzytelniania MFA dla usługi Zabbix przy użyciu protokołu LDAP(S)

W tej dokumentacji opisano, jak zintegrować Rublon MFA z usługą Zabbix przy użyciu protokołu LDAP(S), aby umożliwić uwierzytelnianie wieloskładnikowe dla logowań do usługi Zabbix.

Wspierane metody uwierzytelniania

Metoda uwierzytelniania	Czy wspierana	Komentarz
Powiadomienie mobilne		N/A
Klucz bezpieczeństwa WebAuthn/U2F	–	N/A
Kod dostępu		N/A
Kod SMS	–	N/A
Link SMS		N/A
Połączenie telefoniczne		N/A
Kod QR	–	N/A
Link e-mail		N/A
Klucz bezpieczeństwa YubiKey OTP		N/A

Film demonstracyjny

Zanim zaczniesz konfigurować uwierzytelnianie MFA dla usługi Zabbix przy użyciu protokołu LDAP(S)

Przed skonfigurowaniem uwierzytelniania Rublon MFA dla Zabbix:

• Upewnij się, że wszystkie wymagane komponenty są gotowe.
• Utwórz aplikację w konsoli Rublon Admin Console.
• Zainstaluj aplikację mobilną Rublon Authenticator.

Wymagane komponenty

1. Dostawca tożsamości (IdP) — potrzebujesz zewnętrznego dostawcy tożsamości, takiego jak Microsoft Active Directory, OpenLDAP czy FreeIPA.

2. Rublon Authentication Proxy – zainstaluj usługę Rublon Authentication Proxy, jeśli jeszcze nie jest zainstalowana oraz skonfiguruj usługę Rublon Authentication Proxy jako serwer proxy LDAP.

3. Zabbix – Prawidłowo zainstalowana i skonfigurowana usługa Zabbix.

Utwórz aplikację w konsoli Rublon Admin Console

1. Zarejestruj się w konsoli Rublon Admin Console. Oto jak to zrobić.

2. W konsoli Rublon Admin Console przejdź do zakładki Applications (Aplikacje) i kliknij Add Application (Dodaj aplikację).

3. Wprowadź nazwę swojej aplikacji (np. Zabbix), a następnie ustaw jej typ na Rublon Authentication Proxy.

4. Kliknij przycisk Save (Zapisz), aby dodać nową aplikację w konsoli Rublon Admin Console.

5. Skopiuj i zapisz wartości System Token i Secret Key. Te wartości będą Ci potrzebne później.

Zainstaluj aplikację Rublon Authenticator

Niektórzy użytkownicy końcowi prawdopodobnie skorzystają z aplikacji mobilnej Rublon Authenticator. Dlatego też, jako osoba konfigurująca uwierzytelnianie MFA dla usługi Zabbix, zdecydowanie zalecamy Ci zainstalowanie aplikacji mobilnej Rublon Authenticator. Dzięki temu możliwe będzie przetestowanie uwierzytelniania MFA dla usługi Zabbix za pomocą metody uwierzytelniania Powiadomienie mobilne.

Pobierz aplikację Rublon Authenticator dla systemu:

• Android
• iOS
• HarmonyOS

Konfiguracja uwierzytelniania wieloskładnikowego (MFA) dla usługi Zabbix przy użyciu protokołu LDAP(S)

Rublon Authentication Proxy

1. Edytuj plik konfiguracyjny usługi Rublon Auth Proxy i wklej wcześniej skopiowane wartości System Token i Secret Key odpowiednio w opcjach system_token i secret_key.

2. Przykładowa konfiguracja w pliku YAML:

log:
  debug: true

rublon:
  api_server: https://core.rublon.net
  system_token: YOURSYSTEMTOKEN
  secret_key: YOURSECRETKEY

proxy_servers:
- name: LDAP-Proxy
  type: LDAP
  ip: 0.0.0.0
  port: 636
  auth_source: LDAP_SOURCE_1
  auth_method: push, email
  rublon_section: rublon
  cert_path: /etc/ssl/certs/ca.crt
  pkey_path: /etc/ssl/certs/key.pem

auth_sources:
- name: LDAP_SOURCE_1
  type: LDAP
  ip: 172.16.0.127
  port: 636
  transport_type: ssl
  search_dn: dc=example,dc=org
  access_user_dn: cn=admin,dc=example,dc=org
  access_user_password: CHANGE_ME
  ca_certs_dir_path: /etc/ssl/certs/

Zabbix

1. Zaloguj się do panelu administracyjnego Zabbix.

2. W panelu po lewej przejdź do Users → Authentication → LDAP Settings.

3. Zaznacz Enable LDAP authentication oraz Enable JIT provisioning.

4. W Servers, wybierz Add. Wypełnij pola. Zapoznaj się z poniższym obrazkiem i tabelą.

5. Wybierz Test w celu przetestowania konfiguracji, a następnie Add, aby zapisać nowoutworzony serwer.

6. Wybierz ponownie Update, aby zapisać zmiany w ustawieniach LDAP.

7. W Authentication, ustaw Default authentication na LDAP i wybierz Update.

Testowanie uwierzytelniania wieloskładnikowego (MFA) dla usługi Zabbix zintegrowanego za pośrednictwem protokołu LDAP(S)

Ten przykład przedstawia logowanie wieloskładnikowe do usługi Zabbix. Metoda uwierzytelniania Powiadomienie mobilne została ustawiona jako drugi czynnik w konfiguracji usługi Rublon Authentication Proxy (Parametr AUTH_METHOD został ustawiony na push).

1. Zaloguj się do usługi Zabbix jako użytkownik, wpisując swoją nazwę użytkownika i hasło, a następnie kliknij Sign in.

2. Otrzymasz żądanie uwierzytelniania za pomocą metody Powiadomienie mobilne na swój telefon. Wybierz ZATWIERDŹ.

3. Otrzymasz dostęp do usługi Zabbix.

Rozwiązywanie problemów z uwierzytelnianiem MFA dla usługi Zabbix przy użyciu protokołu LDAP(S)

Jeśli napotkasz jakiekolwiek problemy z integracją Rublon, skontaktuj się z pomocą techniczną Rublon Support.

Powiązane posty

Rublon Authentication Proxy

Rublon Authentication Proxy – Integracje

The post Uwierzytelnianie wieloskładnikowe (2FA/MFA) dla Zabbix – protokół LDAP(S) appeared first on Rublon.

Zintegrowany kontroler zdalnego dostępu Dell (Integrated Dell Remote Access Controller, iDRAC) to wbudowane narzędzie do zarządzania w serwerach Dell PowerEdge, które umożliwia bezpieczne, zdalne monitorowanie, konfigurację i rozwiązywanie problemów bez użycia agentów, nawet gdy serwer jest wyłączony.

Uwierzytelnianie wieloskładnikowe (MFA) dla usługi Dell iDRAC zapewnia dodatkową warstwę bezpieczeństwa podczas logowania do iDRAC. Użytkownicy muszą przejść zarówno uwierzytelnianie podstawowe (login/hasło), jak i dodatkowe (np. Powiadomienie mobilne). Nawet jeśli cyberprzestępca zna hasło użytkownika, nie uzyska dostępu bez ukończenia drugiego kroku.

Omówienie uwierzytelniania MFA dla usługi Dell iDRAC

W tej dokumentacji opisano, jak zintegrować Rublon MFA z usługą Dell iDRAC przy użyciu protokołu LDAP(S), aby włączyć uwierzytelnianie wieloskładnikowe dla logowań użytkowników.

Rublon MFA dla Dell iDRAC integruje się za pośrednictwem usługi Rublon Authentication Proxy, obsługującej protokół LDAP(S). Dzięki temu tylko autoryzowani użytkownicy mogą wykonać dodatkową metodę uwierzytelniania, uniemożliwiając dostęp potencjalnym intruzom.

Wspierane metody uwierzytelniania

Metoda uwierzytelniania	Czy wspierana	Komentarz
Powiadomienie mobilne		N/A
Klucz bezpieczeństwa WebAuthn/U2F	–	N/A
Kod dostępu		N/A
Kod SMS	–	N/A
Link SMS		N/A
Połączenie telefoniczne		N/A
Kod QR	–	N/A
Link e-mail		N/A
Klucz bezpieczeństwa YubiKey OTP		N/A

Film demonstracyjny

Zanim zaczniesz konfigurować uwierzytelnianie MFA dla usługi Dell iDRAC

Przed skonfigurowaniem uwierzytelniania Rublon MFA dla Dell iDRAC:

• Upewnij się, że wszystkie wymagane komponenty są gotowe.
• Utwórz aplikację w konsoli Rublon Admin Console.
• Zainstaluj aplikację mobilną Rublon Authenticator.

Wymagane komponenty

1. Dostawca tożsamości (IdP) — potrzebujesz zewnętrznego dostawcy tożsamości, takiego jak Microsoft Active Directory, OpenLDAP czy FreeIPA.

2. Rublon Authentication Proxy – zainstaluj usługę Rublon Authentication Proxy, jeśli jeszcze nie jest zainstalowana oraz skonfiguruj usługę Rublon Authentication Proxy jako serwer proxy LDAP.

3. Dell iDRAC – Prawidłowo zainstalowana i skonfigurowana usługa Dell PowerEdge i Dell iDRAC. Przetestowano na wersjach Dell PowerEdge R740xd i iDRAC9 Enterprise

Utwórz aplikację w konsoli Rublon Admin Console

1. Zarejestruj się w konsoli Rublon Admin Console. Oto jak to zrobić.

2. W konsoli Rublon Admin Console przejdź do zakładki Applications (Aplikacje) i kliknij Add Application (Dodaj aplikację).

3. Wprowadź nazwę swojej aplikacji (np. Dell iDRAC), a następnie ustaw jej typ na Rublon Authentication Proxy.

4. Kliknij przycisk Save (Zapisz), aby dodać nową aplikację w konsoli Rublon Admin Console.

5. Skopiuj i zapisz wartości System Token i Secret Key. Te wartości będą Ci potrzebne później.

Zainstaluj aplikację Rublon Authenticator

Niektórzy użytkownicy końcowi prawdopodobnie skorzystają z aplikacji mobilnej Rublon Authenticator. Dlatego też, jako osoba konfigurująca uwierzytelnianie MFA dla usługi Dell iDRAC, zdecydowanie zalecamy Ci zainstalowanie aplikacji mobilnej Rublon Authenticator. Dzięki temu możliwe będzie przetestowanie uwierzytelniania MFA dla usługi Dell iDRAC za pomocą metody uwierzytelniania Powiadomienie mobilne.

Pobierz aplikację Rublon Authenticator dla systemu:

• Android
• iOS
• HarmonyOS

Konfiguracja uwierzytelniania wieloskładnikowego (MFA) dla usługi Dell iDRAC

Rublon Authentication Proxy

Edytuj plik konfiguracyjny usługi Rublon Auth Proxy i wklej wcześniej skopiowane wartości System Token i Secret Key odpowiednio w opcjach system_token i secret_key.

2. Przykładowa konfiguracja w pliku YAML:

log:
  debug: true

rublon:
  api_server: https://core.rublon.net
  system_token: YOURSYSTEMTOKEN
  secret_key: YOURSECRETKEY

proxy_servers:
- name: LDAP-Proxy
  type: LDAP
  ip: 0.0.0.0
  port: 636
  auth_source: LDAP_SOURCE_1
  auth_method: push, email
  rublon_section: rublon
  cert_path: /etc/ssl/certs/ca.crt
  pkey_path: /etc/ssl/certs/key.pem

auth_sources:
- name: LDAP_SOURCE_1
  type: LDAP
  ip: 192.0.2.0
  port: 636
  transport_type: ssl
  search_dn: dc=example,dc=org
  access_user_dn: cn=admin,dc=example,dc=org
  access_user_password: CHANGE_ME
  ca_certs_dir_path: /etc/ssl/certs/

Zobacz: Jak skonfigurować certyfikaty LDAPS w Rublon Authentication Proxy?

Dell iDRAC

1. Zaloguj się do konsoli internetowej Dell iDRAC.

2. Przejdź do iDRAC Settings → Users i rozwiń sekcję Directory Services.

3. Wybierz Generic LDAP Directory Services, a następnie Enable w celu włączenia usługi LDAP.

4. Wybierz Edit, aby otworzyć okno Generic LDAP Configuration and Management.

5. W sekcji Certificate Settings:

• Jeśli używasz protokołu LDAPS (zalecane), ustaw opcję Certificate Validation na Enabled, prześlij certyfikat urzędu certyfikacji usługi katalogowej (Directory Service CA), i wybierz Next.
• Jeśli używasz protokołu LDAP (niezalecane), ustaw opcję Certificate Validation na Disabled i wybierz Next.

6. W sekcji Common Settings, wypełnij pola i wybierz Next. Pozostałe opcje pozostaw bez zmian lub dostosuj je zgodnie z własnymi potrzebami. Zapoznaj się z poniższym obrazkiem i tabelą.

7. W sekcji Standard Schema Role Groups, możesz zdefiniować do 15 grup użytkowników wraz z ich uprawnieniami.

8. Kliknij dwukrotnie dowolny wiersz grupy ról, aby go edytować. Wypełnij pola i wybierz Save. Zapoznaj się z poniższym obrazkiem i tabelą.

9. Po powrocie do okna Generic LDAP Configuration and Management wybierz Save, aby zakończyć konfigurację.

Testowanie uwierzytelniania wieloskładnikowego (MFA) dla usługi Dell iDRAC

Ten przykład przedstawia logowanie wieloskładnikowe do usługi Dell iDRAC. Metoda uwierzytelniania Powiadomienie mobilne została ustawiona jako drugi czynnik w konfiguracji usługi Rublon Authentication Proxy (Parametr AUTH_METHOD został ustawiony na Push).

1. Otwórz konsolę internetową iDRAC, wprowadź nazwę użytkownika i hasło, a następnie wybierz Log in.

2. Otrzymasz żądanie uwierzytelniania za pomocą metody Powiadomienie mobilne na swój telefon. Wybierz ZATWIERDŹ.

3. Otrzymasz dostęp do usługi Dell iDRAC.

Rozwiązywanie problemów z uwierzytelnianiem MFA dla usługi Dell iDRAC

Jeśli napotkasz jakiekolwiek problemy z integracją Rublon, skontaktuj się z pomocą techniczną Rublon Support.

Powiązane posty

Rublon Authentication Proxy

Rublon Authentication Proxy – Integracje

The post Uwierzytelnianie wieloskładnikowe (2FA/MFA) dla Dell iDRAC appeared first on Rublon.

Zimbra Collaboration to pakiet oprogramowania typu open source do obsługi poczty elektronicznej i zwiększania wydajności, który łączy serwer pocztowy z nowoczesnym klientem internetowym, oferującym kalendarze, kontakty, zadania, czat i funkcje udostępniania plików.

Uwierzytelnianie wieloskładnikowe (MFA) dla usługi Zimbra Collaboration zapewnia dodatkową warstwę bezpieczeństwa podczas logowania do Zimbra. Użytkownicy muszą przejść zarówno uwierzytelnianie podstawowe (login/hasło), jak i dodatkowe (np. Powiadomienie mobilne). Nawet jeśli cyberprzestępca zna hasło użytkownika, nie uzyska dostępu bez ukończenia drugiego kroku.

Omówienie uwierzytelniania MFA dla usługi Zimbra Collaboration

W tej dokumentacji opisano, jak zintegrować Rublon MFA z usługą Zimbra Collaboration przy użyciu protokołu LDAP, aby włączyć uwierzytelnianie wieloskładnikowe dla logowań użytkowników.

Rublon MFA dla Zimbra Collaboration integruje się za pośrednictwem usługi Rublon Authentication Proxy, obsługującej protokół LDAP. Dzięki temu tylko autoryzowani użytkownicy mogą wykonać dodatkową metodę uwierzytelniania, uniemożliwiając dostęp potencjalnym intruzom.

Wspierane metody uwierzytelniania

Metoda uwierzytelniania	Czy wspierana	Komentarz
Powiadomienie mobilne		N/A
Klucz bezpieczeństwa WebAuthn/U2F	–	N/A
Kod dostępu		N/A
Kod SMS	–	N/A
Link SMS		N/A
Połączenie telefoniczne		N/A
Kod QR	–	N/A
Link e-mail		N/A
Klucz bezpieczeństwa YubiKey OTP		N/A

Film demonstracyjny

Zanim zaczniesz konfigurować uwierzytelnianie MFA dla usługi Zimbra Collaboration

Przed skonfigurowaniem uwierzytelniania Rublon MFA dla Zimbra Collaboration:

• Upewnij się, że wszystkie wymagane komponenty są gotowe.
• Utwórz aplikację w konsoli Rublon Admin Console.
• Zainstaluj aplikację mobilną Rublon Authenticator.

Wymagane komponenty

1. Dostawca tożsamości (IdP) — potrzebujesz zewnętrznego dostawcy tożsamości, takiego jak Microsoft Active Directory, OpenLDAP czy FreeIPA.

2. Rublon Authentication Proxy – zainstaluj usługę Rublon Authentication Proxy, jeśli jeszcze nie jest zainstalowana oraz skonfiguruj usługę Rublon Authentication Proxy jako serwer proxy LDAP.

3. Zimbra Collaboration – Prawidłowo zainstalowana i skonfigurowana usługa Zimbra Collaboration Server. Przetestowano w wersji 10.1.0.

Utwórz aplikację w konsoli Rublon Admin Console

1. Zarejestruj się w konsoli Rublon Admin Console. Oto jak to zrobić.

2. W konsoli Rublon Admin Console przejdź do zakładki Applications (Aplikacje) i kliknij Add Application (Dodaj aplikację).

3. Wprowadź nazwę swojej aplikacji (np. Zimbra Collaboration), a następnie ustaw jej typ na Rublon Authentication Proxy.

4. Kliknij przycisk Save (Zapisz), aby dodać nową aplikację w konsoli Rublon Admin Console.

5. Skopiuj i zapisz wartości System Token i Secret Key. Te wartości będą Ci potrzebne później.

Zainstaluj aplikację Rublon Authenticator

Niektórzy użytkownicy końcowi prawdopodobnie skorzystają z aplikacji mobilnej Rublon Authenticator. Dlatego też, jako osoba konfigurująca uwierzytelnianie MFA dla usługi Zimbra Collaboration, zdecydowanie zalecamy Ci zainstalowanie aplikacji mobilnej Rublon Authenticator. Dzięki temu możliwe będzie przetestowanie uwierzytelniania MFA dla usługi Zimbra Collaboration za pomocą metody uwierzytelniania Powiadomienie mobilne.

Pobierz aplikację Rublon Authenticator dla systemu:

• Android
• iOS
• HarmonyOS

Konfiguracja uwierzytelniania wieloskładnikowego (MFA) dla usługi Zimbra Collaboration

Rublon Authentication Proxy

1. Edytuj plik konfiguracyjny usługi Rublon Auth Proxy i wklej wcześniej skopiowane wartości System Token i Secret Key odpowiednio w opcjach system_token i secret_key.

2. Przykładowa konfiguracja w pliku YAML:

log:
  debug: true

rublon:
  api_server: https://core.rublon.net
  system_token: token_from_admin_console
  secret_key: secret_from_admin_console

proxy_servers:
  - name: LDAP-Proxy
    type: LDAP
    ip: 0.0.0.0
    port: 389
    transport_type: plain
    auth_source: LDAP_SOURCE_1
    auth_method: push,email

auth_sources:
  - name: LDAP_SOURCE_1
    type: LDAP
    ip: x.x.x.x 
    port: 389
    search_dn: DC=domain,DC=local
    access_user_dn: CN=rap,OU=RUBLON,DC=domain,DC=local
    access_user_password: P@ssw0rd123

Tworzenie domeny

1. Zaloguj się do konsoli administracyjnej Zimbra.

2. W panelu po lewej przejdź do Konfiguruj → Domeny. Następnie wybierz ikonę koła zębatego w prawym górnym rogu i wybierz Nowy.

3. W zakładce Informacje ogólne wprowadź nazwę domeny i wybierz Dalej.

4. W zakładce Ustawienia trybu GLA wybierz swój serwer pocztowy z listy rozwijanej. Pozostałe opcje pozostaw bez zmian lub dostosuj je zgodnie z własnymi potrzebami. Następnie wybierz Dalej.

5. W zakładce SSO pozostaw wszystkie opcje bez zmian i wybierz Dalej.

6. Wypełnij pola w zakładce Tryb uwierzytelniania i wybierz Dalej. Zapoznaj się z poniższym obrazkiem i tabelą.

7. W zakładce Podsumowanie ustawień uwierzytelniania, przejrzyj podsumowanie konfiguracji proxy LDAP i wybierz Dalej.

8. Pozostałe zakładki są opcjonalne i można je pominąć. Wybierz Zakończ, aby zakończyć konfigurację domeny.

Konfiguracja uwierzytelniania dla domeny

1. W panelu po lewej konsoli administracyjnej Zimbra przejdź do Konfiguruj → Domeny i wybierz swoją domenę. Następnie wybierz ikonę koła zębatego w prawym górnym rogu i wybierz Konfiguruj uwierzytelnianie.

2. Pojawi się nowe okno z kreatorem konfiguracji uwierzytelniania. W zakładce Tryb uwierzytelniania wybierz Zewnętrzny katalog aktywny i wybierz Dalej.

3. W zakładce Ustawienia uwierzytelniania wypełnij pola i wybierz Dalej. Zapoznaj się z poniższym obrazkiem i tabelą.

4. W zakładce Powiązanie LDAP wypełnij pola i wybierz Dalej. Zapoznaj się z poniższym obrazkiem i tabelą.

5. Pozostałe zakładki są opcjonalne i można je pominąć. Wybierz Zakończ, aby zakończyć konfigurację uwierzytelniania dla domeny.

Konfiguracja uwierzytelniania MFA dla użytkowników i administratorów

1. W panelu po lewej przejdź do Zarządzaj → Konta, wybierz użytkownika (lub administratora), wybierz ikonę koła zębatego w prawym górnym rogu i wybierz Edytuj.

2. Wypełnij pola w zakładce Informacje ogólne. Zapoznaj się z poniższym obrazkiem i tabelą.

3. Pozostałe opcje pozostaw bez zmian lub dostosuj je zgodnie z własnymi potrzebami. Następnie wybierz Zapisz, aby zapisać zmiany.

Testowanie uwierzytelniania wieloskładnikowego (MFA) dla usługi Zimbra Collaboration

Ten przykład przedstawia logowanie wieloskładnikowe do usługi Zimbra Collaboration. Metoda uwierzytelniania Powiadomienie mobilne została ustawiona jako drugi czynnik w konfiguracji usługi Rublon Authentication Proxy (Parametr AUTH_METHOD został ustawiony na Push).

1. Otwórz portal Zimbra, wprowadź swoją nazwę użytkownika i hasło, a następnie wybierz Zaloguj się.

2. Otrzymasz żądanie uwierzytelniania za pomocą metody Powiadomienie mobilne na swój telefon. Wybierz ZATWIERDŹ.

3. Otrzymasz dostęp do usługi Zimbra Collaboration.

Rozwiązywanie problemów z uwierzytelnianiem MFA dla usługi Zimbra Collaboration

Jeśli napotkasz jakiekolwiek problemy z integracją Rublon, skontaktuj się z pomocą techniczną Rublon Support.

Powiązane posty

Rublon Authentication Proxy

Rublon Authentication Proxy – Integracje

The post Uwierzytelnianie wieloskładnikowe (2FA/MFA) dla Zimbra Collaboration appeared first on Rublon.

Gdy opcja secret_source jest ustawiona na env, każda wartość sekretu w pliku konfiguracyjnym staje się nazwą zmiennej środowiskowej, a usługa Auth Proxy odczytuje rzeczywistą wartość sekretu z tej zmiennej.

Sekrety usługi Rublon Authentication Proxy to:

• Sekcja rublon:
  • system_token
  • secret_key
• Sekcja proxy_servers:
  • RADIUS:
    • radius_secret
  • LDAP:
    • pkey_password (jeśli używany)
• Sekcja auth_sources:
  • RADIUS:
    • radius_secret
  • LDAP:
    • access_user_password

Przykład konfiguracji

log:
  debug: false

global:
  secret_source: env

rublon:
  api_server: https://core.rublon.net
  system_token: SYSTEM_TOKEN
  secret_key: SECRET_KEY

proxy_servers:
  - name: RADIUS-Proxy
    type: RADIUS
    radius_secret: RADIUS_SECRET
    ip: 0.0.0.0
    port: 1812
    mode: standard
    auth_source: LDAP_SOURCE_1
    auth_method: email

  - name: LDAP-Proxy
    type: LDAP
    ip: 0.0.0.0
    port: 389
    auth_source: LDAP_SOURCE_1
    auth_method: email

auth_sources:
  - name: LDAP_SOURCE_1
    type: LDAP
    ip: 127.0.2.0
    port: 389
    transport_type: plain
    search_dn: OU=Organization,DC=org,DC=com
    access_user_dn: CN=AccessUser,OU=Organization,DC=org,DC=com
    access_user_password: ACCESS_USER_PW

  - name: RADIUS_SOURCE_1
    type: RADIUS
    ip: 127.0.1.0
    port: 1812
    radius_secret: RADIUS_SECRET

W powyższym przykładzie opcja secret_source została ustawiona na env. Oznacza to, że usługa Rublon Auth Proxy będzie teraz traktować wartości sekretów pliku konfiguracyjnego jako nazwy zmiennych środowiskowych w celu pobrania rzeczywistych sekretów z systemu. W tym przykładzie usługa Auth Proxy oczekuje, że w systemie zostaną zdefiniowane cztery zmienne:

• SYSTEM_TOKEN
• SECRET_KEY
• RADIUS_SECRET (użyty dwukrotnie)
• ACCESS_USER_PW

Ustawianie zmiennych środowiskowych (Windows)

Po zainstalowaniu usługi Rublon Authentication Proxy na komputerze z systemem Windows:

1. Otwórz Edytor rejestru.

2. Przejdź do klucza rejestru Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RublonAuthProxy.

3. Dodaj nową wartość wielociągu (REG_MULTI_SZ) o nazwie Environment i dodaj następujące wiersze w danych wartości:

SYSTEM_TOKEN=wartość_tokenu
SECRET_KEY=wartość_klucza_tajnego
RADIUS_SECRET=wartość_klucza_tajnego_radius
ACCESS_USER_PW=hasło_użytkownika_dostępowego

4. Uruchom ponownie usługę Rublon Authentication Proxy.

Ustawianie zmiennych środowiskowych (Linux)

Po zainstalowaniu usługi Rublon Authentication Proxy na komputerze z systemem Linux:

1. Wykonaj:

systemctl edit rublon

2. Zmodyfikuj plik usługi, ustawiając zmienne środowiskowe w następujący sposób:

[Service]
Environment="SYSTEM_TOKEN=token_value_here"
Environment="SECRET_KEY=secret_value_here"
Environment="RADIUS_SECRET=radius_secret_here"
Environment="ACCESS_USER_PW=access_user_password_here"

3. Zapisz plik i uruchom ponownie usługę proxy:

systemctl restart rublon

Aktualizacja zmiennych środowiskowych

Każda zmiana zmiennych środowiskowych używanych przez usługę Rublon Authentication Proxy wymaga ponownego uruchomienia usługi Auth Proxy, aby zastosować nowe wartości. Usługa Auth Proxy odczytuje zmienne środowiskowe w momencie startu i nie wykonuje później automatycznych aktualizacji.

Korzyści z ustawiania sekretów w zmiennych środowiskowych

• Brak jawnych sekretów w pliku konfiguracyjnym. Plik konfiguracyjny usługi Auth Proxy zawiera nazwy zmiennych środowiskowych, a nie wartości sekretów. Nie musisz niczego usuwać przed udostępnieniem pliku konfiguracyjnego działowi pomocy technicznej Rublon Support.
• Prostsza aktualizacja. Aktualizuj zmienne środowiskowe bez ingerencji w plik konfiguracyjny usługi Auth Proxy. Po aktualizacji wystarczy ponownie uruchomić serwer proxy.
• Rozdzielenie obowiązków. Jeden administrator może zarządzać wartościami sekretów w zmiennych środowiskowych, a inny administrator może dbać o plik konfiguracyjny usługi Auth Proxy.
• Współpracuje ze standardowymi narzędziami. Systemd, usługi Windows, kontenery i CI/CD obsługują wstrzykiwanie zmiennych środowiskowych.

Podsumowanie

Przełączenie opcji secret_source na env powoduje, że poufne wartości nie są zapisywane w pliku konfiguracyjnym usługi Auth Proxy, tylko ładowane z systemu operacyjnego. Zdefiniuj wymagane zmienne środowiskowe, zaktualizuj konfigurację proxy, aby odwoływała się do ich nazw, a następnie uruchom ponownie usługę proxy, aby zastosować zmiany. Takie podejście zapewnia bardziej przejrzystą konfigurację i zmniejsza ryzyko przypadkowego ujawnienia poufnych informacji w plikach.

The post Konfiguracja źródła sekretów usługi Rublon Authentication Proxy appeared first on Rublon.

YubiKey to popularna marka sprzętowych kluczy bezpieczeństwa, natomiast FIDO2 to otwarty standard stosowany przez wielu producentów kluczy bezpieczeństwa. Chociaż terminy „klucz bezpieczeństwa FIDO2” i „YubiKey” są często używane zamiennie, nie oznaczają one tego samego. Niniejszy artykuł pomoże Ci poznać różnice między kluczem bezpieczeństwa YubiKey a kluczem bezpieczeństwa FIDO2.

Co to jest FIDO2?

FIDO2 to otwarty, niezależny od dostawców standard (WebAuthn + CTAP2), który umożliwia uwierzytelnianie bezhasłowe lub uwierzytelnianie wieloskładnikowe odporne na phishing na różnych przeglądarkach, platformach i urządzeniach.

Co to jest klucz bezpieczeństwa FIDO2?

Klucz bezpieczeństwa FIDO2 to dedykowane sprzętowe urządzenie uwierzytelniające (zazwyczaj brelok USB lub NFC), które realizuje standard FIDO2 w zakresie weryfikacji użytkownika i bezpiecznego podpisywania kryptograficznego.

Co to jest YubiKey?

YubiKey to rodzina sprzętowych kluczy bezpieczeństwa opracowana przez firmę Yubico. Większość aktualnych modeli obsługuje standard FIDO2 oraz dodatkowe protokoły, takie jak FIDO U2F, Smart Card (PIV), OpenPGP, Yubico OTP i challenge-response (HMAC-SHA-1).

YubiKey a klucz bezpieczeństwa FIDO2: jaka jest różnica?

Główna różnica polega na tym, że YubiKey to linia produktów opracowana przez firmę Yubico, która spełnia kilka standardów (w tym FIDO2, FIDO U2F i inne). Natomiast klucz bezpieczeństwa FIDO2 może pochodzić od różnych dostawców, o ile spełnia standard FIDO2.

YubiKey a klucz bezpieczeństwa FIDO2: Tabela różnic

* Starsze modele YubiKey Standard/Nano (tylko OTP) oraz YubiKey 4 (FIDO U2F, bez FIDO2) różnią się funkcjonalnie od modeli opisanych w tej tabeli

Rozróżnianie kluczy YubiKey od kluczy bezpieczeństwa FIDO2

• Nie każdy klucz YubiKey obsługuje standard FIDO2 (starsze modele YubiKey Standard i Nano obsługują tylko OTP i U2F).
• Nie każdy klucz bezpieczeństwa FIDO2 jest kluczem YubiKey. Google Titan, Feitian BioPass K27 i Solo V2 to tylko niektóre z wielu alternatyw.
• W środowiskach podlegających regulacjom (PCI DSS, HIPAA, NIS2) należy upewnić się, że urządzenie posiada co najmniej certyfikat FIDO Authenticator Level 2.

Zalety YubiKey w porównaniu z innymi markami kluczy bezpieczeństwa FIDO2

1. Opcje FIPS i wyższe poziomy FIDO. Klucze YubiKey oferuje wersje z certyfikatem FIPS 140 (poziom 2/3) oraz modele z certyfikatem FIDO Authenticator Level 2/3, przydatne w środowiskach regulowanych.
2. Szerszy zakres protokołów. Oprócz standardów FIDO2/U2F wiele modeli obsługuje standardy kart inteligentnych PIV (CCID), OpenPGP, Yubico OTP i HMAC-SHA1, dzięki czemu jeden klucz może obsługiwać proces karty inteligentnej i podpisywania.
3. Sprawdzona marka i jakość. YubiKey ma ugruntowaną reputację dzięki solidnej konstrukcji i niezawodnym aktualizacjom oprogramowania układowego. Ma to kluczowe znaczenie dla zapewnienia stałej wydajności na różnych platformach.
4. Zaufanie do oprogramowania układowego. Yubico dokładnie testuje swoje oprogramowanie układowe. Użytkownicy zyskują pewność, wiedząc, że ich klucze spełniają rygorystyczne standardy bezpieczeństwa wykraczające poza FIDO2.
5. Modele NFC i biometryczne. Niektóre klucze YubiKey oferują obsługę NFC lub zintegrowane skanowanie odcisków palców, co dodatkowo usprawnia i zabezpiecza logowanie.

Zalety kluczy bezpieczeństwa FIDO2 innych marek w porównaniu z YubiKey

1. Zakres cenowy. Niektóre klucze FIDO2 mogą być tańsze od YubiKey, zwłaszcza jeśli nie potrzebujesz specjalnych funkcji, takich jak biometria i NFC.
2. Transmisja Bluetooth Low Energy (BLE). Kilka kluczy FIDO2 (np. Thetis BLE FIDO2 Security Key) obsługuje transmicję BLE w przypadkach, gdy USB/NFC nie są dostępne. Ten typ transmisji nie jest obsługiwany przez klucze YubiKey.
3. Opcje open source. Niektóre klucze (np. Solo V2) są dostarczane z otwartym oprogramowaniem układowym, co zapewnia transparentność w porównaniu z podpisanym, zamkniętym oprogramowaniem YubiKey.
4. Różnorodność dostawców. FIDO2 jest otwartym standardem, co daje Ci wiele marek do wyboru.

Którą markę klucza wybrać?

To zależy od Twoich potrzeb:

• Wybierz klucz YubiKey, jeśli potrzebujesz jednego klucza klasy korporacyjnej, który łączy w sobie standard FIDO2 z obsługą standardów kart inteligentnych PIV i OpenPGP w odpornej na manipulacje obudowie, z opcją modeli z certyfikatem FIPS dla środowisk podlegających regulacjom.
• Wybierz generyczny klucz bezpieczeństwa FIDO2, gdy kluczowa jest niższa cena jednostkowa, polityka różnorodności dostawców lub gdy potrzebujesz funkcji takich jak łączność BLE czy firmware o otwartym kodzie źródłowym.

Niezależnie od Twojego wyboru, nowocześni dostawcy uwierzytelniania wielopoziomowego (MFA), takiego jak Rublon MFA, obsługują zarówno klucze YubiKey, jak i klucze bezpieczeństwa FIDO2 innych marek, a także starsze klucze FIDO U2F i programowe klucze dostępu FIDO2. Daje to organizacjom większą elastyczność przy podejmowaniu decyzji między kluczem bezpieczeństwa FIDO2 a YubiKey.

Szukasz kluczy bezpieczeństwa FIDO2? Mamy je!

Potrzebujesz niezawodnych kluczy bezpieczeństwa FIDO2 dla swoich pracowników lub klientów? Pomożemy Ci wybrać odpowiednie modele.

Rozpocznij bezpłatny okres próbny Rublon MFA już dziś

Wypróbuj rozwiązanie Rublon MFA bezpłatnie przez 30 dni: włącz logowanie MFA odporne na phishing, wdroż klucze bezpieczeństwa FIDO2 i klucze dostępu w ciągu kilku minut i przekonaj się, jak łatwo możesz podnieść poziom bezpieczeństwa swojej organizacji.

Aby rozpocząć bezpłatny okres próbny, kliknij przycisk poniżej.

The post YubiKey a klucz bezpieczeństwa FIDO2: czym się różnią? appeared first on Rublon.

• Jeśli szukasz instrukcji, jak administratorzy mogą zarejestrować klucze bezpieczeństwa/dostępu użytkowników, zapoznaj się z dokumentacją Rublon Admin Console – Jak dodać uwierzytelniacz FIDO dla użytkownika.
• Jeśli szukasz instrukcji, jak użytkownicy mogą samodzielnie zarejestrować swoje uwierzytelniacze FIDO, zapoznaj się z przewodnikami Jak dodać klucz bezpieczeństwa WebAuthn/U2F? oraz Jak zarejestrować klucz dostępu do uwierzytelniania MFA?.

Dlaczego warto używać passkeyów w menedżerze haseł?

• Efektywność kosztowa: Nie trzeba hurtowo kupować sprzętowych tokenów; wiele menedżerów haseł oferuje synchronizację passkeyów w ramach standardowych planów.
• Wbudowane zabezpieczenia: Nie są wymagane zewnętrzne urządzenia, które można łatwo zgubić lub zostawić w domu.
• Szybkie odzyskiwanie: Zgubiono urządzenie? Klucze dostępu stają się ponownie dostępne, gdy użytkownik zainstaluje menedżer na innym urządzeniu i zaloguje się.
• Wygoda użytkownika: Automatyczne monity z poziomu rozszerzenia przeglądarki skracają czas logowania.
• Odporność na phishing: Mechanizm wiązania z adresem źródłowym (origin-binding) w standardzie WebAuthn zapewnia odporność na phishing, udaremniając ataki wyłudzające dane uwierzytelniające.

Względy bezpieczeństwa

• Poziom bezpieczeństwa synchronizowanych kluczy dostępu: Zarejestrowane przez administratora synchronizowalne klucze dostępu przechowywane w menedżerze haseł nie spełniają wymogów sprzętowości i nieeksportowalności wymaganych dla poziomu Authenticator Assurance Level 3 (NIST AAL3) zdefiniowanego w dokumencie NIST Special Publication 800-63B. Spełniają jedynie kryteria wieloskładnikowości i (opcjonalne kryterium) odporności na phishing dla poziomu NIST AAL2. Z tego powodu organizacje z sektorów krytycznych, w których wymagane jest spełnienie wymogu NIST AAL3, powinny zarejestrować sprzętowe klucze FIDO (NIST AAL3). Fizyczne uwierzytelniacze FIDO są również zalecane dla najbardziej wrażliwych kont w innych sektorach.
• Ochrona synchronizowanych kluczy dostępu: Zgodnie z normą NIST SP 800-63B § 5.1.8.1 oraz uzupełnieniem 1 do normy SP 800-63B z kwietnia 2024 r., każde uwierzytelnienie za pomocą programowego klucza dostępu musi wymagać lokalnego czynnika aktywacyjnego (kodu PIN lub danych biometrycznych) oraz wynikowe potwierdzenie WebAuthn musi zawierać flagę „UV = true”. Odblokowanie sejfu menedżera haseł za pomocą odcisku palca lub kodu PIN spełnia ten wymóg tylko wtedy, gdy sejf pozostaje zablokowany przez krótki czas, a moduł uwierzytelniający nadal potwierdza „UV = true”; w przeciwnym razie wymagane jest drugie potwierdzenie (lub klucz sprzętowy), aby pozostać na poziomie AAL2. Więcej informacji można znaleźć w dokumentacji konkretnego wykorzystywanego menedżera haseł.
• Administratorzy o najmniejszych możliwych uprawnieniach: Rejestruj klucze dostępu z kont, które nie przechowują innych ważnych danych uwierzytelniających.
• Przenieś zamiast kopiuj: Zalecaj użytkownikom przeniesienie (a nie tylko skopiowanie) kluczy dostępu do swojej przestrzeni prywatnej, aby administrator nie miał już do nich dostępu.
• Ścieżki audytu: Rublon rejestruje tworzenie i usuwanie kluczy w Dziennikach audytu; większość menedżerów haseł klasy enterprise rejestruje również przeniesienia i usunięcia elementów. Eksportuj okresowo obydwa dzienniki na potrzeby audytów.

Wymagania wstępne

• Rola administratora z uprawnieniami do zarządzania użytkownikami i kluczami bezpieczeństwa.
• Subskrypcja typu Enterprise lub Team w jednym z biznesowych menedżerów haseł udostępniających funkcję współdzielonej przestrzeni między administratorem a użytkownikiem, na przykład współdzielonego sejfu lub kolekcji. (Poniższa lista ma charakter poglądowy. Istnienie i kompatybilność funkcji może się różnić; należy to zweryfikować u dostawcy i przetestować w swoim środowisku.)
  • 1Password Business / Enterprise
  • Dashlane Business
  • Bitwarden Teams / Enterprise
  • NordPass Business
  • Google Password Manager (Workspace or Chrome Sync)
  • Keeper Business
  • Sésame Password Manager
  • Enpass Business
  • Proton Pass Enterprise
  • KeePassXC (with sync solution)
  • Zoho Vault Enterprise
  • LastPass Business
  • Devolutions Password Hub Business
  • LogMeOnce Enterprise
  • Kaspersky Password Manager (Business)
  • pwSafe for Teams
  • Microsoft Password Manager (Edge Sync)
• Przeglądarka z obsługą standardu WebAuthn i passkeyów (Chrome ≥ 109, Edge ≥ 109, Safari ≥ 16.4, Firefox ≥ 122).
• Polityka firmowa musi zezwalać na centralnie udostępniane uwierzytelniacze FIDO.

Przewodnik krok po kroku

Procedura jest podobna we wszystkich nowoczesnych menedżerach haseł: utwórz tymczasową przestrzeń współdzieloną, dodaj passkey w konsoli Rublon Admin Console, zapisz go w tej współdzielonej przestrzeni, a następnie poproś użytkownika o przeniesienie passkeya do swojej przestrzeni prywatnej.

Krok 1: Zainstaluj rozszerzenie przeglądarki menedżera haseł

1. Zainstaluj dedykowane rozszerzenie przeglądarki swojego menedżera haseł.
2. Zaloguj się do menedżera haseł przy użyciu konta z uprawnieniami administratora, które może zarządzać organizacją.

Krok 2: Utwórz tymczasową przestrzeń współdzieloną

W menedżerze haseł:

1. Utwórz sejf/folder/kolekcję (nazwa może się różnić w zależności od menedżera), współdzieloną wyłącznie między Tobą a docelowym użytkownikiem. Właśnie w tej przestrzeni zapiszesz passkey po jego zarejestrowaniu w konsoli Rublon Admin Console.

Krok 3: Dodaj passkey w konsoli Rublon Admin Console

W konsoli Rublon Admin Console:

1. Przejdź do zakładki Users → wybierz użytkownika → przejdź do sekcji Security Keys.
2. Wybierz Add Security Key, nadaj nazwę temu uwierzytelniaczowi FIDO i kliknij Add.
3. Dokończ rejestrację uwierzytelniacza FIDO w przeglądarce.
4. Jeżeli menedżer haseł zapyta o miejsce zapisu, wybierz przestrzeń współdzieloną.

Krok 4: Poproś użytkownika o przeniesienie passkeya

1. Wyślij krótką instrukcję do użytkownika, prosząc go o zalogowanie się do aplikacji przy użyciu tego passkeya. Jeśli test się powiedzie, użytkownik powinien przenieść nowy passkey z przestrzeni współdzielonej do swojej przestrzeni prywatnej.
2. Po przeniesieniu passkeya przez użytkownika, nie jest on już z Tobą współdzielony w menedżerze haseł, co pokrywa się z najlepszymi praktykami wytycznych NIST i stowarzyszenia FIDO Alliance (Administratorzy nadal mogą dezaktywować ten passkey, usuwając go w konsoli Rublon Admin Console.)

Najczęściej zadawane pytania (FAQ)

Powiązane posty

Rublon Admin Console – Jak dodać uwierzytelniacz FIDO dla użytkownika

Jak dodać klucz bezpieczeństwa WebAuthn/U2F?

Jak zarejestrować klucz dostępu do uwierzytelniania MFA?

The post Wdrażanie kluczy dostępu rejestrowanych przez administratora w menedżerach haseł appeared first on Rublon.