Private Service Connect, Private Endpoints & Interconnect

Accéder à un service cloud managé (Cloud SQL, Storage, Key Vault, S3) sans exposer d'IP publique est un besoin critique pour toute architecture sécurisée. Chaque fournisseur a sa solution : Private Service Connect (PSC) chez Google Cloud, Private Endpoint sur Azure, et PrivateLink sur AWS. Associés à Interconnect, Direct Connect ou ExpressRoute, ils permettent une connectivité privée de bout en bout. Cet article détaille ces concepts avec des exemples Terraform et des bonnes pratiques.

L'exposition publique d'un service (base de données, API, queue) augmente la surface d'attaque. Les solutions de private endpoint créent une IP privée (RFC1918) pour le service, accessible uniquement depuis votre VPC ou votre réseau on‑premise via un peering ou un interconnect.

• ✔ Sécurité : plus d'accès depuis l'internet public, fin des pare-feux IP complexes.
• ✔ Conformité : respect de normes (NIS2, ISO 27001, RGPD) exigeant un contrôle strict des flux.
• ✔ Performances : réduction de la latence et de la dépendance aux passerelles NAT.

Private Service Connect (PSC) permet de consommer un service (Google managé, partenaire ou votre propre workload) via une IP interne de votre VPC. Deux modes :

• PSC pour services Google : Cloud SQL, BigQuery, Cloud Storage, Vertex AI, etc.
• PSC pour services publiés : tiers (Confluent, MongoDB Atlas, Redis Enterprise) ou vos propres applications (via un Service Attachment).

Exemple Terraform : Cloud SQL avec PSC

# Déclaration d'un endpoint PSC vers un service Google (ex: Cloud SQL)
resource "google_compute_global_address" "psc_ip" {
  name          = "psc-sql-ip"
  address_type  = "INTERNAL"
  purpose       = "PRIVATE_SERVICE_CONNECT"
  network       = google_compute_network.vpc.id
  address       = "10.0.0.100"
}

resource "google_compute_forwarding_rule" "psc_sql" {
  name                  = "psc-forwarder"
  network               = google_compute_network.vpc.id
  load_balancing_scheme = ""
  target                = "projects/project-id/regions/region/serviceAttachments/cloudsql"
  ip_address            = google_compute_global_address.psc_ip.id
}

# Dans Cloud SQL, activer Private Service Connect
# (via gcloud ou console) : 
# gcloud sql instances patch mon-instance --psc-enabled

Azure Private Link + Private Endpoint

Un Private Endpoint assigne une IP privée d’un sous‑réseau à un service PaaS Azure (Storage, SQL, Key Vault, etc.) ou à un service partenaire. Le trafic reste dans le backbone Microsoft.

# Terraform Azure
resource "azurerm_private_endpoint" "example" {
  name                = "pe-storage"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  subnet_id           = azurerm_subnet.subnet.id

  private_service_connection {
    name                           = "psc-storage"
    private_connection_resource_id = azurerm_storage_account.sa.id
    is_manual_connection           = false
    subresource_names              = ["blob"]
  }
}

AWS PrivateLink (VPC Endpoints)

Interface VPC Endpoint (type Interface) permet d’accéder à un service AWS (S3, DynamoDB, etc.) ou à un service propriétaire via un NLB interne. Utilise des adresses IP privées et des en‐têtes DNS.

# Terraform AWS
resource "aws_vpc_endpoint" "s3" {
  vpc_id       = aws_vpc.main.id
  service_name = "com.amazonaws.us-east-1.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids = [aws_route_table.private.id]
}

⚠️ Note : S3 et DynamoDB utilisent plutôt Gateway Endpoints (gratuits) ; les autres services (ECR, Secrets Manager, etc.) utilisent des Interface Endpoints (payants).

Pour connecter votre datacenter ou vos bureaux à un cloud, les connexions dédiées offrent une bande passante garantie et une latence réduite. Voici comment elles s’articulent avec les private endpoints :

• Dedicated Interconnect (GCP) : liaisons physiques (10/100 Gbps) entre votre routeur et le peering edge de Google. Vous pouvez ensuite atteindre un PSC depuis votre on‑prem via les routes BGP échangées.
• AWS Direct Connect : connexion dédiée, puis via un Virtual Private Gateway ou un Private VIF, vous accédez à vos VPC Endpoints.
• Azure ExpressRoute : circuit privé vers Microsoft, puis accès aux Private Endpoints via le peering privé.

Cas concret : Application sur‑premise (serveur SAP) qui doit requêter une base Cloud SQL dans GCP :

• Mise en place d’un Dedicated Interconnect entre le datacenter et Google.
• Création d’un PSC vers Cloud SQL avec une IP privée.
• Configuration du DNS (Cloud DNS) avec une zone privée résolvant le nom de l’instance Cloud SQL vers l’IP du PSC.
• Le serveur on‑prem utilise le forwarder BGP + résoluteur DNS pour atteindre la base via la connexion privée.

Voici un squelette modulaire pour déployer un PSC sur GCP, un Private Endpoint sur Azure et observer les similitudes :

# GCP : PSC vers Cloud SQL
resource "google_compute_forwarding_rule" "psc" {
  name   = "psc-sql-prod"
  target = "projects/project-id/regions/us-central1/serviceAttachments/cloudsql-mysql"
  ip_address = google_compute_global_address.psc_ip.id
}

# Azure : Private Endpoint vers Storage Account
resource "azurerm_private_endpoint" "pe" {
  name = "pe-storage-prod"
  private_service_connection {
    private_connection_resource_id = azurerm_storage_account.sa.id
    subresource_names              = ["blob"]
  }
}

# AWS : Interface Endpoint pour Secrets Manager
resource "aws_vpc_endpoint" "secrets" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.region.secretsmanager"
  vpc_endpoint_type = "Interface"
  subnet_ids        = [aws_subnet.private.id]
  security_group_ids = [aws_security_group.endpoint.id]
}

⚠️ Attention aux résolutions DNS : chaque cloud recommande d'utiliser ses zones DNS privées (Cloud DNS, Azure Private DNS, Route53 Resolver) pour que les noms canoniques du service pointent automatiquement vers l'IP privée.

✔ À faire

• Isoler les subnets où vous créez des endpoints : appliquez des Network Policies ou NSG restrictives.
• Utiliser des labels/tags pour identifier les ressources de connectivité privée.
• Surveiller les logs : VPC Flow Logs (GCP), NSG Flow Logs (Azure), VPC Flow Logs (AWS) pour détecter des accès anormaux.
• Automatiser le DNS : prévoyez des enregistrements A/AAAA pointant vers les IP du PSC / Private Endpoint.

⚠️ Limites connues

• Quotas : nombre maximal de PSC endpoints par VPC (certains clouds limitent à 250).
• Coûts cachés : les private endpoints sont facturés à l'heure (souvent 0,01$ à 0,05$/h) plus le trafic traité.
• Cross‑region non systématique : Un PSC dans us-central1 vers un service dans europe-west1 n'est pas garanti pour tous les services.
• Latence additionnelle : Le passage par le endpoint peut ajouter quelques millisecondes comparé à un accès direct via IP publique.

• 100% GCP → PSC + Interconnect pour hybridation.
• Azure / AWS → Private Endpoint / PrivateLink sont incontournables pour toute architecture sécurisée.
• Multi-cloud → Chaque cloud gère sa propre connectivité privée. Utilisez un outil de gestion centralisée (Terraform, Crossplane) pour maintenir la cohérence.

La mise en place de ces mécanismes est un prérequis pour tout projet cloud souhaitant atteindre un haut niveau de sécurité et de conformité. Commencez par un audit de vos accès publics, puis planifiez la migration des services critiques vers des points de terminaison privés.