Bevor Sie beginnen
- Ein Dienstinventar mit den Daten, die jede Komponente enthält.
- Eine Liste der Rollen Mitglied, Redakteur und Administrator.
- Ein autorisiertes Testkonto und ein dokumentierter Wiederherstellungsweg, bevor Netzwerk- oder Anmeldeeinstellungen geändert werden.
1. Beschreiben Sie die Person und die Aufgabe.
Vervollständigen Sie für jeden Dienst diesen Satz: „Eine Person in dieser Rolle muss diese Aktion von dieser Art von Gerät aus ausführen.“ Einen öffentlichen Fahrplan lesen, eine interne Arbeitsanweisung bearbeiten und eine Datenbank pflegen sind unterschiedliche Aufgaben. Machen Sie einen Dienst nicht einfach öffentlich, weil eine Freiwillige oder ein Freiwilliger gelegentlich Remote-Zugriff benötigt.
Trennen Sie Netzwerkzugriff von Anwendungsautorisierung. Eine Anmeldeseite zu erreichen ist keine Berechtigung, Mitgliederdateien zu lesen. Umgekehrt entscheidet das Verbergen eines Dienstes hinter einem privaten Netzwerk nicht darüber, welche Mitglieder seine Inhalte bearbeiten oder exportieren dürfen. Erfassen Sie beide Ebenen und den Prozess zum Entfernen des Zugriffs, wenn jemand das Team verlässt.
Behalten Sie die Kontowiederherstellung in derselben Diskussion. Ein privater Dienst, den nur eine Person entsperren kann, erzeugt einen anderen Fehlerfall, selbst wenn seine anfänglichen Zugriffsregeln restriktiv aussehen.
2. Füllen Sie eine kleine Zugriffsmatrix aus.
Hier ist ein hypothetisches Community-Workshop-Setup. Die Entscheidungen sind Beispiele zur Diskussion, kein fertiges Netzwerkdesign.
| Komponente | Beabsichtigte Zielgruppe | Erlaubte Aktion | Prüfen |
|---|---|---|---|
| Öffentlicher Fahrplan | Jeder | Genehmigte Termine lesen | Abgemeldeter Besucher sieht keine Mitgliedernotizen |
| Arbeits-Wiki | Mitglieder und Redakteure | Lesen; Bearbeiten nur für Redakteure | Mitglied kann eine Arbeitsanweisung nicht ändern |
| Dateibibliothek | Benannte Gruppenkonten | Lesen oder Hochladen innerhalb zugewiesener Bereiche | Ausgeschiedenes Konto kann keine Datei herunterladen |
| Anwendungsadministration | Autorisierte Maintainer | Einstellungen und Konten verwalten | Normales Mitglied kann Einstellungen nicht öffnen |
| Datenbank | Anwendungs- und Wartungspfad | Erforderliche Anwendungsoperationen | Kein unbeabsichtigter öffentlicher Listener |
Schreiben Sie den tatsächlichen Mechanismus neben jede Zeile: Anwendungskonten, eine genehmigte private Zugriffsmethode oder eine andere dokumentierte Kontrolle. „Privat“ ohne Mechanismus und Test ist nur ein Etikett.
3. Prüfen Sie die Pfade rund um die Anmeldeseite.
Listen Sie den Reverse-Proxy, die Anwendungs-Listener, Datenbankports und Administrationstools auf. Eine Anwendung kann einen sorgfältig konfigurierten Anmeldebildschirm haben, während eine andere Schnittstelle erreichbar bleibt. Prüfen Sie die bereitgestellte Konfiguration, bevor Sie sie ändern, und behalten Sie einen Wiederherstellungsweg für alles, was den Fernzugriff steuert.
Docker verdient eine separate Prüfung, wenn es Teil Ihres Setups ist. Eine Portzuordnung ohne explizite Hostadresse veröffentlicht normalerweise auf allen Hostadressen. Eine Loopback-Bindung schränkt den Zugriff im dokumentierten Standard-NAT-Fall ein, aber Netzwerkmodus, direktes Routing und älteres Docker-Verhalten spielen eine Rolle. Lesen Sie die Dokumentation für die tatsächliche Topologie und überprüfen Sie dann die Erreichbarkeit über die von Ihnen verwendeten IPv4- und IPv6-Pfade. Docker-Portveröffentlichung und -zuordnung.
4. Prüfen Sie wirksame Kontrollen, nicht beruhigende Beschriftungen.
Prüfen Sie die Firewall zusammen mit der Software, die Netzwerkregeln erstellt. Docker dokumentiert, dass veröffentlichter Container-Datenverkehr umgeleitet werden kann, bevor die üblichen UFW-Eingangsregeln greifen. Ein sauber aussehender UFW-Status beweist daher nicht, dass ein Container-Port unzugänglich ist. Deaktivieren Sie nicht die Docker-Firewallverwaltung als schnelle Lösung; die Dokumentation beschreibt die Netzwerkauswirkungen. Docker-Paketfilterung und Firewalls.
Prüfen Sie Anwendungsrollen separat. Beispielsweise kombiniert BookStack Rollenfähigkeiten und erlaubt Überschreibungen auf Inhaltsebene, sodass die effektiven Berechtigungen eines Benutzers vom Namen einer zugewiesenen Rolle abweichen können. Überprüfen Sie die vollständige Zuweisung und testen Sie repräsentative Seiten und Anhänge. BookStack-Berechtigungsregeln.
5. Behalten Sie Transport und Vertrauen im Plan.
Ein auf Mitglieder beschränkter Dienst trägt weiterhin Anmeldeinformationen und private Inhalte. Planen Sie HTTPS und Zertifikatsvertrauen für die tatsächlichen Clients, anstatt Mitgliedern beizubringen, Browserwarnungen zu ignorieren. Behalten Sie die Zuständigkeit für die Zertifikatserneuerung und Fehlerprüfungen im Notizbuch neben dem Domänenzugriff.
Die Caddy-Dokumentation unterscheidet zwischen öffentlicher Zertifikatsvalidierung und ihrer lokalen Zertifizierungsstelle. Ein Client muss der lokalen Zertifizierungsstelle vertrauen, um ihre Zertifikate ohne Warnungen zu verwenden. Für öffentliche Zertifikate benötigen HTTP- und TLS-ALPN-Validierung ihre jeweiligen eingehenden Pfade; DNS-Validierung ist eine separat konfigurierte Alternative. Wählen Sie eine Methode, die zur beabsichtigten Zugriffsgrenze passt. Caddy automatisches HTTPS und lokales Vertrauen.
Dies ist ein Schritt zur Zugriffsplanung, keine Behauptung, dass ein Zertifikat allein eine Anwendung privat oder angemessen autorisiert macht.
6. Testen Sie sowohl die erlaubten als auch die verweigerten Pfade.
Verwenden Sie separate Browsersitzungen für einen abgemeldeten Besucher, ein normales Mitglied und einen Editor. Prüfen Sie eine normale Seite, eine direkte lokale Anhangs-URL, eine Exportaktion und eine Administrationsroute. Testen Sie erneut, nachdem Sie ein Konto entfernt oder seine Rolle geändert haben. Notieren Sie das erwartete Ergebnis, bevor Sie die Aktion versuchen, damit ein unerwarteter Erfolg nicht mit Bequemlichkeit verwechselt wird.
Überprüfen Sie von Netzwerken aus, die Sie zum Testen autorisiert sind, dass der öffentliche Dienst erreichbar ist und die beabsichtigten privaten Schnittstellen nicht. Testen Sie die relevanten Adressfamilien und den tatsächlichen Endpunkt, nicht nur einen Hostnamen, der möglicherweise anders aufgelöst wird. Notieren Sie Datum, Quellnetzwerk und Ergebnis. Diese Prüfungen müssen in Ihrem Setup durchgeführt werden; keine wird hier als abgeschlossen beansprucht.
Testen Sie ein vertrauliches eingebettetes Bild über seine direkte URL, während Sie abgemeldet sind und mit einem nicht autorisierten Mitglied. BookStack-Bilder sind standardmäßig öffentlich, im Gegensatz zu lokalen Anhängen; eine eingeschränkte Seite allein reicht nicht aus. Überprüfen Sie Bildsicherheit und die Speicher- und Berechtigungsunterschiede im Zugriffsleitfaden bevor Sie die Grenze akzeptieren.
7. Behandeln Sie eine fehlgeschlagene Grenze als Entscheidung, die erneut geprüft werden muss.
Wenn ein nicht autorisiertes Konto Daten lesen kann, stoppen Sie die Zugriffserweiterung und prüfen Sie Rollenvererbung, Freigaben und direkte Dateipfade. Wenn ein privater Port erreichbar ist, überprüfen Sie seine Bindung und Netzwerkregeln, bevor Sie durch Raten eine weitere Ebene hinzufügen. Wenn der vorgesehene Betreuer keine Verbindung herstellen kann, verwenden Sie den dokumentierten Wiederherstellungsweg, anstatt allen breiteren Zugriff zu gewähren.
Tragen Sie die korrigierte Regel und eine wiederholbare Prüfung in das Zugriffsnotizbuch. Verlinken Sie es mit der Dienstverzeichnis und Wiederherstellungsübung. Diese Grenzen reduzieren unerwünschten Zugriff, wenn sie korrekt implementiert sind; sie versprechen keine Anonymität und beseitigen nicht die Notwendigkeit von Updates und sorgfältigem Umgang mit Daten.
Dokumentation zu dieser Notiz
Verwenden Sie die Dokumentation für die Version, die Sie tatsächlich ausführen. Diese Beispiele sind Planungsmaterial, kein Nachweis eines Tests auf einem Hoszen VPS.