Keeper bardzo poważnie traktuje kwestie bezpieczeństwa danych uwierzytelniających i ochrony danych

Omówienie

Firma Keeper Security , Inc. z pasją rozwija oprogramowanie Keeper na urządzenia przenośne i komputery osobiste, aby zapewnić użytkownikowi jak najwyższy poziom zabezpieczeń danych. Miliony klientów bezpośrednich i firm zaufało już aplikacji Keeper w dziedzinie ochrony i dostępu do haseł i danych osobistych.

Oprogramowanie Keeper jest nieustannie rozwijane i aktualizowane, aby zapewnić naszym klientom najnowsze rozwiązania technologiczne w dziedzinie zabezpieczeń. Na niniejszej stronie znajduje się omówienie architektury zabezpieczeń aplikacji Keeper, technik szyfrowania oraz środowiska serwerowego z najnowszej wersji aplikacji. Ponadto niniejszy dokument zawiera omówienie strony technicznej aplikacji, w tym metod szyfrowania i systemu zabezpieczeń.

Z naszą polityką prywatności oraz warunkami użytkowania można zapoznać się na naszej stronie internetowej, klikając poniższe odnośniki:

Platforma zero-trust

Keeper wykorzystuje architekturę zero-trust, która zapewnia, że każdy użytkownik musi zostać zweryfikowany i uwierzytelniony, zanim uzyska dostęp do strony internetowej, aplikacji lub systemu.

Keeper Enterprise Password Management (EPM) zapewnia firmom pełną widoczność i kontrolę nad praktykami dotyczącymi haseł pracowników, umożliwiając administratorom IT monitorowanie użycia haseł i egzekwowanie najlepszych praktyk bezpieczeństwa.

Keeper Secrets Manager (KSM) zapewnia zespołom inżynieryjnym platformę do zarządzania wszystkimi poświadczeniami, w tym wpisami tajnymi infrastruktury, kluczami SSH, kluczami API i certyfikatami z zestawami SDK i integracją CI / CD.

Keeper Connection Manager (KCM) to brama pulpitu zdalnego, która zapewnia zespołom DevOps i IT łatwy dostęp do sieci typu zero-trust (Zero Trust Network Access, ZTNA) w celu zapewnienia dostępu do RDP, SSH, baz danych, wewnętrznych aplikacji internetowych i punktów końcowych Kubernetes za pośrednictwem przeglądarki internetowej – nie jest wymagany żaden agent.

Szczegółowe informacje dotyczące najlepszych w swojej klasie zabezpieczeń Keeper

Szyfrowanie danych magazynu

Keeper zapewnia wielowarstwowy model szyfrowania oparty na najmniejszych uprawnieniach. Na urządzeniu klienckim generowane są 256-bitowe klucze AES na poziomie wpisu i klucze na poziomie folderu, które szyfrują każdy zapisany wpis w sejfie. Wpisy w sejfie i cała ich zawartość są w pełni szyfrowane, co obejmuje loginy, załączniki do plików, kody TOTP, informacje o płatnościach, adresy URL i pola niestandardowe.

Klucze szyfrowania są generowane lokalnie na urządzeniu w celu zachowania zasady zero knowledge i obsługi zaawansowanych funkcji, takich jak udostępnianie wpisów i folderów. Podejście zero knowledge oznacza, że każdy użytkownik ma pełną kontrolę nad szyfrowaniem i odszyfrowywaniem wszystkich danych osobowych w swoim sejfie Keeper, a żadne z przechowywanych przez niego informacji nie są dostępne dla nikogo innego, nawet dla pracowników Keeper.

Klucze wpisów i klucze folderów są szyfrowane 256-bitowym kluczem danych AES, który jest unikatowy dla każdego użytkownika i generowany na jego urządzeniu.

Na urządzeniu użytkownika generowany jest kolejny 256-bitowy klucz klienta AES do szyfrowania lokalnej pamięci podręcznej offline (jeśli administrator firmy zezwala na dostęp offline). Na koniec 256-bitowy klucz danych AES jest szyfrowany innym kluczem, jak opisano w następnej sekcji.

Metody szyfrowania magazynu

Keeper szyfruje dane na różne sposoby w zależności od sposobu logowania użytkowników. Użytkownicy indywidualni i członkowie planu rodzinnego korzystają z hasła głównego i uwierzytelniania biometrycznego. W przypadku użytkowników biznesowych i korporacyjnych, którzy logują się za pomocą SSO, Keeper wykorzystuje szyfrowanie za pomocą krzywej eliptycznej w celu zapewnienia bezpieczeństwa bez podawania hasła.

Użytkownicy logujący się za pomocą hasła głównego: Klucz do odszyfrowania i zaszyfrowania klucza danych jest wyprowadzany z hasła głównego użytkownika przy użyciu funkcji zmiany klucza opartej na haśle (PBKDF2), z 1 000 000 iteracji. Po wpisaniu przez użytkownika hasła głównego klucz jest wyprowadzany lokalnie, a następnie rozpakowuje klucz danych. Klucz danych jest odszyfrowywany i używany do odszyfrowania poszczególnych kluczy wpisów i folderów. Odszyfrowanie każdego klucza przechowuje zawartość wpisu lokalnie na urządzeniu użytkownika.

Użytkownicy logujący się za pomocą SSO lub technologii bezhasłowej: Kryptografia krzywych eliptycznych jest używana do szyfrowania i odszyfrowywania danych na poziomie urządzenia. Do odszyfrowania klucza danych używany jest lokalny klucz prywatny ECC-256 (secp256r1). Po odszyfrowaniu klucza danych jest on używany do rozpakowania poszczególnych kluczy wpisów i folderów. Klucz wpisu odszyfrowuje następnie zawartość każdego z przechowywanych wpisów. Zaszyfrowany klucz danych jest przesyłany między urządzeniami użytkownika za pośrednictwem systemu push lub usługi wymiany kluczy, która nosi nazwę Zatwierdzanie urządzenia. Aby zachować zasadę zero knowledge, usługa Zatwierdzanie urządzenia jest zarządzana lokalnie przez użytkownika końcowego.

Model szyfrowania SSO

Pierwszy proces urządzenia (wdrażanie nowego użytkownika)

1. Generowane są klucz danych, para kluczy udostępniania i para kluczy prywatnego/publicznego EC urządzenia
2. Klucz danych jest szyfrowany za pomocą klucza publicznego EC urządzenia i przechowywany w chmurze (DEDK)
3. Użytkownik loguje się za pomocą swojego dostawcy tożsamości (IdP)
4. Po zalogowaniu IdP podpisane potwierdzenie SAML jest weryfikowane przez Keeper
5. Sejf jest tworzony, a użytkownik jest wdrażany

Proces istniejącego urządzenia

1. Użytkownik loguje się za pomocą swojego dostawcy tożsamości (IdP)
2. Po zalogowaniu IdP podpisane potwierdzenie SAML jest weryfikowane przez Keeper
3. Keeper dostarcza użytkownikowi zaszyfrowany klucz danych urządzenia (DEDK)
4. Klucz danych jest odszyfrowywany za pomocą klucza prywatnego EC urządzenia
5. Klucz danych odszyfrowuje klucze folderów i klucze wpisów
6. Klucze wpisów odszyfrowują zawartość wpisów

Proces nowego lub nierozpoznanego urządzenia

1. Na każdym nowym urządzeniu generowana jest para kluczy prywatnego/publicznego EC
2. Użytkownik loguje się za pomocą swojego dostawcy tożsamości (IdP)
3. Po zalogowaniu IdP podpisane potwierdzenie SAML jest weryfikowane przez Keeper
4. Urządzenie zostaje „zatwierdzone“ za pomocą Keeper Push, zatwierdzenia przez administratora lub usługi Keeper Automator (*patrz Zatwierdzanie urządzeń poniżej)
5. Podczas procesu zatwierdzania klucz danych jest szyfrowany kluczem publicznym nowego urządzenia
6. Zaszyfrowany klucz danych urządzenia (DEDK) jest wysyłany do użytkownika

Zatwierdzanie urządzenia

• Zatwierdzenie urządzeń to mechanizm bezpiecznego dostarczania klucza danych użytkownika do jego nowego urządzenia przy zachowaniu zasady zero knowledge
• Użytkownik może zatwierdzić swoje urządzenie poprzez zaszyfrowanie klucza danych kluczem publicznym nowego urządzenia
• Administrator może zatwierdzić urządzenie z poziomu Konsoli administratora, aplikacji Commander lub usługi Keeper Automator
• Administrator odszyfrowuje klucz danych użytkownika i ponownie szyfruje klucz danych za pomocą klucza publicznego nowego urządzenia
• Usługa Keeper Automator może automatycznie zatwierdzać urządzenia w infrastrukturze klienta
• Keeper Automator sprawdza podpis SAML, rozpakowuje klucz danych i szyfruje klucz danych kluczem publicznym nowego urządzenia

Dowiedz się więcej o usłudze Keeper Automator.

Bezpieczeństwo na poziomie urządzenia dla SSO Connect Cloud

Dla użytkowników SSO Connect Cloud klucz prywatny krzywej eliptycznej jest generowany i przechowywany lokalnie na każdym urządzeniu. W nowoczesnych przeglądarkach internetowych i aplikacji Keeper Desktop opartej na Electronie sejf Keeper przechowuje lokalny klucz prywatny EC urządzenia („DPRIV”) jako nieeksportowalny CryptoKey. Na urządzeniach z systemami iOS i macOS klucz jest przechowywany w pęku kluczy urządzenia. Na urządzeniach z systemem Android klucz jest szyfrowany za pomocą Android Keystore, przy użyciu klasy Encrypted Shared Preferences. Tam, gdzie to możliwe, Keeper wykorzystuje bezpieczne mechanizmy przechowywania danych w każdym systemie operacyjnym.

Klucz prywatny urządzenia nie jest bezpośrednio wykorzystywany do szyfrowania lub odszyfrowywania danych sejfu. Po pomyślnym uwierzytelnieniu przez dostawcę tożsamości oddzielny klucz (który nie jest przechowywany) jest wykorzystywany do odszyfrowania danych sejfu. W związku z tym wyodrębnienie lokalnego klucza prywatnego urządzenia w trybie offline nie pozwala odszyfrować sejfu użytkownika.

Szyfrowanie danych podczas przechowywania

Keeper korzysta z AWS do hostowania platformy i architektury Keeper. Nasze centra danych AWS znajdują się w wielu lokalizacjach geograficznych, a klienci mogą hostować swoją dzierżawę Keeper w dowolnym preferowanym regionie podstawowym. Gwarantuje to, że dane klienta i dostęp do platformy będą izolowane do tego konkretnego regionu.

Dane sejfu w spoczynku są szyfrowane lokalnie na urządzeniu użytkownika przy użyciu AES-256 GCM, a zaszyfrowane dane w tranzycie są szyfrowane za pomocą TLS 1.3 z dodatkową warstwą szyfrowania w ładunku. Dane klientów są izolowane poprzez zastosowanie szyfrowania na poziomie wpisu.

Model szyfrowania Keeper ma następującą strukturę:

• Wszystkie sejfy są szyfrowane unikatowym, generowanym po stronie klienta 256-bitowym kluczem AES w trybie GCM.
• Wszystkie klucze na poziomie wpisów w folderach współdzielonych są opakowane 256-bitowym kluczem AES folderu współdzielonego.
• Klucze wpisów i folderów dla użytkowników sejfu są szyfrowane innym 256-bitowym kluczem AES zwanym kluczem danych.
• W przypadku Keeper Secrets Manager (KSM) klucze wpisów i folderów użytkownika są szyfrowane 256-bitowym kluczem aplikacji AES.
• W przypadku użytkowników logujących się za pomocą hasła głównego, klucze do odszyfrowywania i szyfrowania danych pochodzą z hasła głównego.
• Logowanie za pomocą SSO lub technologii bezhasłowej wykorzystuje kryptografię krzywej eliptycznej do szyfrowania i odszyfrowywania danych na urządzeniu.
• Każdy zaszyfrowany ładunek jest wysyłany do serwerów Keeper i zabezpieczony 256-bitowym kluczem transmisji AES z TLS w celu ochrony przed atakami typu Man in the Middle (MITM). Klucz jest generowany na kliencie i przesyłany przy użyciu szyfrowania ECIES za pośrednictwem publicznego klucza krzywej eliptycznej serwera.
• Bezpieczne udostępnianie wpisów tajnych między użytkownikami wykorzystuje dystrybucję kluczy z kryptografią krzywych eliptycznych.

Przechowywanie wersji wpisów

Keeper przechowuje pełną zaszyfrowaną historię wersji każdego wpisu przechowywanego w sejfie użytkownika, dając pewność, że żadne krytyczne dane nie zostaną utracone. Z poziomu aplikacji klienckiej Keeper użytkownicy mogą sprawdzić historię wpisów i przywrócić dowolny wpis w sejfie. Jeśli zapisane hasło lub plik w rozwiązaniu Keeper zostaną zmienione lub usunięte, użytkownicy zawsze mają możliwość przywrócenia ich w dowolnym momencie.

Keeper Business

Klienci, którzy zakupią Keeper Business, otrzymają dodatkową warstwę kontroli nad swoimi użytkownikami i urządzeniami. Administratorzy Keeper otrzymują dostęp do opartej na chmurze konsoli administracyjnej, która umożliwia pełną kontrolę nad wdrażaniem i usuwaniem użytkowników, uprawnieniami opartymi na rolach, administracją delegowaną, zespołami, integracją z Active Directory/LDAP, uwierzytelnianiem dwuskładnikowym, pojedynczym logowaniem i zasadami egzekwowania zabezpieczeń. Oparte na rolach zasady egzekwowania zabezpieczeń Keeper są w pełni konfigurowalne i skalowalne do dowolnej wielkości organizacji.

Wielokrotne szyfrowanie danych w spoczynku

Oprócz przechowywania w infrastrukturze AWS wyłącznie zaszyfrowanego przez urządzenie szyfrogramu, Keeper wykonuje również superszyfrowanie za pomocą wieloregionalnych sprzętowych modułów bezpieczeństwa (HSM) przy użyciu kluczy, których nie można eksportować.

Szyfrowanie i ochrona kopii zapasowych

Na poziomie produktu/użytkownika oprogramowanie Keeper przechowuje pełną historię zmian każdego wpisu. W związku z tym, jeśli użytkownik wymaga przywrócenia danych, może w dowolnym momencie wyświetlić i przywrócić wcześniejsze wersje swoich zapisanych wpisów Keeper bez ograniczeń za pośrednictwem interfejsu użytkownika.

Na poziomie systemu zaszyfrowane bazy danych i obiekty plików Keeper są replikowane i tworzone są ich kopie zapasowe w wielu regionach geograficznych na potrzeby odzyskiwania danych po awarii. Wszystkie kopie zapasowe są szyfrowane przy użyciu algorytmu AES-256 oraz superszyfrowania szyfrogramu generowanego przez urządzenie.

Klientom, którzy potrzebują pomocy w odzyskiwaniu danych (na przykład z powodu przypadkowego usunięcia sejfu lub folderu udostępnionego), zespół pomocy technicznej Keeper może pomóc w przywróceniu danych do dowolnego punktu w czasie (z dokładnością co do minuty) w ciągu 30 dni. Wsparcie Keeper może pomóc w dowolnym odzyskiwaniu danych, takim jak przywracanie użytkowników, sejfów lub pełne przywracanie danych przedsiębiorstwa.

Odzyskiwanie konta

Fraza odzyskiwania zawierającą 24 słowa umożliwia klientom Keeper odzyskanie dostępu do sejfu Keeper w przypadku utraty lub zapomnienia hasła głównego.

Keeper zaimplementował frazy odzyskiwania przy użyciu tej samej listy słów BIP39, która służy do ochrony portfeli kryptowalutowych. Lista słów używana w BIP39 to zestaw 2048 słów używanych do generowania klucza szyfrowania z 256 bitami entropii. Ta metoda odzyskiwania jest powszechnie stosowana w popularnych portfelach bitcoin i kryptowalut. Każde słowo na liście BIP39 jest starannie dobrane, aby poprawić widoczność i sprawić, że proces odzyskiwania będzie mniej podatny na błędy. Użytkownicy powinni zapisać swoją frazę odzyskiwania i przechowywać ją w bezpiecznym miejscu, takim jak sejf.

Fraza odzyskiwania generuje 256-bitowy klucz AES, który szyfruje kopię klucza danych użytkownika. Aby odzyskać konto i zresetować hasło główne, użytkownicy będą potrzebować frazy odzyskiwania wraz z weryfikacją adresu e-mail i uwierzytelnianiem dwuskładnikowym (2FA).

Administratorzy przedsiębiorstwa mogą wyłączyć odzyskiwanie konta na poziomie zasad wymuszania ról.

Klucze szyfrowania w planach dla firm

Klienci Keeper Enterprise i Business mogą zarządzać wieloma różnymi funkcjami platformy Keeper, takimi jak zasady dostępu opartego na rolach, udostępnianie, uwierzytelnianie i zarządzanie.

Funkcje administratora są chronione przez platformę Keeper za pomocą szyfrowania i autoryzacji. Autoryzacja gwarantuje, że tylko wyznaczeni użytkownicy mogą wykonywać określone funkcje. Szyfrowanie zapewnia, że wyznaczeni administratorzy mogą fizycznie i kryptograficznie wykonywać tylko te funkcje, które dotyczą danych sejfu lub kluczy kontrolowanych przez przedsiębiorstwo. Oto kilka przykładów:

• Platforma Keeper jest de facto platformą do zarządzania kluczami, na której użytkownicy i administratorzy mają pełną kontrolę nad swoimi kluczami prywatnymi.
• Pary publicznych i prywatnych kluczy szyfrowania są używane do tworzenia urządzeń, użytkowników i zespołów.
• Zasady ról dotyczące przenoszenia sejfów i zatwierdzania urządzeń wykorzystują publiczne i prywatne klucze szyfrowania.
• Pary kluczy z krzywą eliptyczną (EC) są używane do udostępniania danych między użytkownikami oraz od indywidualnego użytkownika do administratora na poziomie przedsiębiorstwa.
• Wrażliwe dane dotyczące użycia, takie jak siła hasła wpisu, są szyfrowane za pomocą kluczy publicznych przedsiębiorstwa, które może odszyfrować tylko administrator.
• Pola tytułu wpisu, adresu URL i typu wpisu we wpisach w sejfie każdego użytkownika korporacyjnego są szyfrowane za pomocą klucza publicznego przedsiębiorstwa i mogą zostać odszyfrowane w Konsoli administratora Keeper przez administratora z uprawnieniami do raportowania zgodności.

Weryfikacja urządzeń

Zanim użytkownik będzie mógł nawet spróbować zalogować się na konto, musi najpierw przejść etap zatwierdzania i weryfikacji urządzenia. Weryfikacja urządzenia zapobiega wyliczaniu kont i chroni przed atakami siłowymi.

Klienci, którzy logują się przy użyciu hasła głównego, mogą przeprowadzić weryfikację urządzenia przy użyciu kilku metod, takich jak:

• Kod weryfikacyjny w wiadomości e-mail
• Wprowadzenie kodu 2FA z TOTP lub wiadomości tekstowej
• Użycie Keeper Push^™ do wysyłania wiadomości do rozpoznanego urządzenia

W przypadku klientów, którzy uwierzytelniają się za pomocą Keeper SSO Connect Cloud, zatwierdzenie urządzenia odbywa się za pomocą transferu klucza, podczas którego zaszyfrowany klucz danych użytkownika jest dostarczany do urządzenia i odszyfrowywany lokalnie za pomocą klucza prywatnego krzywej eliptycznej użytkownika. Stosowane są następujące metody zatwierdzania urządzeń:

• Keeper Push (przy użyciu powiadomień push) na istniejących urządzeniach użytkowników
• Zatwierdzenie przez administratora za pośrednictwem Konsoli administratora Keeper
• Automatyczne zatwierdzenie za pośrednictwem usługi Keeper Automator
• Automatyczne zatwierdzenie przez administratora za pośrednictwem interfejsu Commander CLI

Dowiedz się więcej na temat zatwierdzania urządzeń.

Prywatność danych

Firma Keeper zachowuje zgodność z RODO i dokłada wszelkich starań, aby jej procesy i produkty były zgodne z RODO dla klientów w Unii Europejskiej i na całym świecie. We comply with the EU-U.S. Data Privacy Framework ("EU-U.S. DPF"), the UK Extension to the EU-U.S. DPF, the German Federal Data Protection Act (BDSG) and the Swiss-U.S. Data Privacy Framework ("Swiss-U.S. DPF") as set forth by the U.S. Department of Commerce.

Zobacz Politykę prywatności RODO firmy Keeper.

Żadna z aplikacji Keeper nie zawiera modułów śledzących ani bibliotek innych firm, które wykonują śledzenie. Przykładowo, niniejszy raport zawiera informacje na temat aplikacji Keeper dla systemu Android, w której nie zainstalowano żadnych modułów śledzących.

Izolacja danych

Keeper to w pełni zarządzana platforma SaaS przechowująca dane w wielu odizolowanych geograficznie centrach danych AWS. Organizacje mogą korzystać z hostingu dzierżawy Keeper w preferowanym regionie podstawowym. Dane klientów i dostęp do platformy są odizolowane od tego wybranego regionu.

Dostępne regiony:

• Stany Zjednoczone (US)
• United States Government Cloud (US_GOV)
• Europa (EU)
• Australia (AU)
• Japonia (JP)
• Kanada (CA)

Szyfrowanie podczas przesyłania

Sejf Keeper jest chroniony przez interfejsy API, które są weryfikowane poprzez autoryzację na urządzeniu użytkownika.

• Użytkownik pobiera token sesji wraz z loginem i wysyła go przy każdym wywołaniu API.
• Token sesji jest zarządzany i kontrolowany na serwerze zaplecza.
• Logowanie odbywa się za pomocą hasła głównego, danych biometrycznych, wznowienia sesji lub uwierzytelniania SSO SAML 2.0.

W przypadku korzystania z hasła głównego urządzenie użytkownika uzyskuje 256-bitowy klucz uwierzytelniający przy użyciu PBKDF2-HMAC_SHA256 z 1 000 000 iteracjami i losową solą. Skrót uwierzytelniający jest tworzony przez mieszanie klucza uwierzytelniającego przy użyciu SHA-256. Podczas logowania skrót uwierzytelniający jest porównywany z zapisanym skrótem uwierzytelniającym w sejfie Keeper. Po zalogowaniu się użytkownika na serwerze tworzony jest token sesji, który jest wysyłany do użytkownika i wykorzystywany przez urządzenie w kolejnych żądaniach API. Aby umożliwić ciągłe korzystanie z komunikacji klient-serwer, sesja musi być aktywna.

• Keeper wykorzystuje 256-bitowy i 128-bitowy protokół TLS do szyfrowania 100% danych przechowywanych w aplikacji użytkownika i bezpiecznym magazynie plików Keeper.
• Keeper wdraża certyfikaty TLS podpisane przy użyciu algorytmu SHA2. SHA2 to najbezpieczniejszy algorytm podpisu udostępniany obecnie przez komercyjne urzędy certyfikacji. Wykorzystanie SHA2 przez Keeper chroni przed fałszywymi certyfikatami, które atakujący mógłby wykorzystać do podszycia się pod stronę internetową.

Uwierzytelnianie w chmurze

Keeper stworzył zaawansowany model uwierzytelniania w chmurze i komunikacji sieciowej z najwyższym poziomem prywatności, bezpieczeństwa, zaufania i przejrzystości. Poniżej przedstawiono kilka kluczowych cech tego modelu uwierzytelniania:

Integracja z dowolnym dostawcą SAML 2.0

Keeper integruje się ze wszystkimi dostawcami tożsamości zgodnymi z SAML 2.0, w tym Okta, Microsoft Entra ID (Azure), AD FS, Google Workspace, Centrify, OneLogin, Ping Identity, JumpCloud, Duo, Auth0 i innymi.

Nasze produkty oferują dwa różne typy SSO: SSO Connect Cloud i SSO Connect On-Prem. Obie implementacje zapewniają architekturę zero-knowledge z płynnym uwierzytelnianiem użytkowników.

Hasła główne użytkowników nigdy nie są przesyłane w warstwie sieciowej

W przeciwieństwie do większości usług SaaS, dane logowania użytkowników Keeper nigdy nie opuszczają ich urządzeń. Gdy użytkownicy logują się do Keeper przy użyciu hasła głównego, na urządzeniu lokalnym wykorzystywany jest PBKDF2 w celu uzyskania 256-bitowego klucza AES do odszyfrowania. Dodatkowy klucz PBKDF2 jest generowany na poziomie urządzenia, a następnie tworzony jest jego skrót za pomocą HMAC_SHA256 w celu utworzenia tokena uwierzytelniającego. Keeper nie ma żadnej wiedzy na temat klucza deszyfrującego użytkownika.

Ruch pomiędzy urządzeniem klienta a Keeper Cloud nie może zostać przechwycony ani odszyfrowany

Wszystkie zaszyfrowane ładunki wysyłane do serwerów Keeper są zabezpieczone 256-bitowym kluczem transmisji AES i TLS w celu ochrony przed atakami typu man-in-the-middle (MITM). Klucz transmisji jest generowany na urządzeniu klienckim i przesyłany do serwera przy użyciu szyfrowania ECIES za pośrednictwem publicznego klucza EC serwera.

Nie można używać nowych urządzeń do logowania się na konto bez etapu weryfikacji

Użytkownicy nie mogą używać nowych urządzeń do logowania się na swoje konta Keeper bez użycia metody weryfikacji. Keeper obsługuje kilka rodzajów metod weryfikacji, w zależności od schematu uwierzytelniania.

Uwierzytelnianie wieloskładnikowe (MFA) jest wykonywane po weryfikacji, zanim użytkownik wprowadzi hasło główne

Jeśli użytkownik ma skonfigurowane lub wymuszone uwierzytelnianie wieloskładnikowe, musi najpierw przejść ten krok przed wprowadzeniem hasła głównego.

Nie można wprowadzić hasła głównego przed ukończeniem etapów weryfikacji urządzenia i MFA

Jeśli nie zostanie skonfigurowana żadna metoda weryfikacji, użytkownik nie będzie mógł przejść do wprowadzania hasła głównego. To zaawansowane uwierzytelnianie chroni przed kilkoma popularnymi metodami ataków, w tym atakami typu brute force, atakami typu „password spray”, wyliczaniem i atakami MITM.

Uwierzytelnianie wieloskładnikowe (MFA)

Aby chronić przed nieautoryzowanym dostępem do konta klienta, Keeper oferuje uwierzytelnianie wieloskładnikowe (MFA) – podejście do uwierzytelniania wymagające co najmniej dwóch składników uwierzytelniania, którymi są składnik wiedzy, posiadania i/lub czynnik nierozłączności. Dowiedz się więcej o konfigurowaniu uwierzytelniania wieloskładnikowego w rozwiązaniu Keeper.

Keeper wykorzystuje Twoje hasło główne i posiadane przez Ciebie urządzenie, aby zapewnić dodatkową warstwę zabezpieczeń, jeśli Twoje hasło główne lub urządzenie zostanie przejęte. Keeper obsługuje klucze sprzętowe FIDO2 WebAuthn i rozwiązania programowe, takie jak TOTP i SMS.

W przypadku korzystania z metody TOTP MFA/2FA Keeper generuje 10-bajtowy tajny klucz przy użyciu kryptograficznie bezpiecznego generatora liczb losowych. Kod ten jest ważny przez około minutę i nie może zostać ponownie użyty po pomyślnym uwierzytelnieniu. Keeper obsługuje dowolną aplikację TOTP, w tym Google Authenticator i Microsoft Authenticator. Keeper integruje się również bezpośrednio z popularnymi usługami MFA, takimi jak Duo i RSA SecurID.

Podczas korzystania z aplikacji uwierzytelniających MFA, takich jak Google Authenticator, Microsoft Authenticator lub innych aplikacji TOTP na Twoim urządzeniu mobilnym, serwer Keeper wewnętrznie generuje kod QR zawierający Twój tajny klucz. Za każdym razem, gdy użytkownik aktywuje MFA, generowany jest nowy klucz.

Aby aktywować uwierzytelnianie wieloskładnikowe, przejdź do ekranu ustawień aplikacji internetowej Keeper, aplikacji komputerowej lub aplikacji dla systemu iOS/Android. Administratorzy Keeper Business mogą również wymusić korzystanie z MFA i obsługiwanych metod MFA za pośrednictwem Konsoli administratora Keeper.

Keeper zapewniaobsługę uwierzytelniani WebAuth zgodnego z FIDO2, a dodatkowym składnikiem są sprzętowe klucze bezpieczeństwa, takie jak YubiKey i klucze Google Titan. Klucze dostępu również są obsługiwane jako metoda 2FA przy użyciu urządzeń fizycznych lub przeglądarek internetowych. Klucze bezpieczeństwa zapewniają bezpieczny sposób wykonywania uwierzytelniania wieloskładnikowego bez konieczności ręcznego wprowadzania kodów przez użytkownika.

Android Smart Watch Apple Smart Watch DUO Entrust Google Authenticator Microsoft Authenticator RSA SecureID Wiadomość tekstowa SMS Titan Security Key TOTP Yubico

Active Directory / LDAP Bridge aplikacji Keeper

Keeper Bridge integruje się z serwerami Active Directory i LDAP, co upraszcza wprowadzanie i wdrażanie użytkowników. Komunikacja Keeper Bridge jest najpierw autoryzowana przez administratora posiadającego uprawnienia zarządzania Bridge. Klucz transmisji jest generowany i udostępniany dla wszystkich kolejnych komunikacji. Klucz transmisji jest stosowany w celu autoryzacji wszystkich operacji wykonywanych przez mostek z wyjątkiem jego uruchamiania. Klucz transmisji można wygenerować ponownie w dowolnej chwili. Klucz zmienia się automatycznie co 30 dni.

Klucz transmisji służy wyłącznie do transmisji, co oznacza, że dany klucz może zostać ponownie zainicjowany, a także unieważniony bez utraty jakichkolwiek danych czy uprawnień.

Keeper Bridge może nie nadać uprawnień dla danej roli lub danemu użytkownikowi. Może też nadać użytkownikowi rolę z określonymi uprawnieniami pod warunkiem, że nie są do tego wymagane żadne klucze. Keeper Bridge nie może podnieść rangi swojej ani użytkownika ponad poziom, którym zarządza. Nie wszystkie operacje są dla niego dostępne, np. Bridge może wyłączyć aktywnego użytkownika, ale nie może go usunąć. To administrator decyduje, czy dany użytkownik ma zostać usunięty czy przeniesiony.

Uwierzytelnianie SSO z MFA

Podczas wdrożenia Keeper z rozwiązaniem SSO, takim jak Entra ID / Azure AD, Okta, Ping, Google Workspace lub innm dostawcą tożsamości SAML 2.0, można w pełni zarządzać MFA podczas procesu logowania dostawcy. Keeper obsługuje również zasady dostępu warunkowego Azure na wszystkich typach urządzeń i we wszystkich aplikacjach.

Uwierzytelnianie MFA może być wymuszane zarówno po stronie dostawcy tożsamości, jak i po stronie Keeper. Na przykład, gdy użytkownik przejdzie etap MFA u dostawcy tożsamości, może zostać dodatkowo zmuszony do przejścia drugiego etapu MFA w interfejsie Keeper. Odpowiednie zasady mogą być wymuszane przez administratora Keeper.

Amazon Web Services CAS Centrify DUO F5 Google Workplace IBM Security JumpCloud Microsoft ADFS Onelogin Okta Ping Identity

Uwierzytelnianie SAML 2.0 z SSO Connect Cloud

Keeper SSO Connect Cloud emożliwia klientom korporacyjnym pełną integrację Keeper z dowolnym dostawcą tożsamości zgodnym z SAML 2.0 i wdrażanie szyfrowanych sejfów dla swoich użytkowników.

SAML implementation with Keeper allows a user to authenticate through their SSO IdP and then decrypt their vault ciphertext on their device. Every user device has an individual Elliptic Curve (EC) key pair and encrypted data key. In addition, each user has their own 256-bit AES data key. When signing in to Keeper using a new device, the user must utilize existing devices to perform an approval or, alternatively, an admin with privileges can approve their device.

This capability is essential so a user can decrypt their vault locally, on their device, without the requirement of a master password or password key derivation. Zero knowledge is maintained because the cloud cannot decrypt the user's data key. Instead, the device-encrypted data key (DEDK) is provided to the user upon successful authentication of the IdP (e.g., Okta, Azure, Google Workspace, AD FS, Ping, Duo, Jumpcloud, etc.). The data key for the user is decrypted locally on the device with the elliptic curve device private key. Keeper holds US Utility Patents on this technology, which has been in production since 2015.

Keeper Automator to opcjonalna usługa na potrzeby natychmiastowego zatwierdzania zespołów, zatwierdzania urządzeń oraz przydzielania użytkowników zespołów po udanym zalogowaniu przez dostawcę tożsamości SSO.

Po uruchomieniu usługi Automator użytkownicy mogą płynnie uzyskać dostęp do rozwiązania Keeper na nowych urządzeniach (które nie zostały wcześniej zatwierdzone) po udanym uwierzytelnieniu u dostawcy tożsamości bez kolejnych etapów zatwierdzania.

Keeper SSO Connect - stacjonarny

Mimo że większość klientów wdraża rozwiązanie Keeper SSO Connect Cloud, klienci wymagający rozwiązania lokalnego mogą wdrożyć SSO Connect On-Prem, czyli integrację do samodzielnego hostingu, która wymaga serwera aplikacji hostowanego na systemie Windows lub Linux. W celu zapewnienia zabezpieczeń zero-knowledgle oraz płynnego środowiska SSO dla użytkowników należy zainstalować Keeper SSO Connect na serwerze klienta. Środowiska Windows, Mac i Linux są w pełni obsługiwane dzięki trybom operacyjnym równoważenia obciążenia o wysokiej dostępności (HA) oraz wielokrotnemu szyfrowaniu z wykorzystaniem sprzętowych modułów bezpieczeństwa.

Keeper SSO Connect automatycznie generuje i utrzymuje hasło główne dla każdego udostępnionego użytkownika, które jest losowo wygenerowanym 256-bitowym kluczem. Hasło główne jest szyfrowane za pomocą klucza SSO. Klucz SSO jest szyfrowany za pomocą klucza drzewa. Klucz SSO jest pobierany z serwera po uruchomieniu usługi Keeper SSO Connect, a następnie odszyfrowywany przy użyciu klucza drzewa, który jest przechowywany lokalnie na serwerze w celu obsługi automatycznego uruchamiania usługi. Komunikacja między SSO Connect a chmurą Keeper Cloud Security Vault firmy jest chroniona za pomocą klucza transmisji. Komunikacja SAML jest podpisywana kryptograficznie i chroniona algorytmem podpisu RSA-SHA256 lub ECDSA-SHA256 w zależności od typu klucza szyfrowania (RSA lub ECC) dostarczonego przez klienta.

Udostępnianie

Keeper obsługuje możliwość bezpiecznego udostępniania wpisów między użytkownikami, wewnętrznemu zespołowi lub nawet poza organizacją (jeśli zezwoli na to administrator Keeper).

=Udostępnianie wpisów

Użytkownicy Keeper mogą bezpośrednio udostępniać sobie nawzajem wpisy. W tym celu Keeper początkowo żąda klucza publicznego krzywej eliptycznej użytkownika z jego sejfu. Każdy wpis ma klucz wpisu, który jest szyfrowany kluczem publicznym krzywej eliptycznej odbiorcy i synchronizowany z sejfem Keeper użytkownika.

Właściciel zaszyfrowanego udostępnionego wpisu odszyfrowuje klucz wpisu za pomocą swojego klucza prywatnego krzywej eliptycznej. Klucz wpisu zostanie również ponownie zaszyfrowany za pomocą klucza danych użytkownika, a szyfrogram zostanie zapisany w sejfie odbiorcy.

Udostępnienie jednorazowe

Funkcja udostępniania jednorazowego Keeper umożliwia ograniczone czasowo, bezpieczne udostępnianie danych – takich jak hasło, poświadczenia, wpis tajny, połączenie, dokument lub inne poufne informacje – dowolnej osobie, nawet jeśli nie posiada ona konta Keeper. Model szyfrowania udostępniania jednorazowego Keeper wykorzystuje tę samą technologię, co Keeper Secrets Manager (KSM) – platformę typu zero-knowledge i zero-trust do zabezpieczania infrastruktury chmury.

1. W sejfie Keeper użytkownika inicjator generuje dostęp jednorazowy, klikając opcję Udostępnianie jednorazowe. 256-bitowy klucz wpisu AES jest szyfrowany za pomocą tokena jednorazowego dostępu, a zaszyfrowana wartość jest przechowywana w sejfie Keeper.
2. Użytkownik udostępniający odbiorcy jednorazowy token dostępu używa prostego adresu URL lub kodu QR. Część adresu URL zawierająca token dostępu jest przechowywana w części „identyfikator fragmentu” adresu URL, który nigdy nie jest wysyłany na serwery Keeper. W związku z tym Keeper nie może uzyskać dostępu do tych informacji ani ich odszyfrować, a zasada zero knowledge zostaje zachowana.
3. Adres URL otwiera się w przeglądarce użytkownika, a aplikacja sejfu jest ładowana na urządzeniu. Token jest przekazywany bezpośrednio do lokalnej aplikacji sejfu i nie jest wysyłany na serwer.
4. Następnie odbiorca używa swojego urządzenia do wygenerowania pary kluczy EC po stronie użytkownika końcowego, a klucz prywatny jest przechowywany lokalnie, na urządzeniu, w pamięci CryptoKey przeglądarki.
5. Przy pierwszym użyciu przez odbiorcę biblioteka SDK uwierzytelnia się za pomocą skrótu jednorazowego tokena dostępu. Następnie serwer Keeper odpowiada zaszyfrowanym szyfrogramem wpisu i zaszyfrowanym kluczem wpisu.
6. Urządzenie odszyfrowuje klucz wpisu za pomocą jednorazowego tokena dostępu, a zawartość jest odszyfrowywana. Klucz jest przechowywany na urządzeniu klienckim w pamięci CryptoKey przeglądarki lub w innej lokalizacji.
7. Zaszyfrowany klucz wpisu dla danego urządzenia jest usuwany, więc token nie może być ponownie użyty. Następnie żądanie klienta musi zostać podpisane kluczem prywatnym.
8. Kolejne wywołania tego samego urządzenia są wysyłane z identyfikatorem definiującym urządzenie i żądaniem podpisanym kluczem prywatnym klienta. Żądanie dla danego identyfikatora urządzenia – poprzez podpis ECDSA – wykorzystuje klucz publiczny klienta urządzenia i jest sprawdzane przez serwer. Keeper przetwarza żądanie, a serwer zwraca zaszyfrowany wpis w postaci szyfrogramu do urządzenia użytkownika.
9. Oprócz szyfrowania na poziomie wpisu, urządzenie klienckie tworzy losowo wygenerowany 256-bitowy klucz transmisji AES, który jest szyfrowany kluczem publicznym API chmury Keeper. Urządzenie klienckie odszyfrowuje odpowiedź z serwera za pomocą klucza transmisji, a następnie odszyfrowuje zaszyfrowany ładunek odpowiedzi za pomocą klucza wpisu, który odszyfrowuje zawartość wpisu.

Administrator udostępniania

Funkcja Administrator udostępniania Keeper to uprawnienie kontroli dostępu opartej na rolach (RBAC), które daje administratorom podwyższone uprawnienia do folderów udostępnionych i wpisów organizacji. Administratorzy udostępniania mają pełne uprawnienia użytkownika i wpisu dla każdego udostępnionego wpisu, do którego mają dostęp.

Model szyfrowania platformy Secrets Manager

Keeper Secrets Manager to platforma typu zero-knowledge dla specjalistów IT i DevOps zespołom zarządzanie wpisami tajnymi w całym cyklu tworzenia i wdrażania oprogramowania.

Secrets Manager wykorzystuje następujący model szyfrowania:

• Szyfrowanie i deszyfrowanie odbywa się lokalnie na urządzeniu (nie na serwerze).
• Zwykły tekst nigdy nie jest przechowywany na urządzeniu.
• Zwykły tekst nigdy nie jest odbierany przez serwer.
• Nikt, w tym pracownicy Keeper, strony trzecie lub pośrednicy, nie może odszyfrować wpisów tajnych.
• Urządzenie klienckie zarządza kluczami do szyfrowania i odszyfrowywania wpisów tajnych pod kontrolą użytkownika.
• Każdy wpis tajny jest szyfrowany przez wygenerowany po stronie klienta 256-bitowy klucz szyfrowania AES w trybie GCM.
• Jeśli wpis tajny znajduje się w folderze współdzielonym, klucz wpisu jest owijany przez klucz folderu współdzielonego.
• 256-bitowy klucz AES aplikacji jest generowany po stronie klienta i używany do odszyfrowania folderu współdzielonego i kluczy wpisów. Klucz wpisu odszyfrowuje następnie indywidualny klucz tajny.
• Serwery Keeper są zabezpieczane 256-bitowym kluczem AES i protokołem TLS w celu ochrony przed atakami MITM.
• Klucz transmisji jest generowany na urządzeniu klienckim i przesyłany do serwera przy użyciu szyfrowania ECIES za pośrednictwem publicznego klucza EC serwera.
• Kryptografia krzywych eliptycznych jest używana do udostępniania wpisów tajnych między użytkownikami w celu bezpiecznej dystrybucji kluczy.
• Wielowarstwowe szyfrowanie zapewnia kontrolę dostępu na poziomie użytkownika, grupy i administratora.
• Wpisy tajne, które zarządzane w sejfie, są segmentowane i izolowane do zdefiniowanych urządzeń Secrets Manager, które mają dostęp do wpisu i folderu.

Model Keeper Secrets Manager na potrzeby wymuszania zmiany haseł

• Unikatowy klient Keeper Secrets Manager (KSM), zwany bramą, jest instalowany w środowisku klienta.
• Brama ustanawia bezpieczne połączenie wychodzące z routerem Keeper.
• Router to usługa w chmurze hostowana w środowisku AWS firmy Keeper, która ułatwia komunikację między interfejsem API zaplecza Keeper, aplikacjami użytkownika końcowego (sejf internetowy, aplikacja komputerowa itp.) i bramami zainstalowanymi w środowisku użytkownika.
• Gniazda internetowe są ustanawiane między urządzeniem użytkownika końcowego (np. sejfem internetowym) a routerem Keeper przy użyciu bieżącego tokena sesji.
• Router Keeper weryfikuje token sesji i uwierzytelnia sesję. Wszystkie zaszyfrowane ładunki wysyłane do routera Keeper są zabezpieczone 256-bitowym kluczem AES, oprócz TLS, w celu ochrony przed atakami MITM.
• 256-bitowy klucz AES jest tworzony na urządzeniu użytkownika końcowego i przesyłany do serwera przy użyciu szyfrowania ECIES za pośrednictwem publicznego klucza EC routera.
• Żądania rotowania i wykrywania są wysyłane między urządzeniem użytkownika końcowego (lub Keeper Scheduler) a bramą za pośrednictwem ustanowionego kanału komunikacji gniazda internetowego.
• Podczas rotowania, gdy brama wymaga wpisu tajnego z sejfu Keeper, uwierzytelnia i odszyfrowuje wpis tajny za pomocą interfejsów API Keeper Secrets Manager, aby zachować podejście zero knowledge.
• Podobnie jak w przypadku każdego innego urządzenia Secrets Manager, oprócz procesu szyfrowania i podpisywania dostęp może być również ograniczony na podstawie adresu IP.

Połączenie zero-trust i zabezpieczenie tunelu

Rozwiązanie KeeperPAM typu zero-trust umożliwia ustanawianie sesji uprzywilejowanych w chmurze i lokalnych, tworzenie tuneli, bezpośredni dostęp do infrastruktury oraz bezpieczny zdalny dostęp do baz danych bez konieczności użycia VPN.

Połączenie to wizualna sesja zdalna za pośrednictwem przeglądarki internetowej. Interakcja pomiędzy użytkownikiem i urządzeniem docelowym odbywa się w oknie przeglądarki internetowej lub w aplikacji Keeper Desktop.

Tunel to połączenie TCP/IP ustanawiane pomiędzy klientem magazynu lokalnego a docelowym punktem końcowym za pośrednictwem bramy Keeper Użytkownik może wykorzystać dowolną aplikację natywną do komunikacji z docelowym punktem końcowym, na przykład terminal wiersza polecenia, aplikację GUI lub aplikację do zarządzania bazami danych, taką jak MySQL Workbench.

Gdy użytkownik ustanawia połączenie lub tunel:

1. Aplikacja klienta magazynu komunikuje się z infrastrukturą routera Keeper w celu zainicjowania połączenia WebRTC chronionego kluczem symetrycznym ECDH przechowywanym w odpowiednim wpisie Keeper.
2. Brama Keeper komunikuje się z routerem Keeper za pośrednictwem protokołu WebSocket obejmującego wyłącznie ruch wychodzący. Szczegółowy opis jest dostępny tutaj.
3. Brama Keeper wykorzystuje interfejsy API Keeper Secrets Manager do pobrania niezbędnych wpisów tajnych z magazynu, w tym klucza symetrycznego ECDH.
4. W przypadku połączeń klient magazynu (wykorzystujący protokół Apache Guacamole) przesyła dane za pośrednictwem połączenia WebRTC do bramy Keeper, która następnie wykorzystuje Guacd do połączenia z miejscem docelowym zawartym we wpisie Keeper.
5. W przypadku funkcji tunelowania (przekierowanie portów) na urządzeniu lokalnym z oprogramowaniem Keeper Desktop otwierany jest port lokalny. Dane wysyłane do portu lokalnego są przesyłane za pośrednictwem połączenia WebRTC do bramy Keeper, a następnie przekazywane do docelowego punktu końcowego określonego we wpisie Keeper.
6. Nagrania sesji połączeń są chronione kluczem szyfrowania AES-256 („klucz nagrywania”) generowanym w bramie Keeper podczas każdej sesji. Klucz nagrywania jest dodatkowo opakowany kluczem zasobu AES-256 generowanym przez funkcję HKDF.

Zabezpieczenie zdalnej izolacji przeglądarki

Technologia zdalnej izolacji przeglądarki Keeper chroni dostęp do wewnętrznych aplikacji internetowych lub innych zasobów internetowych za pośrednictwem kontenera Docker rozwiązania Keeper Connection Manager albo za pośrednictwem bramy Keeper.

Wykorzystanie metody kontenera Docker rozwiązania Connection Manager:

1. Użytkownik przeprowadza uwierzytelnienie do usługi internetowej Keeper Connection Manager hostowanej przez klienta w kontenerze Docker.
2. Użytkownik uruchamia sesję zdalnej izolacji przeglądarki w docelowej aplikacji Web. Komunikacja realizowana za pośrednictwem protokołu HTTPS pomiędzy przeglądarką użytkownika a hostowaną usługą internetową Keeper Connection Manager jest chroniona za pomocą Let's Encrypt lub określonego certyfikatu klienta.
3. Wewnątrz kontenera Docker usługi Keeper Connection Manager uruchamiana jest wbudowana wersja Chromium w piaskownicy, a docelowa strona internetowa jest renderowana przy użyciu lokalnego sterownika wyświetlania, który przesyła strumieniowo widoczną zawartość strony w czasie rzeczywistym do przeglądarki internetowej użytkownika za pośrednictwem protokołu Apache Guacamole.

Wykorzystanie bramy Keeper z magazynem Web Keeper lub aplikacją komputerową:

1. Aplikacja klienta magazynu komunikuje się z infrastrukturą routera Keeper w celu zainicjowania połączenia WebRTC chronionego kluczem symetrycznym ECDH przechowywanym w odpowiednim wpisie Keeper.
2. Brama Keeper komunikuje się z routerem Keeper za pośrednictwem protokołu WebSocket obejmującego wyłącznie ruch wychodzący. Szczegółowy opis jest dostępny tutaj.
3. Brama Keeper wykorzystuje interfejsy API Keeper Secrets Manager do pobrania niezbędnych wpisów tajnych z magazynu, w tym klucza symetrycznego ECDH.
4. Klient magazynu (wykorzystujący protokół Apache Guacamole) przesyła dane za pośrednictwem połączenia WebRTC do bramy Keeper, która następnie wykorzystuje protokół HTTP lub HTTPS do połączenia z miejscem docelowym zawartym we wpisie Keeper.
5. Nagrania sesji połączeń są chronione kluczem szyfrowania AES-256 („klucz nagrywania”) generowanym w bramie Keeper podczas każdej sesji. Klucz nagrywania jest dodatkowo opakowany kluczem zasobu AES-256 generowanym przez funkcję HKDF.

Ochrona izolacji przeglądarki

Wykorzystanie protokołu zdalnej izolacji zapewnia kilka środków bezpieczeństwa:

1. Chroniony punkt końcowy aplikacji internetowej jest opakowany warstwą szyfrowania TLS z bramy Keeper Connection Manager do urządzenia lokalnego użytkownika niezależnie od tego, czy pomiędzy bramą a punktem końcowym wykorzystano TLS — co zapewnia ochronę przed atakiem MITM lub inspekcją pakietów w sieci lokalnej użytkownika.
2. Sesja zdalnego przeglądania przedstawia wizualnie interakcję z urządzeniem lokalnym użytkownika za pomocą kanwy i renderowania grafiki. Na komputerze lokalnym użytkownika nie jest wykonywany żaden kod JavaScript ani kod HTML z docelowej strony internetowej.
3. Ponieważ żaden kod z docelowej strony internetowej nie jest wykonywany lokalnie, a lokalna przeglądarka nie może bezpośrednio uzyskać dostępu do kodu aplikacji, odizolowana aplikacja internetowa jest chroniona przed wektorami ataku takimi jak odwzorowane luki w zabezpieczeniach skryptów między witrynami, fałszowanie żądań między witrynami oraz nadużycie interfejsu API.
4. Można ograniczyć możliwość eksportowania przez użytkownika danych z docelowego punktu końcowego za pośrednictwem filtrowania adresów URL i żądań zasobów. Ograniczone jest przesyłanie i pobieranie plików, nawet jeśli docelowa aplikacja internetowa zezwala na takie działanie.
5. Istnieje możliwość rejestrowania sesji przeglądania i naciśnięć klawiszy na potrzeby audytu oraz zapewnienia zgodności, co umożliwia analizę śledczą sesji internetowych.
6. Dane uwierzytelniające automatycznie wypełniane z bramy do docelowej aplikacji internetowej nigdy nie zostają przesłane do urządzenia użytkownika ani nie są dostępne dla użytkownika na urządzeniu lokalnym, co chroni przed wyciekiem wpisów tajnych.
7. Zasady zapory mogą wymagać od użytkownika dostępu do docelowej aplikacji internetowej wyłącznie za pośrednictwem zdalnej sesji izolacji przeglądarki, co zmniejsza zagrożenie związane z naruszonym oprogramowaniem przeglądarki lub złośliwym oprogramowaniem urządzenia lokalnego.
8. Docelowa aplikacja internetowa zostaje objęta ochroną za pośrednictwem uwierzytelniania jednokrotnego lub MFA, nawet jeśli aplikacja nie obsługuje jej natywnie. Keeper chroni dostęp do magazynu i sesji zdalnej izolacji przeglądarki za pośrednictwem zaawansowanych metod uwierzytelniania opisanych w tym dokumencie.

BreachWatch^®

Keeper posiada zarządzaną, niezależną architekturę w usłudze AWS o nazwie BreachWatch. BreachWatch jest fizycznie oddzielony od interfejsu API Keeper i wpisów użytkowników.

Fizyczny sprzętowy moduł bezpieczeństwa (HSM) na serwerach BreachWatch służy do przetwarzania, tworzenia skrótów i przechowywania miliardów unikalnych haseł pochodzących z naruszeń danych w dark webie. Wszystkie hasła są przetwarzane na serwerach Keeper przy użyciu metody tworzenia skrótów HMAC_SHA512. Skróty są tworzone przez HSM przy użyciu klucza, którego nie można eksportować.

Gdy usługa BreachWatch zostaje aktywowana na urządzeniu klienckim, skrót HMAC_SHA512 jest generowany na podstawie każdego wpisu i wysyłany na serwer. Na serwerze tworzony jest drugi skrót przy użyciu HMAC_SHA512 za pośrednictwem HSM przy użyciu klucza, którego nie można eksportować. Skróty skrótów są porównywane, aby sprawdzić, czy poświadczenia zostały naruszone.

Architektura BreachWatch została zbudowana tak, aby zapobiec korelacji złamanego hasła z hasłem w sejfie użytkownika, bez względu na rozmiar naruszenia danych. Wykrywanie złamanych haseł wykorzystuje fizyczny moduł HSM, aby upewnić się, że tworzenie skrótów może być wykonywane tylko online, co pozwala zapobiec atakom siłowym na dane.

• Skróty haseł są tworzone dwukrotnie za pomocą HMAC_512: raz na urządzeniu klienckim przy użyciu „pieprzu”, a raz w AWS CloudHSM przy użyciu sprzętowego modułu bezpieczeństwa z kluczem, którego nie można eksportować.
• HMAC_512 jest wykorzystywany, ponieważ wykorzystuje silną funkcję tworzenia skrótów oraz tajny klucz, którego nie można eksportować. Z tego powodu atak offline na skróty nie jest możliwy.
• Kod uwierzytelniania komunikatu (MAC) z wynikiem kryptograficznej funkcji skrótu rozszerza zastosowanie funkcji skrótu. Jego wyniki zależą nie tylko od komunikatu, ale także od innych danych wejściowych, takich jak tajny klucz.

BreachWatch jest w 100% tworzony przez Keeper przy użyciu kanałów danych SpyCloud, ale Keeper nigdy nie wysyła żadnych danych stronom trzecim.

Skanowanie domen

Klienci BreachWatch pobierają listę domen, które zostały zaatakowane i sprawdzają je lokalnie.

Skanowanie nazw użytkowników i haseł

Urządzenia klienckie łączą się z BreachWatch i przesyłają listę zaszyfrowanych nazw użytkowników (lub haseł) wraz z wybranym przez klienta, losowym identyfikatorem (oddzielne identyfikatory dla usług sprawdzania nazw użytkowników i haseł). Te skróty haseł są przetwarzane podczas przesyłania za pomocą HMAC przy użyciu sprzętowego modułu bezpieczeństwa (HSM) i tajnego klucza przechowywanego w HSM oznaczonego jako nieeksportowalny (co oznacza, że HSM przetworzy HMAC tylko lokalnie, a klucza nie można wyodrębnić). Te dane wejściowe HMAC (nazwy użytkowników lub hasła) są porównywane z zestawami danych naruszeń, które zostały przetworzone przy użyciu tego samego HMAC i klucza. Wszelkie dopasowania są zgłaszane do urządzenia klienckiego. Wszelkie wartości, które nie są zgodne, są przechowywane wraz z anonimowym identyfikatorem klienta.

Gdy nowe naruszone nazwy użytkowników i hasła zostają dodane do systemu, są one przetwarzane za pomocą HMAC na HSM, dodawane do zbioru danych BreachWatch i porównywane z przechowywanymi wartościami klienta. Wszelkie dopasowania ustawiają alert w kolejce dla tego identyfikatora klienta.

Klient okresowo sprawdza BreachWatch i podaje identyfikator BreachWatch. Pobierane są wszystkie wiadomości, a klient przesyła nowe lub zmienione nazwy użytkowników i hasła, które zostaną poddane temu samemu procesowi.

Bezpieczeństwo BreachWatch jest oparte na modelu TOFU (Zaufanie przy pierwszym użyciu). Oznacza to, że klienci muszą przyjąć, że w momencie przesyłania ich zaszyfrowanych wartości, serwer BreachWatch nie jest zaatakowany przez hakerów. Wartości te, po ich przetworzeniu przy użyciu HSM, są zabezpieczane przed zewnętrznymi atakami hakerów. Tak więc, nawet jeśli haker ukradnie zestaw danych zawierający wartości klienta, nie będzie w stanie złamać tych wartości offline bez kodu HMAC przechowywanego w module HSM.

W przypadku wykrycia naruszenia hasła urządzenie klienckie wysyła skrót kombinacji nazwy użytkownika i hasła do serwerów BreachWatch, które następnie wykonują to samo porównanie skrótu HMAC w celu ustalenia, czy kombinacja nazwy użytkownika i hasła została naruszona, a jeśli tak, domeny związane z tymi naruszeniami są zwracane, aby urządzenie klienckie mogło określić, czy nazwa użytkownika + hasło + domena są zgodne. Jeśli wszystkie trzy parametry są zgodne na urządzeniu klienckim, użytkownik jest ostrzegany o istotności naruszenia.

BreachWatch dla klientów firmowych i korporacyjnych

Po aktywacji BreachWatch dla klientów firmowych i korporacyjnych sejfy użytkowników końcowych są skanowane automatycznie za każdym razem, gdy użytkownik loguje się do Keeper. Dane podsumowujące BreachWatch zeskanowane na urządzeniu użytkownika są szyfrowane kluczem publicznym przedsiębiorstwa i odszyfrowywane przez administratora przedsiębiorstwa po zalogowaniu się do Konsoli administratora Keeper. Te zaszyfrowane informacje obejmują adres e-mail, liczbę wpisów wysokiego ryzyka, liczbę rozwiązanych wpisów i liczbę zignorowanych wpisów. Administrator Keeper może przeglądać statystyki podsumowujące na poziomie użytkownika w interfejsie użytkownika Konsoli administratora.

Logowanie zdarzeń i raportowanie

Po zintegrowaniu z modułem Zaawansowane raportowanie i ostrzeżenia urządzenia użytkowników końcowych Keeper mogą być również opcjonalnie skonfigurowane do przesyłania szczegółowych zdarzeń w czasie rzeczywistym do rozwiązań SIEM innych firm i interfejsu raportowania Konsoli administratora Keeper. Dane zdarzenia zawierają adres e-mail, identyfikator UID wpisu, adres IP i informacje o urządzeniu (zdarzenia nie zawierają żadnych odszyfrowanych danych wpisu, ponieważ Keeper jest platformą zero-knowledge i nie może odszyfrować danych użytkownika).

Domyślnie szczegółowe dane zdarzeń BreachWatch nie są wysyłane do modułu Zaawansowane raportowanie i ostrzeżenia ani do żadnych podłączonych zewnętrznych systemów rejestrowania. Aby aktywować raportowanie danych BreachWatch na poziomie zdarzeń do modułu Zaawansowane raportowanie i ostrzeżenia, należy włączyć zasady egzekwowania roli zdarzenia na ekranie określona rola > Zasady egzekwowania > Funkcje sejfu. Po aktywacji urządzenia klienckie użytkowników końcowych zaczną wysyłać te dane zdarzeń. Ponieważ integracja z rozwiązaniami SIEM innych firm jest przesyłana z zaplecza Keeper do docelowego SIEM, te informacje o zdarzeniach są odczytywane przez docelowy SIEM i mogą zostać wykorzystane do zidentyfikowania, które wpisy i którzy użytkownicy w organizacji mają hasła wysokiego ryzyka. Jeśli administrator Keeper nie chce przesyłać danych zdarzeń na poziomie rekordów do modułu Zaawansowane raportowanie i ostrzeżenia Keeper, ustawienie to można pozostawić wyłączone.

Splunk Sumo Logic LogRhythm Syslog Push IBM QRadar Azure Sentinel AWS S3 Bucket Devo Datadog Logz.io Elastic

Tryb off-line

Tryb offline umożliwia użytkownikom dostęp do sejfu, gdy nie mogą połączyć się online z Keeper lub swoim dostawcą tożsamości SSO. Ta funkcja jest dostępna w aplikacji mobilnej Keeper, aplikacji komputerowej i sejfie internetowym we wszystkich przeglądarkach.

Funkcja ta działa poprzez utworzenie kopii sejfu na lokalnym urządzeniu użytkownika. Przechowywane offline dane sejfu są szyfrowane AES-GCM za pomocą 256-bitowego „klucza klienta”, który jest generowany losowo i chroniony przez PBKDF2-HMAC-SHA512 z 1 000 000 iteracjami i losową solą. Sól i iteracje są przechowywane lokalnie. Gdy użytkownik wprowadza swoje hasło główne lub używa danych biometrycznych, klucz jest wyprowadzany przy użyciu soli i iteracji oraz podejmowana jest próba odszyfrowania klucza klienta. Klucz klienta jest następnie używany do odszyfrowania przechowywanej pamięci podręcznej wpisów. Jeśli w sejfie użytkownika włączona jest ochrona przed autodestrukcją, 5 nieudanych prób logowania spowoduje automatyczne wyczyszczenie wszystkich lokalnie przechowywanych danych sejfu. W przypadku klientów biznesowych dostęp offline może zostać ograniczony na podstawie zasad egzekwowania ról przez administratora Keeper.

Dostęp awaryjny (cyfrowe dziedzictwo)

Plany indywidualne i rodzinne Keeper pozwalają użytkownikom na dodanie do pięciu kontaktów awaryjnych w celu przyznania dostępu do sejfu w przypadku śmierci użytkownika lub innej sytuacji awaryjnej. Użytkownik określa czas oczekiwania, a po jego upływie kontakt awaryjny uzyska dostęp do sejfu użytkownika. Udostępnianie sejfu osobie kontaktowej w nagłych wypadkach odbywa się na zasadzie zero knowledge, a hasło główne użytkownika nigdy nie jest udostępniane. Ponadto używane jest 2048-bitowe szyfrowanie RSA z 256-bitowym kluczem AES. Kontakt awaryjny musi mieć konto Keeper, aby zaakceptować informacje.

Architektura sieci

Keeper korzysta z usług AWS w Ameryce Północnej (w chmurze komercyjnej lub GovCloud), Europie, Australii, Japonii i Kanadzie w celu zapewnienia zlokalizowanej prywatności danych i izolacji geograficznej, aby hostować i obsługiwać rozwiązania i architekturę Keeper. Wykorzystanie usług AWS pozwala firmie Keeper płynnie skalować zasoby na żądanie i zapewniać klientom najszybsze i najbezpieczniejsze środowisko przechowywania danych w chmurze. Keeper obsługuje zarówno środowiska wielostrefowe, jak i wieloregionalne, aby zmaksymalizować czas działania i zapewnić klientom najszybszy czas reakcji. Klienci korporacyjni mogą hostować swoją dzierżawę Keeper w dowolnym preferowanym regionie podstawowym. Dane klientów i dostęp do platformy są izolowane do tego konkretnego regionu.

Uwierzytelnianie w chmurze

Keeper stworzył zaawansowany model uwierzytelniania w chmurze i komunikacji sieciowej, który został zbudowany z myślą o najwyższym poziomie prywatności, bezpieczeństwa i zaufania. Poniżej przedstawiono kilka kluczowych cech tego modelu uwierzytelniania:

• Hasło główne nigdy nie jest przesyłane przez warstwę sieciową. W przeciwieństwie do większości usług SaaS, dane logowania nigdy nie opuszczają urządzenia. PBKDF2 jest wykorzystywany na urządzeniu lokalnym do uzyskania 256-bitowego klucza AES używanego do deszyfrowania. Drugi klucz PBKDF2 jest generowany lokalnie, a następnie hashowany za pomocą HMAC_SHA256 w celu uzyskania tokenu uwierzytelniającego. Sejf Keeper Cloud Security Vault nie posiada żadnej wiedzy na temat klucza deszyfrującego użytkownika.
• Ruch między urządzeniem klienckim a chmurą Keeper nie może zostać przechwycony ani odszyfrowany. Keeper wykorzystuje przypinanie kluczy i dodatkowe warstwy szyfrowania na poziomie sieci (klucze transmisji) między urządzeniem a serwerami Keeper, aby uniemożliwić ataki MITM.
• Nowe urządzenia nie mogą zalogować się na konto bez weryfikacji urządzenia. Żadne próby logowania nie mogą być podejmowane na koncie bez przejścia tego kroku. Keeper obsługuje kilka rodzajów metod weryfikacji urządzeń, które zależą od używanego schematu uwierzytelniania.
• Uwierzytelnianie 2FA jest wykonywane po weryfikacji urządzenia, przed wprowadzeniem hasła głównego. Jeśli użytkownik ma skonfigurowane lub wymuszone 2FA, ten krok musi przejść przed wprowadzeniem hasła głównego.
• Nie można wprowadzić hasła głównego, dopóki nie powiedzie się weryfikacja urządzenia i uwierzytelnianie 2FA. Użytkownik nie może przejść do kroku wprowadzania hasła głównego bez uprzedniego przeprowadzenia weryfikacji urządzenia i uwierzytelnienia 2FA. Ten zaawansowany przepływ uwierzytelniania zapewnia ochronę przed kilkoma wektorami ataków, w tym atakami siłowymi, atakami typu „password spray”, wyliczaniem i atakami MITM.

Szyfrowanie podczas przesyłania

Sejf Keeper Cloud Security Vault jest chroniony przez interfejsy API, które są weryfikowane poprzez autoryzację przez urządzenie klienckie. Klient pobiera token sesji podczas logowania i wysyła go przy każdym wywołaniu API. Token sesji jest śledzony na serwerze. Logowanie odbywa się za pomocą hasła głównego, wznowienia sesji lub uwierzytelniania SSO SAML 2.0.

W przypadku korzystania z hasła głównego urządzenie klienckie uzyskuje 256-bitowy klucz uwierzytelniający przy użyciu PBKDF2-HMAC_SHA256 z 1 000 000 iteracjami i 128-bitową losową solą. „Skrót uwierzytelniający” jest tworzony przez mieszanie klucza uwierzytelniającego przy użyciu SHA-256. Podczas logowania skrót uwierzytelniający jest porównywany z zapisanym skrótem uwierzytelniającym w sejfie Keeper. Po zalogowaniu się użytkownika na serwerze tworzony jest token sesji, który jest wysyłany do użytkownika i wykorzystywany przez urządzenie w kolejnych żądaniach API. Aby umożliwić ciągłe korzystanie z komunikacji klient-serwer, sesja musi być aktywna.

Keeper wykorzystuje 256-bitowy i 128-bitowy protokół TLS w celu szyfrowania wszystkich danych przesyłanych między aplikacją kliencką a magazynem w chmurze Keeper.

Keeper wdraża certyfikaty TLS podpisane przez DigiCert przy użyciu algorytmu SHA2, najbezpieczniejszego algorytmu podpisu oferowanego obecnie przez komercyjne urzędy certyfikacji. SHA2 jest znacznie bezpieczniejszy niż powszechnie stosowany SHA1, który może zostać wykorzystany ze względu na słabość matematyczną zidentyfikowaną w algorytmie. SHA2 pomaga chronić przed wydawaniem fałszywych certyfikatów, które mogłyby zostać wykorzystane przez atakującego do podszycia się pod stronę internetową.

Keeper obsługuje również tzw. przejrzystość certyfikatów (Certificate Transparency – CT), która jest nową inicjatywą Google mającą na celu stworzenie dostępnego powszechnie spisu certyfikatów podpisanego przez urzędy certyfikacji. Przejrzystość certyfikatów ma pomagać w zapobieganiu wydawaniu certyfikatów przez nieupoważnione do tego podmioty i w chwili obecnej jest obsługiwana przez najnowsze wersje przeglądarek Chrome, Safari i Brave. Więcej informacji na temat przejrzystości certyfikatów można znaleźć na stronie internetowej: https://certificate.transparency.dev/. Keeper obsługuje następujące zestawy szyfrów TLS:

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES128-SHA256
• ECDHE-RSA-AES128-SHA256
• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA384

Urządzenia klienckie Keeper z systemami iOS i Android wdrażają również przypisanie kluczy, czyli mechanizm bezpieczeństwa, który zapobiega podszywaniu się pod osoby atakujące przy użyciu fałszywych certyfikatów cyfrowych.

Ochrona przed atakami XSS (Cross-Site Scripting)

Sejf internetowy Keeper stosuje restrykcyjną politykę w zakresie bezpieczeństwa zawartości, która ogranicza źródło żądań wychodzących i zapobiega wykonywaniu wszystkich skryptów, z wyjątkiem tych, których źródłem jest Keeper, w tym skryptów wbudowanych i atrybutów HTML obsługujących zdarzenia. Tym samym ogranicza się lub eliminuje większość wektorów dla ataków XSS.

Dostęp do nazw domen Keeper jest ograniczony do protokołu HTTPS z TLS 1.3 i jest egzekwowany przez HTTP Strict Transport Security. Zapobiega to szerokiej gamie prób podsłuchiwania pakietów, modyfikacji danych i atakom typu man-in-the-middle.

W ramach rozszerzenia przeglądarki Keeper użytkownicy nie będą otrzymywać monitów logowania do swoich sejfów Keeper w obszarze ramki strony. Logowanie do rozszerzenia odbywa się w obszarze paska zadań rozszerzenia przeglądarki w danej przeglądarce. Logowanie do sejfu w przeglądarce internetowej zawsze przebiega w domenie keepersecurity.com, keepersecurity.eu, keepersecurity.com.au, keepersecurity.jp, keepersecurity.ca lub govcloud.keepersecurity.us, bądź z paska narzędzi rozszerzenia przeglądarki Keeper, który nie jest częścią strony zawartości.

Rozszerzenie przeglądarki Keeper umieszcza ramkę iFrame w formularzach logowania na stronie internetowej, aby zapewnić, że żadna złośliwa witryna nie będzie miała dostępu do wstrzykniętej zawartości. Treść wpisów wstrzykiwana do ramek iFrame jest również ograniczona do wpisów sejfu przechowywanych w sejfie użytkownika, które odpowiadają domenie strony docelowej. Keeper nie będzie oferował automatycznego uzupełniania danych logowania lub hasła, jeśli domena strony nie będzie zgodna z polem domeny strony we wpisie sejfu Keeper. Rozszerzenie nie będzie wyświetlać wpisów, jeśli nie są one zgodne z domeną główną adresu strony internetowej.

Zewnętrzne rozszerzenia przeglądarki mogą posiadać wyższe uprawnienia w przeglądarkach internetowych i uzyskiwać dostęp do informacji na danej stronie. Z tego powodu zaleca się, by administratorzy Keeper uniemożliwili użytkownikom instalowanie niezatwierdzonych zewnętrznych rozszerzeń przeglądarki ze sklepów z aplikacjami.

Biometria

Keeper natywnie obsługuje Windows Hello, Touch ID, Face ID i biometrię w systemie Android. Klienci, którzy normalnie logują się do swojego sejfu Keeper za pomocą hasła głównego lub loginu SSO przedsiębiorstwa (SAML 2.0), mogą również logować się do swoich urządzeń za pomocą danych biometrycznych. Dane biometryczne muszą zostać włączone przez administratora Keeper w zasadach ról. Dostęp offline można również uzyskać za pomocą danych biometrycznych zarówno w przypadku hasła głównego, jak i użytkowników korzystających z logowania SSO, gdy ta funkcja jest włączona.

Gdy logowanie biometryczne jest włączone na urządzeniu, klucz jest generowany losowo lokalnie i przechowywany w bezpiecznej enklawie (np. w pęku kluczy lub magazynie kluczy) urządzenia. Klucz danych użytkownika jest szyfrowany za pomocą klucza biometrycznego. Po pomyślnym uwierzytelnieniu biometrycznym klucz jest pobierany, a użytkownik może odszyfrować swój sejf.

Pęk kluczy iOS, Touch ID i Face ID

Funkcje Touch ID i Face ID na urządzeniach z systemem iOS umożliwiają użytkownikom dostęp do sejfu Keeper za pomocą danych biometrycznych. Aby zapewnić tę wygodną funkcję, losowo wygenerowany 256-bitowy ‚klucz biometryczny” jest przechowywany w pęku kluczy iOS. Element pęku kluczy iOS utworzony dla tej funkcji nie jest przeznaczony do synchronizacji z pękiem kluczy iCloud, a zatem nie opuści Twojego urządzenia mobilnego z systemem iOS.

Zdecydowanie zaleca się używanie złożonego hasła głównego i włączenie uwierzytelniania wieloskładnikowego w celu zapewnienia maksymalnego bezpieczeństwa zaszyfrowanego sejfu Keeper. Korzystanie z funkcji Touch ID i Face ID sprawia, że wygodniej jest używać złożonego hasła głównego na urządzeniu mobilnym z systemem iOS. Zaleca się również ustawienie hasła dłuższego niż minimalne 4 cyfry w celu zabezpieczenia pęku kluczy iOS.

Pęk kluczy iOS jest używany przez system iOS i aplikacje do bezpiecznego przechowywania danych uwierzytelniających. Aplikacje iOS używają pęku kluczy iOS do przechowywania różnych poufnych informacji, w tym haseł do stron internetowych, kluczy, numerów kart kredytowych i danych Apple Pay. Keeper nie używa pęku kluczy iOS do przechowywania Twoich danych Keeper – wszystkie dane Keeper są chronione 256-bitowym szyfrowaniem AES i bezpiecznie przechowywane w sejfie Keeper. Pęk kluczy iOS jest również szyfrowany 256-bitowym szyfrowaniem AES przy użyciu kodu urządzenia. Nawet jeśli urządzenie zostanie zgubione lub skradzione albo osoba atakująca uzyska fizyczny dostęp do urządzenia mobilnego, nie będzie w stanie uzyskać dostępu do żadnych przechowywanych informacji Keeper. Pęk kluczy iOS nie może zostać odszyfrowany bez kodu dostępu, a sejf Keeper nie może zostać odszyfrowany bez hasła głównego Keeper użytkownika.

Apple Watch^®

Funkcja ulubionych na zegarku Apple Watch umożliwia wyświetlanie wybranych wpisów na sparowanym zegarku. Wpisy aplikacji Keeper muszą zostać jednoznacznie oznaczone w celu wyświetlania na zegarku Apple Watch. Sparowany zegarek Apple Watch komunikuje się z rozszerzeniem Keeper dla zegarka działającym transparentnie w przestrzeni piaskownicy, która jest niezależna od aplikacji Keeper dla systemu iOS. Rozszerzenie Keeper dla zegarka używa także pęku kluczy systemu iOS w celu bezpiecznego przechowywania i uzyskiwania dostępu do kluczy, aby umożliwić płynną i bezpieczną komunikację z aplikacją Keeper dla systemu iOS.

Keeper DNA^®

Keeper DNA zapewnia metodę uwierzytelniania wieloskładnikowego przy użyciu inteligentnego zegarka (smartwatcha). Keeper DNA wykorzystuje bezpieczne tokeny przechowywane w Keeper Vault do generowania kodów czasowych do uwierzytelniania wieloskładnikowego. Te czasowe żądania uwierzytelnienia mogą być zatwierdzane i wysyłane automatycznie z Apple Watch (lub urządzenia Android Wear) poprzez dotknięcie ekranu zegarka lub wprowadzane ręcznie przez użytkownika.

Usuwanie pracowników z organizacji (transfer magazynu)

Gdy zasady transferu kont są aktywowane dla węzła, zasady węzła dla pary kluczy publicznego/prywatnego są tworzone w Konsoli administratora na urządzeniu użytkownika. Klucz danych użytkownika końcowego – dla użytkowników w roli, do której stosowane jest egzekwowanie – jest szyfrowany kluczem publicznym zasad, gdy użytkownik loguje się do sejfu. Klucz prywatny jest szyfrowany za pomocą klucza publicznego administratora, a administrator może następnie odszyfrować klucz egzekwowania roli za pomocą transferu sejfu.

Podczas transferu sejfu administrator Keeper musi najpierw zablokować konto użytkownika. Transfer sejfu może nastąpić natychmiast, po czym konto użytkownika zostanie usunięte. Dzięki temu operacja nie jest wykonywana w tajemnicy. Podczas transferu klucz danych użytkownika jest pobierany poprzez rozpakowanie klucza prywatnego egzekwowania ról, a następnie rozpakowanie klucza danych użytkownika. Klucz danych jest używany do rozpakowywania kluczy wpisów, kluczy zespołów i kluczy folderów.

Całe szyfrowanie odbywa się po stronie klienta w Konsoli administratora i w żadnym momencie Keeper nie ma możliwości odszyfrowania udostępnianych lub przesyłanych informacji. Ponadto w żadnym momencie klucz danych klienta użytkownika nie jest udostępniany. Użytkownik, który zostanie usunięty z zespołu, folderu udostępnionego lub udziału bezpośredniego, nie otrzyma nowych danych z zespołu, folderu udostępnionego lub wpisu. Chociaż klucze wpisów, folderów i zespołów są odszyfrowywane lokalnie dla administratora podczas transakcji, klucze te nie mogą być używane do uzyskania dostępu do bazowych danych wpisów lub folderów.

Podczas transferu sejfu administrator otrzymuje tylko zaszyfrowany klucz danych, zaszyfrowane klucze wpisów i zaszyfrowane klucze folderów. Odszyfrowuje te klucze, które są następnie ponownie szyfrowane za pomocą klucza publicznego sejfu docelowego. Nigdy nie uzyskują dostępu do rzeczywistych danych wpisu. Keeper nie szyfruje bezpośrednio danych przechowywanych przez klienta za pomocą klucza danych – odbywa się to na urządzeniu.

Certyfikaty i zgodność

Keeper bardzo poważnie podchodzi do kwestii bezpieczeństwa. Keeper to najbezpieczniejsze oraz najbardziej certyfikowane, przetestowane i audytowane rozwiązanie do zabezpieczania haseł i platforma do zarządzania dostępem uprzywilejowanym na świecie. Keeper najdłużej o w branży posiada certyfikaty SOC 2 i ISO. Keeper otrzymał certyfikaty ISO ISO 27001, 27017 i 27018. Keeper jest zgodny z RODO, CCPA, HIPAA, FedRAMP i StateRAMP, PCI DSS i TrustArc w zakresie ochrony prywatności.

• Zespoły programistów Keeper składają się z pełnoetatowych pracowników zlokalizowanych w Stanach Zjednoczonych.
• Keeper nie przechowuje haseł, poświadczeń ani wpisów tajnych, takich jak klucze dostępu, w swoim kodzie źródłowym. Regularnie skanujemy kod źródłowy w poszukiwaniu takich informacji.
• Kod źródłowy Keeper, choć przechowywany prywatnie w GitHub Enterprise, nie dostarcza informacji wymaganych do uzyskania dostępu do sejfu użytkownika, ponieważ szyfrowanie danych odbywa się na poziomie urządzenia. Znaczna część tego kodu jest opublikowana w naszym publicznym repozytorium GitHub jako część produktów Commander i Secrets Manager firmy Keeper.
• Keeper nie umieszcza kodu zewnętrznego dostawcy MFA w swoich aplikacjach. Dostawcy Keeper nie byli przedmiotem żadnych naruszeń dotyczących Keeper.
• Keeper nie zapewnia stronom trzecim możliwości zarządzania ani dostępu do naszych centrów danych AWS. Całe zarządzanie jest wykonywane przez pełnoetatowych pracowników Keeper Security, którzy są obywatelami USA i znajdują się w Stanach Zjednoczonych.

Zweryfikowany moduł szyfrowania FIPS 140-3

Keeper wykorzystuje moduły szyfrowania z certyfikatem FIPS 140-3, aby spełnić rygorystyczne wymogi bezpieczeństwa sektora rządowego i publicznego. Szyfrowanie Keeper zostało certyfikowane przez NIST Cryptographic Module Validation Program (CMVP) i zweryfikowane zgodnie ze standardem FIPS 140 przez akredytowane laboratoria zewnętrzne.

Keeper uses FIPS 140-3 validated encryption that has been issued certificate #4743 under the NIST CMVP.

Zgodność z ITAR

Keeper Security Government Cloud (KSGC) zapewnia zgodność z amerykańskimi przepisami dotyczącymi międzynarodowego obrotu bronią (ITAR). Firmy podlegające przepisom eksportowym ITAR muszą kontrolować niezamierzony eksport, ograniczając dostęp do chronionych danych do obywateli USA i ograniczając fizyczną lokalizację chronionych danych do USA.

Środowisko KSGC FedRAMP na poziomie umiarkowanym spełnia wymagania ITAR dzięki następującym działaniom:

• W pełni zgodny z przepisami magazyn danych jest hostowane w chmurze AWS GovCloud i ograniczony do Stanów Zjednoczonych.
• KSGC zapewnia bezpieczne szyfrowanie danych podczas przesyłania i przechowywania.
• Zabezpieczenia typu zero-knowledge i zero-trust w połączeniu ze szczegółowymi uprawnieniami pozwalają organizacjom zapewnić, że tylko zatwierdzony personel może uzyskać dostęp do wrażliwych danych.
• Niezawodne funkcje raportowania zgodności zapewniają identyfikowalną, elektroniczną ścieżkę audytu wszystkich wykonanych działań i wprowadzonych danych.
• Wyznaczony zespół ds. obsługi klienta składa się z obywateli USA specjalnie przeszkolonych w zakresie bezpiecznej obsługi danych objętych kontrolą eksportu i ITAR, bez wsparcia spoza USA.

Środowisko FedRAMP firmy Keeper zostało poddane audytowi przez niezależną zewnętrzną organizację oceniającą (3PAO) w celu potwierdzenia, że istnieją odpowiednie mechanizmy kontrolne wspierające programy zgodności z przepisami eksportowymi klientów, i będzie nadal poddawane corocznym audytom w celu utrzymania zgodności.

Więcej informacji na temat ITAR.

Autoryzacja FedRAMP

KSGC to platforma Keeper Security do zarządzania hasłami i cyberbezpieczeństwa dla organizacji sektora publicznego. KSGC jest autoryzowanym dostawcą FedRAMP na poziomie umiarkowanego wpływu, hostowanym w chmurze AWS GovCloud (USA). KSGC można znaleźć w wykazie FedRAMP Marketplace.

Federal Risk and Authorization Management Program (FedRAMP) to program rządu federalnego USA, który zapewnia znormalizowane podejście do oceny bezpieczeństwa, autoryzacji i ciągłego monitorowania produktów i usług w chmurze. FedRAMP ma na celu przyspieszenie wdrażania nowoczesnych rozwiązań opartych na chmurze przez agencje rządowe, z naciskiem na bezpieczeństwo i ochronę informacji federalnych. Dowiedz się więcej o FedRAMP.

Autoryzacja StateRAMP

Program StateRAMP został opracowany około dziesięć lat po programie FedRAMP w celu zachęcenia do wdrażania bezpiecznych rozwiązań opartych na chmurze na poziomie władz stanowych i lokalnych. Uzyskanie autoryzacji StateRAMP to zwykle dwuletni proces, który został usprawniony dzięki programowi wzajemności dzięki autoryzacji FedRAMP firmy Keeper.

Zgodność z SOC 2

Wpisy w sejfach klientów są chronione przy użyciu rygorystycznych i ściśle monitorowanych praktyk kontroli wewnętrznej. Keeper od ponad dziesięciu lat posiada zgodność z SOC 2 Type 2 zgodnie z wytycznymi Service Organization Control instytutu AICPA. Zgodność z SOC 2 pomaga zapewnić bezpieczeństwo sejfów użytkowników poprzez wdrożenie standardowych mechanizmów kontroli określonych w zasadach Trust Service Principles stworzonych przez instytut AICPA.

Certyfikaty ISO

Keeper posiada certyfikaty ISO ISO 27001, 27017 i 27018 obejmujące system zarządzania informacjami Keeper Security i infrastrukturę chmury, która obsługuje platformę Keeper Enterprise. Certyfikaty ISO firmy Keeper obejmują zarządzanie i obsługę sejfu cyfrowego i usług w chmurze, kontrolę bezpieczeństwa w chmurze, kontrolę prywatności danych, rozwój oprogramowania i aplikacji oraz ochronę zasobów cyfrowych dla sejfu cyfrowego i usług w chmurze.

Zgodność z przepisami FDA 21 CFR część 11

Keeper jest zgodny z przepisami 21 CFR część 11, które dotyczą naukowców pracujących w środowiskach podlegających ścisłym regulacjom, w tym badaczy prowadzących badania kliniczne. Rozporządzenie to określa kryteria FDA, zgodnie z którymi zapisy i podpisy elektroniczne są uznawane za godne zaufania, wiarygodne i równoważne zapisom papierowym z podpisami odręcznymi. W szczególności naukowcy muszą zapewnić, że całe oprogramowanie, którego używają, jest zgodne z przepisami 21 CFR część 11 w następującym zakresie:

Kontrole bezpieczeństwa w zakresie identyfikacji użytkowników – Keeper spełnia wymagania przepisów 21 CFR część 11 w zakresie zabezpieczeń ograniczających dostęp użytkowników i ich uprawnienia, w tym zapewnienia, że wszyscy użytkownicy posiadają unikatowe nazwy użytkownika i hasła, możliwości wykrywania i zapobiegania nieautoryzowanemu dostępowi do systemu oraz możliwości blokowania zagrożonych kont.

Szczegółowa ścieżka audytu

Podczas inspekcji FDA organy regulacyjne wymagają od badaczy przedstawienia ścieżki audytu zawierającej chronologiczny zapis wszystkich operacji. Funkcje raportowania zgodności Keeper umożliwiają badaczom łatwe tworzenie identyfikowalnych elektronicznych ścieżek audytu.

Podpisy elektroniczne

Kiedy dokument wymaga prawnie wiążącego podpisu elektronicznego, przepisy 21 CFR część 11 wymagają, aby podpis był dołączony do unikatowego loginu i hasła lub identyfikacji biometrycznej. Keeper obsługuje to wymaganie, umożliwiając badaczom zapewnienie, że wszyscy użytkownicy posiadają unikatowe nazwy użytkowników i hasła, bezpiecznie przechowywane w cyfrowym sejfie, do którego dostęp ma tylko użytkownik.

Więcej informacji na temat przepisów 21 CFR Part 11 można znaleźć tutaj.

Ochrona danych medycznych pacjentów

Oprogramowanie Keeper jest zgodne ze światowymi standardami ochrony danych medycznych, w tym m.in. ustawy HIPAA (Health Insurance Portability and Accountability Act) oraz DPA (Data Protection Act).

Zgodność z ustawą HIPAA i umowami partnerstwa biznesowego (BAA)

Keeper to platforma bezpieczeństwa zero-knowledge z certyfikatami SOC2 i ISO 27001, która jest zgodna z HIPAA. Przestrzegane są ścisłe zasady w zakresie prywatności, poufności, integralności i dostępności i prowadzone są kontrole w tym zakresie. Dzięki takiej architekturze bezpieczeństwa Keeper nie ma możliwości odszyfrowania, ani uzyskania podglądu i dostępu do informacji, w tym do poufnej dokumentacji medycznej przechowywanej w sejfie Keeper użytkownika. Keeper nie jest partnerem biznesowym według definicji przedstawionej w ustawie HIPAA, dlatego też nie podlega umowie partnerstwa biznesowego (BAA).

by dowiedzieć się więcej na temat dodatkowych korzyści dla podmioty świadczących opiekę zdrowotną i ubezpieczycieli w zakresie ochrony zdrowia, przeczytaj cały dokument: Informacje dot. bezpieczeństwa i zapoznaj się z naszym Przewodnikiem dla przedsiębiorstw.

Certyfikat FSQS-NL

Keeper Security EMEA Limited posiada certyfikat Hellios Financial Services Qualification System-Netherlands (FSQS-NL), który uznaje najwyższe standardy w zakresie bezpieczeństwa, jakości i innowacji w Holandii. Standard ten wykazuje zgodność z Financial Conduct Authority i Prudential Regulation Authority, aby zapewnić wiarygodność oprogramowania Keeper Enterprise dla dużych banków i instytucji finansowych.

Produkt eksportowy licencjonowany przez ministerstwo handlu Stanów Zjednoczonych (U.S. Department of Commerce) zgodnie z rozporządzeniem EAR

Keeper jest certyfikowany przez Biuro Przemysłu i Bezpieczeństwa Departamentu Handlu Stanów Zjednoczonych pod numerem kontrolnym klasyfikacji towarów eksportowych 5D992, zgodnie z przepisami eksportowymi (Export Administration Regulations, EAR).
Aby uzyskać więcej informacji na temat przepisów EAR: https://www.bis.doc.gov

Całodobowe zdalne monitorowanie we wszystkie dni tygodnia

Keeper jest zdalnie monitorowany 24 godziny na dobę, 7 dni w tygodniu przez niezależną sieć monitorującą o światowym zasięgu, aby zapewnić dostęp do naszej strony oraz usługi Cloud Security Vault na całym świecie.

Jeżeli masz pytania pytania związane z tymi informacjami dotyczącymi bezpieczeństwa, skontaktuj się z nami.

Wyłudzające informacje lub sfałszowane adresy e-mail

Jeśli otrzymasz wiadomość e-mail rzekomo wysłaną przez firmę Keeper Security i nie masz pewności, czy jest ona legalna, może to być „wiadomość phishingowa”, w której adres e-mail nadawcy jest sfałszowany lub „podrobiony”. W takim przypadku wiadomość e-mail może zawierać odnośniki do strony, która wygląda jak KeeperSecurity.com, ale nie jest naszą stroną. Strona może prosić Cię o podanie hasła głównego Keeper Security lub próbować zainstalować na Twoim komputerze niechciane oprogramowanie w celu kradzieży Twoich danych osobowych lub uzyskania dostępu do Twojego komputera. Inne wiadomości e-mail zawierają odnośniki, które mogą przekierować Cię na inne potencjalnie niebezpieczne strony internetowe. Wiadomość może również zawierać załączniki, które zazwyczaj zawierają niechciane oprogramowanie zwane „złośliwym oprogramowaniem”. Jeśli nie masz pewności co do wiadomości e-mail otrzymanej w skrzynce odbiorczej, usuń ją bez klikania jakichkolwiek odnośników lub otwierania załączników

Jeśli chcesz zgłosić wiadomość e-mail rzekomo pochodzącą od Keeper, która Twoim zdaniem jest fałszywa, lub masz inne obawy dotyczące bezpieczeństwa związane z innymi sprawami, skontaktuj się z nami.

Infrastruktura hostingowa z certyfikatem najbardziej rygorystycznych standardów branżowych

Strona Keeper oraz chmura danych działają w oparciu o bezpieczną infrastrukturę chmurową Amazon Web Services (AWS). Infrastruktura chmury AWS, na której znajduje się architektura systemu Keeper, posiada udokumentowaną zgodność z raportami, orzeczeniami i certyfikatami następujących stron trzecich:

Program zgłaszania błędów i luk w zabezpieczeniach

Celem firmy Keeper Security jest opracowanie najbezpieczniejszego na rynku rozwiązania do zarządzania hasłami i dostępem uprzywilejowanym. Zależy nam na ochronie prywatności i danych osobowych naszych klientów. Misją firmy Keeper jest stworzenie najbezpieczniejszej i najbardziej innowacyjnej platformy bezpieczeństwa na świecie i uważamy, że zgłaszanie błędów przez światową społeczność badaczy bezpieczeństwa ma kluczowe znaczenie dla zapewnienia bezpieczeństwa produktów i usług Keeper.

Keeper przeprowadza szeroko zakrojone testy wewnętrzne i zewnętrzne, w tym testy penetracyjne wykonywane przez NCC Group i CyberTest z pełnym dostępem do kodu źródłowego. Keeper prowadzi swój program ujawniania luk we współpracy z Bugcrowd. Wszystko to przynosi to korzyści całej branży, a ponadto wspiera dobro społeczne.

Wskazówki

Polityka Keeper w zakresie ujawniania luk w zabezpieczeniach określa nasze oczekiwania podczas pracy z hakerami działającymi w dobrej wierze oraz precyzuje, czego możesz spodziewać się od nas.

Jeśli testy bezpieczeństwa i raportowanie są przeprowadzane zgodnie z wytycznymi niniejszych zasad:

• Uznajemy je za autoryzowane zgodnie z ustawą o oszustwach i nadużyciach komputerowych (Computer Fraud and Abuse Act).
• Uznajemy je za wyłączone z DMCA i nie pozwiemy Cię za obejście jakichkolwiek kontroli bezpieczeństwa i kontroli technologii.
• Uznajemy je za legalne i nie będziemy wnosić ani wspierać jakichkolwiek spraw sądowych przeciwko Tobie w związku z tym programem.
• Będziemy z Tobą współpracować w celu zrozumienia i szybkiego rozwiązania problemu.
• Twój wkład zostanie podany do wiadomości publicznej, jeśli zgłosisz problem jako pierwsza osoba i na jego podstawie zmienimy kod lub konfigurację.

Jeśli w dowolnym momencie będziesz mieć obawy lub wątpliwości dotyczące testowania w sposób zgodny z wytycznymi i zakresem niniejszych zasad, skontaktuj się z nami pod adresem security@keepersecurity.com przed przejściem dalej.

Aby zachęcać do testowania zabezpieczeń i ujawniania w dobrzej wierze odkrytych luk, oczekujemy, że:

• Unikaj naruszania prywatności użytkowników, szkodzenia ich doświadczeniom, zakłócania produkcji lub systemów korporacyjnych i/lub niszczenia danych.
• Przeprowadzaj badania wyłącznie w zakresie określonym przez program ujawniania luk Bugcrowd, do którego odsyłacz znajduje się poniżej, z wyłączeniem systemów i działań, które nie są przez ten zakres objęte.
• Skontaktuj się z nami natychmiast security@keepersecurity.com, jeśli podczas testowania napotkasz jakiekolwiek dane użytkowników.
• Zapewnij nam rozsądny czas na przeanalizowanie, potwierdzenie i rozwiązanie zgłoszonego problemu przed publicznym ujawnieniem odkrytej luki w zabezpieczeniach.

Prosimy o przesyłanie raportów za pośrednictwem strony: https://bugcrowd.com/keepersecurity

Widoczność

Keeper jest nie tylko zaangażowany w kwestie bezpieczeństwa, jest wręcz fanatykiem w tej kwestii. Dlatego udostępniamy publicznie każdy szczegół naszego modelu szyfrowania. Wierzymy, że nasi klienci zasługują na to, by znać każdy krok, jaki podejmujemy w celu zapewnienia bezpieczeństwa ich danych w obliczu stale zmieniającego się krajobrazu cyberbezpieczeństwa.

Model szyfrowania typu zero-trust i zero-knowledge firmy Keeper gwarantuje, że nawet w najgorszym scenariuszu Twój sejf Keeper będzie chroniony, a my nieustannie przeprowadzamy testy bezpieczeństwa, aby mieć pewność, że pozostajemy najlepszym rozwiązaniem do ochrony Twoich najcenniejszych danych.

Dokumentacja produktu

Portal z dokumentacją Keeper, zawierający instrukcje obsługi produktu, informacje techniczne, informacje o wersji i przewodniki dla użytkownika, jest dostępny pod tym adresem.

Informacje o wersji produktu

Aby zwiększyć przejrzystość, Keeper publikuje szczegółowe informacje o wydaniu dla każdej platformy.

Stan systemu

Status systemów można sprawdzić w czasie rzeczywistym tutaj.