GDPR политика

Всички данни са криптирани при пренос (TLS 1.2+). Паролите са хеширани с bcrypt (12 рунда). PostgreSQL Flexible Server използва прозрачно криптиране на данните в покой. Azure Blob Storage е криптирано в покой. Изображенията на шофьорски книжки и подписите са криптирани в покой с AES-256 от Azure Storage и Azure Database for PostgreSQL (ключове, управлявани от Microsoft), а достъпът до тях е ограничен според ролята и организацията. JWT токените са криптографски подписани (HS256). Тайните се управляват чрез Azure Key Vault, достъпван от управлявана идентичност на App Service — никакви тайни в кода, файловете с променливи на средата или образите на контейнери.

Контрол на достъпа, базиран на роли (RBAC), за удостоверени маршрути с прилагане на обхвата на наемателя от страна на сървъра. Изолацията на наематели се тества автоматично преди всяко издание: проверката на изданието извършва кръстосано сканиране между наематели, като извиква API като една организация с идентификатори на записи на друга организация, и изданието се блокира, ако данните на тази организация могат да бъдат прочетени или променени. Single sign-on (SAML 2.0, Google, Microsoft); MFA с времево базирана еднократна парола, задължителна за администратори на платформата и достъпна за всички потребители.

Пълно одитно записване на действията на потребителите: самоличност на потребителя, времеви клейм, IP адрес, вид действие, засегнат обект, стари и нови стойности. GMP-релевантните действия са маркирани отделно (is_gmp_relevant=1). С възможност за откриване на подправяне и само за добавяне, наложено в базата данни чрез хеш верига; GMP-релевантните записи се съхраняват най-малко 7 години докато договорът за услуги е в сила, а останалите одитни записи — 365 дни. Псевдонимизирани, но не изтрити при заличаване по Art. 17 (отмяна по силата на законово задължение по Art. 17(3)(b)). При прекратяване на договора клиентът получава пълен експорт на своя одитен журнал преди неговото изтриване, освен ако не откаже това писмено или не може да бъде открит след разумни опити; YARDtwin го съхранява по-дълго единствено по писмена инструкция на клиента, с изключение на резервни копия до тяхното изтичане и собствения си запис за предаването.

Хостван в Microsoft Azure (Sweden Central + Norway East, ЕИП). Контейнеризирана App Service услуга, внедрена чрез Azure Container Registry с процес на поетапно слотово заместване. Трафикът достига до приложението чрез Azure Front Door с Web Application Firewall в режим на превенция; базата данни приема връзки само от услуги на Azure и списък с разрешени администраторски IP адреси. Application Insights с предупреждение за отклонение в схемата при грешки "column / relation does not exist" в Postgres (прозорец от 15 минути). Сондата /health/db-write проверява end-to-end дали приложението може да записва и чете от базата данни при всяко внедряване.

Събираме само данни, необходими за предоставянето на услугата. Незадължителните полета за шофьора (телефон, имейл) могат да останат празни, когато процесът на клиента го позволява. Персоналът на портала може да направи снимка на лицето на шофьора като доказателство при влизане. Когато даден обект активира AI сравнение на лица, нашият AI доставчик (Anthropic) сравнява тази снимка едно към едно с лицевата снимка от шофьорската книжка или съхранената снимка на шофьора, за да помогне на персонала да потвърди самоличността му. Резултатът е препоръка: персоналът на портала решава и може да допусне шофьор, чиято самоличност сравнението не е потвърдило, като посочи причина. Всяко сравнение се записва на нашите сървъри заедно с резултата. Когато сравнението на лица е изключено (по подразбиране), никаква лицева снимка не се изпраща до AI доставчика и персоналът сам сравнява шофьора с лицевата снимка от книжката; изображенията на шофьорските книжки все още се обработват от AI, когато AI четенето е включено. YARDtwin не съхранява шаблони на лица и не извършва идентификация от типа едно към много. Бюлетинът събира само имейл и незадължително наименование на фирмата.

Всяка заявка за сливане (pull request) трябва да премине npm audit (уязвимости в зависимостите), Semgrep (статичен анализ) и gitleaks (сканиране за тайни) преди да бъде слята, като допълнително се извършва advisory проверка с Trivy за сканиране на контейнерния образ; тези проверки се изпълняват и при всяко push към master и нощно, заедно с advisory OWASP ZAP baseline сканиране (динамично тестване) на production средата. Предупрежденията от Dependabot докладват новооткрити уязвимости в нашите зависимости.