Prezentare generală a securității

Versiune: 0.1-draft Data intrării în vigoare: încă nu este în vigoare (proiect)

Proiect care urmează să fie revizuit de un avocat român calificat înainte de utilizare. Elementele marcate [De confirmat] trebuie confirmate de echipa tehnică înainte de publicarea acestei pagini. Ele corespund măsurilor marcate „[de confirmat înainte de semnare]” în Anexa 2 la data-processing-agreement.md, iar ambele documente trebuie actualizate în același timp.

1. Despre această pagină

1.1 Această pagină descrie, pe înțelesul tuturor, modul în care ALTTAB PROFIT SRL, societate cu răspundere limitată („Compania”) protejează Platforma 1ads și Datele Clientului. Ea descrie măsurile de protecție pe care le avem astăzi, ce nu am făcut încă și ce planificăm.

1.2 Această pagină are caracter informativ. Angajamentele contractuale ale Companiei privind securitatea sunt stabilite în Termeni (terms-of-service.md) și în Acordul de prelucrare a datelor (data-processing-agreement.md), inclusiv în descrierea măsurilor tehnice și organizatorice potrivit articolului 32 GDPR. Dacă această pagină și documentele respective diferă, prevalează documentele respective.

1.3 Certificări. În prezent, Compania nu deține SOC 2, ISO/IEC 27001 sau orice altă certificare ori atestare de securitate. Nu pretindem conformitatea cu niciun standard de certificare. A se vedea secțiunea 11 pentru planurile noastre.

2. Arhitectură și găzduire

2.1 Platforma rulează pe clusterul Kubernetes on-prem propriu al Companiei, aflat în România (UE) și operat chiar de Companie, sub brandul său FirstIT. Platforma nu rulează într-un cloud public, iar clusterul nu este operat de un terț, astfel încât nu există un subîmputernicit pentru găzduire (subprocessors.md).

2.2 Următoarele componente rulează în interiorul acestui cluster și nu sunt expuse ca servicii publice: bazele de date PostgreSQL, gestionarea secretelor (HashiCorp Vault), coada de sarcini de fundal (graphile-worker, pe PostgreSQL) și furnizorul de identitate pentru autentificare, SSO și MFA (Keycloak, găzduit de noi la auth.1ads.net). Niciuna dintre ele nu este expusă direct în internet: numai serverul web de la marginea rețelei (Caddy) este accesibil din internet și publică paginile de autentificare Keycloak, iar interfața de administrare Keycloak este accesibilă numai de la o listă de adrese permise. Pentru urmărirea erorilor se folosește instanța Sentry găzduită și operată de Companie, sub brandul său FirstIT, în aceeași infrastructură [De confirmat: expunerea în rețea a punctului de acces Sentry și regula din politica de rețea care permite componentelor api și worker să îi raporteze erorile]. Comunicarea dintre componente este restricționată prin politici de rețea Kubernetes de tip „interzis implicit” (default-deny): fiecare componentă poate accesa numai componentele de care are nevoie.

2.3 Unele funcții se bazează pe subîmputerniciți (persoane împuternicite secundare), de exemplu furnizorii de modele AI și emailul tranzacțional (Amazon SES, în UE). Lista completă, cu locațiile și scopurile, se găsește în subprocessors.md. Platformele Terțe pe care Clientul le conectează (platforme de publicitate, analiză, ecommerce, CRM și rețele sociale), precum și furnizorii de identitate pe care Clientul îi folosește pentru SSO, sunt furnizorii proprii ai Clientului, nu subîmputerniciții noștri.

2.4 Site-ul public https://1ads.net este un site static servit de același server de la marginea rețelei. La lansare, site-ul nu folosește instrumente de analiză sau de publicitate.

3. Izolarea clienților (tenanților)

3.1 Platforma este multi-tenant. Datele Clientului sunt separate logic pe fiecare client (tenant) și, în cadrul unui tenant, pe fiecare spațiu de lucru al unui client (workspace). Fiecare acces la Datele Clientului este limitat la tenantul și spațiul de lucru ale utilizatorului autentificat. Separarea este impusă în baza de date prin politici PostgreSQL de securitate la nivel de rând (row-level security) pe tenant și pe spațiu de lucru, pe lângă verificările din aplicație. Rolurile de bază de date ale aplicației nu pot ocoli securitatea la nivel de rând (niciunul nu este superuser și niciunul nu are atributul BYPASSRLS). Numai rolul de salvare are atributul BYPASSRLS, pentru a permite exporturi complete ale bazei de date. Acest rol are drept exclusiv de citire (rolul predefinit PostgreSQL pg_read_all_data), nu poate modifica date și este folosit numai de procesul zilnic de salvare. [De confirmat: prima salvare și prima restaurare reușite.] Formularul public de cerere de acces folosește un rol de bază de date separat, care poate doar să adauge cereri noi și nu poate citi niciun fel de date.

3.2 Datele primite de la o Platformă Terță pentru un Client sunt folosite numai pentru acel Client. Nu combinăm astfel de date între Clienți (de exemplu, conform cerinței din secțiunea 5.b a Termenilor Meta pentru platformă).

4. Criptare

4.1 În tranzit, prin rețele publice. Toate punctele de acces publice (https://1ads.net, https://app.1ads.net, API-ul REST, serverul MCP și paginile de autentificare) sunt servite prin TLS de serverul web de la marginea rețelei (Caddy), cu certificate Let's Encrypt și HTTP Strict Transport Security (HSTS). [De confirmat: versiunea minimă TLS 1.2.]

4.2 În rețeaua privată a clusterului. Traficul dintre componentele din interiorul clusterului (de exemplu, între aplicație și PostgreSQL sau între serviciul de tokenuri și Vault) nu este criptat în prezent. El circulă într-o singură rețea privată și este restricționat prin politici de rețea de tip „interzis implicit”. Criptarea acestui trafic intern (Cilium WireGuard sau TLS) este planificată înainte de disponibilitatea generală. [Planificat – neimplementat încă]

4.3 În repaus. Copiile de rezervă zilnice ale bazelor de date sunt criptate (a se vedea secțiunea 7.3). Criptarea în repaus a discurilor serverelor, inclusiv a volumelor bazelor de date: [De confirmat cu responsabilul infrastructurii]. Nu afirmăm criptarea discurilor până când aceasta nu este confirmată.

4.4 Tokenuri OAuth și date de autentificare. Tokenurile pentru conturile conectate ale Clientului sunt criptate cu motorul Transit al HashiCorp Vault (AES-256-GCM), cu o cheie derivată separat pentru fiecare tenant, conexiune și furnizor. Materialul cheilor nu părăsește niciodată Vault. Numai un serviciu de tokenuri izolat poate cere Vault să cripteze sau să decripteze tokenuri și face acest lucru numai atunci când este necesar pentru a apela API-ul Platformei Terțe relevante. Tokenurile nu sunt transmise niciodată modelelor AI. [De confirmat: excluderea tokenurilor din jurnale și din rapoartele de erori.]

5. Identitate și acces

5.1 Utilizatorii Clientului. (a) Autentificarea, SSO și MFA sunt gestionate de furnizorul nostru de identitate găzduit de noi (Keycloak). Autentificarea unică (SSO) este disponibilă prin federare cu furnizorul de identitate propriu al Clientului, de exemplu Okta, Microsoft Entra ID, Google Workspace sau OneLogin; SSO se configurează manual pentru fiecare Client. Sincronizarea automată a directoarelor (crearea și dezactivarea conturilor prin SCIM) nu este disponibilă la lansare; atunci când o persoană pleacă, Clientul o elimină din Platformă (secțiunea 12.1 lit. (a)). Un furnizor de identitate e inclus pe Pro, Agency 15 și Agency, mai mulți pe Enterprise; pe Starter, Growth și Agency Starter, SSO e supliment per furnizor de identitate (Formularul de Comandă C.2 și C.3). (b) Autentificarea multifactor (MFA) este obligatorie pentru toți utilizatorii care nu se autentifică prin SSO. (c) Rolurile și permisiunile stabilesc cine poate vedea date, crea propuneri, aproba modificări și publica conținut. Fluxurile de aprobare pot include mai mulți pași (de exemplu întâi agenția și apoi clientul). (d) Pe durata programului cu acces închis, conturile sunt create numai după ce Compania analizează și aprobă manual cererea de acces.

5.2 API și MCP. Serverul MCP folosește OAuth 2.1. Accesul prin API este limitat la permisiunile (scopurile) acordate. [De confirmat: limitarea permisiunilor, rotirea și expirarea cheilor API.]

5.3 Personalul Companiei. [De confirmat: accesul personalului pe principiul privilegiului minim, MFA pentru orice acces administrativ, jurnalizarea accesului administrativ la mediul de producție și regulile privind accesul personalului de suport la Datele Clientului, de exemplu numai la cererea Clientului.]

6. Măsuri de protecție specifice AI

6.1 Aprobare umană. AI-ul nu execută niciodată singur modificări în conturile de publicitate și nu publică niciodată singur conținut. Modificările se execută doar după ce o persoană autorizată le aprobă sau, atunci când va fi disponibilă, în baza unei politici de aprobare automată configurate de Client în limitele maxime ale Platformei. Politicile de aprobare automată sunt dezactivate pe durata Programului de Acces (access-program-terms.md, Secțiunea 8.5), fără excepții. A se vedea ai-transparency-notice.md.

6.2 Jurnal de audit. Fiecare propunere, aprobare și acțiune executată este înregistrată într-un jurnal de audit, cu identificatori de utilizator pseudonimizați.

6.3 Protecție împotriva prompt injection. Conținutul provenit din pagini web, comentarii, fluxuri de produse și documente este tratat ca date nesigure. Funcționalitățile AI nu pot executa acțiuni pe cont propriu; instrumentele disponibile AI-ului sunt limitate la ceea ce are nevoie funcționalitatea; iar fiecare modificare necesită aprobare. Rămâne un risc rezidual, descris în ai-transparency-notice.md.

6.4 Datele de autentificare rămân în afara prompturilor. Tokenurile OAuth și secretele nu sunt incluse niciodată în instrucțiunile (prompturile) transmise modelelor AI.

6.5 Observabilitatea modelelor AI. Monitorizăm calitatea și erorile AI cu Langfuse, găzduit de noi în propria infrastructură, cu redactarea datelor cu caracter personal.

6.6 Furnizorii de modele. Folosim API-urile comerciale ale Anthropic (furnizorul nostru principal; implicit Claude Opus 5.5 pentru chatul AI) și OpenAI (generarea de imagini și, opțional, anumite sarcini de text). Potrivit termenilor aplicabili în prezent, aceștia nu își antrenează modelele pe datele transmise prin API. Am solicitat de la Anthropic păstrarea zero a datelor (zero data retention). Nu folosim Datele Clientului pentru a antrena modele AI.

6.7 Web Intelligence. Web Intelligence citește numai pagini publice, respectă robots.txt și rezervele privind extragerea de text și date și nu se autentifică niciodată pe site-uri.

7. Jurnalizare, monitorizare și copii de rezervă

7.1 Urmărirea erorilor. Folosim Sentry, găzduit de noi în propria infrastructură, pentru urmărirea erorilor din aplicație pe partea de server. Datele despre erori nu sunt transmise unui serviciu extern de urmărire a erorilor. [De confirmat: eliminarea datelor cu caracter personal și a secretelor din rapoartele de erori.]

7.2 Monitorizare și alertare. [De confirmat: monitorizarea infrastructurii, alertarea și regimul de permanență.]

7.3 Copii de rezervă. Bazele de date PostgreSQL sunt salvate în fiecare noapte prin exporturi logice (dump-uri). Fiecare export este criptat cu age (X25519) înainte de a fi scris pe un spațiu de stocare în rețea din aceeași locație, care reprezintă un domeniu de defectare separat de discul bazei de date. În cluster se află numai cheia publică de criptare; cheia privată, necesară pentru restaurare, este păstrată offline. Copiile de rezervă sunt șterse după cel mult 14 zile. Procesul de salvare folosește un rol de bază de date cu drept exclusiv de citire. [De confirmat: prima salvare și prima restaurare reușite.] [De confirmat: testarea restaurării, planificată trimestrial.] Până la introducerea replicării bazei de date, o defecțiune poate duce la pierderea datelor din cel mult ultimele 24 de ore (obiectiv privind punctul de recuperare de 24 de ore).

8. Repere privind perioadele de păstrare

8.1 Anumite date au, în mod implicit, perioade scurte de păstrare: (a) comentariile și mesajele directe din conturile sociale conectate: 30 de zile, în mod implicit; (b) datele membrilor LinkedIn: cel mult 24 de ore, conform termenilor API LinkedIn; (c) copiile de rezervă ale bazelor de date: șterse după cel mult 14 zile; (d) amprenta pseudonimizată a adresei IP și agentul utilizatorului (user agent) înregistrate odată cu cererile de acces, precum și amprenta pseudonimizată a adresei IP și datele despre browser înregistrate odată cu cererile de estimare a ROI: șterse după 30 de zile.

8.2 Regulile complete privind păstrarea, inclusiv ștergerea la încetarea contractului, se găsesc în data-retention-schedule.md, iar rezumate ale acestora se găsesc în privacy-policy.md și data-processing-agreement.md.

9. Dezvoltare și operare în siguranță

9.1 Implementările în producție trec prin fluxuri automate (Jenkins) și GitOps (Flux): modificările în producție se fac prin configurații versionate, nu manual.

9.2 Secretele sunt stocate în Vault, nu în codul sursă, și sunt livrate separat fiecărei componente, astfel încât fiecare componentă primește numai propriile secrete.

9.3 Imaginile de containere sunt scanate pentru vulnerabilități cunoscute (Trivy) în fluxul de compilare, înainte de implementare. [De confirmat: revizuirea obligatorie a codului înainte de integrare, scanarea vulnerabilităților din dependențe, termenele de aplicare a actualizărilor de securitate și separarea mediilor de dezvoltare, testare (staging) și producție.]

9.4 Formularul de cerere de acces. Formularul public de cerere de acces este protejat împotriva spamului și a abuzurilor printr-un câmp ascuns de tip „capcană” (honeypot) și prin verificarea duratei în care formularul a fost deschis, fără niciun CAPTCHA furnizat de terți și fără cookie-uri. Stocăm o amprentă pseudonimizată a adresei IP a expeditorului (SHA-256 cu sare, trunchiată) și agentul utilizatorului (user agent) al browserului, ambele șterse după 30 de zile. E-mailul de confirmare trimis solicitantului are un text fix, nu reia niciodată informațiile transmise și se trimite cel mult o dată la 24 de ore pentru aceeași adresă.

10. Răspunsul la incidente

10.1 Avem o procedură pentru detectarea, evaluarea și gestionarea incidentelor de securitate. [De confirmat: existența unei proceduri scrise de răspuns la incidente înainte de publicare.]

10.2 Atunci când un incident afectează date cu caracter personal pe care le prelucrăm ca persoană împuternicită în numele unui Client, notificăm Clientul fără întârzieri nejustificate, conform data-processing-agreement.md, pentru ca acesta să își poată îndeplini propriile obligații.

10.3 Atunci când acționăm ca operator (de exemplu pentru datele de cont și de contact), notificăm Autoritatea Națională de Supraveghere a Prelucrării Datelor cu Caracter Personal (ANSPDCP) în termen de 72 de ore de la momentul în care am luat cunoștință de o încălcare a securității datelor cu caracter personal, cu excepția cazului în care este puțin probabil ca încălcarea să genereze un risc pentru persoane, și informăm persoanele vizate atunci când articolul 34 GDPR o impune.

10.4 Continuitatea activității. Nu ne-am asumat încă obiective formale privind timpul de recuperare sau punctul de recuperare. Punctul tehnic de recuperare actual este de cel mult 24 de ore (secțiunea 7.3); replicarea bazei de date cu arhivare continuă este planificată înainte de disponibilitatea generală. Orice angajamente privind nivelul serviciilor sunt cele stabilite în service-level-and-support.md și în Formularul de Comandă.

11. Stadiul conformității și planuri

11.1 Stadiul actual. Nicio certificare sau atestare din partea unei terțe părți. [De confirmat: dacă a fost efectuat un test de penetrare independent și, în caz afirmativ, când.]

11.2 Planificat. [De confirmat: planul de certificare urmează să fie confirmat de fondator.] Vom actualiza această pagină dacă se planifică un audit.

11.3 Chestionare. Putem răspunde la chestionare rezonabile de securitate din partea Clienților și a potențialilor clienți, în baza unui acord de confidențialitate atunci când este necesar. Scrieți la ops@1ads.net.

12. Responsabilitate partajată

12.1 Securitatea este o responsabilitate partajată. Clientul răspunde pentru: (a) gestionarea Utilizatorilor Autorizați, a rolurilor și a aprobatorilor, precum și pentru retragerea promptă a accesului persoanelor care pleacă; (b) folosirea SSO sau MFA și protejarea datelor de autentificare, a cheilor API și a clienților OAuth; (c) acordarea doar a permisiunilor necesare la conectarea Platformelor Terțe și revocarea conexiunilor de care nu mai are nevoie; (d) configurarea atentă a fluxurilor de aprobare și, atunci când vor fi disponibile, a politicilor de aprobare automată; (e) verificarea clienților MCP și a agenților AI pe care îi conectează la Platformă; (f) securitatea propriilor sisteme și a Platformelor Terțe pe care le folosește.

13. Raportarea vulnerabilităților

13.1 Cum raportați. Dacă considerați că ați descoperit o vulnerabilitate de securitate în Platformă, vă rugăm să scrieți la ops@1ads.net, cu o descriere, URL-ul sau componenta afectată, pașii de reproducere și impactul potențial. Vă rugăm să nu includeți în raport date cu caracter personal ale altor persoane decât în măsura strict necesară. [De confirmat: publicarea fișierului /.well-known/security.txt (RFC 9116) și a unei chei PGP.]

13.2 Ce facem. Ne propunem să confirmăm primirea raportului în 2 Zile Lucrătoare, să vă informăm despre progresul nostru și să vă anunțăm când problema a fost remediată. Cu acordul dumneavoastră, vă vom menționa public după rezolvarea problemei.

13.3 Inclus în program. https://1ads.net, https://app.1ads.net, API-ul REST public și serverul MCP operate de Companie.

13.4 Exclus din program. Platformele Terțe, serviciile subîmputerniciților noștri, domeniile white-label operate de Clienți care nu sunt găzduite de Companie, ingineria socială asupra personalului sau Clienților, atacurile fizice, atacurile de tip denial-of-service și scanările automate care generează trafic semnificativ.

13.5 Reguli de testare. Vă rugăm: (a) să folosiți numai conturi care vă aparțin sau conturi de test furnizate de noi. Deoarece în prezent accesul se acordă numai pe bază de aprobare, puteți solicita un tenant de test la ops@1ads.net; (b) să nu accesați, modificați sau ștergeți datele altor utilizatori ori Clienți; dacă dați peste astfel de date, opriți-vă, nu păstrați o copie și anunțați-ne; (c) să nu degradați serviciul și să nu afectați alți utilizatori; (d) să nu exploatați vulnerabilitatea dincolo de minimul necesar pentru a o demonstra; (e) să ne acordați un termen rezonabil pentru remediere înainte de orice dezvăluire publică; propunem 90 de zile sau un termen mai scurt, dacă ne înțelegem astfel; (f) să respectați legea.

13.6 Protecție pentru cercetarea de bună-credință (safe harbour). Dacă acționați cu bună-credință și respectați aceste reguli, vom considera cercetarea dumneavoastră autorizată, nu vom introduce acțiuni în justiție și nu vom depune plângeri penale împotriva dumneavoastră în legătură cu aceasta și nu vom cere altcuiva să o facă. Dacă un terț introduce o acțiune împotriva dumneavoastră pentru cercetări efectuate cu respectarea acestor reguli, vom face cunoscut faptul că cercetarea a fost autorizată de noi. Această protecție acoperă numai sistemele operate de Companie; nu putem autoriza testarea sistemelor care aparțin altora, precum Platformele Terțe sau subîmputerniciții. Ea nu acoperă activitățile care încalcă regulile de mai sus sau legea.

13.7 Fără program de recompense. În prezent nu oferim recompense bănești pentru raportări.

14. Contact

• Raportări de securitate și chestionare: ops@1ads.net
• Întrebări privind datele cu caracter personal: privacy@1ads.net
• Suport: support@1ads.net