Criando um Bot para o Diretor: Extensão 1C + Criptografia + VPS
Um desenvolvedor 1C compartilha sua experiência na criação de um bot Telegram para diretores, detalhando a arquitetura, segurança e desafios enfrentados. O projeto visa fornecer acesso rápido a métricas chave da empresa, com foco em segurança e facilidade de uso.
MundiX News·13 de abril de 2026·7 min de leitura·👁 4 views
Eu sou um desenvolvedor 1C com 10 anos de experiência.
Uma manhã, senti vontade de desenvolver algo meu – algo não complicado, mas necessário, e decidi recorrer ao meu amigo artificial Qwen3.5:
Olá, meu amigo.
Sugira um projeto lucrativo e interessante que possa ser vendido (monetizado) facilmente. O que os usuários do 1C perguntam principalmente nos fóruns? Dê as 10 principais ideias para desenvolver um aplicativo interessante no 1C.
Depois de pensar um pouco, meu amigo me deu uma resposta bastante detalhada. A primeira ideia no Top-10 foi justamente essa: um bot do Telegram "Diretor no Bolso".
A IA descreveu assim:
1. Bot do Telegram "Diretor no Bolso"
Essência: Um bot que envia indicadores-chave (saldos de dinheiro, lucro por dia, dívidas de clientes, plano de vendas) sob demanda.
Por que comprariam: Os gerentes não querem mexer no 1C. Eles precisam de um número no telefone em 5 segundos.
Monetização: Assinatura (SaaS) de 500–1000 rublos/mês ou compra única de licença.
Dificuldade: Baixa (serviços HTTP + API do Telegram).
Isso é tudo! Eu estava empolgado.
Eu posso fazer tudo isso!!! Especialmente se eu escrever 90% do código com a ajuda do Cursor.
Neste artigo, contarei quais dificuldades tive que enfrentar, compartilharei a arquitetura da solução, o código da extensão-agente e como a segurança dos dados é garantida.
Problema e tarefa a ser resolvida
Na maioria dos sistemas "1C:Enterprise", o acesso aos dados fora do escritório é uma dor de cabeça.
Web client - pesado, requer boa internet e licenças.
RDP/Thin Client - inconveniente no telefone.
Relatórios por e-mail - não dão a sensação de "aqui e agora".
Tarefa: dar ao diretor a capacidade de receber métricas relevantes com comandos simples no Telegram ( /balance, /sales, /debts), com o mínimo de esforço de configuração e com uma garantia de segurança dos dados transmitidos.
Arquitetura do sistema
Decidi não construir um "monólito sobre um monólito" e dividi o sistema em três componentes independentes. Isso permitiu desvincular os bancos de dados dos clientes e a lógica do servidor.
O esquema de interação consiste em três elos: Agente (no banco de dados do cliente) → Servidor (VPS) → Bot do Telegram.
Extensão-agente (Client-side)
Esta é a única coisa que é instalada no banco de dados do cliente.
Função: Gateway. Não contém lógica de negócios, apenas envia métricas para o servidor via HTTPS.
Configuração: Mínimo de metadados. Inseriu a chave → clicou em "Conectar".
Segurança: O agente não se autentica no servidor com uma senha, ele envia um pacote criptografado com métricas e um token. Se o servidor for hackeado, o invasor receberá apenas números agregados, não transações.
Por que o código do agente é aberto? Eu abri o código-fonte da extensão por princípio. Qualquer especialista qualificado pode conectá-lo à sua configuração, ver exatamente quais dados estão sendo enviados e garantir que nada extra esteja acontecendo "sob o capô". A confiança é construída sobre a transparência no lado do cliente.
Por que não usar o BCP (Biblioteca de Componentes Padrão)? Para um gateway de API leve, peguei uma configuração vazia + 3 módulos. Funciona mais rápido, é mais fácil de atualizar.
Servidor - "cérebro" (Server-side)
Aqui vivem 1C, Apache e Windows VPS.
Funções: Recebe dados de agentes, verifica a assinatura, forma respostas para o bot.
Lógica: Verificações de segurança, validação de assinatura, roteamento de solicitações são implementados aqui.
Arquitetura: O padrão "Adaptador" é usado. Atualmente, o Telegram está funcionando, mas a arquitetura permite adicionar facilmente VK, MAX ou qualquer outro mensageiro sem reescrever o núcleo.
Bot do Telegram
Interface simples para o usuário.
Processamento de comandos via webhooks.
Cache de respostas para velocidade de resposta (< 1 segundo).
Integração com o sistema de pagamento (para gerenciamento de assinatura).
Proteção de dados
A questão da segurança foi fundamental. Os clientes não querem que suas transações detalhadas vazem para a internet. Como isso é resolvido:
Contra hacking da extensão
Toda a lógica de verificação de assinatura é movida para o servidor. O código da extensão (.cfu) no cliente é "burro" - ele simplesmente envia o que foi solicitado. Mesmo que você reescreva a extensão, não será possível enganar o servidor e obter uma resposta sem pagamento.
Contra vazamento de dados
Protocolo: Todas as solicitações passam por HTTPS com validação de certificado.
Armazenamento: Apenas métricas agregadas (saldos, volumes) são armazenadas no servidor. Transações detalhadas e dados pessoais nunca chegam ao servidor.
Contextos: Os dados de diferentes clientes são isolados no nível do banco de dados do servidor 1C.
Criptografia (RSA)
A criptografia assimétrica é usada. O agente e o servidor trocam chaves públicas. Se um invasor tentar organizar um ataque "Man-in-the-Middle" (ficar no meio e fingir ser um servidor), o agente não executará seu código, pois a assinatura não passará na verificação.
Vinculação de dois fatores
A autorização no bot requer dois fatores:
Chave de licença
Telegram ChatID
Mesmo que alguém roube a chave, sem acesso ao telefone (Telegram), ele não receberá os dados.
Como funciona: cenário de conexão
Eu queria tornar o processo o mais simples possível ("Plug and Play").
Passo 1: O usuário entra no bot, aceita a oferta e recebe uma chave única.
Passo 2: Baixa a extensão .cfu e a adiciona ao seu banco de dados (UT, UNF ou BP).
Passo 3: Insere a chave nas configurações da extensão e clica em "Salvar".
É isso. Em seguida, a extensão começa a enviar dados por conta própria de acordo com a programação ou sob demanda do bot.
Requisitos para a extensão
Plataforma: 1C:Enterprise 8.3.20+
Configurações: UT 11.5, UNF 3.0, BP 3.0 (e superior).
Rede: Capacidade de solicitações HTTPS de saída.
Recursos de implementação e modelo de negócios
O projeto opera sob um modelo SaaS. O lado do servidor é fechado, pois é um serviço comercial que requer suporte e tempo de atividade. No entanto, como mencionei acima, o código da extensão é totalmente aberto.
Isso permite que a solução seja usada como:
Um produto pronto para uso para pequenas empresas (existe um plano gratuito para startups).
Uma arquitetura de referência para desenvolvedores que desejam construir seu próprio bot, mas não querem "reinventar a roda" com segurança e troca de dados.
Roteiro
O que já está funcionando e o que está planejado:
[Concluído] Multiusuário: uma conta para o diretor, diretor financeiro e chefe de departamento de vendas.
[Concluído] Suporte para vários bancos de dados em uma conta.
[Planejado] Anonimização automática de dados
[Planejado] Bot para VK Messenger.
[Planejado] Classificador de solicitações de IA (seguro, somente leitura).
[Planejado] Geração de gráficos e relatórios em PDF diretamente no chat.
[Planejado] Anonimização automática de dados
Para onde ir em seguida?
Dependerá das solicitações dos usuários ativos. Escreva para mim, o que é mais importante para você?
Adicionar variedade de comandos 1C
Escrever um bot para outros mensageiros
O que você espera da implementação da IA?
Links úteis
Bot: @DirectorInPocketBot
Vídeo de instruções: Rutube
Código-fonte do agente: GitHub
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Eu sou um desenvolvedor 1C com 10 anos de experiência.
Uma manhã, senti vontade de desenvolver algo meu – algo não complicado, mas necessário, e decidi recorrer ao meu amigo artificial Qwen3.5:
Olá, meu amigo.
Sugira um projeto lucrativo e interessante que possa ser vendido (monetizado) facilmente. O que os usuários do 1C perguntam principalmente nos fóruns? Dê as 10 principais ideias para desenvolver um aplicativo interessante no 1C.
Depois de pensar um pouco, meu amigo me deu uma resposta bastante detalhada. A primeira ideia no Top-10 foi justamente essa: um bot do Telegram "Diretor no Bolso".
A IA descreveu assim:
1. Bot do Telegram "Diretor no Bolso"
Essência: Um bot que envia indicadores-chave (saldos de dinheiro, lucro por dia, dívidas de clientes, plano de vendas) sob demanda.
Por que comprariam: Os gerentes não querem mexer no 1C. Eles precisam de um número no telefone em 5 segundos.
Monetização: Assinatura (SaaS) de 500–1000 rublos/mês ou compra única de licença.
Dificuldade: Baixa (serviços HTTP + API do Telegram).
Isso é tudo! Eu estava empolgado.
Eu posso fazer tudo isso!!! Especialmente se eu escrever 90% do código com a ajuda do Cursor.
Neste artigo, contarei quais dificuldades tive que enfrentar, compartilharei a arquitetura da solução, o código da extensão-agente e como a segurança dos dados é garantida.
Problema e tarefa a ser resolvida
Na maioria dos sistemas "1C:Enterprise", o acesso aos dados fora do escritório é uma dor de cabeça.
Web client - pesado, requer boa internet e licenças.
RDP/Thin Client - inconveniente no telefone.
Relatórios por e-mail - não dão a sensação de "aqui e agora".
Tarefa: dar ao diretor a capacidade de receber métricas relevantes com comandos simples no Telegram ( /balance, /sales, /debts), com o mínimo de esforço de configuração e com uma garantia de segurança dos dados transmitidos.
Arquitetura do sistema
Decidi não construir um "monólito sobre um monólito" e dividi o sistema em três componentes independentes. Isso permitiu desvincular os bancos de dados dos clientes e a lógica do servidor.
O esquema de interação consiste em três elos: Agente (no banco de dados do cliente) → Servidor (VPS) → Bot do Telegram.
Extensão-agente (Client-side)
Esta é a única coisa que é instalada no banco de dados do cliente.
Função: Gateway. Não contém lógica de negócios, apenas envia métricas para o servidor via HTTPS.
Configuração: Mínimo de metadados. Inseriu a chave → clicou em "Conectar".
Segurança: O agente não se autentica no servidor com uma senha, ele envia um pacote criptografado com métricas e um token. Se o servidor for hackeado, o invasor receberá apenas números agregados, não transações.
Por que o código do agente é aberto? Eu abri o código-fonte da extensão por princípio. Qualquer especialista qualificado pode conectá-lo à sua configuração, ver exatamente quais dados estão sendo enviados e garantir que nada extra esteja acontecendo "sob o capô". A confiança é construída sobre a transparência no lado do cliente.
Por que não usar o BCP (Biblioteca de Componentes Padrão)? Para um gateway de API leve, peguei uma configuração vazia + 3 módulos. Funciona mais rápido, é mais fácil de atualizar.
Servidor - "cérebro" (Server-side)
Aqui vivem 1C, Apache e Windows VPS.
Funções: Recebe dados de agentes, verifica a assinatura, forma respostas para o bot.
Lógica: Verificações de segurança, validação de assinatura, roteamento de solicitações são implementados aqui.
Arquitetura: O padrão "Adaptador" é usado. Atualmente, o Telegram está funcionando, mas a arquitetura permite adicionar facilmente VK, MAX ou qualquer outro mensageiro sem reescrever o núcleo.
Bot do Telegram
Interface simples para o usuário.
Processamento de comandos via webhooks.
Cache de respostas para velocidade de resposta (< 1 segundo).
Integração com o sistema de pagamento (para gerenciamento de assinatura).
Proteção de dados
A questão da segurança foi fundamental. Os clientes não querem que suas transações detalhadas vazem para a internet. Como isso é resolvido:
Contra hacking da extensão
Toda a lógica de verificação de assinatura é movida para o servidor. O código da extensão (.cfu) no cliente é "burro" - ele simplesmente envia o que foi solicitado. Mesmo que você reescreva a extensão, não será possível enganar o servidor e obter uma resposta sem pagamento.
Contra vazamento de dados
Protocolo: Todas as solicitações passam por HTTPS com validação de certificado.
Armazenamento: Apenas métricas agregadas (saldos, volumes) são armazenadas no servidor. Transações detalhadas e dados pessoais nunca chegam ao servidor.
Contextos: Os dados de diferentes clientes são isolados no nível do banco de dados do servidor 1C.
Criptografia (RSA)
A criptografia assimétrica é usada. O agente e o servidor trocam chaves públicas. Se um invasor tentar organizar um ataque "Man-in-the-Middle" (ficar no meio e fingir ser um servidor), o agente não executará seu código, pois a assinatura não passará na verificação.
Vinculação de dois fatores
A autorização no bot requer dois fatores:
Chave de licença
Telegram ChatID
Mesmo que alguém roube a chave, sem acesso ao telefone (Telegram), ele não receberá os dados.
Como funciona: cenário de conexão
Eu queria tornar o processo o mais simples possível ("Plug and Play").
Passo 1: O usuário entra no bot, aceita a oferta e recebe uma chave única.
Passo 2: Baixa a extensão .cfu e a adiciona ao seu banco de dados (UT, UNF ou BP).
Passo 3: Insere a chave nas configurações da extensão e clica em "Salvar".
É isso. Em seguida, a extensão começa a enviar dados por conta própria de acordo com a programação ou sob demanda do bot.
Requisitos para a extensão
Plataforma: 1C:Enterprise 8.3.20+
Configurações: UT 11.5, UNF 3.0, BP 3.0 (e superior).
Rede: Capacidade de solicitações HTTPS de saída.
Recursos de implementação e modelo de negócios
O projeto opera sob um modelo SaaS. O lado do servidor é fechado, pois é um serviço comercial que requer suporte e tempo de atividade. No entanto, como mencionei acima, o código da extensão é totalmente aberto.
Isso permite que a solução seja usada como:
Um produto pronto para uso para pequenas empresas (existe um plano gratuito para startups).
Uma arquitetura de referência para desenvolvedores que desejam construir seu próprio bot, mas não querem "reinventar a roda" com segurança e troca de dados.
Roteiro
O que já está funcionando e o que está planejado:
[Concluído] Multiusuário: uma conta para o diretor, diretor financeiro e chefe de departamento de vendas.
[Concluído] Suporte para vários bancos de dados em uma conta.
[Planejado] Anonimização automática de dados
[Planejado] Bot para VK Messenger.
[Planejado] Classificador de solicitações de IA (seguro, somente leitura).
[Planejado] Geração de gráficos e relatórios em PDF diretamente no chat.
[Planejado] Anonimização automática de dados
Para onde ir em seguida?
Dependerá das solicitações dos usuários ativos. Escreva para mim, o que é mais importante para você?
Adicionar variedade de comandos 1C
Escrever um bot para outros mensageiros
O que você espera da implementação da IA?
Links úteis
Bot: @DirectorInPocketBot
Vídeo de instruções: Rutube
Código-fonte do agente: GitHub
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
