Keep access deliberate when people and software change.

Separate the three kinds of access

In our illustrative workshop wiki, a member writes instructions, a notebook coordinator manages application accounts, and a host maintainer operates the server. One person may hold more than one responsibility, but the permissions should remain explicit. The worksheet below describes the group's intended policy; application settings still need to be configured and checked.

A technical administrator may be able to reach underlying data. Keep that responsibility in the group's trust decision rather than promising privacy from someone who controls the host.

Give a new member a small, checked starting role

Before sending an invitation, agree which books the member needs and whether they should edit, export or manage anything. Create an individual account where supported. Explain the intended scope and how to request a change; avoid making administration the default solution to a missing permission.

For BookStack, several assigned roles can combine their permissions, and content-level overrides affect access. Review the complete role set and the relevant content rules. Checking only a role's name is insufficient. BookStack role and content permission rules.

1. Assign the intended role and record its owner and review trigger.
2. Check the allowed task using a representative non-administrator account.
3. Check a task that should fail, such as editing a read-only book.
4. Confirm that a restricted book and its local file attachments remain unavailable.
5. Record any exception and who approved it.

Store recovery material in the agreed credential store. The access notebook holds the retrieval reference, not a password, token or private key.

Check embedded images separately: BookStack images are public by default, while local file attachments use its permission controls. A hard-to-guess URL is not access control. BookStack image security. For an image intended to be confidential, test its direct URL signed out, then with a member who cannot view its source page; neither should receive it under that policy.

local_secure requires login but does not enforce page permissions; local_secure_restricted checks access to the item the image was uploaded to. Review the documented performance, copied-page and migration limits before changing storage. Existing uploads need the documented migration, not just a setting change. BookStack storage options and migration.

Close the handover before closing the account

When a maintainer leaves, identify everything that depends on their identity: application ownership, host keys, domain administration, backup access, integrations and recovery contacts. Transfer the responsibilities to an authorized replacement and check that the replacement can retrieve the operational notes.

Remove unneeded application roles and revoke host or service access through each system's supported controls. Review active sessions, tokens and shared credentials as separate items; do not assume disabling one login revokes every mechanism. Where a shared credential was exposed to the departing person, arrange its replacement and update the consuming service deliberately.

Retain content or attribution according to the group's policy and the application's behavior. An account removal should not become an unreviewed deletion of shared work. Finish with a forbidden-access check and an updated service inventory.

Write the return decision before the update

Record the installed version, intended version and reason for the change. Read the release-specific notes, including intervening migrations and runtime requirements. BookStack's documented update process can change dependencies and the database, and it calls for backups of the database and uploads first. BookStack update guidance.

From that dependency, a practical recovery rule follows: do not assume replacing old application files will undo a database migration. Name the compatible application, configuration and data set you would restore. Decide who can stop the change, when that decision must be made, and what happens to edits accepted after the recovery point.

1. Confirm the backup's identity and the relevant restore procedure.
2. Rehearse significant changes on the isolated copy where practical.
3. Agree an editing pause or maintenance window and inform affected members.
4. Apply the documented update for the actual installation method.
5. Check sign-in, reading, editing, attachments, restricted content and configured jobs.
6. Resume ordinary use after the checks, or follow the documented recovery decision.

If an update fails, preserve the error evidence and current state. Avoid stacking unrelated fixes on top of a partial migration. Use the application documentation and the recorded recovery point to choose the next action.

Keep a working route when changing host access

Host access changes deserve a separate check. Keep the current authorized SSH session open and confirm the new key-based login before removing an existing authentication route. Know how an authorized maintainer would regain access if a new connection fails.

On an Ubuntu OpenSSH server, the documented configuration validation command is sudo sshd -t. OpenSSH also documents sshd -T for effective settings and connection parameters with -C for evaluating matching rules. These checks inspect configuration; they do not demonstrate a successful connection through the network. Ubuntu OpenSSH configuration checks; OpenSSH server test options.

Use the service controls and configuration paths for the installed distribution. Resolve validation errors before applying the change. Afterward, open a second independent connection and verify the privileges required for maintenance. Close the preserved session only after that check succeeds. This is a change procedure to adapt, not evidence that any server access has been tested here.

Keep the note short enough to update

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:

Choose a review rhythm the group can sustain and treat a security notice, membership change or failed backup as a reason to act sooner. Keep operating-system, application and integration maintenance visible as separate responsibilities. Revisit the restore rehearsal after a material change, and use the public and private service guide when the group changes who should reach the service.