Lors du déploiement des applications Java dans des environnements de production, le renforcement de la sécurité doit démarrer à partir de cinq points clés: 1. Restreindre les autorisations d'exécution, utiliser des utilisateurs non privilégiés pour démarrer les services, éviter les abus des autorisations racinaires, configurer la sécurité de sécurité (en fonction de la situation), restreindre les permis de système de fichiers pendant le déploiement conteneurisé, désactiver le mode de débogage de la botte de printemps et les paramètres sensibles; 2. Mettre à jour les bibliothèques de dépendance et désactiver les protocoles dangereux, rechercher régulièrement des vulnérabilités de dépendance tierces, désactiver SSLV3 et TLS 1.1 et ci-dessous, forcer TLS 1.2, activer les algorithmes de confidentialité HTTPS et transférer; 3. Gérer les journaux et les messages d'erreur avec prudence, éviter d'enregistrer des données sensibles, renvoyer les codes d'erreur communs de manière unifiée et désactiver l'exposition aux informations de la pile; 4. Optimiser les paramètres JVM et les scripts de démarrage, désactiver System.gc (), lire les informations sensibles à partir de variables environnementales ou de configurations cryptées et éviter les mots de passe codés en dure sur la ligne de commande; 5. Surveiller et mettre à jour en continu les configurations pour garantir que les mesures de sécurité restent efficaces avec le changement d'environnement.

Lors du déploiement des applications Java dans des environnements de production, le renforcement de la sécurité est une partie importante qui ne peut être ignorée. De nombreux problèmes ne sont pas dus à la vulnérabilité du code lui-même, mais en raison d'une mauvaise configuration, d'une gestion des autorisations laches ou d'un risque de dépendance à la bibliothèque. Commen?ons par plusieurs points clés et parlons des mesures de sécurité auxquelles il faut faire attention à un fonctionnement réel.

Restreindre les autorisations d'exécution

Les applications Java exécutent par défaut sous des autorisations relativement laches, en particulier lors du démarrage des services avec des comptes root ou administratrice. Le principe des autorisations minimales est très importante ici.

• Exécutez les processus Java avec des utilisateurs non privilégiés et évitez d'utiliser directement la racine
• Configurer SecurityManager (bien qu'il soit obsolète dans la nouvelle version, certains scénarios sont toujours précieux)
• Pour les déploiements conteneurisés, utilisez des systèmes de fichiers en lecture seule ou limitez les chemins de montage
• Si vous utilisez des frameworks tels que Spring Boot, assurez-vous que le mode de débogage ou les points d'extrémité sensibles ne sont pas activés (tels que /actuator )

Par exemple, si l'interface /actuator/env de démarrage de Spring est exposée au réseau externe et n'est pas authentifiée, un attaquant peut obtenir des informations sensibles via l'informatique ou même déclencher l'exécution du code distant.

Mettre à jour les dépendances et désactiver les protocoles dangereux

Les projets Java s'appuient souvent sur un grand nombre de bibliothèques tierces qui peuvent avoir connu des vulnérabilités. De plus, les configurations SSL / TLS sont souvent ignorées.

• Succulez régulièrement des dépendances, en utilisant des outils tels que la dépendance à la dépendance OWASP, le SNYK ou le Nexus Sonatype
• Passez à la dernière version stable, en particulier des bibliothèques couramment utilisées telles que Log4j, Jackson, Apache Commons
• Désactiver les protocoles obsolètes tels que SSLV3, TLS 1.0, TLS 1.1 et Force TLS 1.2 ou plus
• évitez la transmission en texte en clair HTTP et forcez HTTPS
• Configurez la suite de chiffrement droite et hiérarchisez l'algorithme de secret avant

Si votre application utilise toujours JDK 8, n'oubliez pas de la corriger dans le temps, en particulier les mises à jour de sécurité pour Oracle et OpenJDK.

Soyez prudent lors de la gestion des journaux et des erreurs

Les informations sensibles aux fuites de journaux sont un problème commun mais facilement négligé. Les pages d'erreur peuvent également exposer les informations de pile, en fournissant des indices sur les attaquants.

• évitez d'enregistrer des données sensibles telles que les mots de passe, les jetons et les clés dans le journal
• Utilisez des mécanismes de désensibilisation des journaux, tels que le remplacement du numéro de carte de crédit ****
• N'affichez pas les informations d'exception détaillées sur la page d'erreur, en particulier dans les applications Web
• L'interface externe renvoie un code d'erreur commun, plut?t qu'une description d'erreur spécifique.

Par exemple: si une erreur de l'API REST renvoie quelque chose comme java.lang.NullPointerException at com.example.service.UserService.getUserById(UserService.java:45) , cela équivaut à dire à l'attaquant ce qui n'a pas fonctionné.

Paramètres JVM et optimisation de script de démarrage

De nombreuses personnes écrivent directement un script shell pour démarrer des applications Java lors du déploiement et remplissent tous les paramètres. En fait, il y a beaucoup de choses qui peuvent être renforcées ici.

• Paramètres de démarrage Plus -Djava.security.manager (selon la situation) et coopérer avec les autorisations de contr?le des fichiers de politique
• Utiliser -XX: DisableExplicitGC pour désactiver System.gc () pour empêcher la gigue de performance
• Ne pas coder les mots de passe du compte pour les scripts de démarrage, ils doivent être lus à partir de variables environnementales ou de configurations cryptées.
• N'écrivez pas le mot de passe du stade de clés à mort sur la ligne de commande, car il est facile d'être vu par le processus de visualisation PS.

Par exemple:

 java -jar \
  -Duser.TimeZone = GMT 8 \
  -Xx: useg1gc \
  -Xx: disablexplicitgc \
  -Djavax.net.ssl.keystore = / path / to / keystore.jks \
  -Djavax.net.ssl.keystorepassword = your_password_here \
  app.jar

Bien que la commande ci-dessus puisse s'exécuter, le mot KeyStorePass est directement exposé à la ligne de commande. Une fois que d'autres utilisent ps aux , ils peuvent le voir, ce qui est très dangereux.

Fondamentalement, c'est tout. Le renforcement de la sécurité Java n'est pas une tache unique, mais un processus qui nécessite une surveillance et des mises à jour continues. Certains paramètres peuvent sembler simples, mais si ce n'est pas fait, ils peuvent devenir des portails d'attaque.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!