Технические и организационные меры

Этот документ опубликован на нескольких языках. В случае расхождений между языковыми версиями обязательной является польская версия.

Версия 1.1 · Последнее обновление: 22 октября 2026 г.

Меры согласно ст. 32 GDPR, с помощью которых LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Польша, защищает сервис formexposed. Эта страница является частью Соглашения об обработке данных в качестве Приложения 2.

1. Сфера действия и принцип

Меры применяются ко всем данным, обрабатываемым сервисом: к данным, которые мы обрабатываем по поручению наших Клиентов (описаны в Соглашении об обработке данных), и к данным, в отношении которых контролёром являемся мы сами, например к клиентским учётным записям и журналам. Отдельных уровней защиты для этих двух категорий нет; то, что защищает учётную запись, защищает и данные, обрабатываемые по поручению.

Структура согласно ст. 32(1) GDPR. Псевдонимизация и шифрование (пункт (a)) рассматриваются в разделе 4; постоянная конфиденциальность, целостность, доступность и устойчивость систем (пункт (b)) — в разделах 3, 5, 6 и 7; способность своевременно восстановить доступность после инцидента (пункт (c)) — в разделе 7.1; процесс регулярного тестирования, оценки и проверки эффективности (пункт (d)) — в разделе 9. Мы выбрали меры на основе рисков, описанных в нашей Оценке воздействия на защиту данных, с учётом современного уровня техники и затрат на реализацию.

Принцип: измерено, а не задумано. Здесь указано только то, что фактически реализовано в коде или в эксплуатации. То, что запланировано, но ещё не реализовано, прямо перечислено как «запланировано» в разделе 10. Мера, которой здесь нет, не действует негласно.

Имена машин, внутренние адреса, порты, имена пользователей и версии программного обеспечения намеренно не указываются. Они никому не помогают оценить меры, но помогают тому, кто хочет их обойти. Тот, кому они нужны для аудита в соответствии с Соглашением об обработке данных, получит их в ходе этого аудита на условиях конфиденциальности в той мере, в какой они необходимы для аудита.

2. Устройство сервиса

Сервис работает на двух собственных серверах поставщика в Польше, расположенных в одной внутренней сети:

Веб-сервер с базой данных. Он отдаёт приложение, хранит базу данных, отправляет уведомления и выполняет резервное копирование данных. Только он настроен на приём запросов из интернета.
Сервер сканирования. Он выполняет проверки сторонних и собственных сайтов в браузере и запускает языковую модель, которая классифицирует отдельные формы, обобщает находки сканирования в виде планов действий в порядке приоритетов для учётных записей на платных тарифах и добавляет код в «Fix it for me». Он не настроен на приём запросов из интернета, а сам забирает свои задания с веб-сервера и возвращает туда результаты.

В эксплуатации не участвуют хостинг-провайдеры, центры обработки данных или облачные провайдеры, и ничего не передаётся во внешние ИИ-сервисы. Какие третьи лица получают данные, указано на странице Субобработчики.

3. Конфиденциальность

3.1 Контроль физического доступа

Серверы находятся в помещениях поставщика в Польше, закрытых для посторонних. Доступ есть только у владельца (по заявлению оператора). Точный адрес местонахождения здесь намеренно не указывается.

3.2 Контроль доступа: вход в сервис

Пароли хранятся только в виде хеша по стандартному методу PHP (bcrypt). Если стандартный метод изменится, хеш обновляется при следующем входе. При попытке входа с неизвестным адресом сервер всё равно вычисляет хеш, чтобы время ответа не выдавало, существует ли учётная запись. Аналогично ответ на запрос сброса пароля ни формулировкой, ни длительностью не выдаёт, существует ли учётная запись; письма для сброса отправляются на один и тот же адрес не более трёх раз в час. Новые пароли должны содержать не менее десяти символов и не превышать 72 байт (UTF-8), поскольку bcrypt не учитывает большее число байт. Смена пароля завершает сеансы на всех других устройствах; сброс по ссылке завершает сеансы на всех устройствах, а ссылка действительна только один раз.
Блокировка после неудачных попыток. Неудачные попытки входа подсчитываются по IP-адресу; после слишком большого их числа за короткое время (в настоящее время восемь за 15 минут) вход с этого адреса временно блокируется. Успешный вход сбрасывает этот счётчик. Попытки удаляются через семь дней. Кроме того, перед каждой проверкой пароля засчитывается одна попытка на учётную запись (для неизвестного адреса — на введённый адрес) и на IP-адрес, включая успешные: в настоящее время не более восьми на учётную запись с одного IP-адреса и 80 на IP-адрес за 15 минут; против распределённого подбора действует значительно более высокий лимит на учётную запись по всем адресам вместе. Поэтому неудачные попытки с другого адреса больше не блокируют владельцу доступ к учётной записи. Эти счётчики содержат только HMAC-ключ, без адреса электронной почты или IP-адреса в открытом виде, и истекают вместе со своим временным окном. Если хранилище счётчиков недоступно, вход отклоняется, а не пропускается. Такой же лимит действует для подтверждения пароля перед сменой пароля или адреса, включением или отключением второго фактора, передачей рабочего пространства, экспортом данных и удалением учётной записи (пять попыток на учётную запись за 15 минут), для регистраций (десять на IP-адрес в час) и для паролей клиентских порталов (десять попыток на портал и IP-адрес, 50 на портал за 15 минут).
Второй фактор. Для каждой учётной записи можно включить вход с одноразовым кодом по RFC 6238 (TOTP). Секрет для этого хранится в базе данных в зашифрованном виде; ключ в базе данных не хранится, поэтому одной выгрузки базы данных недостаточно. Принятый код повторно недействителен. Десять кодов восстановления хранятся только в виде хеша. Одноразовые коды и коды восстановления ограничены десятью попытками на учётную запись за 15 минут, в том числе при настройке.
Административная область — только со вторым фактором. Административная область оператора открывается только для учётных записей с включённым вторым фактором. Контрольный список настройки сообщает о каждой учётной записи администратора без второго фактора.
Сеансы. Сеансовый cookie недоступен для чтения скриптами (HttpOnly), передаётся только по HTTPS (Secure) и не отправляется с запросами со сторонних сайтов, которые могли бы что-то изменить (SameSite=Lax). При входе создаётся новый идентификатор сеанса, так что заранее подброшенный идентификатор становится недействительным; сервер не принимает идентификатор сеанса, который он не выдавал сам. Каждая учётная запись видит устройства, на которых выполнен вход, и может завершать сеансы на них по отдельности.
«Оставаться в системе» — необязательная функция, действующая 30 дней, но не для учётных записей с административными правами; они всегда входят с паролем и вторым фактором. Токен состоит из двух частей; проверочная часть хранится в базе данных только в виде хеша. При каждом использовании он заменяется новым, и даже при одновременных запросах каждый токен действителен только один раз, так что украденный токен обнаруживается не позднее следующего настоящего визита.
Ссылки в письмах. Ссылки для подтверждения адреса и сброса пароля хранятся в базе данных только в виде хеша. Ссылка для сброса действительна один час, ссылка для подтверждения регистрации — 72 часа, ссылка для подтверждения изменённого адреса — 24 часа. При изменении адреса электронной почты открытая ссылка для сброса становится недействительной.
Интерфейсы. API-ключи, коды подключения расширений и коды развёртывания хранятся только в виде хеша. API-ключи можно использовать лишь ограниченное число раз в минуту; коды подключения расширений действительны 15 минут и только один раз.
Защита от ботов на общедоступных формах (регистрация, вход, пароль, проверка, инструмент проверки заголовков, opt-out, поддержка и контакты): Google reCAPTCHA, которая загружается только при отправке. Принимается только действительный ответ Google с достаточной оценкой именно для действия данной формы; если Google не отвечает в течение трёх секунд, отправка отклоняется. Подробности — в Политике конфиденциальности.

3.3 Контроль доступа: администрирование серверов

Сервер, доступный из интернета, с помощью пакетного фильтра пропускает только предлагаемые им службы и автоматически блокирует адреса после повторных неудачных попыток входа в администрирование сервера.
Автоматизированные процессы между серверами используют собственные ключи со строго ограниченными правами. Ключ, с помощью которого веб-сервер доставляет новые версии сканера, может выполнять на сервере сканирования только фиксированный список команд и может только копировать в каталог сканера в режиме «только запись»; интерактивный вход с ним невозможен, а каждая отклонённая команда протоколируется. Аналогично сервер сканирования может записывать снимки экрана только в определённый каталог на веб-сервере.
Процесс, обслуживающий сайт, не имеет ни права записи в рабочую установку, ни ключа для сервера сканирования. Развёртывание, запущенное в административной области, лишь создаёт задание, которое выполняет отдельный процесс.
Секреты, такие как учётные данные базы данных и ключи, хранятся в конфигурационных файлах вне обслуживаемого каталога и не копируются при развёртывании. Конфигурация веб-сервера не распространяется через веб-интерфейс.

3.4 Контроль полномочий: права внутри сервиса

Роли. В каждом рабочем пространстве есть роли владельца, администратора и читателя. Изменение, удаление, приглашение и сохранение учётных данных доступны только владельцам и администраторам; изменять роли и удалять участников может только владелец. Приглашение действительно лишь до тех пор, пока отправившее его лицо остаётся владельцем или администратором. Читатели видят адреса вебхуков и чат-каналов только в сокращённом до хоста виде, поскольку один лишь адрес позволяет публиковать сообщения в канале. Проверка выполняется на сервере, а не только в интерфейсе.
Привязка к рабочему пространству. Домены и настройки доступны только участникам рабочего пространства. Для каждой проверки Сервис создаёт отчёт по случайной ссылке, которую невозможно угадать; результаты и снимки экрана проверки доступны по этой ссылке без входа, снимки экрана — только вместе со ссылкой на их отчёт. Ссылка отображается в учётной записи и в оповещениях; кто передаёт её дальше, передаёт дальше и отчёт.
Запросы, изменяющие состояние, требуют токена безопасности для каждого сеанса (защита от CSRF), который сравнивается за постоянное время.
«Просмотр от имени клиента». Для поддержки оператор может видеть приложение так, как его видит Клиент. Просмотр завершается через час, блокирует изменение пароля, адреса, второго фактора, устройств, подписки, экспорт и удаление, на это время закрывает административную область и протоколируется. Его завершение полностью выводит оператора из системы; вернуться в административную область оператор может только после повторного входа с паролем и вторым фактором. Клиент видит это в своём экспорте данных.
Администрирование. Административными правами обладают лишь несколько специально уполномоченных учётных записей; каждый сброс второго фактора администрацией протоколируется.

3.5 Контроль разделения

Данные клиентов логически разделены по рабочим пространствам. Каждый путь чтения и записи в области после входа несёт эту привязку; отчёты дополнительно доступны по своей ссылке (раздел 3.4).
Разработка и эксплуатация ведутся в отдельных установках с отдельными базами данных и отдельными пользователями баз данных. Пользователь разработки не имеет доступа к рабочей базе данных. Реальные данные клиентов в среду разработки не копируются; там мы работаем со сгенерированными тестовыми данными.
Для каждой среды у сканера есть собственные учётные данные с правами только на те данные, которые нужны ему для заданий. Он не может читать учётные записи, данные о расчётах или журналы.
На веб-сервере работают и другие сервисы того же поставщика. У них собственные базы данных и собственные пользователи баз данных без доступа к данным этого сервиса.

4. Шифрование, псевдонимизация и минимизация данных

4.1 Учётные данные для сканирования за входом

Для этой функции Клиент сохраняет имя пользователя и пароль тестовой учётной записи. Это самые чувствительные данные в сервисе, поэтому они защищены иначе, чем всё остальное:

При сохранении веб-сервер шифрует их открытым ключом сервера сканирования (ECIES: X25519 с одноразовым ключом для каждой записи, HKDF-SHA256, AES-256-GCM). Закрытый ключ существует только на сервере сканирования. Веб-сервер, база данных и резервные копии содержат только шифротекст; мы тоже не можем прочитать его там.
Каждая запись криптографически привязана к своему домену. При переносе на другой домен расшифровка не удаётся.
Для сканирования шифротекст прикрепляется к заданию. Сервер сканирования расшифровывает его и передаёт учётные данные в контейнер проверки только через стандартный ввод, никогда — в виде аргумента командной строки, который был бы виден в списках процессов. Как только сервер сканирования его прочитал, шифротекст удаляется из задания; отдельный процесс удаляет возможные остатки не позднее чем через час.
Учётные данные никогда не отображаются, никогда не протоколируются, никогда не выводятся через API и не экспортируются. Интерфейс показывает только первый символ и длину имени пользователя. Удаление перезаписывает шифротекст.
За входом сканер только читает: никаких отправок, никаких активных тестов, никаких снимков экрана, никаких страниц выхода, удаления или расторжения.

4.2 Прочее шифрование и хеши

Пароли, коды восстановления, пароли клиентских порталов, API-ключи, коды подключения и развёртывания, токены «Оставаться в системе», идентификаторы сеансов в списке устройств и ссылки для подтверждения и сброса хранятся только в виде хеша.
Секреты для второго фактора хранятся в зашифрованном виде (раздел 3.2).
Мы не заявляем о шифровании всей базы данных в состоянии хранения. Чувствительные значения защищены по отдельности, как описано выше.

4.3 Минимизация данных за счёт архитектуры

Проверка доставки: считываются только заголовки и не более первых 8 КБ текста. В базу данных попадают только время, привязка, где применимо — ID тестовой отправки, и результат проверки подлинности (SPF, DKIM, DMARC), но никогда не содержимое или полный адрес отправителя. Результат проверки подлинности последнего письма хранится вместе с доменом и перезаписывается следующим; он содержит IP-адрес доставляющего почтового сервера и почтовый домен отправителя. Письмо удаляется из почтового ящика после успешной обработки; если получение или удаление не удаётся, это происходит при следующем успешном запуске.
Проверки: структура форм сохраняется с именами полей, типами и подписями, атрибутами обязательности и видимости, без значений; начала предзаполненных скрытых полей (до 24 символов) и data-атрибутов (до 60 символов) сканер читает только во время проверки и не сохраняет. Снимки экрана полной проверки не редактируются; только браузерные проверки закрывают поля ввода. Адреса получателей форм сохраняются только в виде домена. Активные тестовые отправки содержат только помеченные тестовые тексты без персональных данных.
Расширения для WordPress и TYPO3 передают только ежедневные показатели и характеристики, например перечень плагинов, а для подключённого плагина WordPress также домены ссылок из заблокированных сообщений для коллективной защиты (включено по умолчанию); никакого другого содержимого, никаких имён, адресов или IP-адресов посетителей. Необязательные счётчики ошибок форм и полей по умолчанию отключены.
«Fix it for me»: вставленный код обрабатывается только на время выполнения запроса и не сохраняется.
Значок: изображение значка на сайтах клиентов не устанавливает cookie и не открывает сеанс.
Эксплуатационные уведомления на телефон оператора — это фиксированные тексты без переменных, т. е. без имён, адресов или содержимого. Уведомления об ошибках по электронной почте оператору содержат исходный текст сообщения об ошибке, не очищенный и усечённый до 400 символов; в отдельных случаях он может содержать адреса или ссылки.
Коллективная защита: между расширениями Клиентов передаются только домены из ссылок в заблокированном спаме; обмен IP-сетями отключён.
Местоположение: страна IP-адреса определяется по локальному файлу базы данных; никакие адреса не передаются в службы геолокации.

5. Защита от злоупотребления сканером

Сканер загружает сторонние страницы настоящим браузером. Без защиты он стал бы инструментом, с помощью которого кто-то извне мог бы добраться до нашей внутренней сети или других закрытых целей (подделка запросов на стороне сервера, SSRF). Поэтому существуют два независимых уровня и изоляция каждого отдельного запуска.

5.1 Изолированный запуск

Каждая проверка выполняется в собственном контейнере, который затем удаляется. Он работает без прав администратора, без дополнительных возможностей операционной системы и без возможности повышения привилегий. Его файловая система доступна только для чтения, за исключением небольших временных областей.
Память, число процессов и время выполнения ограничены; запуск, превысивший время, прерывается.

5.2 Сеть: два уровня

Первый уровень, в сканере: перед сканированием, а затем для каждого отдельного запроса браузера, включая перенаправления и встроенное содержимое, проверяется, куда разрешается адрес. Частные, локальные, зарезервированные и документационные сети (IPv4 и IPv6) отклоняются, как и порты, отличные от обычных для веба. Браузер не допускает service workers, а соединения WebSocket закрываются, поскольку и то и другое может обойти эту проверку.
Второй уровень, в сети: контейнеры работают в собственной сети. Правила межсетевого экрана разрешают оттуда соединения с интернетом только на веб-портах; соединения с частными сетями, включая нашу внутреннюю сеть с веб-сервером и базой данных, заблокированы. Исключения, необходимые самому процессу проверки, ограничены необходимым и описаны в нашей внутренней документации. Этот уровень действует и в том случае, если имя разрешается иначе лишь после первой проверки.

5.3 Запросы, выполняемые веб-сервером

Там, где веб-сервер сам обращается к сторонним адресам — для подтверждения контроля над доменом, для инструмента проверки заголовков, для поиска открытых файлов, для запросов пульса, для запросов RDAP и проверки сертификатов, для вебхуков и оповещений в чатах и для необязательной второй точки проверки, — действуют те же правила: только веб-протоколы на обычных веб-портах (вебхуки и оповещения в чатах — только по HTTPS на стандартном порту), только публичные адреса, соединение только именно с заранее проверенным адресом, чтобы имя нельзя было впоследствии перенаправить на внутреннюю цель, перенаправления либо вообще не выполняются, либо выполняются только вручную с повторной проверкой каждый раз, короткие лимиты времени; для подтверждения контроля над доменом, для запросов пульса и для второй точки проверки в браузерных проверках — также ограниченный размер ответа.

5.4 Чего сканер не делает на сторонних сайтах

Активные тестовые отправки (не более пяти за проверку) для Клиентов выполняются только для доменов, по которым предоставлено подтверждение контроля (DNS, метатег, файл или расширение); единственное исключение — внутренние проверки наших собственных тестовых и демонстрационных доменов. Имя хоста домена с подтверждённым контролем нельзя изменить, чтобы подтверждение не перешло на другой хост. Всё остальное пассивно: чтение страниц, как это делает посетитель.
Браузерные проверки доходят до момента перед отправкой и не инициируют ни заказа, ни оплаты, ни отправки.
Домены из списка opt-out не проверяются; текущий мониторинг завершается при следующей плановой проверке.

6. Целостность: передача и ввод

6.1 Транспорт

Приложение доступно из интернета только по HTTPS; браузеру предписывается в течение одного года использовать только HTTPS (HSTS). Сертификаты обновляются автоматически.
Дополнительные заголовки ограничивают встраивание приложения в сторонние страницы, угадывание типов файлов и отправку форм на сторонние адреса. Политика безопасности содержимого (CSP) разрешает выполнять в приложении только те скрипты, которые сервер разрешает вместе с соответствующим ответом; современные браузеры не выполняют внедрённые скрипты или обработчики событий в HTML.
Почтовый ящик проверки доставки опрашивается по зашифрованному соединению с проверкой сертификата.
Вебхуки можно подписывать секретом Клиента (HMAC-SHA256 с меткой времени), чтобы получатель мог проверить происхождение и целостность. Запросы к необязательной второй точке проверки подписываются, а для браузерных проверок — и ответы на них.
Говорим открыто: соединения внутри нашей внутренней сети зашифрованы не везде. Учётные данные для сканирования за входом остаются зашифрованными на всём пути (раздел 4.1).

6.2 Контроль ввода и журналы

Важные действия в учётных записях и рабочих пространствах (например, вход, изменения доменов, каналов оповещений и прав, удаления, доступ поддержки) фиксируются в журнале активности с указанием учётной записи, времени, IP-адреса и страны и удаляются через 365 дн.
Записи о доступе к страницам, ведущиеся для безопасности и предотвращения злоупотреблений, удаляются через 60 дн., журналы ошибок — через 90 дн., содержимое отправленных писем — через 30 дн. Токены доступа в запрашиваемых адресах и источниках перехода (referrer), например в ссылках на отчёты или порталы, отображаются в записях о доступе к страницам только в замаскированном виде.
Принятие договорных документов сохраняется с отображённой версией, её контрольной суммой, временем, IP-адресом и идентификатором браузера.
Журналы доказательств могут снабжаться меткой времени от внешнего удостоверяющего центра меток времени; туда передаётся только контрольная сумма содержимого, а не само содержимое.

7. Доступность и устойчивость

7.1 Резервное копирование

Резервное копирование базы данных выполняется каждую ночь. Резервная копия получает окончательное имя только после проверки её содержимого: успешное завершение программы резервного копирования, не менее одной записи, столько таблиц, сколько их в базе данных, и завершающая строка полного прогона. Более старые резервные копии удаляются только после успешного создания новой.
Каждая резервная копия удаляется через 14 дн. Место хранения находится вне любого обслуживаемого каталога; место внутри проекта отклоняется.
Тест восстановления: раз в неделю последняя резервная копия загружается во временную базу данных, сравнивается по таблицам с рабочей и снова удаляется. Результат сохраняется.
Если резервное копирование или тест не удаётся, отправляется уведомление по электронной почте и на телефон оператора.
Восстановление после инцидента: если база данных выходит из строя или данные повреждены, мы восстанавливаем последнюю проверенную резервную копию. Изменения, внесённые после этой копии, как правило не более чем за один день, при этом могут быть утрачены; если резервное копирование не удалось — соответственно больше. Затем мы повторно выполняем известные более поздние запросы на удаление (раздел 8). Определённого времени восстановления мы не гарантируем.
Ограничение, говорим открыто: резервные копии в настоящее время хранятся в том же месте, что и база данных, и отдельно не шифруются. Они защищают от ошибок эксплуатации, ошибочных изменений и повреждённых данных, но не от утраты самого сервера. Запланирована зашифрованная копия во втором месте (раздел 10).
Учётные данные для сканирования за входом содержатся в резервных копиях только в виде шифротекста; секрет второго фактора — только в зашифрованном виде, с ключом вне базы данных.

7.2 Мониторинг

Процесс контроля состояния каждые пять минут проверяет компоненты сервиса, включая базу данных, очередь и сигнал жизнеспособности (heartbeat) сканера, который сканер регулярно записывает даже в режиме простоя. Если компонент выходит из строя, отправляется уведомление; когда он восстанавливается — отбой тревоги.
Взаимный контроль: процесс контроля состояния не может сообщить о сбое машины, на которой он работает. Поэтому сервер сканирования каждую минуту проверяет, отвечает ли приложение, и после нескольких сбоев подряд сообщает об этом фиксированным текстом на телефон оператора. И наоборот, веб-сервер отслеживает heartbeat сканера; контрольный список настройки показывает, работает ли взаимный контроль.
Оповещение об ошибках: тип ошибки, который ещё никогда не возникал, сообщается один раз немедленно; скопление ошибок вызывает лишь один сигнал на телефон оператора; раз в день отправляется обзор. Таким образом, мы не узнаём об ошибке впервые от Клиента.
Ограничение, говорим открыто: оба сервера находятся в одном месте. О выходе из строя всего местоположения, например электропитания или интернет-подключения, не сообщает ни один механизм оповещения — его замечает человек.

7.3 Изменения и развёртывание

Новые версии сначала собираются и тестируются в отдельной среде разработки. Развёртывание проверяет все предварительные условия до записи первого файла, вносит изменения в схему базы данных и даёт выполняющимся проверкам упорядоченно завершиться перед перезапуском сканера.
Для пути нового Клиента существует smoke-тест по реальному HTTP, который запускается после переключений. Мы не заявляем о наличии автоматизированного набора тестов перед каждым отдельным развёртыванием.

8. Удаление и сроки хранения

Ночной процесс удаления обеспечивает соблюдение сроков, указанных в Политике конфиденциальности и в Соглашении об обработке данных. Он считывает те же настройки, из которых берутся цифры в текстах; поэтому для этих сроков текст и поведение не расходятся.
Результаты проверок, включая снимки экрана, удаляются через 13 мес. (последний по каждому домену сохраняется), показатели расширений — через 13 мес., журналы доставки оповещений — через 90 дн., обращения в поддержку — через 24 мес.
Удаление домена удаляет данные домена, включая проверки, формы, результаты, снимки экрана, отчёты, задания, каналы и журналы оповещений, инциденты, данные о доставке, учётные данные для сканирования за входом и доказательства.
Удаление учётной записи происходит немедленно; рабочие пространства без других участников удаляются вместе с их данными, рабочие пространства с другими участниками переходят к другому участнику — в первую очередь к администраторам, а среди них к состоящему дольше всех. До истечения их собственных сроков сохраняются: журналы, записи в которых сохраняют старый номер учётной записи, больше не указывающий ни на одну существующую учётную запись, включая запись об удалении, а также отправленные письма, подтверждение заключения договора, обращения в поддержку, отчёты о проверках потенциальных клиентов (до 90 дней) и платёжные данные в Stripe; подробности — в Политике конфиденциальности.
Удалённые данные остаются в резервных копиях до истечения их срока через 14 дн. Целенаправленное удаление внутри резервной копии не производится; если резервная копия восстанавливается, известные более поздние запросы на удаление выполняются повторно вручную.

9. Организация и пересмотр

Персонал: в настоящее время сервис эксплуатирует сам владелец. Другие лица получают доступ только после принятия обязательства о конфиденциальности и только в необходимом объёме и обрабатывают данные только по нашим указаниям (ст. 29 и ст. 32(4) GDPR).
Субобработчики: мы привлекаем их только после проверки их гарантий и на основании договора согласно ст. 28(4) GDPR и перечисляем их на странице Субобработчики; подробности регулируются Соглашением об обработке данных.
Нарушения защиты персональных данных: если нарушение защиты персональных данных затрагивает данные, обрабатываемые по поручению, мы уведомляем Клиента без неоправданной задержки, по возможности в течение 48 часов; подробности регулируются Соглашением об обработке данных.
Сообщения об уязвимостях: мы принимаем сообщения на странице Безопасность и через файл /.well-known/security.txt.
Контрольный список настройки и запуска: в административной области контрольный список измеряет состояние важных для безопасности настроек, например резервного копирования, администраторов без второго фактора, настройки почты и heartbeat, и показывает отклонения.
Пересмотр этих мер (ст. 32(1)(d) GDPR): при каждом существенном изменении сервиса, после каждого инцидента безопасности и в остальном не реже одного раза в год. При этом мы оцениваем, эффективны ли меры и соответствуют ли они по-прежнему рискам, и фиксируем результат в новой версии этой страницы или, если ничего не меняется, датой пересмотра в разделе 11. На постоянной основе контрольный список настройки и запуска измеряет состояние охватываемых им настроек.
Внешние аудиты: внешние тесты на проникновение в настоящее время не заказываются, сертификатов безопасности нет. Мы указываем это здесь, чтобы никто не предполагал обратного.

10. Запланировано, ещё не реализовано

Эти пункты не являются принятыми на себя мерами, пока они не будут указаны здесь как реализованные в новой версии:

Резервная копия во втором месте: зашифрованная копия ночной резервной копии вне сервера, чтобы даже полная утрата сервера не приводила к потере данных.
Вторая точка проверки: независимое подтверждение браузерных проверок из второго местоположения подготовлено в сервисе, но не настроено. Без него нет подтверждения из второго местоположения.
Усиление защиты администрирования серверов: работа продолжается. По причинам, указанным в разделе 1, подробности мы не публикуем.

11. Статус и версия

Версия 1.1 · Последнее обновление: 22 октября 2026 г. · в случае расхождений между языковыми версиями преимущественную силу имеет польская версия вместо немецкой; других изменений нет.
Версия 1.0 · Последнее обновление: 11 октября 2026 г. · первая версия в виде отдельной страницы; ранее Приложение 2 к Соглашению об обработке данных. Исправлено по сравнению с прежним приложением: тест восстановления проводится еженедельно, резервные копии находятся на том же сервере, автоматизированный набор тестов не запускается перед каждым развёртыванием, соединения во внутренней сети зашифрованы не везде. Впервые описаны: шифрование учётных данных для сканирования за входом, изоляция сканера, взаимный контроль и оповещение об ошибках.
Изменения публикуются с новым номером версии здесь и в обзоре Изменения договорных документов; при любом ослаблении мер применяется срок уведомления, предусмотренный Соглашением об обработке данных.
В случае расхождений между языковыми версиями преимущественную силу имеет польская версия.

Чем мы можем помочь?