С чистого листа

Архитектура 2.0 почти определена. Общие контуры постепенно вырисовываются. Многое ещё сырое — детали будут уточняться по ходу — но принципиальные решения приняты. Приступаем к реализации.

Как именно мигрировать с того, что есть, на то, что задумано — у меня пока нет четкого плана. Скорее всего, я буду поднимать новую инфраструктуру отдельно, рядом со старой, и переносить всё постепенно, по частям — пока старая не отомрет сама за ненадобностью.

Я начну с управляющего кластера — группы серверов под управлением Kubernetes для сервисных функций: PKI, etcd, subscription-сервис, Telegram-бот, резервное копирование. Логика выбора простая: это компонент, который не участвует в передаче трафика — его можно поднять и проверить в полной изоляции, не трогая рабочую сеть.

Управляющий кластер — мозг всей системы. Убить его — значит остановить всё. Поэтому один сервер здесь не подойдет: единственная точка отказа в самом критичном месте — это не архитектурное решение, это архитектурная ошибка. Нужен кластер из нескольких серверов. А раз кластер — значит, Kubernetes. Мне ещё не доводилось поднимать Kubernetes. Хороший повод наконец разобраться — у меня есть пара свободных недель, думаю, как раз хватит.

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

В мире существует два подхода к безопасности.

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

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

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

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

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

Поэтому я решил начать заново. С нуля. С чистого листа — полностью пересмотрев подход к безопасности на всех уровнях.

Первый шаг — организационный. Проект выносится в отдельную учетную запись и отделяется от всего личного. Никакого смешения: Sigil Gate теперь самостоятельный ресурс со своей идентичностью — отдельный проект с отдельной инфраструктурой.

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

Все секреты — переносим на физический носитель (и защищаем на физическом уровне). Форматируем под LUKS2 — зашифрованный том открывается мастер-паролем при каждом использовании. Генерируем SSH-ключи Ed25519 с passphrase. Теперь, даже при доступе к расшифрованному носителю — ключ без своего пароля бесполезен. Отключаем SSH-агента — passphrase запрашивается при каждом подключении, ключ не кешируется. Регистрируем ноды нашего будущего кластера — с верификацией host fingerprint из панели хостера при первом подключении. После сверки хост фиксируется в known_hosts, StrictHostKeyChecking=yes. Отключаем вход по паролю. Отключаем Root-доступ. Разрешаем подключение только пользователям из списка. Обновляем систему, настраиваем апдейты только для security-патчей. Включаем фаервол и закрываем все порты, оставляем пока только сервисный SSH. Fail2ban блокирует брутфорс. Пишем аутентификационные данные сервисных пользователей и токены доступа не флешку - вместе с нихитрым скриптом, загружающим их в переменные среды на время сессии. Форвардинг переменных окружения с учётными данными на сервере явно запрещён, теперь все дальнейшие действия — только с флешки оператора.

Инфраструктура настроена, серверы готовы. Можно начинать разворачивать кластер.