Bloc 3 · Workloads et accès aux apps | SC-300

3.1

System-assigned : liée à une ressource Azure spécifique (VM, App Service...), supprimée avec elle
User-assigned : ressource indépendante, assignable à plusieurs ressources Azure simultanément
Zéro secret à gérer : token fourni par le metadata endpoint Azure (IMDS) à la ressource
Dans le code : DefaultAzureCredential récupère automatiquement le token Managed Identity
Préférer aux Service Principals avec secrets pour toute ressource hébergée sur Azure

3.2

Utilisé quand la Managed Identity n'est pas possible : app hors Azure, CI/CD externe, service on-prem
Client secret : chaîne aléatoire, durée 1-24 mois, rotation manuelle requise avant expiration
Certificat : plus sécurisé car la clé privée ne quitte jamais l'application ; Microsoft le recommande
Workload Identity Federation (OIDC) : alternative moderne sans secret, basée sur des tokens IdP externes (GitHub Actions, etc.)

3.3

App Registration : définit l'identité de l'app (permissions déclarées, credentials, URIs) — le "moule"
Enterprise App (Service Principal) : instance dans le tenant — le "déploiement" pour les accès et le SSO
Créer une App Registration crée automatiquement un Service Principal dans le tenant home
Les apps de la galerie Microsoft créent uniquement un Enterprise App (pas de App Registration modifiable)
Les Access Reviews et les assignations se font sur l'Enterprise App, pas l'App Registration

3.4

Protocole fédéré XML le plus courant pour les apps enterprise (SaaS, legacy)
Paramètres côté Entra : Entity ID (identifier), Reply URL (ACS URL), certificat de signature
Claims mapping : personnaliser les attributs envoyés dans l'assertion SAML (nom, email, groupes...)
Configuration : Enterprise Apps > [app] > Single sign-on > SAML
Test SSO disponible directement dans le portail avant déploiement

3.5

Protocole moderne basé sur des tokens JWT — utilisé par les apps web, SPA et mobiles actuelles
Flows principaux : Authorization Code + PKCE (apps interactives), Client Credentials (daemon/service)
Configuration via App Registration (pas Enterprise Apps > SSO comme pour SAML)
Différence SAML vs OIDC : SAML = XML + assertions signées ; OIDC = JWT + tokens courts durée de vie
Access token (permissions), ID token (identité), Refresh token (renouvellement silencieux)

3.6

Password-based SSO : Entra ID injecte le login/MDP dans un formulaire web pour les apps sans SSO moderne
Requiert l'extension de navigateur My Apps pour fonctionner sur les postes users
Linked SSO : affiche simplement un lien dans My Apps vers une app déjà configurée ailleurs — aucun vrai SSO
Les deux sont des options de dernier recours ; privilégier SAML ou OIDC si possible

3.7

Expose des apps web on-premise sur Internet sans ouvrir de port entrant dans le firewall
Connector : agent Windows léger on-prem, établit une connexion sortante vers Azure
KCD (Kerberos Constrained Delegation) : pour les apps avec authentification Windows intégrée (IWA)
Header-based : pour les apps qui s'authentifient via des headers HTTP (X-Forwarded-User, etc.)
Compatible CA : accès conditionnel Entra ID s'applique avant le proxy

3.8

Crée/met à jour/désactive automatiquement les comptes dans les apps SaaS compatibles SCIM 2.0
Déclencheur : changements dans Entra ID (onboarding, offboarding, changement de département)
Configuration : Enterprise app > Provisioning > Automatic
Cycle provisioning : create, update, disable, delete (selon les règles configurées)
Attribute mapping : définir quels attributs Entra ID sont copiés dans l'app cible

3.9

User consent : l'utilisateur autorise une app à accéder à ses propres données (delegated permissions)
Admin consent : un admin autorise pour tout le tenant (requis pour les application permissions)
Admin consent workflow : les users peuvent demander l'approbation d'un admin — configurable
User consent settings : autoriser tout / restreindre aux apps vérifiées Microsoft / désactiver entièrement
Révoquer un consentement : Enterprise App > Permissions > Revoke admin consent

3.10

Client secret : 1 mois à 24 mois de validité, valeur visible une seule fois à la création
Certificat : la clé privée reste chez l'application, Entra ID ne voit que la clé publique — plus sécurisé
Microsoft recommande les certificats plutôt que les secrets pour les apps de production
Rotation : surveiller les dates d'expiration (alertes Azure Monitor recommandées)
Workload Identity Federation : élimine complètement le besoin de secrets pour les pipelines CI/CD modernes

3.11

Delegated : l'app agit au nom de l'utilisateur connecté — limitée à ce que l'user peut faire
Application : l'app agit avec sa propre identité (daemon, background job) — toujours admin consent requis
Ex : User.Read (delegated, lit le profil de l'user connecté) vs User.Read.All (application, lit tous les users)
Les Application permissions donnent un accès potentiellement très large — à accorder avec parcimonie
Least Privilege : toujours demander les permissions minimales nécessaires

3.12

Rôles métier définis dans l'App Registration (ex : Admin, Reader, Contributor, SuperUser)
Assignation : utilisateurs ou groupes assignés à ces rôles dans Enterprise App > Users and groups
Dans le token JWT : le claim roles contient la liste des App Roles de l'utilisateur connecté
L'application vérifie le claim roles pour autoriser l'accès à ses fonctionnalités
Différent des rôles Entra ID : les App Roles sont spécifiques à une application donnée

3.13

Analyse les logs réseau (firewall, proxy) pour détecter toutes les apps cloud utilisées par les employés
Résultat : catalogue des apps avec score de risque (0-10), nombre d'utilisateurs, volume de données
Permet de sanctionner (autoriser) ou d'unsanctionner (bloquer via proxy/firewall) les apps découvertes
Configuration : MDCA portal > Cloud Discovery > Upload logs (automatique avec intégration Defender for Endpoint)

3.14

MDCA agit comme reverse proxy entre l'utilisateur et l'application — sans agent sur l'app
Politiques de session : bloquer le download, forcer watermark, bloquer copier-coller, logger toute activité
Prérequis : politique CA avec contrôle de session "Use Conditional Access App Control"
Fonctionne pour les apps compatibles MDCA (galerie + apps SAML custom)

3.15

Inventorie toutes les apps tierces OAuth ayant obtenu un consentement dans le tenant
Affiche : qui a consenti, quelles permissions ont été accordées, niveau de risque de chaque app
Permet de révoquer les consentements suspects (apps inconnues, permissions excessives)
Complémentaire au blocage des consentements en amont via les User consent settings CA