Eliminar un botón de descarga puede apoyar un flujo de trabajo solo de lectura, pero no hace que un documento visible sea imposible de copiar. Una implementación segura necesita autorización del lado del servidor, almacenamiento protegido, sesiones de corta duración, registro cuidadoso y una comprensión honesta de lo que las restricciones de la interfaz de usuario pueden lograr.
Doconut ofrece un visor de documentos .NET incrustado para aplicaciones empresariales. Este tutorial explica el diseño de seguridad circundante sin publicar propiedades de configuración adivinadas ni otro código fuente no documentado de Doconut.
1. Definir qué significa “solo de lectura”
Comience con una política precisa. Diferentes equipos pueden usar “solo de lectura” para referirse a:
- No ofrecer el archivo original como descarga.
- No mostrar una acción de exportación.
- No permitir la impresión.
- Permitir la visualización solo durante una sesión autorizada.
- Impedir que los usuarios accedan directamente a la ubicación de almacenamiento.
- Añadir registros de auditoría cuando se abre un documento.
Estos son controles separados. Decida cuáles son necesarios y verifique que su producto Doconut seleccionado, complementos y licencia soporten el comportamiento del visor que necesita.
Nunca prometa que un documento visible no pueda ser capturado. Capturas de pantalla, cámaras, herramientas de accesibilidad, capacidades del navegador y acceso autorizado a los píxeles mostrados hacen que la prevención absoluta sea poco realista.
2. Proteger el archivo original
El documento original debe permanecer en un almacenamiento protegido del lado del servidor.
Utilice:
- Identificadores de documento generados por el servidor
- Permisos de almacenamiento restringidos
- Cifrado en reposo cuando sea necesario
- Una política de retención documentada
- Permisos separados para carga, visualización, exportación y administración
No envíe credenciales de almacenamiento, rutas de archivo sin restricciones o URLs públicas permanentes al cliente.
3. Autorizar cada solicitud de documento
En ASP.NET Core, proteja la ruta del visor con los mecanismos estándar de autenticación y autorización.
El servidor debe verificar:
- Que el usuario esté autenticado.
- Que el documento exista.
- Que el usuario tenga permiso para ver ese documento específico.
- Que la acción solicitada esté permitida para el rol del usuario y el estado actual del flujo de trabajo.
El atributo [Authorize] puede proteger una ruta, mientras que políticas, reclamaciones o autorización basada en recursos pueden tomar la decisión específica del documento.
La autorización también debe cubrir cualquier punto final que devuelva datos del documento, páginas, exportaciones, anotaciones o salida de impresión. Asegurar solo la página inicial deja rutas alternativas expuestas.
4. Separar permisos de visualización y descarga
Modele los permisos explícitamente en lugar de inferirlos a partir de un botón oculto.
Por ejemplo:
CanViewDocumentCanDownloadOriginalCanExportDocumentCanPrintDocumentCanManageDocument
Estos nombres describen políticas de la aplicación, no APIs de Doconut. Su capa de autorización debe evaluarlos en el servidor antes de ejecutar la acción correspondiente.
Un administrador puede tener permiso de descarga mientras que otro usuario autenticado solo tiene permiso de visualización. Ambos usuarios pueden compartir la misma página de la aplicación recibiendo capacidades autorizadas diferentes.
5. Configurar el visor según la documentación oficial
Utilice solo los nombres de configuración y los pasos de integración documentados para la versión exacta de Doconut instalada en su aplicación.
La página verificada del Visor Doconut brinda información actual del producto. La página de descarga y documentación de Doconut ofrece recursos de instalación y ejemplos específicos por versión.
Si el producto instalado expone una configuración compatible para ocultar o desactivar una acción de descarga:
- Aplíquela según la documentación oficial.
- Trátela como un control de interfaz de usuario y flujo de trabajo.
- Mantenga protegido el punto final del servidor relacionado.
- Pruebe que los usuarios no autorizados no puedan eludirla con una solicitud directa.
No copie propiedades de configuración adivinadas de un artículo no relacionado y asuma que están soportadas.
6. Mantener la integración del visor detrás de un servicio
Un servicio de aplicación dedicado puede:
- Resolver el documento autorizado
- Abrirlo mediante una abstracción de almacenamiento aprobada
- Aplicar la configuración del visor soportada
- Liberar flujos y recursos temporales
- Registrar eventos de auditoría saneados
- Devolver errores seguros al controlador
Esto mantiene los detalles específicos del SDK fuera de las políticas de autorización y del código de presentación.
Tipos estándar de .NET como Stream, FileStream, CancellationToken y servicios inyectados por dependencia pueden formar el límite de la aplicación circundante. Siga la propia documentación de Doconut para las llamadas al SDK.
7. Aplicar defensa en profundidad
Un flujo de trabajo solo de lectura puede incluir:
- Autenticación y autorización a nivel de recurso
- Aislamiento de red y almacenamiento
- Duración corta de la sesión
- Rutas restringidas de exportación e impresión
- Marca de agua cuando sea compatible y apropiada
- Eventos de auditoría para el acceso a documentos
- Límites de velocidad y controles de concurrencia
- Reglas claras de retención y limpieza
- Monitoreo de seguridad para patrones de acceso inusuales
Ningún control único es suficiente. Un botón oculto sin protección del servidor es especialmente fácil de eludir.
8. Registrar accesos sin filtrar datos
Campos útiles de auditoría incluyen:
- Identificador del documento en la aplicación
- Identificador del usuario autorizado
- Marca de tiempo
- Acción solicitada
- Resultado
- Identificador de correlación
- Razón saneada del rechazo o fallo
Evite registrar:
- Contenido del documento
- Credenciales de almacenamiento
- Tokens de acceso
- URLs sensibles
- Rutas completas del servidor
- Información personal innecesaria
Proteja los registros de auditoría según su sensibilidad y requisitos de retención.
9. Probar intentos de eludir la UI
No se detenga después de confirmar que falta un botón en la barra de herramientas.
Pruebe si un usuario solo de lectura puede:
- Solicitar directamente la ruta del archivo original
- Llamar a una ruta de exportación o impresión
- Cambiar un identificador de documento
- Reutilizar una sesión expirada
- Acceder al documento de otro usuario
- Descubrir URLs de almacenamiento en el marcado o respuestas de red
- Activar errores verbosos que revelen rutas internas
- Mantener acceso después de que se revoque su permiso
Incluya tanto pruebas automatizadas de autorización como pruebas manuales en el navegador.
10. Establecer expectativas claras para el usuario
Explique qué hace la política:
- Limita los flujos de descarga o exportación proporcionados por la aplicación.
- Restringe el acceso a usuarios autorizados.
- Puede registrar eventos de visualización.
- Mantiene el archivo original detrás de controles del servidor.
También explique lo que no puede garantizar:
- No puede impedir la fotografía o capturas de pantalla en todos los entornos.
- No puede revocar la información ya vista y recordada.
- No reemplaza controles contractuales, organizacionales o de seguridad en los puntos finales.
Esta distinción hace que el producto sea más confiable y ayuda a las partes interesadas a elegir controles apropiados para material altamente sensible.
Lista de verificación de verificación
- Visualización y descarga usan permisos de servidor separados.
- Cada solicitud de documento realiza autorización a nivel de recurso.
- El archivo original no tiene URL pública permanente.
- La configuración del visor proviene de la documentación para la versión instalada de Doconut.
- Las acciones ocultas tienen puntos finales de servidor protegidos.
- Los datos temporales tienen un proceso de limpieza definido.
- Los registros de auditoría evitan contenido del documento y secretos.
- Las solicitudes directas no autorizadas están cubiertas por pruebas.
- Las respuestas de error no exponen detalles internos de almacenamiento.
- La copia del producto no afirma prevención absoluta de copias.
Dónde encaja Doconut
Doconut proporciona la capa de visualización incrustada dentro de la aplicación .NET. Su aplicación sigue siendo responsable de la identidad, autorización, permisos, almacenamiento, retención, auditoría y la veracidad de la promesa “solo de lectura”.
Evalúe el SDK del visor de documentos .NET de Doconut con sus requisitos de seguridad y documentos representativos. Use los recursos oficiales para configuraciones compatibles en lugar de depender de código fuente adivinado.
Conclusión
Un flujo de trabajo de documentos solo de lectura es un diseño de defensa en profundidad, no una bandera booleana. Proteja el archivo original, autorice cada solicitud, separe los permisos de visualización y descarga, valide las configuraciones del visor soportadas, audite el acceso y pruebe intentos directos de eludir la interfaz.
Con esos controles en su lugar, Doconut puede ofrecer la experiencia de documento incrustado mientras su aplicación ASP.NET hace cumplir la política de seguridad alrededor de ella.