Keeper фанатично относится к безопасности учетных данных и защите информации

Обзор

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

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

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

Платформа с нулевым доверием

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

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

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

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

Способы шифрования хранилища

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

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

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

Модель шифрования единого входа

Поток данных на устройстве при первом использовании (подключение нового пользователя)

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

Поток данных на существующих устройствах

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

Поток данных на новых и нераспознанных устройствах

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

Утверждение устройств

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

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

Безопасность на уровне устройства для SSO Connect Cloud

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

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

Шифрование хранящихся данных

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 через открытый ключ ЭК сервера.
• Для безопасного обмена секретами между пользователями используется распределение ключей эллиптической криптографии.

История версий записей

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

Keeper Business

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

Супершифрование хранящихся данных

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

Шифрование и защита резервных копий

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

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

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

Восстановление учетных записей

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

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

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

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

Корпоративные ключи шифрования

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

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

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

Проверка устройств

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

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

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

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

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

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

Конфиденциальность данных

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, которая показывает, что трекеры не установлены.

Изоляция данных

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

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

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

Шифрование при передаче данных

Хранилище 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 защищает от поддельных сертификатов, которые злоумышленник может использовать для подмены веб-сайта.

Облачная аутентификация

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

Интеграция с любым поставщиком SAML 2.0

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. Обе реализации обеспечивают архитектуру с нулевым разглашением информации и простой аутентификацией пользователей.

Мастер-пароли пользователей никогда не передаются на сетевом уровне

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

Трафик между клиентским устройством и Keeper Cloud невозможно перехватить или расшифровать

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

Новые устройство не могут быть использованы для входа в учетные записи без проверки

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

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

Если у пользователя включена или принудительно применена 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 Watch Apple Smart Watch DUO Entrust Google Authenticator Microsoft Authenticator RSA SecureID Текстовое сообщение SMS Titan Security Key TOTP Yubico

Keeper Bridge для Active Directory / LDAP

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

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

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

Аутентификация единого входа с использованием многофакторной аутентификации

Когда Keeper развернут с помощью решения единого входа, такого как Entra ID / Azure AD, Okta, Ping, Google Workspace или любого другого поставщика идентификации SAML 2.0, многофакторной аутентификацией можно полностью управлять в процессе входа в IdP. Keeper также поддерживает политики условного доступа Azure для всех типов устройств и приложений.

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

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

Аутентификация SAML 2.0 с использованием 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 — это дополнительная служба, которая выполняет мгновенное утверждение команд, утверждение устройств и назначение пользователей команды после входа в систему от поставщика идентификации единого входа.

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

Keeper SSO Connect на месте

Хотя большинство клиентов развертывают Keeper SSO Connect Cloud, те из них, кому требуется решение для локальных систем, могут развернуть SSO Connect On-Prem. Это самостоятельно размещаемая интеграция, для которой требуется сервер приложений на базе Windows или Linux. Для обеспечения безопасности с нулевым разглашением и бесперебойной работы единого входа для пользователей Keeper SSO Connect необходимо установить на сервере клиента. Среды Windows, Mac и Linux полностью поддерживаются благодаря режимам балансировки нагрузки высокой доступности (High Availability, HA) и супершифрованию с помощью аппаратных модулей безопасности.

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

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

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

=Общий доступ к записям

Пользователи 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), которое предоставляет администраторам повышенные права в отношении общих папок и записей организации. Администраторы общего доступа обладают полными правами пользователя и записи для любой общей записи, к которой у них есть доступ.

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

Keeper Secrets Manager — это платформа с нулевым разглашением для ИТ-специалистов и групп DevOps. Оно позволяет командам управлять секретами на протяжении всего жизненного цикла разработки и развертывания программного обеспечения.

Secrets Manager использует следующую модель шифрования

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

Модель Keeper Secrets Manager для ротации паролей

• В среде клиента устанавливается уникальный клиент 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-адреса, в дополнение к процессу шифрования и подписи.

Подключение с нулевым доверием и безопасность туннелей

KeeperPAM с нулевым доверием позволяет создавать облачные и локальные привилегированные сеансы, организовывать туннели, устанавливать прямой доступ к инфраструктуре и защищать удаленный доступ к базам данных без использования VPN.

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

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

После установки пользователем соединения или туннеля происходит следующее:

1. Vault Client связывается с инфраструктурой Keeper Router, чтобы инициировать WebRTC-соединение, защищенное симметричным ключом ECDH, который хранится в соответствующей записи Keeper.
2. Шлюз Keeper Gateway взаимодействует с Keeper Router только через исходящие протоколы WebSocket. Процесс подробно описан по этой ссылке.
3. Keeper Gateway использует API Keeper Secrets Manager для получения необходимых секретов из хранилища, включая симметричный ключ ECDH.
4. Для подключений Vault Client (используя протокол Apache Guacamole) передает данные через WebRTC к Keeper Gateway, который затем использует Guacd для соединения с целевым адресом, указанным в записи Keeper.
5. Для функций туннелирования (переадресация портов) на локальном устройстве, на котором работает программное обеспечение Keeper Desktop, открывается локальный порт. Данные, отправленные на локальный порт, передаются через WebRTC на Keeper Gateway и затем перенаправляются на целевую конечную точку, определенную в записи Keeper.
6. Записи сеансов соединений защищены ключом шифрования AES-256 (ключом записи), который генерируется на Keeper Gateway при каждом сеансе. Ключ записи дополнительно заключен в оболочку с помощью ключа ресурса AES-256, полученного из HKDF.

Безопасность благодаря удаленной изоляции браузера

Технология Keeper Remote Browser Isolation защищает доступ к внутренним веб-приложениям или любым другим веб-приложениям через Docker-контейнер Keeper Connection Manager или шлюз Keeper Gateway.

Использование способа Docker-контейнера Connection Manager:

1. Пользователь проходит аутентификацию в веб-службе Keeper Connection Manager, размещенной клиентом в Docker-контейнере.
2. Пользователь запускает сеанс Remote Browser Isolation для целевого веб-приложения. Между браузером пользователя и размещенной веб-службой Keeper Connection Manager обмен данными по протоколу HTTPS защищен с помощью Let's Encrypt или указанного клиентом сертификата.
3. В Docker-контейнере Keeper Connection Manager в песочнице запускается встроенная версия Chromium, а целевой веб-сайт отображается с помощью локального драйвера отображения, который передает видимое содержимое страницы в реальном времени в веб-браузер пользователя по протоколу Apache Guacamole.

Использование шлюза Keeper Gateway с web-хранилищем или настольным приложением Keeper:

1. Vault Client связывается с инфраструктурой Keeper Router, чтобы инициировать WebRTC-соединение, защищенное симметричным ключом ECDH, который хранится в соответствующей записи Keeper.
2. Шлюз Keeper Gateway взаимодействует с Keeper Router только через исходящие протоколы WebSocket. Процесс подробно описан по этой ссылке.
3. Keeper Gateway использует API Keeper Secrets Manager для получения необходимых секретов из хранилища, включая симметричный ключ ECDH.
4. Vault Client (используя протокол Apache Guacamole) передает данные через WebRTC к Keeper Gateway, который затем использует HTTP or HTTPS для соединения с целевым адресом, указанным в записи Keeper.
5. Записи сеансов соединений защищены ключом шифрования AES-256 (ключом записи), который генерируется на Keeper Gateway при каждом сеансе. Ключ записи дополнительно заключен в оболочку с помощью ключа ресурса AES-256, полученного из HKDF.

Защита изоляции браузера

При использовании протокола Remote Browser Isolation активируется несколько мер безопасности:

1. Защищаемая конечная точка веб-приложения заключается в оболочку с помощью слоя TLS-шифрования от шлюза Keeper Connection Manager до локального устройства пользователя независимо от того, используется ли TLS между шлюзом и конечной точкой. Это защищает от MITM-атак или проверки пакетов в локальной сети пользователя.
2. Сеанс удаленного просмотра веб-страниц визуально проецирует взаимодействие на локальное устройство пользователя с помощью рабочей области и графического рендеринга. На локальном компьютере пользователя не выполняется код JavaScript или HTML с целевого веб-сайта.
3. Поскольку код целевого веб-сайта не выполняется локально, а локальный браузер не может получить прямой доступ к основному коду приложения, изолированное веб-приложение защищено от таких векторов атак, как отраженные уязвимости межсайтового скриптинга, подделка межсайтовых запросов и злоупотребление API.
4. Конечный пользователь может быть лишен возможности осуществлять эксфильтрацию данных с целевой конечной точки посредством фильтрации запросов URL-адресов и ресурсов. Загрузка и скачивание файлов ограничиваются, даже если целевое веб-приложение в противном случае разрешает это действие.
5. Сеанс просмотра веб-страниц и нажатия клавиш можно записывать для целей аудита и соблюдения нормативных требований. Это позволяет проводить криминалистический анализ веб-сеансов.
6. Учетные данные, автоматически заполняемые шлюзом в целевом веб-приложении, не передаются на устройство пользователя и недоступны ему на локальном устройстве, что защищает от утечки секретов.
7. Благодаря политикам брандмауэра можно обязать пользователя получать доступ к целевому веб-приложению только через сеанс удаленной изоляции браузера, что снижает угрозу со стороны скомпрометированного браузера или вредоносного ПО на локальном устройстве.
8. Целевое веб-приложение становится защищенным с помощью аутентификации единого входа и/или многофакторной аутентификации, даже если приложение изначально их не поддерживает. Keeper защищает доступ к хранилищу и любым сеансам Remote Browser Isolation с помощью расширенных способов аутентификации, описанных в этом документе.

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 никогда не отправляет какие-либо данные третьим лицам.

Сканирование доменов

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

Сканирование имен пользователей и паролей

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

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

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

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

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

BreachWatch для бизнес- и корпоративных пользователей

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

Регистрация событий и отчетность

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

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

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

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

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

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

Экстренный доступ (цифровое наследие)

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

Сетевая архитектура

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

Облачная аутентификация

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

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

Шифрование при передаче данных

Хранилище 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 также используют привязывание ключей — механизм безопасности, предотвращающий выдачу себя за другое лицо злоумышленниками, использующими поддельные цифровые сертификаты.

Защита от атак с помощью межсайтового скриптинга (XSS)

Веб-хранилище 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), касаясь экрана часов, либо вводить вручную

Выведение сотрудников из должности (передача хранилища)

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

При передачи хранилища администратор 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, являющиеся гражданами США, проживающими на территории США.

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

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

Keeper uses FIPS 140-3 validated encryption that has been issued certificate #4743 under the 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 к функциям безопасности, которые ограничивают доступ пользователей и их привилегии, включая обеспечение того, чтобы у всех пользователей были уникальные имена пользователей и пароли, возможность обнаружения и предотвращения несанкционированного доступа к системе и возможность блокировки скомпрометированных учетных записей.

Подробный журнал аудита

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

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

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

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

Защита медицинских данных пациентов

Программное обеспечение 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

Удаленный мониторинг круглосуточно и без выходных

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

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

Фишинговые и поддельные электронные письма

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

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

Инфраструктура хостинга, сертифицированная в соответствии с самыми строгими отраслевыми стандартами

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

Программа выплаты вознаграждений за обнаружение ошибок и уязвимостей

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 будет защищено, и мы постоянно проводим тесты безопасности, чтобы гарантировать, что мы остаемся лучшим решением для защиты наиболее ценных ваших данных.

Документация по продукту

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

Заметки о выпуске продукта

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

Состояние системы

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