Gardez un accès délibéré lorsque les personnes et les logiciels changent.

Séparez les trois types d'accès

Dans notre wiki d'atelier illustratif, un membre rédige des instructions, un coordinateur de carnet gère les comptes applicatifs et un mainteneur d'hôte exploite le serveur. Une personne peut assumer plusieurs responsabilités, mais les autorisations doivent rester explicites. La feuille de calcul ci-dessous décrit la politique prévue du groupe ; les paramètres de l'application doivent encore être configurés et vérifiés.

Un administrateur technique peut être en mesure d'accéder aux données sous-jacentes. Gardez cette responsabilité dans la décision de confiance du groupe plutôt que de promettre la confidentialité vis-à-vis d'une personne qui contrôle l'hôte.

Attribuez à un nouveau membre un rôle de départ restreint et vérifié

Avant d'envoyer une invitation, convenez des livres dont le membre a besoin et s'il doit pouvoir modifier, exporter ou gérer quoi que ce soit. Créez un compte individuel lorsque cela est pris en charge. Expliquez le périmètre prévu et comment demander une modification ; évitez de faire de l'administration la solution par défaut à une autorisation manquante.

Pour BookStack, plusieurs rôles attribués peuvent combiner leurs autorisations, et les dérogations au niveau du contenu affectent l'accès. Examinez l'ensemble complet des rôles et les règles de contenu pertinentes. Vérifier uniquement le nom d'un rôle est insuffisant. Règles de rôle et d'autorisation de contenu de BookStack.

1. Attribuez le rôle prévu et enregistrez son propriétaire et son déclencheur de revue.
2. Vérifiez la tâche autorisée à l'aide d'un compte non administrateur représentatif.
3. Vérifiez une tâche qui devrait échouer, comme la modification d'un livre en lecture seule.
4. Confirmez qu'un livre restreint et ses pièces jointes locales restent indisponibles.
5. Enregistrez toute exception et qui l'a approuvée.

Stockez le matériel de récupération dans le coffre d'identifiants convenu. Le carnet d'accès contient la référence de récupération, pas un mot de passe, un jeton ou une clé privée.

Vérifiez les images intégrées séparément : les images BookStack sont publiques par défaut, tandis que les pièces jointes locales utilisent ses contrôles d'autorisation. Une URL difficile à deviner n'est pas un contrôle d'accès. Sécurité des images BookStack. Pour une image destinée à être confidentielle, testez son URL directe en étant déconnecté, puis avec un membre qui ne peut pas voir sa page source ; aucun des deux ne doit la recevoir selon cette politique.

local_secure nécessite une connexion mais n'applique pas les autorisations de page ; local_secure_restricted vérifie l'accès à l'élément dans lequel l'image a été téléversée. Examinez les limites documentées de performance, de pages copiées et de migration avant de modifier le stockage. Les téléversements existants nécessitent la migration documentée, pas seulement un changement de paramètre. Options de stockage et migration de BookStack.

Clôturez la passation avant de fermer le compte

Lorsqu'un mainteneur part, identifiez tout ce qui dépend de son identité : propriété d'application, clés d'hôte, administration de domaine, accès aux sauvegardes, intégrations et contacts de récupération. Transférez les responsabilités à un remplaçant autorisé et vérifiez que le remplaçant peut récupérer les notes opérationnelles.

Supprimez les rôles applicatifs inutiles et révoquez l'accès à l'hôte ou au service via les contrôles pris en charge par chaque système. Examinez les sessions actives, les jetons et les identifiants partagés comme des éléments distincts ; ne présumez pas que la désactivation d'une connexion révoque tous les mécanismes. Lorsqu'un identifiant partagé a été exposé à la personne qui part, organisez son remplacement et mettez à jour le service consommateur de manière délibérée.

Conservez le contenu ou l'attribution conformément à la politique du groupe et au comportement de l'application. La suppression d'un compte ne doit pas devenir une suppression non examinée d'un travail partagé. Terminez par une vérification d'accès interdit et une mise à jour de l'inventaire des services.

Écrivez la décision de retour avant la mise à jour

Enregistrez la version installée, la version cible et la raison du changement. Lisez les notes spécifiques à la version, y compris les migrations intermédiaires et les exigences d'exécution. Le processus de mise à jour documenté de BookStack peut modifier les dépendances et la base de données, et il exige des sauvegardes de la base de données et des téléversements au préalable. Guide de mise à jour de BookStack.

De cette dépendance découle une règle de récupération pratique : ne présumez pas que le remplacement des anciens fichiers d'application annulera une migration de base de données. Nommez l'application, la configuration et le jeu de données compatibles que vous restaureriez. Décidez qui peut arrêter la modification, quand cette décision doit être prise et ce qu'il advient des modifications acceptées après le point de récupération.

1. Confirmez l'identité de la sauvegarde et la procédure de restauration applicable.
2. Répétez les modifications importantes sur la copie isolée lorsque c'est possible.
3. Convenez d'une pause d'édition ou d'une fenêtre de maintenance et informez les membres concernés.
4. Appliquez la mise à jour documentée pour la méthode d'installation réelle.
5. Vérifiez la connexion, la lecture, l'édition, les pièces jointes, le contenu restreint et les tâches planifiées.
6. Reprenez l'usage normal après les vérifications, ou suivez la décision de récupération documentée.

Si une mise à jour échoue, conservez les preuves de l'erreur et l'état actuel. Évitez d'empiler des correctifs sans rapport sur une migration partielle. Utilisez la documentation de l'application et le point de récupération enregistré pour choisir l'action suivante.

Conservez une voie fonctionnelle lors de la modification de l'accès à l'hôte

Les changements d'accès à l'hôte méritent une vérification distincte. Gardez la session SSH autorisée actuelle ouverte et confirmez la nouvelle connexion par clé avant de supprimer une route d'authentification existante. Sachez comment un mainteneur autorisé regagnerait l'accès si une nouvelle connexion échoue.

Sur un serveur Ubuntu OpenSSH, la commande documentée de validation de la configuration est sudo sshd -t. OpenSSH documente également sshd -T pour les paramètres effectifs et les paramètres de connexion avec -C pour évaluer les règles de correspondance. Ces vérifications inspectent la configuration ; elles ne démontrent pas une connexion réussie à travers le réseau. Vérifications de configuration Ubuntu OpenSSH; Options de test du serveur OpenSSH.

Utilisez les contrôles de service et les chemins de configuration de la distribution installée. Résolvez les erreurs de validation avant d'appliquer la modification. Ensuite, ouvrez une seconde connexion indépendante et vérifiez les privilèges requis pour la maintenance. Fermez la session préservée seulement après la réussite de cette vérification. Il s'agit d'une procédure de modification à adapter, et non d'une preuve qu'un accès serveur a été testé ici.

Gardez la note assez courte pour être mise à jour

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:

Choisissez un rythme de revue que le groupe peut maintenir et considérez un avis de sécurité, un changement d'adhésion ou une sauvegarde échouée comme une raison d'agir plus tôt. Gardez la maintenance du système d'exploitation, de l'application et des intégrations visible comme des responsabilités distinctes. Revoyez la répétition de restauration après un changement important, et utilisez le guide des services publics et privés lorsque le groupe change qui doit accéder au service.