Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Gestion des identités et des accès pour Amazon Connect Health

AWS Identity and Access Management (IAM) est un service AWS qui permet à un administrateur de contrôler l’accès aux ressources AWS en toute sécurité. Les administrateurs IAM contrôlent qui peut être authentifié (connecté) et autorisé (autorisé) à utiliser les ressources Amazon Connect Health. IAM est un service AWS que vous pouvez utiliser sans frais supplémentaires.

Public ciblé

La façon dont vous utilisez AWS Identity and Access Management (IAM) varie en fonction du travail que vous effectuez dans Amazon Connect Health.

Utilisateur du service : si vous utilisez le service Amazon Connect Health pour faire votre travail, votre administrateur vous fournit les informations d'identification et les autorisations dont vous avez besoin. Au fur et à mesure que vous utilisez de plus en plus de fonctionnalités d'Amazon Connect Health dans le cadre de votre travail, vous aurez peut-être besoin d'autorisations supplémentaires. Si vous comprenez bien la gestion des accès, vous saurez demander les autorisations appropriées à votre administrateur.

Administrateur du service — Si vous êtes responsable des ressources Amazon Connect Health au sein de votre entreprise, vous avez probablement un accès complet à Amazon Connect Health. C'est à vous de déterminer les fonctionnalités et les ressources d'Amazon Connect Health auxquelles les utilisateurs de votre service doivent accéder. Vous devez ensuite soumettre les demandes à votre administrateur IAM pour modifier les autorisations des utilisateurs de votre service. Consultez les informations sur cette page pour comprendre les concepts de base d’IAM.

Administrateur IAM — Si vous êtes administrateur IAM, vous souhaiterez peut-être en savoir plus sur la manière dont vous pouvez rédiger des politiques pour gérer l'accès à Amazon Connect Health.

Authentification par des identités

L'authentification correspond au processus par lequel vous vous connectez à AWS via vos informations d'identification. Vous devez être authentifié (connecté à AWS) en tant qu'utilisateur racine du compte AWS, en tant qu'utilisateur IAM ou en assumant un rôle IAM.

Pour l'accès par programmation, AWS fournit un SDK et une CLI qui signent de manière cryptographique vos demandes à l'aide de vos informations d'identification. Si vous n'utilisez pas les outils AWS, vous devez signer vous-même les demandes. Amazon Connect Health prend en charge Signature Version 4, un protocole permettant d'authentifier les demandes d'API entrantes. Pour plus d'informations sur l'authentification des demandes, consultez la version 4 d'AWS Signature pour les demandes d'API dans le guide de l'utilisateur IAM.

Quelle que soit la méthode d’authentification que vous utilisez, vous devrez peut-être également fournir des informations de sécurité supplémentaires. Par exemple, AWS vous recommande d'utiliser l'authentification multi-facteur (MFA) pour améliorer la sécurité de votre compte.

Utilisateur racine du compte AWS : lorsque vous créez un compte AWS, vous commencez par une seule identité de connexion qui donne un accès complet à tous les services et ressources AWS du compte. Cette identité est appelée l'utilisateur racine du compte AWS. N'utilisez pas l’utilisateur root de vos tâches courantes. Protégez vos informations d’identification d’utilisateur racine et utilisez-les pour effectuer les tâches que seul l’utilisateur racine peut effectuer.

Utilisateurs et groupes IAM : un utilisateur IAM est une identité au sein de votre compte AWS dotée d'autorisations spécifiques pour une seule personne ou application. Dans la mesure du possible, nous vous recommandons de vous appuyer sur des informations d’identification temporaires plutôt que de créer des utilisateurs IAM ayant des informations d’identification à long terme telles que des mots de passe et des clés d’accès.

Rôles IAM — Un rôle IAM est une identité au sein de votre compte AWS dotée d'autorisations spécifiques. Le concept ressemble à celui d’utilisateur IAM, mais le rôle IAM n’est pas associé à une personne en particulier. Vous pouvez temporairement endosser un rôle IAM dans l’AWS Management Console grâce au changement de rôle.

Identités fédérées : la meilleure pratique consiste à obliger les utilisateurs humains, y compris les utilisateurs nécessitant un accès administrateur, à utiliser la fédération avec un fournisseur d'identité pour accéder aux services AWS à l'aide d'informations d'identification temporaires. Une identité fédérée est un utilisateur de l'annuaire des utilisateurs de votre entreprise, un fournisseur d'identité Web, l'AWS Directory Service, le répertoire Identity Center ou tout utilisateur qui accède aux services AWS à l'aide des informations d'identification fournies par le biais d'une source d'identité.

Gestion de l’accès à l’aide de politiques

Vous contrôlez l'accès dans AWS en créant des politiques et en les associant aux identités ou aux ressources AWS. Une stratégie est un objet dans AWS qui, une fois attaché à une identité ou à une ressource, définit ses autorisations. AWS évalue ces politiques lorsqu'un mandant (utilisateur ou rôle) fait une demande. Les autorisations dans les politiques déterminent si la demande est autorisée ou refusée. La plupart des stratégies sont stockées dans AWS en tant que documents JSON.

Identity-based politiques : Identity-based les politiques sont des documents de politique d'autorisation JSON que vous pouvez associer à une identité, telle qu'un utilisateur, un groupe d'utilisateurs ou un rôle IAM. Ces politiques contrôlent quel type d’actions des utilisateurs et des rôles peuvent exécuter, sur quelles ressources et dans quelles conditions.

Resource-based politiques : Resource-based les politiques sont des documents de politique JSON que vous attachez à une ressource. Par exemple, les politiques de confiance de rôle IAM et les politiques de compartiment Amazon S3 sont des politiques basées sur les ressources.

Autres types de politiques : AWS prend en charge d'autres types de politiques moins courants, notamment les limites d'autorisations, les politiques de contrôle des services (SCP), les politiques de contrôle des ressources (RCP) et les politiques de session.

Comment Amazon Connect Health fonctionne avec IAM

Amazon Connect Health utilise des politiques basées sur l'identité IAM pour contrôler l'accès aux opérations et aux ressources de Connect Health. Les administrateurs doivent appliquer le principe du moindre privilège, en n'accordant que les autorisations requises pour chaque rôle.

Amazon Connect Health prend en charge les fonctionnalités IAM suivantes :

Amazon Connect Health prend en charge le contrôle d'accès basé sur les attributs (ABAC) via des balises IAM pour les opérations liées aux domaines et aux agents. Resource-level des autorisations peuvent être appliquées pour restreindre l'accès à des domaines, agents et intégrations spécifiques. Des autorisations IAM minimales sont requises pour que les administrateurs puissent accéder à Amazon Connect Health via la console AWS.

Read-only politique de console :

{
  "Version": "2012-10-17" ,
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "health-agent:ListDomains",
        "health-agent:GetDomain",
        "health-agent:ListIntegrations",
        "health-agent:ListAgents"
      ],
      "Resource": "*"
    }
  ]
}

Politique d'accès complet à la console :

{
  "Version": "2012-10-17" ,
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudformation:CreateStack",
        "cloudformation:DescribeStackEvents",
        "cloudformation:DescribeStacks",
        "cloudformation:GetTemplate",
        "cloudformation:ListStacks",
        "connect:AssociatePhoneNumberContactFlow",
        "connect:ClaimPhoneNumber",
        "connect:DescribeInstance",
        "connect:DescribePhoneNumber",
        "connect:ListInstances",
        "connect:ListPhoneNumbersV2",
        "connect:ReleasePhoneNumber",
        "connect:SearchAvailablePhoneNumbers",
        "connect:TagResource",
        "connect:UpdatePhoneNumber",
        "connect:UpdatePhoneNumberMetadata",
        "ds:DescribeDirectories",
        "health-agent:CreateAgent",
        "health-agent:CreateDomain",
        "health-agent:CreateIntegration",
        "health-agent:DeleteAgent",
        "health-agent:DeleteDomain",
        "health-agent:DeleteIntegration",
        "health-agent:GenerateMedicalCodes",
        "health-agent:GetAgent",
        "health-agent:GetDomain",
        "health-agent:GetIntegration",
        "health-agent:GetPatientInsightsJob",
        "health-agent:ListAgents",
        "health-agent:ListDomains",
        "health-agent:ListIntegrations",
        "health-agent:PublishAgent",
        "health-agent:StartPatientInsightsJob",
        "health-agent:UpdateAgent",
        "health-agent:UpdateIntegration",
        "healthlake:ReadResource",
        "healthlake:SearchEverything",
        "healthlake:SearchWithGet",
        "healthlake:SearchWithPost",
        "iam:AttachRolePolicy",
        "iam:CreatePolicy",
        "iam:CreatePolicyVersion",
        "iam:CreateRole",
        "iam:CreateServiceLinkedRole",
        "iam:DeletePolicyVersion",
        "iam:GetRole",
        "iam:GetRolePolicy",
        "iam:PassRole",
        "iam:PutRolePolicy",
        "kms:DescribeKey",
        "kms:ListAliases",
        "kms:ListKeys",
        "lambda:AddPermission",
        "lambda:CreateFunction",
        "lambda:GetFunction",
        "lex:BuildBotLocale",
        "lex:CreateBot",
        "lex:CreateBotAlias",
        "lex:CreateBotLocale",
        "lex:CreateBotVersion",
        "lex:CreateCustomVocabulary",
        "lex:CreateIntent",
        "lex:CreateResourcePolicy",
        "lex:CreateSlot",
        "lex:CreateSlotType",
        "lex:CreateUploadUrl",
        "lex:DeleteBotLocale",
        "lex:DeleteCustomVocabulary",
        "lex:DeleteIntent",
        "lex:DeleteSlot",
        "lex:DeleteSlotType",
        "lex:DescribeBot",
        "lex:DescribeBotAlias",
        "lex:DescribeBotLocale",
        "lex:DescribeBotVersion",
        "lex:DescribeImport",
        "lex:ListBotLocales",
        "lex:ListBots",
        "lex:ListTagsForResource",
        "lex:StartImport",
        "lex:TagResource",
        "lex:UpdateBot",
        "lex:UpdateBotAlias",
        "lex:UpdateBotLocale",
        "lex:UpdateCustomVocabulary",
        "lex:UpdateIntent",
        "lex:UpdateResourcePolicy",
        "lex:UpdateSlot",
        "lex:UpdateSlotType",
        "organizations:DescribeOrganization",
        "organizations:ListAccounts",
        "s3:GetObject",
        "s3:ListAllMyBuckets",
        "s3:ListBucket",
        "s3:PutObject",
        "sso:CreateApplication",
        "sso:CreateApplicationAssignment",
        "sso:CreateInstance",
        "sso:ListDirectoryAssociations",
        "sso:ListInstances",
        "sso:PutApplicationAuthenticationMethod",
        "sso:PutApplicationGrant",
        "sso-directory:CreateUser",
        "sso-directory:SearchUsers"
      ],
      "Resource": "*"
    }
  ]
}

Identity-based exemples de politiques pour Amazon Connect Health

Par défaut, les utilisateurs et les rôles ne sont pas autorisés à créer ou à modifier les ressources Amazon Connect Health. Ils ne peuvent pas non plus effectuer de tâches à l'aide de l'AWS Management Console, de l'AWS CLI ou de l'API AWS. Pour octroyer aux utilisateurs des autorisations d’effectuer des actions sur les ressources dont ils ont besoin, un administrateur IAM peut créer des politiques IAM. L’administrateur peut ensuite ajouter les politiques IAM aux rôles et les utilisateurs peuvent assumer les rôles.

Pour savoir comment créer une politique basée sur l'identité IAM à l'aide de ces exemples de documents de stratégie JSON, consultez la section Création de politiques dans l'onglet JSON du guide de l'utilisateur IAM.

Bonnes pratiques en matière de politiques :

Exemple 1 : Autoriser l'accès complet à un domaine spécifique

La politique suivante accorde un accès complet à un domaine Amazon Connect Health spécifique et à ses intégrations.

{
  "Version": "2012-10-17" ,
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "health-agent:*"
      ],
      "Resource": [
        "arn:aws:health-agent:<region>:<account-id>:domain/<domain-id>",
        "arn:aws:health-agent:<region>:<account-id>:domain/<domain-id>/integration/*"
      ]
    }
  ]
}

Exemple 2 : Autoriser les utilisateurs à démarrer et à consulter des sessions de documentation sur environnement ambiant

La politique suivante permet aux utilisateurs de démarrer et de récupérer des sessions de documentation sur l'environnement.

{
  "Version": "2012-10-17" ,
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "health-agent:StartMedicalScribeListeningSession",
        "health-agent:GetMedicalScribeListeningSession"
      ],
      "Resource": "*"
    }
  ]
}

Exemple 3 : Read-only accès à la documentation sur l'environnement

La politique suivante accorde un accès en lecture seule aux sessions de documentation sur l'environnement.

{
  "Version": "2012-10-17" ,
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "health-agent:GetMedicalScribeListeningSession",
        "health-agent:ListMedicalScribeListeningSessions"
      ],
      "Resource": "*"
    }
  ]
}

Exemple 4 : Accès complet à toutes les ressources Connect Health

La politique suivante accorde un accès complet à toutes les ressources Amazon Connect Health.

{
  "Version": "2012-10-17" ,
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "health-agent:*",
      "Resource": "*"
    }
  ]
}

Exemple 5 : Read-only accès avec refus en cas d'actions destructrices

La politique suivante accorde un accès en lecture seule aux domaines et aux agents tout en refusant explicitement les opérations de suppression.

{
  "Version": "2012-10-17" ,
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "health-agent:GetDomain",
        "health-agent:ListAgents",
        "health-agent:GetAgent"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "health-agent:DeleteDomain",
        "health-agent:DeleteAgent"
      ],
      "Resource": "*"
    }
  ]
}

Exemple 6 : Autoriser les utilisateurs IAM à consulter leurs propres autorisations

Cet exemple montre comment créer une politique qui permet aux utilisateurs IAM d’afficher les politiques en ligne et gérées attachées à leur identité d’utilisateur.

{
  "Version": "2012-10-17" ,
  "Statement": [
    {
      "Sid": "ViewOwnUserInfo",
      "Effect": "Allow",
      "Action": [
        "iam:GetUserPolicy",
        "iam:ListGroupsForUser",
        "iam:ListAttachedUserPolicies",
        "iam:ListUserPolicies",
        "iam:GetUser"
      ],
      "Resource": ["arn:aws:iam::*:user/${aws:username}"]
    },
    {
      "Sid": "NavigateInConsole",
      "Effect": "Allow",
      "Action": [
        "iam:GetGroupPolicy",
        "iam:GetPolicyVersion",
        "iam:GetPolicy",
        "iam:ListAttachedGroupPolicies",
        "iam:ListGroupPolicies",
        "iam:ListPolicyVersions",
        "iam:ListPolicies",
        "iam:ListUsers"
      ],
      "Resource": "*"
    }
  ]
}

Rôles de service et politiques de confiance

Amazon Connect Health utilise un rôle de service IAM pour effectuer des actions en votre nom. Chaque composant de service AWS avec lequel Amazon Connect Health interagit fonctionne dans le cadre d'un rôle de service IAM dédié avec une politique de confiance limitée au principal de service spécifique.

L'exemple suivant montre une politique de rôle de service pour Amazon Connect Health qui accorde des autorisations pour la gestion des domaines, de l'intégration et des agents.

{
  "Version": "2012-10-17" ,
  "Statement": [
    {
      "Sid": "DescribeUserWithSourceIdentity",
      "Effect": "Allow",
      "Action": [
        "identitystore:DescribeUser"
      ],
      "Resource": "arn:aws:identitystore:::user/${aws:SourceIdentity}"
    },
    {
      "Sid": "DomainReadAccess",
      "Effect": "Allow",
      "Action": [
        "health-agent:GetDomain"
      ],
      "Resource": "arn:aws:health-agent:<region>:<account-id>:domain/<domain-id>"
    },
    {
      "Sid": "ListOperations",
      "Effect": "Allow",
      "Action": [
        "health-agent:ListIntegrations",
        "health-agent:ListAgents",
        "health-agent:ListAgentVersions"
      ],
      "Resource": "arn:aws:health-agent:<region>:<account-id>:domain/<domain-id>"
    },
    {
      "Sid": "IntegrationManagement",
      "Effect": "Allow",
      "Action": [
        "health-agent:CreateIntegration",
        "health-agent:GetIntegration",
        "health-agent:UpdateIntegration",
        "health-agent:DeleteIntegration"
      ],
      "Resource": [
        "arn:aws:health-agent:<region>:<account-id>:domain/<domain-id>",
        "arn:aws:health-agent:<region>:<account-id>:domain/<domain-id>/integration/*"
      ]
    },
    {
      "Sid": "AgentManagement",
      "Effect": "Allow",
      "Action": [
        "health-agent:CreateAgent",
        "health-agent:UpdateAgent",
        "health-agent:GetAgent",
        "health-agent:PublishAgent",
        "health-agent:DeleteAgent"
      ],
      "Resource": [
        "arn:aws:health-agent:<region>:<account-id>:domain/<domain-id>",
        "arn:aws:health-agent:<region>:<account-id>:domain/<domain-id>/agent/*"
      ]
    }
  ]
}

L'exemple suivant montre une politique de confiance qui permet au directeur du service Amazon Connect Health d'assumer ce rôle.

{
  "Version": "2012-10-17" ,
  "Statement": [
    {
      "Sid": "AllowHealthAgentServicePrincipal",
      "Effect": "Allow",
      "Principal": {
        "Service": "health-agent.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:SetContext",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:health-agent:<region>:<account-id>:domain/<domain-id>/*"
        },
        "StringEquals": {
          "aws:SourceAccount": "<account-id>"
        }
      }
    }
  ]
}

Pour éviter le problème de confusion des adjoints, nous vous recommandons d'utiliser les clés de aws:SourceAccount condition aws:SourceArn et de la politique de confiance. L'ARN source doit être limité au domaine Amazon Connect Health spécifique que le rôle est censé servir.