Arquitetura de segurança

O modelo de segurança do Exportelier se baseia em uma divisão deliberada em dois apps, para que o app que lida com os dados das suas issues não tenha como enviá-los para lugar algum.

App principal: sem fetch, sem webtriggers

O app principal não declara nenhuma chamada externa nem webtriggers no seu manifesto do Forge. Os PDFs são renderizados inteiramente no Forge, sem navegador headless e sem servidores de terceiros. Isso é imposto pela plataforma da Atlassian — é uma garantia de arquitetura, não uma promessa de política.

Um diagrama: o app principal (sem egress, renderiza no Forge) ao lado do app Automation (todo o egress, isolado).

App Automation: egress isolado

Tudo o que precisa enviar dados para fora — e-mail, webhooks de entrada do Slack, Microsoft Teams Workflows e API — vive no app separado Exportelier Automation. Ele transporta todo o tráfego de saída, com proteção SSRF e URLs secretas específicas do provedor.

Relatórios leem o Jira como a pessoa que exporta

Toda leitura do Jira feita por um relatório — listar filtros salvos, conferi-los na verificação prévia e buscá-los durante a exportação — é executada como a pessoa que a iniciou, usando a identidade asUser do Forge. O aplicativo nunca recorre à própria identidade de aplicativo para fazer uma exportação enfileirada dar certo.

Daí decorrem diretamente duas propriedades:

• Ser administrador do site no Exportelier nunca amplia a visibilidade no Jira. Um administrador pode construir um relatório a partir de filtros que ele vê; isso não concede acesso a mais ninguém. Se uma fonte não estiver disponível para quem exporta, a exportação falha e a nomeia, em vez de omitir em silêncio uma fonte de dados.
• Nenhuma consulta é armazenada ou montada a partir do seu texto. O Exportelier mantém o ID numérico de um filtro salvo e monta exatamente um predicado estritamente numérico, filter = <id>. O JQL do filtro nunca é lido, armazenado, registrado nem concatenado, então não há superfície de injeção de JQL nem cópia desatualizada da sua consulta.

A saída dos relatórios é temporária e excluída após o download — veja Retenção de dados e GDPR.

A importação de painéis usa apenas APIs documentadas

A importação de painéis lê o Jira exclusivamente pela API REST de painéis do Jira Cloud documentada pela Atlassian, como a pessoa que importa. Ela não analisa páginas web do Jira, não lê iframes de gadgets, não captura telas, não usa endpoints não documentados de preferências de gadgets e não envia nada para fora do Forge. Não foi necessário nenhum escopo de permissão novo.

O que é lido é deliberadamente restrito. Os valores de configuração dos gadgets são validados contra uma lista de permissões por gadget, limitados em tamanho bem abaixo do máximo do próprio Jira e nunca registrados em log, repetidos em erros ou gravados em eventos de auditoria. O JQL nunca é armazenado, mesmo quando uma propriedade de gadget o contém — um relatório importado mantém o mesmo id numérico de filtro que qualquer outro.

Uma das operações envolvidas, Get gadgets, é marcada como Experimental pela Atlassian. Se a resposta dela deixar de corresponder ao que o Exportelier verificou contra um site Jira real, o caminho de importação falha de forma controlada e o recurso se desativa, em vez de agir sobre uma resposta lida errado. Relatórios e exportações existentes não são afetados.

Os eventos de auditoria registram que um registro de importação foi verificado ou excluído. Eles não contêm configuração de gadget, JQL ou dados de itens.

Por que separá-los

Se sua política proíbe tráfego de saída, você instala apenas o app principal e tem uma garantia firme de que nada sai do Atlassian. Equipes que precisam de entrega adicionam o app Automation conscientemente.

Consulte também Residência de dados e a página Compras e segurança de fornecedores.