Gérer les miroirs publics¶

Chaque build, chaque déploiement, chaque installation de paquet depend de registres publics : npm, PyPI, Maven Central, Docker Hub, les dépôts apt/rpm. Une DSI qui laisse chaque poste et chaque pipeline telecharger directement depuis Internet s'expose a trois catégories de risques.

Pourquoi mettre en place des miroirs internes ?¶

Sécurité de la chaîne d'approvisionnement¶

Les attaques par supply chain se multiplient : typosquatting (paquets malveillants aux noms proches de paquets populaires), dependency confusion (paquets internes ecrases par des paquets publics portant le même nom), mainteneurs compromis (injection de code dans des versions legitimes). Un miroir interne permet de scanner, filtrer et auditer chaque paquet avant qu'il n'atteigne un environnement de build.

Disponibilité et performance¶

Problème sans miroir	Solution avec miroir
Panne de Docker Hub → builds casses	Cache local sert les images déjà connues
Rate limiting npm/PyPI → pipelines en echec	Un seul compte upstream, pas de throttling
Latence réseau → builds lents	Cache local, latence < 1 ms
Coupure internet → déploiement impossible	Paquets disponibles hors ligne

Conformite et audit¶

Les reglementations (ISO 27001, SOC 2, NIS2) exigent de tracer l'origine des composants logiciels. Un miroir interne centralise les SBOM (Software Bill of Materials) et fournit un journal complet des paquets consommes.

Classification¶

Aspect	Niveau
Données manipulees	Interne (les paquets sont publics, mais la configuration et les usages non)
Zone de déploiement	Chaîne logicielle
Chiffrement	HTTPS entre clients et miroir, TLS vers les upstream

Les miroirs révèlent les technologies utilisees

Bien que classes Interne, les miroirs meritent une attention particulière : la liste des paquets caches et la fréquence de telechargement révèlent les technologies, les versions et les dependances de chaque projet. Un attaquant ayant accès au miroir interne peut cartographier la stack technique de l'entreprise. Voir le chapitre Confidentialite.

Ecosystemes couverts¶

graph TD
    subgraph Nexus["Miroir interne (Nexus Repository)"]
        Docker["Docker Hub"]
        npm["npm"]
        PyPI["PyPI"]
        Maven["Maven Central"]
        apt["apt/deb"]
        rpm["rpm/yum"]
        Go["Go"]
        Helm["Helm Charts"]
    end

Chapitres¶

Chapitre	Sujet
Fondamentaux	Ecosystemes de paquets, proxy vs hosted vs group, supply chain, SBOM
Comparaison des solutions	Nexus vs Artifactory vs Verdaccio vs Pulp — grille ADR
Architecture de référence	Nexus : blob stores, metadonnees, reverse proxy, tâches planifiees, sizing
Installation et configuration	Déploiement Nexus avec Podman, configuration initiale, repos proxy et hosted
Integration	Configuration clients (Docker, npm, pip, Maven, Go, apt), CI/CD, webhooks
Confidentialite	Classification, scanning, RBAC, audit, segmentation réseau
Bonnes pratiques	Cleanup, stockage, HA, monitoring, migration, troubleshooting