Los departamentos legales manejan contratos, archivos de evidencia y otros documentos altamente confidenciales. El flujo de trabajo común de subir un PDF a un servicio de compartición basado en la nube crea instantáneamente un riesgo de seguridad: el archivo vive fuera de su perímetro corporativo, y pierde el control granular sobre quién puede verlo y por cuánto tiempo.

¿Y si pudiera incrustar un visor de PDF seguro y cifrado directamente en su portal web .NET, garantizando que el documento nunca toque un servidor de terceros?

En esta guía recorremos una arquitectura práctica construida alrededor de Doconut Viewer, el SDK de visor de documentos .NET. Se instala en su propia aplicación y no realiza llamadas a los servidores de Doconut, por lo que el documento nunca abandona su infraestructura.

Dos cosas que deben quedar claras antes del primer paso, porque el resto de la guía depende de ellas. Doconut.app es el visor web gratuito — un sitio web, no un componente, y no lo que instala aquí. Y el cifrado, los tokens y el registro de auditoría a continuación son suyos para construir: el SDK renderiza documentos, no incluye un programa de cumplimiento. Doconut no posee certificado ISO 27001, informe SOC 2 ni certificación HIPAA, por lo que el argumento de cumplimiento que realmente puede presentar a un regulador es arquitectónico — el archivo permaneció dentro de un límite que ya controla.

Por qué el intercambio tradicional en la nube es insuficiente

Riesgo	Servicio de nube típico	Qué hace esta arquitectura en su lugar
Exilio de datos - archivo almacenado en servidores externos	Los archivos se guardan en el almacenamiento del proveedor, a menudo en regiones que no puede controlar.	El PDF permanece en su propia infraestructura. El SDK lo renderiza allí y no llama a nadie.
Pérdida de control sobre la duración del acceso	Los enlaces de compartición pueden ser reenviados indefinidamente.	Usted emite tokens de corta duración y un solo uso. Esto es código que usted escribe, no un interruptor que active.
Brechas de cumplimiento	Los registros de auditoría a menudo se limitan a eventos de "descarga".	Registra cada solicitud de previsualización, porque la solicitud va a su propio endpoint.
Dependencia de complementos	Muchos visores requieren Flash, ActiveX o extensiones del navegador.	No se instala nada en la máquina del lector; el navegador recibe páginas renderizadas.

Visión general de la solución

Instale Doconut Viewer en su proyecto .NET.
Cifre los PDFs en reposo con una clave del lado del servidor, usando la criptografía propia de .NET.
Incruste el visor en una página Razor o vista MVC, detrás de un token que su aplicación emite.
Registre cada solicitud de previsualización para rastros de auditoría y detección de anomalías.

Los pasos 2, 3 y 4 son trabajo de su aplicación. La parte del SDK es el paso 1 y la renderización; todo lo protector en este diseño es código que usted posee, lo que también explica por qué puede ser auditado por su propio equipo.

A continuación se muestra una guía detallada de cada paso, incluidas recomendaciones de mejores prácticas para la gestión de claves, la seguridad de tokens y el registro de cumplimiento.

Paso 1 – Prepare su entorno .NET

Abra su solución en Visual Studio (se recomienda 2022 o posterior).
Elija su framework objetivo. Doconut Viewer admite ASP.NET, MVC, .NET Core, .NET 6+ y Blazor. Registre la versión que elija — los detalles de integración son específicos de la versión.
Instale el SDK desde la página de descarga de Doconut, usando el paquete y la documentación que coincidan con la versión que seleccionó. Tome el nombre del paquete y los pasos de configuración de esa documentación en lugar de un artículo; ambos han cambiado entre versiones.

Mantenga la configuración de la licencia fuera del control de versiones mientras está allí. Es lo más común que se filtra de un prototipo funcional.

Consejos Adicionales

Almacene la referencia del paquete en un archivo Directory.Packages.props para la gestión centralizada de versiones entre varios servicios.

Paso 2 – Almacenar PDFs con Cifrado Fuerte

2.1 Elegir un Algoritmo de Cifrado

Esta es su decisión y su código. System.Security.Cryptography en .NET le brinda AES-256-GCM, que proporciona cifrado autenticado — confidencialidad e integridad juntas — y es una opción predeterminada defensible para documentos en reposo.

Ningún algoritmo de cifrado hace que un sistema cumpla con GDPR, HIPAA o ISO 27001. Estos marcos preguntan sobre procesos, control de acceso, retención y evidencia. El cifrado es un control entre muchos, y una biblioteca de visualización no puede proporcionar el resto.

2.2 Implementar una Gestión Segura de Claves

Nunca codifique las claves en el código. Use Azure Key Vault, AWS KMS o HashiCorp Vault para obtener la clave de cifrado en tiempo de ejecución.
Rote las claves regularmente — cada 90 días es una práctica común. Planifique el trabajo de recifrado antes de necesitarlo; descubrir que no tiene forma de rotar una clave es algo negativo que aprender durante un incidente.

Paso 3 – Generar un Token de Tiempo Limitado y de Un Solo Uso

El token de vista previa actúa como una credencial de un solo uso que expira automáticamente. Incluye:

User ID – Quién está autorizado a ver el documento.
PDF ID – Qué archivo cifrado transmitir.
Expiration – Normalmente 5–10 minutos, configurable según la política.
Signature – Firmado con HMAC o RSA para evitar manipulaciones.

3.1 Consideraciones de Seguridad

TLS en todas partes – Siempre sirva el token mediante HTTPS.
Principio de menor privilegio – Codifique solo los datos necesarios para la vista previa; evite incrustar reclamos adicionales.
Revocación de tokens – Una simple “lista negra” en Redis permite la revocación inmediata si los derechos de acceso de un usuario cambian.

Paso 4 – Incrustar el DoconutApp Viewer

4.1 Punto de Extremo de Transmisión del Lado del Servidor

Descifrar en memoria si su modelo de amenaza lo requiere, de modo que el texto plano nunca se guarde en disco. Este es su punto de extremo, por lo que es su decisión y su código para revisar.
El renderizado ocurre en su servidor, no en el navegador del lector. Eso es lo que permite que el navegador muestre el documento sin recibir nunca el archivo fuente — y también es la razón para verificar dónde el SDK escribe la salida de renderizado temporal y qué la elimina.

4.2 No se Requieren Complementos

El lector recibe páginas renderizadas mediante tecnologías web estándar, por lo que el visor funciona en Chrome, Edge, Firefox y Safari sin complementos, controles ActiveX o dependencia de Flash. No se instala nada en el portátil de un abogado, lo que suele ser la diferencia entre una revisión de seguridad que se completa y una que no lo hace.

Paso 5 – Auditar y Registrar el Acceso para Cumplimiento

Los equipos legales a menudo necesitan una traza a prueba de manipulaciones de quién vio qué contrato y cuándo. Implemente una canalización de registro estructurado:

Campo	Descripción
`UserId`	Identificador del profesional legal solicitante
`PdfId`	Referencia interna al documento cifrado
`Timestamp`	Hora UTC de la solicitud de vista previa
`IpAddress`	IP de origen (útil para verificaciones de geolocalización)
`UserAgent`	Cadena del navegador para análisis forense
`Result`	Éxito / Fallo (p. ej., token inválido, error de descifrado)

Mejores Prácticas

Almacene los registros en un almacén de datos solo de anexado e inmutable (p. ej., Azure Log Analytics, Splunk o un bucket S3 de escritura única).
Habilite alertas para patrones anormales — como el mismo token usado desde dos IP distintas en segundos.
Política de retención: Mantenga los registros durante el período requerido por su jurisdicción (comúnmente 7 años para registros legales).

Resumen Rápido

Instale Doconut Viewer en su proyecto .NET, usando la documentación para su versión.
Cifre PDFs al escribir con AES-256-GCM de la propia biblioteca criptográfica de .NET; gestione las claves mediante un servicio de bóveda.
Emita un token de vista previa de corta duración y de un solo uso cuando un usuario solicite una vista.
Renderice en su servidor e incruste el visor en una página Razor. El documento nunca se envía a un tercero, y no se instala nada en la máquina del lector.
Registre cada vista previa para auditoría, con alertas para patrones sospechosos.

Los puntos 2, 3 y 5 son su código. Esa es la división honesta del trabajo, y vale la pena declararlo claramente en su propia documentación de seguridad, porque un revisor eventualmente preguntará qué parte es responsable de qué.

Conclusión

Compartir PDFs de forma segura no tiene que involucrar un servicio de terceros. Con Doconut Viewer dentro de tu propio portal .NET, tu departamento legal puede presentar contratos confidenciales, pruebas de litigio y políticas internas sin que el archivo salga nunca de tu infraestructura.

Lo que el SDK te brinda es esa última parte: renderizado, en tu entorno, sin llamadas externas. El cifrado de extremo a extremo, el control de acceso y el registro de auditoría son tuyos — que es el punto, porque un visor que afirmara proporcionar eso te estaría pidiendo que confíes en el cumplimiento de un proveedor en lugar de en el tuyo propio.

¿Listo para probarlo? Visita doconut.com — la licencia de prueba es gratuita, y las demos en vivo son la forma más rápida de ver si el renderizado se mantiene en tu prueba más exigente antes de escribir cualquier código arriba.

Implementar estos pasos le dará a los oficiales de cumplimiento tranquilidad, reducirá la superficie de ataque y mantendrá tus PDFs firmemente dentro del firewall corporativo, exactamente la postura de seguridad que cualquier equipo legal necesita.

Mantente seguro, mantente conforme y guarda esos sobres sellados donde pertenecen: dentro de tu propia bóveda.