Недавно прилетела статья от очень уважаемого мной ресурса
Приведу не столько перевод, сколько собственную компиляцию данных мыслей + бонусы
Итак, что же автор статьи не рекомендует хостить у себя дома
1. Email
Если раньше корпоративная почта на внутреннем сервере считалась нормой и давало тотальный контроль над сервисом, то сейчас требования для успешной доставки стали абсолютно абсурдными.
Тут я могу добавить, что email относится к тем ужасным технологиям 19 века, когда безопасность в интернете еще не изобрели, а лаборанты все еще скучали и изобретали абсурдные технологии на своих рабочих компьютерах.
В итоге все последующее время инженерам приходится бороться с дырявостью отраслевых стандартов, таких. как e-mail, FTP, голосовая телефония, DNS, RIP, Telnet
Где-то разработали новые протоколы, а где-то, по причине тотального использования, приходится навешивать расширения для повышения защищенности
Так для борьбы со спамом приходится настраивать DKIM, SFP, MTA-STS, Reverse DNS, просить провайдера открыть 25 порт на своем фаерволе, следить за списками репутации.
При этом, даже если ваша почта не попадает в спам, то это не значит, что ваш сервер не будет пропускать спам, сейчас в этом направлении есть подвижки, но в целом, крупные системы, такие как Gmail, Yandex Mail и прочие собирают информацию по всей почте со всех и для всех клиентов и постоянно работают в направлении улучшения защиты, они могут отловить спамера еще на этапе отправки писем другому пользователю и когда до вас дойдет очередь письма будут помечаться как спам.
К слову, я развернул дома Stalwart для служебных почтовых ящиков и доволен как слон - максимально быстрое разворачивание и все необходимые настройки безопасности из коробки.
2. Публичный DNS
Одно дело когда вы хостите свою локальную зону у себя дома и когда она падает, то не работает сеть
Другое дело, когда вы держите у себя публичную зону при отключении сервера от сети пользователи интернета не могут зайти на вашу персональную страничку на github pages т.к. вы просто не в состоянии направить их по нужному адресу
Уточнение:
Я одно время хостил зону и вполне успешно, надо понимать, что тут не все так просто и регистраторы доменов требуют указывать как минимум 2 сервера, находящихся в разных кассах C как раз таки для регионального разделения. У меня был основной сервер, а я дополнительно держал несколько вторичных в облаке, при этом, в случае недоступности основного сервера отвечают вторичные, но первичным источником зоны является только ваш сервер, который при помощи специального протокола пересылает свою зону при ее обновлении на вторичные сервера
3. Шлюзы удаленного доступа
Тут я ничего не понял, но посыл в том, что держать дома шлюз не безопасно т.к. его могут взломать, поэтому хостим его на VPS и направляем трафиг внутрь своей лабы через туннели, локально же не открываем никакие порты
Ну не знаю, тут выглядит как реклама ZeroTrust платформ, можете высказаться в комментариях
3. Пуш нотификации
Они сложные, ломаются, надо разбираться и поддерживать пуши больше чем сами серисы для них
Поэтому автор использует Mailrise и Pushover
Тут с одной стороны выглядит надуманно, с другой могу сказать, что уведомления это тоже точка отказа и чем она проще, тем лучше. Я сейчас использую TG для уведомлений и стараюсь реализовать либо без посредников, либо с установкой apprise рядом с сервисом, чтобы не было так, что уведомления ходят между сервисами и нодами PVE кластера
Ну и дублировать уведомления, например на почту
Подумываю над автономными уведомлениями на случай чебурнета
4. Менеджеры паролей
Это очень чувствительная информация и хранить ее дома очень опасно, банальный выход из строя сервера может привести к ситуации, когда вам нужен пароль от резервной копии, а этот пароль находится в этой самой резервной копии (проблема курицы и яйца)
Поэтому автор использует облачный менеджер паролей, который не зависит от работы лабы и позволит получить пароли, необходимые для восстановления работоспособности лабы
Я тоже задумывался по этому вопросу и у меня есть 2 решения и 1 в голове
- Секреты приложений я храню в кластере OpenBao
- Bitwarden может работать автономно без доступа к серверу, поэтому, надо иметь телефон или ноутбук с актуальной копией базы, при активном использовании менеджера паролей это не сложно
- Ключи доступа и одноразовые пароли я дублирую на YubiKey
- Подумываю над дублированием vaultwarden либо в Bitwarden облачный, либо в формате запуска резервной копии где-то еще
Ну и бонусы от меня
5. Базовый мониторинг
UptimeKuma и UptimeBot это очень простые сервисы мониторинга, но их достаточно для получения уведомления о сбое.
Можно крутить дома Zabbix, AlertManager и прочие naigos, но вы не получите уведомление о том, что ваш сервер помер если система мониторинга находилась на этом же сервере, поэтому, помимо крутого и сложного мониторинга добавьте еще что-то облачное или предельно простое где-то еще для дублирования функций и мониторьте с помощью его основной мониторинг.
Например, у мня уведомления о падении корпоративных сервисв приходили в Rocket Chat, а при падении Rocket Chat в телегу т.к. слать в Rocket Chat сообщение, что Rocket Chat упал бессмысленно
Про уровни критичности инфраструктуры
Недавно уже писал тут статью где как раз таки поднимал подобные проблемы, там я выделил 4.5 уровня критичности инфраструктуры и описанные сервисы как раз таки попадали в 2 самых высоких уровня. Если вы хостите их дома/сами, то уделите особое внимание надежности работы этих сервисов.
В корпоративной среде
Я исхожу из того, что часть сервисов могут быть недоступны некоторое время, а что-то является критически важным.
Когда у вас упал сервис, а сотрудники не могут ни дозвониться ни дописаться по данному вопросу т.к. у вас и сервис и почта и мессенджер и телефония находились на одном сервере - эпичный фейл и фатальная ошибка.
- Сделайте страницу с доступности сервисов, тот же uptimekuma потребляет очень мало ресурсов и при этом умеет создавать красивые дашборды для сотрудников
- Вынесети мессенджер или в SAAS или на VPS, пользуйте для почты SAAS и тогда будет намного легче