Aceasta este versiunea în limba română, cea care prevalează în raporturile cu consumatorii.Read in English
GPTpostLLM Legal

Securitate

Acest document descrie modul în care este protejat GPTpostLLM la https://app.oraglegpt.org și unde nu este. Este publicat de TRIIVON S.R.L., ale cărei date de identificare se află în Date de identificare.

Este redactat pentru a fi verificat, nu pentru a fi crezut. Fiecare măsură de mai jos corespunde unui element implementat în aplicația aflată în funcțiune. Atunci când o măsură pe care un cititor ar putea-o aștepta în mod rezonabil lipsește sau este mai slabă decât o valoare implicită obișnuită, ea este enumerată în secțiunea 11, în loc să fie omisă. O pagină de securitate care enumeră numai punctele tari nu vă spune nimic, pentru că nu puteți distinge dacă omisiunile sunt absențe sau tăcere. Așadar, secțiunea privind limitările este partea acestei pagini pe care o considerăm esențială.

1. Ce acoperă acest document

Acoperă aplicația, depozitul ei de date și serverele care le rulează. Nu descrie securitatea internă a platformelor sociale pe care publicați. Acelea sunt servicii independente, cu propriile măsuri de control, iar conexiunea noastră cu ele este restrânsă într-un mod prezentat în secțiunea 8.

Două fapte despre produs delimitează tot restul acestei pagini, pentru că elimină clase întregi de riscuri pe care un produs similar le-ar purta:

2. Autentificare și sesiuni

Parolele sunt stocate ca derivări PBKDF2-HMAC-SHA256, cu 210.000 de iterații și o sare aleatorie de 16 octeți pentru fiecare parolă. Verificarea se face în timp constant. Parola în clar nu este scrisă niciodată în stocare sau într-un jurnal.

Sesiunile sunt jetoane purtătoare opace, nu JWT-uri. Un identificator de sesiune are 32 de octeți dintr-o sursă aleatorie sigură din punct de vedere criptografic și este stocat pe server. Nu poartă niciun element lizibil, prin urmare nimic despre contul dumneavoastră nu poate fi decodat din el, iar revocarea lui pe server produce efecte imediat, fără a aștepta expirarea unui jeton.

Proprietatea sesiuniiValoare
Durată absolută12 ore de la autentificare
Expirare la inactivitate2 ore fără activitate
Durată absolută pentru operatorul platformei30 de minute
Expirare la inactivitate pentru operatorul platformei15 minute
Fereastra de reautentificare suplimentară10 minute
Modul cookieorbitpost_session, HttpOnly, Secure, SameSite=Lax

Operațiunile sensibile impun o reautentificare suplimentară: dacă nu v-ați dovedit identitatea în ultimele 10 minute, vi se cere din nou înainte ca operațiunea să continue, chiar dacă sesiunea dumneavoastră este încă valabilă.

Cererile care modifică date sunt verificate în plus în raport cu originea cererii, astfel încât un site ostil nu poate face browserul dumneavoastră să acționeze pe sesiunea dumneavoastră. Evidențele de sesiune sunt ele însele păstrate sub izolarea între clienți descrisă în secțiunea 5.

Răspunsurile la autentificare sunt întărite împotriva enumerării utilizatorilor: durata și conținutul răspunsului la o încercare de autentificare nu dezvăluie dacă o adresă este înregistrată.

3. Autentificare multifactorială

Parolele de unică folosință bazate pe timp sunt implementate conform RFC 6238, cu un pas de 30 de secunde, o fereastră de verificare de plus sau minus un pas și comparare în timp constant a codului transmis.

MFA este opțională pentru utilizatorii obișnuiți. O puteți activa pentru propriul cont și vă recomandăm să o faceți, dar aplicația nu o impune, iar noi nu vom pretinde pe această pagină că o impune. Este obligatorie numai pentru conturile de operator al platformei, care sunt conturile deținute de personalul propriu al societății.

Un detaliu onest care decurge de aici: secretele MFA sunt stocate ca simple câmpuri de bază de date, necriptate de aplicație. Ele sunt mascate atunci când sunt citite prin API. Se supun izolării între clienți și controalelor de acces la baza de date, dar nu se află în lista câmpurilor criptate din secțiunea 4, iar noi nu vom sugera că s-ar afla.

Această implementare nu oferă nicio autentificare fără parolă sau cu cheie hardware. Există cod în depozit legat de aceasta, dar el nu acordă nicio sesiune și nu poate autentifica pe nimeni, prin urmare nu este o funcționalitate și nu ar trebui să contați pe ea.

4. Ce este criptat și ce nu

Aceasta este secțiunea în care produsele exagerează cel mai des. Situația exactă este prezentată mai jos.

Criptarea la nivel de aplicație este AES-256-GCM, cu șirul de context legat ca date suplimentare autentificate, și este aplicată exclusiv unor câmpuri de credențiale specifice:

Acea listă descrie ce câmpuri sunt criptate atunci când conțin o valoare. Nu este o afirmație potrivit căreia fiecare funcționalitate care folosește unul dintre acele câmpuri este activată în această implementare.

Ce nu este criptat de aplicație: conținutul dumneavoastră de business. Postările, ciornele, campaniile, programările, contactele, metadatele fișierelor media și observațiile analitice sunt stocate fără criptare la nivel de aplicație. Ele sunt protejate prin izolarea între clienți din secțiunea 5, prin autentificare și prin controalele de acces de pe server, nu printr-un cifru din aplicație.

Alte două aspecte pe care pagini similare le trec de obicei sub tăcere:

Așadar, propoziția "toate datele sunt criptate în repaus" este falsă aici, iar noi nu o vom scrie. Ce este adevărat este că credențialele care i-ar permite cuiva să acționeze în numele dumneavoastră pe o platformă socială sunt criptate, iar conținutul dumneavoastră nu este.

Datele în tranzit sunt protejate prin TLS. Certificatele sunt emise de Let's Encrypt prin ACME și sunt terminate de proxy-ul invers Caddy.

5. Izolarea între clienți

Spațiile de lucru sunt izolate prin securitatea la nivel de rând din PostgreSQL, care este atât ENABLED, cât și FORCED pe tabelele care contează: înregistrări, chei de idempotență, coada de sarcini, coada de ieșire tranzacțională, jurnalul de audit și sesiunile. FORCED contează pentru că înseamnă că politica se aplică și proprietarului tabelei, în loc să fie ocolită de acesta.

Identitatea clientului folosită de politică provine din sesiunea stocată pe server, niciodată din cerere. Un client nu poate selecta un spațiu de lucru trimițând un antet, un parametru sau un element dintr-un jeton.

Acest lucru este verificat printr-un test care deschide o conexiune brută la baza de date în afara contextului de client al aplicației și confirmă că citește zero rânduri. Producția rulează acest profil PostgreSQL, prin urmare izolarea descrisă aici este izolarea care este implementată, nu o configurație care există numai în mediul de dezvoltare.

6. Jurnalul de audit

Jurnalul de audit este cea mai puternică măsură de control din produs și merită înțeles cu precizie.

Citirile nu sunt auditate. Nu există niciun jurnal de acces care să consemneze cine a vizualizat o înregistrare. Dacă cerința dumneavoastră este "arătați-mi toate persoanele care s-au uitat la acest contact", acest produs nu poate răspunde. Poate răspunde la "arătați-mi tot ce a fost modificat, de cine, când, și dovediți că înregistrarea nu a fost editată de atunci".

7. Limitarea ratei și controalele împotriva abuzurilor

Limitarea ratei este o fereastră fixă în proces, de 900 de cereri pe minut per adresă IP, aplicată per replică. Dacă rulează mai multe replici, plafonul efectiv este acel număr înmulțit cu numărul de replici, pentru că numărătoarele nu sunt partajate.

Nu există nicio limitare a ratei specifică autentificării și nicio blocare a contului. Încercările de autentificare sunt supuse numai limitei generale de mai sus. Aceasta este o slăbiciune reală și este enumerată din nou în secțiunea 11. Măsurile de atenuare care există sunt costul de calcul al derivării parolei din secțiunea 2, comportamentul de autentificare rezistent la enumerare și MFA opțională. Dacă vă contează contul, activați MFA.

8. Siguranța cererilor de ieșire

Aplicația face cereri de ieșire către API-urile platformelor sociale și către puncte finale configurate de clienți. Acele cereri sunt constrânse, ceea ce împiedică folosirea unui URL furnizat de un client pentru a ajunge în interiorul rețelei noastre:

Rețineți forma acestei măsuri: este o listă de interdicții, nu o listă de permisiuni. Blochează destinațiile cunoscute ca periculoase, în loc să permită numai un set aprobat.

Pe partea de intrare, singurele apeluri de retur de la furnizori pe care aplicația le acceptă sunt cele de ștergere a datelor și de dezautorizare de la Meta, exclusiv pentru facebook, instagram și threads. Ele sunt verificate printr-o semnătură HMAC-SHA256, cu o fereastră de prospețime de cinci minute. Nu există niciun alt receptor de intrare. Funcționalitatea de "webhook-uri" destinată clienților este exclusiv de ieșire.

9. Datele pe care le puteți scoate și datele pe care le eliminăm

Exportul este disponibil în interfață, la Setări, Confidențialitatea datelor. Rulează sincron și returnează o arhivă ZIP semnată, denumită cu extensia .optenant, care conține manifest.json și records.json și acoperă 48 de familii de resurse, cu un rezumat criptografic SHA-256 al conținutului și o semnătură HMAC asupra manifestului, astfel încât puteți verifica dacă fișierul a fost alterat. Credențialele stocate nu sunt niciodată incluse într-un export.

Importul și restaurarea nu sunt disponibile. Există cod, dar nu există nicio rută și niciun apelant, prin urmare un export este o arhivă lizibilă a datelor dumneavoastră, nu o copie de siguranță pe care o puteți reîncărca.

Ștergerea contului se solicită prin API, la POST /api/v1/privacy/deletion-requests, și se execută după o perioadă de grație de 30 de zile, care este o constantă la compilare, este impusă înainte de executarea ștergerii și poate fi anulată în interiorul ferestrei. Ecranul Confidențialitatea datelor nu are un buton de ștergere a contului. O instrucțiune de ștergere primită de la Meta prin apelul de retur din secțiunea 8 nu are perioadă de grație și este pusă în coadă imediat.

Închiderea spațiului de lucru folosește o fereastră de 30 de zile în care spațiul de lucru rămâne lizibil și exportabil, trecând prin stările activ, în curs de ștergere și închis, și poate fi anulată prin redeschidere. Ștergerea finală de la sfârșitul acelei ferestre este realizată de noi ca un angajament operațional, nu de o sarcină automată: curățarea automată rulează în mod exclusiv de raportare în această implementare. Fereastra și data ștergerii sunt reale și sunt consemnate pe înregistrare. Executarea este o promisiune a societății, iar noi preferăm să ne țineți de o promisiune pe care o puteți vedea decât să vă încredeți într-o automatizare pe care nu am activat-o. Mecanismul complet se află în Politica de ștergere a datelor.

10. Infrastructură, disponibilitate și copii de siguranță

Aplicația, baza de date, stocarea de obiecte și procesarea media rulează toate pe un singur server din Lauterbourg, Franța. Acest site juridic și căsuța poștală a societății rulează pe un al doilea server din Germania. Ambele sunt închiriate de la Contabo GmbH, care este singurul furnizor de infrastructură. Ambele se află în UE. Lista completă se găsește în Subîmputerniciți.

Depozitul de date este PostgreSQL 18 cu sume de control ale datelor activate, în spatele PgBouncer în mod de grupare pe tranzacții. Nu există Redis și niciun broker de mesaje: punerea în coadă este o coadă de ieșire tranzacțională și un tabel de sarcini în aceeași bază de date, ceea ce înseamnă că o sarcină nu poate fi acceptată decât dacă modificarea care a creat-o a fost confirmată. Stocarea de obiecte folosește protocolul S3, dar este găzduită pe propriul nostru server, nu la un furnizor de stocare în cloud. Procesarea media este ffmpeg care rulează ca subproces local; nimic nu este trimis către un serviciu de transcodare.

Disponibilitate. Aceasta este o implementare pe un singur server, fără preluare automată în altă regiune și fără cluster de înaltă disponibilitate. Nu publicăm nicio cifră de disponibilitate pe această pagină. Orice angajament de disponibilitate care există este cel din Termeni și condiții, iar incidentele curente se află la Starea serviciului.

Copii de siguranță. Nu vom tipări aici un program al copiilor de siguranță, o perioadă de păstrare sau un obiectiv de timp de recuperare, pentru că o cifră pe o pagină nu vă este de niciun folos dacă nu este cifra aflată efectiv în vigoare. Dacă procedura dumneavoastră de achiziții are nevoie de o declarație privind frecvența copiilor de siguranță, păstrarea și testarea restaurării, întrebați la contact@oraglegpt.org și veți primi situația așa cum stă efectiv la data la care întrebați. Ce puteți face fără să întrebați pe nimeni este să vă faceți propria copie, folosind exportul din secțiunea 9.

11. Limitări cunoscute

Enunțate simplu, la data menționată în partea de sus a acestei pagini.

  1. Nicio limitare a ratei specifică autentificării și nicio blocare a contului. Autentificarea este acoperită numai de limita generală per IP din secțiunea 7.
  2. Limitarea ratei este per replică, nu partajată, prin urmare plafonul efectiv crește cu numărul de replici în funcțiune.
  3. Conținutul de masă al clienților nu este criptat de aplicație. Sunt criptate numai câmpurile de credențiale enumerate în secțiunea 4.
  4. Nu există nicio criptare a întregului disc sau la nivel de bază de date configurată în această implementare.
  5. Criptarea folosește o singură cheie statică. Nu există nicio cheie per client și aceasta nu este criptare de tip anvelopă.
  6. Rotația cheilor nu acoperă baza de date pe acest profil. Instrumentarul de rotație există, dar nu recriptează câmpurile stocate aici, prin urmare nu promitem rotația cheilor și nu ar trebui să o presupuneți.
  7. MFA este opțională pentru utilizatorii obișnuiți, obligatorie numai pentru conturile de operator al platformei.
  8. Secretele MFA sunt stocate necriptate în baza de date, mascate la citire.
  9. Citirile nu sunt auditate. Jurnalul de audit acoperă numai modificările.
  10. Filtrarea cererilor de ieșire este o listă de interdicții, nu o listă de permisiuni.
  11. Niciun test de penetrare independent și nicio certificare de securitate. Nu există niciun ISO 27001, niciun raport SOC 2 și nicio atestare echivalentă din partea unui terț pentru acest serviciu. Nimeni din afara societății nu l-a auditat. Dacă o certificare este o cerință obligatorie pentru dumneavoastră, astăzi nu o îndeplinim și am prefera să aflați acest lucru aici, nu în luna a treia.
  12. Implementare pe un singur server, fără preluare automată, așa cum se descrie în secțiunea 10.
  13. Nicio cale de import sau de restaurare, așa cum se descrie în secțiunea 9.

12. Raportarea unei vulnerabilități

Trimiteți-o la contact@oraglegpt.org. Puneți "security" la subiect. Includeți ce ați găsit, unde și pașii de reproducere. Dacă aveți o demonstrație a conceptului, atașați-o. Scrieți în română sau în engleză.

Termen țintă de confirmare: 3 zile lucrătoare. Este un obiectiv la care ne obligăm noi înșine, nu un nivel de serviciu contractual. Vă vom comunica ce intenționăm să facem în legătură cu raportul și vă vom anunța când problema este remediată. În prezent nu rulăm un program plătit de recompense pentru vulnerabilități și nu vom pretinde contrariul.

Port sigur. Dacă efectuați cercetarea cu bună-credință, în condițiile de mai jos, nu vom introduce acțiuni în justiție împotriva dumneavoastră, nu vă vom reclama autorităților pentru cercetarea în sine și nu vom cere angajatorului dumneavoastră să vă sancționeze. Condițiile sunt:

Vă rugăm să nu raportați elementele deja enumerate în secțiunea 11. Le știm. Sunt acolo pentru ca dumneavoastră să vă puteți folosi timpul pentru ceva ce nu am consemnat deja.

13. Modificări și pagini conexe

Modificările substanțiale ale acestei pagini schimbă data din partea de sus. Întrucât Serviciul nu trimite e-mailuri, nu există nicio notificare automată: dacă doriți să fiți anunțat când această pagină se modifică, solicitați acest lucru la contact@oraglegpt.org și vă va scrie o persoană.