first commit

This commit is contained in:
Alexis Rolland
2026-06-20 11:21:34 +02:00
commit 0d021fcd66
12 changed files with 637 additions and 0 deletions
+35
View File
@@ -0,0 +1,35 @@
#!/usr/bin/env bash
#
# Template anonymisé — synchronisation chiffrée vers pCloud
# Copier en pcloud-sync.sh, adapter les chemins, ne jamais commiter le fichier réel
# ni les identifiants (à stocker via un gestionnaire de secrets / variables d'environnement,
# jamais en dur dans ce script).
#
# Pré-requis : rclone configuré avec un remote pCloud chiffré (crypt) nommé "pcloud-crypt"
# Doc rclone crypt : https://rclone.org/crypt/
set -euo pipefail
SOURCE_DIR="/mnt/data-pool/sensitive"
REMOTE_NAME="pcloud-crypt"
REMOTE_PATH="backup/data-pool"
LOG_FILE="/var/log/pcloud-sync.log"
timestamp() {
date "+%Y-%m-%d %H:%M:%S"
}
echo "$(timestamp) - Début de la synchronisation" >> "$LOG_FILE"
rclone sync "$SOURCE_DIR" "${REMOTE_NAME}:${REMOTE_PATH}" \
--backup-dir "${REMOTE_NAME}:${REMOTE_PATH}-versions/$(date +%Y%m%d)" \
--log-file "$LOG_FILE" \
--log-level INFO \
--transfers 4 \
--checkers 8
echo "$(timestamp) - Synchronisation terminée" >> "$LOG_FILE"
# Note : l'option --backup-dir conserve une copie des fichiers modifiés/supprimés
# côté distant, datée du jour, pour limiter l'impact d'une synchronisation
# après compromission ou chiffrement local malveillant.
+21
View File
@@ -0,0 +1,21 @@
# Template anonymisé — config Cloudflare Tunnel
# Copier en config.yml, remplacer les valeurs, ne jamais commiter le fichier réel ni le credentials-file.
tunnel: __REPLACE_WITH_TUNNEL_ID__
credentials-file: /etc/cloudflared/__REPLACE_WITH_TUNNEL_ID__.json
ingress:
- hostname: cloud.__REPLACE_WITH_DOMAIN__
service: http://nginx-proxy-manager:80
- hostname: media.__REPLACE_WITH_DOMAIN__
service: http://nginx-proxy-manager:80
- hostname: vault.__REPLACE_WITH_DOMAIN__
service: http://nginx-proxy-manager:80
- hostname: auth.__REPLACE_WITH_DOMAIN__
service: http://nginx-proxy-manager:80
# Règle de repli obligatoire en fin de fichier
- service: http_status:404
@@ -0,0 +1,129 @@
# Template anonymisé — à adapter, ne JAMAIS commiter de vraies valeurs
# Copier ce fichier en docker-compose.yml et remplacer les variables avant usage.
version: "3.9"
networks:
proxy-net:
external: true
internal-net:
internal: true
services:
nginx-proxy-manager:
image: jc21/nginx-proxy-manager:latest
container_name: nginx-proxy-manager
restart: unless-stopped
ports:
- "80:80"
- "443:443"
- "81:81" # interface d'admin, à exposer uniquement via le tunnel
volumes:
- ./npm/data:/data
- ./npm/letsencrypt:/etc/letsencrypt
networks:
- proxy-net
cloudflared:
image: cloudflare/cloudflared:latest
container_name: cloudflared
restart: unless-stopped
command: tunnel run
environment:
- TUNNEL_TOKEN=__REPLACE_WITH_SECRET__ # à stocker dans un .env, jamais en clair ici
networks:
- proxy-net
authentik-server:
image: ghcr.io/goauthentik/server:latest
container_name: authentik-server
restart: unless-stopped
command: server
environment:
AUTHENTIK_SECRET_KEY: __REPLACE_WITH_SECRET__
AUTHENTIK_POSTGRESQL__HOST: authentik-db
AUTHENTIK_POSTGRESQL__PASSWORD: __REPLACE_WITH_SECRET__
AUTHENTIK_REDIS__HOST: authentik-redis
depends_on:
- authentik-db
- authentik-redis
networks:
- proxy-net
- internal-net
authentik-db:
image: postgres:16-alpine
container_name: authentik-db
restart: unless-stopped
environment:
POSTGRES_PASSWORD: __REPLACE_WITH_SECRET__
POSTGRES_USER: authentik
POSTGRES_DB: authentik
volumes:
- ./authentik/database:/var/lib/postgresql/data
networks:
- internal-net
authentik-redis:
image: redis:alpine
container_name: authentik-redis
restart: unless-stopped
networks:
- internal-net
vaultwarden:
image: vaultwarden/server:latest
container_name: vaultwarden
restart: unless-stopped
environment:
DOMAIN: "https://__REPLACE_WITH_SUBDOMAIN__"
SIGNUPS_ALLOWED: "false"
volumes:
- ./vaultwarden/data:/data
networks:
- proxy-net
nextcloud:
image: nextcloud:latest
container_name: nextcloud
restart: unless-stopped
volumes:
- /mnt/data-pool/nextcloud:/var/www/html
networks:
- proxy-net
- internal-net
jellyfin:
image: jellyfin/jellyfin:latest
container_name: jellyfin
restart: unless-stopped
volumes:
- /mnt/media-pool/library:/media
- ./jellyfin/config:/config
networks:
- proxy-net
gluetun:
image: qmcgaw/gluetun:latest
container_name: gluetun
restart: unless-stopped
cap_add:
- NET_ADMIN
environment:
VPN_SERVICE_PROVIDER: __REPLACE_WITH_PROVIDER__
VPN_TYPE: wireguard
WIREGUARD_PRIVATE_KEY: __REPLACE_WITH_SECRET__
networks:
- internal-net
deluge:
image: linuxserver/deluge:latest
container_name: deluge
restart: unless-stopped
network_mode: "service:gluetun"
depends_on:
- gluetun
volumes:
- /mnt/media-pool/downloads:/downloads
- ./deluge/config:/config
+29
View File
@@ -0,0 +1,29 @@
# 🌐 Nginx Proxy Manager — bonnes pratiques appliquées
> Aucune capture d'écran ni configuration réelle n'est versionnée ici (l'admin NPM contient les certificats et les hosts internes). Ce fichier documente les règles suivies.
## Principes
- Un **proxy host** par service, jamais de service exposé directement sans passer par NPM.
- Forçage SSL systématique (`Force SSL` + `HTTP/2`) sur chaque host.
- Certificats Let's Encrypt en wildcard sur le domaine principal, renouvellement automatique.
- Pas d'exposition de l'interface d'administration NPM (port 81) en dehors du tunnel Cloudflare + Authentik forward-auth.
## Convention de nommage des sous-domaines
| Sous-domaine | Service |
| ------------------------- | -------------------- |
| `cloud.example.com` | Nextcloud |
| `media.example.com` | Jellyfin |
| `photos.example.com` | Immich |
| `vault.example.com` | Vaultwarden |
| `auth.example.com` | Authentik |
| `git.example.com` | Gitea |
## Forward-auth (Authentik)
Pour les services ne gérant pas nativement le SSO, un bloc de configuration personnalisée NPM redirige les requêtes non authentifiées vers Authentik (`outpost` en mode proxy), qui valide la session avant de relayer la requête vers le service interne.
## Journalisation
Les access logs et error logs de NPM sont conservés localement avec rotation, pour permettre une analyse en cas de comportement suspect (tentatives d'accès répétées, scans, etc.).
+66
View File
@@ -0,0 +1,66 @@
# 🏗️ Architecture détaillée
## Vue matérielle
```text
┌─────────────────────────────────────────────────────────────┐
│ Jonsbo N4 (boîtier) │
│ │
│ ┌───────────────┐ ┌───────────────┐ ┌─────────────────┐ │
│ │ Ryzen 5 5600 │ │ 32 Go DDR4 │ │ TrueNAS Scale │ │
│ │ (CPU) │ │ (RAM) │ │ (OS, ZFS) │ │
│ └───────────────┘ └───────────────┘ └─────────────────┘ │
│ │
│ Stockage : │
│ ┌───────────┐ ┌───────────────┐ ┌───────────────────────┐ │
│ │ 256 Go NVMe│ │ 2× 500 Go SSD │ │ 2× 4 To HDD + 1× 8 To │ │
│ │ → OS │ │ → Apps/Docker │ │ → Data / Médias │ │
│ └───────────┘ └───────────────┘ └───────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
```
## Logique de séparation
| Couche | Support | Contenu |
| ---------------- | ------------------ | -------------------------------------- |
| Système | NVMe 256 Go | TrueNAS Scale (boot pool) |
| Applications | 2× SSD 500 Go | Conteneurs Docker, bases de données |
| Données sensibles | 2× HDD 4 To (miroir) | Photos, vidéos, documents personnels |
| Médias | 1× HDD 8 To | Bibliothèque multimédia (Jellyfin) |
Cette séparation permet :
- d'isoler les workloads (le système ne partage pas son support avec les données) ;
- de dimensionner chaque pool selon son usage (performance pour les apps, capacité/redondance pour les données) ;
- de limiter le rayon d'impact d'une panne disque à une seule couche.
## Vue logique des services
```text
┌────────────────────┐
│ Cloudflared │
│ (tunnel sortant) │
└─────────┬────────────┘
│ HTTPS uniquement
┌─────────▼────────────┐
│ Nginx Proxy Manager │
│ (reverse proxy + TLS) │
└─────────┬────────────┘
┌──────────────┬──────────┼──────────┬──────────────┐
│ │ │ │ │
┌────▼───┐ ┌─────▼────┐ ┌───▼────┐ ┌────▼─────┐ ┌─────▼─────┐
│Nextcloud│ │ Jellyfin │ │ Immich │ │Vaultwarden│ │ Gitea … │
└────┬───┘ └──────────┘ └────────┘ └──────────┘ └───────────┘
┌────▼─────────────┐
│ Authentik (SSO/MFA)│ ← contrôle d'accès transverse à tous les services
└────────────────────┘
```
## Principes directeurs
1. **Aucun service n'est exposé directement** : tout passe par le tunnel sortant Cloudflared puis le reverse proxy.
2. **Authentification centralisée** : Authentik agit comme point de contrôle unique pour le SSO/MFA.
3. **Isolation réseau interne** : les conteneurs communiquent sur des réseaux Docker dédiés, pas en mode `host`.
4. **VPN dédié pour les flux sensibles** : Gluetun encapsule le trafic de téléchargement (Deluge) pour éviter toute fuite d'IP.
+52
View File
@@ -0,0 +1,52 @@
# 🔐 Politique de sécurité
## Principes appliqués
| Principe | Mise en œuvre |
| ----------------------------- | ----------------------------------------------------------------------------- |
| Exposition minimale | Aucun port ouvert sur le WAN — accès uniquement via tunnel sortant Cloudflared |
| Chiffrement en transit | HTTPS natif sur l'ensemble des services, via Nginx Proxy Manager |
| Authentification centralisée | Authentik (SSO + MFA) en frontal des services sensibles |
| Moindre privilège | Comptes applicatifs dédiés, accès segmentés par service |
| Isolation par conteneur | Chaque service dans son propre conteneur Docker, réseaux internes dédiés |
| Cloisonnement des flux sensibles | VPN dédié (Gluetun) pour les conteneurs de téléchargement |
| Gestion des secrets | Vaultwarden pour les mots de passe et identifiants de service |
| Journalisation | Logs centralisés, conservés pour analyse en cas d'incident |
| Mises à jour | Mises à jour régulières des conteneurs et de TrueNAS Scale |
## Accès distant
```text
Internet
Cloudflare (réseau)
│ tunnel sortant chiffré, initié depuis le NAS
Cloudflared (conteneur, sur le NAS)
Nginx Proxy Manager (TLS, routage par sous-domaine)
Services internes (Nextcloud, Jellyfin, Immich, …)
```
Aucune règle de NAT/port-forwarding n'est configurée sur la box Internet : le tunnel est **initié depuis le NAS vers Cloudflare**, jamais l'inverse. Cela élimine la quasi-totalité des risques liés au scan de ports et aux expositions involontaires.
## Authentification & identités
- **Authentik** centralise le SSO pour les services qui le supportent (OIDC/SAML/proxy forward-auth).
- Le MFA est activé pour tous les comptes ayant un accès administrateur.
- Les services ne supportant pas nativement le SSO sont placés derrière un forward-auth Authentik au niveau du reverse proxy lorsque c'est possible.
## Cycle de vie des accès
- Revue périodique des comptes et des accès actifs.
- Rotation des mots de passe et clés sensibles stockées dans Vaultwarden.
- Suppression des comptes/services inutilisés plutôt que leur désactivation simple.
## Limites connues / axes d'amélioration
- Pas de segmentation réseau par VLAN au niveau du NAS lui-même (la segmentation réseau plus fine est gérée côté infrastructure de virtualisation, voir le projet *pve-project*).
- La supervision est actuellement manuelle (consultation des logs) ; une stack de monitoring/alerting (ex. Uptime Kuma, Grafana) est envisagée.
+40
View File
@@ -0,0 +1,40 @@
# 🗂️ Stratégie de stockage & sauvegarde
## Pools ZFS
| Pool | Disques | Usage | Redondance |
| ----------- | ------------------------- | -------------------------------- | -------------------- |
| `boot-pool` | 1× NVMe 256 Go | Système TrueNAS Scale | Aucune (réinstallable) |
| `apps-pool` | 2× SSD 500 Go | Applications, bases Docker | Miroir |
| `data-pool` | 2× HDD 4 To | Photos, vidéos, documents | Miroir |
| `media-pool` | 1× HDD 8 To | Bibliothèque multimédia (Jellyfin)| Aucune (non critique) |
## Snapshots
- Fréquence : quotidienne sur `data-pool`, hebdomadaire sur `apps-pool`.
- Politique de rétention : conservation glissante (ex. 7 jours / 4 semaines / 6 mois) à adapter selon l'espace disponible.
- Objectif : pouvoir revenir en arrière en cas de suppression accidentelle ou de chiffrement par un ransomware, sans dépendre uniquement de la sauvegarde distante.
## Stratégie 3-2-1 (adaptée à un usage personnel)
```text
3 copies des données
┌──────────┼──────────────┐
│ │ │
Original Snapshot ZFS Sauvegarde
(data-pool) (local) cloud chiffrée
(pCloud, 2 To)
```
1. **Copie 1** — données originales sur `data-pool` (miroir ZFS).
2. **Copie 2** — snapshots ZFS locaux (protection contre erreur humaine / ransomware récent).
3. **Copie 3** — synchronisation chiffrée vers **pCloud** (2 To, abonnement à vie), hors-site, pour couvrir un sinistre matériel ou un vol.
> Les sauvegardes distantes sont versionnées : une compromission ou un chiffrement malveillant détecté tardivement n'écrase pas les versions précédentes.
## Points d'attention
- Le chiffrement vers le cloud est effectué **avant** l'envoi (chiffrement côté client), pCloud ne reçoit que des données déjà chiffrées.
- Les identifiants de synchronisation sont stockés dans Vaultwarden, jamais en clair dans les scripts (voir [`configs/backup/pcloud-sync.sh.example`](../configs/backup/pcloud-sync.sh.example)).
- Un test de restauration est effectué périodiquement pour valider que les sauvegardes sont exploitables (et pas seulement « présentes »).
+25
View File
@@ -0,0 +1,25 @@
# 🎯 Modèle de menace
## Risques considérés et mitigations
| # | Risque | Impact potentiel | Mitigation |
| - | ----------------------------------------- | -------------------------------------------- | ----------------------------------------------------------------------------- |
| 1 | Défaillance matérielle (disque, alim…) | Perte de données, indisponibilité de service | Pools ZFS redondés (miroir), pièces remplaçables à chaud sur la backplane |
| 2 | Erreur humaine (suppression accidentelle) | Perte de fichiers/données | Snapshots ZFS réguliers, versioning |
| 3 | Ransomware | Chiffrement des données locales et distantes | Snapshots locaux + sauvegarde cloud versionnée et chiffrée hors-site |
| 4 | Exposition Internet involontaire | Accès non autorisé depuis l'extérieur | Zéro port ouvert, tunnel sortant exclusif (Cloudflared) |
| 5 | Compromission d'identifiants | Accès non autorisé à un ou plusieurs services | SSO + MFA centralisés (Authentik), secrets dans Vaultwarden |
| 6 | Fuite de données sensibles (réseau, logs) | Divulgation d'informations personnelles | Segmentation des conteneurs, VPN dédié pour les flux de téléchargement |
| 7 | Compromission d'un conteneur applicatif | Mouvement latéral vers d'autres services | Isolation par conteneur, réseaux Docker dédiés, mises à jour régulières |
## Hypothèses
- L'attaquant n'a pas d'accès physique au matériel.
- Le FAI/box Internet n'est pas considéré comme une frontière de confiance (d'où l'absence totale de port ouvert).
- Les services tiers (Cloudflare, pCloud) sont traités comme des intermédiaires de transport/stockage chiffré, pas comme des tiers de confiance absolue : les données qui leur sont confiées sont chiffrées avant envoi lorsque c'est pertinent.
## Ce que ce modèle ne couvre pas (axes d'évolution)
- Attaque ciblée et sophistiquée sur la chaîne d'approvisionnement logicielle (images Docker compromises).
- Défaillance simultanée de plusieurs disques au sein d'un même pool (au-delà de la tolérance du miroir).
- Compromission du compte Cloudflare lui-même (atténuée par le MFA sur ce compte, hors périmètre du NAS).
+240
View File
@@ -0,0 +1,240 @@
# 🗄️ Homelab Serveur NAS & infrastructure de services auto-hébergés
> Serveur **TrueNAS Scale** auto-hébergé, conçu comme une infrastructure de stockage résiliente et un socle de services sécurisés appliquant des principes **Zero-Trust** à un environnement personnel.
---
## 📋 Vue d'ensemble
Ce projet est un **NAS personnel** tournant 24/7, construit autour de **TrueNAS Scale**. Il dépasse le simple stockage de fichiers : c'est un mini-datacenter personnel, pensé pour la maîtrise des données, la résilience face aux sinistres/ransomware, et l'hébergement d'une vingtaine de services conteneurisés.
**Usages principaux :**
- 🔐 Sécuriser et maîtriser mes données personnelles (photos, vidéos, documents)
- ☁️ Mettre en place une stratégie de sauvegarde hybride (local + cloud, logique 3-2-1)
- 🐳 Héberger un écosystème applicatif conteneurisé (cloud, médias, identité, mots de passe…)
- 🧠 Appliquer des principes d'architecture Zero-Trust à un homelab
---
## 🧱 Architecture générale
```text
┌──────────────────────────────────┐
│ Jonsbo N4 │
│ TrueNAS Scale Host │
│ Ryzen 5 5600 / 32 Go DDR4 │
└────────────────┬───────────────────┘
┌───────────────────────────┼───────────────────────────┐
│ │ │
┌───────▼────────┐ ┌────────▼─────────┐ ┌────────▼─────────┐
│ Stockage │ │ Identité & accès │ │ Services Docker │
│ │ │ │ │ │
│ • NVMe → OS │ │ • Authentik (SSO) │ │ • Nextcloud │
│ • SSD → Apps │ │ • Cloudflared │ │ • Jellyfin │
│ • HDD → Data │ │ (tunnel sortant) │ │ • Immich │
│ • HDD → Médias │ │ • Vaultwarden │ │ • Gitea, etc. │
└─────────────────┘ └────────────────────┘ └──────────────────┘
```
---
## 🔧 Infrastructure matérielle
| Composant | Détail |
| ----------- | ------------------------------------------ |
| Boîtier | Jonsbo N4 |
| CPU | Ryzen 5 5600 |
| RAM | 32 Go DDR4 |
| OS storage | 256 Go NVMe (TrueNAS Scale) |
| Apps/Docker | 2 × 500 Go SSD 2,5″ |
| Données | 2 × 4 To HDD (photos, vidéos, documents) |
| Médias | 1 × 8 To HDD (bibliothèque multimédia) |
| Hyperviseur | TrueNAS Scale (ZFS) |
| Fonctionnement | 24/7 |
**Logique d'architecture :**
- Séparation stricte OS / Applications / Données
- Isolation logique des workloads
- Stockage critique redondé (pools ZFS dédiés)
- Optimisation des performances (NVMe pour le système, SSD pour les conteneurs)
Approche inspirée des environnements professionnels : segmentation fonctionnelle, limitation des risques, maintenabilité.
---
## 🗂️ Stratégie de stockage & sauvegarde
### 🔐 Données sensibles
- Stockage sur pool ZFS dédié et redondé
- Snapshots réguliers
- Versioning avec politique de conservation maîtrisée
Protection contre la suppression accidentelle et les scénarios ransomware.
### ☁️ Sauvegarde cloud hybride
Synchronisation chiffrée de 2 To vers **pCloud** (abonnement « à vie »).
**Objectifs :**
- Protection contre un sinistre matériel
- Résilience face au ransomware
- Stratégie **3-2-1** adaptée à un environnement personnel
> Les données critiques ne dépendent jamais exclusivement du cloud. Les sauvegardes distantes sont versionnées afin de limiter l'impact d'une compromission ou d'un chiffrement malveillant.
Détails dans [`docs/storage-and-backup-strategy.md`](docs/storage-and-backup-strategy.md).
---
## 🐳 Écosystème applicatif auto-hébergé
| Service | Rôle |
| ----------------------- | ---------------------------------------------- |
| Nextcloud | Cloud personnel |
| Jellyfin | Streaming local |
| Immich | Gestion photos intelligente |
| Authentik | SSO & gestion centralisée des identités |
| Vaultwarden | Gestionnaire de mots de passe |
| Cloudflared | Tunnel sortant sécurisé |
| Nginx Proxy Manager | Reverse proxy & TLS |
| Gitea | Gestion de code |
| Portainer | Administration Docker |
| ONLYOFFICE | Suite bureautique collaborative |
| Synapse | Serveur Matrix (messagerie décentralisée) |
| Sonarr / Radarr / Prowlarr | Indexation & gestion médias |
| Deluge + Gluetun | Téléchargement cloisonné via VPN |
---
## 🛡️ Sécurité & architecture Zero-Trust
### 🌍 Aucun port exposé
- Pas d'ouverture WAN directe
- Accès distant exclusivement via tunnel sortant chiffré (**Cloudflared**)
- HTTPS natif de bout en bout
- Réduction drastique de la surface d'attaque
### 🔐 Gestion des identités centralisée (Authentik)
- SSO
- MFA
- Segmentation des accès
- Politique de moindre privilège
### 🐳 Isolation des services
- Conteneurisation systématique
- Séparation réseau interne
- Reverse proxy centralisé (Nginx Proxy Manager)
- Cloisonnement des applications sensibles
### 🔍 Protection des flux sensibles
- VPN dédié pour certains conteneurs (Gluetun)
- Journalisation et surveillance des logs
- Mises à jour régulières
Détails dans [`docs/security-policy.md`](docs/security-policy.md).
---
## 🎯 Modèle de menace
| Risque | Mitigation principale |
| ------------------------------------ | ----------------------------------------------- |
| Défaillance matérielle | Pools ZFS redondés, sauvegarde externalisée |
| Erreur humaine / suppression accidentelle | Snapshots réguliers, versioning |
| Ransomware | Snapshots immuables, sauvegarde hors-site, versioning cloud |
| Exposition Internet involontaire | Zéro port ouvert, tunnel sortant uniquement |
| Compromission d'identifiants | SSO + MFA via Authentik |
| Fuite de données sensibles | Segmentation réseau, isolation par conteneur |
Détail complet dans [`docs/threat-model.md`](docs/threat-model.md).
---
## 📊 Approche résilience & continuité
- Snapshots réguliers (politique de rétention documentée)
- Sauvegarde distante externalisée (pCloud, 2 To, chiffrée)
- Séparation données critiques / médias
- Restauration granulaire possible
- Documentation d'architecture tenue à jour
Objectif : réduire le RPO/RTO même dans un contexte personnel.
---
## 📁 Contenu du dépôt
```text
truenas-project/
├── readme.md # Ce fichier
├── docs/
│ ├── architecture.md # Schémas et choix d'architecture détaillés
│ ├── storage-and-backup-strategy.md # Pools ZFS, snapshots, stratégie 3-2-1
│ ├── security-policy.md # Politique de sécurité Zero-Trust
│ └── threat-model.md # Modèle de menace détaillé
├── configs/
│ ├── docker-compose/
│ │ └── docker-compose.yml.example # Template anonymisé (sans secrets)
│ ├── cloudflared/
│ │ └── config.yml.example # Template de tunnel sortant
│ ├── nginx-proxy-manager/
│ │ └── notes.md # Bonnes pratiques de configuration
│ └── backup/
│ └── pcloud-sync.sh.example # Script de synchro chiffrée (template)
└── screenshots/
├── 1.png # Dashboard
├── 2.png # Liste des apps Truenas (docker)
└── 3.png # Liste non exhaustive (bug affichage GUI) des dockers
```
---
## 🧠 Compétences illustrées
**Stockage & résilience**
- Administration TrueNAS Scale / ZFS (pools, snapshots, versioning)
- Conception d'une stratégie de sauvegarde 3-2-1 hybride
- Planification RPO/RTO
**Cybersécurité**
- Architecture Zero-Trust appliquée (aucun port exposé, tunnel sortant uniquement)
- Gestion centralisée des identités (SSO/MFA via Authentik)
- Cloisonnement réseau et isolation par conteneur
- Réduction de la surface d'attaque
**Administration système**
- Conteneurisation (Docker/Portainer)
- Reverse proxy & TLS (Nginx Proxy Manager)
- Auto-hébergement d'une suite applicative complète (cloud, médias, identité, code)
---
## ⚠️ Sécurité du dépôt
> Ce dépôt est **public**. Aucune clé privée, mot de passe, adresse IP réelle ou information sensible n'est commitée. Les fichiers de configuration sont systématiquement **anonymisés ou fournis sous forme de templates**.
---
## 📌 À propos
Projet personnel en évolution continue, utilisé comme plateforme d'apprentissage, d'expérimentation et de montée en compétences en ingénierie cybersécurité et architecture système.
---
*Infrastructure opérationnelle — évolutions régulières selon les services ajoutés et les retours d'expérience.*
BIN
View File
Binary file not shown.

After

Width:  |  Height:  |  Size: 237 KiB

BIN
View File
Binary file not shown.

After

Width:  |  Height:  |  Size: 254 KiB

BIN
View File
Binary file not shown.

After

Width:  |  Height:  |  Size: 71 KiB