Auth0 et PCI-DSS : sécuriser l'authentification dans un environnement de paiement

Configurez Auth0 pour répondre aux exigences PCI-DSS v4.0 : authentification multi-facteur, logging, gestion des sessions et contrôle d'accès aux systèmes de paiement.

Par Auth0.Expert · 2025-05-19 · 14 min de lecture

PCI-DSS Paiement Conformité Auth0

Auth0 et PCI-DSS : conformité pour l'environnement de paiement

TL;DR

PCI-DSS v4.0 (en vigueur depuis avril 2024) impose des exigences strictes sur l'authentification pour les systèmes traitant des données de cartes bancaires. Auth0 peut satisfaire les requirements 8.x (gestion des accès) avec la bonne configuration.

Points de douleur

Voici les principales exigences qui posent problème lors de la mise en conformité PCI-DSS avec Auth0 :

Requirement 8.4.2 : MFA obligatoire pour tous les accès à l'environnement CDE
Requirement 8.2.6 : Comptes inactifs désactivés après 30 jours
Requirement 8.6.3 : Pas de mots de passe par défaut, politique de rotation
Requirement 10.x : Logging complet de tous les accès
Comment prouver la conformité à un QSA ?

PCI-DSS Requirements couverts par Auth0

Ce tableau montre comment Auth0 couvre les exigences du PCI-DSS v4.0 pour la gestion des identités et du logging.

PCI-DSS v4.0 — Couverture Auth0 :

Requirement 8 : Identification et authentification
├── 8.2.2 : Identifiants uniques ✅ (Auth0 user_id unique)
├── 8.2.6 : Désactivation comptes inactifs ✅ (Action auto)
├── 8.3.4 : Lockout après N tentatives ✅ (Attack Protection)
├── 8.3.6 : Complexité mots de passe ✅ (Password Policy)
├── 8.3.9 : Expiration mots de passe ✅ (Action + prompt)
├── 8.4.2 : MFA pour CDE ✅ (Auth0 MFA + Actions)
└── 8.6.1 : Accès admin restreint ✅ (RBAC + Actions)

Requirement 10 : Logging et monitoring
├── 10.2.1 : Toutes les actions admin ✅ (Log streaming)
├── 10.2.2 : Tentatives d'accès invalides ✅ (Attack Protection)
└── 10.3.x : Protection des logs ✅ (Log streaming SIEM)

Configuration MFA PCI-DSS

Cette Action Auth0 impose l’utilisation de la MFA pour toute connexion sur une application sensible du périmètre CDE. Cela garantit l’application du PCI-DSS requirement 8.4.2 et privilégie les méthodes MFA résistantes au phishing.

// Auth0 Action : MFA obligatoire pour accès CDE
exports.onExecutePostLogin = async (event, api) => {
  const isCDEApp = [
    "payment-admin",
    "card-management",
    "transaction-portal"
  ].includes(event.client.name);

  if (!isCDEApp) return;

  // Requirement 8.4.2 : MFA obligatoire pour CDE
  const hasMFA = event.authentication?.methods?.some(
    m => m.name === "mfa"
  );

  if (!hasMFA) {
    // Forcer MFA — méthodes phishing-resistant préférées
    api.authentication.challengeWithAny([
      { type: "webauthn-roaming" },  // Clé FIDO2 — recommandé PCI
      { type: "webauthn-platform" }, // Biométrie
      { type: "totp" }               // TOTP — accepté PCI
      // SMS non recommandé pour CDE (vulnérable SIM swap)
    ]);
  }

  // Logger l'accès CDE
  api.accessToken.setCustomClaim(
    "https://pci.votre-app.com/cde_access",
    {
      timestamp: new Date().toISOString(),
      mfa_method: event.authentication?.methods,
      ip: event.request.ip
    }
  );
};

Cette Action vérifie l’accès MFA, force une méthode conforme PCI si nécessaire, puis journalise l’accès à des fins d’audit.

Désactivation automatique des comptes inactifs (8.2.6)

Pour respecter le requirement 8.2.6 PCI-DSS, il faut désactiver tout compte utilisateur inactif depuis plus de 30 jours. Voici un exemple d’Action côté Auth0, suivie d’un script pour automatiser la désactivation via API.

// Auth0 Action : bloquer comptes inactifs > 30 jours
exports.onExecutePostLogin = async (event, api) => {
  const lastLogin = event.user.last_login;

  if (!lastLogin) return; // Premier login

  const daysSinceLastLogin = (Date.now() - new Date(lastLogin)) / (1000 * 60 * 60 * 24);

  // PCI requirement 8.2.6 : désactiver après 30 jours d'inactivité
  if (daysSinceLastLogin > 30) {
    // Bloquer l'accès et déclencher notification admin
    await fetch(process.env.ADMIN_NOTIFY_URL, {
      method: "POST",
      body: JSON.stringify({
        type: "inactive_account_blocked",
        user_id: event.user.user_id,
        email: event.user.email,
        days_inactive: Math.floor(daysSinceLastLogin)
      })
    });

    api.access.deny(
      "Account inactive for more than 30 days. Contact your administrator."
    );
  }
};

Ce code bloque et notifie automatiquement les comptes inactifs selon la politique PCI-DSS.

Pour compléter la conformité PCI, un script cron permet de désactiver chaque jour les comptes Auth0 inactifs depuis 30 jours via l’API Management.

# Script cron : désactiver les comptes inactifs Auth0 (30 jours)
# À exécuter quotidiennement
import requests
from datetime import datetime, timedelta

def disable_inactive_pci_accounts(mgmt_token: str, domain: str):
    headers = {"Authorization": f"Bearer {mgmt_token}"}
    base = f"https://{domain}/api/v2"

    cutoff_date = (datetime.utcnow() - timedelta(days=30)).isoformat() + "Z"

    # Récupérer les utilisateurs inactifs depuis 30 jours
    resp = requests.get(
        f"{base}/users",
        headers=headers,
        params={
            "q": f"last_login:[* TO {cutoff_date}] AND blocked:false",
            "search_engine": "v3",
            "per_page": 100
        }
    )

    inactive_users = resp.json()

    for user in inactive_users:
        # Bloquer le compte
        requests.patch(
            f"{base}/users/{user['user_id']}",
            headers=headers,
            json={"blocked": True}
        )
        print(f"Blocked inactive user: {user['email']} (last login: {user.get('last_login', 'never')})")

    return len(inactive_users)

Ce script identifie chaque jour les comptes inactifs et les bloque. Il vous permet de prouver la conformité PCI-DSS lors des audits.

Politique de mots de passe PCI

Cette configuration impose une politique de mots de passe conforme PCI-DSS v4.0 avec complexité, expiration, historique et blocage des mots de passe faibles.

// Auth0 Dashboard — Password Policy
// Tenant Settings > Password Policy

const pciPasswordPolicy = {
  // Requirement 8.3.6
  password_complexity_options: {
    min_length: 12,                    // Minimum 12 caractères PCI v4.0
    requires_uppercase: true,
    requires_lowercase: true,
    requires_numbers: true,
    requires_symbols: true,
  },

  // Requirement 8.3.9 : expiration mots de passe
  password_expiration_days: 90,        // Maximum 90 jours
  password_history_size: 24,           // Interdire réutilisation 12 derniers

  // Requirement 8.3.4 : lockout
  password_dictionary: {
    enable: true,                      // Bloquer mots de passe courants
  }
};

// Via Management API
const configurePasswordPolicy = async () => {
  await fetch(`https://${domain}/api/v2/connections/${connectionId}`, {
    method: "PATCH",
    headers: { Authorization: `Bearer ${mgmtToken}` },
    body: JSON.stringify({
      options: {
        password_complexity_options: pciPasswordPolicy.password_complexity_options,
        password_expiration: { enabled: true, days: 90 },
        password_history: { enable: true, size: 24 },
        password_dictionary: { enable: true }
      }
    })
  });
};

Cette configuration permet d’appliquer automatiquement toutes les règles PCI-DSS pour les mots de passe sur le tenant Auth0.

Logging PCI-DSS (Requirement 10)

Pour assurer une traçabilité complète des événements de sécurité exigée par PCI-DSS, il est essentiel de streamer les logs Auth0 vers un SIEM compatible.

# Configuration Log Streaming vers SIEM PCI-compliant
# Auth0 Dashboard > Log Streams > New Stream

# Exemple : stream vers Splunk PCI-compliant
splunk_stream_config = {
    "name": "PCI-DSS Splunk Stream",
    "type": "splunk",
    "sink": {
        "splunkDomain": "splunk.votre-corp.com",
        "splunkToken": "your-hec-token",
        "splunkPort": 8088,
        "splunkSecure": True
    },
    "filters": [
        # Requirement 10.2 : tous les événements de sécurité
        "s",    # Signup
        "slo",  # Logout
        "f",    # Failed login
        "w",    # Warnings
        "fp",   # Failed password
        "fu",   # Failed username
        "frd",  # Failed refresh token
        "fapi", # Failed API operation
        "sce",  # SCIM external error
        "pwd_leak",  # Credential stuffing
        "limit_mu",  # Rate limit
        "admin"      # All admin operations
    ]
}

# Les logs doivent être conservés 12 mois (3 mois accessibles immédiatement)
# Configurer la rétention dans votre SIEM en conséquence

Ce code permet de garantir une conservation et une traçabilité des logs conforme PCI-DSS sur votre infrastructure.

Preuve de conformité pour QSA

Cette liste résume les éléments à présenter à votre QSA lors de l’audit PCI-DSS Auth0.

## Documentation Auth0 pour votre QSA PCI DSS

### Preuves à fournir :

1. **Capture Auth0 Dashboard** : MFA enforced policy
2. **Export log stream config** : vers SIEM certifié
3. **Export password policy** : complexité, expiration, historique
4. **Rapport Attack Protection** : tentatives bloquées 90 derniers jours
5. **Liste des users CDE** : avec MFA activé (100%)
6. **Script désactivation inactivité** : preuve d'exécution cron
7. **SOC2 Type II Auth0/Okta** : certificat disponible sur trust.okta.com

Tableau PCI-DSS v4.0 × Auth0

Ce tableau synthétise les requirements PCI-DSS v4.0 et leur couverture Auth0, vous permettant de vérifier facilement la conformité et l’auditabilité.

| Requirement | Exigence | Config Auth0 | Prouvable | |---|---|---|---| | 8.2.2 | IDs uniques | user_id Auth0 | ✅ | | 8.2.6 | Inactivité 30j | Action + cron | ✅ | | 8.3.4 | Lockout | Attack Protection | ✅ | | 8.3.6 | Complexité MDP | Password Policy | ✅ | | 8.3.9 | Expiration MDP | Password Expiration | ✅ | | 8.4.2 | MFA CDE | MFA Policies | ✅ | | 10.2.x | Audit trail | Log Streaming | ✅ | | 10.3.x | Protection logs | SIEM externe | ✅ |

Auth0.Expert réalise des audits PCI-DSS sur votre configuration Auth0 et produit la documentation requise pour vos QSA.