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

Розмежуйте три види доступу

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

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

Надайте новому учаснику невелику перевірену початкову роль

Перш ніж надсилати запрошення, узгодьте, які книги потрібні учаснику і чи слід їм редагувати, експортувати або чимось керувати. Створіть окремий обліковий запис, де це підтримується. Поясніть передбачуваний обсяг і як请求 зміну; уникайте робити адміністрування типовим рішенням для відсутнього дозволу.

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

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

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

Перевіряйте вбудовані зображення окремо: зображення BookStack за замовчуванням публічні, тоді як локальні файлові вкладення використовують його засоби контролю дозволів. Важко передбачуваний URL не є контролем доступу. Безпека зображень у BookStack. Для зображення, призначеного бути конфіденційним, перевірте його прямий URL після виходу з облікового запису, а потім з учасником, який не може переглянути його вихідну сторінку; за цією політикою жоден із них не повинен його отримати.

local_secure вимагає входу, але не забезпечує дотримання дозволів сторінки; local_secure_restricted перевіряє доступ до елемента, до якого було завантажено зображення. Перегляньте задокументовані обмеження щодо продуктивності, копіювання сторінок і міграції, перш ніж змінювати сховище. Наявні завантаження потребують задокументованої міграції, а не лише зміни налаштування. Варіанти сховища та міграція в BookStack.

Завершіть передачу справ до закриття облікового запису

Коли супроводжувач іде, визначте все, що залежить від його ідентичності: володіння застосунком, ключі хоста, адміністрування домену, доступ до резервних копій, інтеграції та контакти для відновлення. Передайте відповідальність уповноваженій заміні та перевірте, що заміна може отримати оперативні нотатки.

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

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

Запишіть рішення про повернення до оновлення

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

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

1. Підтвердьте ідентичність резервної копії та відповідну процедуру відновлення.
2. За можливості відрепетируйте значні зміни на ізольованій копії.
3. Погодьте паузу для редагування або вікно обслуговування та повідомте постраждалих учасників.
4. Застосуйте задокументоване оновлення для фактичного способу встановлення.
5. Перевірте вхід, читання, редагування, вкладення, обмежений вміст і налаштовані завдання.
6. Відновіть звичайне використання після перевірок або дотримуйтеся задокументованого рішення про відновлення.

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

Збережіть робочий шлях під час зміни доступу до хоста

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

На сервері Ubuntu OpenSSH задокументована команда перевірки конфігурації — sudo sshd -t. OpenSSH також документує sshd -T для дієвих налаштувань і параметрів з'єднання з -C для оцінювання правил зіставлення. Ці перевірки оглядають конфігурацію; вони не демонструють успішне з'єднання через мережу. Перевірки конфігурації Ubuntu OpenSSH; Параметри тестування сервера OpenSSH.

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

Тримайте нотатку достатньо короткою для оновлення

Service / responsible maintainer / cover:
Account or change being reviewed:
Purpose / permitted tasks / forbidden tasks:
Current version / target version, if relevant:
Credential reference / recovery access reference:
Backup identifier / return decision:
Member notice or editing pause:
Checks performed / actual result:
Unresolved issue / action owner:
Next review trigger:

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