L’accès à Claude Platform on AWS unifie trois environnements, mais la précision d’IAM décide de l’issue en matière de sécurité

AWS a documenté trois voies d’accès à Claude Platform on AWS sous un même abonnement, malgré des exigences très différentes en matière d’identifiants et de sécurité.

Publiée le 1er octobre, l’implémentation connecte les charges de travail AWS, les ordinateurs portables des développeurs et les services externes à des espaces de travail hébergés dans un compte AI Services dédié. Les applications de production utilisent Signature Version 4 entre comptes, les développeurs reçoivent des clés API à portée limitée et les charges de travail externes s’authentifient via la fédération OpenID Connect.

L’architecture promet une facturation et une administration centralisées sans imposer à chaque environnement un modèle d’identifiants unique. Sa tension est tout aussi évidente. La centralisation simplifie la responsabilité, mais une politique IAM trop large ou une clé développeur mal gérée peut affaiblir les frontières entre espaces de travail qui rendent cette conception utile.

Il ne s’agit pas simplement d’un nouveau guide d’intégration de Claude. L’implémentation AWS transforme l’authentification en plan de contrôle propre à chaque environnement. Elle révèle aussi le travail opérationnel dissimulé derrière l’expression « abonnement unique ».

Amazon Bedrock reste un point de référence important. Il fournit des modèles Claude via un service de modèles de fondation géré par AWS. Claude Platform on AWS propose plutôt l’expérience de plateforme native d’Anthropic via un compte AWS, y compris ses API, sa console et ses fonctionnalités de plateforme.

Le nouveau modèle d’accès n’efface pas cette distinction. Il montre comment les entreprises peuvent étendre la plateforme native d’Anthropic à l’ensemble d’une organisation AWS tout en conservant un contrôle IAM sur le trafic de production.

Un abonnement sert désormais trois frontières de confiance

Le changement important ne réside pas seulement dans une connectivité élargie. AWS a associé trois environnements à trois méthodes d’authentification distinctes tout en centralisant la propriété des espaces de travail.

La topologie proposée commence par trois rôles de compte. Un compte de gestion traite la facturation et la gouvernance à l’échelle de l’organisation. Un compte AI Services dédié possède l’abonnement Claude Platform, les espaces de travail, les clés API et les rôles d’accès.

Un ou plusieurs comptes de charges de travail consomment ensuite l’inférence Claude sans posséder l’abonnement. Leurs applications endossent des rôles dans le compte AI Services et appellent des ressources d’espace de travail autorisées par ces rôles.

Cette séparation donne au compte AI Services un objectif précis. Il devient la frontière administrative autour de l’accès à Claude, plutôt qu’un autre compte d’application général rempli de ressources sans rapport.

AWS recommande de créer des espaces de travail distincts pour la production et le développement dans ce compte. Un espace de travail constitue la frontière de ressources utilisée pour séparer les équipes, les projets ou les environnements tout en conservant une administration centralisée.

Chaque espace de travail possède un Amazon Resource Name, ou ARN, auquel les politiques IAM peuvent faire référence. Les autorisations peuvent donc permettre l’inférence sur un espace de travail sans automatiquement autoriser un autre.

La première voie d’accès concerne les applications qui s’exécutent déjà dans AWS. AWS utilise un pod Amazon EKS comme exemple, bien que ce modèle puisse s’appliquer à d’autres charges de travail AWS.

Ce pod endosse d’abord un rôle entre comptes dans le compte AI Services. Les identifiants temporaires signent ensuite les requêtes Claude avec AWS Signature Version 4, couramment appelée SigV4.

SigV4 signe cryptographiquement les requêtes API AWS à l’aide d’identifiants AWS. Elle permet au service destinataire de vérifier l’appelant, l’intégrité de la requête et le contexte d’autorisation sans secret API statique distinct.

Le rôle entre comptes accorde certaines actions aws-external-anthropic sur l’ARN de l’espace de travail de production. L’exemple comprend l’inférence, le comptage des jetons, la récupération de modèles et la liste des modèles.

Le rôle n’a pas besoin d’autorisation pour accéder à l’espace de travail de développement. Cela crée un lien direct entre l’identité de la charge de travail, ses actions API autorisées et son espace de travail Claude permis.

La deuxième voie concerne les ordinateurs portables des développeurs. Les développeurs ont souvent besoin d’un moyen moins contraignant pour tester des prompts, le comportement des SDK et la logique applicative hors d’une charge de travail déployée.

AWS attribue à ces utilisateurs une clé API de longue durée associée à l’espace de travail de développement. Le SDK Anthropic standard peut utiliser cette clé avec le point de terminaison régional Claude Platform on AWS.

Cette voie préserve une expérience développeur familière, mais elle crée un identifiant porteur persistant. Toute personne détenant la clé peut utiliser ses autorisations jusqu’à son expiration ou sa révocation par un administrateur.

La troisième voie cible les services externes. Parmi les exemples figurent les charges de travail exécutées sur Google Cloud, les clusters Kubernetes hors AWS et les systèmes CI/CD tels que GitHub Actions ou GitLab CI.

Ces services utilisent la fédération OIDC, qui échange le jeton signé d’un fournisseur d’identité contre des identifiants AWS temporaires. Ces identifiants temporaires génèrent un jeton porteur Claude de courte durée.

L’exemple d’AWS crée un jeton valable une heure. L’implémentation autorise des durées configurables allant jusqu’à 12 heures, après quoi le service externe doit obtenir un autre jeton.

Ensemble, ces trois voies constituent le cœur de l’accès Claude multi-environnements. L’abonnement reste dans un seul compte, tandis que l’authentification change selon l’emplacement où l’appelant s’exécute.

C’est l’avancée architecturale. Elle reconnaît qu’un pod EKS, un ordinateur portable de développeur et un pipeline externe ne devraient pas partager un modèle d’identifiants universel.

L’accès à Claude Platform on AWS déplace le contrôle vers IAM

L’accès à Claude Platform on AWS dépend désormais moins de l’endroit où le code s’exécute que de la capacité d’IAM à décrire avec précision son identité et son espace de travail prévus.

AWS a présenté le service comme un moyen d’utiliser la plateforme native d’Anthropic via un compte AWS existant. L’entreprise a déclaré qu’AWS était le premier fournisseur cloud à proposer cette expérience native via sa propre structure de compte.

Le lancement initial a relié l’authentification, la facturation et les fonctions d’audit à AWS. Les clients pouvaient utiliser les API et les outils d’Anthropic sans établir de relation commerciale distincte.

La conception multi-environnements étend cette proposition au-delà d’une connexion API de base. Elle fait de l’organisation AWS, plutôt que d’une application individuelle, la couche organisatrice de l’accès à Claude.

C’est important, car l’usage de l’IA en entreprise reste rarement dans un seul environnement. Une équipe peut tester une application localement, la déployer sur EKS et exécuter des évaluations depuis un autre cloud.

Une clé statique partagée peut relier ces trois emplacements, mais elle fusionne aussi leurs identités. Les journaux montrent la clé, pas nécessairement la charge de travail, le compte ou le pipeline qui l’a utilisée.

Les rôles entre comptes conservent davantage de contexte. La charge de travail endosse un rôle nommé, reçoit des identifiants temporaires et effectue des requêtes signées qu’AWS peut attribuer à un principal.

Le rôle crée également deux points de contrôle d’autorisation. Le compte de charge de travail doit permettre à son identité locale d’endosser le rôle cible. Le compte AI Services doit faire confiance à cette identité et à cette organisation.

L’exemple d’AWS ajoute une condition aws:PrincipalOrgID à la politique de confiance. Cette condition limite l’endossement du rôle aux principaux associés à l’organisation AWS spécifiée.

La politique d’autorisation limite ensuite l’inférence à l’ARN de l’espace de travail de production. La confiance répond à la question de savoir qui peut endosser le rôle, tandis que les autorisations définissent ce que ce rôle peut faire ensuite.

Cette séparation met sous pression les équipes qui considéraient auparavant l’accès aux modèles comme une simple distribution de secrets. Elles doivent désormais gérer l’authentification Claude AWS comme une architecture d’identité.

Les équipes sécurité, plateforme et application doivent s’accorder sur la propriété des comptes. Elles ont également besoin de normes de nommage pour les rôles, les espaces de travail, les politiques et les correspondances entre environnements.

Un compte dédié peut rendre ces responsabilités visibles. Il ne les rend toutefois pas automatiquement correctes.

L’architecture affecte également la réponse aux incidents. Un rôle de production peut être désactivé sans supprimer immédiatement l’accès des développeurs. Une clé de développement compromise peut être révoquée sans modifier un rôle de charge de travail EKS.

La séparation des espaces de travail peut aussi faciliter l’attribution des coûts. AWS indique que les organisations peuvent étiqueter les espaces de travail et activer ces étiquettes pour l’allocation des coûts.

Après l’activation, qui peut selon AWS prendre 24 à 48 heures, les équipes peuvent filtrer les données AWS Cost Explorer par espace de travail. Cela crée un lien entre l’isolation technique et l’analyse des dépenses au niveau des projets.

L’auditabilité exige un autre choix explicite. L’administration des espaces de travail apparaît par défaut dans les événements de gestion CloudTrail, mais l’inférence relève de la catégorie des événements de données.

La documentation de surveillance indique que les équipes doivent activer la journalisation des événements de données pour capturer l’inférence et les autres opérations d’espace de travail. Ces événements peuvent également entraîner des frais CloudTrail supplémentaires.

Cette distinction est facile à manquer. La centralisation de l’abonnement améliore la piste d’audit potentielle, mais ne garantit pas que l’activité d’inférence soit enregistrée.

La conception pousse donc les responsables de plateforme à traiter l’observabilité comme une composante du contrôle d’accès. Une politique peut limiter une action, tandis que la journalisation fournit des preuves sur le principal qui l’a effectivement effectuée.

Les trois voies d’authentification résolvent des problèmes différents

L’architecture fonctionne parce qu’elle évite de contraindre la facilité d’utilisation, l’identité des charges de travail et la fédération externe à partager le même cycle de vie des identifiants.

Pour les charges de travail AWS, SigV4 entre comptes offre l’alignement le plus net avec l’identité cloud existante. L’application reçoit des identifiants AWS temporaires en endossant un rôle.

Elle signe ensuite chaque requête vers le point de terminaison Claude. Aucune clé API Claude distincte n’est stockée dans le compte de charge de travail, l’image de conteneur ou la configuration de déploiement.

Cette approche suit les recommandations établies d’AWS. Les bonnes pratiques IAM de l’entreprise recommandent des identifiants de rôle temporaires pour les charges de travail au lieu de clés d’accès de longue durée.

Le rôle de production peut inclure uniquement les actions dont l’application a besoin. Une application synchrone de base peut nécessiter des autorisations d’inférence et de comptage des jetons, mais pas d’actions sur les fichiers, les lots ou l’administration.

Claude Platform on AWS utilise l’espace de noms IAM aws-external-anthropic. Son modèle d’autorisations associe les routes API à des actions spécifiques, telles que CreateInference pour les requêtes de messages.

Cette action peut faire référence à un ARN d’espace de travail. L’application accède à l’espace de travail de production sans hériter de privilèges Claude à l’échelle du compte.

C’est la plus robuste des trois voies pour les charges de travail AWS continues. L’application ne contient pas de secret Claude durable, et AWS peut attribuer les requêtes à une identité endossée.

Les ordinateurs portables des développeurs créent une contrainte différente. Exiger que chaque expérimentation locale passe par une chaîne de rôles entre comptes peut augmenter les coûts de configuration et ralentir l’itération.

AWS utilise donc une clé API limitée à l’espace de travail pour le développement. La clé fonctionne avec le client Anthropic standard et cible le point de terminaison régional Claude Platform on AWS.

La réserve importante est qu’une clé nouvellement générée n’est pas automatiquement assez limitée pour ce modèle. AWS indique que son utilisateur IAM sous-jacent reçoit initialement la politique gérée AnthropicLimitedAccess.

Selon le guide d’implémentation, cette politique gérée accorde l’accès à l’ensemble des espaces de travail. Un administrateur doit la détacher et la remplacer par une politique intégrée limitée au développement.

Cette étape constitue le contrôle manuel le plus déterminant du parcours développeur. Générer la clé est simple, mais appliquer la limite prévue de l’espace de travail exige une modification IAM distincte.

AWS recommande de tester ensuite cette limite. Le développeur doit appeler avec succès l’espace de travail de développement, puis tenter une requête de production et confirmer qu’IAM la refuse.

Ce test négatif compte davantage que la requête réussie. Une réponse de développement prouve la connectivité, mais seul le rejet d’un appel de production vérifie l’affirmation d’isolation.

La clé API reste auto-authentifiante. Elle fonctionne depuis AWS, un autre cloud ou un ordinateur portable, car la possession de la clé fournit l’identifiant.

Les équipes doivent donc la stocker dans un gestionnaire de secrets approuvé et définir une date d’expiration. Elles ont également besoin de procédures de révocation pour les appareils perdus, les changements de rôle et l’exposition accidentelle d’un dépôt.

Le parcours des charges de travail externes élimine ce secret persistant. OIDC permet à un fournisseur d’identité compatible d’émettre un JSON Web Token qui identifie la charge de travail.

AWS Security Token Service valide le jeton et vérifie les conditions de confiance du rôle. Il renvoie ensuite des identifiants AWS temporaires via AssumeRoleWithWebIdentity.

Les conseils OIDC recommandent ce modèle pour les applications hors d’AWS, car il évite d’intégrer des identifiants à long terme.

La charge de travail externe utilise ses identifiants AWS temporaires pour demander un jeton porteur Claude de courte durée. Une fois généré, ce jeton porteur peut appeler Claude sans conserver les identifiants AWS.

Cela est utile pour les conteneurs externes et les tâches CI/CD, mais le renouvellement du jeton devient alors une responsabilité de l’application. Un service exécuté en continu doit renouveler le jeton avant son expiration.

La politique de confiance OIDC mérite également une attention particulière. L’exemple d’AWS vérifie les revendications d’audience et de sujet du jeton par rapport aux valeurs attendues.

L’audience identifie le destinataire prévu du jeton. Le sujet distingue la charge de travail, le compte de service, le dépôt ou l’identité de pipeline autorisés.

Des filtres de revendications trop souples peuvent admettre davantage d’identités externes que prévu. Un mécanisme de fédération correct assorti d’une condition de confiance imprécise produit tout de même un accès excessif.

Ces parcours sont donc complémentaires, et non interchangeables.

• SigV4 inter-comptes convient aux charges de travail de production déjà régies par des identités AWS.

• Les clés API limitées à un espace de travail réduisent les frictions pour le développement local.

• La fédération OIDC convient à l’automatisation externe capable de présenter une identité de charge de travail vérifiable.

L’élément commun est l’espace de travail. Chaque parcours d’identifiants doit, en définitive, se résoudre en autorisations pour l’espace de travail adapté à cet environnement.

La centralisation n’élimine pas le risque lié aux identifiants

La conception n’améliore l’isolation que si chaque rôle, clé, condition de confiance, point de terminaison et paramètre de journalisation correspond à l’espace de travail prévu.

Le risque le plus clair se situe dans le parcours développeur. Les propres instructions d’AWS indiquent qu’une clé API générée porte initialement une politique gérée donnant accès à chaque espace de travail.

Un administrateur doit identifier le nouvel utilisateur IAM associé, supprimer cette politique et attacher une politique en ligne plus restrictive.

Ce flux de travail est vulnérable aux erreurs humaines. Un administrateur peut limiter le mauvais utilisateur, conserver la politique gérée ou référencer un ARN d’espace de travail incorrect.

La clé résultante fonctionnerait tout de même. Sa requête de développement réussie ne révélerait pas qu’elle a également conservé un accès à la production.

Un test de refus obligatoire peut détecter cette erreur. Les organisations devraient intégrer le test d’accès à la production au processus d’émission des clés, plutôt que d’en faire une validation facultative effectuée plus tard.

Les clés de longue durée créent également une attribution plus faible que l’accès fondé sur les rôles. Plusieurs développeurs partageant une même clé peuvent apparaître comme le même principal dans les enregistrements d’audit.

Les clés individuelles améliorent l’attribution, mais augmentent le nombre d’identifiants nécessitant un stockage sécurisé, une expiration, une révocation et un suivi de propriété.

Le parcours inter-comptes présente d’autres modes de défaillance. Une politique de confiance peut être trop large, ou l’autorisation d’assumer un rôle côté charge de travail peut atteindre le mauvais rôle cible.

La condition aws:PrincipalOrgID aide à restreindre le périmètre organisationnel. Elle ne remplace toutefois pas un ARN de principal exact ni une nomenclature rigoureuse des rôles.

Les autorisations méritent également un examen au niveau des actions. Accorder un accès générique à l’ensemble de l’espace de noms aws-external-anthropic compromettrait la structure de moindre privilège présentée dans le guide.

AWS publie des exemples détaillés de politiques IAM pour l’inférence dans un seul espace de travail et d’autres contrôles. Les équipes doivent valider leurs politiques déployées par rapport aux fonctionnalités d’API qu’elles utilisent réellement.

Le parcours OIDC déplace la sécurité vers les revendications d’identité externes. Sa sûreté dépend du bon fonctionnement conjoint de l’émetteur, de l’audience, du filtre de sujet, de la politique de rôle et de la logique de renouvellement des jetons.

Un modèle de sujet couvrant tout un groupe de dépôts peut autoriser des pipelines sans rapport. Un modèle de compte de service trop large peut admettre des charges de travail en dehors de l’espace de noms prévu.

Les identifiants temporaires limitent la durée d’exposition, mais ils ne corrigent pas des autorisations excessives pendant cette durée. Un accès de courte durée est plus sûr qu’un accès permanent, mais pas automatiquement conforme au principe du moindre privilège.

Le jeton Claude généré devient aussi un identifiant porteur autonome. Jusqu’à son expiration, sa possession suffit pour l’utiliser dans la limite d’autorisation héritée.

Les applications doivent éviter de l’imprimer dans les journaux, les sorties de build, les traces d’exception ou les métadonnées de supervision. La durée de vie du jeton devrait, dans la mesure du possible, correspondre à celle de la tâche.

Le comportement régional ajoute une autre contrainte opérationnelle. Les espaces de travail sont créés dans une région AWS, et les requêtes API doivent cibler le point de terminaison régional correspondant.

AWS distingue cette liaison au point de terminaison de la géographie d’inférence. Les paramètres de sécurité de l’espace de travail déterminent indépendamment si l’inférence utilise un routage américain ou mondial.

Les clés de courte durée fonctionnent uniquement avec le même point de terminaison régional où elles ont été générées. Selon le guide d’AWS, les clés API de longue durée ne sont pas verrouillées à une région.

Cette différence peut produire des échecs déroutants lors du déploiement. Un processus de renouvellement de jeton peut réussir dans une région tandis qu’une application pointe vers un autre point de terminaison.

L’architecture comporte également une limite plus large que les acheteurs doivent comprendre. AWS indique que Claude Platform on AWS est exploité par Anthropic, les requêtes et les données étant traitées hors de la limite de sécurité AWS.

Le service se distingue donc d’une hypothèse selon laquelle tous les traitements restent à l’intérieur d’un périmètre de service contrôlé par AWS. Les organisations soumises à des exigences strictes de résidence des données ont besoin d’un examen distinct.

AWS positionne Claude Platform on AWS comme complémentaire aux modèles Claude disponibles via Amazon Bedrock. Le choix ne se résume donc pas à comparer une méthode d’authentification à une autre.

Il inclut les fonctionnalités de la plateforme, la responsabilité opérationnelle, les limites de traitement et les exigences régionales. L’accès multi-environnements ne résout pas ces questions pour chaque charge de travail.

La centralisation peut également augmenter le rayon d’impact des erreurs administratives. Le compte AI Services détient l’abonnement, les espaces de travail, les clés API et les rôles d’accès.

Une modification dans ce compte peut affecter plusieurs comptes d’application à la fois. La conception doit donc appliquer à ce compte des contrôles de changement plus stricts qu’à un environnement de développement occasionnel.

Les équipes devraient séparer, lorsque possible, la rédaction des politiques de leur approbation. L’infrastructure en tant que code peut aussi réduire les définitions de rôles incohérentes entre les équipes et espaces de travail supplémentaires.

AWS indique que les organisations disposant de davantage d’environnements peuvent créer un espace de travail pour chaque équipe ou charge de travail et reproduire le modèle de rôle inter-comptes.

Cette approche fait évoluer le modèle d’isolation, mais elle multiplie aussi les politiques, les relations entre rôles, les journaux, les balises et les configurations de points de terminaison. La discipline opérationnelle devient le facteur limitant.

La promesse centrale doit donc être formulée avec prudence. Le modèle fournit les composants nécessaires à l’isolation des espaces de travail, mais les politiques déployées et la gestion des identifiants déterminent si cette isolation tient réellement.

Ce que les entreprises devraient valider ensuite

Le prochain test consiste à déterminer si les organisations peuvent exploiter ce modèle d’accès de manière cohérente, et non si les trois flux d’authentification fonctionnent dans une démonstration.

Le premier indicateur est la validation automatisée des politiques. Les équipes devraient confirmer que chaque rôle de production cible un ARN d’espace de travail attendu et uniquement les actions API nécessaires.

L’émission de clés développeur devrait inclure le remplacement de politique, l’expiration, le stockage des secrets et un test forcé de refus d’accès à la production. Un processus qui dépend de la mémoire finira inévitablement par dériver.

Si les organisations automatisent ces vérifications via des pipelines de déploiement, le modèle centralisé d’AWS devient plus crédible à grande échelle. Des exceptions manuelles répétées affaibliraient cette conclusion.

Le deuxième indicateur est la couverture d’audit. Les seuls événements de gestion CloudTrail ne fournissent pas de visibilité par appel sur l’inférence.

Les organisations devraient activer les événements de données pour le type de ressource Claude concerné, puis vérifier que les enregistrements contiennent une attribution utile du principal.

Elles devraient également tester si les intervenants en cas d’incident peuvent relier une requête à un rôle EKS, une clé développeur ou une identité OIDC externe.

Si le parcours d’audit préserve ces distinctions, l’architecture à trois parcours favorise un accès responsable. Si les journaux aplatissent les appelants en identités partagées, la centralisation offre moins de valeur pour les enquêtes.

Le troisième indicateur est l’adoption au-delà des applications natives AWS. Le parcours OIDC est conçu pour les clouds externes, les déploiements Kubernetes et les systèmes CI/CD.

Son véritable test sera la rotation fiable des jetons pendant les tâches de longue durée. Les équipes doivent également maintenir des revendications de sujet et d’audience étroites à mesure que les dépôts et comptes de service évoluent.

Des échecs d’authentification fréquents encourageraient les développeurs à revenir aux secrets de longue durée. Un renouvellement stable assorti de conditions de confiance précises renforcerait l’approche fédérée.

Les entreprises devraient également surveiller la prolifération des espaces de travail. Créer un espace de travail par équipe ou charge de travail peut améliorer l’isolation, la propriété et l’allocation des coûts.

Un trop grand nombre d’espaces de travail sans étiquettes cohérentes ni règles de cycle de vie peut créer une autre forme de prolifération. Les anciennes clés, les rôles abandonnés et les espaces de travail inutilisés nécessitent un processus de retrait.

Le compte AI Services dédié devrait devenir une limite de service gouvernée. Ses administrateurs doivent disposer de registres de propriété pour chaque espace de travail, rôle et identifiant.

Les équipes plateforme peuvent consigner les décisions d’accès parallèlement à l’architecture applicative et aux procédures d’incident. Une base de connaissances d’ingénierie consultable peut aider à préserver ces correspondances à mesure que les équipes évoluent.

L’évaluation la plus utile commence par un parcours d’application complet. Connectez une charge de travail de production via SigV4, un client de développement via une clé restreinte et un pipeline via OIDC.

Vérifiez ensuite les requêtes inter-espaces de travail refusées, le renouvellement des jetons, les événements de données CloudTrail et la révocation d’urgence. Ces contrôles tiennent-ils toujours après des modifications de politique courantes ?

Cette réponse compte davantage que la première requête réussie. L’accès à Claude Platform on AWS prend désormais en charge trois environnements sous un même abonnement, mais sa valeur de sécurité dépend d’une preuve d’isolation reproductible.