Вирішіть, що належить до публічної частини.

1. Опишіть особу та завдання.

Для кожного сервісу завершіть це речення: «Особа в цій ролі повинна виконати цю дію з цього типу пристрою». Читання публічного розкладу, редагування внутрішньої процедури та підтримка бази даних — це різні завдання. Уникайте робити сервіс публічним лише тому, що одному волонтеру потрібен час від часу віддалений доступ.

Відокремте мережевий доступ від авторизації в застосунку. Досягнення сторінки входу не є дозволом читати файли членів. І навпаки, приховування сервісу за приватною мережею не визначає, які члени можуть редагувати або експортувати його вміст. Запишіть обидва рівні та процес скасування доступу, коли хтось іде.

Тримайте відновлення облікових записів у тому самому обговоренні. Приватний сервіс, який може розблокувати лише одна особа, створює інший збій, навіть якщо його початкові правила доступу виглядають обмежувальними.

2. Заповніть невелику матрицю доступу.

Ось гіпотетична конфігурація громадської майстерні. Вибір є прикладами для обговорення, а не готовим дизайном мережі.

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

3. Перегляньте шляхи навколо сторінки входу.

Перелічіть зворотний проксі, слухачі застосунку, порти бази даних та інструменти адміністрування. Застосунок може мати ретельно налаштований екран входу, тоді як інший інтерфейс залишається доступним. Огляньте розгорнуту конфігурацію перед її зміною та збережіть шлях відновлення для всього, що контролює віддалений доступ.

Docker заслуговує на окрему перевірку, коли він є частиною вашої конфігурації. Перепризначення порту без явної адреси хоста зазвичай публікує його на всіх адресах хоста. Прив'язка до петльового інтерфейсу обмежує доступ у документованому стандартному випадку 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. Розглядайте невдалу межу як рішення, яке потрібно переглянути.

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

Внесіть виправлене правило та повторювану перевірку до нотатника доступу. Пов'яжіть його з реєстр сервісів та вправою відновлення. Ці межі зменшують небажаний доступ за умови правильного впровадження; вони не обіцяють анонімності та не усувають потреби в оновленнях і обережному поводженні з даними.