Înainte de a începe
- Un inventar de servicii cu datele pe care le deține fiecare componentă.
- O listă de roluri de membru, editor și administrator.
- Un cont de test autorizat și o rută de recuperare documentată înainte de a modifica setările de rețea sau de autentificare.
1. Descrieți persoana și sarcina.
Pentru fiecare serviciu, finalizați această propoziție: „O persoană în acest rol trebuie să efectueze această acțiune de pe acest tip de dispozitiv.” Citirea unui orar public, editarea unei proceduri interne și întreținerea unei baze de date sunt sarcini diferite. Evitați să faceți un serviciu public doar pentru că un voluntar are nevoie ocazional de acces de la distanță.
Separați accesul la rețea de autorizarea la nivel de aplicație. Accesarea unei pagini de autentificare nu înseamnă permisiunea de a citi fișierele membrilor. Invers, ascunderea unui serviciu în spatele unei rețele private nu decide ce membri pot edita sau exporta conținutul acestuia. Înregistrați ambele straturi și procesul de eliminare a accesului atunci când cineva pleacă.
Păstrați recuperarea contului în aceeași discuție. Un serviciu privat pe care doar o singură persoană îl poate debloca creează o altă defecțiune, chiar dacă regulile sale inițiale de acces par restrictive.
2. Completați o mică matrice de acces.
Iată o configurație ipotetică de atelier comunitar. Alegerile sunt exemple pentru discuție, nu un design de rețea gata făcut.
| Componentă | Publicul vizat | Acțiune permisă | Verificați |
|---|---|---|---|
| Orar public | Oricine | Citiți datele aprobate | Vizitatorul deconectat nu vede notele membrilor |
| Wiki de lucru | Membri și editori | Citire; editare doar pentru editori | Membrul nu poate modifica o procedură |
| Bibliotecă de fișiere | Conturi de grup nominale | Citire sau încărcare în zonele atribuite | Contul plecat nu poate descărca un fișier |
| Administrarea aplicației | Maintaineri autorizați | Gestionați setările și conturile | Membrul obișnuit nu poate deschide setările |
| Bază de date | Calea aplicației și de întreținere | Operațiuni de aplicație necesare | Fără listener public neintenționat |
Scrieți mecanismul real lângă fiecare rând: conturi de aplicație, o metodă aprobată de acces privat sau un alt control documentat. „Privat” fără un mecanism și un test este doar o etichetă.
3. Revizuiți căile din jurul paginii de autentificare.
Enumerați proxy-ul invers, listenerii aplicației, porturile bazei de date și instrumentele de administrare. O aplicație poate avea un ecran de autentificare configurat cu atenție în timp ce o interfață diferită rămâne accesibilă. Inspectați configurația implementată înainte de a o modifica și păstrați o cale de recuperare pentru orice controlează accesul de la distanță.
Docker merită o verificare separată atunci când face parte din configurația dvs. O mapare de port fără o adresă gazdă explicită se publică în mod normal pe toate adresele gazdă. O legare loopback limitează accesul în cazul documentat implicit NAT, dar modul de rețea, rutarea directă și comportamentul Docker mai vechi contează. Citiți documentația pentru topologia reală, apoi verificați accesibilitatea pe căile IPv4 și IPv6 pe care le utilizați. Publicarea și maparea porturilor Docker.
4. Verificați controalele efective, nu etichetele liniștitoare.
Inspectați firewall-ul împreună cu software-ul care creează reguli de rețea. Docker documentează că traficul publicat al containerelor poate fi deviat înainte de a se aplica regulile obișnuite de intrare UFW. Un status UFW care pare curat nu dovedește, prin urmare, că un port de container este inaccesibil. Nu dezactivați gestionarea firewall-ului Docker ca soluție rapidă; documentația descrie consecințele asupra rețelei. Filtrarea pachetelor Docker și firewall-urile.
Verificați separat rolurile aplicației. De exemplu, BookStack combină abilitățile rolurilor și permite suprascrieri la nivel de conținut, astfel încât permisiunile efective ale unui utilizator pot diferi de numele unui rol atribuit. Examinați atribuirea completă și testați pagini și atașamente reprezentative. Regulile de permisiuni BookStack.
5. Păstrați transportul și încrederea în plan.
Un serviciu restricționat la membri conține totuși acreditări și conținut privat. Planificați HTTPS și încrederea în certificate pentru clienții reali, în loc să învățați membrii să ignore avertismentele browserului. Păstrați responsabilitatea reînnoirii certificatelor și verificările de eșec în notebook, alături de accesul la domeniu.
Documentația Caddy distinge validarea certificatelor publice de autoritatea sa locală de certificate. Un client trebuie să aibă încredere în autoritatea locală pentru a utiliza certificatele sale fără avertismente. Pentru certificatele publice, validarea HTTP și TLS-ALPN necesită căile de intrare respective; validarea DNS este o alternativă configurată separat. Alegeți o metodă care se potrivește limitei de acces dorite. HTTPS automată Caddy și încrederea locală.
Acesta este un pas de planificare a accesului, nu o afirmație că un certificat singur face o aplicație privată sau autorizată corespunzător.
6. Testați atât căile permise, cât și cele refuzate.
Utilizați sesiuni de browser separate pentru un vizitator deconectat, un membru obișnuit și un editor. Verificați o pagină normală, un URL direct de atașament local, o acțiune de export și o rută de administrare. Retestați după eliminarea unui cont sau schimbarea rolului acestuia. Înregistrați rezultatul așteptat înainte de a încerca acțiunea, astfel încât un succes neașteptat să nu fie confundat cu o comoditate.
Din rețelele pe care sunteți autorizat să le utilizați pentru testare, verificați că serviciul public este accesibil și că interfețele private dorite nu sunt. Testați familiile de adrese relevante și punctul final real, nu doar un nume de gazdă care se poate rezolva diferit. Înregistrați data, rețeaua sursă și rezultatul. Aceste verificări trebuie efectuate pe configurația dvs.; niciuna nu este declarată ca finalizată aici.
Testați o imagine confidențială încorporată prin URL-ul său direct în timp ce sunteți deconectat și cu un membru neautorizat. Imaginile BookStack sunt publice implicit, spre deosebire de atașamentele locale; o pagină restricționată singură este insuficientă. Examinați securitatea imaginilor și distincțiile de stocare și permisiuni din ghidul de acces înainte de a accepta limita.
7. Tratați o graniță eșuată ca o decizie de revizuit.
Dacă un cont neautorizat poate citi date, opriți extinderea accesului și inspectați moștenirea rolurilor, partajările și căile directe ale fișierelor. Dacă un port privat este accesibil, examinați legarea și regulile de rețea înainte de a adăuga un alt strat prin presupuneri. Dacă întreținătorul dorit nu se poate conecta, utilizați ruta de recuperare documentată în loc să acordați tuturor un acces mai larg.
Puneți regula corectată și o verificare repetabilă în notebook-ul de acces. Legați-o de inventar de servicii și exercițiul de recuperare. Aceste limite reduc accesul nedorit atunci când sunt implementate corect; ele nu promit anonimat și nu elimină nevoia de actualizări și de manipulare atentă a datelor.
Documentația din spatele acestei note
Folosiți documentația pentru versiunea pe care o rulați efectiv. Aceste exemple sunt material de planificare, nu o dovadă a unui test pe un VPS Hoszen.