Технический аудит и публичная статья — это два разных документа.
Аудит должен быть подробным. В нём полезны адреса, версии, роли машин, открытые сервисы, пути, пользователи и всё остальное, что помогает обслуживать систему.
В статье большая часть этих деталей не нужна.
Более того, если просто выложить аудит как есть, получится не экспертный материал, а аккуратная карта собственной инфраструктуры.
Точные адреса почти никогда не улучшают текст
Читателю достаточно знать, что публичный шлюз направляет запросы к внутренним сервисам.
Ему не нужен адрес каждой машины, полный диапазон сети и список интерфейсов. Эти данные ничего не объясняют про архитектуру, зато упрощают сбор информации о системе.
То же касается портов.
Иногда номер порта важен для учебного примера или документации. В личной обзорной статье обычно достаточно написать: сервис доступен только локально, снаружи работает через прокси.
Конфиги опасны не только паролями
Все знают, что токены и пароли нужно замазывать. На этом проверка часто заканчивается.
Но конфиг может раскрыть намного больше:
- имена пользователей;
- внутренние домены;
- пути к каталогам;
- названия контейнеров;
- структуру сети;
- идентификаторы комнат;
- адреса API;
- параметры авторизации.
Даже если каждый отдельный фрагмент выглядит безобидно, вместе они складываются в подробную схему.
Скриншот терминала — отдельная ловушка
Самые неприятные утечки часто происходят именно на скриншотах.
Человек замазал пароль, но оставил адрес в строке подключения. Обрезал вывод команды, но в prompt осталось имя пользователя и хоста. Показал админку, а в адресной строке виден служебный поддомен.
Перед публикацией стоит проверить каждый угол изображения: адресную строку, вкладки, терминальный prompt, боковые панели, уведомления, QR-коды, имена файлов и метаданные.
И лучше делать отдельный демонстрационный скриншот, а не пытаться чистить рабочий.
Версии программ — спорный момент
С одной стороны, версия даёт контекст. С другой — статья живёт долго, а конкретная версия быстро устаревает.
Если материал не посвящён багу или обновлению, чаще достаточно назвать саму технологию. Точный номер сборки редко приносит пользу.
Особенно не стоит публиковать подробный список старых компонентов, которые всё ещё доступны снаружи.
Что я оставляю в публичных материалах
Я спокойно рассказываю о ролях компонентов, выбранных технологиях, причинах решений, ошибках, сценариях использования, связях между сервисами и ограничениях.
Это и есть ценная часть статьи.
Читателю полезнее понять, почему публичный слой лучше отделить от тяжёлых приложений, чем узнать точный адрес внутренней машины.
Простое правило перед публикацией
Я задаю себе вопрос: эта деталь помогает человеку повторить идею или просто доказывает, что я действительно настроил сервер?
Если второе — её можно удалить.
Технический текст не становится слабее без лишних адресов и серийников. Обычно наоборот: после чистки он наконец начинает говорить о сути.
Публичный маршрут описан в Caddy, сеть — в Сети, процесс публикации — в Quartz-пайплайне.