MONOLIT
← Înapoi la prezentareToate modulele

Platforma

Platforma: utilizatori, roluri, audit

Autentificarea, rolurile, jurnalul de audit și regulile care țin cele 15 module împreună.

Versiune
2.0.0
Stadiu
Stabil
Capturi
3
Înlocuiește
Conturi și permisiuni separate în fiecare unealtă
Utilizatori sincronizați din Active Directory. Conturile platformei, importate din AD, cu departament, tip și roluri. Rolurile decid ce module vede fiecare om și ce poate face în ele.
Utilizatori sincronizați din Active Directory. Conturile platformei, importate din AD, cu departament, tip și roluri. Rolurile decid ce module vede fiecare om și ce poate face în ele.

Capturi din aplicație

Cum arată în lucru

Interfața reală Monolit, cu datele unei firme fictive într-o zi obișnuită. Apăsați pe o captură ca s-o vedeți la dimensiune completă.

Roluri și vizibilitatea modulelor. Cele cinci roluri implicite, plus trei create pentru firmă (hr, soc_analyst, auditor). Dedesubt, tabelul care stabilește ce module apar în meniu pentru fiecare rol.
Captura 2 din 3

Roluri și vizibilitatea modulelor

Cele cinci roluri implicite, plus trei create pentru firmă (hr, soc_analyst, auditor). Dedesubt, tabelul care stabilește ce module apar în meniu pentru fiecare rol.

Jurnalul de audit. Autentificări, eșecuri și modificări de setări, cu ora, utilizatorul și IP-ul. Se văd schimbările făcute azi de administrator și blocările repetate ale contului AD m.pop de dimineață.
Captura 3 din 3

Jurnalul de audit

Autentificări, eșecuri și modificări de setări, cu ora, utilizatorul și IP-ul. Se văd schimbările făcute azi de administrator și blocările repetate ale contului AD m.pop de dimineață.

1Nivelul 1

Pentru conducere

Ce problemă rezolvă, cum se lucrează cu modulul și ce se poate măsura.

Ce problemă rezolvă

Monolit are 15 module: tichete, RMM, SOC, UPS, Seif și altele. Fără un nucleu comun, fiecare ar avea propriile conturi, propriile reguli de acces și propriul istoric. Ar fi imposibil de răspuns simplu la întrebările „cine are acces la ce?” și „cine a schimbat asta?”.

Nucleul platformei oferă un singur login, conturi sincronizate din Active Directory, roluri comune pentru toate modulele, un jurnal de audit și backup-ul datelor fiecărui modul.

Ce face, concret

  • Login unic pentru toate modulele, cu contul de domeniu sau cu un cont local. O sesiune este valabilă în toată aplicația.
  • Utilizatori din Active Directory: conturile se importă periodic (implicit la 4 ore) sau la cerere, cu butonul „Sync AD”. Un cont dezactivat în AD se dezactivează și în Monolit.
  • Roluri: cinci roluri implicite (admin, it_manager, it_staff, employee, client) plus roluri proprii firmei. Un tabel stabilește ce module apar în meniu pentru fiecare rol.
  • Setări aplicație: nume, fus orar, politica de securitate (expirarea sesiunii, numărul maxim de încercări de login, lungimea minimă a parolei), server SMTP și canal Teams pentru notificări, fiecare cu buton de test.
  • Jurnal de audit: autentificări reușite și eșuate, schimbări de parolă și de profil, modificări de setări, creări și actualizări de utilizatori, cu ora, utilizatorul, IP-ul și detaliile. Se filtrează pe tipul evenimentului.
  • Backup și recuperare: backup zilnic al datelor fiecărui modul, păstrare configurabilă, copie pe NAS, verificare SHA-256 și restaurare cu backup de siguranță creat automat înainte.
  • Despre: versiunea aplicației și a fiecărui modul, citită direct din modul, cu starea și latența lui.

Fluxuri de lucru

1. Angajat nou

  1. Contul se creează în Active Directory.
  2. La următoarea sincronizare, apare în Monolit cu rolul potrivit grupului AD: it_staff pentru echipa IT, employee pentru restul.
  3. IT-ul adaugă, dacă e nevoie, roluri suplimentare (de exemplu hr). Modificarea intră în jurnalul de audit.

2. Plecarea unui angajat

  1. Contul se dezactivează în AD.
  2. Sincronizarea îl marchează inactiv în Monolit, iar accesul se oprește.
  3. Istoricul acțiunilor lui rămâne în jurnalul de audit.

3. Restaurarea datelor unui modul

  1. Administratorul alege un backup din istoric și vede dimensiunea, numărul de tabele și rânduri și amprenta SHA-256.
  2. Confirmă explicit operațiunea, marcată ca distructivă.
  3. Înainte de restaurare se creează automat un backup de siguranță al stării curente.
  4. Rezultatul arată tabelele și rândurile restaurate. Evenimentul e publicat ca audit critic.

Beneficii și indicatori

  • Un singur loc pentru a vedea cine are acces și cu ce rol: numărul total de utilizatori, câți sunt activi și câți vin din AD.
  • Autentificări eșuate pe utilizator, vizibile în audit: blocări repetate, încercări suspecte.
  • Pentru fiecare modul: data și starea ultimului backup, numărul de copii și spațiul ocupat, plus starea NAS-ului.
  • Versiunea și starea fiecărui modul într-un singur tabel, util la upgrade și la depanare.

2Nivelul 2

Pentru echipa IT

Arhitectură, integrări, API, roluri și limitările cunoscute.

Arhitectură

  • core_service: versiunea 2.0.0, port 8001, schemă SQL auth, prefix /api/auth. Contractul listează 11 endpoint-uri.
  • Stack: FastAPI pe Python 3.12, SQL Server 2022, Redis 7 (cache și evenimente între module), Nginx ca reverse proxy și server pentru interfața React. Fiecare modul rulează ca serviciu systemd separat, pe Ubuntu Server 22.04.
  • Minim recomandat pentru mașina virtuală: 6 vCPU, 12 GB RAM, 120 GB SSD.
  • Instalare și actualizare prin scripturi: install.sh (idempotent, 11 pași, cu verificare la final), deploy.sh, upgrade.sh cu --rollback.

Autentificare (JWT)

  • Login → access token și refresh token, cu rolurile incluse în payload.
  • HS256, același SECRET_KEY pe toate modulele. Access token valabil 60 de minute, refresh token 7 zile.
  • La un răspuns 401, interfața reînnoiește automat token-ul și reia cererea. Dacă reînnoirea eșuează, trimite utilizatorul la login.
  • În backend, modulele verifică token-ul prin require_auth și require_roles din pachetul comun monolit_core.

Active Directory

  • Sincronizare LDAP (ldap3), la intervalul AD_SYNC_INTERVAL_HOURS (implicit 4) sau manual, prin POST /api/auth/ad/sync.
  • Grupul AD_IT_STAFF_GROUP devine rolul it_staff; AD_EMPLOYEE_GROUP sau lipsa grupului devine employee.
  • Starea sincronizării: GET /api/auth/ad/status. Evenimente publicate: auth.user_created, auth.user_disabled.

Arhitectura modulară (reguli de integrare)

  • Fiecare modul își declară contractul în module.yaml: port, schemă SQL, prefix API, endpoint-uri, evenimente, variabile de mediu obligatorii. Aceste câmpuri sunt înghețate. Se pot adăuga elemente noi; ștergerea sau redenumirea cere versiune majoră nouă și actualizarea consumatorilor.
  • Fiecare modul expune /health cu status, module, port și version. Versiunea trebuie să coincidă cu module.yaml. scripts/verify_integration.py verifică portul, prefixul, schema și /health; scripts/validate_contracts.py verifică potrivirea dintre ce consumă și ce oferă modulele.
  • Modulele comunică doar prin HTTP sau prin evenimente Redis. Importul direct din codul altui modul este interzis. Interogările SQL între scheme sunt permise doar modulului de monitorizare.
  • În interfață, registrul de module decide ce apare în meniu. Un modul se poate ascunde fără a fi șters.

Backup și restaurare

  • Modulul backup_manager: port 8013, schemă core_backup, prefix /api/backup.
  • Backup automat zilnic la 02:00 UTC pentru fiecare schemă de modul. Păstrare implicită 7 zile, configurabilă pe modul, cu programare, notificare la eșec și copiere pe NAS (BACKUP_NAS_MOUNT).
  • Crearea, descărcarea și ștergerea backup-urilor cer rolul it_manager; restaurarea cere admin. Evenimente: backup.completed, backup.failed, backup.restored.
  • Separat, upgrade.sh salvează fișierele .env și codul înainte de fiecare actualizare și păstrează ultimele 5 copii. Fișierele .env nu sunt suprascrise niciodată la upgrade.

Endpoint-uri notabile ale nucleului

  • POST /login, POST /refresh, POST /logout, GET /me
  • GET /roles, GET|POST /users, PUT|DELETE /users/{id} (rolul it_manager; ștergerea înseamnă dezactivare)
  • GET /ad/status, POST /ad/sync
  • Interfața de Setări mai folosește POST|DELETE /roles, GET /settings, PUT /settings/{key}, testele SMTP și Teams, PUT /me, POST /me/password și GET /audit. Aceste rute nu apar încă în module.yaml.

Roluri și audit

  • Administrarea utilizatorilor cere rolul it_manager. Restaurarea backup-urilor și tabul „Stocare & Loguri” sunt doar pentru admin.
  • Rolurile implicite nu se pot șterge; rolurile proprii, da.
  • Jurnalul de audit al nucleului acoperă autentificarea, parolele, profilul, setările și utilizatorii. Modulele sensibile (de exemplu Seif, Suprafață externă) își țin auditul propriu.

Limitări și ce e încă în plan

  • Tabelul de vizibilitate pe rol controlează ce module apar în meniu. Drepturile efective sunt verificate separat, în fiecare modul, pe baza rolurilor din token.
  • Contractul core_service trebuie completat cu rutele de roluri, setări, profil și audit pe care interfața le folosește deja.
  • Maparea automată din AD acoperă doar două roluri (it_staff, employee). Celelalte roluri se atribuie manual.
Înapoi laPrezentarea principală