Keeper is fanatical about credential security and data protection

Keeper utilizes world-class security with end-to-end encryption and a zero-knowledge and zero-trust architecture to protect your information and prevent cybercriminals from accessing your data.

Keeper’s best-in-class security at a glance

Strongest end-to-end encryption

Keeper защищает ваши пароли, секреты и личную информацию с помощью 256-битного шифрования AES и эллиптической криптографии, которая считается самым надежным методом шифрованием в индустрии кибербезопасности.

Keeper — поставщик услуг обеспечения безопасности с нулевым разглашением данных. Нулевое разглашение представляет собой системную архитектуру, гарантирующую высочайший уровень безопасности и конфиденциальности. Шифрование и дешифрование данных всегда происходит локально на устройстве пользователя.

Vulnerability and bug bounty program

Keeper стремится защищать конфиденциальность и личные данные своих клиентов. Наша миссия — создавать самые надежные в мире и инновационные приложения обеспечения безопасности, и мы считаем, что отчеты об ошибках от мирового сообщества исследователей по безопасности являются ценным компонентом обеспечения безопасности продуктов и услуг Keeper. По этим причинам мы сотрудничаем с Bugcrowd в целях управления нашей программой раскрытия уязвимостей (VDP) и программой вознаграждения за обнаружение ошибок.

Сертификат FIPS 140

Решение Keeper сертифицировано Программой проверки криптографических модулей NIST (CMVP) на соответствие стандарту FIPS 140-2.

Penetration testing

Keeper сотрудничает со сторонними экспертами, такими как NCC Group, CyberTest и независимыми исследователями по безопасности, для проведения ежеквартального тестирования всех решений и систем на проникновение.

Secure and reliable cloud vault

Keeper использует AWS в нескольких регионах, включая США, GovCloud США, Европу, Австралию, Калифорнию и Японию, для размещения и эксплуатации платформы и архитектуры Keeper. Благодаря этому клиентам предоставляется самое безопасное доступное облачное хранилище. Данные полностью изолированы в предпочитаемом клиентом регионе AWS при передаче и хранении.

High availability

Глобальная инфраструктура Keeper размещена в нескольких центрах обработки данных AWS с высоким уровнем готовности. Эти центры обработки данных распределены по нескольким регионам AWS, чтобы обеспечить доступность услуг в случае регионального отключения Интернета.

Многофакторная аутентификация

Keeper поддерживает многофакторную аутентификацию (MFA), аутентификацию единого входа (SSO), политики условного доступа (CAP), аппаратные ключи безопасности FIDO2 WebAuthn, ключи доступа, биометрический вход в систему (например, Face ID, Touch ID и Windows Hello) и Keeper DNA®, используя умные часы для подтверждения личности.

Zero-knowledge encryption

Данные конечного пользователя шифруются и дешифруются на уровне устройства и на уровне записи – никогда в облаке или на серверах Keeper. Шифрование на уровне записей уменьшает «радиус поражения» информации, хранящейся в пользовательских хранилищах, и поддерживает многие функции платформы с наименьшими привилегиями, такие как совместное использование записей.

Обзор

Keeper Security, Inc. стремится защитить информацию своих клиентов с помощью программного обеспечения Keeper для обеспечения безопасности мобильных устройств и настольных компьютеров. Миллионы потребителей и предприятий доверяют Keeper защиту своих паролей и личной информации и доступ к ним.

Программное обеспечение Keeper постоянно совершенствуется и обновляется, чтобы предоставить клиентам новейшие технологии и средства защиты. На этой странице представлен обзор архитектуры безопасности Keeper, методологий шифрования и среды хостинга по состоянию на текущую опубликованную версию. В этом документе дается обзор технических деталей наших методов шифрования и защиты.

Наша Политика конфиденциальности и Условия использования доступны на нашем веб-сайте по следующим ссылкам:

Zero-trust platform

Keeper использует архитектуру нулевого доверия, которая гарантирует, что каждый пользователь должен пройти проверку и аутентификацию, прежде чем он сможет получить доступ к веб-сайту, приложению или системе.

Keeper Enterprise Password Management (EPM) обеспечивает компаниям полную видимость и контроль над тем, как их сотрудники используют пароли, позволяя ИТ-администраторам отслеживать использование паролей и применять передовые методы обеспечения безопасности.

Keeper Secrets Manager (KSM) предоставляет инженерным командам платформу для управления всеми учетными данными, включая секреты инфраструктуры, ключи SSH, ключи API и сертификаты, с помощью SDK и интеграции CI/CD.

Keeper Connection Manager (KCM) – это шлюз удаленного рабочего стола, который предоставляет группам DevOps и ИТ-специалистам легкий сетевой доступ с нулевым доверием (ZTNA) к RDP, SSH и базам данных, внутренним веб-приложениям и конечным точкам Kubernetes через веб-браузер — агент не требуется.

Как Keeper поддерживает платформу с нулевым доверием
Модель шифрования и безопасности Keeper

Keeper’s best-in-class security in detail

Encryption of vault data

Keeper предоставляет модель многоуровневого шифрования на базе принципа наименьших привилегий. На клиентском устройстве генерируются 256-битные ключи AES на уровне записи и ключи на уровне папки, с помощью которых шифруется каждая запись в хранилище. Записи хранилища и все его содержимое полностью зашифрованы, включая логины, вложенные файлы, коды TOTP, платежную информацию, URL-адреса и настраиваемые поля.

Ключи шифрования генерируются локально на устройстве в целях обеспечения принципа нулевого разглашения данных и поддержки расширенных функций, таких как совместное использование записей и папок. Нулевое разглашение означает, что каждый пользователь имеет полный контроль над шифрованием и дешифрованием всей личной информации в своем хранилище Keeper, и ничто из сохраненных им данных не доступно никому другому, даже сотрудникам Keeper.

Ключи записей и ключи папок шифруются 256-битным ключом данных AES, который уникален для каждого пользователя и генерируется на устройстве пользователя.

На устройстве пользователя создается еще один 256-битный клиентский ключ AES для шифрования локального автономного кэша (если администратор предприятия разрешает автономный доступ). Наконец, 256-битный ключ данных AES шифруется другим ключом, как описано в следующем разделе.

Vault encryption methods

Keeper шифрует данные по-разному в зависимости от того, как пользователи входят в систему. Для рядовых пользователей и участников семейного плана используется мастер-пароль и биометрическая аутентификация. Для бизнес-пользователей и корпоративных пользователей, которые входят в систему с помощью единого входа, Keeper использует эллиптическую криптографию в целях безопасной работы без пароля.

Для пользователей, входящих с помощью мастер-пароля: Ключ для дешифрования и шифрования ключа данных извлекается из мастер-пароля пользователя с использованием функции изменения ключа на основе пароля. (PBKDF2) с 1 000 000 итераций. После того как пользователь вводит свой мастер-пароль, ключ извлекается локально, а затем получается ключ данных. Ключ данных дешифруется и используется для получения ключей отдельных записей и папок. При дешифровке каждого ключа содержимое записи сохраняется локально на устройстве пользователя.

Модель шифрования Keeper — Вход с мастер-паролем

Для пользователей, входящих в систему с помощью единого входа или технологии без пароля: Эллиптическая криптография используется для шифрования и дешифрования данных на уровне устройства. Локальный закрытый ключ ECC-256 (secp256r1) используется для дешифровки ключа данных. После дешифровки ключа данных он используется для получения ключей отдельных записей и папок. Затем с помощью ключа записи дешифруется содержимое каждой сохраненной записи. Зашифрованный ключ данных передается между устройствами пользователя через push-систему или службу обмена ключами, называемую подтверждением устройства. С целью обеспечения принципа нулевого разглашения, подтверждение устройства управляется локально конечным пользователем.

SSO Connect Cloud — Многоуровневая модель шифрования

SSO encryption model

First device flow (new user onboarding)

  1. Генерируются ключ данных, пара ключей общего доступа и пара закрытых/открытых ключей ЭК устройства
  2. Ключ данных шифруется открытым ключом ЭК устройства и сохраняется в облаке (DEDK)
  3. Пользователь входит в систему с помощью своего поставщика удостоверений (IdP)
  4. После входа в систему с IdP подписанное утверждение SAML проверяется Keeper
  5. Создается хранилище, и пользователь подключается

Existing device flow

  1. Пользователь входит в систему с помощью своего поставщика удостоверений (IdP)
  2. После входа в систему с IdP подписанное утверждение SAML проверяется Keeper
  3. Keeper предоставляет пользователю ключ данных, зашифрованный устройством (DESK)
  4. Ключ данных дешифруется закрытым ключом ЭК устройства
  5. С помощью ключа данных дешифруются ключи папок и ключи записей
  6. С помощью ключей записи дешифруется содержимое записей

New or unrecognized device flow

  1. На каждом новом устройстве создается пара закрытого/открытого ключа ЭК
  2. Пользователь входит в систему с помощью своего поставщика удостоверений (IdP)
  3. После входа в систему с IdP подписанное утверждение SAML проверяется Keeper
  4. Устройство «одобряется» посредством Keeper Push, одобрение администратора или службу Keeper Automator (*см. «Подтверждение устройства» ниже).
  5. В процессе подтверждения ключ данных шифруется открытым ключом нового устройства
  6. Ключ данных, зашифрованный устройством (DEDK), отправляется пользователю

Device approval

  • Подтверждение устройства — это механизм безопасной доставки ключа данных пользователя на новое устройство с сохранением принципа нулевого разглашения
  • Пользователь может подтвердить свое устройство, зашифровав ключ данных открытым ключом нового устройства
  • Администратор может одобрить устройство с помощью консоли администрирования, Keeper Commander или службы Keeper Automator
  • Администратор дешифрует ключ данных пользователя и повторно шифрует ключ данных с помощью открытого ключа нового устройства.
  • Служба Keeper Automator может выполнять автоматическое подтверждение устройств в инфраструктуре клиента
  • Keeper Automator проверяет подпись SAML, получает ключ данных и шифрует ключ данных с помощью открытого ключа нового устройства

Узнайте подробнее о службе Keeper Automator.

Device-level security for SSO Connect Cloud

Для пользователей SSO Connect Cloud создается закрытый ключ эллиптической криптографии (ЭК), который сохраняется локально на каждом устройстве. В современных веб-браузерах и приложении Keeper Desktop на базе Electron хранилище Keeper хранит закрытый ключ ЭК локального устройства («DPRIV») в виде неэкспортируемого файла CryptoKey. На устройствах iOS и macOS ключ хранится в связке ключей устройства. На устройствах Android ключ шифруется с Android Keystore с использованием Encrypted Shared Preferences. Там, где это возможно, Keeper использует механизмы безопасного хранения в каждой операционной системе.

Закрытый ключ устройства не используется напрямую для шифрования или дешифрования данных хранилища. После успешной аутентификации от поставщика удостоверений для расшифровки данных хранилища используется отдельный ключ (который не сохраняется). Поэтому при автономном извлечении закрытого ключа локального устройства невозможно дешифровать хранилище пользователя.

Encryption of data at rest

Keeper использует AWS для хостинга платформы и архитектуры Keeper. Наши центры обработки данных AWS расположены в нескольких географических точках, и наши клиенты могут арендовать Keeper в любом предпочтительном основном регионе. Это гарантирует, что данные клиентов и доступ к платформе будут ограничены этим конкретным регионом.

Хранящиеся данные шифруются на устройстве пользователя локально с использованием AES-256 GCM, а зашифрованные данные при передаче шифруются с помощью TLS 1.3 с дополнительным уровнем шифрования. Данные клиентов изолируются за счет шифрования на уровне записей.

Модель шифрования Keeper придерживается следующей структуры:

  • Все хранилища шифруются уникальным 256-битным ключом AES, сгенерированным на стороне клиента в режиме GCM.
  • Все ключи уровня записи в общих папках шифруются 256-битным ключом AES общей папки.
  • Ключи записей и папок для пользователей хранилища шифруются с помощью другого 256-битного ключа AES, называемого ключом данных.
  • В Keeper Secrets Manager (KSM) ключи записей и папок пользователя шифруются с помощью 256-битного ключа AES, называемого ключом приложения.
  • Для пользователей, входящих в систему с помощью мастер-пароля, ключи для дешифрования и шифрования данных получаются из мастер-пароля.
  • При входе в систему с помощью единого входа или технологии без пароля используется эллиптическая криптография для шифрования и дешифрования данных на устройстве.
  • Все зашифрованные полезные данные отправляется на серверы Keeper и шифруются 256-битным ключом передачи AES с TLS — для защиты от атак «человек посередине» (MITM). Ключ генерируется на клиенте и передается с использованием шифрования ECIES через открытый ключ ЭК сервера.
  • Для безопасного обмена секретами между пользователями используется распределение ключей эллиптической криптографии.
Схема шифрования записей

Record versioning

Keeper ведет полную зашифрованную историю версий каждой записи в хранилище пользователя, обеспечивая уверенность в том, что никакие важные данные никогда не будут потеряны. В клиентском приложении Keeper пользователи могут просматривать историю записей и выполнять восстановление любой отдельной записи хранилища. Если сохраненный пароль или файл в Keeper изменен или удален, у пользователей всегда есть возможность выполнить восстановление на определенный момент времени.

Keeper Business

Клиентам, приобретающим Keeper Business, предоставляется дополнительный уровень контроля над своими пользователями и устройствами. Администраторам Keeper предоставляется доступ к облачной консоли администрирования, которая позволяет полностью контролировать регистрацию и удаление пользователей, разрешения на основе ролей, делегированное администрирование, группы пользователей, интеграцию Active Directory/LDAP, двухфакторную аутентификацию, единый вход и политики обеспечения безопасности. Политики применения Keeper на основе ролей полностью настраиваемы и масштабируемы для организации любого размера.

Super encryption of data at rest

Помимо хранения в инфраструктуре AWS только зашифрованного на устройстве шифротекста, Keeper также выполняет супершифрование с помощью многорегиональных аппаратных модулей безопасности (HSM) с использованием неэкспортируемых ключей.

Encryption and protection of backups

На уровне продукта/пользователя программное обеспечение Keeper сохраняет полную историю изменений каждой записи. Поэтому, если пользователю требуется провести восстановление, он может просмотреть и вернуться к предыдущим версиям своих сохраненных записей Keeper в любое время без ограничений, используя пользовательский интерфейс.

На системном уровне зашифрованные базы данных и файловые объекты Keeper реплицируются и резервируются в нескольких географических регионах в целях аварийного восстановления. Все резервные копии шифруются с помощью AES-256 в дополнение к супершифрованию шифротекста, созданного на устройстве.

Клиентам, которым требуется помощь в восстановлении (например, из-за того, что клиент случайно удалил хранилище или общую папку), служба поддержки Keeper может помочь в восстановлении на любой момент времени (с точностью до минуты) в течение 30 дней. Поддержка Keeper может помочь в любом восстановлении, например восстановлении пользователя, восстановлении хранилища или полном восстановлении предприятия.

Account recovery

Фраза восстановления из 24 слов позволяет клиентам Keeper восстановить доступ к своему хранилищу Keeper, если они потеряют или забудут свой мастер-пароль.

Keeper ввел фразы восстановления, используя тот же список слов BIP39, который используется для защиты криптокошельков. Список слов BIP39 представляет собой набор из 2048 слов, используемых для генерации ключа шифрования с 256 битами энтропии. Этот метод восстановления обычно используется в популярных биткойн- и криптовалютных кошельках. Каждое слово в списке BIP39 тщательно отобрано, чтобы улучшить видимость и сделать процесс восстановления менее подверженным ошибкам. Пользователям следует записать фразу восстановления и хранить ее в надежном месте, например в сейфе.

По фразе восстановления генерируется 256-битный ключ AES, с которым шифруется копия ключа данных пользователя. Чтобы восстановить учетную запись и сбросить мастер-пароль, пользователю требуется ввести фразу восстановления, а также пройти проверку посредством электронной почты и двухфакторной аутентификации (2FA).

Администраторы предприятия могут отключить восстановление учетной записи на уровне политики применения ролей.

Установка фразы восстановления

Enterprise encryption keys

Клиенты Keeper Enterprise и Business могут управлять множеством различных возможностей платформы Keeper, такими как политики доступа на основе ролей, подготовка пользователей, аутентификация и управление.

Функции администратора защищены на платформе Keeper как шифрованием, так и авторизацией. Авторизация гарантирует, что только назначенные пользователи могут выполнять определенные функции. Шифрование гарантирует, что назначенные администраторы смогут физически и криптографически выполнять только функции, связанные с данными хранилища или ключами, контролируемыми предприятием. Вот несколько примеров:

  • Платформа Keeper де-факто является платформой управления ключами, на которой пользователи и администраторы имеют полный контроль над своими закрытыми ключами.
  • Пары открытых и закрытых ключей шифрования используются при создании устройств, пользователей и команд.
  • Ролевые политики для передачи хранилищ и подтверждения устройств используют открытый и закрытый ключи шифрования.
  • Пары ключей эллиптической криптографии (ЭК) используются для обмена данными между пользователями, а также для передачи данных от отдельного пользователя к администратору на уровне предприятия.
  • Конфиденциальные данные об использовании, такие как надежность пароля записи, шифруются с помощью корпоративных открытых ключей, дешифровать которые может только администратор.
  • Поля записи, URL-адреса и типа записи каждой записи хранилища корпоративного пользователя шифруются с помощью корпоративного открытого ключа и могут быть дешифрованы с консоли администрирования Keeper администратором, которому предоставлены права на создание отчетов о соответствии нормативным требованиям.

Device verification

Прежде чем пользователь сможет даже попытаться войти в учетную запись, он должен сначала пройти этап проверки и подтверждения устройства. Проверка устройства предотвращает атаки перечислением и защищает от атак методом подбора.

Клиенты, вошедшие в систему с помощью мастер-пароля, могут выполнять проверку устройства несколькими способами, в том числе:

  • Проверочный код по электронной почте
  • Ввод кода 2FA из TOTP или текстового сообщения
  • Использование Keeper Push для отправки сообщения на распознанное устройство

Для клиентов, прошедших аутентификацию с помощью Keeper SSO Connect Cloud подтверждение устройства осуществляется с помощью передачи ключа, при которой на устройство доставляется зашифрованный ключ данных пользователя, который дешифруется локально с использованием закрытого ключа пользователя эллиптической криптографии. К методам подтверждения устройства относятся следующие:

  • Keeper Push (с использованием push-уведомлений) на подтвержденные пользовательские устройства
  • Одобрение администратором с помощью консоли администрирования Keeper
  • Автоматическое подтверждение посредством службы Keeper Automator.
  • Автоматическое подтверждение администратором посредством интерфейса командной строки Keeper Commander

Узнайте подробнее о подтверждении устройств.

Data privacy

Keeper соответствует требованиям GDPR и стремится обеспечить соответствие своих процессов и продуктов требованиям GDPR для клиентов в Европейском Союзе и по всему миру. 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.

См. Политику конфиденциальности Keeper в связи с GDPR.

Ни одно из приложений Keeper не содержит трекеров и сторонних библиотек, осуществляющих отслеживание. В качестве примера в данном отчете представлена информация о работе приложения Keeper для Android, которая показывает, что трекеры не установлены.

Data isolation

Keeper is a fully-managed SaaS platform and hosts its data in multiple, geographically isolated AWS data centers. Organizations may host their Keeper tenant in their preferred primary region. Customer data and access to the platform is isolated to that specific region.

Доступные регионы:

  • Соединенные Штаты Америки (США)
  • Правительственное облако США (US_GOV)
  • Европа
  • Австралия
  • Япония
  • Канада

Encryption in transit

Хранилище Keeper защищено API, которые проверяются посредством авторизации на устройстве пользователя.

  • Пользователь получает токен сеанса со своим логином и отправляет его при каждом вызове API.
  • Токен сеанса управляется и контролируется на внутреннем сервере.
  • Вход в систему осуществляется с помощью мастер-пароля, биометрических данных, возобновления сеанса или аутентификации единого входа SAML 2.0.

При использовании мастер-пароля пользовательское устройство получает 256-битный ключ аутентификации с использованием PBKDF2-HMAC_SHA256 с 1 000 000 итераций и случайной солью. Хэш аутентификации создается путем хеширования ключа аутентификации с использованием SHA-256. При входе в систему хэш аутентификации сравнивается с сохраненным хэшем аутентификации в хранилище Keeper. После входа пользователя в систему на сервере создается токен сеанса, который отправляется пользователю для использования устройством для последующих запросов API. Чтобы разрешить постоянное использование связи клиент-сервер, сеанс должен быть активным.

  • Keeper использует 256-битный и 128-битный TLS для шифрования 100% данных, хранящихся в пользовательском приложении и безопасном файловом хранилище Keeper.
  • Keeper развертывает сертификаты TLS, подписанные с использованием алгоритма SHA2. SHA2 — это наиболее безопасный алгоритм подписи, доступный в настоящее время коммерческим центрам сертификации. Использование SHA2 в Keeper защищает от поддельных сертификатов, которые злоумышленник может использовать для подмены веб-сайта.

Cloud authentication

Компания Keeper создала усовершенствованную модель облачной аутентификации и сетевых коммуникаций с высочайшим уровнем конфиденциальности, безопасности, доверия и прозрачности. Вот ряд ключевых особенностей этой модели аутентификации:

Integration with any SAML 2.0 provider 

Keeper интегрируется со всеми поставщиками удостоверений, совместимыми с SAML 2.0, включая Okta, Microsoft Entra ID (Azure), AD FS, Google Workspace, Centrify, OneLogin, Ping Identity, JumpCloud, Duo, Auth0 и другими.

Мы предлагаем два разных типа единого входа: SSO Connect Cloud и SSO Connect On-Prem. Обе реализации обеспечивают архитектуру с нулевым разглашением информации и простой аутентификацией пользователей.

User master passwords are never transmitted over the network layer

В отличие от большинства услуг SaaS, учетные данные пользователей Keeper никогда не покидают их устройства. Когда пользователи входят в Keeper с помощью мастер-пароля, PBKDF2 используется на локальном устройстве для получения 256-битного ключа AES для дешифрования. Дополнительный ключ PBKDF2 генерируется на уровне устройства, а затем хэшируется с помощью HMAC_SHA256 для создания токена аутентификации. Keeper ничего не знает о ключе дешифрования пользователя.

Traffic between the client device and Keeper Cloud cannot be intercepted or decrypted

Все зашифрованные полезные данные, отправляемые на серверы Keeper, шифруются 256-битным ключом передачи AES и TLS для защиты от атак типа «человек посередине» (MITM). Ключ передачи генерируется на клиентском устройстве и передается на сервер с использованием шифрования ECIES посредством открытого ключа ЭК сервера.

New devices cannot be used to log in to an account without a verification step

Пользователи не могут использовать новые устройства для входа в свои учетные записи Keeper, не пройдя их проверку. Keeper поддерживает несколько способов проверки в зависимости от схемы аутентификации.

Multi-factor authentication (MFA) is performed after verification, before users enter their master password

Если у пользователя включена или принудительно применена MFA, он должен сначала выполнить этот шаг, прежде чем вводить свой мастер-пароль.

Master password entry cannot be performed until the device verification and MFA steps succeed

Если способ проверки не настроен, пользователь не сможет перейти к вводу своего мастер-пароля. Такая расширенная аутентификация защищает от нескольких распространенных типов атак, включая атаки методом подбора, распыление паролей, перечисление и «человек посередине».

Multi-factor authentication (MFA)

Для защиты от несанкционированного доступа к учетным записям клиентов Keeper предлагает много-факторную аутентификацию (MFA), в которой требуется два или более факторов аутентификации, которыми являются фактор знания, фактор владения и/или фактор неотъемлемости. Узнайте больше о настройке MFA в Keeper.

Keeper использует ваш мастер-пароль и ваше устройство, чтобы обеспечить дополнительный уровень безопасности, если ваш мастер-пароль или устройство будут скомпрометированы. Keeper поддерживает аппаратные ключи FIDO2 WebAuthn и программные решения, такие как TOTP и SMS.

При использовании метода TOTP в MFA/2FA Keeper генерирует 10-байтовый секретный ключ с помощью криптографически безопасного генератора случайных чисел. Код TOTP действителен около минуты и не может быть использован повторно после успешной аутентификации. Keeper поддерживает любое приложение TOTP, включая Google Authenticator и Microsoft Authenticator. Keeper также напрямую интегрируется с популярными службами MFA, такими как Duo и RSA SecurID.

При использовании аутентификаторов MFA, таких как Google Authenticator, Microsoft Authenticator или других приложений TOTP на вашем мобильном устройстве, сервер Keeper внутренне генерирует QR-код, содержащий ваш секретный ключ. Каждый раз, когда пользователь активирует MFA, генерируется новый ключ.

Чтобы активировать MFA, перейдите на экран настроек веб-приложения Keeper, настольного приложения Desktop App или приложения для iOS/Android. Администраторы Keeper Business также могут принудительно вводить MFA и поддерживаемые методы MFA посредством консоли администрирования Keeper.

Поддержка FIDO2-совместимого WebAuth обеспечивается посредством Keeper, а в качестве дополнительного фактора используются аппаратные ключи безопасности, такие как ключи YubiKey и Google Titan. Ключи доступа также поддерживаются методом 2FA с использованием физических устройств или веб-браузеров. Ключи безопасности предоставляют безопасный способ выполнения MFA, не требуя от пользователя ввода кодов вручную.

Android Smart WatchAndroid Smart Watch Apple Smart WatchApple Smart Watch DUODUO EntrustEntrust Google AuthenticatorGoogle Authenticator Microsoft Authenticator Microsoft Authenticator RSA SecureIDRSA SecureID Текстовое сообщение SMSТекстовое сообщение SMS Titan Security KeyTitan Security Key TOTPTOTP YubicoYubico

Keeper Bridge для Active Directory / LDAP

Мост Keeper Bridge интегрируется с серверами Active Directory и LDAP для подготовки и подключения пользователей пользователей. Коммуникация с Keeper Bridge сначала авторизуется администратором, имеющим право управлять мостом. Ключ передачи генерируется и передается Keeper для всех последующих коммуникаций. Использование ключа передачи предстает авторизацией всех операций, выполняемых мостом, за исключением инициализации моста. Ключ передачи можно восстановить в любое время, и он будет автоматически меняться каждые 30 дней.

Ключ передачи предназначен только для передачи, что означает, что скомпрометированный ключ может быть повторно инициализирован или отозван без какой-либо потери данных или разрешения.

Keeper Bridge не может предоставлять привилегии роли или пользователю. Он может добавить пользователю привилегированную роль, при условии, что ключи принудительного исполнения не требуются. Операции Keeper Bridge не могут распространяться выше той части дерева, которой он управляет. Мосту доступны не все операции, например, мост может отключить активного пользователя, но не может удалить его. Администратор должен будет выбрать, следует ли удалить пользователя или перенести его.

Keeper Bridge для Active Directory / LDAP

SSO authentication with MFA

When Keeper is deployed with an SSO solution such as Entra ID / Azure AD, Okta, Ping, Google Workspace or any other SAML 2.0 identity provider, MFA can be fully managed during the IdP login process. Keeper also supports Azure conditional access policies across all device types and applications.

MFA можно ввести как на стороне поставщика удостоверений, так и на стороне Keeper. Например, как только пользователь проходит этап MFA с поставщиком удостоверений, его дополнительно можно заставить пройти второй этап MFA в интерфейсе Keeper. Эту политику может применить администратор Keeper.

Amazon Web ServicesAmazon Web Services CASCAS CentrifyCentrify DUODUO F5F5 Google WorkplaceGoogle Workplace IBM SecurityIBM Security JumpCloudJumpCloud MicrosoftMicrosoft OneloginOnelogin OktaOkta Ping IdentityPing Identity

SAML 2.0 authentication with SSO Connect Cloud

Keeper SSO Connect Cloud позволяет корпоративным клиентам полностью интегрировать Keeper с любым поставщиком удостоверений, совместимым с SAML 2.0, и развертывать зашифрованные хранилища для своих пользователей.

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 is an optional service which performs instant team approvals, device approvals and team user assignments upon a successful login from the SSO identity provider.

Once Automator is running, users can seamlessly access Keeper on new devices (not previously approved) after a successful authentication with your identity provider, without any further approval steps.

Keeper SSO Connect на месте

While most customers deploy Keeper SSO Connect Cloud, customers that require an on-prem solution can deploy SSO Connect On-Prem, a self-hosted integration that requires either a Windows or Linux hosted application server. In order to maintain Zero Knowledge security and ensure a seamless SSO experience for users, Keeper SSO Connect must be installed on the customer's server. Windows, Mac and Linux environments are fully supported with High Availability (HA) load balancing operational modes and super-encryption with hardware security modules.

Keeper SSO Connect автоматически генерирует и сохраняет мастер-пароль для каждого подготовленного пользователя; этот пароль представляет собой случайно сгенерированный 256-битный ключ. Мастер-пароль шифруется с помощью ключа единого входа. Ключ единого входа шифруется с помощью ключа дерева. Ключ единого входа извлекается с сервера при запуске службы Keeper SSO Connect, а затем дешифруется с помощью ключа дерева, который хранится локально на сервере для поддержки автоматического запуска службы. Коммуникация между SSO Connect и безопасным облачным хранилищем Keeper защищена ключом передачи. Сообщения SAML имеют криптографическую подпись и защищены алгоритмом подписи RSA-SHA256 или ECDSA-SHA256 в зависимости от типа ключа шифрования (RSA или ECC), предоставленного клиентом.

Обмен записями

Keeper поддерживает возможность безопасного обмена записями между пользователями, безопасного предоставления записей другой группе в организации или даже за пределами организации (если это разрешено администратором Keeper).

Sharing records

Пользователи Keeper могут напрямую обмениваться записями друг с другом. Для этого Keeper сначала запрашивает открытый ключ эллиптической криптографии пользователя из его хранилища. Каждая запись имеет ключ записи, который шифруется с помощью открытого ключа эллиптической криптографии получателя и синхронизируется с хранилищем Keeper пользователя.

Владелец зашифрованной общей записи дешифрует ключ записи с помощью своего закрытого ключа эллиптической криптографии. Ключ записи также повторно шифруется с помощью ключа данных пользователя, а зашифрованный текст сохраняется в хранилище получателя.

Архитектура предоставления записей

Огранич. доступ

Функция ограниченного предоставления Keeper обеспечивает ограниченное по времени безопасное предоставление записи (например, пароля, учетных данных, секрета, соединения, документа или другой конфиденциальной информации) кому угодно, даже если у него нет учетной записи Keeper. Модель шифрования ограниченного предоставления Keeper использует ту же технологию, что и Keeper Secrets Manager (KSM) — платформу с нулевым разглашением и нулевым доверием для защиты облачной инфраструктуры.

  1. Чтобы использовать функцию ограниченного предоставления, отправитель нажимает «Ограниченное предоставление» в хранилище Keeper пользователя. 256-битный ключ записи AES шифруется с помощью токена ограниченного доступа, а зашифрованное значение сохраняется в хранилище Keeper.
  2. Пользователь, передающий получателю токен ограниченного доступа, использует простой URL-адрес или QR-код. Часть URL-адреса, содержащая токен доступа, хранится в части URL-адреса «идентификатор фрагмента», которая никогда не отправляется на серверы Keeper. Таким образом, Keeper не может получить доступ к информации или дешифровать ее, и при этом сохраняется принцип нулевого разглашения.
  3. URL-адрес открывается в браузере пользователя, и приложение хранилища загружается на устройство. Токен передается непосредственно в локальное приложение хранилища, а не на сервер.
  4. Затем получатель использует свое устройство для создания пары ключей ЭК на стороне конечного пользователя, а закрытый ключ сохраняется локально, на устройстве, в хранилище CryptoKey браузера.
  5. При первом использовании получателя библиотека SDK проверяет подлинность с помощью хэша токена ограниченного доступа. Затем сервер Keeper отвечает зашифрованным шифротекстом записи и зашифрованным ключом записи.
  6. Устройство дешифрует ключ записи с помощью токена ограниченного доступа, и содержимое дешифруется. Ключ хранится на клиентском устройстве в хранилище CryptoKey браузера или в другом месте хранения.
  7. Зашифрованный ключ записи для данного устройства удаляется, поэтому токен нельзя использовать снова. После этого клиентский запрос необходимо подписать закрытым ключом.
  8. Дополнительные вызовы на то же устройство отправляются с идентификатором, определяющим устройство, и запросом, подписанным закрытым ключом клиента. В запросе идентификатора данного устройства – посредством подписи ECDSA – используется открытый ключ клиента устройства, и он проверяется сервером. Keeper обрабатывает запрос, и сервер возвращает зашифрованную запись в шифротексте на устройство пользователя.
  9. В дополнение к шифрованию на уровне записи клиентское устройство создает случайно сгенерированный 256-битный ключ передачи AES, который шифруется открытым ключом облачного API Keeper. Клиентское устройство дешифрует ответ от сервера с помощью ключа передачи, а затем дешифрует полезные данные ответа шифротекста с помощью ключа записи, который дешифрует содержимое записи.
Огранич. доступ

Share Admin

Функция администратора общего доступа Keeper представляет собой разрешение управления доступом на основе ролей (RBAC), которое предоставляет администраторам повышенные права в отношении общих папок и записей организации. Администраторы общего доступа обладают полными правами пользователя и записи для любой общей записи, к которой у них есть доступ.

Share Admin

Secrets Manager encryption model

Keeper Secrets Manager is a zero-knowledge platform for IT and DevOps professionals that allows teams to manage secrets throughout the software development and deployment lifecycle.

Модель шифрования Keeper Secrets Manager

Secrets Manager uses the following encryption model

  • Шифрование и дешифрование происходит локально на устройстве (не на сервере).
  • Обычный незашифрованный текст никогда не сохраняется на устройстве.
  • Обычный незашифрованный текст никогда не принимается сервером.
  • Никто, включая сотрудников Keeper, третьих лиц и посредников, не может дешифровать секреты.
  • Клиентское устройство управляет ключами шифрования и дешифрования секретов под контролем пользователя.
  • Каждый секрет шифруется сгенерированным на стороне клиента 256-битным ключом шифрования AES в режиме GCM.
  • Если секрет содержится в общей папке, ключ записи шифруется ключом общей папки.
  • 256-битный ключ приложения AES генерируется на стороне клиента и используется для дешифрования ключей общей папки и записи. Ключ записи затем дешифрует индивидуальный секрет.
  • Серверы Keeper защищены 256-битным ключом AES с TLS от атак типа MITM.
  • Ключ передачи генерируется на клиентском устройстве и передается на сервер с использованием шифрования ECIES с помощью открытого ключа ЭК сервера.
  • Эллиптическая криптография используется для обмена секретами между пользователями в целях безопасного распределения ключей.
  • Многоуровневое шифрование обеспечивает контроль доступа на уровне пользователя, группы и администратора.
  • Секреты, управляемые в хранилище, сегментируются и изолируются для определенных устройств Secrets Manager, которым предоставляется доступ к записи и папке.

Keeper Secrets Manager’s model for password rotation

  • В среде клиента устанавливается уникальный клиент Keeper Secrets Manager (KSM), называемый шлюзом.
  • Шлюз устанавливает защищенное исходящее соединение с маршрутизатором Keeper.
  • Маршрутизатор представляет собой облачный сервис, размещенный в среде AWS Keeper, который облегчает взаимодействие между внутренним API Keeper, приложениями конечного пользователя (веб-хранилище, настольное приложение и т. д.) и шлюзами, установленными в среде пользователя.
  • Веб-сокеты устанавливаются между устройством конечного пользователя (например, веб-хранилище) и маршрутизатором Keeper с использованием токена текущего сеанса.
  • Маршрутизатор Keeper проверяет токен сеанса и аутентифицирует сеанс. Все зашифрованные полезные данные, отправляемые на маршрутизатор Keeper, в дополнение к TLS шифруются 256-битным ключом AES для защиты от атак типа MITM.
  • 256-битный ключ AES создается на устройстве конечного пользователя и передается на сервер с использованием шифрования ECIES с открытым ключом ЭК маршрутизатора.
  • Запросы на ротацию и обнаружение отправляются между устройством конечного пользователя (или планировщиком Keeper) и шлюзом через установленный канал связи веб-сокета.
  • Во время ротации, когда шлюзу требуется секрет из хранилища Keeper, он аутентифицирует и дешифрует секрет с помощью API-интерфейсов Keeper Secrets Manager, благодаря чему поддерживается принцип нулевого разглашения.
  • Как и на любом другом устройстве Secrets Manager, доступ также может быть ограничен на основе IP-адреса, в дополнение к процессу шифрования и подписи.
Схема инфраструктуры ротации паролей

Zero-trust connection and tunnel security

Zero-Trust KeeperPAM provides the capability to establish cloud and on-prem privileged sessions, create tunnels, establish direct infrastructure access and secure remote database access without a VPN.

A Connection is a visual remote session using the web browser. Interaction between the user and the target device is with a web browser window or within the Keeper Desktop application.

A Tunnel is a TCP/IP connection that is established between the local vault client through the Keeper Gateway to the target endpoint. The user can utilize any native application for communicating with the target endpoint, such as the command-line terminal, GUI application or database management application such as MySQL Workbench.

When the user establishes a connection or tunnel:

  1. The Vault Client application communicates to the Keeper Router infrastructure to initiate a WebRTC connection that is protected by a ECDH symmetric key that is stored inside the relevant Keeper record. 
  2. The Keeper Gateway communicates with the Keeper Router through outbound-only WebSockets. This is described in detail at this link.
  3. The Keeper Gateway utilizes Keeper Secrets Manager APIs to retrieve the necessary secrets from the vault, including the ECDH symmetric key.
  4. For Connections, the Vault Client (using the Apache Guacamole protocol) passes data through the WebRTC connection to the Keeper Gateway that then uses Guacd to connect to the destination found in the Keeper record.
  5. For Tunneling features (port forwarding), a local port is opened up on the local device running Keeper Desktop software. Data sent to the local port is transmitted through the WebRTC connection to the Keeper Gateway and subsequently forwarded to the target endpoint defined in the Keeper record.
  6. Session recordings of connections are protected by an AES-256 encryption key ("recording key") which is generated on the Keeper Gateway on every session. The recording key is additionally wrapped by a HKDF-derived AES-256 resource key.

Zero-trust connection and tunnel security

Remote Browser Isolation security

Keeper Remote Browser Isolation technology protects access to internal web applications or any other web-based asset through the Keeper Connection Manager Docker container or through the Keeper Gateway.

Using the Connection Manager Docker container method:

  1. The user authenticates into the Keeper Connection Manager web service, hosted by the customer in a Docker container.
  2. The user launches a Remote Browser Isolation session to the target web application. Between the user's browser and the hosted Keeper Connection Manager web service, communication over HTTPS is protected by Let's Encrypt or the customer's specified certificate.
  3. On the Keeper Connection Manager Docker container, an embedded version of Chromium is executed within a sandbox, the target website is rendered using a local display driver that streams the visible content of the page in real time to the user's web browser using the Apache Guacamole protocol.

Using the Keeper Gateway with the Keeper Web Vault or Desktop App:

  1. The Vault Client application communicates to the Keeper Router infrastructure to initiate a WebRTC connection that is protected by a ECDH symmetric key that is stored inside the relevant Keeper record. 
  2. The Keeper Gateway communicates with the Keeper Router through outbound-only WebSockets. This is described in detail at this link.
  3. The Keeper Gateway utilizes Keeper Secrets Manager APIs to retrieve the necessary secrets from the vault, including the ECDH symmetric key.
  4. The Vault Client (using the Apache Guacamole protocol) passes data through the WebRTC connection to the Keeper Gateway that then uses HTTP or HTTPS to connect to the destination found in the Keeper record.
  5. Session recordings of connections are protected by an AES-256 encryption key ("recording key") which is generated on the Keeper Gateway on every session. The recording key is additionally wrapped by a HKDF-derived AES-256 resource key.
Remote Browser Isolation security

Browser Isolation protection

Several security measures are activated by using the Remote Browser Isolation protocol:

  1. The web application endpoint being protected is wrapped by a layer of TLS encryption from the Keeper Connection Manager gateway to the user's local device, regardless of whether TLS is used between gateway and endpoint - protecting against MITM attack or packet inspection on the user's local network.
  2. The remote browsing session is visually projecting the interaction to the user's local device using a canvas and graphical rendering. No JavaScript code or HTML from the target website is executed on the user's local machine.
  3. Since no website code from the target is executed locally and the local browser cannot directly access the underlying application code, the isolated web application is protected against attack vectors such as reflected cross-site scripting vulnerabilities, cross-site request forgery, and API abuse.
  4. The end user can be restricted from performing data exfiltration from the target endpoint through URL and resource request filtering. File uploads and downloads are restricted, even if the target web application would otherwise permit the action.
  5. The browsing session and keystrokes can be recorded for auditing and compliance purposes, providing the ability to perform forensic analysis of web-based sessions.
  6. Credentials that are auto-filled from the gateway into the target web application are never transmitted to the user's device, and are not accessible by the user on their local device, protecting against secret leakage.
  7. Through firewall policies, the user can be required to access the target web application only through the remote browser isolation session, reducing the threat from a compromised browser or local device malware.
  8. The target web application becomes protected by Single Sign-On and/or MFA authentication, even if the application does not natively support it. Keeper protects access to the vault and any Remote Browser Isolation sessions through the advanced authentication methods described in this document.
Browser Isolation protection

BreachWatch®

Keeper использует управляемую автономную архитектуру на AWS под названием BreachWatch, которая физически отделена от API Keeper и записей пользователей.

Физический модуль аппаратной безопасности (HSM) на серверах BreachWatch используется для обработки, хэширования и хранения миллиардов уникальных паролей в «Даркнете», собранных в результате утечек данных. Все пароли обрабатываются на серверах Keeper с использованием метода хеширования HMAC_SHA512 и хешируются с помощью HSM с использованием неэкспортируемого ключа.

Когда на клиентском устройстве активирована функция BreachWatch, хэш HMAC_SHA512 генерируется на основе каждой записи и отправляется на сервер. На сервере создается второй хэш с использованием HMAC_SHA512 посредством HSM с использованием неэкспортируемого ключа. «Хеши хэшей» сравниваются, чтобы определить, были ли взломаны учетные данные.

Архитектура BreachWatch создана с прицелом на предотвращение корреляции взломанного пароля с паролем в хранилище пользователя, независимо от размера утечки данных. При обнаружении взломанного пароля используется физический модуль HSM, чтобы гарантировать, что хеширование может выполняться только онлайн – для предотвращения любой атаки методом подбора.

  • Пароли дважды хешируются с помощью HMAC_512: один раз на клиентском устройстве с помощью «перца» и один раз в AWS CloudHSM с использованием аппаратного модуля безопасности с неэкспортируемым ключом.
  • HMAC_512 используется из-за того, что он использует надежную функцию хеширования и секретный ключ, не подлежащий экспорту. Как следствие, автономная атака на хеши невозможна.
  • Код аутентификации сообщения (MAC) с применением криптографической хэш-функции расширяет возможности использования хэш-функций. Результаты хеширования зависят не только от сообщения, но и от вставки, которая может быть секретным ключом.

BreachWatch на 100% создан Keeper с использованием каналов данных SpyCloud, но Keeper никогда не отправляет какие-либо данные третьим лицам.

Модель Keeper BreachWatch

Domain scanning

Пользователи BreachWatch загружают список взломанных доменов и осуществляют локальную проверку.

Username and password scanning

Клиентские устройства подключаются к BreachWatch и загружают список хешированных имен пользователей (или паролей) вместе с выбранным клиентом случайным идентификатором (отдельные идентификаторы для служб проверки имени пользователя и пароля). Эти хэши паролей обрабатываются при загрузке с помощью HMAC с использованием аппаратного модуля безопасности (HSM) и секретного ключа, хранящегося в HSM, помеченного как неэкспортируемый (это означает, что HSM будет обрабатывать HMAC только локально, и ключ не может быть извлечен). Эти входные данные HMAC (имена пользователей или пароли) сравниваются с наборами взломанных данных с использованием того же HMAC и ключа. О любых совпадениях сообщается на клиентское устройство. Любые несовпадающие значения сохраняются вместе с анонимным идентификатором клиента.

По мере добавления в систему новых взломанных имен пользователей и паролей они обрабатываются с помощью HMAC в HSM, добавляются в набор данных BreachWatch и сравниваются с сохраненными значениями клиента. При обнаружении совпадения отправляется оповещение для соответствующего идентификатора клиента.

Клиентские устройства периодически обращаются к BreachWatch, сообщая свои идентификаторы BreachWatch. Все сгенерированные ранее сообщения загружаются на клиентские устройства, и клиентские устройства передают все новые или измененные имена пользователей и пароли, которые обрабатываются тем же образом.

Безопасность служб BreachWatch обеспечивается по принципу доверия при первом использовании (TOFU). Иными словами, клиентские устройства должны предполагать, что сервер BreachWatch не является вредоносным (то есть, не скомпрометирован злоумышленником), когда клиентское устройство передает хэшированные данные. Как только эти данные обработаны с HSM, они становятся защищенными от попыток оффлайн-взлома. Иными словами, если злоумышленник и украдет набор данных хранимых клиентских данных, он не сможет взломать эти данные в режиме оффлайн без ключа HMAC, хранящегося в HSM.

Если обнаружен взлом пароля, клиентское устройство отправляет хешированную комбинацию имени пользователя и пароля на серверы BreachWatch, которые затем выполняют то же самое сравнение хэшей в HMAC, чтобы определить, была ли взломана комбинация имени пользователя и пароля, и если да, то возвращаются домены, связанные с этими взломами, чтобы клиентское устройство могло определить, совпадает ли вся комбинация имя пользователя+пароль+домен. Если все три параметра на клиентском устройстве совпадают, пользователь получает предупреждение о взломе.

BreachWatch for business and enterprise customers

Когда BreachWatch активирован для корпоративных и бизнес-клиентов, хранилища конечных пользователей сканируются автоматически каждый раз, когда пользователь входит в систему с помощью Keeper. Сводные данные BreachWatch, сканируемые на устройстве пользователя, шифруются с помощью корпоративного открытого ключа и расшифровываются администратором предприятия при входе в консоль администрирования Keeper. Эта зашифрованная информация включает адрес электронной почты, количество записей с высоким риском, количество записей с решенными проблемами безопасности и количество проигнорированных записей. Администратор Keeper может просматривать сводную статистику на уровне пользователя в пользовательском интерфейсе консоли администрирования.

Event logging and reporting

При интеграции с модулем расширенной отчетности и предупреждений устройства конечных пользователей Keeper также могут быть дополнительно настроены для передачи подробных данных о событиях в реальном времени в сторонние SIEM-решения и интерфейс отчетности консоли администрирования Keeper. Данные о событии содержат адрес электронной почты, UID записи, IP-адрес и информацию об устройстве (события не включают в себя какие-либо расшифрованные данные записи, поскольку Keeper является платформой с нулевым разглашением и не может расшифровать пользовательские данные).

По умолчанию подробные данные о событиях BreachWatch не отправляются в модуль расширенной отчетности и предупреждений или в любые подключенные внешние системы журналирования. Чтобы активировать отправку данных BreachWatch на уровне событий в модуль расширенной отчетности и предупреждений, необходимо включить политику применения для события на экране конкретной роли > Политики принудительного применения > Функции хранилища. После активации клиентские устройства конечных пользователей начнут отправлять данные об этом событии. Поскольку интеграция со сторонними решениями SIEM передается из серверной части Keeper в целевую систему SIEM, эта информация о событии доступна для чтения целевой SIEM и может использоваться для определения того, какие записи и какие пользователи в организации имеют пароли с высоким риском. Если администратор Keeper не желает передавать данные о событиях на уровне записей в модуль расширенных отчетов и предупреждений Keeper, этот параметр можно оставить отключенным.

SplunkSplunk Sumo LogicSumo Logic LogRhythmLogRhythm Syslog PushSyslog Push IBM QRadarIBM QRadar Azure SentinelAzure Sentinel AWS S3 BucketAWS S3 Bucket DevoDevo DatadogDatadog Logz.ioLogz.io ElasticElastic

Офлайн-режим

Офлайн-режим позволяет пользователям иметь доступ к своему хранилищу, когда они не могут подключиться в режиме онлайн к Keeper или к своему поставщику удостоверений единого входа. Эта возможность доступна в мобильном приложении Keeper, настольном приложении и веб-хранилище во всех браузерах.

Офлайн-режим

Это осуществляется путем создания копии хранилища на локальном устройстве пользователя. Данные хранилища, хранящиеся в офлайн-режиме, зашифрованы AES-GCM с помощью 256-битного «клиентского ключа», который генерируется случайным образом и защищается PBKDF2-HMAC-SHA512 с 1 000 000 итераций и случайной солью. Соль и итерации хранятся локально. Когда пользователь вводит свой мастер-пароль или использует биометрические данные, ключ извлекается с использованием соли и итераций, и предпринимается попытка дешифровать клиентский ключ. Затем клиентский ключ используется для дешифровки кэша сохраненных записей. Если в хранилище пользователя включена защита посредством самоуничтожения, при 5 неудачных попытках входа в систему будут автоматически удалены все локально хранящиеся данные хранилища. Для бизнес-клиентов офлайн-доступ может быть ограничен администратором Keeper на основе политик применения ролей.

Emergency access (digital legacy)

Индивидуальные и семейные планы Keeper позволяют пользователям добавлять до пяти контактов для экстренных случаев, чтобы предоставить доступ к хранилищу в случае смерти пользователя или другой чрезвычайной ситуации. Пользователь указывает время ожидания, и по его истечении контакт для экстренных случаев получит доступ к хранилищу пользователя. Предоставление общего доступа к хранилищу контактному лицу в экстренных ситуациях не нарушает принцип нулевого разглашения, и мастер-пароль пользователя никогда не разглашается. Кроме того, используется 2048-битное шифрование RSA с 256-битным ключом AES. Чтобы принять информацию, контакт для экстренных случаев должен иметь учетную запись Keeper.

Функция экстренного доступа

Network architecture

Keeper использует AWS в Северной Америке (коммерческая или GovCloud), Европе, Австралии, Японии и Канаде в целях локализованной конфиденциальности данных и географической изоляции для размещения и использования решения и архитектуры Keeper. Использование AWS позволяет Keeper беспрепятственно масштабировать ресурсы по требованию и предоставлять клиентам самую быструю и безопасную среду облачного хранения. Keeper работает как в мультизонной, так и в мультирегиональной среде, чтобы максимизировать время безотказной работы и обеспечить максимально быстрое время ответа клиентам. Корпоративные клиенты могут арендовать решение Keeper в любом предпочитаемом основном регионе. Данные клиентов и доступ к платформе ограничены этим конкретным регионом.

Cloud authentication

Компания Keeper создала передовую модель облачной аутентификации и сетевых коммуникаций, обеспечивающую высочайший уровень конфиденциальности, безопасности и доверия. Вот несколько ключевых особенностей модели аутентификации:

  • Мастер-пароль никогда не передается по сетевому уровню. В отличие от большинства услуг SaaS, учетные данные для входа никогда не покидают устройство. PBKDF2 используется на локальном устройстве для получения 256-битного ключа AES, используемого для дешифрования. Второй ключ PBKDF2 генерируется локально, а затем хэшируется с помощью HMAC_SHA256 с целью получения токена аутентификации. Защищенное облачное хранилище Keeper придерживается принципа нулевого разглашения по отношению к ключу дешифрования пользователя.
  • Трафик между клиентским устройством и облаком Keeper не может быть перехвачен или дешифрован. Keeper использует привязывание ключей и дополнительные уровни шифрования сетевого уровня (ключи передачи) между устройством и серверами Keeper, чтобы предотвращать атаки типа MITM.
  • На новых устройствах невозможно войти в учетную запись, минуя этап проверки устройства. Без прохождения этого этапа невозможно выполнить вход в учетную запись. Keeper поддерживает несколько типов проверки устройства, зависящих от используемой схемы аутентификации.
  • Двухфакторная аутентификация выполняется после подтверждения устройства, перед вводом мастер-пароля. Если у пользователя настроена или включена двухфакторная аутентификация, этот шаг должен быть выполнен до ввода мастер-пароля.
  • Ввод мастер-пароля не может быть выполнен до тех пор, пока не будет успешно пройден этап проверки устройства и двухфакторной аутентификации. Пользователь не может перейти к этапу ввода мастер-пароля без предварительной проверки устройства и двухфакторной аутентификации. Такой расширенный процесс аутентификации обеспечивает защиту от нескольких типов атак, включая атаку методом подбора, распыление паролей, перечисление и MITM.

Encryption in transit

Хранилище Keeper Cloud Security Vault защищено API-интерфейсами, которые проверяются посредством авторизации на клиентском устройстве. Клиент получает токен сеанса при входе в систему и отправляет его при каждом вызове API. Токен сеанса отслеживается на сервере. Вход осуществляется посредством мастер-пароля, возобновления сеанса или аутентификации SAML 2.0 SSO.

При использовании мастер-пароля клиентское устройство получает 256-битный «ключ аутентификации» с использованием PBKDF2-HMAC-SHA256 с 1 000 000 итераций и 128-битной случайной солью. «Хеш аутентификации» генерируется путем хеширования ключа аутентификации с использованием SHA-256. Для входа в систему хэш аутентификации сравнивается с хешем аутентификации, хранящимся в Cloud Security Vault. После входа в систему на сервере генерируется токен сеанса, который отправляется клиенту для использования клиентским устройством для последующих запросов API. Сеанс должен быть активным, чтобы можно было продолжать использовать связь между клиентом и сервером.

Keeper использует 128- и 256-битные версии протокола TLS для шифрования всех данных, передающихся между клиентским приложением и облачным хранилищем Keeper.

Keeper развертывает сертификаты TLS, подписанные DigiCert с использованием алгоритма SHA2, наиболее безопасного алгоритма подписи, предлагаемого в настоящее время коммерческими центрами сертификации. SHA2 значительно более безопасен, чем более широко используемый SHA1, который может быть дешифрован из-за математической слабости, выявленной в алгоритме. SHA2 помогает защититься от выдачи поддельных сертификатов, которые злоумышленник может использовать для подмены веб-сайта.

Keeper также поддерживает Certificate Transparency (CT), инициативу Google по созданию публично проверяемой записи сертификатов, подписанных центрами сертификации. CT помогает защититься от выдачи сертификатов неавторизованными организациями. CT в настоящее время поддерживается в последних версиях веб-браузеров Chrome, Safari и Brave. Дополнительную информацию о Certificate Transparency можно найти по адресу: https://certificate.transparency.dev/. Keeper поддерживает следующие наборы шифров 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

Клиентские устройства Keeper на iOS и Android также используют привязывание ключей — механизм безопасности, предотвращающий выдачу себя за другое лицо злоумышленниками, использующими поддельные цифровые сертификаты.

Cross-Site Scripting (XSS) attack prevention

Веб-хранилище Keeper обеспечивает выполнение строгой политики безопасности контента, которая ограничивает происхождение исходящих запросов и препятствует выполнению всех скриптов, за исключением скриптов, явно исходящих от Keeper, включая встраиваемые скрипты и атрибуты обработки событий HTML, сокращая или устраняя большинство направлений атак посредством межсайтового скриптинга.

Доступ к доменным именам Keeper ограничен протоколом HTTPS с TLS 1.3 и обеспечивается механизмом HTTP Strict Transport Security. Это предотвращает широкий спектр атак с перехватом пакетов и модификацией данных и атак типа «человек посередине».

В браузерном расширении Keeper запрашиваются у пользователей их учетные данные хранилища из области фрейма страницы. Вход в расширение происходит в области панели инструментов расширения браузера. Вход в хранилище через веб-браузер всегда будет происходить либо в домене keepersecurity.com, keepersecurity.eu, keepersecurity.com.au, keepersecurity.jp, keepersecurity.ca или govcloud.keepersecurity.us, либо с панели инструментов расширения браузера Keeper, которая находится за пределами страницы контента.

Браузерное расширение Keeper помещает iFrame в формы входа на веб-страницу, чтобы гарантировать, что ни один вредоносный веб-сайт не получит доступ к внедренному контенту. Содержимое записей, внедренное в iFrames, также ограничивается записями хранилища, хранящимися в хранилище пользователя, которые соответствуют домену целевого веб-сайта. Keeper не будет предлагать автоматический ввод данных для логина и пароля, если домен веб-сайта не совпадает с доменом веб-сайта в записи в хранилище Keeper. Расширение не будет отображать записи, если они не соответствуют корневому домену адреса веб-сайта.

Сторонние браузерные расширения могут иметь повышенные уровни разрешений в веб-браузерах и могут получать доступ к информации внутри страницы. Поэтому администраторам Keeper рекомендуется запретить пользователям устанавливать сторонние браузерные расширения из соответствующего магазина приложений для браузера.

Биометрика

Keeper изначально поддерживает Windows Hello, Touch ID, Face ID и биометрию Android. Клиенты, которые обычно входят в свое хранилище Keeper с помощью мастер-пароля или корпоративного единого входа (SAML 2.0), также могут входить на своих устройствах с помощью биометрических данных. Биометрия должна быть включена администратором Keeper в ролевой политике. В таком случае офлайн-доступ также возможен с помощью биометрических данных, если эта функция активирована.

Когда на устройстве включен биометрический вход в систему, ключ генерируется случайным образом локально и сохраняется в защищенном анклаве (например, в «Связке ключей» или «Хранилище ключей») устройства. Ключ данных пользователя зашифрован биометрическим ключом. После успешной биометрической аутентификации ключ извлекается, и пользователь может расшифровать свое хранилище.

Связка ключей iOS, Touch ID и Face ID

Touch ID и Face ID на устройствах iOS позволяют пользователям получать доступ к своему хранилищу Keeper с помощью биометрических данных. Чтобы обеспечить эту удобную функцию, в связке ключей iOS хранится случайно сгенерированный 256-битный «биометрический ключ». Элемент «Связка ключей iOS», созданный для этой функции, не предназначен для синхронизации со «Связкой ключей iCloud» и поэтому не покинет ваше мобильное устройство iOS.

Настоятельно рекомендуется использовать сложный мастер-пароль и включить многофакторную аутентификацию, чтобы обеспечить максимальную безопасность вашего зашифрованного хранилища Keeper. Использование Touch ID и Face ID делает более удобным использование сложного мастер-пароля на мобильном устройстве iOS. Также рекомендуется установить пароль длиной более 4 цифр, чтобы защитить связку ключей iOS.

Связка ключей iOS используется iOS и приложениями для безопасного хранения учетных данных. Приложения iOS используют связку ключей iOS для хранения различной конфиденциальной информации, включая пароли веб-сайтов, ключи, номера кредитных карт и информацию Apple Pay. Keeper не использует связку ключей iOS для хранения ваших записей Keeper - все записи Keeper защищены 256-битным шифрованием AES и надежно хранятся в хранилище Keeper. Связка ключей iOS также зашифрована 256-битным шифрованием AES с использованием пароля устройства. Даже если устройство будет потеряно или украдено или злоумышленник получит физический доступ к мобильному устройству, он не сможет получить доступ к сохраненной информации Keeper. Связку ключей iOS невозможно расшифровать без пароля, а содержимое хранилища Keeper невозможно расшифровать без мастер-пароля пользователя Keeper.

Apple Watch®

Функция избранного Apple Watch позволяет просматривать избранные записи на подключенных часах Apple Watch. Записи Keeper должны быть явно включены для возможности просмотра на Apple Watch. Подключенные часы Apple Watch взаимодействуют с расширением Keeper для часов, работающем в своем выделенном замкнутом пространстве отдельно от приложения iOS Keeper. Расширение Keeper для часов также использует Связку ключей iOS в целях безопасного хранения и доступа к ключам, чтобы безопасно связываться с приложением iOS Keeper.

Keeper DNA®

Keeper DNA предоставляет способ многофакторной аутентификации с использованием умных часов. Keeper DNA использует з токены, хранящиеся в хранилище Keeper, чтобы генерировать временные пароли для многофакторной аутентификации. Запросы на аутентификацию можно одобрять и автоматически отправлять с Apple Watch (или устройства Android Wear), касаясь экрана часов, либо вводить вручную

Employee offboarding (vault transfer)

Когда для узла активируется политика передачи учетной записи, политика узла для пары открытого/закрытого ключей создается в консоли администрирования на устройстве пользователя. Ключ данных конечного пользователя (для пользователей, к которым принудительно применяется политика) шифруется с помощью открытого ключа политики, когда пользователь входит в хранилище. Закрытый ключ шифруется с помощью открытого ключа администратора, после чего администратор может расшифровать ключ принудительного применения с передачей хранилища.

При передачи хранилища администратор Keeper должен сначала заблокировать учетную запись пользователя. Затем передача хранилища может произойти немедленно с последующим удалением учетной записи пользователя. Это гарантирует, что операция не будет проведена тайно. При выполнении передачи ключ данных пользователя извлекается путем сначала дешифровки закрытого ключа принудительного применения, а затем дешифровки ключа данных пользователя. Ключ данных используется для дешифровки ключей записи, ключей групп и ключей папок.

Все шифрование выполняется на стороне клиента в консоли администрирования, и Keeper ни при каких обстоятельствах не имеет возможности дешифровать передаваемую или предоставляемую информацию. Кроме того, ключ данных клиента пользователя никогда не передается. Пользователь, удаленный из группы, общей папки или прямого предоставления, не будет получать новые данные из группы, общей папки или записи. Хотя ключи записи, папки и группы дешифруются локально для администратора во время операции, эти ключи невозможно использовать для получения доступа к базовой записи или данным папки.

Во время передачи хранилища администратор получает только зашифрованный ключ данных, зашифрованные ключи записей и зашифрованные ключи папок. Эти ключи дешифруются, а затем повторно шифруются с помощью открытого ключа целевого хранилища. Администратор никогда не получают доступа к фактическим данным записи. Keeper не шифрует данные, сохраненные клиентом, напрямую с помощью ключа данных — это происходит на устройстве.

Сохранение данных уволенных сотрудников Сохранение данных уволенных сотрудников

Сертификаты и соответствие нормативным требованиям

Keeper фанатично относится к безопасности. Keeper — это самое безопасное в мире, сертифицированное, протестированное и проверенное решение для защиты паролей и платформа управления привилегированным доступом. Keeper имеет самую продолжительную в отрасли сертификацию SOC2 и ISO. Решение Keeper сертифицировано по стандартам ISO 27001, 27017 и 27018. Keeper соответствует требованиям GDPR, CCPA, HIPAA, FedRAMP и StateRAMP, а также сертифицировано PCI DSS и TrustArc по части обеспечения конфиденциальности.

  • Команды разработчиков программного обеспечения Keeper состоят из штатных сотрудников, находящихся в США.
  • Keeper не хранит пароли, учетные данные или секреты, такие как ключи доступа, в своем исходном коде. Мы регулярно проверяем исходный код на наличие этой информации.
  • Хотя исходный код Keeper и хранится в частном порядке на GitHub Enterprise, он не предоставляет информацию, необходимую для доступа к хранилищу пользователя, поскольку шифрование данных происходит на уровне устройства. Большая часть этого кода опубликована в нашем общедоступном репозитории GitHub как часть продуктов Keeper Commander и Keeper Secrets Manager.
  • Keeper не встраивает код стороннего поставщика услуг многофакторной аутентификации в свои приложения. Вендоры Keeper не подвергались каким-либо взломам, связанным с Keeper.
  • Keeper не предоставляет третьим сторонам управление или доступ к своим центрам обработки данных AWS. Все управление осуществляют штатные сотрудники Keeper Security, являющиеся гражданами США, проживающими на территории США.
ISO 27001 SOC2 FedRAMP StateRAMP HIPAA Compliant GDPR Compliant PCI DDS Level 1 TRUSTe Level 1 FIPS 140-3

Сертификат FIPS 140-3

Keeper использует проверенные модули шифрования FIPS 140-3 для соблюдения строгих требований безопасности правительственного и государственного сектора. Шифрование Keeper сертифицировано программой проверки криптографических модулей NIST (CMVP) и подтверждено на соответствие стандарту FIPS 140 аккредитованными сторонними лабораториями.

Keeper выдан сертификат № 3976 в соответствии с NIST CMVP

Соответствие требованиям ITAR

Keeper Security Government Cloud (KSGC) поддерживает соблюдение Правил международной торговли оружием США (ITAR). Компании, на которых распространяются экспортные правила ITAR, должны контролировать непреднамеренный экспорт, ограничивая доступ к защищенным данным гражданами США и ограничивая физическое местонахождение защищенных данных Соединенными Штатами Америки.

Среда KSGC, отвечающая требованиям FedRAMP на умеренном уровне воздействия, поддерживает требования ITAR благодаря следующему:

  • Полностью соответствующее требованиям хранилище данных размещено на AWS GovCloud и ограничивается размещением в США.
  • KSGC обеспечивает безопасное шифрование данных при передаче и хранении.
  • Безопасность с нулевым разглашением и нулевым доверием в сочетании с детальными разрешениями позволяет организациям гарантировать, что только утвержденный персонал может получать доступ к конфиденциальным данным.
  • Надежные функции отчетности о соответствии требованиям обеспечивают ведение отслеживаемого электронного контрольного журнала всех выполненных действий и введенных данных.
  • Отдельная команда по сопровождению клиентов состоит из граждан США, специально обученных безопасному обращению с данными, контролируемыми экспортными правилами и ITAR, без какой-либо поддержки за пределами США.

Среда Keeper FedRAMP была проверена независимой сторонней оценочной организацией (3PAO) на подтверждение наличия надлежащих средств контроля для поддержки программ экспортного соответствия клиентов и продолжает проходить ежегодный аудит, необходимый для поддержания соответствия требованиям.

Дополнительная информация о ITAR.

Соответствует требованиям FedRAMP

Keeper Security Government Cloud (KSGC) — платформа KSI для управления паролями и обеспечения кибербезопасности для государственных учреждений. KSGC является авторизованным поставщиком FedRAMP на уровне умеренного воздействия (Moderate Impact Level), размещенным в AWS GovCloud (США). KSGC можно найти на торговой площадке FedRAMP.

Федеральная программа управления рисками и авторизацией (FedRAMP) — это программа федерального правительства США, обеспечивающая стандартизированный подход к оценке безопасности, авторизации и непрерывному мониторингу облачных продуктов и сервисов. FedRAMP стремится ускорить внедрение современных облачных решений государственными учреждениями, уделяя особое внимание безопасности и защите федеральной информации. Узнайте подробнее о FedRAMP.

Соответствует требованиям StateRAMP

StateRAMP разработана примерно через десять лет после FedRAMP с целью стимулирования внедрения безопасных облачных решений на уровне штатов и местных органов власти. Получение авторизации StateRAMP обычно представляет собой двухлетний процесс, который был ускорен посредством программы взаимности благодаря авторизации Keeper в FedRAMP.

Соответствует требованиям SOC 2

Записи в клиентских хранилищах защищены с использованием строгих методов внутреннего контроля с тщательным отслеживанием. Keeper уже более десяти лет сертифицирован как соответствующий требованиям SOC 2 Type 2 в соответствии с AICPA Service Organization Control. Соблюдение SOC 2 помогает обеспечить безопасность хранилищ пользователей путем внедрения стандартизированных средств контроля, определенных в рамках принципов надежности AICPA Trust Service Principles.

Сертификаты ISO

Решение Keeper сертифицировано по стандартам ISO 27001, 27017 и 27018, охватывающим систему управления информацией и облачную инфраструктуру Keeper Security, которая поддерживает платформу Keeper Enterprise. Сертификаты ISO компании Keeper покрывают управление и эксплуатацию цифрового хранилища и облачных сервисов, контроль облачной безопасности, контроль конфиденциальности данных, разработку программного обеспечения и приложений, а также защиту цифровых активов как для цифрового хранилища, так и для облачных сервисов.

Соответствие требованиям части 11 раздела 21 CFR FDA

Keeper соответствует требованиям части 11 раздела 21 кодекса федеральных нормативных актов (CFR), которые применяются к ученым, работающим в строго регулируемых средах, в том числе к исследователям, проводящим клинические испытания. Эти требования отражают критерии Управления США по санитарному надзору за качеством пищевых продуктов и медикаментов (FDA), в соответствии с которыми электронные записи и подписи считаются заслуживающими доверия, надежными и эквивалентными бумажным записям с рукописными подписями. В частности, ученые должны убедиться, что все используемое ими программное обеспечение соответствует требованиям части 11 раздела 21 CFR, в отношении следующего:

Средства контроля безопасности для идентификации пользователей – Keeper соответствует требованиям части 11 раздела 21 CFR к функциям безопасности, которые ограничивают доступ пользователей и их привилегии, включая обеспечение того, чтобы у всех пользователей были уникальные имена пользователей и пароли, возможность обнаружения и предотвращения несанкционированного доступа к системе и возможность блокировки скомпрометированных учетных записей.

Detailed audit trail

Во время проверок FDA регулирующие органы требуют от исследователей предоставления аудиторского журнала с подробной хронологической записью всех операций. Функции отчетности Keeper о соответствии требованиям позволяют исследователям легко создавать отслеживаемые электронные журналы аудита.

Электронные подписи

Если для документа требуется юридически обязывающая электронная подпись, согласно части 11 раздела 21 CFR требуется, чтобы подпись была привязана к уникальному логину и паролю или биометрической идентификации. Keeper поддерживает это требование, предоставляя исследователям возможность гарантировать, что все пользователи имеют уникальные имена пользователей и пароли, надежно хранящиеся в цифровом хранилище пользователя, к которому может получить доступ только сам пользователь.

Дополнительную информацию о 21 CFR, часть 11 можно найти здесь.

Protection of patient medical data

Программное обеспечение Keeper отвечает мировым стандартам по защите медицинских данных пациентов, включая, без ограничения, HIPAA (Health Insurance Portability and Accountability Act) и DPA (Data Protection Act).

Соответствие требованиям и соглашение о деловом партнерстве HIPAA

Keeper является сертифицированной SOC2 и ISO 27001 платформой обеспечения безопасности с нулевым разглашением данных и соответствует требованиям HIPAA. Поддерживается строгое соблюдение требований и контроль, охватывающий неприкосновенность частной жизни, конфиденциальность, целостность и доступность. При такой архитектуре безопасности Keeper не может расшифровать, просмотреть или получить доступ к какой-либо информации, включая ePHI, хранящейся в хранилище пользователя Keeper. По вышеуказанным причинам Keeper не является деловым партнером, как это определено в Законе о переносимости и подотчетности медицинского страхования (HIPAA), и, следовательно, на него не распространяется действие Соглашения о деловом партнерстве.

Чтобы подробнее узнать о дополнительных преимуществах для поставщиков медицинских услуг и компаний медицинского страхования, прочтите весь документ Раскрытие данных безопасности и посетите наше Руководство для предприятий.

Сертификация FSQS-NL

Компания Keeper Security EMEA Limited сертифицирована в соответствии с квалификационной системой Hellios Financial Services Qualification System-Netherlands (FSQS-NL), которая признает самые высокие стандарты безопасности, качества и инноваций в Нидерландах. Этот стандарт демонстрирует соответствие требованиям Управления финансового надзора и Управления пруденциального надзора для обеспечения надежности программного обеспечения Keeper Enterprise для крупных банков и финансовых учреждений.

Экспортная лицензия Министерства торговли США на условиях EAR

Решение Keeper сертифицировано Бюро промышленности и безопасности Министерства торговли США под контрольным номером 5D992 по классификации экспортных товаров в соответствии с Правилами экспортного контроля (EAR).
Для получения дополнительной информации о EAR: https://www.bis.doc.gov

24x7 remote monitoring

Keeper контролируется 24x7x365 штатными сотрудниками DevOps и глобальной сторонней сетью мониторинга, чтобы гарантировать доступность нашего веб-сайта и хранилища Cloud Security Vault по всему миру.

Если у вас есть вопросы относительно раскрытия даных безопасности, свяжитесь с нами.

Phishing or spoofed emails

Если вы получили электронное письмо, предположительно отправленное от Keeper Security, и не уверены, так ли это на самом деле, это может быть «фишинговое письмо», в котором подделан адрес электронной почты отправителя. В этом случае электронное письмо может содержать ссылки на веб-сайт, похожий на KeeperSecurity.com, но не являющийся нашим сайтом. Веб-сайт может запросить у вас мастер-пароль Keeper Security или попытаться установить нежелательное программное обеспечение на ваш компьютер в попытке украсть вашу личную информацию или получить доступ к вашему компьютеру. Подобные электронные письма могут также содержать ссылки, ведущие на другие потенциально опасные веб-сайты. Сообщение также может содержать вложения, которые обычно содержат нежелательное программное обеспечение, называемое «вредоносным ПО». Если вы не уверены в подлинности пришедшего электронного письма, не переходя по каким-либо ссылкам и не открывая никаких вложений.

Если вы хотите сообщить об электронном письме, якобы отправленном от Keeper, которое, по вашему мнению, является поддельным, или у вас есть другие вопросы в связи с безопасностью свяжитесь с нами..

Hosting infrastructure certified to the strictest industry standards

Веб-сайт и облачное хранилище Keeper работают в безопасной облачной инфраструктуре Amazon Web Services (AWS). Облачная инфраструктура AWS, используемая для размещения архитектуры Keeper, получила следующие аттестаты и сертификаты:

SOC2 PCI Compliant FIPS 140-3 ISO 27001 FedRAMP StateRAMP

Vulnerability reporting and bug bounty program

Keeper Security занимается разработкой самого безопасного решения для управления паролями и привилегированным доступом. Мы стремимся защищать конфиденциальность и персональные данные своих клиентов. Миссия Keeper заключается в создании самой надежной в мире инновационной платформы обеспечения безопасности, и мы считаем, что сообщения об ошибках, поступающие от мирового сообщества исследователей безопасности, имеют решающее значение для обеспечения безопасности продуктов и услуг Keeper.

Keeper проводит обширное внутреннее и внешнее тестирование, включая тесты на проникновение, проводимые NCC Group и CyberTest с полным доступом к исходному коду. Keeper проводит свою программу раскрытия уязвимостей в партнерстве с Bugcrowd. В совокупности это приносит пользу всей отрасли и, более того, служит общественному благу.

Рекомендации

Политика раскрытия уязвимостей Keeper устанавливает ожидаемые нормы при работе с хакерами доброй воли, а также то, что вы можете ожидать от нас.

Если тестирование безопасности и отчетность проводятся в соответствии с руководящими принципами данной политики, мы:

  • Считаем тестирование выполненным в соответствии с Законом о компьютерном мошенничестве и злоупотреблениях.
  • Считаем, что тестирование подпадает под действие DMCA, и мы не будем предъявлять вам иск за обход каких-либо мер безопасности или технологического контроля.
  • Считаем тестирование законным и не будем преследовать вас или поддерживать какие-либо юридические действия, связанные с этой программой, против вас.
  • Будем сотрудничать с вами, чтобы быстро понять и решить проблему.
  • Публично признаем ваш вклад, если вы первым сообщите о проблеме и внесете изменения в код или конфигурацию в зависимости от проблемы.

Если в какой-либо момент у вас возникнут сомнения или вы не будете уверены в проведении тестирования способом, соответствующим руководящим принципам и сфере применения настоящей политики, свяжитесь с нами по адресу security@keepersecurity.com, прежде чем продолжить.

С целью поощрения тестирования безопасности с добрыми намерениями и раскрытия обнаруженных уязвимостей, мы просим вас:

  • Не нарушайте конфиденциальность пользователей, не приводите к неудобству работы пользователей, не нарушайте работу производственных или корпоративных систем и не уничтожайте данные.
  • Проводите исследования только в рамках программы раскрытия уязвимостей Bugcrowd, ссылка на которую приведена ниже, и не трогайте системы и действия, выходящие за рамки этой программы.
  • Немедленно свяжитесь с нами по адресу security@keepersecurity.com, если во время тестирования вы обнаружите какие-либо пользовательские данные.
  • Предоставьте нам достаточно времени для анализа, подтверждения и решения сообщенной проблемы, прежде чем публично раскрывать любые обнаруженные уязвимости.

Подавайте свои отчеты здесь: https://bugcrowd.com/keepersecurity

Прозрачность

Keeper не просто заботится о безопасности; мы относимся к этому фанатично. Вот почему мы делаем каждую деталь нашей модели шифрования доступной для общественности. Мы считаем, что наши клиенты заслуживают того, чтобы знать о каждом шаге, который мы предпринимаем для обеспечения безопасности их данных в условиях постоянно меняющейся среды кибербезопасности.

Модель Keeper шифрования с нулевым доверием и нулевым разглашением данных гарантирует, что даже в худшем случае ваше хранилище Keeper будет защищено, и мы постоянно проводим тесты безопасности, чтобы гарантировать, что мы остаемся лучшим решением для защиты наиболее ценных ваших данных.

Product documentation

Портал документации Keeper, содержащий руководства по продуктам, техническую информацию, примечания к выпускам и руководства для конечных пользователей, доступен по этой ссылке.

Product release notes

Чтобы повысить прозрачность, Keeper публикует подробные примечания к выпускам на каждой платформе.

System status

Состояние системы в реальном времени можно найти здесь.

Pусский (RU) Связь с нами