Что должно отображаться на странице проверки отчёта по QR-коду?

Короткий ответ: какова задача страницы верификации?

Страница должна показывать идентификатор отчёта, актуальную редакцию, статус публикации, результат проверки подписи и целостности, время верификации; она не должна открывать всем лишние персональные данные и полное содержимое отчёта.

QR-код — лишь носитель, ведущий по правильному адресу. Доверие создаёт то, что открытая страница в реальном времени соответствует канонической записи отчёта, не считает неоднозначный результат действительным и ясно объясняет пользователю, что именно проверено.

Какие сведения обязательны на странице верификации?

Короткий ответ: пользователь должен сначала увидеть результат, а затем — для какого отчёта и какой версии он получен. Технические детали должны пояснять результат, а не затенять главное сообщение.

Разъяснение BTK об электронной подписе указывает, что безопасная электронная подпись позволяет установить личность подписанта и определить, были ли изменены подписанные данные после подписания. Поэтому «запись найдена» и «подпись и целостность содержимого верифицированы» — не одно и то же.

Как разграничить «действителен», «недействителен» и «не верифицирован»?

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

• Действителен: Запрошенная версия отчёта найдена, статус публикации корректен, проверки подписи и целостности успешно завершены согласно заданной политике.
• Недействителен: Содержимое изменено, криптографическая проверка подписи не пройдена или запись явно находится в состоянии отмены/недействительности.
• Не верифицирован: Не удалось получить статус сертификата, служба верификации не ответила, доказательства неполны либо невозможно вынести решение о целостности записи.

ETSI TS 119 102-2 предусматривает, что в отчёте о верификации вместе с результатом фиксируются структурированные сведения о верификаторе и использованных объектах верификации. Технический аналог в реализации VizyonTech — показать конечному пользователю простой результат, но сохранить в журнале аудита связанные с ним сведения о верификаторе, политике/версии и ссылки на технические доказательства.

На экране непредвиденной ошибки не следует показывать трассировку стека, идентификаторы базы данных, путь сертификата или имя внутреннего сервиса. Согласно подходу OWASP «deny-by-default», при сбое системы результат должен оставаться «не верифицирован», а пользователю следует предоставить безопасный опорный код поддержки.

Насколько подробно показывать результат проверки электронной подписи?

Короткий ответ: вместо значка с юридическим вердиктом следует показывать простую и проверяемую сводку фактически выполненных технических проверок.

Само наличие подписи ещё не означает, что отчёт актуален или операционно авторизован. Экран должен как минимум разделять результат проверки целостности подписи, время подписания, время проверки сертификата и, при наличии, результат метки времени. Если личность подписанта отображается, следует использовать только поля, необходимые для целей верификации.

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

Для проектирования потока отчётов до подписания вы можете обратиться к руководству по процессу электронной подписи в инспекционных отчётах . QR-страница — это контролируемый интерфейс верификации этой цепочки, открытый внешнему пользователю.

Какие сведения не должны быть общедоступными?

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

Основные принципы KVKK требуют обработки персональных данных в связке с целью, ограниченно и соразмерно. Следует исходить из того, что QR-ссылка может быть передана третьим лицам; открытый вид должен проектироваться с учётом этого риска.

• Не показывайте прямые персональные данные, такие как номер турецкого удостоверения личности, адрес, телефон и электронная почта.
• Не публикуйте изображение собственноручной подписи, излишние детали сертификата и полный серийный номер.
• Не открывайте по умолчанию конфиденциальные данные объектов клиента, приложения с измерениями и полный PDF отчёта.
• Если имя подписанта не обязательно, используйте роль или маскированное имя; необходимость задокументируйте целью обработки данных.
• Защитите скачивание подробных файлов аутентификацией, проверкой полномочий и журналом действий.

Как отображать сведения о редакции и отмене?

Вместо незаметного удаления старого отчёта явно указывайте его статус и давайте безопасную ссылку на актуальную версию. Так распределённые старые PDF можно проверить задним числом.

Статусы «актуален», «опубликована новая редакция взамен», «отменён» и «ожидает публикации» должны быть раздельными. Если причина отмены содержит конфиденциальные сведения, следует показывать общий класс, а детали оставить авторизованному пользователю. Новая редакция не должна перезаписывать URL или историю старой записи; связь между двумя записями сохраняется в журнале аудита.

Каким должно быть мобильное и доступное взаимодействие с верификацией?

Результат должен пониматься на одном экране, быстро и без опоры только на цвет. Поскольку QR чаще открывают с телефона, первый экран должен показывать идентификатор отчёта и результат вместе.

• Передавайте статус одновременно текстом, значком и с достаточным контрастом.
• Сообщайте изменения статуса вспомогательным технологиям через соответствующую живую область или статусную роль.
• Делайте области касания комфортно выбираемыми; не заставляйте горизонтально прокручивать таблицу.
• Наглядно показывайте, что ссылка ведёт на подлинный домен VizyonTech и работает по HTTPS.
• Если QR не читается, предоставьте альтернативный запрос по номеру отчёта и безопасному коду верификации.

WCAG 2.2 требует текстовых альтернатив, понятного содержимого и программно определяемых статусных сообщений. Поэтому зелёный/красный цвет или галочка/крестик сами по себе недостаточны.

Как провести пилот процесса верификации VizyonTech?

Решение Vizyon Periyodik при оценке испытайте на реалистичных, но обезличенных примерах как минимум следующие сценарии: актуальный и действительный отчёт, старая редакция, отменённая запись, изменённый файл, тайм-аут сервиса верификации и несанкционированный доступ к полному отчёту.

Критерий успеха — не просто открытие QR. Понимает ли пользователь, какой отчёт он проверяет, остаётся ли система закрытой в неоднозначной ситуации, не утекают ли лишние данные, читается ли результат на мобильном экране и может ли команда поддержки отследить инцидент по безопасному опорному коду? Пилот должен дать доказательства ответов на эти вопросы.