Сигурност #

EthicsPortal обработва чувствителни данни по сигнали. Тази страница описва конкретните технически и организационни мерки, които прилагаме. Тя е предназначена за екипи по съответствие, DPO и правни екипи, които оценяват платформата.

Последна актуализация: 2026-11-04.

Шифроване на данните #

Изброените по-долу чувствителни полета в базата данни се съхраняват шифровано чрез Rails Active Record Encryption с недетерминистично шифроване (всяко шифроване дава уникален шифротекст, което предотвратява анализ по модели). Шифроването на полета не обхваща цели дъмпове на базата данни, нито прикачени файлове; те се шифроват отделно, както е описано в разделите прикачени файлове и архивиране.

Недетерминистичното шифроване означава, че тези полета не могат да се търсят по стойност на ниво база данни. Дори при пълен достъп до базата данни нападател не може да търси конкретно име на сигнализиращо лице в записите.

Прикачени файлове #

Файловете, прикачени към сигнали, съобщения и вътрешни бележки, гласовите записи и експортите на данни по случаи се съхраняват шифровано в Hetzner Object Storage с AES-256, с отделен случаен ключ за всеки файл (шифроване от страна на сървъра с ключове, предоставени от клиента). Ключът се изпраща с всяка заявка към хранилището и Hetzner отказва всяко четене без него. EthicsPortal съхранява ключа в базата данни под описаното по-горе Active Record Encryption, така че данните за достъп до хранилището сами по себе си не позволяват прочитане на файл: необходими са също базата данни и ключовете за шифроване на приложението. Файловете достигат до оторизираните потребители чрез поточно предаване през приложението, никога чрез директна връзка към хранилището.

Файловете, качени преди 6 октомври 2026 г., бяха шифровани повторно на тази дата, а нешифрованите им копия, включително запазените предишни версии, бяха изтрити. Файлове, които не са данни по сигнали, като профилни снимки и изображения за споделяне на организации, не се шифроват по този начин. Нищо от това не защитава при компрометиране на сървъра на приложението, който държи заедно данните за достъп до хранилището, базата данни и ключовете.

Всички връзки с EthicsPortal използват HTTPS/TLS. Нешифрованите HTTP заявки се пренасочват.

Анонимност и поверителност #

IP адреси #

EthicsPortal не записва IP адреса на сигнализиращото лице със сигналите, съобщенията или одитните записи, а записите на приложението за канала за сигнали не съдържат IP адреси.

Ограничаването на честотата на заявките в канала за сигнали (подаване на сигнал, проверка на преписка, съобщения) се основава на съкратен SHA-256 хеш с ключ на IP адреса на заявката. Хешът е псевдонимен, а не анонимен: от него не може да се прочете адрес, но всеки, който притежава тайния ключ на приложението, би могъл да проверява предполагаеми адреси спрямо него. Използва се само за периода на ограничението (най-много 10 минути), а фонова задача го изтрива от кеша в рамките на 5 минути след края на периода.

TLS проксито пред приложението води собствен журнал на заявките: IP адрес, път на заявката, потребителски агент и статус на отговора. Пътят на страницата, на която подателят на сигнал преглежда своя сигнал, съдържа номера на преписката, затова запис за тази страница може да бъде свързан със сигнала. Съхраняват се в един лог файл с размер 10 MB, който се презаписва при запълване, в момента след около два дни; 7-дневните моментни копия на сървъра, описани в раздел архивиране, може да съдържат тяхно копие.

Премахване на метаданните от файловете #

Качените файлове автоматично се изчистват от идентифициращите метаданни преди съхранение:

Премахването на метаданните се извършва на сървъра преди съхранение. За типовете файлове, обработвани с exiftool, това зависи от наличието на стандартните производствени инструменти.

В PDF файла имената в коментарите и метаданните на вградените снимки, като GPS местоположение и сериен номер на камерата, се запазват. Сигнализиращо лице, което иска да ги премахне, следва да качи снимките като отделни файлове с изображения и да изтрие коментарите, преди да качи PDF файла.

Проверка за вируси #

Файловете, прикачени към сигнали, съобщения и вътрешни бележки, се сканират автоматично за зловреден код чрез ClamAV — антивирусна програма с отворен код. Сканирането се извършва на сървъра във фонов процес след качването. Файлове, които не са преминали сканирането, се блокират и не се предоставят, а заразените файлове се премахват автоматично.

Файловете се сканират в инфраструктурата на EthicsPortal — никакви данни от файловете не се изпращат към услуги за сканиране на трети страни.

Сигнали по имейл #

Всеки канал за сигнали има собствен имейл адрес в report.ethicsportal.eu. Имейл, изпратен до него, става преписка в този канал, както сигнал, подаден чрез онлайн формуляра за сигнали. Сигналите по имейл са включени по подразбиране. Организацията може да ги изключи в настройките на канала и тогава адресът отказва нови имейли до една минута.

• Собствен пощенски сървър. Пощата за тези адреси се получава от собствения пощенски сървър на EthicsPortal в същата инфраструктура в Германия, а не от външен доставчик на имейл услуги. Той приема поща само за адресите на каналите, отказва всички други адреси и не препраща поща.
• Шифроване при пренос. Сървърът предлага TLS 1.2 или по-нова версия със сертификат от Let’s Encrypt. TLS се използва, когато е възможно: изпращащ сървър, който не го поддържа, доставя писмото нешифровано.
• Адресът на подателя е скрит от обработващите. Адресът на подателя се съхранява шифрован и никога не се показва на обработващите — нито в преписката, нито в нейния PDF файл или в експортите. EthicsPortal го използва само за да изпрати на сигнализиращото лице автоматичния отговор и известията за нови съобщения.
• Достъп без имейл. Автоматичният отговор съдържа номера на преписката и еднократна парола за защитената входяща кутия, която се заменя при първото влизане. Въпросите и отговорите след това остават във входящата кутия, а не в имейла. Когато собственият домейн на подателя отхвърля адреса чрез своята DMARC политика, сигналът се запазва, но парола не се изпраща. След 10 сигнала по имейл до една организация или 50 в целия EthicsPortal в рамките на 24 часа следващите сигнали се запазват, но не се изпраща имейл: нито автоматичен отговор до сигнализиращото лице, нито известие по имейл до администраторите, които продължават да виждат случая в приложението.
• Прикачени файлове. Файловете минават през същото премахване на метаданни и същата проверка за вируси като файловете, качени чрез формуляра. Файлове, които не могат да бъдат приети (друг тип, твърде големи или невъзможни за изчистване), се пропускат, а сигнализиращото лице научава колко са.
• Копия. Съобщението чака в опашката на пощенския сървър, на същия сървър, само докато приложението го приеме. Приложението пази оригиналния имейл шифрован, докато преписката бъде записана, и след това го изтрива. Записите на пощенския сървър съдържат адресите на каналите, никога адреса на подателя.
• Проверка на подателя. SPF, DKIM и DMARC се проверяват в инфраструктурата на EthicsPortal. Никакви данни от съобщенията не се изпращат към външна услуга за спам или репутация.

Имейлът не е анонимен: доставчикът на имейл на сигнализиращото лице, както и пощенските системи на организацията, ако то пише от служебен профил, могат да пазят копия и записи на съобщението. Автоматичният отговор посочва това и съдържа връзка към онлайн формуляра за сигнали за сигнализиращите лица, които искат да останат анонимни.

Имейл за новини #

Онлайн формулярът за сигнали има незадължително поле за имейл за новини. На този адрес се изпращат автоматичният отговор и известие, когато обработващ напише съобщение, но никога съдържанието на сигнала. Адресът се съхранява шифрован и, както адресът на подателя на сигнал, изпратен по имейл, не се показва на никоя страница за обработващите, в PDF файл или в експорт. Полето остава достъпно, когато сигнализиращото лице подава сигнала анонимно. Само ако сигнализиращото лице изключи анонимното подаване и отметне „покажи имейл адреса ми и на служителите по сигнала“, адресът става адрес за контакт, който обработващите виждат.

Анонимност на обработващите #

Сигнализиращите лица никога не виждат истинските имена или имейл адресите на хората, които разглеждат сигнала им. Всички съобщения от обработващите се изписват като „Служител по сигнала“. Това защитава самоличността на обработващите и предотвратява социално инженерство.

Без проследяване #

EthicsPortal не използва проследяващи бисквитки на трети страни, рекламни пиксели или скриптове за снемане на цифров отпечатък. Използваме Plausible Analytics само на маркетинговия сайт, обслужван през собствения ни домейн. Той не поставя бисквитки и не съхранява IP адреси. Cloudflare, който доставя маркетинговия сайт, обработва метаданни на заявките, включително IP адреси, както е описано в Декларацията за поверителност. Самият канал за сигнали няма аналитични инструменти.

Текущ статус на сертификацията #

EthicsPortal понастоящем не заявява на този сайт акредитирана сертификация ISO 27001. Не е публикуван и независим външен одит на архитектурата за анонимност. Ако това се промени, обхватът и датата ще бъдат публикувани тук.

Материали за преглед на сигурността #

Клиенти, на които са нужни материали за обществена поръчка или за правен преглед, могат да ги поискат по време на прегледа. Налични материали могат да включват подписано DPA, регистрационни и данъчни документи, попълнен въпросник за сигурност, както и писмени отговори относно процедурите по архивиране и възстановяване, достъпа с повишени права в производствената среда и реакцията при инциденти.

Контрол на достъпа #

Авторизацията се прилага на ниво приложение чрез политики на Pundit.

• Обработващите не виждат сигнали, които нито са им възложени, нито участват в тях. Участниците се добавят изрично от администратор или от основния отговорник по сигнала (например за включване на правния отдел или отдела по човешки ресурси).
• Сигнализиращите лица нямат потребителски профил — отварят сигнала си с номер на преписката (WB-XXXX-XXXX) и парола, която системата генерира при подаването на сигнала.
• Всяко действие на ниво контролер проверява авторизацията. Неоправомощените опити за достъп се блокират и записват.

Двуфакторно удостоверяване #

Профилите на обработващите и администраторите могат да включат TOTP-базирано двуфакторно удостоверяване чрез всяко стандартно приложение за удостоверяване (Google Authenticator, 1Password, Authy и съвместими алтернативи). След включването му влизането изисква както основния идентификатор, така и сменящ се 6-цифрен код.

Вход на сигнализиращите лица #

Сигнализиращите лица влизат с номера на преписката и парола. Номерът на преписката идентифицира преписката и не е таен. Паролата се състои от 16 случайни цифри и се генерира от системата при подаването на сигнала; сигнализиращото лице не я избира. Тя се съхранява само като bcrypt хеш, затова никой не може да я възстанови, а EthicsPortal няма функция, с която сигнализиращото лице, обработващият или операторът да я нулират. Сигнализиращо лице, което я загуби, подава нов сигнал и посочва номера на преписката. Сигналите, подадени преди 18 октомври 2026 г., запазват 6-цифрената парола, която сигнализиращото лице е избрало тогава, и тя продължава да работи. Входящата кутия за последващи действия и изпращането на съобщения са достъпни само в сесия след тази проверка, така че изтекъл номер на преписката сам по себе си не позволява прочитане на сигнала или представяне за сигнализиращото лице.

Веднага след подаването страница с потвърждение показва адреса на защитената входяща кутия, номера на преписката и паролата. Тя остава достъпна в същия браузър само докато преписката е отключена и изчезва, когато входящата кутия се заключи след 30 минути без активност или когато сигнализиращото лице излезе. На страницата за вход полето за паролата е видимо текстово поле с изключено автоматично попълване, а не маскирано поле за парола. Така браузърите не предлагат да запазят паролата. Иначе браузър, управляван от работодателя, би могъл да я синхронизира с профила на работодателя. Поставянето работи, а интервалите нямат значение.

Когато служители регистрират сигнал, получен по телефона, на лична среща, с писмо или по имейл, и сигнализиращото лице иска да следи преписката онлайн, системата генерира еднократна парола, която обработващият предава на лицето. Тя важи само веднъж: при първото влизане на сигнализиращото лице тя се заменя на сървъра с нова парола, която вижда само то.

Достъпът на сигнализиращото лице приключва, когато избере „Изход“, или след 30 минути без активност. Около две минути преди заключването се показва предупреждение с възможност входящата кутия да остане отворена; ако никой не реагира, случаят изчезва от екрана. Достъпът се пази в криптирана бисквитка в браузъра на сигнализиращото лице, а сървърът не съхранява негова сесия.

Жизнен цикъл на сесиите #

Всяка удостоверена сесия записва last_seen_at при всяка заявка (с дебаунс). Потребителите могат да преглеждат активните си сесии, да виждат кога всяка от тях е била последно активна, да отнемат отделна сесия или да излязат от всички останали сесии наведнъж от настройките на профила.

Сесиите изтичат автоматично след 14 дни неактивност. Следващата заявка от неактивна сесия унищожава записа от страна на сървъра, изчиства бисквитката и налага повторно удостоверяване чрез нов магически линк. Нощно задание прочиства изоставените сесии със същия таймаут, така че user_agent и ip_address не се запазват след прозореца на неактивност, дори когато потребителят повече не се връща.

Удостоверяването чрез магически линк ограничава поразяващото действие на дълготрайните сесии: открадната бисквитка на сесия не дава пригоден за повторна употреба идентификатор и повторното удостоверяване изисква достъп до имейл.

Достъп и прекратяване на участието на членове #

Достъпът до организацията се прилага на ниво заявка. Когато член бъде деактивиран:

• Достъпът до организацията се отхвърля незабавно, включително и от вече запазени в отметките URL адреси.
• Възлагането на отворени сигнали се премахва.
• Участията се премахват.
• Историята в одитната следа, която се отнася до члена, се запазва.
• Деактивираният член бива уведомен.
• Повторното активиране не възстановява автоматично предишния достъп до преписките.

Собственикът на организацията, последният активен администратор и определеният за канала за сигнали служител, отговарящ за разглеждането на сигнали, не могат да бъдат деактивирани. Всички събития по деактивиране и повторно активиране се записват в одитната следа, която е само за добавяне.

Премахването на член деактивира членството, вместо да го изтрие, така че одитната следа и историята на сигналите остават проследими. Членството се изтрива окончателно само когато бъде изтрит собственият профил на члена или самата организация.

Изтриване на профила #

Когато член закрие собствения си профил, имейл адресът му се заменя с недоставяем заместител, а аватарът, данните за двуфакторно удостоверяване, сесиите, API токените и предпочитанията му се изтриват окончателно; профилът вече не може да се удостоверява, нито с него може да се осъществи контакт. Ако профилът никога не е извършвал действие в организация, записът се изтрива изцяло. Ако е извършвал, името на члена остава, а членствата му се деактивират, така че запазените бележки по преписките, съобщенията и одитните записи да останат проследими до него. Администраторът на лични данни определя срока на съхранение съгласно документираните си указания и приложимото право; правото на изтриване по ОРЗД остава предмет на приложимите изключения за правни задължения или правни претенции.

Изчистен профил не може да се удостоверява по никакъв начин: чрез магически линк, SSO потвърждение или API токен.

Ограничаване на честотата на заявките #

Публичните адреси на канала за сигнали имат ограничения на честотата, за да се предотвратят злоупотреби и атаки чрез изброяване:

Ограничаването на честотата на заявките използва описания по-горе хеш с ключ на IP адреса — за него не се съхранява IP адрес. Ограничението по номер на преписката използва като ключ самия номер на преписката, който се изтрива от същия кеш в рамките на 15 минути.

Одит и съответствие #

Незаличима одитна следа #

Определени събития, свързани със сигнали и профили, се записват с:

• дата и час (UTC)
• извършител (кой потребител или системен процес е извършил действието)
• тип на действието (например създаден сигнал, променен статус, изпратено съобщение, възложен обработващ, експортиран или изтрит сигнал). Всеки преглед на даден сигнал от обработващ се записва, като се обединява в един запис на обработващ на сигнал за 24 часа; прегледите при последващи действия от сигнализиращото лице се записват по същия начин. Четенето на други ресурси не се записва.

Записите са само за добавяне. Никой потребител, включително администратор на организацията, не може да редактира запис или да изтрие отделен запис: тригери на PostgreSQL отхвърлят промяна и съкращаване на ниво база данни. Записи се премахват само от жизнения цикъл на съхранение или когато самата организация бъде изтрита, а привилегированата намеса в базата данни остава документиран остатъчен риск (регистър на рисковете R-08). Пълната одитна следа се включва в PDF експортите на преписките за регулаторен преглед.

Срокове за съхранение #

Организациите задават собствен срок на съхранение: 12, 24, 36, 48 или 60 месеца след приключване на сигнала. След изтичането на срока фоново задание изтрива сигнала и свързаните данни от производствената среда; резервните копия изтичат съгласно отделния документиран жизнен цикъл.

Имейлите до сигнализиращото лице не оставят запис в историята на изпращанията на EthicsPortal, затова след изтриването на сигнала не остава адрес на сигнализиращо лице.

Администраторът на лични данни носи отговорност за избора на срок, който отговаря на принципа на ограничение на съхранението по ОРЗД и на приложимите национални правила за водене на документация.

Защита от CSRF #

Всички формуляри са защитени срещу CSRF (фалшифициране на заявки между сайтове) чрез вградените токени на Rails.

Сигурен жизнен цикъл на разработката #

EthicsPortal следва документиран жизнен цикъл на разработката за промените, засягащи Услугата. Етапите са изложени тук, за да може проверяващ в процедура по възлагане да ги съотнесе към мерките A.8.25–A.8.29 от ISO/IEC 27001:2022 (пълното съответствие е в картата на мерките).

Управление на зависимостите и кръпките #

EthicsPortal не внедрява софтуерни компоненти, излезли от поддръжка. Приложението работи на активно поддържаните издания на Rails, Ruby, PostgreSQL и съответната операционна система; обновленията по сигурността нагоре по веригата се прилагат текущо.

Зависимостите се сканират непрекъснато в continuous integration:

• Brakeman отбелязва уязвимости, специфични за Rails, при всяка промяна.
• bundler-audit проверява Gemfile спрямо Ruby Advisory Database при всяка промяна и допълнително ежедневно по график, така че новооповестените уязвимости да се откриват дори без промяна в кода.
• importmap audit сканира JavaScript импортите за известни уязвимости при всяка промяна и допълнително ежедневно по график.
• Dependabot отваря седмични pull request-и за остарели Ruby gems и GitHub Actions, групирани по minor/patch обновявания.

Контролите във веригата на доставки ограничават до какво може да достигне компрометирана версия на зависимост:

• Период на изчакване. Новите версии на gem пакети се приемат едва след като са публични от три дни; обновяванията на версии чрез Dependabot изчакват 3, 7 или 14 дни за patch, minor и major версии. Компрометираните версии обикновено се оттеглят в рамките на този период.
• Фиксирани CI действия. Всяка стъпка в GitHub Actions е фиксирана към пълен SHA на commit, така че пренасочен таг не може да промени какво се изпълнява.
• Проверени изтегляния. Двоичните файлове, изтеглени при изграждането на контейнерния образ, се проверяват спрямо фиксирана контролна сума SHA-256.
• Контролирани автоматични обновявания. Pull request-ите от Dependabot се сливат автоматично само след като преминат пълния набор от тестове и статичния анализ.

Компонентите, които достигат край на поддръжката нагоре по веригата, се заменят или обновяват преди изтичането на срока за поддръжка.

Инфраструктура #

• Основното съхранение на данните по сигнали и преписки е в Европейския съюз. Доставката на имейли и телеметрията на приложението имат отделни вериги от доставчици надолу по веригата; вж. DPA.
• На сървърите на EthicsPortal не се съхраняват номера на кредитни карти или платежни данни. Всички платежни данни се обработват от Stripe.
• Mailjet изпраща известията до обработващите, както и незадължителните потвърждения и известия за нови съобщения до сигнализиращите лица. Известията до сигнализиращите лица съдържат имейл адреса на получателя, номера на преписката и линк, но не и описанието на сигнала. Веригата за поддръжка на Mailjet надолу по веригата може да включва достъп извън ЕИП; вж. Потвърждението за сигнал, изпратен по имейл, съдържа и еднократна парола за защитената пощенска кутия, която се сменя при първото влизане на сигнализиращото лице. DPA.
• Маркетинговият сайт се доставя през Cloudflare (CDN, САЩ); каналът за сигнали и порталът на обработващите — не. Тази отделна обработка на публичния сайт и гаранциите при трансфер са описани в Декларацията за поверителност, а не в списъка на подизпълнителите по обработването в DPA с клиента.

Архивиране и възстановяване #

EthicsPortal поддържа три допълващи се слоя на архивиране, всички запазвани в ЕС:

Цели за възстановяване. Целта за точка на възстановяване (RPO) е 24 часа. Целта за време за възстановяване (RTO) е 4 часа. Тези цели присъстват и в споразумението за ниво на услугата.

Тестване на възстановяването. Учение по възстановяване се извършва автоматично всеки месец чрез CI работен процес, както и при поискване, като най-новият дъмп се възстановява в среда за еднократна употреба. Учението дешифрира дъмпа, възстановява го, сравнява всяка таблица с действащата производствена база и след това стартира приложението върху възстановената база данни, за да потвърди, че шифрована колона все още се дешифрира , че един шифрован прикачен файл се отваря с ключа, съдържащ се във възстановения дъмп, и че всеки прикачен файл, по-стар от един час, има копие в резервното местоположение, като едно копие се отваря и се проверява спрямо контролната му сума — броят на редовете сам по себе си не може да отличи използваемо резервно копие от шифротекст, чийто ключ вече не съвпада. Актуалността на архивите се наблюдава постоянно (известие, ако най-новият дъмп е по-стар от 36 часа).

Шифроване. Според Hetzner, Object Storage не шифрова обектите при съхранение по подразбиране, затова дъмповете на базата данни се шифроват, преди да напуснат хоста: GnuPG симетрично AES-256, като паролата се съхранява само от процеса за резервни копия и се депозира извън машината. Полетата, шифровани на ниво приложение с Rails Active Record Encryption, остават отделно шифровани вътре във всеки дъмп. Прикачените файлове се съхраняват шифровано с отделен ключ за всеки файл (вж. прикачени файлове). Тези ключове съществуват само в базата данни, затова всеки шифрован дъмп ги съдържа. Самите файлове не се копират в дъмпа. Всеки от тях се съхранява в Нюрнберг и се копира, със същия ключ, във втори bucket във Falkenstein; и на двете места предишните версии се пазят 28 дни.

Оперативен преглед #

Част от оперативните материали се споделят по време на преглед в рамките на обществена поръчка, а не се публикуват изцяло в отворения уеб, защото съдържат инфраструктурни и реакционни подробности, които са по-подходящи за контролирано разкриване.

При поискване по време на такъв преглед са налични следните теми:

• Резюме на достъпа с повишени права в производствената среда
• Процедура при инциденти и контакти за ескалация
• Отговори за непрекъсваемост на дейността и за приключване и сваляне на данни на клиент

Отговорно разкриване #

Ако откриете уязвимост в сигурността на EthicsPortal, пишете на security@ethicsportal.eu. Молим ви:

1. Да не разкривате публично уязвимостта, преди да имаме възможност да я отстраним.
2. Да предоставите достатъчно подробности, за да я възпроизведем и поправим.
3. Да не достъпвате и не променяте данни на други клиенти.
4. Да не провеждате атаки за отказ на услуга или масово автоматизирано сканиране, да не опитвате социално инженерство спрямо нашия персонал и да не подавате сигнали чрез канала за сигнали на клиент.

Потвърждаваме получаването на вашето съобщение в рамките на 2 работни дни и се стремим към бързо отстраняване на потвърдените уязвимости.

Няма платена програма за награди (bug bounty). Разкриването не се възнаграждава: не заплащаме за съобщения за уязвимости и не подписваме споразумения за поверителност, не договаряме търговски условия и не провеждаме разговори като предварително условие за приемане на съобщение. Изпратете на посочения адрес засегнатия актив, стъпките за възпроизвеждане и установеното от вас въздействие.

Последна актуализация: 8 ноември 2026 г.