Securitate tehnica
Standarde de
Securitate
MKWork Manager este construit cu securitatea ca prioritate de proiectare. Acest document descrie masurile tehnice si organizatorice implementate pentru a proteja datele organizatiei tale.
Criptare AES-256-GCM
Fisierele incarcate sunt criptate individual per organizatie cu chei unice derivate HKDF-SHA256.
Autentificare 2FA (TOTP)
Suport nativ Google Authenticator / Authy conform RFC 6238. Activabil per utilizator.
Izolare multi-tenant
Fiecare organizatie are schema PostgreSQL separata. Nicio interactiune intre tenant-uri posibila prin aplicatie.
Audit log complet
Toate actiunile sensibile sunt inregistrate cu utilizator, IP, timestamp si detalii complete.
CSP + Security Headers
Content-Security-Policy cu nonce unic per request, HSTS, X-Frame-Options, Referrer-Policy.
Rate Limiting
Limita de incercari pe login si endpoint-uri sensibile, cu blocare automata IP-uri abuzive.
01 Autentificare si gestionarea sesiunilor
| Masura | Detalii tehnice |
|---|---|
| Parole hash-uite | bcrypt cu factor de cost ridicat — rezistent la atacuri brute-force si rainbow table |
| 2FA TOTP | Conform RFC 6238, compatibil Google Authenticator, Authy si orice aplicatie TOTP standard. Activabil per utilizator. |
| Token server-side | La login se genereaza un token aleatoriu stocat server-side. La fiecare request tokenul este verificat timing-safe — sesiunile furate devin invalide imediat la deconectare |
| Cookie securizat | HttpOnly, SameSite=Lax, Secure — inaccesibil din JavaScript, protejat impotriva CSRF si MITM |
| Session fixation | ID sesiune regenerat la fiecare autentificare reusita |
| Logout complet | La deconectare, tokenul de sesiune este invalidat server-side — sesiunile furate nu mai pot fi reutilizate |
| Login lockout | Dupa mai multe incercari esuate, autentificarea este blocata temporar per IP si per cont |
02 Criptare date si fisiere
Fisierele incarcate in aplicatie (planuri tehnice, PDF-uri, fisiere GCode, modele 3D etc.) sunt criptate la stocare cand organizatia are criptarea activata.
| Element | Standard aplicat |
|---|---|
| Algoritm criptare fisiere | AES-256-GCM — autentificat, rezistent la modificari neautorizate |
| Cheie per organizatie | Fiecare organizatie are o cheie de criptare unica, derivata criptografic — compromiterea unui tenant nu afecteaza altii |
| Nonce unic | Nonce criptografic generat aleatoriu per fisier — garanteaza unicitatea cifrarii chiar pentru fisiere identice |
| Parola SMTP | Stocata criptat in baza de date, niciodata in plaintext |
| Secret webhook | Criptat la stocare, decriptat doar la momentul trimiterii; semnat HMAC-SHA256 la fiecare request outbound |
| Cheie aplicatie | Obligatorie explicit in productie — aplicatia refuza sa porneasca fara ea, previne deployuri cu chei nesigure |
03 Izolare multi-tenant
Arhitectura MKWork asigura separarea completa a datelor intre organizatii la nivel de baza de date.
- Fiecare organizatie are schema de baza de date separata — nu exista tabele partajate intre tenanti
- Sesiunile de baza de date sunt legate strict de organizatia autentificata — nu exista posibilitate de acces cross-tenant prin aplicatie
- Datele de administrare ale platformei sunt separate complet de datele operationale ale clientilor
- Cheile de criptare sunt derivate individual per organizatie — compromiterea unui cont nu expune datele altor organizatii
- Fiecare request verifica apartenenta resursei la organizatia curenta inainte de orice operatie
04 Securitatea aplicatiei web
| Vector de atac | Protectie implementata |
|---|---|
| CSRF | Token CSRF pe toate formularele POST cu expirare automata; API REST protejat prin autentificare dedicata, separat de sesiunea browser |
| XSS | Content-Security-Policy cu nonce unic per request si strict-dynamic — scripturi inline neautorizate sunt blocate de browser chiar daca sunt injectate |
| SQL Injection | SQLAlchemy ORM cu query-uri parametrizate — niciun SQL raw cu date de la utilizator |
| Path Traversal | Validare os.path.realpath() pe toate caile de fisiere inainte de operatii; werkzeug.utils.secure_filename() pe filename-uri incarcate |
| Open Redirect | Parametrul next de la login este validat strict — acceptat doar URL-uri relative din aceeasi origine |
| Clickjacking | X-Frame-Options: SAMEORIGIN — pagina nu poate fi inclusa in iframe de pe alte domenii |
| MIME Sniffing | X-Content-Type-Options: nosniff — browserul respecta tipul MIME declarat |
| Information Disclosure | Mesajele de eroare nu dezvaluie detalii interne (stack trace, versiuni, structura BD) catre utilizatori neautentificati |
05 Validare fisiere incarcate
Fisierele incarcate de utilizatori sunt supuse mai multor niveluri de validare inainte de stocare:
- Magic bytes validation — continutul real al fisierului este verificat (primii bytes), nu doar extensia declarata; un fisier
.pdfcu continut executabil este respins - Lista alba de tipuri — doar formatele permise explicit sunt acceptate per context (PDF, DXF, STL, STEP, GCode etc.)
- Checksum SHA-256 — calculat la upload; detecteaza duplicate si verifica integritatea la download
- Quota stocare — fiecare organizatie are o limita de spatiu configurabila per plan; upload-urile sunt respinse daca depasesc cota
- Monitorizare disk VPS — upload-urile sunt blocate automat la nivel global cand spatiul liber pe server scade sub pragul critic
- Path traversal — caile de fisiere sunt validate cu
realpath()inainte de scriere sau citire
06 HTTP Security Headers
Fiecare raspuns HTTP include urmatoarele headere de securitate:
| Header | Valoare / Efect |
|---|---|
| Content-Security-Policy | nonce-{random} per request, strict-dynamic — previne XSS prin scripturi neautorizate |
| Strict-Transport-Security | Forteaza conexiuni HTTPS pe termen lung pentru domeniu si subdomenii |
| X-Frame-Options | SAMEORIGIN — previne clickjacking |
| X-Content-Type-Options | nosniff — previne MIME sniffing |
| Referrer-Policy | strict-origin-when-cross-origin — limiteaza informatiile trimise la navigare inter-domeniu |
| Permissions-Policy | geolocation=(), camera=(), microphone=() — dezactiveaza accesul la senzori si periferice |
07 Rate Limiting si protectie brute-force
- Login — numar limitat de cereri per IP cu blocare automata dupa depasire
- Blocare cont — dupa mai multe incercari esuate consecutive, autentificarea este suspendata temporar per IP
- API REST — rate limit per endpoint, raspunsurile includ informatii despre limita ramasa
- Formulare publice — endpoint-urile publice au limite separate, mai restrictive
Protectia brute-force este activa atat per IP cat si per cont, prevenind atacurile distribuite si cele tintite.
08 Securitatea integrarilor externe
| Integrare | Masuri de securitate |
|---|---|
| Webhook outbound |
Semnat HMAC-SHA256 cu secret unic per client, stocat criptat. Validare SSRF: URL-urile catre retele private si localhost sunt refuzate automat. |
| SMTP email |
Credentialele SMTP stocate criptat, niciodata in plaintext. Verificare certificat SSL/TLS activa implicit. Headerele email sunt sanitizate impotriva header injection. |
| Link acces client |
Token criptografic aleatoriu cu expirare configurabila. Acces read-only la statusul comenzii, fara date sensibile. |
| API REST |
Cheile API sunt asociate unui utilizator si au scopuri definite (citire / scriere). Pot fi revocate oricand. Toate apelurile sunt inregistrate in jurnalul de audit. |
| SSO / SAML 2.0 |
Configurabil per organizatie (plan Enterprise). Metadatele IdP sunt validate la configurare. |
09 Controlul accesului bazat pe roluri (RBAC)
Fiecare utilizator are un rol cu un set de permisiuni. Accesul la resurse este verificat la nivel de ruta si la nivel de obiect.
| Rol | Accese principale |
|---|---|
| Operator / User | Lucru pe reperele proprii, pontaj propriu, vizualizare comenzi |
| CTC | Calitate, NCR, CoC, vizualizare toate reperele |
| Director | Vizualizare rapoarte si KPI-uri |
| Sef productie | Gestionare productie, atribuiri, planificare |
| Moderator | Creare/editare repere, proiecte, pontaj toti angajatii |
| Admin | Acces complet la organizatie, utilizatori, setari |
Conturile de administrare a platformei sunt complet separate de conturile organizatiilor si nu au acces implicit la datele operationale ale clientilor.
10 Audit Log
Toate actiunile sensibile sunt inregistrate automat in jurnalul de audit al organizatiei (disponibil in planurile Pro si Enterprise).
- Ce se inregistreaza — autentificari, modificari utilizatori, creare/editare/stergere repere si proiecte, modificari setari, actiuni API, evenimente de securitate
- Ce contine o intrare — categorie, actiune, descriere, utilizator, adresa IP, timestamp UTC, severitate
- Detectie IP — suport pentru deployuri in spatele unui reverse proxy, cu detectie corecta a IP-ului real
- Arii auditate — autentificare, utilizatori, proiecte, repere, materiale, calitate, administrare, API, billing, securitate
Audit log-ul este per organizatie — fiecare tenant are propriul istoric complet, izolat de alte organizatii.
11 Detectie scanere si boti
- Activitatea de scanare automata este detectata si blocata
- Tentativele de acces la cai neexistente sau specifice altor platforme sunt inregistrate si monitorizate
- Activitatea de scanning este inregistrata pentru analiza ulterioara
12 Raportarea vulnerabilitatilor
Daca ai descoperit o vulnerabilitate de securitate in MKWork Manager, te rugam sa ne contactezi inainte de divulgare publica:
Email securitate: contact@mkwork.ro
Raspundem in maximum 72 de ore. Vulnerabilitatile confirmate sunt corectate prioritar, inaintea oricaror alte task-uri.
Programul nostru de responsible disclosure cere:
- Nu accesa, modifica sau sterge date ale altor utilizatori
- Nu efectua atacuri de tip DoS sau care pot afecta disponibilitatea serviciului
- Raporteaza vulnerabilitatea in mod privat inainte de orice divulgare publica