Proteger aplicativos Spring Boot

springboot protege aplicativos Spring Boot e cuida de BOOT-INF/classes, BOOT-INF/lib, do carregador do Spring Boot e da varredura do framework.

1. Pela interface gráfica

1. Na página do tipo de aplicativo, escolha Spring Boot.

   

2. Selecione o aplicativo Spring Boot a proteger, a versão do Java a incluir e as plataformas-alvo, e escolha entre modo simples ou avançado.

   

3. No modo avançado, escolha a disposição de saída, os JAR de dependências a proteger, os ajustes do JavaFX, as opções da JVM e as regras de exclusão. O modo simples deduz a disposição e as exclusões da verificação de compatibilidade. O significado de cada opção está em Configurações do modo avançado do Protector4J.

   

4. Escolha a pasta de saída, confira o resumo e clique em Executar proteção.

   

2. Exemplos de linha de comando

A forma mais curta:

p4j springboot app.jar dist

Por padrão usa-se a disposição p4jx-fat. Para escolher outra explicitamente:

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

Proteger apenas parte do aplicativo:

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

3. Estrutura da saída e disposições

p4jx-fat: a disposição padrão, um único arquivo protegido

dist/
├── app.p4jx              # vira app.jar com o sufixo jar
├── vlxjre/
├── run.sh
├── run.command
└── run.bat

Características:

• todo o aplicativo é entregue como um único arquivo P4JX;
• o arquivo físico não é um ZIP por padrão;
• os recursos do Spring Boot, as dependências aninhadas e os metadados são oferecidos por uma visão JAR virtual;
• o alcance da proteção é o mais amplo, adequado a aplicativos que não dependem de scanners de classpath de terceiros.

fat: disposição de compatibilidade com o Spring Boot

dist/
├── app.jar
├── app.p4jx              # vira app-protected.jar com o sufixo jar
├── vlxjre/
└── run.*

Características:

• app.jar preserva a estrutura física padrão de BOOT-INF;
• as implementações reais das classes protegidas ficam no arquivo P4JX ao lado;
• serve a aplicativos que precisam varrer a estrutura física do JAR do Spring Boot, por exemplo com ClassGraph ou Reflections;
• os dois arquivos dependem um do outro e precisam ser atualizados e entregues juntos.

separate: disposição de compatibilidade separada

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

Características:

• o carregador do Spring Boot, as classes sem proteção e as dependências ficam separados;
• serve a ambientes de integração antigos que exigem um classpath plano lib/*;
• o iniciador gerado pré-carrega as classes protegidas;
• em projetos novos, prefira p4jx-fat ou aquela que o scanner recomendar entre p4jx-fat e fat.

Como escolher a disposição

A camada ZIP só ajuda as ferramentas que leem diretamente o diretório central do ZIP. Ela não substitui a estrutura física do Spring Boot de que precisam o ClassLoader e os scanners de classpath.

4. Inicialização

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

No Windows:

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

Não substitua a pasta vlxjre da saída por um JRE do sistema.

Para alvos Windows também é possível gerar um iniciador nativo. Ele funciona com as três disposições e convive com os scripts de inicialização — veja Criar um iniciador EXE do Windows.

Opções de inicialização JVM

As opções podem ser fixadas no empacotamento, seja uma por linha em Opções de inicialização JVM na interface gráfica, seja na linha de comando:

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

Para acrescentar opções a um pacote já implantado, só naquela execução:

APP_JAVA_OPTS="-Duser.timezone=America/Sao_Paulo" ./run.sh

Também é possível editar diretamente o script implantado:

• macOS e Linux: em run.sh, acrescente JVM_OPTS+=("-Xms1g" "-Xmx2g") depois das linhas geradas JVM_OPTS=(...) e JVM_OPTS+=(...).
• Windows: em run.bat, acrescente set "JVM_OPTS=%JVM_OPTS% -Xms1g -Xmx2g" depois da linha gerada set "JVM_OPTS=...".

Não remova as opções que o empacotador gerou para o Spring Boot ou o JavaFX, como --add-opens e o caminho de módulos. Empacotar de novo sobrescreve qualquer alteração manual — veja Opções de inicialização JVM.

5. Alcance da proteção

Por padrão, as classes de aplicativo sob BOOT-INF/classes são protegidas. Estas classes ligadas ao Spring costumam ficar melhor sem proteção:

• classes @Controller, @RestController e @ControllerAdvice;
• classes @Configuration, classes de autoconfiguração e classes ampliadas por AOT ou CGLIB;
• DTOs do Jackson, entidades JPA, records e modelos de validação;
• o ponto de entrada do aplicativo e qualquer classe que o framework construa ou coloque atrás de um proxy diretamente;
• classes que precisam de ampliação de bytecode em tempo de execução.

Proteja as implementações de serviço e chegue até elas por uma fachada ou interface pública. As regras aceitam nomes de classe exatos, além de pkg.* e pkg.**.

6. Proteger JAR de dependências

--protect-lib protege as dependências correspondentes em BOOT-INF/lib e funciona com as três disposições.

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

Proteja apenas as suas dependências de código fechado. Não criptografe pacotes de frameworks de terceiros como Spring, Tomcat, bibliotecas de log ou drivers de banco de dados na ideia de «proteger mais».

7. Verificação de compatibilidade

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

As duas opções não podem ser usadas juntas. A diferença é esta:

Para springboot, --compat-apply pode escolher a disposição, acrescentar regras de exclusão e ajustar a camada ZIP, o JavaFX e o sufixo do arquivo. Em tudo, menos nas exclusões, prevalece o valor informado explicitamente na linha de comando. As exclusões recomendadas são combinadas por padrão com os seus próprios padrões --exclude; acrescente --no-compat-excludes se não quiser isso. O scanner faz apenas análise heurística estática, de modo que os problemas que exigem mudanças no código não são resolvidos por --compat-apply, e o aplicativo empacotado continua precisando de testes de regressão na plataforma-alvo.

Os demais comandos, todas as opções, as variáveis de ambiente e os exemplos de automação estão na Referência da linha de comando.