Немного дольше, немного дешевле · Экономия 28% за 6 месяцев или 50% за год, единым платежом Смотрите тарифы ↗

Операции · 6 мин чтения

Сохраняйте осознанный доступ, когда меняются люди и программное обеспечение.

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

Перед началом

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

Разделите три вида доступа

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

Заполненный план доступа для блокнота мастерской
ОтветственностьОбычная работаГраница доступа
Читатель или редакторЧитать назначенные книги; редактировать там, где группа разрешает.Без управления учётными записями и входа на хост.
Координатор приложенияПроверять роли участников и права на содержимое.Администрирование приложения не требует общей учётной записи хоста.
Сопровождающий хостаПоддерживать среду выполнения, конфигурацию и восстановление.Индивидуальная идентичность хоста; привилегированная работа записывается.
Идентичность резервного копированияВыполнять определённую операцию резервного копирования.Без обычного просмотра участниками; область проверяется отдельно.
Резервный сопровождающийВосстанавливать доступ, когда основной сопровождающий отсутствует.Авторизованный маршрут задокументирован вне вики.

Технический администратор может иметь доступ к нижележащим данным. Оставьте эту ответственность в решении группы о доверии, а не обещайте приватность от того, кто контролирует хост.

Дайте новому участнику небольшую проверенную начальную роль

Перед отправкой приглашения согласуйте, какие книги нужны участнику и должен ли он редактировать, экспортировать или чем-то управлять. Создайте отдельную учётную запись там, где это поддерживается. Объясните предполагаемую область и как запросить изменение; избегайте превращения администрирования в решение по умолчанию для отсутствующего права.

В 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:

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

Документация к этому примечанию

Используйте документацию для версии, которую вы фактически запускаете. Эти примеры — материал для планирования, а не запись теста на Hoszen VPS.