Как сторонние токены входа могут раскрыть метаданные вашей электронной почты

Понимание токенов OAuth и их важность для конфиденциальности электронной почты

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

Токен, выданный вашим поставщиком электронной почты, дает конкретные разрешения — называемые "областями" — которые определяют, к чему приложение может получить доступ. Приложение, запрашивающее область "mail.google.com", получает возможность читать все метаданные, связанные с каждой электронной почтой в вашем почтовом ящике, а не только содержимое сообщений. Это включает в себя адреса отправителей и получателей, темы, временные метки, информацию о вложениях и маршрутизации, показывающую, какие серверы обрабатывали каждое сообщение.

Проблема постоянства: почему смена пароля не отменяет доступ токена

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

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

Что метаданные электронной почты говорят о вас

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

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

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

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

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

Как компрометируются токены входа сторонних приложений

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

Фишинг согласия: ловушка разрешений OAuth

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

Атака работает, потому что экран согласия выглядит полностью законным — потому что он законный. Вы видите официальную страницу входа Microsoft, аутентифицируетесь с вашими реальными данными и затем сталкиваетесь с тем, что выглядит как обычный запрос разрешения. Приложение может носить что-то общее, например, "Пакет продуктivität электронной почты" или "Инструмент интеграции календаря", запрашивая, казалось бы, невинные разрешения, такие как "чтение вашей электронной почты" и "доступ к вашему календарю".

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

Кража токенов сеанса через уязвимости браузера

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

ФБР выпустило конкретные предупреждения о том, что киберпреступники систематически крадут токены сеанса из учетных записей Gmail, Outlook, Yahoo и AOL, что показывает, что эта атака переместилась от теоретической уязвимости к активной эксплуатации в больших масштабах. Как только злоумышленники овладевают вашими токенами сеанса, они могут аутентифицироваться в ваших почтовых службах, не вызывая сигналов безопасности, которые смены паролей или входы с новых устройств могли бы генерировать.

Уязвимости сторонних приложений: риск цепочки поставок

По меньшей мере 35.5% всех утечек данных в 2024 году были связаны с компрометацией третьих сторон, по сравнению с 29% в 2023 году. Когда законное стороннее приложение для электронной почты нарушается, все токены OAuth, которые пользователи предоставили этому приложению, потенциально компрометированы. Это создает ситуацию, когда вы никогда не взаимодействуете напрямую с злонамеренными актерами, но ваши метаданные электронной почты все еще раскрыты, потому что вы используете законное приложение, которое впоследствии было скомпрометировано.

Финансовые услуги и здравоохранение испытывают особенно острые риски утечек от третьих сторон, при этом розничная торговля и гостиничный бизнес имеют одни из самых высоких уровней компрометации третьих сторон, составивших 52.4% от всех их нарушений. Эти отрасли целенаправленно нацелены, потому что они обрабатывают чувствительную финансовую и медицинскую информацию, что делает учетные данные, которые они предоставляют через интеграции OAuth, чрезвычайно ценными для злоумышленников.

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

Эксплуатация токена основного обновления в корпоративных средах

Основные токены обновления (PRT), используемые в Microsoft Entra ID, представляют собой особенно серьезную уязвимость, потому что один скомпрометированный PRT может предоставить доступ ко всей экосистеме связанных приложений. В отличие от отдельных токенов доступа, которые предоставляют ограниченный доступ к конкретным услугам, PRT являются главными учетными данными, которые могут быть обменены на токены доступа к любой службе, аутентифицированной через того же провайдера идентификации.

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

Опасные OAuth-области, которые раскрывают метаданные электронной почты

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

Области доступа ко всему почтовому ящику

Наиболее опасные области — это те, которые предоставляют полный доступ к содержимому и метаданным электронной почты. Для Google Workspace область "mail.google.com" предоставляет всесторонний доступ для чтения всех электронных писем, вложений и метаданных. Для Microsoft 365 "Mail.ReadWrite" предлагает аналогичный полный доступ к чтению и записи почтовых ящиков пользователей.

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

Области изменения настроек: риск задней двери

Области, которые позволяют изменять настройки электронной почты, создают постоянные задние двери, которые продолжают экстрагировать данные даже после того, как вы обнаружите и устраните первоначальное нарушение. Область Google Workspace "gmail.settings.sharing" позволяет приложениям изменять настройки электронной почты, включая правила пересылки. "MailboxSettings.ReadWrite" от Microsoft 365 предоставляет аналогичные возможности для изменения правил пересылки и адресов электронной почты для восстановления.

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

Области только с метаданными: по-прежнему раскрывают конфиденциальную информацию

Даже области, которые кажутся ограниченными метаданными, создают значительные уязвимости в конфиденциальности. Область Google Workspace "drive.metadata.readonly" предоставляет только метаданные о файлах, а не о содержимом файлов, но эти метаданные раскрывают имена файлов, время изменения, статус совместного использования и информацию о праве собственности, которые в совокупности описывают организационную структуру и проекты.

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

Правила пересылки электронной почты: постоянная задняя дверь

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

Как правила пересылки обходят средства контроля безопасности

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

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

Раскрытие метаданных через пересланные электронные письма

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

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

Регулирование конфиденциальности метаданных электронной почты и требования к соблюдению

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

Требования GDPR и Директивы ePrivacy

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

Это решение установило, что метаданные электронной почты сотрудников могут раскрывать модели поведения, отношения и косвенно указывать на уровень производительности, что вызывает полное применение требований GDPR. Более того, ruling установил максимальные сроки хранения метаданных электронной почты в 21 день без конкретного юридического основания, требуя, чтобы хранение более 21 дня удовлетворяло определённым условиям, связанным с трудовым законодательством и мониторингом сотрудников.

Проблемы соблюдения в связи с доступом по OAuth от третьих сторон

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

Эта реальность означает, что даже правильно реализованные меры безопасности электронной почты не могут гарантировать соблюдение требований GDPR, если сторонние приложения с доступом по OAuth к электронной почте работают без адекватного контроля. Организации должны тщательно отслеживать, какие метаданные собираются, как долго они хранятся и какое юридическое основание существует для этого сбора.

Практические стратегии защиты метаданных электронной почты от утечки токенов

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

Проведите комплексный аудит OAuth

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

Для учетных записей Google посетите настройки учетной записи Google и перейдите в раздел "Безопасность" > "Приложения третьих сторон с доступом к учетной записи." Для учетных записей Microsoft перейдите в "Учетная запись" > "Конфиденциальность" > "Приложения и услуги." Тщательно просмотрите каждое приложение, спрашивая себя: использую ли я это приложение? Действительно ли ему нужен доступ к электронной почте для его основной функциональности? Когда я в последний раз его использовал?

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

Реализуйте методы аутентификации, устойчивые к фишингу

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

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

Используйте локальные почтовые клиенты для снижения доступа к метаданным провайдеров

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

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

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

Рассмотрите возможность использования провайдеров электронной почты, ориентированных на конфиденциальность

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

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

Включите ротацию токенов обновления

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

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

Реализуйте организационные политики OAuth

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

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

Следите за подозрительными правилами пересылки электронной почты

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

Для отдельных пользователей периодически проверяйте настройки вашей электронной почты, чтобы убедиться, что нет неожиданных правил пересылки. В Gmail перейдите в "Настройки" > "Пересылка и POP/IMAP". В Outlook перейдите в "Настройки" > "Почта" > "Пересылка". Если вы обнаружите правила пересылки, которые вы не создавали, немедленно удалите их и узнайте, как они были созданы.

Как архитектура Mailbird решает проблемы с метаданными токенов OAuth

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

Локальное хранение устраняет доступ к метаданным со стороны провайдеров

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

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

Реализация OAuth 2.0 без постоянного серверного доступа

Mailbird реализует аутентификацию OAuth 2.0 для подключения к почтовым провайдерам, таким как Microsoft и Google, обеспечивая преимущества безопасности токенизированной аутентификации без рисков раскрытия метаданных облачного хранилища. Когда вы подключаете свою учетную запись Gmail или Outlook к Mailbird, токены OAuth используются для синхронизации писем на вашем локальном устройстве, но Mailbird не сохраняет серверные копии этих токенов или писем, к которым они имеют доступ.

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

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

Многие профессионалы управляют несколькими почтовыми аккаунтами — личным Gmail, рабочим Outlook, специфическими адресами клиентов — и нуждаются в едином интерфейсе для их эффективного управления. Локальная архитектура Mailbird позволяет управлять несколькими аккаунтами без создания возможностей для корреляции метаданных между аккаунтами, которые создают облачные службы унифицированного почтового ящика.

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

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

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

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

Сокращенная поверхность атаки для интеграции с третьими сторонами

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

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

Часто задаваемые вопросы