Cloud Public Azure¶
Concepts de cloud hybride¶
Le cloud hybride combine infrastructure on-premise (cloud prive) et cloud public pour tirer le meilleur de chaque modele.
Pourquoi le cloud hybride ?¶
| Besoin | Reponse hybride |
|---|---|
| Resilience | Replicas hors site pour la reprise d'activite (PRA) |
| Souverainete | Donnees sensibles on-premise, workloads non sensibles dans le cloud |
| Elasticite | Burst vers Azure en cas de pic de charge (cloud bursting) |
| Cout | Workloads stables on-premise (CAPEX), workloads variables dans le cloud (OPEX) |
| Conformite | Certaines donnees doivent rester en Europe (RGPD, HDS) |
Connectivite hybride¶
graph LR
subgraph ONPREM["Site On-Premise"]
FW["Fortigate<br/>VPN Endpoint"]
INFRA["Infrastructure<br/>OpenStack + VMware"]
end
subgraph AZURE["Microsoft Azure"]
VPNGW["VPN Gateway<br/>(Active-Active)"]
VNET["Virtual Network<br/>10.16.0.0/16"]
BLOB["Blob Storage"]
ENTRA["Entra ID"]
end
FW <-->|"IPsec IKEv2<br/>BGP dynamique"| VPNGW
VPNGW --> VNET
INFRA --> FW
style FW fill:#f96
style VPNGW fill:#0078d4,color:#fff
| Methode | Debit | Latence | Cout | Cas d'usage |
|---|---|---|---|---|
| VPN Gateway | Jusqu'a 10 Gbps (agregation) | Variable (Internet) | Faible | Sauvegardes, administration, burst occasionnel |
| ExpressRoute | 1-100 Gbps (dedie) | Faible et previsible | Eleve | Production critique, gros volumes de donnees |
VPN Active-Active
Le VPN Gateway est deploye en mode active-active avec deux tunnels IPsec. En cas de panne d'un tunnel, le trafic bascule automatiquement sur le second, avec convergence BGP en quelques secondes.
Services Azure deployes¶
| Service | Usage | Benefice | Lien infra |
|---|---|---|---|
| Azure Blob Storage | Stockage objet pour sauvegardes et archivage | Scalabilite quasi-illimitee, cout au Go | Capacity Tier Veeam SOBR |
| Immutable Storage | Protection anti-ransomware (politique WORM) | Copies inalterables, conformite reglementaire | Retention compliance Veeam |
| Virtual Machines | Workloads DR et environments de test | Elasticite, provisionnement en minutes | Replicas Veeam CDP |
| Virtual Network | Extension reseau hybride via VPN/ExpressRoute | Connectivite securisee site-to-site | Tunnel IPsec Fortigate |
| Entra ID | Federation d'identites (SSO, MFA) | Authentification unifiee cloud + on-prem | Sync AD + FreeIPA |
| Azure Monitor | Metriques et logs des ressources Azure | Visibilite centralisee, alertes | Export vers Grafana |
| Key Vault | Gestion des secrets et certificats cloud | Rotation automatique, audit trail | Complement a Vault on-prem |
| Cost Management | Suivi budgetaire et optimisation | Alertes de depassement, recommandations | Gouvernance financiere |
Blob Storage : tiers de stockage¶
Azure Blob Storage propose trois niveaux d'acces adaptes a la frequence de consultation :
graph LR
subgraph TIERS["Tiers Azure Blob Storage"]
HOT["<b>Hot</b><br/>Acces frequent<br/>Stockage cher<br/>Acces gratuit"]
COOL["<b>Cool</b><br/>Acces occasionnel<br/>Stockage -50%<br/>Acces payant"]
ARCHIVE["<b>Archive</b><br/>Acces rare<br/>Stockage -90%<br/>Rehydratation longue"]
end
HOT -->|"Lifecycle policy<br/>30 jours"| COOL
COOL -->|"Lifecycle policy<br/>90 jours"| ARCHIVE
| Tier | Cout stockage (relatif) | Cout acces | Latence acces | Cas d'usage |
|---|---|---|---|---|
| Hot | 100% (reference) | Tres faible | Millisecondes | Sauvegardes recentes (< 30j), donnees actives |
| Cool | ~50% du Hot | Modere | Millisecondes | Sauvegardes mensuelles (30-90j), logs archives |
| Archive | ~10% du Hot | Eleve | 1-15 heures (rehydratation) | Conformite legale (> 90j), retention longue duree |
Lifecycle Policies
Les regles de cycle de vie permettent de deplacer automatiquement les blobs entre tiers
selon leur age. Combinee au SOBR Veeam, la politique Hot (14j) → Cool (90j) → Archive (365j)
reduit les couts de stockage de 60-70% sans intervention manuelle.
Immutabilite et protection ransomware¶
WORM (Write Once Read Many)¶
L'immutabilite Azure empeche toute modification ou suppression d'un blob pendant la periode de retention, meme par un administrateur Azure avec les droits Owner.
| Mode | Politique modifiable | Suppression possible | Cas d'usage |
|---|---|---|---|
| Legal Hold | N/A (hold actif/inactif) | Non tant que hold actif | Investigations legales, preservation de preuves |
| Time-based (Unlocked) | Oui (extension possible) | Non pendant la retention | Environnements de test, politique en evaluation |
| Time-based (Locked) | Non (irrevocable) | Non pendant la retention | Production, conformite SEC 17a-4, FINRA |
Chaine de protection anti-ransomware¶
graph TD
ATTACK["Attaque ransomware"] --> PROD["Chiffrement des donnees de production"]
ATTACK --> BACKUP["Tentative de suppression des sauvegardes"]
BACKUP --> IMMUTABLE{"Copie immutable<br/>Azure WORM ?"}
IMMUTABLE -->|"Oui"| SAFE["Restauration possible<br/>depuis la copie immutable"]
IMMUTABLE -->|"Non"| LOST["Donnees perdues<br/>Paiement de la rancon"]
style SAFE fill:#2e7d32,color:#fff
style LOST fill:#c62828,color:#fff
Verrouillage irrevocable
Une fois la politique Time-based verrouillee (Locked), elle ne peut plus etre raccourcie ni supprimee, meme par Microsoft. Tester soigneusement la duree de retention avant le verrouillage.
Normes de conformite couvertes¶
| Norme | Secteur | Exigence cle |
|---|---|---|
| SEC 17a-4 | Finance (USA) | Conservation non modifiable des enregistrements |
| FINRA 4511 | Courtage (USA) | Retention des communications electroniques |
| RGPD | Europe | Protection et conservation des donnees personnelles |
| HDS | Sante (France) | Hebergement securise des donnees de sante |
| NIS2 | Europe | Obligations de securite pour les entites essentielles |
Integration Veeam et Azure¶
Le Scale-out Backup Repository (SOBR) de Veeam utilise Azure comme tier de stockage externe.
| Etape | Action | Detail |
|---|---|---|
| 1 | Sauvegarde locale | Veeam ecrit sur le Performance Tier (disque local) |
| 2 | Tiering automatique | Les sauvegardes > 14 jours sont copiees vers Azure Blob (Capacity Tier) |
| 3 | Immutabilite | Veeam active les verrous WORM via l'API Azure sur chaque blob |
| 4 | Archivage | Les sauvegardes > 90 jours migrent vers le tier Archive |
| 5 | Restauration | Veeam peut restaurer directement depuis Azure (rehydratation si Archive) |
Deduplication et compression
Les donnees envoyees vers Azure sont dedupliquees et compressees par Veeam avant le transfert. Cela reduit la bande passante VPN consommee et le volume de stockage facture par Azure.
Reseau hybride¶
Architecture reseau detaillee¶
graph TB
subgraph ONPREM["On-Premise (10.15.0.0/16)"]
FGT["Fortigate FW"]
CORE["Core Switch"]
VLANS["VLANs 100-200"]
end
subgraph AZURE_NET["Azure Networking"]
VPNGW["VPN Gateway<br/>Active-Active<br/>2 tunnels IPsec"]
VNET["VNet Hub<br/>10.16.0.0/16"]
NSG["Network Security Groups"]
AZFW["Azure Firewall<br/>(FQDN rules)"]
PE["Private Endpoints<br/>(Blob, Key Vault)"]
VPNGW --> VNET
VNET --> NSG
VNET --> AZFW
VNET --> PE
end
FGT <-->|"IPsec IKEv2 + BGP"| VPNGW
CORE --> FGT
VLANS --> CORE
| Composant | Role | Configuration |
|---|---|---|
| VPN Gateway | Tunnel IPsec entre on-prem et Azure | Active-active, IKEv2, PFS, DH group 14+ |
| BGP | Echange dynamique des routes | ASN on-prem + ASN Azure, annonce automatique des sous-reseaux |
| NSG | Pare-feu par sous-reseau/NIC | Regles deny-all par defaut, ouverture explicite par port/source |
| Azure Firewall | Filtrage centralise L3-L7 | Regles FQDN (pas seulement IP), inspection TLS optionnelle |
| Private Endpoints | Acces prive aux services PaaS | Blob Storage et Key Vault accessibles via IP privee du VNet |
Private Endpoints vs Public
Sans Private Endpoints, l'acces au Blob Storage passe par Internet (meme via VPN, le trafic sort puis revient). Les Private Endpoints garantissent que le trafic reste entierement sur le backbone Azure.
Identite et acces¶
Architecture d'identite hybride¶
graph LR
subgraph ONPREM_ID["On-Premise"]
AD["Active Directory"]
FREEIPA["FreeIPA"]
end
subgraph AZURE_ID["Azure"]
ENTRA["Entra ID<br/>(Azure AD)"]
CA["Conditional Access"]
PIM["Privileged Identity<br/>Management"]
end
AD -->|"AD Connect Sync<br/>(hash de mot de passe)"| ENTRA
FREEIPA -->|"SAML / OIDC<br/>Federation"| ENTRA
ENTRA --> CA
ENTRA --> PIM
| Composant | Fonction | Detail |
|---|---|---|
| Azure AD Connect | Synchronisation AD on-prem vers Entra ID | Hash de mot de passe, sync toutes les 30 min |
| Federation SAML/OIDC | SSO entre FreeIPA et les applications cloud | Pas de mot de passe stocke dans Azure |
| Conditional Access | Politiques d'acces contextuelles | Geolocalisation, appareil conforme, risque utilisateur |
| RBAC | Controle d'acces base sur les roles | Principe du moindre privilege, Managed Identities pour VMs |
| PIM | Elevation de privileges temporaire | Acces admin JIT (Just-In-Time), approbation, audit trail |
Zero Standing Privileges
Avec PIM, aucun compte n'a de privileges permanents. Un administrateur doit demander une elevation temporaire (ex : 4h), qui est auditee et expire automatiquement.
Infrastructure as Code¶
| Outil | Perimetre | Fichiers |
|---|---|---|
| Terraform | Provisionnement des ressources Azure (VNet, Storage, VMs, NSG) | main.tf, variables.tf, outputs.tf |
| Ansible | Configuration post-deploiement (agents, packages, hardening) | Inventaire dynamique Azure, playbooks |
Workflow IaC¶
| Etape | Outil | Action |
|---|---|---|
| 1. Plan | Terraform | terraform plan : previsualisation des changements |
| 2. Apply | Terraform | terraform apply : creation/modification des ressources |
| 3. Configure | Ansible | Playbooks de configuration (Zabbix agent, Wazuh agent, hardening) |
| 4. Validate | Terraform + Tests | terraform validate + tests d'integration |
State Terraform
Le state Terraform est stocke dans un Azure Blob Storage distant (backend remote) avec verrouillage (state locking) pour eviter les modifications concurrentes par plusieurs operateurs.
Monitoring et logs¶
La supervision des ressources Azure est integree a la supervision globale de l'infrastructure.
| Source | Destination | Protocole | Donnees |
|---|---|---|---|
| Azure Monitor | Grafana (on-prem) | API REST / Plugin | Metriques VMs, stockage, reseau |
| Zabbix Agent 2 (VMs Azure) | Zabbix Server (on-prem) | TCP 10051 via VPN | CPU, RAM, disque, services |
| Azure Log Analytics | ELK / Wazuh (on-prem) | API REST / Event Hub | Logs d'activite, logs de securite |
| Entra ID Logs | Wazuh SIEM | API Graph | Connexions, MFA, risques utilisateur |
Gouvernance des couts¶
La maitrise des couts cloud est un enjeu majeur. Sans gouvernance, les depenses peuvent exploser de maniere imprevisible.
| Levier | Economie estimee | Mecanisme |
|---|---|---|
| Reserved Instances | 30-72% sur les VMs | Engagement 1 ou 3 ans sur les VMs a usage constant |
| Lifecycle Policies | 60-70% sur le stockage | Tiering automatique Hot → Cool → Archive |
| Auto-shutdown | 40-60% sur les VMs dev/test | Arret automatique hors heures de travail (19h-7h, week-ends) |
| Cost Management | Variable | Alertes budget, recommandations Azure Advisor |
| Spot Instances | Jusqu'a 90% | VMs interruptibles pour workloads tolerants (CI/CD, batch) |
graph TD
subgraph GOVERNANCE["Gouvernance des couts"]
BUDGET["Budget mensuel<br/>+ alertes a 80%/100%"]
TAGS["Tags obligatoires<br/>(environment, owner, project)"]
POLICY["Azure Policy<br/>(enforce tags, restrict regions)"]
REVIEW["Revue mensuelle<br/>des depenses"]
end
BUDGET --> TAGS --> POLICY --> REVIEW
REVIEW -->|"Ajustements"| BUDGET
Risque de surconsommation
Un seul developpeur oubliant d'eteindre une VM GPU Standard_NC24 peut generer plus de 3 000 EUR/mois. Les policies d'auto-shutdown et les alertes budget sont indispensables.