Решите, что должно быть в публичной части.

1. Опишите человека и задачу.

Для каждого сервиса закончите это предложение: «Человеку в этой роли нужно выполнить это действие с такого типа устройства». Чтение публичного расписания, редактирование внутренней процедуры и обслуживание базы данных — разные задачи. Не делайте сервис публичным только потому, что одному волонтёру нужен occasional удалённый доступ.

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

Включите восстановление учётных записей в то же обсуждение. Частный сервис, который может разблокировать только один человек, создаёт другую проблему, даже если его начальные правила доступа выглядят строгими.

2. Заполните небольшую матрицу доступа.

Вот гипотетическая конфигурация общественной мастерской. Выборы приведены как примеры для обсуждения, а не как готовый проект сети.

Запишите фактический механизм рядом с каждой строкой: учётные записи приложения, утверждённый метод частного доступа или другой документированный контроль. «Частный» без механизма и теста — это только ярлык.

3. Проверьте пути вокруг страницы входа.

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

Docker заслуживает отдельной проверки, когда он является частью вашей конфигурации. Сопоставление портов без явного адреса хоста обычно публикует службу на всех адресах хоста. Привязка к loopback ограничивает доступ в документированном случае NAT по умолчанию, но сетевой режим, прямое маршрутизирование и старое поведение Docker имеют значение. Прочитайте документацию для фактической топологии, затем проверьте доступность по используемым вами путям IPv4 и IPv6. Публикация и сопоставление портов Docker.

4. Проверяйте действующие механизмы контроля, а не успокаивающие метки.

Проверяйте межсетевой экран вместе с программным обеспечением, создающим сетевые правила. Docker документирует, что опубликованный трафик контейнера может перенаправляться до применения обычных входных правил UFW. Поэтому безупречный статус UFW не доказывает недоступность порта контейнера. Не отключайте управление межсетевым экраном Docker в качестве быстрого решения; в документации описаны сетевые последствия. Фильтрация пакетов Docker и файрволы.

Проверяйте роли приложений отдельно. Например, BookStack объединяет возможности ролей и допускает переопределения на уровне содержимого, поэтому фактические разрешения пользователя могут отличаться от названия одной назначенной роли. Проверьте полное назначение и протестируйте характерные страницы и вложения. Правила разрешений BookStack.

5. Учитывайте транспорт и доверие в плане.

Служба, ограниченная для участников, всё равно содержит учётные данные и закрытое содержимое. Планируйте HTTPS и доверие к сертификатам для фактических клиентов, а не приучайте участников игнорировать предупреждения браузера. Ведите учёт ответственного за продление сертификатов вместе с проверками сбоев в рабочем журнале рядом с доступом к домену.

Документация Caddy различает проверку публичных сертификатов и свой локальный центр сертификации. Клиент должен доверять локальному центру, чтобы использовать его сертификаты без предупреждений. Для публичных сертификатов проверка HTTP и TLS-ALPN требует соответствующих входящих путей; проверка DNS — отдельно настраиваемая альтернатива. Выберите метод, подходящий к предполагаемой границе доступа. Автоматический HTTPS Caddy и локальное доверие.

Это этап планирования доступа, а не утверждение, что один сертификат делает приложение приватным или надлежащим образом авторизованным.

6. Проверьте как разрешённые, так и запрещённые пути.

Используйте отдельные сеансы браузера для вышедшего посетителя, обычного участника и редактора. Проверьте обычную страницу, прямой локальный URL вложения, действие экспорта и административный маршрут. Повторно протестируйте после удаления учётной записи или изменения её роли. Запишите ожидаемый результат до выполнения действия, чтобы неожиданный успех не был принят за удобство.

Из сетей, которые вам разрешено использовать для тестирования, убедитесь, что публичная служба доступна, а предполагаемые приватные интерфейсы — нет. Тестируйте соответствующие семейства адресов и фактическую конечную точку, а не только имя хоста, которое может разрешаться иначе. Запишите дату, исходную сеть и результат. Эти проверки должны быть выполнены в вашей конфигурации; ни одна из них не заявлена здесь как выполненная.

Проверьте конфиденциальное встроенное изображение по его прямому URL, выйдя из системы и от имени неавторизованного участника. Изображения BookStack по умолчанию публичны, в отличие от локальных вложений; одной ограниченной страницы недостаточно. Просмотрите безопасность изображений и различия хранилищ и разрешений в руководстве по доступу прежде чем принять границу.

7. Считайте неудачную границу поводом вернуться к решению.

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

Поместите исправленное правило и воспроизводимую проверку в журнал доступа. Свяжите его с инвентаризацией сервисов и упражнением по восстановлению. Эти границы уменьшают нежелательный доступ при правильной реализации; они не обещают анонимность и не устраняют необходимость обновлений и аккуратной работы с данными.