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.
Autorisations d'accès aux données à l'aide d'Amazon S3 URIs
Vous pouvez accéder aux données du magasin de séquences à l'aide HealthOmics d'opérations d'API ou d'opérations d'API Amazon S3.
Pour HealthOmics l'accès aux API, HealthOmics les autorisations sont gérées par le biais d'une politique IAM. Cependant, S3 Access nécessite deux niveaux de configuration : une autorisation explicite dans la politique d'accès S3 du Store et une politique IAM. Pour en savoir plus sur l'utilisation des politiques IAM avec HealthOmics, consultez la section Rôles de service pour HealthOmics.
Il existe trois manières de partager la capacité de lecture d'objets à l'aide d'Amazon S3 APIs :
-
Partage basé sur des politiques : ce partage nécessite d'activer le principal IAM à la fois dans la politique d'accès S3 et d'écrire une politique IAM et de l'associer au principal IAM. Consultez la rubrique suivante pour plus de détails.
-
Présigné URLs — Vous pouvez également générer une URL pré-signée partageable pour un fichier dans le magasin de séquences. Pour en savoir plus sur la création de présignés URLs à l'aide d'Amazon S3, consultez la section Utilisation de présignés URLs dans la documentation Amazon S3. La politique d'accès S3 du magasin de séquences prend en charge les instructions visant à limiter les capacités des URL présignées.
-
Rôles assumés : créez un rôle dans le compte du propriétaire des données doté d'une politique d'accès permettant aux utilisateurs d'assumer ce rôle.
Partage basé sur des politiques
Si vous accédez aux données du magasin de séquences à l'aide d'une URI S3 directe, HealthOmics fournit des mesures de sécurité renforcées pour la politique d'accès au compartiment S3 associée.
Les règles suivantes s'appliquent aux nouvelles politiques d'accès S3. Pour les politiques existantes, les règles s'appliquent lors de la prochaine mise à jour de la politique :
-
Les politiques d'accès S3 prennent en charge les éléments de politique suivants
-
Version, identifiant, déclaration, side, effet, principal, action, ressource, condition
-
-
Les politiques d'accès S3 prennent en charge les clés de condition suivantes :
-
s3 :ExistingObjectTag/<key>, s3 : préfixe, s3 : version de signature, s3 : TlsVersion
-
Les politiques prennent également en charge aws : PrincipalArn avec les opérateurs de condition suivants : ArnEquals et ArnLike
-
Si vous essayez d'ajouter ou de mettre à jour une politique afin d'inclure un élément ou une condition non pris en charge, le système rejette la demande.
Rubriques
Politique d'accès S3 par défaut
Lorsque vous créez un magasin de séquences, HealthOmics crée une politique d'accès S3 par défaut accordant au compte racine du propriétaire du magasin de données les autorisations suivantes pour tous les objets accessibles du magasin de séquences : S3 : GetObjectGetObjectTagging, S3 et S3 :ListBucket. La politique créée par défaut est la suivante :
Personnalisation de la politique d'accès
Si la politique d'accès S3 est vide, aucun accès S3 n'est autorisé. S'il existe une politique existante et que vous devez supprimer l'accès s3, utilisez-la deleteS3AccessPolicy pour supprimer tous les accès.
Pour ajouter des restrictions au partage ou pour accorder l'accès à d'autres comptes, vous pouvez mettre à jour la politique à l'aide de l'PutS3AccessPolicyAPI. Les mises à jour de la politique ne peuvent pas aller au-delà du préfixe du magasin de séquences ou des actions spécifiées.
Politique IAM
Pour autoriser un utilisateur ou un utilisateur principal IAM à l'aide d'Amazon S3 APIs, en plus de l'autorisation prévue dans la politique d'accès S3, une politique IAM doit être créée et attachée au principal pour accorder l'accès. Une politique autorisant l'accès à l'API Amazon S3 peut être appliquée au niveau du magasin de séquences ou au niveau du jeu de lecture. Au niveau de l'ensemble de lecture, les autorisations peuvent être restreintes soit par le biais du préfixe, soit à l'aide de filtres de balises de ressources pour les modèles d'identification des échantillons ou des sujets.
Si le magasin de séquences utilise une clé gérée par le client (CMK), le principal doit également avoir le droit d'utiliser la clé KMS pour le déchiffrement. Pour plus d'informations, consultez la section Accès KMS entre comptes dans le Guide du AWS Key Management Service développeur.
L'exemple suivant donne à un utilisateur l'accès à un magasin de séquences. Vous pouvez affiner l'accès à l'aide de conditions supplémentaires ou de filtres basés sur les ressources.
Contrôle d’accès basé sur les étiquettes
Pour utiliser le contrôle d'accès basé sur les balises, le magasin de séquences doit d'abord être mis à jour pour propager les clés de balise qui seront utilisées. Cette configuration est définie lors de la création ou de la mise à jour du magasin de séquences. Une fois les balises propagées, les conditions des balises peuvent être utilisées pour ajouter des restrictions supplémentaires. Les restrictions peuvent être placées dans la politique d'accès S3 ou dans la politique IAM. Voici un exemple de politique d'accès S3 basée sur des onglets qui serait définie :
{ "Sid": "tagRestrictedGets", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<target_restricted_account_id>:root" }, "Action": [ "s3:GetObject", "s3:GetObjectTagging" ], "Resource": "arn:aws:s3:us-west-2:222222222222:accesspoint/111111111111-1234567890/object/111111111111/sequenceStore/1234567890/*", "Condition": { "StringEquals": { "s3:ExistingObjectTag/tagKey1": "tagValue1", "s3:ExistingObjectTag/tagKey2": "tagValue2" } } }
Exemple de restriction
Scénario : création d'un partage dans lequel le propriétaire des données peut restreindre la capacité d'un utilisateur à télécharger des données « retirées ».
Dans ce scénario, un propriétaire de données (compte #111111111111) gérait un magasin de données. Ce propriétaire de données partage les données avec un large éventail d'utilisateurs tiers, y compris un chercheur (compte #999999999999). Dans le cadre de la gestion des données, le propriétaire des données reçoit régulièrement des demandes de retrait des données d'un participant. Pour gérer ce retrait, le propriétaire des données restreint d'abord l'accès direct au téléchargement à la réception de la demande et supprime finalement les données selon ses besoins.
Pour répondre à ce besoin, le propriétaire des données met en place un magasin de séquences et chaque ensemble de lecture reçoit une étiquette de « statut » qui sera définie sur « retiré » si la demande de retrait est acceptée. Pour les données dont la balise est définie sur cette valeur, ils veulent s'assurer qu'aucun utilisateur ne peut exécuter « GetObject » sur ce fichier. Pour effectuer cette configuration, le propriétaire des données doit s'assurer que deux étapes ont été suivies.
Étape 1. Pour le magasin de séquences, assurez-vous que la balise d'état est mise à jour pour être propagée. Cela se fait en ajoutant la touche « status » dans le champ propogatedSetLevelTags lors de l'appel createSequenceStore ou updateSequenceStore.
Étape 2. Mettez à jour la politique d'accès s3 du magasin pour restreindre GetObject aux objets dont la balise d'état est définie sur « retiré ». Cela se fait en mettant à jour la politique d'accès aux boutiques à l'aide de l'PutS3AccesPolicyAPI. La politique suivante permettrait aux clients de toujours voir les fichiers retirés lorsqu'ils mettent en vente des objets, mais les empêcherait d'y accéder :
Déclaration 1 (restrictedGetWithdrawal) : Le compte 999999999999 ne peut pas récupérer les objets retirés.
Déclaration 2 (ownerGetAll) : Le compte 111111111111, propriétaire des données, peut récupérer tous les objets, y compris les objets retirés.
Déclaration 3 (everyoneListAll) : Tous les comptes partagés, 111111111111 et 999999999999, peuvent exécuter l'opération sur l'ensemble du préfixe. ListBucket
