Юридичні відділи працюють з контрактами, доказовими файлами та іншими надзвичайно конфіденційними документами. Типовий процес завантаження PDF‑файлу у хмарний сервіс обміну миттєво створює ризик безпеки: файл живе поза межами вашого корпоративного периметру, і ви втрачаєте детальний контроль над тим, хто може його переглядати і як довго.

А що, якщо ви зможете вбудувати захищений, зашифрований переглядач PDF безпосередньо у ваш .NET‑веб‑портал, гарантуючи, що документ ніколи не торкнеться стороннього сервера?

У цьому посібнику ми розглянемо практичну архітектуру, побудовану навколо Doconut Viewer, SDK переглядача документів для .NET. Він встановлюється у вашій власній програмі і не робить запитів до серверів Doconut, тому документ ніколи не залишає вашу інфраструктуру.

Дві речі, які треба уточнити перед першим кроком, бо решта посібника залежить від них. Doconut.app — це безкоштовний веб‑переглядач, веб‑сайт, а не компонент, і не те, що ви встановлюєте тут. А шифрування, токени та журнал аудиту нижче — це ваші власні інструменти: SDK лише рендерить документи, він не постачає програму відповідності. Doconut не має сертифікату ISO 27001, звіту SOC 2 та атестації HIPAA, тому аргумент щодо відповідності, який ви можете надати регулятору, є архітектурним — файл залишився в межах контролю, який ви вже маєте.

Чому традиційний хмарний обмін не задовольняє потреби

Ризик	Типовий хмарний сервіс	Що робить ця архітектура замість
Ексиль даних — файл зберігається на зовнішніх серверах	Файли зберігаються у сховищі провайдера, часто у регіонах, які ви не контролюєте.	PDF‑файл залишається у вашій інфраструктурі. SDK рендерить його там і не викликає нікого.
Втрата контролю над тривалістю доступу	Посилання на спільний доступ можуть передаватися безстроково.	Ви видаєте короткоживучі одноразові токени. Це ваш код, а не перемикач.
Прогалини у відповідності	Журнали аудиту часто обмежуються подіями «завантаження».	Ви реєструєте кожен запит на перегляд, бо запит надходить до вашої власної точки входу.
Залежність від плагінів	Багато переглядачів вимагають Flash, ActiveX або розширень браузера.	На машині читача нічого не встановлюється; браузер отримує вже відрендерені сторінки.

Огляд рішення

Встановити Doconut Viewer у ваш .NET‑проект.
Зашифрувати PDF‑файли в спокої за допомогою серверного ключа, використовуючи власну криптографію .NET.
Вбудувати переглядач у Razor‑сторінку або MVC‑вид, захищений токеном, який видає ваша програма.
Логувати кожен запит на перегляд для аудиту та виявлення аномалій.

Кроки 2, 3 і 4 — це ваша робота. Частина SDK — це крок 1 і рендеринг; все захисне в цьому дизайні — це код, яким ви володієте, і саме тому його може перевіряти ваша команда.

Нижче наведено докладний покроковий опис кожного етапу, включаючи рекомендації щодо управління ключами, безпеки токенів та журналу відповідності.

Крок 1 – Підготовка .NET‑середовища

Відкрийте рішення у Visual Studio (рекомендовано 2022 або новіша версія).
Виберіть цільовий фреймворк. Doconut Viewer підтримує ASP.NET, MVC, .NET Core, .NET 6+ та Blazor. Зафіксуйте версію, яку обрали — деталі інтеграції залежать від неї.
Встановіть SDK зі сторінки завантаження Doconut, використовуючи пакет і документацію, що відповідають обраній версії. Візьміть назву пакету та кроки налаштування саме з цієї документації, а не зі статті; обидва джерела змінювалися між випусками.

Тримайте конфігурацію ліцензії поза системою контролю версій, доки працюєте над прототипом. Це найпоширеніша причина витоку конфіденційної інформації.

Додаткові поради

Зберігайте посилання на пакет у файлі Directory.Packages.props для централізованого керування версіями у кількох сервісах.

Крок 2 – Зберігання PDF‑файлів з потужним шифруванням

2.1 Вибір алгоритму шифрування

Це ваше рішення і ваш код. System.Security.Cryptography у .NET надає AES-256-GCM, який забезпечує автентифіковане шифрування — конфіденційність і цілісність одночасно — і є обґрунтованим типово‑за замовчуванням для документів у спокої.

Жоден алгоритм шифрування не робить систему відповідною GDPR, HIPAA чи ISO 27001. Ці стандарти запитують про процеси, контроль доступу, зберігання та докази. Шифрування — лише один із контролів серед багатьох, і бібліотека переглядача не може забезпечити решту.

2.2 Реалізація безпечного управління ключами

Ніколи не вбудовуйте ключі у код. Використовуйте Azure Key Vault, AWS KMS або HashiCorp Vault для отримання ключа шифрування під час виконання.
Регулярно змінюйте ключі — зазвичай кожні 90 днів. Заплануйте завдання повторного шифрування заздалегідь; виявлення, що немає способу оновити ключ, під час інциденту, — поганий досвід.

Крок 3 – Генерація часово обмеженого одноразового токену

Токен попереднього перегляду діє як одноразовий бейдж з автоматичним закінченням терміну дії. Він містить:

User ID – Хто має право переглядати документ.
PDF ID – Який зашифрований файл транслювати.
Expiration – Зазвичай 5–10 хвилин, налаштовується згідно політики.
Signature – Підпис HMAC або RSA для запобігання підробці.

3.1 Зауваження щодо безпеки

TLS скрізь – Завжди передавайте токен через HTTPS.
Принцип найменших привілеїв – Кодуйте лише дані, необхідні для попереднього перегляду; уникайте вбудовування зайвих претензій.
Відкликання токену – Простий «чорний список» у Redis дозволяє миттєво відкликати токен, якщо змінюються права користувача.

Крок 4 – Вбудування DoconutApp Viewer

4.1 Точка потокової передачі на боці сервера

Розшифровуйте в пам'яті якщо ваша модель загрози це передбачає, щоб відкритий текст ніколи не потрапляв на диск. Це ваша кінцева точка, тому рішення і код залишаються вашими.
Рендеринг відбувається на вашому сервері, а не в браузері користувача. Це дозволяє браузеру показувати документ, не отримуючи вихідний файл — і це причина перевіряти, куди SDK записує тимчасовий результат рендерингу і як він видаляється.

4.2 Плагіни не потрібні

Користувач отримує відрендерені сторінки через стандартні веб‑технології, тому переглядач працює в Chrome, Edge, Firefox та Safari без жодних плагінів, ActiveX‑контролів чи Flash. На ноутбуці юриста нічого не встановлюється, що зазвичай є різницею між успішним та неуспішним аудитом безпеки.

Крок 5 – Аудит та журналювання доступу для відповідності

Юридичні команди часто потребують незмінного сліду того, хто і коли переглянув який контракт. Реалізуйте структурований конвеєр журналювання:

Поле	Опис
`UserId`	Ідентифікатор запитуючого юридичного спеціаліста
`PdfId`	Внутрішнє посилання на зашифрований документ
`Timestamp`	UTC‑час запиту попереднього перегляду
`IpAddress`	IP‑адреса джерела (корисно для перевірки геолокації)
`UserAgent`	Строка браузера для судово‑медичного аналізу
`Result`	Успіх / Помилка (наприклад, недійсний токен, помилка розшифрування)

Кращі практики

Зберігайте журнали в додатково‑только, незмінному сховищі (наприклад, Azure Log Analytics, Splunk або S3‑бакеті з одноразовим записом).
Увімкніть сповіщення про аномальні патерни — наприклад, коли один і той же токен використовується з двох різних IP‑адрес за кілька секунд.
Політика зберігання: Зберігайте журнали протягом періоду, вимаганого вашою юрисдикцією (зазвичай 7 років для юридичних записів).

Швидкий підсумок

Встановіть Doconut Viewer у ваш .NET‑проект, скориставшись документацією для вашої версії.
Шифруйте PDF‑файли під час запису за допомогою AES-256-GCM з бібліотеки криптографії .NET; керуйте ключами через сховище.
Видавайте короткоживучий одноразовий токен попереднього перегляду коли користувач запитує перегляд.
Рендерьте на вашому сервері та вбудовуйте переглядач у Razor‑сторінку. Документ ніколи не передається третій стороні, і на машині користувача нічого не встановлюється.
Журнуйте кожен перегляд для аудиту, з сповіщенням про підозрілі патерни.

Пункти 2, 3 і 5 — це ваш код. Це чесний розподіл обов’язків, і варто чітко зазначити це у вашій документації з безпеки, бо ревізор зрештою запитає, яка сторона відповідає за що.

Висновок

Обмін захищеними PDF не обов’язково має включати сторонню службу. За допомогою Doconut Viewer у вашому власному .NET‑порталі ваш юридичний відділ може представити конфіденційні контракти, матеріали судових процесів та внутрішні політики, не дозволяючи файлу покинути вашу інфраструктуру.

Те, що SDK дає вам, — це остання частина: рендеринг у вашому середовищі без вихідних запитів. Сквозне шифрування, контроль доступу та журнал аудиту належать вам — і саме в цьому сенс, бо переглядач, який стверджує, що забезпечує їх, змушуватиме вас довіряти відповідності постачальника, а не вашій власній.

Готові спробувати? Відвідайте doconut.com — пробна ліцензія безкоштовна, а живі демонстрації — найшвидший спосіб переконатися, чи рендеринг витримує ваш найскладніший матеріал, перш ніж ви напишете будь‑який код вище.

Впровадження цих кроків дасть офіцерам з комплаєнсу спокій, зменшить поверхню атаки та збереже ваші PDF‑файли всередині корпоративного брандмауера — саме та безпекова позиція, яка потрібна будь‑якій юридичній команді.

Залишайтеся в безпеці, дотримуйтесь вимог і тримайте запечатані конверти там, де їм місце: у вашому власному сховищі.