Доступ к электронной почте подрядчиков в эпоху Mailbird: что предоставить, что удержать, когда отозвать

Понимание рисков доступа подрядчиков к электронной почте

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

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

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

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

Регулирующие требования: защита данных

Электронная почта содержит личные данные и конфиденциальную деловую информацию, что влечет за собой нормативные обязательства при доступе подрядчиков к почтовым ящикам с данными потребителей, финансовой информацией или медицинскими данными. Руководство Федеральной торговой комиссии США «Защита личной информации» описывает надежный план безопасности данных, основанный на пяти принципах: инвентаризация, минимизация, защита, удаление и планирование. FTC явно включает такие меры электронной безопасности, как шифрование, ограничение доступа и безопасная утилизация — все они регулярно применяются на уровне электронной почты.

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

Человеческий фактор и сложности при завершении работы

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

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

Как архитектура Mailbird влияет на управление доступом подрядчиков

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

Модель локального хранения и размещение данных

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

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

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

Зависимости аутентификации и OAuth 2.0

Ключевым изменением, влияющим на управление доступом подрядчиков через настольные клиенты, является отказ крупных провайдеров от базовой аутентификации в пользу OAuth 2.0. Согласно руководству Mailbird по контролю доступа сторонних приложений, Google прекратил поддержку базовой аутентификации для Gmail и Google Workspace 14 марта 2025 года, требуя, чтобы все подключения IMAP, POP, SMTP, CalDAV и CardDAV осуществлялись через OAuth 2.0. Microsoft ввёл аналогичный график, включая полное прекращение базовой аутентификации для Exchange Online и Microsoft 365 к 30 апреля 2026.

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

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

Управление несколькими аккаунтами

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

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

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

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

Реализация принципа наименьших привилегий через ролевой доступ

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

В среде Mailbird это часто означает предоставление подрядчикам доступа к специализированным ролевым почтовым аккаунтам, а не к личным почтовым ящикам внутреннего персонала. Согласно обсуждениям сообщества Spiceworks о лучших практиках Microsoft 365, организации должны использовать общие почтовые ящики или адреса на основе ролей (например, company-HR@ или company-AP@) вместо личных электронных адресов сотрудников, занимающих временные должности, чтобы упростить процессы приема и увольнения и одновременно поддерживать учетность.

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

Требования к надежной аутентификации

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

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

Модели доступа: прямые аккаунты, делегирование и гостевой доступ

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

Когда делегат отправляет сообщение, отображается его адрес электронной почты, что обеспечивает прозрачность, а настройки безопасности Google Account остаются недоступными для делегатов. Предоставление подрядчику доступа через делегирование позволяет управлять рабочим процессом почтового ящика без полного владения аккаунтом; Mailbird можно использовать в качестве клиента делегированного аккаунта после настройки соответствующего доступа в веб-интерфейсе Gmail.

Согласно документации по общим почтовым ящикам Microsoft 365, общие почтовые ящики позволяют множеству внутренних пользователей иметь доступ к адресам типа support@ или info@ без выделения отдельных лицензий. Однако Microsoft чётко указывает, что внешним пользователям, например владельцам аккаунтов Gmail, прямой доступ к совместным почтовым ящикам предоставлять нельзя; для доступа извне следует использовать группы Outlook.

При предоставлении подрядчикам доступа в Microsoft 365 организации обычно создают гостевые учетные записи в каталоге арендатора согласно документации Microsoft по гостевым пользователям, которые затем можно добавлять в Teams, SharePoint или приложения. Эти гостевые аккаунты могут участвовать в совещаниях и просматривать документы, но их возможности могут быть ограничены, а администраторы сохраняют возможность централизованно отзывать их доступ.

Договорные и управленческие меры контроля

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

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

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

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

Административный доступ и привилегированные операции

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

В контексте Mailbird административный доступ зачастую находится на уровне провайдера, а не в самом клиенте. Организациям следует ограничивать подрядчикам административные роли на уровне провайдера, такие как супер-администратор Google Workspace или глобальный администратор Microsoft 365, и предоставлять им только пользовательский или делегированный доступ к конкретным почтовым ящикам. Это соответствует рекомендациям FTC по ограничению способности сотрудников загружать несанкционированное программное обеспечение и получать доступ к конфиденциальным данным.

Крайне конфиденциальные почтовые ящики и архивы

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

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

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

Ещё одна категория возможностей, которые следует ограничить для подрядчиков, — это контроль настроек безопасности аккаунтов и механизмов восстановления. Модель делегирования Gmail является примером, позволяя делегатам управлять содержимым электронной почты, но не изменять пароль аккаунта или получать доступ к неэлектронным сервисам и конфиденциальным настройкам Google Account. Такой дизайн предотвращает возможность блокировки основного пользователя или вмешательства в настройки безопасности, такие как адреса для восстановления или устройства двухфакторной аутентификации.

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

Личное использование и смешивание данных

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

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

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

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

События для отзыва доступа

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

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

Процедуры отзыва доступа на уровне провайдера

Согласно рекомендациям Google Workspace по удалению или исключению пользователей, администраторы могут удалять одного или нескольких пользователей, при необходимости передавая данные Drive и Docs другому пользователю. Аккаунт удаляемого пользователя может быть временно приостановлен до завершения передачи данных. Через двадцать дней после удаления адрес электронной почты удаляется из Google Workspace, но администраторы могут переназначить его другому управляемому пользователю до истечения этого периода.

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

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

Отзыв OAuth-токенов и разрешений приложений

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

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

Контроль локальных данных и устройств

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

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

Аудит и постоянный контроль

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

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

Операционные модели: реализация доступа подрядчиков на практике

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

Подрядчики по краткосрочным проектам

Рассмотрим сценарий, когда организация нанимает подрядчика для работы над проектом поддержки клиентов сроком на три месяца. Подрядчику необходимо отвечать на входящие письма поддержки, участвовать в работе с тикетами и координироваться с внутренними командами. Исходя из изученных рекомендаций, организация должна создать почтовый ящик с ролевым доступом, например support@company.com, в Microsoft 365 или Google Workspace, предоставить подрядчику делегированный доступ через его именованный аккаунт, настроить Mailbird на устройстве подрядчика для доступа к делегированному почтовому ящику с использованием OAuth и многофакторной аутентификации, а также обеспечить защиту конечной точки.

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

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

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

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

Подрядчики, работающие на нескольких клиентов одновременно

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

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

Вопросы безопасности и соответствия

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

Соответствие стандартам NIST и ISO

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

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

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

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

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

Конфиденциальность и локальная обработка данных

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

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