Как добавить Doconut в ориентированное на безопасность .NET приложение
8/14/2026

Как добавить Doconut в ориентированное на безопасность .NET приложение

Руководство по защите в глубине (defense-in-depth) по использованию Doconut с авторизацией, принадлежащей приложению, границами хранилища, удержанием, контролем браузера и проверкой.

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

Защищённый документ, окружённый многоуровневыми контролями доступа и журналом аудита
Защищённый документ, окружённый многоуровневыми контролями доступа и журналом аудита

Статья Doconut о best practices безопасного просмотра документов описывает серверный рендеринг как один из слоёв в дизайне defense-in-depth. Поэтому эта статья сосредоточена на обязанностях приложения в отношении Doconut и направляет детали реализации к поддерживаемой документации продукта.


Начните с модели угроз

«Приватный» и «безопасный» — это не настройки. Определите события, которые необходимо предотвратить или обнаружить, прежде чем выбирать средства контроля.

РискПримерКонтроль приложения
Несанкционированный доступПользователь меняет идентификатор документа в URLАвторизация на уровне объекта для каждого запроса
Пересечение арендаторовВалидный пользователь запрашивает файл другого клиентаОбласть арендатора включена в решение об авторизации
Раскрытие источникаПуть к хранилищу или оригинальный файл возвращаются напрямуюСерверный контроль поиска и потока рендеринга
Устаревший доступСсылка остаётся рабочей после изменения роли или случаяКраткоживущий сеанс плюс повторная проверка авторизации
Чрезмерное хранениеВременные вводные или выводные данные накапливаютсяЯвные задачи жизненного цикла с наблюдаемыми результатами
Чувствительное логированиеТокены или пути к файлам появляются в логахСтруктурированное редактирование и телеметрия только с идентификаторами

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

Юридический сценарий использования Doconut служит полезной ссылкой на роль продукта внутри аутентифицированных рабочих процессов по делам, контрактам, доказательствам и соответствию. Он также подчёркивает архитектурную границу: разрешения, хранилище, клиентские записи и бизнес‑правила остаются рядом с хост‑приложением.

Авторизуйте перед открытием документа

Выполните аутентификацию и авторизацию на уровне объекта перед открытием документа с помощью Doconut. Официальное руководство по настройке для .NET 6 и выше показывает, как конфигурировать просмотрщик и как открывать документ на стороне сервера; разместите проверки идентификации приложения, арендатора и разрешений на документ до этого шага продукта.

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

Избегайте прямого принятия пути к файловой системе, ключа хранилища или удалённого URL из браузера. Преобразуйте идентификатор документа, принадлежащий приложению, в его место хранения на сервере, затем подтвердите, что полученный объект принадлежит авторизованному арендатору и рабочему процессу.

Разделите просмотрщик и политику хранилища

Просмотрщик не должен определять ваш период удержания. Документируйте каждый класс хранилища и владельца:

  • Исходный документ — контролируется вашей основной политикой контента или записей.
  • Временные рабочие файлы — создаются для обработки и удаляются по расписанию, наблюдаемому жизненному циклу.
  • Отрисованные страницы или кэши — ограничены минимальным полезным сроком и защищены так же, как источник.
  • Экспортные и готовые к печати файлы — создаются только при наличии соответствующего разрешения у пользователя.
  • Логи и события аудита — содержат идентификаторы и результаты, а не содержимое документа или учётные данные.

Шифрование в транзите и в состоянии покоя зависит от вашего веб‑сервера, поставщика хранилища, управления ключами и настроек развертывания. Проверьте эти контролы в реальной среде; не делайте выводы только на основе наличия библиотеки просмотрщика.

Используйте краткоживущие ссылки осмотрительно

Краткоживущая ссылка может сократить время, доступное для повторного воспроизведения, но не заменяет авторизацию. Если ваш дизайн использует подписанный маршрут или токен сеанса:

  1. Привяжите его к одному документу и предполагаемой операции.
  2. Задайте узкий срок жизни, основанный на рабочем процессе.
  3. Не размещайте чувствительные претензии или места хранения в открытом виде.
  4. Повторно проверяйте авторизацию для привилегированных операций.
  5. Определите, что означает отзыв до естественного истечения срока.
  6. Держите токены вне аналитики, рефереров, сообщений об исключениях и скриншотов.

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

Поймите, что могут и чего не могут клиентские ограничения

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

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

Не превращайте функции продукта в заявления о соответствии

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

Для оценки GDPR задокументируйте как минимум:

  • Где обрабатываются и хранятся исходные и производные файлы
  • Кто выступает контролёром и процессором для каждой службы
  • Какие субподрядчики и передачи задействованы
  • Как запросы на удаление достигают каждого класса хранилища и политики резервного копирования
  • Какие события логируются и как долго логи остаются доступными
  • Как проводятся обзоры доступа и реагирование на инциденты

Пусть заинтересованные стороны по конфиденциальности и юридическим вопросам проверят эти решения для вашего развертывания.

Добавьте заголовки безопасности и правила кэширования

Для аутентифицированных маршрутов предварительного просмотра оцените ограничительную Content Security Policy, политику фреймов, защиту от MIME‑sniffing и политику рефереров. Если просмотр происходит внутри iframe, явно укажите допустимые родительские источники.

Выбирайте заголовки кэша в зависимости от чувствительности и маршрута рендеринга. no-store может быть уместен для некоторых ответов, но может влиять на производительность и не стирает уже захваченный контент. Тестируйте поведение браузера, прокси и CDN, а не полагайтесь только на один заголовок.

Логируйте решения, а не секреты

Полезное событие аудита может содержать:

  • Идентификаторы пользователя и арендатора
  • Идентификатор документа
  • Запрошенную операцию
  • Результат авторизации
  • Метку времени и correlation ID
  • Результат удержания или очистки

Избегайте логирования сырых токенов, строк запросов, URL‑ов хранилища, имён документов, содержащих персональные данные, или извлечённого текста. Защитите журналы аудита от изменения и ограничьте доступ только тем командам, которым это необходимо.

Проверьте полный поток

Тестирование безопасности должно включать негативные сценарии:

  • Изменить идентификатор документа, оставаясь аутентифицированным.
  • Повторно использовать URL‑превью от другого пользователя или арендатора.
  • Вызывать конечные точки страниц, миниатюр, печати и экспорта напрямую.
  • Истечь сеанс во время длительного превью.
  • Удалить разрешение пользователя, пока документ открыт.
  • Отправить неподдерживаемый, слишком большой, повреждённый или защищённый паролем ввод.
  • Подтвердить, что задачи очистки удаляют подходящие данные и сообщают о сбоях.
  • Проверить логи, аналитику и страницы ошибок на наличие чувствительных значений.

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

Заключение

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