Cum se activează auditarea jurnalului de activitate în ownCloud Enterprise

Activarea fluxului de activitate a fișierelor ownCloud nu creează, în sine, o pistă de audit pentru administratori. Pentru ownCloud Server Enterprise, componenta relevantă este aplicația de audit exclusiv pentru întreprinderi . Aceasta înregistrează un set mai larg de acțiuni ale utilizatorilor și administratorilor în sistemul de jurnalizare a serverului, unde puteți direcționa aceste înregistrări către un fișier dedicat și, dacă este necesar, către o platformă de analiză a jurnalelor.

Acest ghid urmărește implementarea clasică ownCloud Server documentată pentru versiunea 11.0. Etichetele meniului și metodele de configurare pot varia în funcție de versiune și pachet. ownCloud Infinite Scale (oCIS) utilizează un serviciu de audit separat, așadar nu aplicați aceste instrucțiuni Server la o implementare oCIS.

Ce înregistrează auditul ownCloud?

Aplicația de auditare poate înregistra evenimente precum conectările și deconectările utilizatorilor, crearea, ștergerea și mutarea fișierelor, operațiunile de eliminare a fișierelor din coșul de gunoi și de versiune, partajarea și modificările permisiunilor, gestionarea grupurilor și a utilizatorilor, comentariile, etichetele, modificările setărilor utilizatorilor, activarea sau dezactivarea aplicațiilor, uzurparea identității și executarea comenzilor OCC. Intrările includ câmpuri comune, cum ar fi ora, utilizatorul, detaliile solicitării, adresa la distanță, aplicația, mesajul și un nume unic al acțiunii. Câmpurile exacte ale evenimentului variază în funcție de acțiune.

Auditarea este diferită de aplicația Activitate. Activitatea este un flux de evenimente de fișiere și foldere orientat spre utilizator. Auditarea este destinată revizuirii administrative, fluxurilor de lucru de conformitate și analizei evenimentelor relevante pentru securitate. Activați aplicația Enterprise Auditing atunci când aveți nevoie de o înregistrare pe server; utilizați Activitatea atunci când utilizatorii au nevoie de un flux convenabil cu modificările aduse conținutului.

Înainte de a activa auditarea

• Confirmați că implementarea este ownCloud Server Enterprise și că aplicația Auditing este disponibilă pentru instanță.
• Folosește un cont de administrator ownCloud pentru a activa aplicația. Un administrator de sistem poate avea nevoie și de acces la shell sau container pentru a seta configurația de înregistrare în jurnal.
• Alegeți o destinație dedicată pentru jurnal cu suficient spațiu pe disc. Confirmați că serverul web sau containerul poate scrie în aceasta și decideți cine are permisiunea de a o citi.
• Setați o politică de retenție și rotație înainte de a activa un flux de audit cu volum mare. Înregistrările de audit pot include ID-uri de utilizator, adrese IP, căi de fișiere, detalii despre clienți și metadate de partajare.

Pasul 1: Activați aplicația Auditare

Conectați-vă ca administrator ownCloud și deschideți secțiunea Aplicații din interfața de administrare. Găsiți Auditare și activați-o. Dacă aplicația lipsește, verificați drepturile Enterprise, versiunea serverului dvs. și canalul de asistență ownCloud Marketplace sau al furnizorului pentru pachetul de aplicații compatibil. Nu presupuneți că aplicația standard Activitate este un înlocuitor.

Pasul 2: Dirijați mesajele de audit către un fișier dedicat

ownCloud recomandă separarea mesajelor de audit de jurnalul general al serverului. Un fișier dedicat facilitează setarea permisiunilor, a regulilor de păstrare și colectare pentru datele de audit. Documentația actuală Server 11.0 oferă un exemplu de variabilă de mediu pentru container. Ajustați destinația la o cale care există în implementarea dvs. și pe care serviciul ownCloud o poate scrie:

OWNCLOUD_LOG_CONDITIONS=[{"apps":["admin_audit"],"loglevel":0,"logfile":"/mnt/data/files/admin_audit.log"}]

Această condiție direcționează mesajele din admin_auditaplicație către fișierul numit. În exemplul documentat, rutarea mesajelor de audit către un fișier separat ocolește filtrul global la nivel de jurnal și înregistrează mesajele indiferent de nivelul lor. Calea afișată este asociată cu un volum de date montat în Docker; este un exemplu, nu o cale universală. Persistați modificarea mediului utilizând metoda de configurare pentru implementare și reporniți sau recreați serviciul numai după cum este necesar în procesul de orchestrare a containerelor.

Pentru instalările configurate prin config.php, referința de configurare a aplicației ownCloud documentează și log.conditionscheia. Adaptați calea la directorul de date real al gazdei și păstrați intrările de configurare existente, în loc să înlocuiți întreaga matrice:

'log.conditions' => [
  [
    'apps' => ['admin_audit'],
    'logfile' => '/var/www/owncloud/data/admin_audit.log'
  ],
],

Dacă păstrați ieșirea auditului în jurnalul normal ownCloud în loc să o direcționați separat, ghidul de auditare ownCloud precizează că nivelul jurnalului serverului trebuie setat la 1(INFO) sau 0(DEBUG), altfel mesajele de audit pot să nu fie scrise. O condiție de fișier separat evită utilizarea nivelului global de jurnal, dar nu elimină necesitatea monitorizării spațiului disponibil pe disc.

Pasul 3: Verificați dacă un eveniment real ajunge la fișier

După activarea aplicației și aplicarea configurației de înregistrare în jurnal, generați un eveniment controlat permis de politica dvs. - de exemplu, creați sau ștergeți un fișier de testare temporar într-un cont de testare desemnat. Apoi, inspectați jurnalul de audit configurat pe server. O intrare tipică este reprezentată de date structurate, mai degrabă decât de o cronologie a activității orientată spre om. Căutați ora evenimentului, actorul, aplicația, acțiunea și detaliile relevante. Operațiunile asupra fișierelor pot include, de asemenea, o cale, un proprietar sau un identificator de fișier; alte tipuri de evenimente au propriile câmpuri.

Verificați dacă o acțiune nou generată apare după modificarea configurației, dacă marcajul său temporal este sensibil pentru fusul orar al serverului și dacă acțiunea și utilizatorul corespund testului. Evitați utilizarea unui fișier de producție sensibil pentru a testa înregistrarea în jurnal a ștergerilor. Dacă nu apare nimic, confirmați că aplicația Auditing este activată, destinația jurnalului este corectă și poate fi scrisă, variabila de mediu sau configurația PHP a fost încărcată efectiv, nivelul jurnalului serverului este adecvat atunci când utilizați jurnalul implicit și tipul de acțiune se numără printre cele înregistrate de versiunea instalată a aplicației Auditing.

Pasul 4: Protejați, păstrați și revizuiți fișierul de audit

Jurnalizarea auditului este utilă numai atunci când înregistrările rămân disponibile și accesul este controlat. Restricționați permisiunile pentru fișiere și directoare la conturile sistemului de operare și rolurile de audit care necesită acces. Planificați rotația sau colectarea jurnalelor, astfel încât o instanță ocupată să nu își poată umple spațiul de stocare. Decideți cât timp veți păstra înregistrările pe baza politicii interne și a obligațiilor legale; ownCloud nu stabilește o perioadă universală de păstrare pentru fiecare organizație.

Pentru o separare mai puternică a sarcinilor, păstrați fișierul de audit în afara zonei de fișiere obișnuite accesibile prin web, acolo unde este posibil, și definiți ce administratori de sistem și auditori îl pot citi sau administra. ownCloud documentează un rol de Auditor și descrie separarea jurnalelor de audit de jurnalele generale ownCloud, inclusiv configurațiile în care administratorul de sistem nu poate accesa fișierul de audit. Acest rezultat depinde de modul în care sunt configurate permisiunile gazdei și implementarea, așadar verificați-l cu echipa dvs. de securitate, în loc să presupuneți că un nume de fișier separat creează o separare de la sine.

Dacă utilizați Splunk, documentația de auditare ownCloud descrie monitorizarea admin_audit.logcu Splunk Universal Forwarder și analizarea ieșirii ca JSON. Documentația include un exemplu inputs.confși props.confsetări. Tratați forwarder-ul și sistemul receptor ca parte a limitei de audit: protejați acreditările, criptați transportul acolo unde este permis de arhitectura dvs. de înregistrare în jurnal, confirmați sosirea evenimentelor și alertați cu privire la lacune sau erori de ingerare.

Opțional: limitați numele de grup care apar în intrări

În mod implicit, contextul de auditare poate include utilizatori asociați unui eveniment și grupurile cărora le aparțin acești utilizatori. Setarea OWNCLOUD_ADMIN_AUDIT_GROUPSpoate limita numele de grupuri incluse. Folosiți-o numai atunci când este adecvată o politică de filtrare deliberată; reducerea contextului de grup poate face, de asemenea, investigațiile ulterioare mai puțin informative. Examinați înregistrările rezultate și cerințele de confidențialitate înainte de a aplica un filtru.

Probleme comune de configurare

• Nu apar înregistrări de audit: confirmați că aplicația Enterprise Auditing este activată. Dacă utilizați jurnalul standard, verificați dacă nivelul global este INFO (1) sau DEBUG (0). Dacă utilizați un fișier separat, verificați starea aplicației și calea care permite scrierea.
• Fișierul așteptat lipsește: calea Docker documentată presupune un volum montat. Verificați configurația efectivă a containerului, maparea volumului și permisiunile utilizatorului serviciului.
• Înregistrările apar în locul greșit: inspectați configurația activă OWNCLOUD_LOG_CONDITIONSși log.conditionsevitați regulile duplicate sau conflictuale.
• Fluxul pare incomplet: Activitatea și Auditarea sunt aplicații diferite, iar acoperirea aplicației de audit depinde de tipul și versiunea evenimentului. Verificați un eveniment cunoscut, compatibil cu versiunea instalată, înainte de a concluziona că înregistrarea în jurnal este defectuoasă.
• Evenimentele din linia de comandă lipsesc: ownCloud include în mod implicit evenimente declanșate de CLI. Verificați dacă admin_audit ignore_cli_eventsa fost setat la yes.

Lista de verificare finală

1. Implementarea este ownCloud Server Enterprise, iar aplicația de auditare compatibilă este activată.
2. Destinația configurată există, ownCloud poate scrie în ele și nu este expusă ca și conținut obișnuit al utilizatorului.
3. O acțiune de testare permisă creează o înregistrare corespondentă cu o marcă temporală și un actor plauzibili.
4. Permisiunile, rotația, retenția și responsabilitățile privind accesul sunt documentate.
5. Dacă jurnalele sunt transmise extern, sistemul receptor afișează evenimentele recente, iar monitorizarea poate detecta întreruperi.

Pentru detalii specifice versiunii, consultați documentația ownCloud Server Auditing , referința de configurare a aplicației ownCloud și îndrumările de separare a rolurilor și auditurilor ownCloud . Pentru produsul separat Infinite Scale, consultați documentația oCIS Audit Service .