Securitate #

EthicsPortal procesează date sensibile ale avertizorilor de integritate. Această pagină documentează măsurile tehnice și organizatorice concrete pe care le aplicăm. Este scrisă pentru responsabilii de conformitate, responsabilii cu protecția datelor (DPO) și echipele juridice care evaluează platforma.

Ultima actualizare: 2026-11-04.

Criptare #

Câmpurile sensibile din baza de date enumerate mai jos sunt criptate în repaus cu Rails ActiveRecord Encryption, folosind criptare nedeterministă (fiecare criptare produce un text cifrat unic, ceea ce împiedică analiza tiparelor). Criptarea la nivel de câmp nu acoperă copiile integrale ale bazei de date și nici fișierele atașate; acestea sunt criptate separat, așa cum este descris la atașamente și copii de rezervă.

Criptarea nedeterministă înseamnă că aceste câmpuri nu pot fi interogate după valoare la nivelul bazei de date. Chiar și cu acces complet la baza de date, un atacator nu poate căuta un anumit nume al unei persoane care raportează în toate înregistrările.

Atașamente #

Fișierele atașate raportărilor, mesajelor și notelor interne, înregistrările vocale și exporturile de date ale cazurilor sunt criptate în repaus în Hetzner Object Storage cu AES-256, cu o cheie aleatorie separată pentru fiecare fișier (criptare pe partea de server cu chei furnizate de client). Cheia este trimisă cu fiecare cerere către spațiul de stocare, iar Hetzner refuză orice citire efectuată fără ea. EthicsPortal o păstrează în baza de date, sub criptarea ActiveRecord Encryption descrisă mai sus, astfel încât credențialele de stocare singure nu permit citirea unui fișier: sunt necesare și baza de date, și cheile de criptare ale aplicației. Fișierele ajung la utilizatorii autorizați prin transmitere în flux prin aplicație, niciodată printr-un link direct către spațiul de stocare.

Fișierele încărcate înainte de 6 octombrie 2026 au fost recriptate la acea dată, iar copiile lor necriptate, inclusiv versiunile anterioare păstrate, au fost șterse. Fișierele care nu sunt date ale raportărilor, cum ar fi fotografiile de profil și imaginile de partajare ale organizației, nu sunt criptate în acest mod. Nimic din toate acestea nu protejează împotriva compromiterii serverului de aplicație, care deține împreună credențialele de stocare, baza de date și cheile.

Toate conexiunile la EthicsPortal folosesc HTTPS/TLS. Cererile HTTP necriptate sunt redirecționate.

Anonimat și confidențialitate #

Adrese IP #

EthicsPortal nu înregistrează adresa IP a persoanei care raportează împreună cu raportările, mesajele sau înregistrările de audit, iar jurnalele aplicației pentru canalul de raportare nu conțin adrese IP.

Limitarea frecvenței pe canalul de raportare (trimiterea raportării, consultarea cazului, mesageria) se bazează pe un hash SHA-256 trunchiat al adresei IP a cererii, calculat cu o cheie secretă. Hash-ul este pseudonim, nu anonim: nu poate fi citit ca adresă, dar oricine deține secretul aplicației ar putea testa adrese candidate în raport cu el. Este folosit doar pe durata ferestrei de limitare (cel mult 10 minute), iar o sarcină de fundal îl șterge din cache în cel mult 5 minute după încheierea ferestrei.

Proxy-ul TLS din fața aplicației își păstrează propriul jurnal al cererilor: adresa IP, calea cererii, agentul utilizator și starea răspunsului. Calea paginii pe care o persoană care raportează își vede raportarea conține ID-ul cazului, așa că o înregistrare pentru această pagină poate fi legată de raportare. Sunt păstrate într-un singur fișier de jurnal de 10 MB, suprascris pe măsură ce se umple, în prezent după aproximativ două zile; instantaneele de server de 7 zile descrise la copii de rezervă pot conține o copie a acestora.

Eliminarea metadatelor din fișiere #

Fișierele încărcate sunt curățate automat de metadatele de identificare înainte de stocare:

Eliminarea metadatelor se efectuează pe server, înainte de stocare. Pentru tipurile de fișiere procesate de exiftool, aceasta depinde de prezența instrumentelor standard de producție.

Într-un PDF se păstrează numele din comentarii și metadatele fotografiilor încorporate, cum ar fi poziția GPS și numărul de serie al camerei foto. Persoana care raportează și dorește eliminarea acestora ar trebui să încarce fotografiile ca fișiere imagine separate și să elimine comentariile înainte de a încărca un PDF.

Scanare antivirus #

Fișierele atașate raportărilor, mesajelor și notelor interne sunt scanate automat pentru programe malware cu ClamAV, un motor antivirus open-source. Scanarea are loc pe server, într-un proces de fundal, după încărcare. Fișierele care nu au trecut scanarea sunt blocate de la livrare, iar fișierele infectate sunt eliminate automat.

Fișierele sunt scanate pe infrastructura EthicsPortal — nicio dată din fișiere nu este trimisă către servicii de scanare terțe.

Raportări prin e-mail #

Fiecare canal de raportare are propria adresă de e-mail pe report.ethicsportal.eu. Un e-mail trimis la această adresă devine un caz în canalul respectiv, la fel ca o raportare trimisă prin formularul online. Raportările prin e-mail sunt activate implicit. O organizație le poate dezactiva din setările canalului; adresa refuză apoi e-mailurile noi în cel mult un minut.

• Server de e-mail propriu. Mesajele pentru aceste adrese sunt primite de serverul de e-mail propriu al EthicsPortal, pe aceeași infrastructură din Germania, nu de un furnizor de e-mail terț. Serverul acceptă mesaje doar pentru adresele canalelor, refuză orice altă adresă și nu retransmite nimic.
• Criptarea transportului. Serverul oferă TLS 1.2 sau o versiune mai nouă, cu un certificat Let’s Encrypt. TLS este oportunist: un server expeditor care nu îl suportă livrează mesajul necriptat.
• Adresa expeditorului este ascunsă responsabililor de caz. Adresa expeditorului este stocată criptat și nu este afișată niciodată responsabililor de caz, nici în caz, nici în PDF-ul acestuia sau în exporturi. EthicsPortal o folosește doar pentru a trimite persoanei care raportează confirmarea și notificările despre mesaje noi.
• Acces fără e-mail. Confirmarea conține ID-ul cazului și o parolă de unică folosință pentru căsuța securizată, înlocuită la prima autentificare. Întrebările și răspunsurile ulterioare rămân în căsuța securizată, nu în e-mail. Dacă politica DMARC a domeniului expeditorului respinge adresa, raportarea este păstrată, dar nu se trimite nicio parolă. După 10 raportări prin e-mail către o organizație sau 50 în tot EthicsPortal în 24 de ore, raportările următoare sunt păstrate, dar nu se trimite niciun e-mail: nici confirmarea către persoana care raportează, nici notificarea prin e-mail către administratori, care văd în continuare cazul în aplicație.
• Atașamente. Fișierele trec prin aceeași eliminare a metadatelor și scanare antivirus ca fișierele încărcate prin formular. Fișierele care nu pot fi acceptate (alt tip, prea mari sau imposibil de curățat) sunt omise, iar persoana care raportează este informată câte au fost omise.
• Copii. Un mesaj așteaptă în coada serverului de e-mail, pe același server, doar până când aplicația îl preia. Aplicația păstrează e-mailul original criptat până la salvarea cazului, apoi îl șterge. Jurnalele serverului de e-mail înregistrează adresele canalelor, niciodată adresa expeditorului.
• Verificarea expeditorului. SPF, DKIM și DMARC sunt verificate pe infrastructura EthicsPortal. Nicio dată din mesaje nu este trimisă către un serviciu extern de filtrare spam sau de reputație.

E-mailul nu este anonim: furnizorul de e-mail al persoanei care raportează și, dacă aceasta scrie de pe o adresă de serviciu, sistemele de e-mail ale organizației pot păstra copii și evidențe ale mesajului. Confirmarea menționează acest lucru și include un link către formularul online pentru persoanele care doresc să rămână anonime.

Email pentru noutăți #

Formularul online are un câmp de e-mail opțional pentru noutăți. Adresa primește confirmarea și o notificare atunci când un responsabil de caz scrie, niciodată conținutul raportării. Este stocată criptat și, la fel ca adresa expeditorului unei raportări trimise prin e-mail, nu este afișată pe nicio pagină a responsabililor de caz, în niciun PDF și în niciun export. Câmpul rămâne disponibil atunci când persoana care raportează trimite anonim. Doar dacă persoana care raportează dezactivează trimiterea anonimă și bifează „arată adresa mea de email și responsabililor de caz", adresa devine o adresă de contact pe care responsabilii de caz o văd.

Anonimatul responsabilului de caz #

Persoanele care raportează nu văd niciodată numele reale sau adresele de e-mail ale persoanelor care le gestionează raportarea. Toate mesajele de la responsabili sunt afișate ca „Responsabil de caz". Acest lucru protejează identitatea responsabilului și previne ingineria socială.

Fără urmărire #

EthicsPortal nu folosește cookie-uri de urmărire ale terților, pixeli publicitari sau scripturi de amprentare. Folosim Plausible Analytics doar pe site-ul de marketing, servit prin propriul nostru domeniu. Nu setează cookie-uri și nu stochează adrese IP. Cloudflare, care livrează site-ul de marketing, prelucrează metadatele cererii, inclusiv adresele IP, conform Politicii de confidențialitate. Canalul de raportare în sine nu are module de analiză.

Statutul actual al asigurării independente #

EthicsPortal nu pretinde în prezent pe acest site o certificare ISO 27001 acreditată. De asemenea, nu publică în prezent un audit independent, realizat de o terță parte, al arhitecturii de anonimat. Dacă situația se schimbă, domeniul și data vor fi publicate aici.

Materiale pentru evaluarea securității #

Clienții care au nevoie de materiale pentru evaluarea în cadrul achiziției sau pentru analiza juridică le pot solicita în etapa de achiziție. Materialele disponibile pot include un DPA semnat, dovezi de înregistrare și fiscale, un chestionar de securitate completat și răspunsuri scrise privind procedurile de copiere de rezervă și restaurare, accesul privilegiat în producție și gestionarea răspunsului la incidente.

Control de acces #

Autorizarea este aplicată la nivelul aplicației prin politici Pundit.

• Responsabilii de caz nu pot vedea raportările care nu le-au fost alocate și la care nu participă. Participanții sunt adăugați explicit de un administrator sau de responsabilul principal (de exemplu, pentru a implica departamentul juridic sau de resurse umane).
• Persoanele care raportează nu au cont de utilizator — își deschid raportarea cu un ID al cazului (WB-XXXX-XXXX) și o parolă pe care sistemul o generează la trimiterea raportării.
• Fiecare acțiune a controllerului verifică autorizarea. Încercările de acces neautorizat sunt blocate și înregistrate.

Autentificarea cu doi factori #

Conturile responsabililor de caz și ale administratorilor pot activa autentificarea cu doi factori bazată pe TOTP prin orice aplicație de autentificare standard (Google Authenticator, 1Password, Authy și alternative compatibile). După activare, conectarea necesită atât credențialul principal, cât și un cod rotativ din 6 cifre.

Autentificarea persoanelor care raportează #

Persoanele care raportează se autentifică cu ID-ul cazului și o parolă. ID-ul cazului identifică cazul și nu este secret. Parola are 16 cifre aleatorii și este generată de sistem la trimiterea raportării; persoana care raportează nu o alege. Este stocată doar ca digest bcrypt, astfel încât nimeni nu o poate recupera, iar EthicsPortal nu are nicio funcție prin care persoana care raportează, responsabilul de caz sau operatorul platformei să o poată reseta. O persoană care își pierde parola trimite o nouă raportare și menționează ID-ul cazului. Raportările trimise înainte de 18 octombrie 2026 își păstrează parola din 6 cifre aleasă atunci de persoana care raportează, iar aceasta funcționează în continuare. Căsuța de urmărire și trimiterea mesajelor sunt accesibile numai într-o sesiune obținută după această verificare, astfel încât un ID al cazului divulgat nu permite, singur, citirea raportării sau uzurparea identității persoanei care raportează.

Imediat după trimitere, o pagină de confirmare afișează adresa mesageriei securizate, ID-ul cazului și parola. Pagina rămâne disponibilă în acel browser doar cât timp cazul este deblocat și dispare când mesageria se blochează după 30 de minute fără activitate sau când persoana care raportează iese. Pe pagina de autentificare, câmpul pentru parolă este un câmp de text vizibil, cu completarea automată dezactivată, și nu un câmp de parolă mascat, astfel încât browserele să nu propună salvarea parolei, pe care un browser administrat de angajator ar putea altfel să o sincronizeze cu contul angajatorului. Lipirea funcționează, iar spațiile sunt ignorate.

Când personalul înregistrează o raportare primită telefonic, într-o întâlnire în persoană, prin scrisoare sau prin e-mail, iar persoana care raportează dorește să urmărească cazul online, sistemul generează o parolă de unică folosință, pe care responsabilul de caz i-o transmite. Aceasta funcționează o singură dată: la prima autentificare a persoanei care raportează, este înlocuită, pe server, cu o parolă nouă pe care doar persoana care raportează o vede.

Accesul avertizorului se încheie când selectează „Ieșire” sau după 30 de minute fără activitate. Cu aproximativ două minute înainte de blocare, un avertisment oferă posibilitatea de a păstra mesageria deschisă; dacă nimeni nu reacționează, cazul dispare de pe ecran. Accesul este păstrat într-un cookie criptat în browserul avertizorului, iar serverul nu păstrează nicio sesiune a avertizorului.

Ciclul de viață al sesiunii #

Fiecare sesiune autentificată înregistrează last_seen_at la fiecare cerere (cu debouncing). Utilizatorii își pot examina sesiunile active, pot vedea când a fost activă fiecare ultima dată, pot revoca individual orice sesiune sau se pot deconecta din toate celelalte sesiuni simultan din setările contului.

Sesiunile expiră automat după 14 zile de inactivitate. Următoarea cerere a unei sesiuni inactive distruge înregistrarea de pe server, șterge cookie-ul și impune reautentificarea printr-un nou link magic. Un job nocturn elimină sesiunile abandonate cu același prag, astfel încât user_agent și ip_address nu sunt păstrate dincolo de fereastra de inactivitate, chiar dacă utilizatorul nu se mai întoarce.

Autentificarea prin link magic limitează aria de impact a sesiunilor de lungă durată: un cookie de sesiune furat nu oferă o credențială reutilizabilă, iar reautentificarea necesită acces la e-mail.

Accesul membrilor și retragerea accesului #

Accesul la organizație este aplicat la limita cererii. Atunci când un membru este dezactivat:

• Accesul la organizație este respins imediat, inclusiv pe URL-urile salvate anterior.
• Atribuirile raportărilor deschise sunt anulate.
• Participările sunt eliminate.
• Istoricul jurnalului de audit atribuibil membrului este păstrat.
• Membrul dezactivat este notificat.
• Reactivarea nu restabilește automat accesul anterior la cazuri.

Proprietarul organizației, ultimul administrator activ și responsabilul de conformitate desemnat al canalului de raportare nu pot fi dezactivați. Toate evenimentele de dezactivare și reactivare sunt scrise în jurnalul de audit doar pentru adăugare.

Eliminarea unui membru dezactivează calitatea de membru în loc să o șteargă, astfel încât pista de audit și istoricul raportărilor să rămână rezolvabile. O calitate de membru este ștearsă definitiv doar atunci când este șters contul propriu al membrului sau organizația însăși.

Ștergerea contului #

Când un membru își închide propriul cont, adresa sa de e-mail este înlocuită cu o adresă substitut nelivrabilă, iar avatarul, credențialele de autentificare cu doi factori, sesiunile, tokenurile API și preferințele sale sunt șterse definitiv; contul nu se mai poate autentifica și nu mai poate fi contactat. Dacă contul nu a acționat niciodată într-o organizație, înregistrarea este ștearsă integral. Dacă a acționat, numele membrului rămâne, iar calitățile sale de membru sunt dezactivate, astfel încât notele de caz, mesajele și intrările de audit păstrate să rămână atribuibile. Operatorul stabilește perioada de păstrare conform instrucțiunilor sale documentate și legislației aplicabile; dreptul la ștergere conform GDPR rămâne supus excepțiilor aplicabile privind obligațiile legale sau constatarea, exercitarea ori apărarea unor drepturi în instanță.

Un cont curățat nu se poate autentifica pe nicio cale: link magic, aserțiune SSO sau token API.

Limitarea frecvenței #

Punctele finale publice ale canalului de raportare sunt limitate pentru a preveni abuzul și atacurile de enumerare:

Limitarea frecvenței folosește hash-ul IP cu cheie descris mai sus — nicio adresă IP nu este stocată în acest scop. Limita per ID al cazului folosește drept cheie chiar ID-ul cazului, care este șters din același cache în cel mult 15 minute.

Audit și conformitate #

Jurnal de audit doar cu adăugare #

Evenimentele definite privind raportările și conturile sunt înregistrate cu:

• Marcaj temporal (UTC)
• Autor (utilizatorul sau procesul de sistem care a efectuat acțiunea)
• Tip de acțiune (de exemplu, raportare creată, stare schimbată, mesaj trimis, responsabil alocat, raportare exportată sau raportare ștearsă). Fiecare vizualizare a unei raportări de către un responsabil este înregistrată, deduplicată la o intrare per responsabil per raportare per 24 de ore, iar vizualizările de urmărire ale persoanei care raportează sunt înregistrate în același mod. Citirile altor resurse nu sunt înregistrate.

Intrările din jurnalul de audit sunt doar cu adăugare. Niciun utilizator, inclusiv administratorii organizației, nu poate modifica o intrare sau șterge una în mod selectiv: declanșatoarele PostgreSQL resping modificarea și trunchierea la nivel de bază de date. Intrările sunt eliminate doar de ciclul de retenție sau odată cu ștergerea organizației însăși, iar intervenția privilegiată în baza de date rămâne un risc rezidual documentat (registrul de riscuri R-08). Jurnalul complet de audit este inclus în exporturile PDF ale cazurilor pentru revizuirea de către autoritățile de reglementare.

Retenția datelor #

Organizațiile își configurează propria perioadă de retenție: 12, 24, 36, 48 sau 60 de luni după închiderea unei raportări. Când expiră perioada de retenție, o sarcină de fundal șterge raportarea și datele asociate din producție; copiile de rezervă expiră conform ciclului de viață documentat separat.

E-mailurile trimise persoanei care raportează nu lasă nicio înregistrare în istoricul de trimitere EthicsPortal, astfel încât nicio adresă a unei persoane care raportează nu rămâne după ștergerea raportării.

Operatorul rămâne responsabil pentru alegerea unei perioade care respectă limitarea stocării din GDPR și normele naționale aplicabile privind păstrarea evidențelor.

Protecție CSRF #

Toate trimiterile de formulare sunt protejate împotriva falsificării cererilor cross-site folosind jetoanele CSRF integrate ale Rails.

Ciclu de dezvoltare securizat #

EthicsPortal urmează un ciclu de dezvoltare documentat pentru modificările care afectează Serviciul. Etapele sunt enunțate aici pentru ca un evaluator de achiziții să le poată corela cu controalele ISO/IEC 27001:2022 A.8.25–A.8.29 (vezi harta controalelor pentru corespondența completă).

Gestionarea dependențelor și a actualizărilor #

EthicsPortal nu implementează componente software ajunse la sfârșitul ciclului de viață. Aplicația rulează pe versiuni cu suport activ ale Rails, Ruby, PostgreSQL și ale sistemului de operare subiacent; actualizările de securitate din amonte sunt aplicate continuu.

Dependențele sunt scanate continuu în CI:

• Brakeman semnalează vulnerabilitățile specifice Rails la fiecare modificare.
• bundler-audit verifică Gemfile-ul față de Ruby Advisory Database la fiecare modificare și, în plus, zilnic conform unui program, astfel încât vulnerabilitățile nou divulgate să fie detectate chiar și fără modificări de cod.
• importmap audit scanează importurile JavaScript pentru vulnerabilități cunoscute la fiecare modificare și, în plus, zilnic conform unui program.
• Dependabot deschide săptămânal pull request-uri pentru gem-urile Ruby și pentru GitHub Actions învechite, grupate pe actualizări minore/de patch.

Controalele lanțului de aprovizionare limitează ce poate atinge o versiune compromisă a unei dependențe:

• Perioadă de așteptare. Versiunile noi de gem-uri sunt adoptate doar după ce au fost publice timp de trei zile; actualizările de versiune Dependabot așteaptă 3, 7 sau 14 zile pentru versiunile patch, minor și major. Versiunile deturnate sunt de obicei retrase în acest interval.
• Acțiuni CI fixate. Fiecare pas GitHub Actions este fixat la un SHA complet de commit, astfel încât un tag redirecționat nu poate schimba ce se execută.
• Descărcări verificate. Fișierele binare descărcate la construirea imaginii containerului sunt verificate cu o sumă de control SHA-256 fixată.
• Actualizări automate condiționate. Pull request-urile Dependabot sunt îmbinate automat doar după ce trec suita completă de teste și analiza statică.

Componentele care ajung la sfârșitul ciclului de viață în amonte sunt înlocuite sau actualizate înainte de închiderea ferestrei de suport.

Găzduire și infrastructură #

• Stocarea principală a datelor raportărilor și cazurilor are loc în Uniunea Europeană. Livrarea e-mailurilor și telemetria aplicației au lanțuri separate de furnizori din aval; vezi DPA.
• Pe serverele EthicsPortal nu sunt stocate numere de card de credit sau credențiale de plată. Toate datele de plată sunt gestionate de Stripe.
• Mailjet trimite notificările către responsabilii de caz, precum și, opțional, confirmările de primire și notificările de mesaje noi către persoanele care raportează. Notificările către persoanele care raportează conțin adresa de e-mail a destinatarului, ID-ul cazului și un link, dar nu și conținutul raportării. Confirmarea de primire pentru o raportare trimisă prin e-mail conține și o parolă de unică folosință pentru căsuța securizată, înlocuită la prima autentificare a persoanei care raportează. Lanțul de suport din aval al Mailjet poate implica acces din afara SEE; vezi DPA.
• Site-ul de marketing este livrat prin Cloudflare (CDN, Statele Unite); canalul de raportare și interfața responsabililor de caz nu. Această prelucrare separată a site-ului public și garanțiile sale de transfer sunt descrise în Politica de confidențialitate, nu în lista de subprocesatori din DPA-ul cu clientul.

Copii de rezervă și restaurare #

EthicsPortal operează trei straturi complementare de copii de rezervă, toate păstrate în UE:

Obiective de recuperare. Obiectivul punctului de recuperare (RPO) este de 24 de ore. Obiectivul timpului de recuperare (RTO) este de 4 ore. Aceste obiective apar și în Acordul de nivel de serviciu.

Testarea restaurării. Un exercițiu de restaurare rulează automat lunar printr-un flux CI, precum și la cerere, restaurând cea mai recentă copie într-un mediu de unică folosință. Exercițiul decriptează copia, o restaurează, compară fiecare tabel cu producția activă și apoi pornește aplicația pe baza de date restaurată pentru a confirma că o coloană criptată se decriptează în continuare, că un atașament criptat se deschide cu cheia păstrată în copia restaurată și că fiecare atașament mai vechi de o oră are o copie în locația de rezervă, iar o copie este deschisă și verificată pe baza sumei sale de control — numărul de rânduri singur nu poate distinge o copie de rezervă utilizabilă de un text cifrat a cărui cheie nu mai corespunde. Prospețimea copiilor de rezervă este monitorizată continuu (alertă dacă cea mai recentă copie este mai veche de 36 de ore).

Criptare. Hetzner precizează că Object Storage nu criptează implicit obiectele în repaus, de aceea copiile bazei de date sunt criptate înainte de a părăsi serverul: GnuPG simetric AES-256, fraza-parolă fiind deținută doar de procesul de copiere și depusă în afara mașinii. Câmpurile de la nivelul aplicației criptate cu Rails ActiveRecord Encryption rămân criptate separat în interiorul fiecărei copii. Atașamentele sunt criptate în repaus cu chei separate pentru fiecare fișier (vezi atașamente). Aceste chei există doar în baza de date, deci fiecare copie criptată le conține. Fișierele în sine nu sunt incluse în copie. Fiecare este stocat la Nürnberg și copiat, cu aceeași cheie, într-un al doilea bucket la Falkenstein; ambele păstrează versiunile anterioare 28 de zile.

Revizuire operațională #

Anumite materiale operaționale sunt partajate în etapa de revizuire pentru achiziții în loc să fie publicate integral pe web deschis, deoarece conțin detalii de infrastructură și de răspuns mai potrivite pentru dezvăluire controlată.

Subiectele disponibile la cerere în etapa de achiziție includ:

• Sumar al accesului privilegiat în producție
• Flux de răspuns la incidente și contacte de escaladare
• Continuitatea activității și răspunsuri privind dezafilierea/exportul clienților

Dezvăluire responsabilă #

Dacă descoperiți o vulnerabilitate de securitate în EthicsPortal, vă rugăm să o raportați la security@ethicsportal.eu. Vă solicităm să:

1. Nu divulgați public vulnerabilitatea înainte să o putem aborda.
2. Oferiți detalii suficiente pentru a reproduce și remedia problema.
3. Nu accesați și nu modificați datele altor clienți.
4. Nu efectuați atacuri de tip denial-of-service sau scanări automate de volum mare, nu încercați inginerie socială asupra personalului nostru și nu trimiteți rapoarte prin canalul de raportare al unui client.

Vom confirma raportul dvs. în 2 zile lucrătoare și vom urmări remedierea promptă a vulnerabilităților confirmate.

Fără program de recompense plătite. Dezvăluirea nu este recompensată: nu remunerăm rapoartele de vulnerabilități și nu semnăm acorduri de confidențialitate, nu convenim condiții comerciale și nu susținem apeluri drept condiție prealabilă pentru primirea unui raport. Trimiteți la adresa de mai sus activul afectat, pașii de reproducere și impactul pe care l-ați stabilit.

Ultima actualizare: 8 noiembrie 2026