Besluit wat aan die publieke kant hoort.

1. Beschrijf de persoon en de taak.

Maak voor elke dienst deze zin af: “Iemand in deze rol moet deze actie vanaf dit soort apparaat kunnen uitvoeren.” Een openbaar rooster lezen, een interne procedure bewerken en een database onderhouden zijn verschillende taken. Maak een dienst niet openbaar alleen omdat één vrijwilliger af en toe externe toegang nodig heeft.

Scheid netwerktoegang van applicatieautorisatie. Een inlogpagina bereiken is geen toestemming om ledenbestanden te lezen. Omgekeerd bepaalt het verbergen van een dienst achter een privénetwerk niet welke leden de inhoud mogen bewerken of exporteren. Noteer beide lagen en het proces voor het intrekken van toegang wanneer iemand vertrekt.

Houd accountherstel in dezelfde discussie. Een privédienst die slechts één persoon kan ontgrendelen, creëert een ander soort storing, zelfs als de initiële toegangsregels restrictief lijken.

2. Vul een kleine toegangsmatrix in.

Hier is een hypothetische opzet voor een gemeenschapsworkshop. De keuzes zijn voorbeelden voor discussie, geen kant-en-klaar netwerkontwerp.

Schrijf het feitelijke mechanisme naast elke rij: applicatieaccounts, een goedgekeurde privétoegangsmethode of een andere gedocumenteerde beheersmaatregel. “Privé” zonder mechanisme en test is slechts een label.

3. Controleer de paden rond de inlogpagina.

Som de reverse proxy, applicatielisteners, databasepoorten en beheertools op. Een applicatie kan een zorgvuldig geconfigureerd inlogscherm hebben terwijl een andere interface bereikbaar blijft. Inspecteer de geïmplementeerde configuratie voordat je die wijzigt, en houd een herstelpad voor alles wat externe toegang beheert.

Docker verdient een aparte controle wanneer het deel uitmaakt van je opstelling. Een poorttoewijzing zonder expliciet hostadres publiceert normaal op alle hostadressen. Een loopback-binding beperkt de toegang in het gedocumenteerde standaard-NAT-geval, maar de netwerkmodus, directe routering en ouder Docker-gedrag zijn van belang. Lees de documentatie voor de werkelijke topologie en verifieer daarna de bereikbaarheid via de IPv4- en IPv6-paden die je gebruikt. Docker-poortpublicatie en -toewijzing.

4. Controleer effectieve beheersmaatregelen, niet geruststellende labels.

Inspecteer de firewall samen met de software die netwerkregels aanmaakt. Docker documenteert dat gepubliceerd containerverkeer kan worden omgeleid voordat de gebruikelijke UFW-inputregels van toepassing zijn. Een schijnbaar schone UFW-status bewijst daarom niet dat een containerpoort ontoegankelijk is. Schakel het firewallbeheer van Docker niet uit als snelle oplossing; de documentatie beschrijft de netwerkgevolgen. Docker-packetfiltering en firewalls.

Controleer applicatierollen afzonderlijk. BookStack combineert bijvoorbeeld rolmogelijkheden en staat overschrijvingen op contentniveau toe, waardoor de effectieve rechten van een gebruiker kunnen verschillen van de naam van één toegewezen rol. Bekijk de volledige toewijzing en test representatieve pagina's en bijlagen. BookStack-rechtenregels.

5. Houd transport en vertrouwen in het plan.

Een service die tot leden beperkt is, bevat nog steeds inloggegevens en privécontent. Plan HTTPS en certificaatvertrouwen voor de werkelijke clients in plaats van leden te leren browserwaarschuwingen te negeren. Houd eigenaarschap van certificaatvernieuwing en foutcontroles in het notitieboek naast domeintoegang.

Caddy's documentatie onderscheidt publieke certificaatvalidatie van zijn lokale certificaatautoriteit. Een client moet de lokale autoriteit vertrouwen om zijn certificaten zonder waarschuwingen te gebruiken. Voor publieke certificaten hebben HTTP- en TLS-ALPN-validatie hun respectieve inkomende paden nodig; DNS-validatie is een apart geconfigureerd alternatief. Kies een methode die past bij de beoogde toegangsgrens. Caddy automatische HTTPS en lokaal vertrouwen.

Dit is een stap voor toegangsplanning, geen bewering dat een certificaat alleen een applicatie privé of gepast geautoriseerd maakt.

6. Test zowel de toegestane als de geweigerde paden.

Gebruik afzonderlijke browsersessies voor een uitgelogde bezoeker, een gewoon lid en een redacteur. Controleer een normale pagina, een directe lokale bijlage-URL, een exportactie en een beheerroute. Test opnieuw na het verwijderen van een account of het wijzigen van de rol ervan. Noteer het verwachte resultaat voordat je de actie probeert, zodat een onverwachte succesvolle uitkomst niet voor gemak wordt aangezien.

Verifieer vanaf netwerken die je voor tests mag gebruiken dat de publieke service bereikbaar is en de beoogde privé-interfaces niet. Test de relevante adresfamilies en het werkelijke endpoint, niet alleen een hostnaam die anders kan resolven. Noteer de datum, het bronnetwerk en de uitkomst. Deze controles moeten op jouw opstelling worden uitgevoerd; hier wordt niet beweerd dat ze zijn voltooid.

Test een vertrouwelijke ingesloten afbeelding via zijn directe URL terwijl je uitgelogd bent en met een niet-geautoriseerd lid. BookStack-afbeeldingen zijn standaard publiek, anders dan lokale bijlagen; een beperkte pagina alleen is onvoldoende. Bekijk afbeeldingsbeveiliging en de opslag- en rechtenverschillen in de toegangsgids voordat je de grens accepteert.

7. Behandel een mislukte grens als een beslissing om opnieuw te bekijken.

Als een niet-geautoriseerd account gegevens kan lezen, stop dan met het uitbreiden van toegang en inspecteer rolovererving, shares en directe bestandspaden. Als een privépoort bereikbaar is, controleer dan de binding en netwerkregels voordat je op goed geluk een extra laag toevoegt. Als de beoogde beheerder geen verbinding kan maken, gebruik dan de gedocumenteerde herstelroute in plaats van iedereen ruimere toegang te geven.

Zet de gecorrigeerde regel en een herhaalbare controle in het toegangsnotitieboek. Koppel het aan de service-inventaris en hersteloefening. Deze grenzen verminderen ongewenste toegang wanneer ze correct zijn geïmplementeerd; ze beloven geen anonimiteit en nemen de noodzaak van updates en zorgvuldige gegevensbehandeling niet weg.