Архитектура · данные · доступ · инциденты
Отдавать почту и DNS подрядчику страшно — и правильно, что страшно. Эта страница отвечает на неудобные вопросы до договора: где живут ваши данные, что останется работать при отказе нашей панели, кто и как может зайти на узел и чего мы не обещаем.
Инварианты
Инвариант — не «лучшая практика», а свойство, которое обязано выполняться всегда. Каждое из шести придумано под конкретный сценарий отказа: падает провайдер, падает наша панель, компрометируется узел, уходит инженер.
DNS-серверы и почтовые узлы выполняют свой цикл — включая обновление DANE/TLSA — без обращения к панели. Панель задаёт конфигурацию и собирает телеметрию; она не стоит на пути письма.
Сценарий: панель недоступна → почта и DNS работают
Защищённое соединение с hub всегда инициирует сам узел. Входящие административные порты не публикуются; открыты только сервисные порты, которые нужны DNS- и почтовому трафику.
Сценарий: сканирование административной поверхности → нет цели
Provider-agnostic схема: зона живёт у облачного провайдера и одновременно на собственных BIND-узлах в регионах СНГ, с переключением. Ни один провайдер не является обязательным.
Сценарий: отказ или блокировка провайдера → зона отвечает
Разные системы, разные отказы, разные права. Компрометация интерфейса управления не означает автоматического контроля над трафиком — и наоборот.
Сценарий: инцидент в панели → трафик не затронут
Ничего не разрешено, пока не разрешено явно. Права на трансфер зоны выводятся из инвентаря узлов, а не раздаются вручную, и снимаются автоматически, когда узел перестаёт проходить аттестацию.
Сценарий: узел выведен из строя → доступ отозван сам
Два почтовых шлюза с разделением по весу MX, несколько авторитативных серверов, два контура размещения. Каждый элемент, отказ которого остановил бы сервис, задублирован — это и есть отсутствие SPOF.
Сценарий: отказ узла или площадки → сервис продолжает
Данные
Гибрид не означает «где-то в облаке». Контуры разделены явно, и состав собирается под требования регуляторики: часть услуг может целиком уехать на площадку клиента.
| Компонент | Где размещается | Что там хранится |
|---|---|---|
| Авторитативный DNS | облачный провайдер + собственные BIND-узлы (СНГ) | записи зоны, ключи DNSSEC |
| Почтовые шлюзы Proxmox Mail Gateway | on-premises: площадка клиента или оператора | почтовый поток обрабатывается на вашей стороне |
| Панель hub | облачный контур MSCS | инвентарь узлов, конфигурация, телеметрия, аудит-журнал |
| Конвейер DMARC-отчётов | облачный контур MSCS | агрегированные отчёты rua — метаданные о доставке, не содержимое писем |
| Threat Intelligence и DNSBL | облачный контур MSCS, раздача узлам | индикаторы угроз из внешних фидов и собственных наблюдений |
DMARC-отчёты по своей природе содержат метаданные о доставке: адреса отправляющих серверов, результаты проверок SPF и DKIM, домены. Содержимого переписки в них нет — это свойство самого стандарта, а не наша политика.
Согласие
Согласие на обслуживание подтверждается не письмом и не галочкой в панели, а записью в самой зоне: владелец публикует на apex TXT-запись подтверждения. Пока её нет, платформа помечает зону как необслуживаемую.
Подтверждение владения — apex TXT
example-corp.ru. IN TXT "mscs-verification=$true"Почему так: запись в зоне может опубликовать только тот, кто действительно ею управляет. Это защищает и вас — от обслуживания вашего домена по чужой заявке, — и нас: от претензий «мы этого не просили».
Доступ
Удалённый доступ инженера — самое опасное место любого управляемого сервиса. Поэтому он устроен как брокер с многофакторным подтверждением, а не как «у нас есть ваш SSH-ключ».
Подключение
Узел держит исходящий туннель к hub. Входящих портов на нём нет — зайти «снаружи» технически некуда.
Аутентификация
Взаимный TLS с корпоративным удостоверяющим центром, проверка отзыва сертификата через OCSP, подпись Ed25519 и сервисный токен. Отказ любого из них — отказ в сессии.
Полномочия
Право доступа выводится из инвентаря и снимается, если узел не подтверждает свою целостность очередной аттестацией. Телеметрия узлов — read-only.
Следы
Сессии доступа записываются в зашифрованном виде, действия в панели — в журнал аудита со сцеплением записей: незаметно изменить историю задним числом нельзя.
Честная оговорка о зрелости: брокер удалённого доступа работает на пилоте и включается флагом — как и полагается функции такого класса, он не включён «по умолчанию для всех». Базовый контур (активация, аттестация, раздача контента, DNS и TI) работает в проде.
Статус
Страница статуса без клиентской нагрузки — это красивая зелёная плашка ни о чём. Поэтому пока здесь цифры платформы, а не проценты аптайма.
Состав платформы и границы каждой услуги, архитектурные инварианты, состав экспресс-аудита, метрики пилота с датой среза и методику рыночных сравнений — с оговорками там, где данные неполные.
Проценты аптайма и время реакции как публичные обязательства: они появятся вместе с первыми клиентскими пилотами и измеримым периодом. До тех пор целевые показатели фиксируются в договоре, а не на лендинге.
Живая страница статуса — в плане развития: адаптация внутреннего дашборда платформы без чувствительных деталей. Появится после запуска первых клиентских пилотов.
Инциденты
Принципы ниже действуют независимо от договора. Конкретные сроки уведомления и целевые показатели восстановления фиксируются письменно — на сайте им не место, потому что они зависят от состава услуги.
Ответственное лицо со стороны клиента узнаёт об инциденте от нас, а не из жалоб пользователей. Даже если причина ещё не установлена.
Что наблюдаем, что уже сделали, что делаем сейчас, когда следующее обновление. Без «работаем над этим» без содержания.
Хронология, причина, что изменили, чтобы не повторилось. Разбор без поиска виноватых: смысл — в исправленной системе, а не в найденном человеке.
Урок одного клиента становится проверкой, мониторингом или инвариантом для всех. Так растёт чек-лист экспресс-аудита.
Границы
Почтовая аутентификация и DANE закрывают конкретные классы атак. Всё остальное закрывается другими средствами — честно об этом говорим.
Управление вашим доменом остаётся вашим. Мы не делаем необратимых изменений без согласования.
Threat Intelligence собирается собственным конвейером; источники раскрываются в отчётности.
Ни с именем, ни «анонимно»: обезличенный отчёт по домену обезличенным не бывает.
Функции за флагами и на пилоте называются так, как есть, — и на этой странице тоже.
Любое рыночное утверждение на сайте сопровождается методикой, датой среза и оговоркой.
Proxmox Mail Gateway — продукт Proxmox Server Solutions GmbH. MSCS эксплуатирует его как платформу узлов SEG и не аффилирована с вендором.
Proxmox® и Proxmox Mail Gateway® — зарегистрированные товарные знаки Proxmox Server Solutions GmbH (proxmox.com). MSCS эксплуатирует Proxmox Mail Gateway как программную платформу почтовых узлов в составе услуги Secure Email Gateway; мы не аффилированы с Proxmox Server Solutions GmbH, не являемся официальным партнёром и не выступаем от их имени.
Вопросы
Почта и DNS продолжат работать. Панель — это control plane: место, где задаётся конфигурация и видна телеметрия. Обработку трафика ведёт data plane — DNS-серверы и почтовые узлы, которые выполняют свой цикл автономно и не спрашивают панель на каждом запросе.
Входящих административных портов нет: защищённое соединение с hub всегда инициирует сам узел. Сервисные порты DNS и почты открыты только для профильного трафика. Доступ инженера возможен только через брокер с многофакторным подтверждением, действует по политике deny-by-default и записывается. Право доступа снимается, если узел не проходит очередную аттестацию.
Пока нет. Платформа работает в пилоте на собственных доменах группы, и публиковать аптайм по периоду без клиентской нагрузки было бы некорректно. Живая страница статуса появится вместе с первыми клиентскими пилотами; целевые показатели и порядок уведомлений фиксируются в договоре.
Да. Гибридная модель собирается под требования: DNS-зона может обслуживаться собственными BIND-узлами в регионах СНГ, почтовые шлюзы Proxmox Mail Gateway разворачиваются на площадке клиента или оператора. Облачный контур в этом сценарии остаётся для панели и конвейеров TI и DMARC.
Дальше
Задайте их инженеру платформы напрямую — до всякого договора и презентаций. Если ответ окажется полезен другим, он появится на этой странице.