Comment protéger vos environnements et points de terminaison grâce à des listes d’autorisation d’IP, l’authentification Basic, le réseau privé et des contrôles basés sur des politiques.
En bref
- Utilisez l’authentification Basic pour protéger rapidement des URL de prévisualisation ou de préproduction.
- Mettez en liste d’autorisation des IP ou des CIDR pour limiter l’exposition aux réseaux de confiance.
- Gardez les services internes privés (pas de ports publics) et privilégiez le réseau de service à service.
- Appliquez des gardes adaptés à l’environnement (ex. règles plus strictes hors production).
1) Quand restreindre l’accès
- Environnements de préproduction et de prévisualisation non destinés au public.
- Tableaux de bord d’administration et API internes.
- Entrepôts de données (bases, files, caches) qui ne doivent jamais être accessibles publiquement.
- Exigences de conformité (ex. accès basé sur IP pour des outils back‑office).
2) Verrouillage rapide avec l’authentification HTTP Basic
L’authentification Basic est la méthode la plus rapide pour protéger un point d’accès sans modifier le code applicatif. Idéale pour des environnements temporaires de préproduction et des démonstrations internes.
2.1 Exemple de proxy inverse NGINX
# /etc/nginx/conf.d/app.conf
server {
listen 443 ssl;
server_name demo.example.com;SSL config omitted for brevitylocation / {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd; # generated with: htpasswd -c /etc/nginx/.htpasswd demoproxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_pass http://app:8080;
}
}
2.2 Configuration générique de route (YAML)
Si votre plateforme prend en charge l’authentification au niveau des routes, vous pouvez la définir dans un fichier de configuration des routes.
# config/routes.yaml routes: match: "https://demo.example.com/*" target: "app:8080" security: basic_auth: enabled: true users: - username: "demo" # Store secrets in environment variables or a vault, not in source control. password_env: "BASIC_AUTH_PASSWORD"
Stockez les identifiants dans des variables d’environnement ou un gestionnaire de secrets, pas dans Git.
3) Restreindre par liste d’autorisation ou de blocage d’IP
N’autorisez que le trafic provenant d’emplacements connus (IP de bureau, sous‑réseaux VPN, exécuteurs CI).
3.1 Liste d’autorisation NGINX
location /admin/ {
allow 203.0.113.0/24; # Office
allow 2001:db8::/32; # IPv6 corporate range
deny all;proxy_pass http://app:8080;
}
3.2 Configuration générique de route (YAML)
# config/routes.yaml routes: match: "https://admin.example.com/*" target: "app:8080" security: ip_allowlist: - "203.0.113.0/24" - "2001:db8::/32"
4) Garder les services internes privés
Les services tels que les bases de données et les API internes ne doivent pas exposer de ports publics. Faites transiter le trafic uniquement via des réseaux internes.
4.1 Docker Compose (sans port public)
# docker-compose.yml
version: "3.9"
services:
app:
build: .
ports:
- "8080:8080" # public app
depends_on:
- db
networks: [private]db:
image: postgres:16
environment:
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
# No 'ports:' here -> not publicly exposed
networks: [private]networks:
private:
driver: bridge
4.2 Kubernetes (accès privé au cluster)
# app service is public via Ingress; db is internal only apiVersion: v1 kind: Service metadata: name: db spec: type: ClusterIP # internal-only selector: app: db ports: - port: 5432 targetPort: 5432apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-allow-app spec: podSelector: matchLabels: app: db ingress: - from: - podSelector: matchLabels: app: app ports: - protocol: TCP port: 5432 policyTypes: [Ingress]
5) Restrictions sensibles à l’environnement
Appliquez automatiquement des règles plus strictes sur les environnements non‑production. Par exemple, imposez Basic Auth sur les branches de “preview” ou un filtrage IP sur “staging”.
5.1 Middleware Express (Node.js) pour le non‑prod
// app.js
const express = require("express");
const basicAuth = require("basic-auth");const app = express();
const env = process.env.APP_ENV || "dev";
const requireAuth = ["dev", "test", "staging"].includes(env);app.use((req, res, next) => {
if (!requireAuth) return next();const creds = basicAuth(req);
const user = process.env.BASIC_AUTH_USER;
const pass = process.env.BASIC_AUTH_PASS;if (creds && creds.name === user && creds.pass === pass) return next();
res.set("WWW-Authenticate", 'Basic realm="Restricted"');
return res.status(401).send("Authentication required.");
});app.get("/", (_req, res) => res.send("Hello!"));
app.listen(8080);
5.2 Configuration de route générique avec bascule par environnement
# config/routes.yaml
routes:
match: "https://preview.example.com/*"
target: "app:8080"
security:
basic_auth:
enabled: ${BASIC_AUTH_ENABLED:false}
users:
- username: ${BASIC_AUTH_USER:preview}
password_env: "BASIC_AUTH_PASS"
6) Contrôles d’accès au niveau de la base de données
Même sur des réseaux privés, appliquez les règles natives du SGBD.
6.1 PostgreSQL pg_hba.conf
# Allow only app subnet host all all 10.0.0.0/24 scram-sha-256Deny everything elsehost all all 0.0.0.0/0 reject
6.2 Portée des utilisateurs MySQL
-- Create a user restricted to the app network CREATE USER 'app'@'10.0.0.%' IDENTIFIED BY 'strong-secret'; GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO 'app'@'10.0.0.%'; FLUSH PRIVILEGES;
7) Fenêtres d’accès temporaires
Créez des accès limités dans le temps qui expirent automatiquement, utile pour des audits ou des revues externes.
7.1 Entrée de liste d’autorisation IP expirante (idée de script)
#!/usr/bin/env bash
set -euo pipefail
IP="${1:-}"
TTL_MINUTES="${2:-60}"if [[ -z "$IP" ]]; then
echo "Usage: $0 [ttl_minutes]" >&2
exit 1
fiExample: write to a config fragment and schedule removalecho "- "IP\" # expires at (date -u -v+TTLMINUTESM2>/dev/null∣∣date−u−d+{TTL_MINUTES}M 2>/dev/null || date -u -d +TTLMINUTESM2>/dev/null∣∣date−u−d+{TTL_MINUTES}min)"
| tee -a ./config/fragments/ip_allowlist.yamlYou would couple this with a deployment pipelineand a separate job to remove expired entries.8) Tester vos restrictions
- Testez depuis des IP autorisées et non autorisées, ou via un VPN, pour valider les règles.
- Utilisez curl pour confirmer l’authentification Basic et les listes d’autorisation IP.
# Expect 401 without credentials curl -i https://demo.example.com/Expect 200 with valid credentialscurl -i -u demo:"$BASIC_AUTH_PASSWORD" https://demo.example.com/From a disallowed IP, expect 403 or 404 (depending on your policy)curl -i https://admin.example.com/
9) Dépannage
- Ordre d’évaluation : les proxys en bordure (Ingress/NGINX) interceptent avant le middleware applicatif — placez les règles au bon niveau.
- Chevauchement des règles : assurez‑vous que les listes d’autorisation spécifiques aux routes ne contredisent pas les valeurs globales.
- IPv6 : si vous autorisez uniquement IPv4, les clients IPv6 peuvent être bloqués (ou l’inverse). Configurez les deux.
- Secrets : vérifiez que les identifiants sont injectés via l’environnement ou un coffre‑fort au moment de l’exécution.
- Cache : si des points protégés sont mis en cache en amont, purgez après modification des règles d’authentification.
10) Replis et sécurité
- Conservez une porte d’accès d’urgence (identifiants “break‑glass” stockés dans un coffre‑fort sécurisé).
- Déployez par paliers (ex. appliquer d’abord en prévisualisation, puis en préproduction, puis en production).
- Journalisez les refus pour vérifier que le trafic légitime n’est pas impacté.
Ce document présente des schémas généraux pour restreindre l’accès sur des piles courantes (proxys, middlewares applicatifs, orchestration et bases de données). Adaptez les exemples au schéma de configuration et au processus de déploiement de votre plateforme.
Commentaires
0 commentaire
Vous devez vous connecter pour laisser un commentaire.