Коллеги видят детали моих встреч в SOGo: как оставить им только время занятости

Если коллега открывает ваш календарь в SOGo и видит не просто «занято с 14:00 до 15:00», а тему встречи и участников — это не баг, а сочетание двух вещей: категории события, которую выбирает автор, и ролей, выданных коллеге при расшаривании календаря (начальные роли берутся из SOGoCalendarDefaultRoles). Разбираю роли, дефолт mailcow, настройку доступа конкретному коллеге и публичные ссылки.

Кейс: в дизайн-студии руководитель видел темы встреч дизайнеров с клиентами

UX/UI-студия «ИнтерфейсЛаб» — 38 рабочих мест, календари в SOGo используют плотно: встречи с клиентами, ревью макетов, созвоны с подрядчиками по интеграциям. Руководитель отдела как-то открыл календарь одного из дизайнеров, чтобы понять, свободен ли тот для срочной задачи, и увидел не просто занятый слот, а полное название встречи с указанием клиента и суммы контракта в описании — дизайнер писал название события так же подробно, как заметку самому себе, не задумываясь, что его видят коллеги.

Мы ведём для студии корпоративную почту на mailcow с SOGo в качестве веб-почты и календаря, и запрос от студии был предельно конкретный: коллеги внутри компании должны видеть, что человек занят и в какое время, но не видеть, чем именно он занят, если он сам не захотел поделиться подробностями. Это ровно тот сценарий, для которого в SOGo есть штатный, но не всегда очевидный механизм — не через права доступа «всё или ничего», а через категории событий и роли по умолчанию.

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

Категория события: Public, Confidential, Private — выбор автора встречи

В SOGo у каждого календарного события есть категория доступа — по сути, уровень приватности, который выбирает тот, кто создаёт событие: Public (обычное, открытое), Confidential (конфиденциальное) или Private (приватное). Это не то же самое, что права на весь календарь — это метка на конкретном событии, и именно от неё зависит, что увидит человек с доступом к календарю, когда наткнётся на это событие в чужом расписании.

Дальше в дело вступают роли доступа — они как раз определяют, что конкретно видно для каждой категории. Название ролей строится по формуле: сначала категория (Public, Confidential или Private), затем действие — Viewer (видит всё событие целиком), DAndTViewer (видит только дату и время, без темы и описания — сокращение от «Date and Time Viewer»), Modifier (может редактировать) или Responder (может отвечать на приглашение). Есть и дополнительные роли ObjectCreator и ObjectEraser для создания и удаления объектов.

То есть если у события стоит категория Private, а роль для этой категории — PrivateDAndTViewer, коллега увидит в чужом календаре именно «занято с 14:00 до 15:00» — без темы, без описания, без списка участников. Ровно то, что просила студия.

SOGoCalendarDefaultRoles: что реально стоит в mailcow по умолчанию

Связь между категорией события и тем, что видит коллега, задаётся ролями в записи общего доступа к календарю, а начальные значения этих ролей — параметром SOGoCalendarDefaultRoles. Документация SOGo описывает его так: параметр задаёт роли по умолчанию, когда пользователю выдаётся доступ к календарю. Ключевое слово — «когда выдаётся»: это шаблон для новой записи общего доступа, а не фильтр, который действует на все календари постоянно. В установочном руководстве SOGo рекомендовано значение из двух ролей — PublicViewer и ConfidentialDAndTViewer.

В самом же mailcow этот параметр уже задан из коробки в файле data/conf/sogo/sogo.conf, и там значение немного отличается от общей рекомендации SOGo — используются сразу три роли:

SOGoCalendarDefaultRoles = (
  PublicViewer,
  ConfidentialDAndTViewer,
  PrivateDAndTViewer
);

Разница между рекомендацией из общего руководства SOGo и тем, что стоит в mailcow, заметная: mailcow из коробки закрывает и Private-события, ограничивая их отображением даты и времени, тогда как в рекомендации SOGo роли для Private нет вовсе — то есть приватные события новому получателю доступа не видны совсем. Для «ИнтерфейсЛаб» это хорошая новость: когда дизайнер расшаривает календарь коллеге, тот по умолчанию видит конфиденциальные и приватные встречи только как «занято». Проблема у студии была не в этом дефолте, а в том, что дизайнер ставил категорию Public встречам, которые по смыслу должны были быть Confidential или Private, — а Public по дефолту mailcow виден целиком.

• PublicViewer — коллега видит всё событие целиком: тему, описание, участников
• ConfidentialDAndTViewer — для конфиденциальных событий видны только дата и время
• PrivateDAndTViewer — то же самое для приватных событий
• эти роли подставляются при добавлении коллеги в общий доступ; потом их можно поменять вручную для каждого

Важная оговорка: default roles не действуют для публичного доступа

Здесь есть нюанс, который легко упустить и из-за которого администраторы иногда решают, что настройка «не работает»: документация SOGo прямо указывает — роли по умолчанию игнорируются для публичного доступа (public access). Это значит, что SOGoCalendarDefaultRoles применяется только тогда, когда доступ предоставляется конкретному авторизованному пользователю внутри системы — то есть коллеге, у которого есть свой логин в SOGo.

Публичный доступ в SOGo — это отдельная запись в диалоге общего доступа к календарю для анонимного пользователя (без логина), и в mailcow он разрешён: в поставляемом sogo.conf стоит SOGoEnablePublicAccess = YES. Права такой записи владелец календаря выставляет вручную — те же уровни по категориям, но дефолт из SOGoCalendarDefaultRoles к ней не применяется. Если анонимные ссылки на календари в компании не нужны вообще, администратор может выключить их целиком, поставив SOGoEnablePublicAccess = NO и перезапустив sogo-mailcow.

Для «ИнтерфейсЛаб» это было важно прояснить отдельно: часть дизайнеров действительно делится ссылкой на календарь с клиентами напрямую, чтобы те выбирали удобное время для звонка. Мы отдельно проверили каждую такую расшаренную ссылку и убедились, что по ней не открывается ничего лишнего — полагаться на общий дефолт ролей в этом случае было бы ошибкой.

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

Настроек здесь два уровня, и путать их не стоит. Первый — права конкретного коллеги на конкретный календарь: в SOGo владелец открывает у календаря «Общий доступ», выбирает пользователя и для каждой категории (публичные, конфиденциальные, приватные события) выставляет уровень: ничего не видеть, видеть дату и время, видеть всё, отвечать или изменять. Хотите, чтобы руководитель видел только занятость даже на обычных встречах, — поставьте ему для публичных событий «видеть дату и время», это роль PublicDAndTViewer. Действует сразу, без перезапуска и без администратора.

Второй уровень — шаблон SOGoCalendarDefaultRoles в data/conf/sogo/sogo.conf: он правится в текстовом файле, а не в веб-интерфейсе mailcow. Формат — список ролей в скобках, например PublicDAndTViewer, ConfidentialDAndTViewer, PrivateDAndTViewer, если в компании принято по умолчанию показывать коллегам только занятость. Важно: шаблон применяется к новым записям общего доступа, уже выданные права он не перепишет — их придётся поправить в календарях вручную. После изменения файла перезапустите контейнер SOGo, как указано в документации mailcow:

docker compose restart sogo-mailcow

Для студии менять файл конфигурации не пришлось — дефолт mailcow (PublicViewer, ConfidentialDAndTViewer, PrivateDAndTViewer) их устраивал: внутренние планёрки пусть будут видны. Настройку мы свели к двум действиям: обучили сотрудников выбирать категорию Confidential для встреч с клиентами и прошлись по календарям трёх дизайнеров, у которых коллегам когда-то вручную выдали «видеть всё» для всех категорий, — вернули им уровень «дата и время» для конфиденциальных и приватных событий.

Что видит сам сотрудник и как правильно ставить категорию при создании встречи

Категория события выбирается автором прямо в карточке создания или редактирования встречи в SOGo — это отдельное поле, не связанное с полем «Название» или «Описание». Дизайнеры студии до нашей настройки в основном просто никогда не трогали это поле и оставляли значение по умолчанию, которое в SOGo — Public, то есть максимально открытое.

Мы договорились с «ИнтерфейсЛаб» о простом правиле: если во встрече упоминается название клиента, бюджет или что-то из категории коммерческой информации — категория Confidential или Private, в остальных случаях (внутренние созвоны, ревью, планёрки) можно оставлять Public, потому что там скрывать нечего, а видимость темы, наоборот, помогает коллегам ориентироваться в расписании друг друга.

Здесь же стоит учитывать механику: роли у конкретного коллеги могут отличаться от дефолта. Если когда-то владелец календаря вручную выдал ему «видеть всё» для конфиденциальных событий, SOGoCalendarDefaultRoles это не отменит — шаблон работает только в момент добавления в доступ. Отдельная история — пользователи из SOGoSuperUsernames в sogo.conf (в mailcow строка закомментирована): им SOGo даёт административные права над данными всех пользователей, и категории событий для них не преграда. Поэтому при жалобе «коллега видит лишнее» я первым делом открываю диалог общего доступа этого календаря, а не конфиг.

Логика та же, что и в любой другой матрице доступа в компании — права должны соответствовать реальной необходимости, а не выдаваться щедро «на всякий случай». Мы разбирали похожий принцип на примере совсем другой системы — матрицы доступа в 1С, где кладовщик не должен видеть зарплатную ведомость: с календарём та же идея, только объект другой — не документ, а чужое расписание.

Частые ошибки при настройке приватности календаря в SOGo

Первая ошибка — ждать, что правка SOGoCalendarDefaultRoles в конфиге что-то изменит в уже расшаренных календарях. Не изменит: это шаблон для новых записей общего доступа, существующие права остаются как были, пока владелец не поправит их в диалоге «Общий доступ». То же со старыми встречами: категория — свойство самого события, выбранное при создании, и событие с категорией Public при дефолте PublicViewer останется видно целиком, пока автор не сменит категорию.

Вторая ошибка — рассчитывать на SOGoCalendarDefaultRoles, расшаривая календарь по публичной ссылке. Как разобрано выше, для публичного доступа роли по умолчанию игнорируются — права анонимной записи нужно выставлять вручную у каждого календаря или вовсе запретить публичный доступ через SOGoEnablePublicAccess = NO.

Третья ошибка — путать это с междоменной видимостью, которая настраивается отдельным параметром SOGoDomainsVisibility в том же sogo.conf. Это другой уровень: он касается того, видят ли вообще пользователи одного домена существование пользователей другого домена в общей адресной книге и при поиске занятости, а не того, сколько деталей о конкретной встрече видно внутри одного домена. Для студии с одним доменом этот параметр вообще не имел значения, но для компаний с несколькими доменами внутри одного mailcow это отдельная настройка, которую тоже применяют через перезапуск sogo-mailcow.

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

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

Частые вопросы