Як додати Doconut до безпечно‑орієнтованого .NET застосунку
8/14/2026

Як додати Doconut до безпечно‑орієнтованого .NET застосунку

Посібник з глибокого захисту щодо використання Doconut з авторизацією, що належить застосунку, межами сховища, зберіганням, контролем браузера та верифікацією.

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

Захищений документ, оточений багаторівневими контролями доступу та журналом аудиту
Захищений документ, оточений багаторівневими контролями доступу та журналом аудиту

Стаття Doconut про практики безпечного перегляду документів описує серверний рендеринг як один шар у дизайні глибокого захисту. Тому ця стаття зосереджується на відповідальності застосунку щодо 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 постачає можливість перегляду документів, описану в його офіційній документації; ваш застосунок забезпечує автентифікацію, авторизацію, контролі сховища, зберігання, моніторинг та реагування на інциденти. Явне визначення цих обов’язків створює сильніші контролі та більш чесні заяви про конфіденційність.