Proteção de aplicação Spring Boot

springboot é usado para proteger aplicações Spring Boot, sendo capaz de lidar com BOOT-INF/classes, BOOT-INF/lib, Spring Boot Loader e varredura de frameworks.

1. Operação via GUI

1. Selecione Spring Boot na página de tipo de aplicação.

   

2. Escolha a aplicação Spring Boot que deseja proteger, Versão Java incluída no pacote e a plataforma de destino, e selecione o modo simples ou o modo avançado.

   

3. No modo avançado, selecione conforme necessário o layout de saída, os JARs de dependência a serem protegidos, JavaFX, parâmetros da JVM e regras de exclusão; o modo simples sugere automaticamente o layout e os itens a serem excluídos com base na varredura de compatibilidade. As definições de cada opção estão descritas em Configurações do modo avançado do Protector4J.

   

4. Escolha o diretório de saída, revise o resumo dos parâmetros e, em seguida, clique em Run protection.

   

2. Exemplo de CLI

Comando mínimo:

p4j springboot app.jar dist

O layout p4jx-fat é usado por padrão. Selecione explicitamente outro layout:

p4j springboot app.jar dist --layout fat
p4j springboot app.jar dist --layout separate

Proteção seletiva:

p4j springboot app.jar dist \
  --protect 'com.example.service.impl.**' \
  --exclude 'com.example.dto.**,com.example.config.**'

3. Estrutura e layout de saída

p4jx-fat: por padrão, um único arquivo de aplicação protegida

dist/
├── app.p4jx              # Quando se utiliza o sufixo jar, torna-se app.jar
├── vlxjre/
├── run.sh
├── run.command
└── run.bat

Características:

• Entregue em um único arquivo de aplicação P4JX;
• Os arquivos físicos não são, por padrão, em formato ZIP;
• Os recursos do Spring Boot, dependências aninhadas e metadados são fornecidos por meio de uma visão de JAR virtual;
• Oferece o maior nível de proteção, sendo adequado para aplicações que não dependem de scanners de classpath de terceiros.

fat: Layout compatível com Spring Boot

dist/
├── app.jar
├── app.p4jx              # Quando se utiliza o sufixo jar, torna-se app-protected.jar
├── vlxjre/
└── run.*

Características:

• app.jar mantém a estrutura física padrão do BOOT-INF;
• A implementação real das classes protegidas está localizada no arquivo P4JX adjacente;
• Adequado para aplicações que precisam escanear a estrutura física do JAR do Spring Boot, como ClassGraph e Reflections;
• Existem uma relação de vinculação entre os dois arquivos, que devem ser atualizados e entregues juntos.

separate: Layout de compatibilidade separado

dist/
├── plain-launcher.jar
├── app.p4jx
├── lib/
├── vlxjre/
└── run.*

Características:

• Separação entre Spring Boot Loader, classes públicas e dependências;
• Adequado para ambientes de integração antigos que exigem um classpath plano lib/*;
• As classes de proteção são pré-carregadas pelo loader gerado;
• Projetos novos devem usar preferencialmente p4jx-fat ou fat recomendado pelo scanner.

Como escolher o layout

O ZIP overlay apenas auxilia ferramentas que leem diretamente o diretório central do ZIP e não pode substituir a estrutura física do Spring Boot necessária para os scanners ClassLoader/classpath.

4. Iniciar

./run.sh --spring.profiles.active=prod

Windows:

run.bat --spring.profiles.active=prod

Não substitua o vlxjre no diretório de saída pelo JRE do sistema.

Parâmetros de inicialização do JVM

Durante a compilação, os parâmetros do JVM podem ser definidos por meio do JVM startup options na GUI (um por linha) ou via CLI:

p4j springboot app.jar dist \
  --jvm-option -Xms1g \
  --jvm-option -Xmx2g

Adicione temporariamente durante a implantação:

APP_JAVA_OPTS="-Duser.timezone=Asia/Shanghai" ./run.sh

Também é possível modificar diretamente o script de implantação atual:

• macOS/Linux: Adicione o JVM_OPTS+=("-Xms1g" "-Xmx2g") após os arquivos JVM_OPTS=(...)/JVM_OPTS+=(...) já gerados em run.sh.
• Windows: Adicione o set "JVM_OPTS=%JVM_OPTS% -Xms1g -Xmx2g" após os arquivos set "JVM_OPTS=..." já gerados em run.bat.

Não remova parâmetros internos gerados automaticamente pelo Spring Boot ou JavaFX, como o --add-opens e o module path. Uma nova compilação substituirá as alterações feitas manualmente; consulte o Configuração de parâmetros de inicialização do JVM para mais detalhes.

5. Escopo de proteção

Proteção padrão para classes de aplicação sob BOOT-INF/classes. Recomenda-se manter as seguintes classes voltadas para Spring como classes comuns:

• @Controller, @RestController, @ControllerAdvice;
• @Configuration, classes de configuração automática e classes aprimoradas por AOT/CGLIB;
• DTOs Jackson, entidades JPA, records e modelos de validação;
• Ponto de entrada da aplicação e classes construídas/proxied diretamente pelo framework;
• Classes que necessitam de aprimoramento de bytecode em tempo de execução.

Implementação de serviços protegidos, acessada por meio de uma interface ou facade pública. As regras suportam nomes de classe exatos, pkg.* e pkg.**.

6. JARs dependentes protegidos

O --protect-lib oferece proteção para as dependências correspondentes do BOOT-INF/lib, sendo compatível com os três layouts:

p4j springboot app.jar dist \
  --protect-lib 'company-core-*.jar,pricing-*.jar'

Fornece proteção apenas para dependências proprietárias e de código fechado. Não criptografe pacotes de frameworks de terceiros como Spring, Tomcat, gerenciadores de logs e drivers de banco de dados apenas para o “Proteção de mais recursos”.

7. Verificação de compatibilidade

p4j springboot app.jar --compat-scan
p4j springboot app.jar dist --compat-apply

Essas duas opções não podem ser usadas simultaneamente. A diferença entre elas é:

Para springboot e --compat-apply, é possível escolher a estrutura com base nos resultados da varredura, adicionar classes de exclusão e ajustar opções como ZIP overlay, JavaFX e sufixos de arquivamento. Para essas opções que não são classes de exclusão, os valores especificados explicitamente na linha de comando têm prioridade; as classes de exclusão sugeridas são, por padrão, mescladas com --exclude. Se não desejar que classes de exclusão sejam adicionadas automaticamente, é possível passar --no-compat-excludes simultaneamente. O scanner realiza apenas análise heurística estática; problemas que exigem alterações no código não serão corrigidos automaticamente por --compat-apply, e testes de regressão ainda são necessários na plataforma-alvo após a geração.

Para outras comandos CLI, todas as opções, variáveis de ambiente e exemplos de automação, consulte Referência de parâmetros CLI.