Mențineți accesul deliberat atunci când oamenii și software-ul se schimbă.

Separați cele trei tipuri de acces

În wiki-ul nostru ilustrativ de atelier, un membru scrie instrucțiuni, un coordonator de notebook gestionează conturile aplicației, iar un responsabil de gazdă operează serverul. O persoană poate deține mai multe responsabilități, dar permisiunile ar trebui să rămână explicite. Fișa de mai jos descrie politica intenționată a grupului; setările aplicației trebuie încă configurate și verificate.

Un administrator tehnic poate fi capabil să acceseze datele subiacente. Păstrați această responsabilitate în decizia de încredere a grupului, în loc să promiteți confidențialitate față de cineva care controlează gazda.

Acordați unui membru nou un rol de început mic și verificat

Înainte de a trimite o invitație, conveniți ce cărți are nevoie membrul și dacă ar trebui să editeze, să exporte sau să gestioneze ceva. Creați un cont individual acolo unde este acceptat. Explicați domeniul de aplicare intenționat și cum să solicitați o modificare; evitați să faceți din administrare soluția implicită pentru o permisiune lipsă.

Pentru BookStack, mai multe roluri atribuite își pot combina permisiunile, iar suprascrierile la nivel de conținut afectează accesul. Revizuiți setul complet de roluri și regulile de conținut relevante. Verificarea doar a numelui unui rol este insuficientă. Reguli de rol și permisiuni de conținut în BookStack.

1. Atribuiți rolul intenționat și înregistrați proprietarul său și declanșatorul de revizuire.
2. Verificați sarcina permisă folosind un cont reprezentativ non-administrator.
3. Verificați o sarcină care ar trebui să eșueze, cum ar fi editarea unei cărți read-only.
4. Confirmați că o carte restricționată și atașamentele sale de fișiere locale rămân indisponibile.
5. Înregistrați orice excepție și cine a aprobat-o.

Stocați materialul de recuperare în depozitul de acreditări convenit. Caietul de acces conține referința de recuperare, nu o parolă, un token sau o cheie privată.

Verificați imaginile încorporate separat: imaginile BookStack sunt publice în mod implicit, în timp ce atașamentele de fișiere locale folosesc controalele sale de permisiuni. Un URL greu de ghicit nu este control de acces. Securitatea imaginilor în BookStack. Pentru o imagine destinată a fi confidențială, testați URL-ul său direct deconectat, apoi cu un membru care nu poate vedea pagina sa sursă; niciunul nu ar trebui să o primească conform acelei politici.

local_secure necesită autentificare, dar nu aplică permisiunile paginii; local_secure_restricted verifică accesul la elementul în care a fost încărcată imaginea. Revizuiți limitele documentate de performanță, pagini copiate și migrare înainte de a schimba stocarea. Încărcările existente necesită migrarea documentată, nu doar o schimbare de setare. Opțiuni de stocare și migrare în BookStack.

Închideți predarea înainte de a închide contul

Când un responsabil de întreținere pleacă, identificați tot ce depinde de identitatea sa: proprietatea aplicației, cheile gazdei, administrarea domeniului, accesul la backup, integrările și contactele de recuperare. Transferați responsabilitățile către un înlocuitor autorizat și verificați că înlocuitorul poate recupera notele operaționale.

Eliminați rolurile de aplicație nefolosite și revocați accesul la gazdă sau serviciu prin controalele acceptate ale fiecărui sistem. Revizuiți sesiunile active, token-urile și acreditările partajate ca elemente separate; nu presupuneți că dezactivarea unei autentificări revocă toate mecanismele. Acolo unde o acreditare partajată a fost expusă persoanei care pleacă, aranjați înlocuirea sa și actualizați serviciul consumator în mod deliberat.

Păstrați conținutul sau atribuirea conform politicii grupului și comportamentului aplicației. Eliminarea unui cont nu ar trebui să devină o ștergere nerevizuită a muncii partajate. Încheiați cu o verificare a accesului interzis și un inventar actualizat al inventar de servicii.

Scrieți decizia de revenire înainte de actualizare

Înregistrați versiunea instalată, versiunea intenționată și motivul schimbării. Citiți notele specifice versiunii, inclusiv migrările intermediare și cerințele de runtime. Procesul de actualizare documentat al BookStack poate schimba dependențele și baza de date și solicită mai întâi backup-uri ale bazei de date și încărcărilor. Ghid de actualizare BookStack.

Din această dependență decurge o regulă practică de recuperare: nu presupuneți că înlocuirea fișierelor vechi ale aplicației va anula o migrare a bazei de date. Numiți aplicația compatibilă, configurația și setul de date pe care le-ați restaura. Decideți cine poate opri modificarea, când trebuie luată acea decizie și ce se întâmplă cu modificările acceptate după punctul de recuperare.

1. Confirmați identitatea copiei de siguranță și procedura de restaurare relevantă.
2. Repetați modificările semnificative pe copia izolată, acolo unde este practic.
3. Stabiliți o pauză de editare sau o fereastră de mentenanță și informați membrii afectați.
4. Aplicați actualizarea documentată pentru metoda de instalare reală.
5. Verificați autentificarea, citirea, editarea, atașamentele, conținutul restricționat și sarcinile configurate.
6. Reluați utilizarea obișnuită după verificări sau urmați decizia de recuperare documentată.

Dacă o actualizare eșuează, păstrați dovezile erorii și starea curentă. Evitați suprapunerea unor remedieri nelegate peste o migrare parțială. Folosiți documentația aplicației și punctul de recuperare înregistrat pentru a alege acțiunea următoare.

Păstrați o rută funcțională la schimbarea accesului la gazdă

Modificările de acces la gazdă merită o verificare separată. Păstrați deschisă sesiunea SSH autorizată curentă și confirmați noua autentificare bazată pe chei înainte de a elimina o rută de autentificare existentă. Știți cum ar putea un administrator autorizat să recupereze accesul dacă o conexiune nouă eșuează.

Pe un server Ubuntu OpenSSH, comanda documentată de validare a configurației este sudo sshd -t. OpenSSH documentează de asemenea sshd -T pentru setările efective și parametrii de conexiune cu -C pentru evaluarea regulilor de potrivire. Aceste verificări inspectează configurația; nu demonstrează o conexiune reușită prin rețea. Verificări de configurare Ubuntu OpenSSH; Opțiuni de test pentru serverul OpenSSH.

Folosiți controalele serviciului și căile de configurare pentru distribuția instalată. Rezolvați erorile de validare înainte de a aplica modificarea. După aceea, deschideți o a doua conexiune independentă și verificați privilegiile necesare pentru mentenanță. Închideți sesiunea păstrată numai după ce acea verificare reușește. Aceasta este o procedură de modificare de adaptat, nu o dovadă că vreun acces la server a fost testat aici.

Păstrați nota suficient de scurtă pentru a fi actualizată

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:

Alegeți un ritm de revizuire pe care grupul îl poate susține și tratați o notificare de securitate, o schimbare de membru sau o copie de siguranță eșuată ca motiv de acțiune mai rapidă. Mențineți mentenanța sistemului de operare, a aplicației și a integrărilor vizibile ca responsabilități separate. Reveniți la exercițiul de restaurare după o modificare semnificativă și folosiți ghidul serviciilor publice și private când grupul schimbă cine ar trebui să acceseze serviciul.