Avant de commencer
- Un inventaire des services avec les données que détient chaque composant.
- Une liste des rôles de membre, d'éditeur et d'administrateur.
- Un compte de test autorisé et une voie de récupération documentée avant de modifier les paramètres réseau ou de connexion.
1. Décrivez la personne et la tâche.
Pour chaque service, terminez cette phrase : « Une personne dans ce rôle doit effectuer cette action depuis ce type d'appareil. » Lire un horaire public, modifier une procédure interne et maintenir une base de données sont des tâches différentes. Évitez de rendre un service public simplement parce qu'un bénévole a besoin d'un accès distant occasionnel.
Séparez l'accès réseau de l'autorisation applicative. Atteindre une page de connexion n'est pas une permission de lire les fichiers des membres. Inversement, masquer un service derrière un réseau privé ne détermine pas quels membres peuvent modifier ou exporter son contenu. Notez les deux couches et le processus de suppression de l'accès lorsqu'une personne part.
Gardez la récupération de compte dans la même discussion. Un service privé qu'une seule personne peut déverrouiller crée une défaillance différente, même si ses règles d'accès initiales semblent restrictives.
2. Remplissez une petite matrice d'accès.
Voici une configuration hypothétique d'atelier communautaire. Les choix sont des exemples de discussion, pas une conception de réseau prête à l'emploi.
| Composant | Public visé | Action autorisée | Vérification |
|---|---|---|---|
| Horaire public | Tout le monde | Lire les dates approuvées | Le visiteur déconnecté ne voit aucune note des membres |
| Wiki de travail | Membres et éditeurs | Lecture ; modification réservée aux éditeurs | Un membre ne peut pas modifier une procédure |
| Bibliothèque de fichiers | Comptes de groupe nommés | Lire ou téléverser dans les zones assignées | Un compte de personne partie ne peut pas télécharger un fichier |
| Administration de l'application | Mainteneurs autorisés | Gérer les paramètres et les comptes | Un membre ordinaire ne peut pas ouvrir les paramètres |
| Base de données | Parcours applicatif et de maintenance | Opérations applicatives requises | Aucun écouteur public non intentionnel |
Écrivez le mécanisme réel à côté de chaque ligne : comptes applicatifs, une méthode d'accès privée approuvée ou un autre contrôle documenté. « Privé » sans mécanisme ni test n'est qu'une étiquette.
3. Examinez les chemins autour de la page de connexion.
Listez le reverse proxy, les écouteurs applicatifs, les ports de base de données et les outils d'administration. Une application peut avoir un écran de connexion soigneusement configuré tandis qu'une autre interface reste accessible. Inspectez la configuration déployée avant de la modifier et conservez une voie de récupération pour tout ce qui contrôle l'accès distant.
Docker mérite une vérification distincte lorsqu'il fait partie de votre installation. Une correspondance de port sans adresse d'hôte explicite se publie normalement sur toutes les adresses de l'hôte. Une liaison loopback limite l'accès dans le cas NAT par défaut documenté, mais le mode réseau, le routage direct et le comportement des anciennes versions de Docker comptent. Lisez la documentation pour la topologie réelle, puis vérifiez l'accessibilité via les chemins IPv4 et IPv6 que vous utilisez. Publication et mappage des ports Docker.
4. Vérifiez les contrôles effectifs, pas les libellés rassurants.
Inspectez le pare-feu avec le logiciel qui crée les règles réseau. Docker documente que le trafic publié des conteneurs peut être détourné avant que les règles d'entrée UFW habituelles ne s'appliquent. Un statut UFW apparemment propre ne prouve donc pas qu'un port de conteneur est inaccessible. Ne désactivez pas la gestion du pare-feu de Docker comme correctif rapide ; la documentation décrit les conséquences réseau. Filtrage de paquets et pare-feu Docker.
Vérifiez les rôles applicatifs séparément. Par exemple, BookStack combine les capacités des rôles et permet des dérogations au niveau du contenu, de sorte que les permissions effectives d'un utilisateur peuvent différer du nom d'un rôle attribué. Examinez l'attribution complète et testez des pages et pièces jointes représentatives. Règles de permission BookStack.
5. Gardez le transport et la confiance dans le plan.
Un service réservé aux membres porte tout de même des identifiants et du contenu privé. Planifiez HTTPS et la confiance des certificats pour les clients réels au lieu d'apprendre aux membres à ignorer les avertissements du navigateur. Conservez la propriété du renouvellement des certificats et les contrôles de défaillance dans le carnet, aux côtés de l'accès au domaine.
La documentation de Caddy distingue la validation des certificats publics de son autorité de certification locale. Un client doit faire confiance à l'autorité locale pour utiliser ses certificats sans avertissement. Pour les certificats publics, la validation HTTP et TLS-ALPN nécessite leurs chemins entrants respectifs ; la validation DNS est une alternative configurée séparément. Choisissez une méthode adaptée à la frontière d'accès prévue. HTTPS automatique et confiance locale de Caddy.
Il s'agit d'une étape de planification d'accès, et non de l'affirmation qu'un certificat seul rend une application privée ou correctement autorisée.
6. Testez à la fois les chemins autorisés et refusés.
Utilisez des sessions de navigateur distinctes pour un visiteur déconnecté, un membre ordinaire et un éditeur. Vérifiez une page normale, une URL directe de pièce jointe locale, une action d'export et une route d'administration. Retestez après la suppression d'un compte ou la modification de son rôle. Consignez le résultat attendu avant de tenter l'action, afin qu'un succès inattendu ne soit pas pris pour une commodité.
Depuis les réseaux que vous êtes autorisé à utiliser pour les tests, vérifiez que le service public est accessible et que les interfaces privées prévues ne le sont pas. Testez les familles d'adresses pertinentes et le point de terminaison réel, pas seulement un nom d'hôte qui peut résoudre différemment. Consignez la date, le réseau source et le résultat. Ces contrôles doivent être effectués sur votre installation ; aucun n'est déclaré comme terminé ici.
Testez une image confidentielle intégrée par son URL directe en étant déconnecté et avec un membre non autorisé. Les images BookStack sont publiques par défaut, contrairement aux pièces jointes locales ; une page restreinte seule est insuffisante. Consultez sécurité des images et les les distinctions de stockage et de permission dans le guide d'accès avant d'accepter la frontière.
7. Traitez une limite défaillante comme une décision à revoir.
Si un compte non autorisé peut lire des données, cessez d'étendre l'accès et inspectez l'héritage des rôles, les partages et les chemins de fichiers directs. Si un port privé est accessible, examinez sa liaison et ses règles réseau avant d'ajouter une autre couche à l'aveuglette. Si le mainteneur prévu ne peut pas se connecter, utilisez la voie de récupération documentée au lieu d'accorder à tous un accès plus large.
Placez la règle corrigée et un contrôle répétable dans le carnet d'accès. Reliez-le à l' l'inventaire des services et exercice de récupération. Ces frontières réduisent les accès indésirables lorsqu'elles sont correctement mises en œuvre ; elles ne promettent pas l'anonymat ni ne dispensent des mises à jour et d'une manipulation prudente des données.
Documentation à l'appui de cette note
Utilisez la documentation de la version que vous exécutez réellement. Ces exemples sont du matériel de planification, et non un compte rendu d'un test sur un VPS Hoszen.