Introdução

A conversão pública de arquivos é conveniente, mas não está isenta de questões de segurança. Dados podem vazar, a retenção pode ser incerta, obrigações de conformidade podem se expandir e arquivos maliciosos podem visar analisadores complexos. Para equipes .NET, essas preocupações devem ser abordadas antes que um conversor externo se torne parte de um fluxo de trabalho empresarial.

Doconut oferece um visualizador .NET auto-hospedado e um fluxo de trabalho de conversão que pode manter o processamento de documentos suportados dentro da infraestrutura controlada pelo proprietário da aplicação. Isso pode reduzir a dependência de um conversor público, mas a aplicação ainda deve implementar controle de acesso, transporte seguro, política de armazenamento, limpeza, correções e monitoramento.

Pontos de verificação de segurança entre um documento confidencial, um conversor público e um ambiente Windows controlado

Conversão Segura de Arquivos e Criptografia para Aplicativos .NET

Por que a criptografia é importante

Quando você envia um arquivo para um conversor na nuvem, ele precisa viajar pela internet pública. Se o transporte não estiver protegido, um hacker pode se posicionar no meio e interceptar os dados — o clássico ataque “man‑in‑the‑middle”. Mesmo com HTTPS, muitas ferramentas gratuitas ainda armazenam o arquivo em um servidor compartilhado sem criptografia adicional, deixando-o exposto a ameaças internas ou a buckets de armazenamento mal configurados.

O que os dois produtos Doconut realmente fazem

Eles respondem a isso de maneira diferente, e confundi‑los é como as pessoas acabam com um design de segurança que não se sustenta.

O Doconut SDK é instalado no seu próprio ambiente. A renderização ocorre no seu servidor, e o componente não faz chamadas para Doconut. Esse é todo o argumento de segurança, e é forte: o arquivo nunca cruza uma fronteira que você não controla, portanto não há questão de retenção de terceiros a responder.

O que o SDK não faz é criptografar seu armazenamento para você. Não há recurso AES‑256‑at‑rest, nem gerenciamento de chaves e nem log de auditoria embutido. Esses são da sua plataforma, e você quase certamente já os possui — que é o ponto. Qualquer pessoa que afirme que uma biblioteca de visualizador deixa sua aplicação pronta para auditoria está lhe vendendo algo.

Doconut.app é nosso site hospedado gratuitamente, e funciona como um upload genuíno: o arquivo chega aos nossos servidores, é renderizado lá e é excluído quando a sessão de visualização termina. O transporte é HTTPS. Não há conta e nada é mantido depois. Para um documento que você não se importaria de ler em um trem, isso é aceitável; para dados regulados não é, e preferimos ser claros a esse respeito.

Exclusão automática de arquivos e gerenciamento de ciclo de vida

O perigo oculto dos arquivos persistentes

Muitos conversores na nuvem prometem “exclusão automática após a conversão”, mas a definição de “após” varia bastante. Alguns serviços mantêm arquivos por horas, dias ou até semanas, criando uma janela onde documentos confidenciais podem ser acessados por pessoal não autorizado ou recuperados por análise forense. Para empresas que lidam com contratos, projetos de design ou dados pessoais, essa janela é inaceitável.

Resposta definitiva da Doconut App

No Doconut.app – O arquivo existe apenas durante a sessão de visualização e é excluído ao final. Não há configuração de retenção para você, porque não há contas nem administradores; o tempo é definido por nós. A impressão está disponível para quem estiver visualizando, via Ctrl+P.
No SDK – O ciclo de vida é seu. O componente grava a saída de renderização temporária em algum lugar que você configurar, e você é responsável por limpá‑la. Esta é a etapa mais frequentemente ignorada em uma integração, e arquivos de renderização órfãos em um diretório temporário são exatamente o problema de “arquivo fantasma” que esta seção alerta. Verifique onde ele grava e agende a limpeza.
Impressão controlada faz parte do visualizador, não de um plugin separado, portanto restringir impressão e download para papéis específicos é uma questão de configuração e permissões dentro da sua aplicação.

Visualização baseada em nuvem pronta para conformidade para indústrias reguladas

Pressões regulatórias

Cuidados de saúde (HIPAA), finanças (PCI DSS) e governo (FedRAMP) impõem regras rígidas sobre como os dados são transmitidos, armazenados e destruídos. Um conversor em nuvem que armazena arquivos em um servidor multi‑tenant compartilhado pode rapidamente se tornar um pesadelo de conformidade, exigindo processos de exceção custosos ou o abandono total da ferramenta.

Onde a Doconut está, declaradamente

Não possuímos certificações. Nenhum ISO 27001, nenhum SOC 2, nenhuma atestação HIPAA, nenhuma avaliação PCI DSS, nenhuma autorização FedRAMP. Nem os sites gratuitos nem o SDK. Se um questionário de fornecedor solicitar um certificado, a resposta honesta é que não temos nenhum para lhe fornecer.

Nenhum componente de software pode tornar sua aplicação compatível em qualquer caso. Esses frameworks questionam processos, controle de acesso, retenção, evidências e pessoas. Uma biblioteca de renderização é um controle entre dezenas.

O que o SDK oferece a um ambiente regulado é arquitetônico, não documental: como ele roda dentro da sua infraestrutura e não chama nada externo, o documento nunca sai da fronteira que você já avaliou. Para a maioria das revisões, essa é a resposta mais útil do que um certificado pertencente a outra pessoa, e é a que você pode comprovar por conta própria.

Doconut.app é o caso oposto e deve ser tratado como tal: um site público, infraestrutura compartilhada, sem contrato, sem DPA e sem BAA. Não coloque dados regulados nele.

Prevenindo malware e injeção de código na conversão de documentos online

A ameaça oculta de cargas maliciosas

Formatos de arquivo como PDF, Office e CAD podem incorporar scripts, macros ou dados malformados que acionam exploits em motores de renderização vulneráveis. Um serviço em nuvem que processa arquivos em um servidor compartilhado pode, inadvertidamente, executar código malicioso, comprometendo o serviço e quaisquer clientes subsequentes.

Como o modelo de renderização afeta isso

Seja preciso sobre onde a análise ocorre, pois o modelo de ameaça depende totalmente disso: Doconut renderiza no lado do servidor. O documento é analisado no servidor e o navegador recebe páginas renderizadas. Não é um visualizador WebAssembly no cliente.

O que decorre disso:

O navegador não é a superfície de ataque – sem plugin, sem ActiveX, e a máquina do usuário nunca recebe o arquivo original, apenas a saída renderizada.
O servidor é a superfície, e é o seu servidor quando você executa o SDK. Um analisador que processa entrada não confiável é um analisador que processa entrada não confiável; execute-o com o menor privilégio, mantenha-o atualizado e trate os bytes enviados como hostis. A vantagem sobre um conversor público é que esta é sua isolação para projetar e verificar, não uma afirmação que você deve aceitar por confiança.
Renderização não é execução – macros em um .docm ou .xlsm não são executadas, e scripts em um PDF não são executados. O visualizador desenha o documento.
A lista de extensões é uma lista branca – os visualizadores gratuitos aceitam mais de 70 extensões e recusam todo o resto no upload.

Nada disso substitui a varredura de uploads se sua avaliação de risco exigir. Adicione essa camada você mesmo; o visualizador não inclui a varredura de malware.

Um visualizador que se adapta aos estilos estabelecidos de aplicações .NET

O desafio da integração

Empresas frequentemente executam uma mistura de ASP.NET Core, MVC, WebForms e aplicações Blazor mais recentes. Adicionar um visualizador de terceiros geralmente significa lidar com bibliotecas JavaScript, lidar com compatibilidade de plugins e combater peculiaridades de navegadores. Cada dependência extra introduz uma nova superfície de ataque e uma carga de manutenção.

O que o SDK faz a respeito

Zero‑plugin, puro HTML5 – Funciona em todos os navegadores modernos (Chrome, Edge, Firefox, Safari) sem instalar nada na máquina do cliente.
Integração Blazor – Coordene o estado do visualizador a partir de um componente enquanto mantém o acesso a arquivos e o processamento no servidor. Siga a documentação da versão do SDK instalada.
UI personalizável – A barra de ferramentas, cores e identidade visual do visualizador podem ser ajustadas para combinar com sua aplicação, de modo que pareça parte do seu produto e não uma janela para o de outra pessoa. Use os nomes das opções da documentação da versão que você instalou.

Incorporando o visualizador

Adicione o pacote Doconut suportado, imponha a autorização de documentos na aplicação ASP.NET e inicialize o visualizador usando a documentação oficial daquela versão. Não presuma que transporte, criptografia, exclusão ou permissões de UI são automáticas; verifique e configure cada controle na arquitetura implantada.

Integração do Blazor e avaliação

Doconut pode participar dos fluxos de trabalho de aplicações Blazor, mas o modelo de componentes exato e a configuração dependem da versão do SDK instalada. Autenticação, transporte seguro, proteção de armazenamento, limpeza e isolamento de processos devem ser verificados na arquitetura completa implantada, em vez de presumir que estejam habilitados automaticamente.

Para avaliação, a página de download contém a licença de avaliação e a documentação; os termos e o que cada edição inclui estão na página de preços em vez de resumidos aqui, onde poderiam ficar desatualizados.

Se tudo o que você quer primeiro é ver como um arquivo particularmente complicado é renderizado, o Doconut.app executa o mesmo motor em um arquivo de cada vez, gratuitamente — e o exclui depois.

Principais pontos

A propriedade de segurança do SDK é arquitetural – ele roda no seu ambiente e não chama nada externo, portanto o documento nunca sai do seu perímetro. Ele não inclui criptografia em repouso, gerenciamento de chaves ou registro de auditoria; esses permanecem sob sua responsabilidade.
Doconut.app é um upload real – HTTPS de entrada, renderizado em nossos servidores, excluído ao final da sessão, sem conta. Adequado para um arquivo comum, inadequado para dados regulados.
Conformidade não está incorporada – não possuímos credenciais ISO 27001, SOC 2, HIPAA, PCI DSS ou FedRAMP, e nenhum componente pode conceder uma delas.
Renderização é no lado do servidor, não WebAssembly – o navegador recebe páginas, nunca o arquivo fonte. Renderizar não é executar, portanto macros não são executadas.
Limpe seu diretório temporário – em uma implantação auto-hospedada, a saída de renderização órfã representa o risco real de arquivos fantasmas.
Experiência sem plugins no navegador – integra-se aos fluxos de trabalho ASP.NET Core, MVC, WebForms e Blazor.
Avalie no seu próprio ambiente – a qualidade da renderização pode ser verificada gratuitamente no Doconut.app; todo o resto requer a avaliação na sua própria infraestrutura.

Perguntas comuns

P: O Doconut.app mantém uma cópia do meu documento após a visualização?
R: Não. Ele é renderizado em uma sessão temporária vinculada ao seu navegador e excluído dos nossos servidores quando a sessão termina. Não há conta à qual possa ser associado nem biblioteca em que possa reaparecer. Em uma implantação auto‑hospedada do SDK, a pergunta equivalente refere‑se ao seu próprio diretório temporário, e a resposta depende da limpeza que você configurar.

P: Posso habilitar download ou impressão para usuários específicos?
R: No SDK, sim — os controles do visualizador são configuráveis e a impressão controlada faz parte do visualizador, não de um plugin extra, de modo que você pode conceder esses direitos por função a partir da sua própria aplicação. No site gratuito do Doconut.app não há papéis nem API: qualquer pessoa que visualize pode imprimir com Ctrl+P.

P: Como ele lida com arquivos CAD grandes ou imagens de alta resolução?
R: O motor renderiza DWG, DXF, DGN, PSD, TIFF e DNG a partir da geometria e dos dados de pixel, em vez de usar uma pré‑visualização embutida, aplica perfis ICC incorporados e permite desligar camadas CAD e medir distâncias e áreas. No site gratuito os limites são: 10 MB para CAD, que desenhos emitidos podem exceder, e 25 MB para PSD, TIFF e imagens. Em implantação auto‑hospedada, o limite depende da memória do seu servidor.

P: O visualizador é compatível com navegadores móveis?
R: Sim. Como a renderização ocorre no servidor e o navegador recebe HTML e imagens comuns, funciona no Safari iOS, Chrome Android e em qualquer navegador móvel moderno — e um dispositivo fraco não é desvantagem, já que ele não realiza o trabalho de renderização.

P: Quanto custa?
R: O Doconut.app é gratuito, sem nível pago, sem conta e sem período de avaliação a expirar — esse é todo o modelo. O SDK é uma licença comercial com avaliação gratuita; as edições atuais e os preços estão na página de preços, que é a autoridade em vez deste artigo.

Considerações finais

Ao incorporar um conversor de arquivos baseado em nuvem em uma aplicação empresarial .NET, exposição de dados, ciclos de vida incertos dos arquivos, lacunas de conformidade e cargas maliciosas são riscos reais. Um fluxo de trabalho Doconut auto‑hospedado pode dar às equipes .NET baseadas em Windows mais controle sobre o processamento e o armazenamento, enquanto a aplicação circundante permanece responsável pelo design completo de segurança.

Decidindo entre eles? Se os documentos são comuns, o Doconut.app abrirá um agora mesmo sem custo. Se não forem, o argumento a favor do SDK é que o arquivo permanece nos seus servidores — e o trabalho de provar isso a um auditor continua sendo seu, que é a única versão que sobrevive a uma revisão de segurança real.