Keeper ma obsesję na punkcie ochrony danych i bezpieczeństwa menedżera haseł

Omówienie

Firma Keeper Security , Inc. (KSI) 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 z rodziny 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 na poniższe odnośniki:

Privacy Policy Warunki użytkowania

Ochrona danych

„Zero-trust” rozpoczyna się od zabezpieczenia haseł. KSI tworzy swoje produkty przy wykorzystaniu struktury zabezpieczeń „zero-trust”, która zakłada brak zaufania do wszystkich użytkowników w ramach architektury. „Zero-trust” czyli całkowity brak zaufania zakłada, że wszyscy użytkownicy i wszystkie urządzenia mogą być potencjalnie naruszone i w związku z tym należy zweryfikować każdego użytkownika i każde urządzenie przed udzieleniem dostępu do aplikacji lub systemu. Ta struktura cyber-zabezpieczeń tworzy podstawę platformy Keeper, która zapewnia administratorom IT pełny podgląd wszystkich użytkowników, systemów i urządzeń, do których uzyskują dostęp. Ułatwia to zapewnienie zgodności z wymogami branżowymi i regulacyjnymi. Aby zapewnić strukturę „zero-trust” w organizacji, niezbędne jest wdrożenie w organizacji zabezpieczeń haseł na światowym poziomie, wspieranych przez architekturę bezpieczeństwa „zero-knowledge”.

Architektura typu zero-trust

Kliknij ikonę i, aby dowiedzieć się więcej.

Użytkownicy końcowi

Użytkownicy Keeper na dowolnym urządzeniu klienta, w tym komputerach stacjonarnych, urządzeniach mobilnych, w przeglądarkach i wierszu poleceń.

Dostawca tożsamości

IdP to usługa do przechowywania tożsamości użytkowników i zarządzania nimi.

Aplikacje SAML

Umożliwia rozszerzenie SSO na domenach zabezpieczeń, umożliwiając logowania SSO z poziomu przeglądarki.

SecOps, DevOps oraz IT

Użytkownicy uprzywilejowani z dostępem do wysoce poufnych kont, loginów i danych.

Keeper Admin Console

Skorzystaj z tej platformy, aby skonfigurować i wprowadzić polityki biznesowe dla użytkowników końcowych.

Keeper Connection Manager (KCM)

Zezwól sieciom typu zero-trust na dostęp do Twojej infrastruktury bez VPN.

Keeper Secrets Manager (KSM)

Zabezpiecza wpisy tajne infrastruktury takie jak klucze API, hasła do baz danych, klucze dostępu, certyfikaty i wszelkiego rodzaju poufne dane.

Menedżer haseł Keeper Enterprise (EPM)

Zabezpiecza Twoje hasła i prywatne informacje przed cyber-przestępcami.

Urządzenia, przeglądarki i sprzęt klienta

Urządzenia końcowe uzyskujące dostęp do bezpiecznego sejfu na hasła.

Windows, Linux, MySQL, SQL Server, PostgreSQL

Różne punkty końcowe, do których użytkownicy końcowi najczęściej uzyskują dostęp.

Jenkins, GitHub, Terraform, PowerShell

Narzędzia DevOps i deweloperskie, które automatyzują proces tworzenia i rozwoju aplikacji.

Aplikacje oparte na hasłach

Strony internetowe, aplikacje i systemu, które wymagają logowania.

Obejrzyj nagranie o architekturze typu zero trust

Firma KSI nie ma dostępu do hasła głównego użytkownika ani też nie posiada dostępu do wpisów przechowywanych w sejfie aplikacji Keeper. Firma KSI nie może uzyskać zdalnego dostępu do urządzenia użytkownika ani też odszyfrować jego danych. Jedyne informacje, do których firma KSI posiada dostęp, to adres e-mail użytkownika, rodzaj urządzenia oraz szczegóły abonamentu (np. abonament Keeper Unlimited). W przypadku utraty bądź kradzieży urządzenia użytkownika, firma KSI może pomóc mu uzyskać dostęp do zaszyfrowanego pliku kopii zapasowej, dzięki któremu użytkownik będzie mógł odtworzyć swoje dane na nowym urządzeniu.

Informacje przechowywane i używane w aplikacji Keeper są dostępne wyłącznie użytkownikowi ze względu na to, że są natychmiastowo szyfrowane i odszyfrowywane na urządzeniu użytkownika – nawet w przypadku korzystania z aplikacji internetowej Keeper (Web App). Metoda szyfrowania, wykorzystana w aplikacji Keeper, to znany i godny zaufania algorytm AES (Advanced Encryption Standard) z 256-bitowym kluczem. AES z 256-bitowym kluczem to algorytm szyfrujący o standardzie wojskowym, który jest obecnie wykorzystywany przez rząd Stanów Zjednoczonych do szyfrowania wysoce poufnych danych. Zgodnie z broszurą CNSSP-15, wydaną przez Komisję ds. Systemów bezpieczeństwa narodowego, algorytm AES 256-bit jest dostatecznie bezpieczny, aby szyfrować za jego pomocą dane aż do ŚCIŚLE TAJNEGO poziomu poufności danych wg klasyfikacji rządu Stanów Zjednoczonych. Keeper jest weryfikowany i certyfikowany pod kątem FIPS 140-2 przez NIST CMVP (Certyfikat #3976 - https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3976)

Klucze szyfrujące wykorzystywane do szyfrowania i odszyfrowywania wpisów użytkownika nie są przechowywane ani przesyłane do chmury aplikacji Keeper (Cloud Security Vault). Jednakże aby umożliwić synchronizację danych pomiędzy licznymi urządzeniami, przechowujemy w chmurze Cloud Security Vault zaszyfrowaną wersję klucza, która jest potem udostępniania urządzeniom przypisanym do konta użytkownika. Ten zaszyfrowany klucz można odszyfrować wyłącznie na urządzeniu w celu wykorzystania go jako klucza szyfrującego dane.

Silne hasło główne

Zalecamy używanie silnego hasła głównego do konta w aplikacji Keeper. Hasło główne aplikacji Keeper nie powinno być używane gdziekolwiek indziej. Użytkownicy nie powinni nikomu udostępniać swojego hasła głównego.

Uwierzytelnianie dwuskładnikowe

Aby zapewnić Ci ochronę przed nieuprawnionym dostępem do Twojego sejfu, stron internetowych i aplikacji, Keeper oferuje także opcję uwierzytelniania dwuskładnikowego. Uwierzytelnianie dwuskładnikowe to rozwiązanie, które korzysta z dwóch lub więcej z trzech czynników uwierzytelniających: wiedzy, posiadania oraz nierozłączności. Aby uzyskać więcej informacji na temat uwierzytelniania dwuskładnikowego, kliknij to łącze.

Aplikacja Keeper wykorzystuje coś, co wiesz (Twoje hasło) oraz coś, co posiadasz (Twój telefon), aby zapewnić użytkownikom dodatkowe zabezpieczenie w przypadku utraty bądź przechwycenia przez osobę niepowołaną hasła głównego albo urządzenia. W tym celu generujemy tak zwane TOTP (Time-based One-Time Passwords - Tymczasowe Hasła Jednokrotnego Użycia)

Aplikacja Keeper generuje 10-bitowy, tajny klucz przy pomocy kryptograficznie bezpiecznego generatora liczb losowych. Kod ten jest ważny przez około minutę, a użytkownik otrzymuje go za pomocą SMSa, RSA SecurID, aplikacji TOTP albo Google Authenticator lub urządzeń osobistych kompatybilnych z Keeper DNA takich jak Apple Watch lub Android Wear.

Kiedy korzystasz z aplikacji Google Authenticator lub TOTP na swoim urządzeniu, na serwerze Keeper generowany jest kod QR zawierający Twój tajny klucz. Kod ten nie jest przekazywany żadnej niepowołanej osobie. Przy każdym włączeniu lub wyłączeniu opcji uwierzytelniania dwuskładnikowego generowany jest nowy, tajny klucz

Aby włączyć uwierzytelnianie dwuskładnikowe, przejdź do Keeper DNA lub do ekranu Ustawienia w aplikacji internetowej Keeper. Klienci Keeper Business mogą opcjonalnie włączyć opcję uwierzytelniania dwuskładnikowego podczas logowania do sejfu oraz obsługiwane metody 2FA w sekcji wprowadzania zasad w konsoli administratora Keeper.

Klucze bezpieczeństwa FIDO WebAuthn

Keeper obsługuje sprzętowe klucze bezpieczeństwa WebAuthn do uwierzytelniania dwuskładnikowego kompatybilne z FIDO, takie jak YubiKey, spełniające rolę drugiej formy uwierzytelnienia. Klucze bezpieczeństwa zapewniają wygodny i bezpieczny sposób przeprowadzania uwierzytelniania dwuskładnikowego bez konieczności ręcznego wprowadzania przez użytkownika 6-cyfrowych kodów. Dla sejfu jednego użytkownika można skonfigurować kilka kluczy bezpieczeństwa. W przypadku platform, które nie obsługują kluczy bezpieczeństwa, użytkownicy mogą stosować inne metody uwierzytelniania dwuskładnikowego. Aby skonfigurować klucz bezpieczeństwa lub inne metody uwierzytelniania dwuskładnikowego, odwiedź sekcję „Ustawienia” w aplikacji Keeper.

Dostęp alarmowy (cyfrowe dziedzictwo)

Aplikacji Keeper daje możliwość dodania do 5 kontaktów alarmowych, które uzyskają dostęp do sejfu użytkownika na wypadek nadzwyczajnych okoliczności lub śmierci. Po upływie określonego czasu zwłoki kontakt alarmowy uzyska dostęp do sejfu użytkownika. Proces udostępniania sejfu odbywa się przy wykorzystaniu technologii „zero-knowledge”, a hasło główne użytkownika nigdy nie jest udostępniane kontaktowi alarmowemu. Po upływie czasu zwłoki określonego przez właściciela sejfu kontaktowi alarmowemu udostępniany jest 256-bitowy klucz AES. Stosuje się do tego szyfrowanie RSA. Z tego powodu, w celu zaakceptowania zaproszenia, kontakt alarmowy musi posiadać konto Keeper (oraz parę kluczy RSA: prywatny i publiczny).

Odzyskiwanie konta

Podczas rejestracji konta użytkownicy mogą zostać poproszeni o wybranie niestandardowego pytania i odpowiedzi zabezpieczających lub innego rodzaju metody odzyskiwania danych. Również podczas rejestracji Keeper generuje 256-bitowy klucz danych AES, który jest używany do szyfrowania i odszyfrowywania kluczy wpisów przechowywanych w każdym z wpisów sejfu. Klucz danych użytkownika jest szyfrowany kluczem uzyskanym z hasła głównego przy użyciu metody PBKDF2 z maksymalnie 1 000 000 iteracji, a każdy klucz wpisu AES-256 jest szyfrowany kluczem danych AES-256. Każdy wpis w sejfie użytkownika ma indywidualne, odrębne klucze wpisu wygenerowane po stronie klienta.

Sposób, w jaki działa odzyskiwanie konta (przy użyciu pytania zabezpieczającego), polega na zapisaniu drugiej kopii danych użytkownika, która jest zaszyfrowana kluczem pochodzącym z wybranej odpowiedzi zabezpieczającej z maksymalnie 1 000 000 iteracji. Aby zakończyć odzyskiwanie sejfu, użytkownik musi wprowadzić kod weryfikacyjny z wiadomości e-mail, a także kod uwierzytelniania dwuskładnikowego (jeśli jest włączone na koncie). Zalecamy utworzenie silnego pytania i odpowiedzi zabezpieczających, a także włączenie funkcji dwuskładnikowego uwierzytelniania Keeper na ekranie „Ustawienia”. Odzyskiwanie konta może zostać wyłączone w oparciu o konfigurację konta Keeper Enterprise. Uwierzytelnianie dwuskładnikowe może być również wymuszone dla klientów Keeper Enterprise z poziomu Konsoli administratora Keeper.

Klienci Business i Enterprise mają dostęp do metody odzyskiwania kont użytkowników typu „zero-knowledge” przy użyciu zasad przenoszenia kont Keeper.

Szyfrowanie na urządzeniu

Dane są szyfrowane i odszyfrowywane na urządzeniu użytkownika, nie zaś w chmurze Cloud Security Vault. Nazywamy to „szyfrowaniem na urządzeniu klienta”, ponieważ urządzenie-klient (np. iPhone, urządzenie z systemem Android, aplikacja internetowa itd.) przeprowadza cały proces szyfrowania. W chmurze Cloud Security Vault jest przechowywany wyłącznie nieprzetworzony plik binarny, który jest w zasadzie bezużyteczny dla potencjalnych intruzów. Nawet jeżeli dane zostaną przechwycone podczas przesyłania ich między klientem a chmurą, nie można ich odszyfrować ani wykorzystać do ataku lub naruszenia prywatnych danych użytkownika.

Złamanie lub zhackowanie symetrycznego, 256-bitowego klucza wymagałoby 2¹²⁸ razy większej mocy obliczeniowej niż złamanie klucza 128-bitowego. W teorii wymagałoby to wykorzystania urządzenia do złamania klucza przez 3x1051 lat, aby wyczerpać możliwe konfiguracje klucza 256-bitowego.

Udostępnianie

Każdy użytkownik posiada parę 256-bitowych kluczy Elliptic Curve (ECC secp256r1), wykorzystywanych przy udostępnianiu innych kluczy (np. kluczy wpisów, folderów i zespołów) między użytkownikami. Udostępniane informacje są szyfrowane za pomocą klucza publicznego odbiorcy. Odbiorca odszyfrowuje dane swoim prywatnym kluczem. Pozwala to na udostępnianie wpisów wyłącznie wybranemu odbiorcy, ponieważ tylko on będzie mógł je odszyfrować. Aby zapewnić kompatybilność z wcześniejszymi wpisami, możliwe jest użycie także 2048-bitowego klucza RSA.

Generowanie klucza

Domyślną metodą uwierzytelniania w aplikacji Keeper jest użycie wybranego przez użytkownika hasła głównego. Algorytm PBKDF2 służy do uzyskania klucza z hasła głównego, który odszyfrowuje inne klucze użytkownika, takie jak 256-bitowy klucz danych AES. Drugi klucz PBKDF2 jest generowany lokalnie, a następnie haszowany za pomocą metody HMAC_SHA256, aby uzyskać token uwierzytelniający. Możliwość uwierzytelniania za pomocą hasła głównego jest ograniczona, dopóki urządzenie użytkownika nie przejdzie weryfikacji, a uwierzytelnianie dwuskładnikowe nie zostanie zweryfikowane. Liczba iteracji PBKDF2 domyślnie wynosi 1 000 000 rund. Administratorzy Keeper mogą również wymusić poziomy iteracji PBKDF2 w Konsoli administratora Keeper.

Przechowywanie klucza

Wszystkie tajne klucze, takie jak klucz prywatny krzywej eliptycznej, klucz prywatny RSA i klucz danych AES-256 każdego użytkownika, są szyfrowane przed przechowaniem lub przesłaniem. W przypadku konsumentów i użytkowników biznesowych, którzy logują się za pomocą hasła głównego, klucz jest wyprowadzany z hasła głównego w celu odszyfrowania wszelkich przechowywanych kluczy. W przypadku klientów korporacyjnych, którzy logują się za pomocą dostawcy tożsamości SSO, zaszyfrowane klucze są dostarczane do urządzenia po udanym uwierzytelnieniu, a klucze prywatne użytkownika są używane do odszyfrowania klucza danych i innych kluczy sejfu. Ponieważ Keeper Cloud Security Vault nie ma dostępu do hasła głównego użytkownika ani kluczy szyfrowania, nie możemy odszyfrować żadnych przechowywanych kluczy ani danych.

Bezpieczny sejf w chmurze Keeper

Określenie „Cloud Security Vault” odnosi się do własnej architektury oprogramowania i sieci firmy KSI, która jest fizycznie hostowana przez infrastrukturę Amazon Web Services (AWS).

Kiedy użytkownik synchronizuje swój sejf aplikacji Keeper z innymi urządzeniami na swoim koncie, zaszyfrowane dane binarne są przesyłane przez zaszyfrowany tunel SSL i zapisywane w chmurze Cloud Security Vault aplikacji Keeper w zaszyfrowanym formacie.

Przechowywanie wersji wpisów

W aplikacji Keeper przechowywana jest pełna zaszyfrowana wersja historii każdego wpisu z sejfu użytkownika, co daje pewność, że nie stracisz nigdy żadnych istotnych danych. W aplikacji Keeper klienci mają dostęp do historii wpisu i mogą przywrócić dowolny wpis zapisany w sejfie. Jeśli zmieniono lub usunięto przechowywane hasło lub plik, można również skorzystać z przywracania do punktu w czasie.

Keeper Business

Klienci, którzy zakupili Keeper Business, mają zapewniony dodatkowy poziom kontroli nad użytkownikami i urządzeniami. Administratorzy Keeper uzyskują dostęp do konsoli administracyjnej w chmurze, dzięki której mają pełną kontrolę nad wdrażaniem i usuwaniem użytkowników, uprawnieniami opartymi na rolach, administracją delegowaną, zespołami, integracją z usługami Active Directory/LDAP, uwierzytelnianiem dwuskładnikowym, pojedynczym logowaniem i zasadami egzekwowania zabezpieczeń. Oparte na rolach zasady egzekwowania Keeper są w pełni konfigurowalne i skalowalne, więc można je dostosować do organizacji o dowolnej wielkości.

Szyfrowanie na poziomie wpisu

Keeper wprowadza system wielopoziomowego szyfrowania oparty na kluczach generowanych po stronie klienta. Klucze na poziomie wpisów i folderów są generowane na lokalnym urządzeniu, które szyfruje każdy wpis przechowywany w sejfie (np. hasło). Jeśli masz w swoim sejfie 10 000 wpisów, masz również 10 000 kluczy spisów AES zabezpieczających dane.

Klucze są generowane lokalnie na urządzeniu, aby zachować architekturę zero-knowledge i umożliwić obsługę zaawansowanych funkcji, takich jak udostępnianie wpisów i folderów. Klucze wpisów i folderów są zabezpieczane przez inne klucze, np. klucze danych i klucze klienta.

Role, zespoły, foldery udostępnione i delegowany administrator

Keeper for Business zapewnia zestaw bezpiecznych i niezawodnych narzędzi do zarządzania komórkami danej organizacji, rolami, zespołami i folderami udostępnionymi. Zaawansowane wewnętrzne narzędzia kontrolne aplikacji Keeper zapewniają niezawodny poziom kontroli gwarantujący pełną możliwość przydzielania minimalnego dostępu oraz delegowania pełnej roli administratora.

Dla ról, które wymagają przeniesienia konta użytkownika:

Klucz wymuszania jest szyfrowany z kluczem każdego administratora, posiadającego uprawnienia przenoszenia kont.

(Uwaga: oddzielne wymuszenia stosowane w przypadku poszczególnych grup użytkowników mogą być desygnowane do przeniesienia przez oddzielne grupy administratorów.)

Klucze folderu konta są generowane (dla użytkowników, którym przypisana została rola podlegająca wymuszeniu) i szyfrowane przy pomocy klucza wymuszenia. Wszystkie wpisy i foldery udostępnione danego użytkownika mają przypisane swoje klucze szyfrowane z kluczem folderu konta.

Przenoszenie konta wygląda następująco: dane konto zostaje zamknięte, przeniesione, a następnie usuwa się pierwotne konto użytkownika. Dzięki temu operacja ta nie odbywa się bez wiedzy użytkowników. Klucze folderu konta i metadane zapewniają możliwość ewentualnego odszyfrowania wpisów, ale nie zezwalają na bezpośredni dostęp do nich. Dlatego użytkownik, któremu zostały przydzielone wpisy, może z nich korzystać dopiero po ich przydzieleniu. Żadna inna osoba nie ma dostępu do takich wpisów.

Cały proces szyfrowania odbywa się po stronie klienta i na poziomie aplikacji Keeper nie ma możliwości odszyfrowania udostępnianych lub przesyłanych informacji. Dodatkowo, nie udostępnia się kluczy użytkowników. Użytkownik usunięty z zespołu, folderu udostępnianego lub bezpośredniego udostępnienia nie będzie otrzymywał nowych danych i wpisów z zespołu, ani za pośrednictwem folderów udostępnianych. Z tego powodu, nawet jeśli klucz danego użytkownika zostanie naruszony, ten klucz nie jest używany do przydzielania dostępu do danych.

Poszczególnym elementom drzewa hierarchii można przydzielić kilka różnych pozwoleń administracyjnych, dzięki którym członkowie posiadający takie uprawnienia mogą przeprowadzać różne działania za pośrednictwem Kontroli administratora Keeper.

W odniesieniu do ról określających zachowanie klienta wobec grup użytkowników można stosować zarówno politykę wymuszeń po stronie klienta lub po stronie kilku stron.

Zespoły umożliwiają łatwe przydzielanie folderów udostępnionych grupom użytkowników.

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 mostkiem. 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 pozwoleń.

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 w formie pojedynczego logowania (SAML 2.0)

Klienci Keeper dla firm mogą skonfigurować aplikację Keeper tak, by uwierzytelnianie użytkownika podczas logowania do sejfu Keeper odbywało się przy użyciu standardowych produktów SAML 2.0. Keeper to dostawca usług skonfigurowany dla każdego głównego dostawcy tożsamości SSO, m.in. Google Apps, Microsoft Azure, Okta, czy Ping Identity. Mechanizm stosowany przez Keeper w celu zweryfikowania użytkownika podczas logowania do sejfu w środowisku „zero-knowledge” to rozwiązanie, oczekujące na przyznanie ochrony patentowej, zwane Keeper SSO Connect^®. Oprogramowanie Keeper SSO Connect^® instalowane przez administratorów Keeper dla firm w ich własnej infrastrukturze (wewnętrznej lub w chmurze), które pełni funkcję punktu końcowego dla dostawcy usług SAML 2.0. Po aktywacji w określonej jednostce organizacyjnej Keeper SSO Connect^® zarządza wszystkimi kluczami szyfrującymi użytkowników końcowych aplikacji Keeper dla firm. Po skutecznej weryfikacji użytkownika do usług dostawcy tożsamości SSO dla firm następuje zalogowanie tego użytkownika do aplikacji Keeper przy użyciu niezbędnych kluczy szyfrujących służących do odszyfrowania jego sejfu. Oprogramowanie Keeper SSO Connect^® jest odpowiednie dla systemu Windows, Mac i Linux.

SSO Connect^® Cloud

Keeper SSO Connect^® Cloud zapewnia klientom Keeper Enterprise metodę uwierzytelniania użytkowników i możliwość odszyfrowania danych przechowywanych w sejfie i zaszyfrowanych metodą „zero-knowledge" poprzez uwierzytelnianie dokonywane przez zewnętrznego dostawcę tożsamości (IdP), stosującego standardowe protokoły SAML 2.0 w środowisku całkowicie w chmurze.

W przypadku tej implementacji użytkownik może dokonać weryfikacji za pośrednictwem dostawcy tożsamości SSO, a następnie odszyfrować szyfrogram swojego sejfu lokalnie na urządzeniu. Każde urządzenie ma swoją własną parę publicznych/prywatnych kluczy EC (Elliptic Curve) i klucz zaszyfrowanych danych. Aby zalogować się na nowe urządzenie, użytkownik musi użyć istniejących urządzeń i dokonać uwierzytelnienia. Zatwierdzić nowe urządzenie może też administrator posiadający odpowiednie uprawnienia.

Użytkownik może odszyfrować swój sejf przy użyciu zaszyfrowanego klucza przechowywanego w chmurze Keeper. Istota „zero-knowledge" czyli „zerowej wiedzy" pozostaje zachowana, ponieważ chmura Keeper nie jest w stanie odszyfrować Klucza danych użytkownika na jego urządzeniu. Klucz danych (DK) użytkownika może zostać odszyfrowany przy użyciu prywatnego klucza urządzenia (DPRIV), a Klucz zaszyfrowanych danych (EDK) jest przekazywany użytkownikowi tylko po jego zweryfikowaniu przez danego dostawcę tożsamości (np. Okta, Azure, AD FS).

W przypadku użytkowników SSO Connect^® Cloud generowany jest klucz prywatny Elliptic Curve, który jest przechowywany lokalnie na każdym urządzeniu. Dla przeglądarek internetowych opartych na Chromium prywatny klucz EC lokalnego urządzenie jest przechowywany w sejfie Keeper jako niemożliwy do wyeksportowania KryptoKlucz. Na urządzeniach Mac i iOS klucz jest przechowywany w pęku kluczy urządzenia. Gdy jest to możliwe, Keeper używa mechanizmów bezpiecznego przechowywania.

Prywatny klucz urządzenia nie jest bezpośrednio używany do szyfrowania i odszyfrowywania danych z sejfu. Po skutecznym uwierzytelnieniu przeprowadzonym przez dostawcę tożsamości, oddzielny klucz (który nie jest przechowywany) stosuje się do odszyfrowania danych w sejfie. Wyodrębnienie lokalnego Prywatnego klucza urządzenia przeprowadzane off-line nie jest w stanie odszyfrować sejfu użytkownika.

Różne urządzenia/platformy mają różne poziomy zabezpieczeń, więc w celu zapewnienia optymalnego bezpieczeństwa, zalecamy stosowanie zaktualizowanej przeglądarki opartej na Chromium.

W ramach ogólnych zabezpieczeń przed atakami zalecamy również, by wszystkie urządzenia (takie jak komputery stacjonarne) były chronione przez szyfrowanie na poziomie dysku i zaktualizowane programy przeciw szkodliwemu oprogramowaniu.

Zatwierdzanie urządzenia SSO

Aby zalogować się na nowe urządzenie, użytkownik musi użyć istniejących urządzeń i dokonać uwierzytelnienia. Zatwierdzić nowe urządzenie może też administrator posiadający odpowiednie uprawnienia. Nowe urządzenia generują nowy zestaw publicznych/prywatnych kluczy, a zatwierdzające urządzenie szyfruje klucz danych użytkownika przy użyciu klucza publicznego nowego urządzenia. Klucz zaszyfrowanych danych (EDK) nowego urządzenia jest przekazywany użytkownikowi/urządzeniu żądającemu i użytkownik może odszyfrować swój klucz danych, który następnie odszyfrowuje dane w sejfie użytkownika. W ramach szyfrowania danych w sejfie użytkownik może zaszyfrować również swoje inne klucze szyfrujące, takie jak klucze wpisów, folderów, zespołów itp.

Użytkownik może odszyfrować swój sejf przy użyciu zaszyfrowanego klucza przechowywanego w chmurze Keeper, a do zarządzania kluczami szyfrującymi nie jest wymagana żadna aplikacja stacjonarna czy też hostowana przez użytkownika. Istota „zero-knowledge" czyli „zerowej wiedzy" pozostaje zachowana, ponieważ chmura Keeper nie jest w stanie odszyfrować Klucza danych użytkownika na jego urządzeniu. Klucz danych użytkownika może zostać odszyfrowany przy użyciu prywatnego klucza urządzenia (DPRIV), a Klucz EDK jest przekazywany użytkownikowi tylko po jego zweryfikowaniu przez danego dostawcę tożsamości (np. Okta, Azure, AD FS).

Korzyści z punktu widzenia administratora to: łatwa konfiguracja i brak konieczności stosowania hostowanego oprogramowania do zarządzania kluczami szyfrującymi, zgodnie z opisem w obecnym modelu szyfrowania SSO Connect^® Keeper.
Jedyną zmianą w przepływie pracy w przypadku tego modelu (w porównaniu ze stacjonarnym wdrażaniem Keeper SSO Connect^®) jest konieczność zatwierdzenia nowych urządzeń przez użytkownika na już aktywnym urządzeniu lub oddelegowania tego zadania administratorowi.

Keeper SSO Connect^® - stacjonarny

Usługa SSO Connect^® On-Prem (stacjanarna) to integracja obsługiwana samodzielnie, która wymaga serwera aplikacji hostowanego w systemie Windows lub Linux. Aby zachować bezpieczeństwo architektury „zero knowledge” oraz zapewnić użytkownikom bezproblemowe korzystanie z funkcji pojedynczego logowania SSO, konieczne jest zainstalowanie Keeper SSO Connect^® na serwerze klienta. Środowiska Windows, Mac i Linux z trybami operacyjnymi równoważenia obciążenia wysokiej niezawodności (HA) są w pełni obsługiwane.

Keeper SSO Connect^® automatycznie generuje i przechowuje hasło główne dla każdego zautoryzowanego użytkownika. Jest to generowany losowo 256-bitowy klucz. To hasło główne szyfrowane jest przy użyciu klucza SSO. Z kolei klucz SSO jest szyfrowany za pomocą klucza drzewa (Tree Key). Klucz SSO jest przywracany 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, aby umożliwić automatyczne uruchomienie usługi. Komunikacja między SSO Connect^® a chmurą aplikacji Keeper (Cloud Security Vault) jest zabezpieczana za pomocą klucza transmisji.

BreachWatch

BreachWatch nieustannie skanuje wpisy Keeper w poszukiwaniu naruszeń publicznych danych i ostrzega użytkownika bezpośrednio w sejfie. BreachWatch korzysta z architektury „zero-knowledge” opartej na wielopoziomowych technikach ochrony danych naszych klientów. W skrócie:

1. W celu przeprowadzenia porównania haseł z bazą danych skradzionych kont wykorzystywana jest bezpieczna, zaszyfrowana, kryptograficzna funkcja skrótu oraz anonymizacja.
2. Zanim hasła klientów zostaną zestawione z naruszonymi hasłami lub będą przechowywane na serwerach BreachWatch, są one przetwarzane przy użyciu sprzętowego modułu zabezpieczeń (HSM) i nieeksportowalnego tajnego klucza.
3. Klienci Keeper korzystają z BreachWatch przy użyciu identyfikatorów BreachWatch, które nie są powiązane z żadnymi innymi identyfikatorami klientów Keeper.
4. BreachWatch przechowuje nazwy użytkowników i hasła oddzielnie, nadając im różne anonimowe identyfikatory, oddzielając w ten sposób nazwy użytkowników i domeny od haseł.
5. Klienci BreachWatch nie przesyłają informacji o domenie, jedynie pobierają domeny.

Rysunek 1. Przepływ zaszyfrowanych danych klienta w BreachWatch. Na serwerach BreachWatch przechowywane są wyłącznie hasła zabezpieczone przy użyciu HSM i nieeksportowalnego klucza. Wykonując działania na serwerze BreachWatch, klienci BreachWatch stosują anonimowe identyfikatory.

Aby zapewnić bezpieczeństwo, Keeper podzielił BreachWatch na trzy usługi: sprawdzanie domen, nazw użytkowników, haseł oraz par: nazwa użytkownika + hasło. Aplikacje klientów Keeper łączą się z tymi poszczególnymi aplikacjami zaplecza, korzystając z zaszyfrowanego interfejsu API REST.

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 klienta łączą się BreachWatch i pobierają listę zaszyfrowanych nazw użytkowników (lub haseł) oraz losowo wybranych przez klienta identyfikatorów (oddzielnych do sprawdzania nazw użytkowników i haseł). Te skróty haseł procesuje się po ich pobraniu przy użyciu kodu HMAC, korzystając ze sprzętowego modułu bezpieczeństwa (HSM) i nieeksportowalnego tajnego klucza przechowywanego w HSM (co oznacza, że HSM będzie przetwarzać kod HMAC tylko lokalnie, a klucza nie można wyodrębnić). Dane wejściowe HMAC (nazwy użytkowników i hasła) są porównywane z zestawem zagrożonych danych przeprocesowanych przy użyciu tego samego kodu HMAC i klucza. Wszystkie pasujące wartości są przekazywane na urządzenie klienta. Wszystkie niepasujące wartości przechowuje się z anonimowym identyfikatorem klienta.

Po dodaniu do systemu nowego naruszonego hasła i nazwy użytkownika, przetwarza się je przy użyciu kodu HMAC w module HSM, dodanym do zestawu danych BreachWatch, i porównuje z przechowywanymi wartościami klienta. Pasujące wartości generują ostrzeżenie 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 momencie wykrycia naruszenia hasła urządzenie klienta wysyła skrót kombinacji nazwa użytkownika+hasło do serwerów BreachWatch, które następnie wykonują takie samo porównanie skrótów HMAC w celu stwierdzenia, czy kombinacja nazwa użytkownika+hasło została naruszona. Jeśli doszło do naruszenia, zwracane są domeny powiązane z tym naruszeniem, tak aby urządzenie klienta określiło, czy nazwa użytkownika+hasło+domena pasują do siebie. Jeśli wszystkie trzy parametry odpowiadają sobie na urządzeniu klienta, użytkownik otrzymuje ostrzeżenie o naruszeniu i stopniu zagrożenia.

BreachWatch Business

W przypadku aktywowania BreachWatch dla firm i przedsiębiorstw sejfy użytkowników końcowych są skanowane automatycznie za każdym razem, gdy użytkownik loguje się przy użyciu Keeper. Dane podsumowania BreachWatch przeskanowane na urządzeniu użytkownika są szyfrowane przy użyciu publicznego klucza przedsiębiorstwa i odszyfrowane przez administratora w przedsiębiorstwie w momencie logowania do konsoli administratora Keeper. Te zaszyfrowane informacje zawierają: adres e-mail, liczbę wpisów o wysokim ryzyku, liczbę wpisów zignorowanych i zmienionych. Administrator Keeper może zobaczyć statystyki podsumowujące na poziomie użytkownika w obrębie interfejsu użytkownika konsoli administratora.

Logowanie zdarzeń i raportowanie

Urządzenia użytkowników końcowych zintegrowane z Zaawansowane Raportowanie i Ostrzeżenia mogą zostać opcjonalnie skonfigurowane, aby przesyłać w czasie rzeczywistym szczegółowe zdarzenia do rozwiązań SIEM stron trzecich i do interfejsu raportującego konsoli administratora Keeper. Dane dotyczące zdarzeń zawierają adres e-mail, UID wpisu, adres IP i informacje o urządzeniu (w związku z tym, że Keeper to platforma „Zero-Knowledge” i niema możliwości odszyfrowania danych użytkownika, zdarzenia nie zawierają żadnych odszyfrowanych danych o wpisie)

Dane zdarzenia w BreachWatch nie są wysyłane do Modułu zaawansowanego raportowania i ostrzeżeń ani żadnych powiązanych zewnętrznych systemów logowania. Aby aktywować raportowanie zdarzeń w zakresie danych BreachWatch do Modułu zaawansowanego raportowania i ostrzeżeń, należy włączyć politykę wprowadzania zasad w zakresie zdarzeń przy określonej roli w ekranie > Ustawienia zasad > Funkcje sejfu. Po aktywowaniu tej funkcji urządzenia użytkowników końcowych zaczną przesyłać dane dotyczące zdarzeń. W związku z tym, że integracja z rozwiązaniami SIEM stron trzecich odbywa się od systemu back-end Keeper do docelowego rozwiązania SIEM, informacje o zdarzeniach są odczytywane przez docelowe rozwiązanie SIEM i mogą być stosowane w celu sprawdzania, które wpisy i którzy użytkownicy w organizacji posiadają hasła o wysokim ryzyku. Jeśli administrator Keeper nie chce przesyłać danych o zdarzeniach dot. wpisów do Modułu zaawansowanego raportowania i ostrzeżeń Keeper, to ustawienie może pozostać wyłączone.

Tryb off-line

Tryb off-line umożliwia użytkownikom uzyskanie dostępu do sejfu, wówczas gdy nie mogą połączyć się on-line z Keeper lub dostawcą tożsamości SSO. Funkcja ta jest dostępna w aplikacji mobilnej Keeper i aplikacji na komputery stacjonarne oraz w przypadku użytkowników biznesowych w popularnych przeglądarkach internetowych.

Ta funkcja jest możliwa dzięki wykonaniu kopii sejfu na lokalnym urządzeniu użytkownika. Dane z sejfu przechowywane offline są szyfrowane algorytmem AES-GCM przy użyciu generowanego losowo 256-bitowego „klucza klienta”, który jest chroniony przez algorytm PBKDF2-HMAC-SHA512 z maksymalnie 1 000 000 iteracji i przez losowy ciąg inicjujący. Ciąg inicjujący i iteracje są przechowywane lokalnie. Po wprowadzeniu hasła głównego przez użytkownika przy użyciu ciągu inicjującego i iteracji tworzony jest klucz i podejmowana jest próba odszyfrowania klucza klienta. Klucz klienta jest następnie używany w celu odszyfrowania pamięci podręcznej przechowywanego wpisu. Jeśli w opcjach sejfu użytkownika włączona jest ochrona poprzez samozniszczeniem, 5 nieudanych prób logowania spowoduje automatyczne usunięcie danych z sejfu przechowywanego lokalnie.

Architektura sieci

KSI korzysta z Amazon AWS w Ameryce Północnej, Europie i Australii w celu zapewnienia segregacji zlokalizowanych danych pod względem prywatności i obszaru geograficznego i umożliwić hostowanie i obsługiwanie rozwiązań i architektury aplikacji Keeper. Firma KSI korzysta z systemu Amazon AWS do hostingu i operowania rozwiązaniami i architekturą aplikacji Keeper. Wykorzystanie systemu Amazon AWS pozwala aplikacji Keeper na płynne skalowanie i przydzielanie zasobów w czasie rzeczywistym, dzięki czemu nasi klienci mogą korzystać z najszybszego i najbezpieczniejszego środowiska do przechowywania danych w chmurze. Firma KSI operuje zarówno w środowiskach wielostrefowych, jak i wieloregionowych, aby zmaksymalizować czas ciągłego działania serwerów i zapewnić klientom możliwie krótki czas odpowiedzi.

Uwierzytelnianie na serwerze

Cloud Security Vault firmy Keeper jest chroniony przez API, które uwierzytelnia każde żądanie pochodzące z urządzenia klienta. Na urządzeniu klienta 256-bitowy „klucz uwierzytelniający” jest generowany w oparciu o hasło główne przy użyciu PBKDF2-HMAC-SHA256 i losowego ciągu inicjującego. W wyniku operacji skracania hasła głównego przy użyciu SHA-256 powstaje „skrót autoryzacji”. Podczas logowania skrót autoryzacji jest porównywany ze skrótem autoryzacji przechowywanym w Cloud Security Vault. Po zalogowaniu zostaje wygenerowany token sesji, który jest stosowany przez klienta w późniejszych żądaniach. Ten token autoryzacyjny należy odnawiać co 30 dni lub na żądanie serwera.

Szyfrowanie przesyłu danych

KSI supports 256-bit and 128-bit SSL to encrypt all data transport between the client application and KSI’s cloud-based storage. This is the same level of encryption trusted by millions of individuals and businesses everyday for web transactions requiring security, such as online banking, online shopping, trading stocks, accessing medical information and filing tax returns.

KSI korzysta z certyfikatów TLS wystawionych przez DigiCert przy użyciu algorytmu SHA2 – najbezpieczniejszego algorytmu podpisu oferowanego obecnie przez komercyjne firmy certyfikacyjne. SHA2 jest znacznie bezpieczniejszy niż popularniejszy SHA1, którego stosowanie może wiązać się z nadużyciami ze względu na zidentyfikowane przez algorytm niedociągnięcia pod względem matematycznym. SHA2 pomaga chronić przed wydawaniem fałszywych certyfikatów, które mogłyby zostać wykorzystane przez hakerów do podszywania się pod strony internetowe.

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

• 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

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: KeeperSecurity.com i KeeperSecurity.eu jest ograniczony do HTTPS z TLS v1.2 i wprowadzony przez mechanizm HTTP Strict Transport Security. Pozwala to zapobiec wielu atakom typu „packet sniffing” i „man-in-the-middle” oraz zmianom danych.

W ramach rozszerzenia przeglądarki Keeper użytkownicy nie będą otrzymywać propozycji logowania do swoich sejfów Keeper w obszarze 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 lub KeeperSecurity.eu, bądź z paska narzędzi rozszerzenia przeglądarki Keeper, który nie jest częścią strony zawartości.

Rozszerzenie przeglądarki firmy Keeper dla Chrome, Firefox, Edge i Opera korzysta z iFrames w celu wprowadzania danych z wpisu w ekranach logowania na stronach internetowych i zapewnienia, że żadna wroga strona internetowa nie ma dostępu do wprowadzanych treści. Dane logowania wprowadzone do iFrames są również ograniczone do wpisów przechowywanych w sejfach użytkowników, które odpowiadają domenie strony docelowej. Keeper nie będzie oferować automatycznego wypełniania loginów i haseł, chyba że domena strony odpowiada domenie strony przypisanej do wpisu w sejfie Keeper.

Rozszerzenie przeglądarki Internet Explorer do logowania i uzyskiwania dostępy do wpisów korzysta z oddzielnego okna aplikacji natywnej. Te oddzielne okna nie są narażone na ataki XSS, gdyż nie można uzyskać do nich dostępu z przeglądarki. Umożliwia to rozszerzeniu przeglądarki w Internet Explorer zapewnienie okna logowania wewnątrz strony. Rozszerzenie nie będzie wyświetlać wpisów, chyba że będą one odpowiadać głównej domenie adresu strony.

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 internetowych.

Zgodność i audyt

FedRAMP StateRAMP ITAR FIPS 140-2 SOC2 ISO 27001 GDPR Compliant FDA 21 CFR
Part 11 Compliant HIPAA Compliant FSQS-NL

Posiadamy certyfikat SOC 2

Stosujemy rygorystyczne i dokładnie monitorowane procesy kontroli wewnętrznej, które pozwalają chronić wpisy użytkowników w sejfie. Aplikacja Keeper uzyskała certyfikat SOC 2 Type 2 zgodnie z wytycznymi Service Organization Control instytutu AICPA. Zgodność z SOC 2 oznacza, że sejf pozostaje bezpieczny dzięki wprowadzeniu standardowych procedur kontroli określonych w zasadach Trust Service Principles stworzonych przez instytut AICPA.

Certyfikat ISO 27001(System Zarządzania Bezpieczeństwem Informacji)

Keeper posiada certyfikat ISO 27001 w zakresie Systemu Zarządzania Informacjami Keeper Security, który obsługuje platformę Keeper Enterprise. Zakres certyfikatu ISO 27001, który posiada firma Keeper, obejmuje działanie sejfu cyfrowego i usług w chmurze oraz zarządzanie nimi, tworzenie oprogramowania i aplikacji oraz zabezpieczanie aktywów cyfrowych w sejfie cyfrowym i usługach w chmurze.

Zachowanie zgodności z GDPR

Keeper jest zgodny z rozporządzeniem RODO. Dbamy, by nasze procesy biznesowe i produkty zawsze były z nim zgodne, aby zapewnić zadowolenie naszych klientów z Unii Europejskiej. Kliknij tutaj, aby dowiedzieć się więcej o zgodności aplikacji Keeper z rozporządzeniem RODO i pobrać umowę o przetwarzaniu danych.

Autoryzacja FedRAMP

Keeper Security Government Cloud (KSGC) to platforma KSI do zarządzania hasłami i cyberbezpieczeństwa dla agencji sektora publicznego. KSGC jest autoryzowanym dostawcą Moderate Impact, hostowanym w usłudze AWS GovCloud (US). KSGC można znaleźć w wykazie FedRAMP Marketplace.

Federal Risk and Authorization Management Program (FedRAMP) to program rządu federalnego Stanów Zjednoczonych, który zapewnia standardowe podejście do oceny bezpieczeństwa, autoryzacji i ciągłego monitorowania produktów i usług w chmurze. FedRAMP umożliwia agencjom rządowym korzystanie z nowoczesnych technologii chmury, z naciskiem na bezpieczeństwo i ochronę informacji federalnych oraz pomaga przyspieszyć przyjęcie bezpiecznych rozwiązań w chmurze.

Aby uzyskać więcej informacji na temat programu FedRAMP, odwiedź stronę https://www.gsa.gov/technology/government-it-initiatives/fedramp.

Autoryzacja StateRAMP

Keeper Security Government Cloud (KSGC) to platforma KSI do zarządzania hasłami i cyberbezpieczeństwa dla agencji sektora publicznego. KSGC jest autoryzowanym dostawcą StateRAMP na poziomie Moderate Impact, hostowanym w usłudze AWS GovCloud (US). KSGC można znaleźć w wykazie StateRAMP Marketplace.

Komitety zarządzające StateRAMP przyjmują zasady i procedury, które standaryzują wymogi bezpieczeństwa dla dostawców. Biuro zarządzania programem StateRAMP weryfikuje następnie, czy wykorzystywane przez rząd oferty usług w chmurze spełniają przyjęte wymogi bezpieczeństwa poprzez niezależne audyty i stały monitoring. StateRAMP umożliwia agencjom rządowym korzystanie z nowoczesnych technologii chmury, z naciskiem na bezpieczeństwo i ochronę informacji federalnych, oraz pomaga przyspieszyć przyjęcie bezpiecznych rozwiązań w chmurze....

Aby uzyskać więcej informacji na temat StateRAMP, odwiedź stronę https://stateramp.org.

Zgodność z przepisami ITAR

KSGC zapewnia zgodność z przepisami Stanów Zjednoczonych dotyczącymi międzynarodowego obrotu bronią (ITAR). Firmy, które podlegają przepisom ITAR dotyczącym eksportu, muszą kontrolować niezamierzony eksport poprzez ograniczenie dostępu do chronionych danych osobom z USA oraz poprzez ograniczenie fizycznej lokalizacji chronionych danych do USA.

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

• W pełni zgodne z przepisami przechowywanie danych w chmurze AWS GovCloud z ograniczeniem do Stanów Zjednoczonych.
• Bezpieczne szyfrowanie danych podczas przesyłania i w stanie spoczynku.
• Zabezpieczenia zero-knowledge i zero-trust w połączeniu ze szczegółowymi uprawnieniami, co pozwala organizacjom zapewnić dostęp do poufnych danych wyłącznie upoważnionym pracownikom.
• Niezawodne funkcje raportowania zgodności zapewniają identyfikowalną, elektroniczną ścieżkę audytu wszystkich wykonanych działań i wprowadzonych danych.
• Zespół Sequestered Customer Success obejmuje osoby z USA, które zostały specjalnie przeszkolone w zakresie bezpiecznego obchodzenia się z danymi podlegającymi kontroli eksportu i przepisom ITAR.
• Brak wsparcia spoza terytorium USA.

Środowisko FedRAMP firmy Keeper zostało poddane audytowi przez niezależną zewnętrzną organizację oceniającą (3PAO) w celu sprawdzenia, czy zostały wdrożone odpowiednie mechanizmy kontrolne wspierające programy zgodności klienta z przepisami eksportowymi.

Aby uzyskać więcej informacji na temat przepisów ITAR, odwiedź stronę https://www.pmddtc.state.gov/.

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 dostarczenia ścieżki audytu wyszczególniają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.

Aby uzyskać więcej informacji na temat przepisów 21 CFR część 11, zobacz https://www.fda.gov/regulatory-information/search-fda-guidance-documents/part-11-electronic-records-electronic-signatures-scope-and-application

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 to platforma wykorzystująca szyfrowanie „zero-knowledge”, która posiada certyfikatem SOC2 oraz ISO 27001 i jest zgodna z ustawą 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).

Aby 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.

Testy penetracyjne

Keeper przeprowadza testy penetracyjne wszystkich swoich produktów i systemów z udziałem niezależnych ekspertów, w tym: NCC Group, Secarma, Cybertest oraz niezależnych badaczy w dziedzinie bezpieczeństwa. Dodatkowo współpracuje z Bugcrowd, który zarządza programem VDP – ujawniania luk w zabezpieczeniach.

Testy zabezpieczeń i skany zabezpieczeń prowadzone przez niezależne firmy

Infrastruktura Keeper jest codziennie skanowana przez Tenable, aby zapewnić, że aplikacja internetowa Keeper oraz Cloud Security Vault firmy KSI są zabezpieczone przed obecnością obcych programów, mogących próbować wykorzystać luki w oprogramowaniu („exploits”), wszelkich luk w zabezpieczeniach oraz przed próbami ataków mających na celu przeciążenie serwera („Denial of service”).

Przetwarzanie płatności i zgodność z PCI

KSI korzysta z PayPal oraz Stripe, aby w bezpieczny sposób przetwarzać płatności kartami kredytowymi i debetowymi przez stronę płatniczą KSI. PayPal oraz Stripe to rozwiązania do przetwarzania transakcji zgodne z PCI-DSS.

KSI posiada certyfikat zgodności z PCI-DSS.

EU-US Privacy Shield

Aplikacja Keeper w wersji internetowej, na systemy Android, na systemy Windows Phone oraz wersji na iPhone'a/iPada oraz jako rozszerzenie przeglądarki posiada certyfikat zgodności z rozporządzeniem EU Privacy Shield, wydany przez program EU-U.S. Privacy Shield ministerstwa handlu Stanów Zjednoczonych (U.S. Department of Commerce). Oznacza to, że aplikacja Keeper spełnia wymagania rozporządzenia o ochronie danych wydanego przez Komisję Europejską.
Więcej informacji na temat programu Privacy Shield (U.S.-EU) znajdziesz tutaj: https://www.privacyshield.gov

Zweryfikowany moduł szyfrowania FIPS 140-2

Keeper stosuje zatwierdzone moduły szyfrowania FIPS 140-2, aby sprostać rygorystycznym wymogom bezpieczeństwa sektora rządowego oraz publicznego. Szyfrowanie Keeper jest certyfikowane przez NIST CMVP i zatwierdzane do standardu FIPS 140 przez posiadające akredytację strony trzecie. Keeper otrzymał certyfikat #3976 wydawany przez NIST CMVP

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 produktem certyfikowanym przez biuro przemysłu i bezpieczeństwa (Bureau of Industry and Security) ministerstwa handlu Stanów Zjednoczonych (U.S. Department of Commerce) pod numerem kontrolnym klasyfikacji towarów eksportowych 5D992 zgodnie z rozporządzeniem EAR (Export Administration Regulations).
Więcej informacji na temat rozporządzenia EAR znajdziesz tutaj: https://www.bis.doc.gov

Całotygodniowy, zdalny monitoring

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 dotyczące zabezpieczeń związanych z monitoringiem, skontaktuj się z nami.

Wyłudzanie informacji za pośrednictwem poczty elektronicznej

Jeżeli otrzymasz wiadomość email, której rzekomym nadawcą jest firma KSI, a nie masz pewności, że tak faktycznie jest, może być to wiadomość mająca na celu oszukanie odbiorcy poprzez „podszycie się” pod adres email nadawcy („phishing”/„spoofing”). W takim przypadku wiadomość może zawierać odnośnik do strony internetowej, która przypomina wyglądem stronę KeeperSecurity.com, ale nią nie jest. Strona może prosić o podanie hasła głównego aplikacji Keeper Security lub próbować zainstalować niepożądane oprogramowanie na komputerze użytkownika w celu uzyskania do niego dostępu lub kradzieży danych osobowych. Inne wiadomości tego typu mogą zawierać łączą przekierowujące do innych potencjalnie niebezpiecznych stron internetowych. Mogą też zawierać załączniki, które z reguły zawierają złośliwe oprogramowanie („malware”). Jeżeli nie masz pewności co do autentyczności otrzymanej wiadomości email, należy ją usunąć, nie klikając na zawarte w niej odnośniki i nie otwierając zawartych w niej załączników.

Jeżeli chcesz zgłosić otrzymanie wiadomość email, której nadawca Twoim zdaniem podszywa się pod firmę KSI, lub masz inne wątpliwości dotyczące innych obszarów działalności firmy KSI, skontaktuj się z nami.

Infrastruktura serwerowa certyfikowana zgodnie ze ścisłymi standardami branży

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:

SOC 2 PCI Compliant FIPS-140-2 ISO 27001 FedRAMP StateRAMP

Zgłaszanie luk w zabezpieczeniach i program „bug bounty”

Firma Keeper Security przestrzega najlepszych praktyk w branży pod względem odpowiedzialnego informowania o potencjalnych problemów z bezpieczeństwem. Podchodzimy do Twojego bezpieczeństwa i prywatności bardzo poważnie i zależy nam na ochronie prywatności naszych klientów i ich danych osobowych. Misją firmy KSI jest zbudowanie najbezpieczniejszych i najbardziej innowacyjnych aplikacji w zakresie zabezpieczeń i wierzymy, że zgłaszanie luk przez międzynarodową społeczność jest cennym składnikiem, pozwalającym zapewnić bezpieczeństwo produktów i usług oferowanych przez KSI.

Zapewnianie bezpieczeństwa naszym użytkownikom jest kluczową wartością naszej firmy. Doceniamy wkład hakerów działających w dobrej wierze i jesteśmy zdania, że długoterminowa relacja ze społecznością hakerską pomoże nam zapewnić naszym użytkownikom zachowanie bezpieczeństwa i prywatności i sprawić, że Internet stanie się bezpieczniejszym miejscem. W skład tych działań wchodzi odpowiedzialne testowanie bezpieczeństwa i ujawnianie luk w zabezpieczeniach.

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 testowanie i raportowanie odbywa się zgodnie z wytycznymi tej polityki:

• uznajemy je za dozwolone 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 pierwszy/pierwsza i na jego podstawie zmienimy kod lub konfigurację.

Jeśli w dowolnym momencie będziesz mieć wątpliwości w kwestach związanych z testowaniem w sposób zgodny z wytycznymi i zakresem tej polityki, skontaktuj się z nami pod adresem: security@keepersecurity.com zanim rozpoczniesz testowanie.

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

• nie będziesz naruszać prywatności, wpływać negatywnie na korzystanie z aplikacji przez użytkowników, zakłócać systemów produkcyjnych lub korporacyjnych, niszczyć danych;
• Prowadź sprawdzanie zabezpieczeń wyłącznie w zakresie określonym w programie Bugcrowd ujawniania luk w zabezpieczeniach z wyłączeniem systemów i działań, które nie są przez ten zakres objęte;
• skontaktujesz się z nami natychmiast, wysyłając wiadomość na adres: security@keepersecurity.com, jeśli podczas testowania napotkasz jakiekolwiek dane użytkowników;
• zapewnisz nam wystarczający czas na zanalizowanie, potwierdzenie i rozwiązanie zgłaszanej kwestii przed podaniem do wiadomości publicznej jakichkolwiek znalezionych luk w zabezpieczeniach.

Przesyłanie raportu

Keeper współpracuje z Bugcrowd w celu zarządzania naszym programem zgłaszania luk w zabezpieczeniach.

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

Dodatkowe informacje

Dokumentacja produktu

Portal dokumentacyjny Keeper, zawierający instrukcje obsługi produktu, informacje techniczne, informacje o wersji i przewodniki dla użytkownika, jest dostępny pod adresem: https://docs.keeper.io

Status systemu

Rzeczywisty stan systemu można sprawdzić tutaj: https://statuspage.keeper.io