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.
# Meilleures pratiques, considérations et limites en matière de formation des lacs
Utilisez cette section pour trouver rapidement les meilleures pratiques, les considérations et les limites qu'elle contient AWS Lake Formation.
Consultez la section [Quotas de service](https://docs.aws.amazon.com/general/latest/gr/lake-formation.html#limits_lake-formation) pour connaître le nombre maximal de ressources de service ou d'opérations pour votre Compte AWS.
**Topics**
+ [Meilleures pratiques et considérations relatives au partage de données entre comptes](cross-account-notes.md)
+ [Limitations des rôles liés aux services](service-linked-role-limitations.md)
+ [Limites d'accès aux données entre régions](x-region-considerations.md)
+ [Considérations et limites relatives aux affichages du catalogue de données](views-notes.md)
+ [Limites du filtrage des données](data-filtering-notes.md)
+ [Considérations et limites relatives au mode d'accès hybride](notes-hybrid.md)
+ [Limites liées à l'intégration des données de l'entrepôt de données Amazon Redshift dans le AWS Glue Data Catalog](notes-ns-catalog.md)
+ [Limites d'intégration du catalogue S3 Tables](notes-s3-catalog.md)
+ [Considérations et limites relatives au partage des données du magasin de métadonnées Hive](notes-hms.md)
+ [Limites du partage de données Amazon Redshift](notes-rs-datashare.md)
+ [Limites de l'intégration d'IAM Identity Center](identity-center-lf-notes.md)
+ [Meilleures pratiques et considérations relatives au contrôle d'accès basé sur les balises Lake Formation](lf-tag-considerations.md)
+ [Considérations relatives au contrôle d'accès basé sur les attributs, limites et régions prises en charge](abac-considerations.md)
# Meilleures pratiques et considérations relatives au partage de données entre comptes
Les fonctionnalités multi-comptes de Lake Formation permettent aux utilisateurs de partager en toute sécurité des lacs de données distribués entre plusieurs AWS organisations ou directement avec les responsables IAM d'un autre compte Comptes AWS, offrant ainsi un accès détaillé aux métadonnées du catalogue de données et aux données sous-jacentes.
Tenez compte des meilleures pratiques suivantes lorsque vous utilisez le partage de données entre comptes de Lake Formation :
+ Il n'y a pas de limite au nombre d'autorisations de Lake Formation que vous pouvez accorder aux directeurs d'école pour votre propre AWS compte. Cependant, Lake Formation utilise AWS Resource Access Manager (AWS RAM) la capacité pour les subventions entre comptes que votre compte peut accorder avec la méthode de ressource nommée. Pour optimiser la AWS RAM capacité, suivez les meilleures pratiques suivantes pour la méthode de ressource nommée :
+ Utilisez le nouveau mode de subvention entre comptes (**version 3** et supérieure, sous **Paramètres des versions entre comptes**) pour partager une ressource avec un externe Compte AWS. Pour de plus amples informations, veuillez consulter [Mise à jour des paramètres de version de partage de données entre comptes](optimize-ram.md).
+ Organisez AWS les comptes en organisations et accordez des autorisations à des organisations ou à des unités organisationnelles. Une subvention accordée à une organisation ou à une unité organisationnelle est considérée comme une subvention.
L'octroi à des organisations ou à des unités organisationnelles élimine également le besoin d'accepter une AWS Resource Access Manager (AWS RAM) invitation à partager des ressources pour la subvention. Pour de plus amples informations, veuillez consulter [Accès aux tables et aux bases de données partagées du catalogue de données et affichage](viewing-shared-resources.md).
+ Au lieu d'accorder des autorisations sur de nombreuses tables individuelles d'une base de données, utilisez le caractère générique spécial **Toutes les tables** pour accorder des autorisations sur toutes les tables de la base de données. L'octroi d'une subvention sur **toutes les tables** est considéré comme une subvention unique. Pour de plus amples informations, veuillez consulter [Octroi d'autorisations sur les ressources du catalogue de données](granting-catalog-permissions.md).
**Note**
Pour plus d'informations sur la demande d'une limite plus élevée pour le nombre de partages de ressources dans AWS RAM, voir les [quotas de AWS service](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) dans le *Références générales AWS*.
+ Vous devez créer un lien de ressource vers une base de données partagée pour que cette base de données apparaisse dans les éditeurs de requêtes Amazon Redshift Spectrum Amazon Athena et Amazon Redshift. De même, pour pouvoir interroger des tables partagées à l'aide d'Athena et Redshift Spectrum, vous devez créer des liens de ressources vers les tables. Les liens vers les ressources apparaissent ensuite dans la liste des tables des éditeurs de requêtes.
Au lieu de créer des liens de ressources pour de nombreuses tables individuelles à des fins d'interrogation, vous pouvez utiliser le caractère générique **Toutes les tables** pour accorder des autorisations sur toutes les tables d'une base de données. Ensuite, lorsque vous créez un lien de ressource pour cette base de données et que vous sélectionnez ce lien de ressource de base de données dans l'éditeur de requêtes, vous aurez accès à toutes les tables de cette base de données pour votre requête. Pour de plus amples informations, veuillez consulter [Création de liens vers des ressources](creating-resource-links.md).
+ Lorsque vous partagez des ressources directement avec les principaux d'un autre compte, le principal IAM du compte destinataire n'est peut-être pas autorisé à créer des liens vers des ressources pour interroger les tables partagées à l'aide d'Athena et d'Amazon Redshift Spectrum. Au lieu de créer un lien de ressource pour chaque table partagée, l'administrateur du lac de données peut créer une base de données fictive et accorder des `CREATE_TABLE` autorisations au `ALLIAMPrincipal` groupe. Tous les principaux IAM du compte destinataire peuvent ensuite créer des liens de ressources dans la base de données d'espaces réservés et commencer à interroger les tables partagées.
Consultez l'exemple de commande CLI pour accorder des autorisations `ALLIAMPrincipals` d'entrée[Octroi d’autorisations de base de données via la méthode de ressource nommée](granting-database-permissions.md).
+ Lorsque des autorisations entre comptes sont accordées directement à un mandant, seul le bénéficiaire de la subvention peut consulter ces autorisations. L'administrateur du lac de données du AWS compte du bénéficiaire ne peut pas consulter ces subventions directes.
+ Athena et Redshift Spectrum prennent en charge le contrôle d'accès au niveau des colonnes, mais uniquement pour l'inclusion, et non pour l'exclusion. Le contrôle d'accès au niveau des colonnes n'est pas pris en charge dans les tâches AWS Glue ETL.
+ Lorsqu'une ressource est partagée avec votre AWS compte, vous pouvez accorder des autorisations sur cette ressource uniquement aux utilisateurs de votre compte. Vous ne pouvez pas accorder d'autorisations sur la ressource à d'autres AWS comptes, à des organisations (pas même à votre propre organisation) ou au `IAMAllowedPrincipals` groupe.
+ Vous ne pouvez pas accorder `DROP` ou attribuer une `Super` base de données à un compte externe.
+ Révoquez les autorisations entre comptes avant de supprimer une base de données ou une table. Sinon, vous devez supprimer les partages de ressources orphelins dans AWS Resource Access Manager.
**Consultez aussi**
[Meilleures pratiques et considérations relatives au contrôle d'accès basé sur les balises Lake Formation](lf-tag-considerations.md)
[`CREATE_TABLE`](lf-permissions-reference.md#perm-create-table)dans le [Référence des autorisations de Lake Formation](lf-permissions-reference.md) pour plus de règles et de limitations d'accès entre comptes.
# Limitations des rôles liés aux services
Un rôle lié à un service est un type spécial de rôle IAM directement lié à. AWS Lake Formation Ce rôle possède des autorisations prédéfinies qui permettent à Lake Formation d'effectuer des actions en votre nom sur l'ensemble AWS des services.
Les limites suivantes s'appliquent lors de l'utilisation d'un rôle lié à un service (SLR) pour enregistrer des emplacements de données auprès de Lake Formation.
+ Vous ne pouvez pas modifier les politiques de rôle liées aux services une fois créées.
+ Un rôle lié à un service ne prend pas en charge le partage crypté des ressources de catalogue entre les comptes. Les ressources chiffrées nécessitent des autorisations AWS KMS clés spécifiques. Les rôles liés à un service sont dotés d'autorisations prédéfinies qui n'incluent pas la possibilité d'utiliser des ressources de catalogue chiffrées sur plusieurs comptes.
+ Lorsque vous enregistrez plusieurs sites Amazon S3, l'utilisation d'un rôle lié à un service peut vous amener à dépasser rapidement les limites de votre politique IAM. Cela se produit parce qu'avec les rôles liés à un service, elle AWS écrit la politique pour vous, et elle s'incrémente sous la forme d'un gros bloc qui inclut toutes vos inscriptions. Vous pouvez rédiger des politiques gérées par le client de manière plus efficace, répartir les autorisations entre plusieurs politiques ou utiliser différents rôles pour différentes régions.
+ Amazon EMR sur EC2 ne peut pas accéder aux données. Vous enregistrez des emplacements de données avec des rôles liés à un service.
+ Les opérations de rôle liées au service contournent vos politiques de contrôle des AWS services.
+ Lorsque vous enregistrez des emplacements de données avec un rôle lié à un service, les politiques IAM sont mises à jour de manière cohérente. Pour plus d'informations, consultez la documentation relative à la [résolution des problèmes liés à l'IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot.html#troubleshoot_general_eventual-consistency) dans le guide de l'utilisateur d'IAM.
+ Vous ne pouvez pas définir `SET_CONTEXT = TRUE` les paramètres du lac de données de Lake Formation lorsque vous utilisez des rôles liés à un service, et vous utilisez IAM Identity Center. La raison en est que les rôles liés à un service sont soumis à des politiques de confiance immuables incompatibles avec la propagation d'identité fiable nécessaire à l'`SetContext`audit auprès des principaux IAM Identity Center.
# Limites d'accès aux données entre régions
Lake Formation permet d'interroger les tables du catalogue de données. Régions AWS Vous pouvez accéder aux données d'une région depuis d'autres régions à l'aide Amazon Athena d'Amazon EMR et d' AWS Glue ETL en créant des liens de ressources dans d'autres régions pointant vers les bases de données et les tables sources. Grâce à l'accès aux tables entre régions, vous pouvez accéder aux données entre les régions sans copier les données sous-jacentes ou les métadonnées dans le catalogue de données.
Les restrictions suivantes s'appliquent à l'accès aux tables entre régions.
+ Lake Formation ne permet pas d'interroger les tables du catalogue de données d'une autre région à l'aide d'Amazon Redshift Spectrum.
+ Dans la console Lake Formation, les vues de base de données et de table n'affichent pas les noms des bases de données/tables de la région source.
+ Pour afficher la liste des tables d'une base de données partagée d'une autre région, vous devez d'abord créer un lien de ressource vers la base de données partagée, puis sélectionner le lien de ressource et choisir **Afficher les tables**.
+ Lake Formation ne prend pas en charge les appels de liens de ressources interrégionaux effectués par les utilisateurs de SAML.
+ La fonctionnalité interrégionale de Lake Formation n'implique pas de frais supplémentaires pour les transferts de données.
# Considérations et limites relatives aux affichages du catalogue de données
Les considérations et limites suivantes s'appliquent aux vues du catalogue de données.
+ Vous ne pouvez pas créer une vue du catalogue de données à partir de la console Lake Formation. Vous pouvez créer des vues à l'aide du SDK AWS CLI ou.
+ Vous pouvez créer des vues de catalogue de données à partir de 10 tables. C'est une limite stricte. Les tables de référence sous-jacentes d'une vue peuvent appartenir à la même base de données ou à différentes bases de données au sein du même AWS compte.
+ Pour d'autres considérations et limitations spécifiques à la création de vues de catalogue de données à l'aide de Redshift, consultez la section [Considérations et limites relatives aux vues de catalogue de données](https://docs.aws.amazon.com/redshift/latest/dg/data-catalog-views-overview.html#data-catalog-views-considerations) dans le guide du développeur de base de données Amazon Redshift. Pour Athena, consultez la section [Considérations et limites relatives aux vues du catalogue de données](https://docs.aws.amazon.com/athena/latest/ug/views-glue.html#views-glue-limitations) dans le guide de l'utilisateur d'Amazon Athena.
+ Vous pouvez créer des vues de catalogue de données sur des tables enregistrées auprès de Lake Formation à la fois en mode d'accès hybride et en mode Lake Formation.
Lorsque vous utilisez des vues du catalogue de données avec le mode d'accès hybride Lake Formation, il est recommandé de s'assurer que les principaux consommateurs de vues sont autorisés à accéder aux autorisations Lake Formation pour les tables de base référencées dans la vue sans accorder d'accès. Cela garantit que les tables de base ne seront pas révélées aux consommateurs via les autorisations AWS Glue IAM.
+ Il n'existe aucune restriction quant à la version de partage entre comptes pour partager des vues.
+ Les vues sont versionnées comme les tables du catalogue de données, lorsque vous utilisez l'`ALTER VIEW`instruction pour un dialecte de vue déjà créé. Vous ne pouvez pas revenir à une vue précédente car la version de la vue change en fonction des modifications des données sous-jacentes. Vous pouvez supprimer une version d'affichage et elle utilisera par défaut la version la plus récente disponible. Lorsque vous modifiez la version de vue, assurez-vous que vos données sont synchronisées avec le schéma de version de vue sélectionné.
+ Aucun nouveau catalogue de données APIs n'est introduit. Les existants `CreateTable``UpdateTable`, `DeleteTable` et `GetTable` APIs sont mis à jour.
+ Amazon Redshift crée toujours des vues avec des colonnes varchar à partir de tables contenant des chaînes. Vous devez convertir les colonnes de chaîne en varchar avec une longueur explicite lorsque vous ajoutez des dialectes provenant d'autres moteurs.
+ L'octroi d'autorisations de lac de données au `All tables` sein d'une base de données permettra au bénéficiaire de disposer d'autorisations sur toutes les tables et vues de la base de données.
+ Vous ne pouvez pas créer de vues :
+ Cela fait référence à d'autres points de vue.
+ Lorsque la table de référence est un lien vers une ressource.
+ Lorsque la table de référence se trouve dans un autre compte.
+ À partir de métastores Hive externes.
+ Les rôles de définition entre comptes ne sont pas pris en charge pour les vues Redshift Spectrum Dialect.
+ Les liens de ressources pour le dialecte Athena dans l'éditeur de requêtes Athena ne sont pas pris en charge. Pour utiliser des rôles de définition entre comptes pour le dialecte Athena, ajoutez le compte hébergeant les tables de base en tant que source de données dans Athena.
# Limites du filtrage des données
Lorsque vous accordez des autorisations à Lake Formation sur une table du catalogue de données, vous pouvez inclure des spécifications de filtrage des données afin de restreindre l'accès à certaines données dans les résultats des requêtes et les moteurs intégrés à Lake Formation. Lake Formation utilise le filtrage des données pour garantir la sécurité au niveau des colonnes, au niveau des lignes et au niveau des cellules. Vous pouvez définir et appliquer des filtres de données sur des colonnes imbriquées si vos données sources contiennent des structures imbriquées.
## Remarques et restrictions relatives au filtrage au niveau des colonnes
Il existe trois méthodes pour définir le filtrage des colonnes :
+ En utilisant des filtres de données
+ En utilisant un filtrage par colonne simple ou un filtrage par colonne imbriqué.
+ En utilisant TAGs.
Le filtrage simple des colonnes indique simplement une liste de colonnes à inclure ou à exclure. La console Lake Formation, l'API et l'API prennent en AWS CLI charge un filtrage simple par colonne. Pour obtenir un exemple, consultez [Grant with Simple Column Filtering](granting-table-permissions.md#simple-column-filter-example).
Les remarques et restrictions suivantes s'appliquent au filtrage des colonnes :
+ AWS Glue La version 5.0 ou supérieure prend en charge le contrôle d'accès précis via Lake Formation uniquement pour les tables Apache Hive et Apache Iceberg.
+ Pour octroyer `SELECT` avec l'option d'autorisation et le filtrage des colonnes, vous devez utiliser une liste d'inclusion et non une liste d'exclusion. Sans l'option d'autorisation, vous pouvez utiliser des listes d'inclusion ou d'exclusion.
+ Pour accorder une autorisation `SELECT` sur une table avec filtrage par colonne, vous devez avoir été autorisé `SELECT` sur la table avec l'option d'attribution et sans aucune restriction de ligne. Vous devez avoir accès à toutes les lignes.
+ Si vous accordez une subvention `SELECT` avec l'option d'attribution et le filtrage des colonnes à un principal de votre compte, ce principal doit spécifier le filtrage des colonnes pour les mêmes colonnes ou pour un sous-ensemble des colonnes accordées lorsqu'il octroie à un autre principal. Si vous accordez `SELECT` à un compte externe à l'aide de l'option d'attribution et du filtrage des colonnes, l'administrateur du lac de données du compte externe peut accorder une autorisation `SELECT` sur toutes les colonnes à un autre principal de son compte. Cependant, même dans toutes `SELECT` les colonnes, ce principal n'aura de visibilité que sur les colonnes accordées au compte externe.
+ Vous ne pouvez pas appliquer le filtrage des colonnes aux clés de partition.
+ Un principal `SELECT` autorisé autorisé à accéder à un sous-ensemble de colonnes d'une table ne peut pas obtenir l'`INSERT`autorisation `ALTER``DROP`,`DELETE`, ou sur cette table. Pour un directeur disposant de l'`INSERT`autorisation `ALTER``DROP`,`DELETE`, ou sur une table, si vous accordez l'`SELECT`autorisation avec filtrage par colonne, cela n'a aucun effet.
Les remarques et restrictions suivantes s'appliquent au filtrage des colonnes imbriquées :
+ Vous pouvez inclure ou exclure cinq niveaux de champs imbriqués dans un filtre de données.
**Example**
Col1.Col1\$11.Col1\$11\$11.Col1\$11\$11\$11.Col1\$11\$11\$11\$11\$11
+ Vous ne pouvez pas appliquer de filtrage de colonnes à des champs imbriqués dans des colonnes de partition.
+ Si le schéma de votre table contient un nom de colonne de premier niveau (« client »). » adresse ») qui a le même modèle de représentation de champs imbriqués dans un filtre de données (une colonne imbriquée avec un nom de colonne de premier niveau `customer` et un nom de champ imbriqué `address` est spécifiée comme `"customer"."address"` dans un filtre de données), vous ne pouvez pas spécifier explicitement l'accès à une colonne de niveau supérieur ou à un champ imbriqué car les deux sont représentés selon le même modèle dans les listes. inclusion/exclusion Cela est ambigu, et Lake Formation ne peut pas être résolu si vous spécifiez la colonne de niveau supérieur ou le champ imbriqué.
+ Si le nom d'une colonne ou d'un champ imbriqué de niveau supérieur contient un guillemet double, vous devez inclure un deuxième guillemet double lorsque vous spécifiez l'accès à un champ imbriqué dans la liste d'inclusion et d'exclusion d'un filtre de cellules de données.
**Example**
Exemple de nom de colonne imbriqué entre guillemets : `a.b.double"quote`
**Example**
Exemple de représentation de colonnes imbriquées dans un filtre de données : ` "a"."b"."double""quote"`
## Limites du filtrage au niveau des cellules
Tenez compte des remarques et restrictions suivantes concernant le filtrage au niveau des lignes et au niveau des cellules.
+ La sécurité au niveau des cellules n'est pas prise en charge sur les colonnes, les vues et les liens de ressources imbriqués.
+ Toutes les expressions prises en charge sur les colonnes de niveau supérieur sont également prises en charge sur les colonnes imbriquées. Cependant, les champs imbriqués sous les colonnes de partition **ne doivent PAS** être référencés lors de la définition d'expressions imbriquées au niveau des lignes.
+ La sécurité au niveau des cellules est disponible dans toutes les régions lorsque vous utilisez le moteur Athena version 3 ou Amazon Redshift Spectrum. Pour les autres services, la sécurité au niveau des cellules n'est disponible que dans les régions mentionnées sur le. [Régions prises en charge](supported-regions.md)
+ Les instructions `SELECT INTO` ne sont pas prises en charge.
+ Les types `array` de `map` données et ne sont pas pris en charge dans les expressions de filtre de ligne. Le type `struct` de données est pris en charge.
+ Il n'y a pas de limite au nombre de filtres de données pouvant être définis sur une table, mais il existe une limite de 100 filtres de données pour un seul principal sur une table.
+ Pour appliquer un filtre de données avec une expression de filtre de ligne, vous devez avoir `SELECT` l'option grant sur toutes les colonnes du tableau. Cette restriction ne s'applique pas aux administrateurs des comptes externes lorsque la subvention a été accordée au compte externe.
+ Si un directeur est membre d'un groupe et que le principal et le groupe reçoivent des autorisations sur un sous-ensemble de lignes, les autorisations de ligne effectives du principal sont l'union des autorisations du principal et des autorisations du groupe.
+ Les noms de colonnes suivants sont restreints dans un tableau pour le filtrage au niveau des lignes et au niveau des cellules :
+ ctid
+ oid
+ xmin
+ cmin
+ xmax
+ cmax
+ tabloïd
+ insérez un identifiant
+ supprimer exid
+ importoïde
+ identifiant unique du chat rouge
+ Si vous appliquez l'expression de filtre toutes les lignes sur un tableau en même temps que d'autres expressions de filtre contenant des prédicats, l'expression de toutes les lignes prévaudra sur toutes les autres expressions de filtre.
+ Lorsque des autorisations sur un sous-ensemble de lignes sont accordées à un AWS compte externe et que l'administrateur du lac de données du compte externe accorde ces autorisations au principal de ce compte, le prédicat de filtre effectif du principal est l'intersection du prédicat du compte et de tout prédicat directement accordé au principal.
Par exemple, si le compte dispose d'autorisations de ligne avec le prédicat `dept='hr'` et que le principal a été autorisé séparément pour`country='us'`, le principal n'a accès qu'aux lignes avec `dept='hr'` et`country='us'`.
Pour plus d'informations sur le filtrage au niveau des cellules, consultez. [Filtrage des données et sécurité au niveau des cellules dans Lake Formation](data-filtering.md)
Pour connaître les points à prendre en compte et les limites lors de l'interrogation de tables à l'aide d'Amazon Redshift Spectrum avec des politiques de sécurité au niveau des lignes, consultez la section [Considérations et limites relatives à l'utilisation des politiques RLS dans le](https://docs.aws.amazon.com/redshift/latest/dg/t_rls_usage.html) manuel Amazon Redshift Database Developer Guide.
# Considérations et limites relatives au mode d'accès hybride
Le mode d'accès hybride offre la flexibilité d'activer de manière sélective les autorisations de Lake Formation pour les bases de données et les tables de votre AWS Glue Data Catalog.
Avec le mode d'accès hybride, vous disposez désormais d'un chemin incrémentiel qui vous permet de définir les autorisations de Lake Formation pour un ensemble spécifique d'utilisateurs sans interrompre les politiques d'autorisation des autres utilisateurs ou charges de travail existants.
Les considérations et limitations suivantes s'appliquent au mode d'accès hybride.
**Limitations**
+ **Mettre à jour l'enregistrement d'une position Amazon S3** : vous ne pouvez pas modifier les paramètres d'une position enregistrée auprès de Lake Formation à l'aide d'un rôle lié à un service.
+ **Option d'activation lors de l'utilisation des balises LF** — Lorsque vous pouvez accorder des autorisations à Lake Formation à l'aide de balises LF, vous pouvez choisir des principes pour appliquer les autorisations de Lake Formation par étapes successives en choisissant des bases de données et des tables auxquelles des balises LF sont attachées.
+ **Accès en mode d'accès hybride** — L'accès au mode d'accès hybride dans Lake Formation est limité aux utilisateurs disposant d'autorisations d'administrateur de lac de données ou d'administrateur en lecture seule.
+ **Principaux d'adhésion** — Actuellement, seul un rôle d'administrateur de lac de données peut attribuer des principes aux ressources.
+ **Activer toutes les tables d'une base de données** : dans le cas des autorisations entre comptes, lorsque vous accordez des autorisations et que vous activez toutes les tables d'une base de données, vous devez également activer la base de données pour que les autorisations fonctionnent.
**Considérations**
+ **Mise à jour de l'emplacement Amazon S3 enregistré auprès de Lake Formation en mode d'accès hybride** — Nous déconseillons de convertir un emplacement de données Amazon S3 déjà enregistré auprès de Lake Formation en mode d'accès hybride, bien que cela soit possible.
+ **Comportements de l'API lorsqu'un emplacement de données est enregistré en mode d'accès hybride**
+ CreateTable — L'emplacement est considéré comme enregistré auprès de Lake Formation, quels que soient le drapeau du mode d'accès hybride et le statut d'inscription. L'utilisateur a donc besoin de l'autorisation de localisation des données pour créer une table.
+ CreatePartition/BatchCreatePartitions/UpdatePartitions(lorsque l'emplacement de la partition est mis à jour pour pointer vers l'emplacement enregistré auprès de l'hybride) — L'emplacement Amazon S3 est considéré comme enregistré auprès de Lake Formation, quels que soient l'indicateur du mode d'accès hybride et le statut d'option d'inscription. L'utilisateur a donc besoin de l'autorisation de localisation des données pour créer ou mettre à jour une base de données.
+ CreateDatabase/UpdateDatabase (lorsque l'emplacement de la base de données est mis à jour pour pointer vers l'emplacement enregistré en mode d'accès hybride) — L'emplacement est considéré comme enregistré auprès de Lake Formation, quels que soient le drapeau du mode d'accès hybride et le statut d'option d'inscription. L'utilisateur a donc besoin de l'autorisation de localisation des données pour créer ou mettre à jour une base de données.
+ UpdateTable (lorsqu'un emplacement de table est mis à jour pour pointer vers l'emplacement enregistré en mode d'accès hybride) — L'emplacement est considéré comme enregistré auprès de Lake Formation, quels que soient le drapeau du mode d'accès hybride et le statut d'option d'inscription. L'utilisateur a donc besoin d'une autorisation de localisation des données pour mettre à jour le tableau. Si l'emplacement de la table n'est pas mis à jour ou s'il pointe vers un emplacement qui n'est pas enregistré auprès de Lake Formation, l'utilisateur n'a pas besoin d'autorisation de localisation des données pour mettre à jour la table.
# Limites liées à l'intégration des données de l'entrepôt de données Amazon Redshift dans le AWS Glue Data Catalog
Vous pouvez cataloguer et gérer l'accès aux données analytiques dans les entrepôts de données Amazon Redshift à l'aide du. AWS Glue Data Catalog Les limites suivantes s'appliquent :
+ Le partage entre comptes n'est pas pris en charge au niveau du catalogue fédéré. Cependant, vous pouvez partager des bases de données et des tables individuelles à partir d'un catalogue fédéré entre Compte AWS nous.
+ Vous devez disposer des **paramètres de version inter-comptes** version 4 ou supérieure pour partager des bases de données ou des tables dans le catalogue fédéré entre Compte AWS s.
+ Le catalogue de données prend uniquement en charge la création de catalogues de haut niveau.
+ Vous pouvez uniquement mettre à jour la description des catalogues dans le Redshift Managed Storage (RMS).
+ La configuration d'autorisations sur les catalogues fédérés ainsi que sur les bases de données et les tables du catalogue fédéré à `IAMAllowedPrincipals` regrouper n'est pas prise en charge.
+ Les opérations DDL (Data Definition Language) sur le catalogue à partir de moteurs tels qu'Athena, Amazon EMR Spark ou d'autres, y compris la définition des configurations du catalogue, ne sont pas prises en charge.
+ L'exécution d'opérations DDL sur des tables RMS à l'aide d'Athena n'est pas prise en charge.
+ La création de vues matérialisées n'est pas prise en charge, que ce soit via Athena, Apache Spark, AWS Glue Data Catalog le client Amazon Redshift ou Amazon Redshift.
+ Athena ne prend pas en charge une expérience multi-catalogues. Il ne peut se connecter qu'à un seul catalogue spécifique à la fois. Athena ne peut pas accéder à plusieurs catalogues ou les interroger simultanément.
+ Les opérations de balisage et de branchement sur les tables Iceberg via Athena et Amazon Redshift ne sont pas prises en charge.
+ Le voyage dans le temps sur les tables RMS n'est pas pris en charge.
+ Les catalogues multiniveaux avec des tables de lacs de données ne sont pas pris en charge. Toutes les données stockées dans Amazon S3 destinées à être utilisées avec les tables de lacs de données doivent résider dans la version par défaut AWS Glue Data Catalog et ne peuvent pas être organisées dans des catalogues à plusieurs niveaux.
+ Dans Amazon Redshift, les partages de données ne sont pas ajoutés à l'espace de noms enregistré. Les clusters et les espaces de noms sont synonymes. Une fois que vous avez publié un cluster sur le AWS Glue Data Catalog, vous ne pouvez pas ajouter de nouvelles données.
+ Amazon EMR sur EC2 ne prend pas en charge la jonction entre les tables RMS et les tables Amazon S3. Seul EMR Serverless prend en charge cette fonctionnalité.
+ Les schémas et tables externes ne sont pas pris en charge.
+ Les tables RMS ne sont accessibles que depuis le point de terminaison de l'extension dans le catalogue REST d' AWS Glue Iceberg.
+ Les tables Hive ne sont pas accessibles depuis des moteurs tiers connectés au catalogue REST d' AWS Glue Iceberg.
+ Le niveau d'isolation read\$1committed sur les tables RMS via Spark sera pris en charge.
+ Les noms des bases de données Redshift sont traités sans distinction majuscules/majuscules AWS Glue Data Catalog, limités à 128 caractères, et peuvent être alphanumériques avec des tirets (-) et des traits de soulignement (\$1).
+ Les noms de catalogue ne distinguent pas les majuscules des minuscules, sont limités à 50 caractères et peuvent être alphanumériques avec des tirets (-) et des traits de soulignement (\$1).
+ Amazon Redshift ne prend pas en charge l'utilisation des commandes GRANT et REVOKE de style Lake Formation SQL pour gérer les autorisations d'accès sur les tables publiées sur le. AWS Glue Data Catalog
+ Les politiques de sécurité au niveau des lignes et de masquage dynamique des données associées au cluster Amazon Redshift producteur (source) ne seront pas appliquées. Au lieu de cela, les autorisations d'accès définies dans Lake Formation seront appliquées aux données partagées.
+ L'exécution d'opérations en langage de définition de données (DDL) et en langage de manipulation de données (DML) sur les liens de table n'est pas prise en charge.
+ Si les mots clés réservés ne sont pas correctement échappés, cela entraînera des échecs ou des erreurs.
+ Le chiffrement des données dans les scénarios à catalogues multiples n'est pas pris en charge.
# Limites d'intégration du catalogue S3 Tables
Amazon S3 Tables s'intègre à AWS Glue Data Catalog (Data Catalog) et enregistre le catalogue en tant que localisation de données de Lake Formation. Vous pouvez configurer cet enregistrement depuis la console Lake Formation ou en utilisant le service APIs.
**Note**
Si vous avez une politique basée sur les ressources IAM ou S3 Tables qui restreint les utilisateurs IAM et les rôles IAM en fonction des balises principales, vous devez associer les mêmes balises principales au rôle IAM que Lake Formation utilise pour accéder à vos données S3 (par exemple LakeFormationDataAccessRole,) et accorder à ce rôle les autorisations nécessaires. Cela est nécessaire pour que votre politique de contrôle d'accès basée sur des balises fonctionne correctement avec votre intégration d'analyse S3 Tables.
Les limites suivantes s'appliquent à l'intégration du catalogue de tables S3 au catalogue de données et à Lake Formation :
+ AWS Glue et Lake Formation ne prennent pas en charge les noms de colonnes mixtes et convertissent tous les noms de colonnes en minuscules. Vous devez vérifier que les noms des colonnes des tables sont uniques lorsqu'ils sont convertis en minuscules. Utiliser `customer_id` au lieu de`customerId`. L'utilisation de noms de colonnes en majuscules et minuscules n'était prise en charge que lors de la version préliminaire.
+ L' CreateCatalog API ne peut pas créer de compartiments de tables dans Amazon S3.
+ L' SearchTables API ne peut pas effectuer de recherche dans les tables S3.
# Considérations et limites relatives au partage des données du magasin de métadonnées Hive
Grâce à la fédération des AWS Glue Data Catalog métadonnées (fédération du catalogue de données), vous pouvez connecter le catalogue de données à des métastores externes qui stockent les métadonnées de vos données Amazon S3 et gérer en toute sécurité les autorisations d'accès aux données à l'aide de. AWS Lake Formation
Les considérations et limitations suivantes s'appliquent aux bases de données fédérées créées à partir de bases de données Hive :
**Considérations**
+ **AWS SAM support des applications** : vous êtes responsable de la disponibilité des ressources de l'application AWS SAM déployée (Amazon API Gateway et de la fonction Lambda). Assurez-vous que la connexion entre le métastore AWS Glue Data Catalog et le métastore Hive fonctionne lorsque les utilisateurs exécutent des requêtes.
+ **Exigence de version du métastore Hive** — Vous ne pouvez créer des bases de données fédérées qu'à l'aide d'Apache Hive version 3 ou supérieure.
+ **Exigence de base de données mappée** — Chaque base de données Hive doit être mappée à une nouvelle base de données dans Lake Formation.
+ **Support de fédération au niveau de la base** de données : vous pouvez vous connecter au métastore Hive uniquement au niveau de la base de données.
+ **Autorisations sur les bases de données fédérées** : les autorisations appliquées à une base de données fédérée ou aux tables d'une base de données fédérée sont conservées même lorsqu'une table source ou une base de données est supprimée. Lorsque la base de données ou la table source est recréée, il n'est pas nécessaire de réoctroyer les autorisations. Lorsqu'une table fédérée dotée d'autorisations Lake Formation est supprimée à la source, les autorisations Lake Formation sont toujours visibles et vous pouvez les révoquer si nécessaire.
Si un utilisateur supprime une base de données fédérée, toutes les autorisations correspondantes sont perdues. La recréation de la même base de données portant le même nom ne permet pas de récupérer les autorisations de Lake Formation. Les utilisateurs devront à nouveau configurer de nouvelles autorisations.
+ **IAMAllowedAutorisations de groupe principales sur les** bases de données fédérées — Sur la base de cela`DataLakeSettings`, Lake Formation peut attribuer des autorisations à toutes les bases de données et tables à un groupe virtuel nommé`IAMAllowedPrincipal`. Il `IAMAllowedPrincipal` fait référence à tous les principaux IAM qui ont accès aux ressources du catalogue de données par le biais des politiques principales IAM et AWS Glue des politiques de ressources. Si ces autorisations existent sur une base de données ou une table, tous les principaux ont accès à la base de données ou à la table.
Cependant, Lake Formation n'autorise pas `IAMAllowedPrincipal` les autorisations sur les tables des bases de données fédérées. Lorsque vous créez des bases de données fédérées, assurez-vous de transmettre le `CreateTableDefaultPermissions` paramètre sous forme de liste vide.
Pour de plus amples informations, veuillez consulter [Modification des paramètres par défaut de votre lac de données](change-settings.md).
+ **Joindre des tables dans des requêtes** : vous pouvez joindre des tables de métastore Hive à des tables natives de Data Catalog pour exécuter des requêtes.
**Limitations**
+ **Limitation de synchronisation des métadonnées entre le métastore AWS Glue Data Catalog et le métastore Hive** — Après avoir établi la connexion au métastore Hive, vous devez créer une base de données fédérée pour synchroniser les métadonnées du métastore Hive avec le. AWS Glue Data Catalog Les tables de la base de données fédérée sont synchronisées au moment de l'exécution lorsque les utilisateurs exécutent des requêtes.
+ **Limitation relative à la création de nouvelles tables dans une base de données fédérée** : vous ne pourrez pas créer de nouvelles tables dans des bases de données fédérées.
+ **Limitation des autorisations relatives aux données** : le support pour les autorisations sur les vues tabulaires du métastore Hive n'est pas disponible.
# Limites du partage de données Amazon Redshift
AWS Lake Formation vous permet de gérer en toute sécurité les données d'un partage de données d'Amazon Redshift. Amazon Redshift est un service d'entrepôt de données entièrement géré de plusieurs pétaoctets dans le cloud. AWS Grâce à la fonctionnalité de partage de données, Amazon Redshift vous permet de partager des données entre différentes entités. Comptes AWS Pour plus d'informations sur le partage de données Amazon Redshift, consultez [Présentation du partage de données dans Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/data_sharing_intro.html).
Les remarques et restrictions suivantes s'appliquent aux bases de données fédérées créées à partir de partages de données Amazon Redshift :
+ **Exigence de base de données mappée** — Chaque partage de données Amazon Redshift doit être mappé vers une nouvelle base de données dans Lake Formation. Cela est nécessaire pour conserver des noms de table uniques lorsque la représentation des objets de partage de données est aplatie dans la base de données du catalogue de données.
+ **Limitation relative à la création de nouvelles tables dans une base de données fédérée** : vous ne pourrez pas créer de nouvelles tables dans des bases de données fédérées.
+ **Autorisations sur les bases de données fédérées** : les autorisations appliquées à une base de données fédérée ou à des tables d'une base de données fédérée sont conservées même lorsqu'une table source ou une base de données est supprimée. Lorsque la base de données ou la table source est recréée, il n'est pas nécessaire de réoctroyer les autorisations. Lorsqu'une table fédérée avec des autorisations Lake Formation est supprimée à la source, les autorisations Lake Formation seront toujours visibles et vous pouvez les révoquer si nécessaire.
Si un utilisateur supprime une base de données fédérée, toutes les autorisations correspondantes sont perdues. La recréation de la même base de données portant le même nom ne permet pas de récupérer les autorisations de Lake Formation. Les utilisateurs devront à nouveau configurer de nouvelles autorisations.
+ **IAMAllowedAutorisations de groupe principales sur les bases de données fédérées** — Sur la base de cela`DataLakeSettings`, Lake Formation peut attribuer des autorisations à toutes les bases de données et tables à un groupe virtuel nommé`IAMAllowedPrincipal`. Il `IAMAllowedPrincipal` fait référence à tous les principaux IAM qui ont accès aux ressources du catalogue de données par le biais des politiques principales IAM et AWS Glue des politiques de ressources. Si ces autorisations existent sur une base de données ou une table, tous les principaux ont accès à la base de données ou à la table.
Cependant, Lake Formation n'autorise pas `IAMAllowedPrincipal` les autorisations sur les tables des bases de données fédérées. Lorsque vous créez des bases de données fédérées, assurez-vous de transmettre le `CreateTableDefaultPermissions` paramètre sous forme de liste vide.
Pour de plus amples informations, veuillez consulter [Modification des paramètres par défaut de votre lac de données](change-settings.md).
+ **Filtrage des données** : dans Lake Formation, vous pouvez accorder des autorisations sur une table d'une base de données fédérée avec un filtrage au niveau des colonnes et au niveau des lignes. Toutefois, vous ne pouvez pas combiner le filtrage au niveau des colonnes et au niveau des lignes pour restreindre l'accès au niveau de la granularité au niveau des cellules aux tables des bases de données fédérées.
+ **Identifiant distinguant majuscules** et minuscules : les objets de partage de données Amazon Redshift gérés par Lake Formation prennent en charge les noms de tables et de colonnes uniquement en minuscules. N'activez pas l'identifiant majuscules/minuscules pour les bases de données, les tables et les colonnes dans les partages de données Amazon Redshift, s'ils doivent être partagés et gérés à l'aide de Lake Formation.
+ **Assistance aux requêtes** — Vous pouvez interroger les partages de données Amazon Redshift gérés par Lake Formation avec Amazon Redshift. Athena ne prend pas en charge l'interrogation des partages de données Amazon Redshift gérés par Lake Formation.
Pour plus d'informations sur les limites liées à l'utilisation de partages de données dans Amazon Redshift, [consultez la section Limitations relatives au partage de données dans le manuel](https://docs.aws.amazon.com/redshift/latest/dg/datashare-overview.html#limitations-datashare) Amazon Redshift Database Developer Guide.
# Limites de l'intégration d'IAM Identity Center
Vous pouvez ainsi vous connecter à des fournisseurs d'identité (IdPs) et gérer de manière centralisée l'accès des utilisateurs et des groupes à travers les services AWS d'analyse. AWS IAM Identity Center Vous pouvez AWS Lake Formation le configurer en tant qu'application activée dans IAM Identity Center, et les administrateurs de data lake peuvent accorder des autorisations détaillées aux utilisateurs et aux groupes autorisés sur les ressources. AWS Glue Data Catalog
Les limites suivantes s'appliquent à l'intégration de Lake Formation à IAM Identity Center :
+ Vous ne pouvez pas affecter des utilisateurs et des groupes IAM Identity Center en tant qu'administrateurs de data lake ou administrateurs en lecture seule dans Lake Formation.
Les utilisateurs et les groupes IAM Identity Center peuvent interroger les ressources chiffrées du catalogue de données si vous utilisez un rôle IAM qui AWS Glue peut assumer en votre nom le chiffrement et le déchiffrement du catalogue de données. AWS les clés gérées ne prennent pas en charge la propagation d'identités fiables.
+ Les utilisateurs et les groupes IAM Identity Center peuvent uniquement invoquer les opérations d'API répertoriées dans la `AWSIAMIdentityCenterAllowListForIdentityContext` politique fournie par IAM Identity Center.
+ Lake Formation permet aux rôles IAM issus de comptes externes d'agir en tant que rôles de support au nom des utilisateurs et des groupes d'IAM Identity Center pour accéder aux ressources du catalogue de données, mais les autorisations ne peuvent être accordées que sur les ressources du catalogue de données du compte propriétaire. Si vous essayez d'accorder des autorisations aux utilisateurs et aux groupes d'IAM Identity Center sur les ressources du catalogue de données d'un compte externe, Lake Formation génère le message d'erreur suivant : « Les autorisations entre comptes ne sont pas prises en charge pour le principal ».
+ Lorsque vous utilisez Lake Formation avec IAM Identity Center, la configuration d'attribution des applications est définie `false` par défaut. Si vous modifiez cette configuration directement via l'[API IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_PutApplicationAssignmentConfiguration.html), vous devez ensuite gérer manuellement toutes les attributions d'applications à l'aide de l'API. Lake Formation ne synchronise ni ne gère automatiquement les modifications d'affectation effectuées en dehors de ses flux de travail standard, ce qui peut avoir un impact sur les modèles d'accès et les flux d'autorisation au sein de votre environnement de lac de données.
# Meilleures pratiques et considérations relatives au contrôle d'accès basé sur les balises Lake Formation
Vous pouvez créer, gérer et attribuer des balises LF pour contrôler l'accès aux bases de données, aux tables et aux colonnes du catalogue de données.
Tenez compte des meilleures pratiques suivantes lorsque vous utilisez le contrôle d'accès basé sur des balises Lake Formation :
+ Toutes les balises LF doivent être prédéfinies avant de pouvoir être attribuées aux ressources du catalogue de données ou accordées aux principaux.
L'administrateur du lac de données peut déléguer les tâches de gestion des balises en créant des *balises LF avec les* autorisations IAM requises. Les ingénieurs de données et les analystes décident des caractéristiques et des relations des balises LF. Les créateurs de balises LF créent et maintiennent ensuite les balises LF dans Lake Formation.
+ Vous pouvez attribuer plusieurs balises LF aux ressources du catalogue de données. Une seule valeur pour une clé donnée peut être affectée à une ressource donnée.
Par exemple, vous pouvez attribuer`module=Orders`,`region=West`,`division=Consumer`, etc. à une base de données, une table ou une colonne. Vous ne pouvez pas attribuer`module=Orders,Customers`.
+ Vous ne pouvez pas attribuer de balises LF aux ressources lorsque vous les créez. Vous ne pouvez ajouter des balises LF qu'aux ressources existantes.
+ Vous pouvez accorder des expressions de balises LF, et pas simplement des balises LF uniques, à un principal.
Une expression LF-Tag ressemble à ce qui suit (en pseudo-code).
```
module=sales AND division=(consumer OR commercial)
```
Un principal auquel cette expression LF-Tag est attribuée ne peut accéder qu'aux ressources du catalogue de données (bases de données, tables et colonnes) attribuées `module=sales` *et* soit`division=consumer`. `division=commercial` Si vous souhaitez que le directeur puisse accéder à des ressources qui incluent `module=sales` *ou* `division=commercial` non les deux dans la même subvention. Faites deux subventions, une pour `module=sales` et une pour`division=commercial`.
L'expression LF-Tag la plus simple consiste en une seule balise LF, telle que. `module=sales`
+ Un principal autorisé à accéder à une balise LF comportant plusieurs valeurs peut accéder aux ressources du catalogue de données avec l'une ou l'autre de ces valeurs. Par exemple, si un utilisateur se voit attribuer une balise LF avec key= `module` et values=`orders,customers`, il a accès aux ressources attribuées soit. `module=orders` `module=customers`
+ Vous devez être `Grant with LF-Tag expressions` autorisé à accorder des autorisations de données sur les ressources du catalogue de données à l'aide de la méthode LF-TBAC. L'administrateur du lac de données et le créateur du tag LF reçoivent implicitement cette autorisation. Un principal `Grant with LFTag expressions` autorisé peut accorder des autorisations de données sur les ressources en utilisant :
+ la méthode de ressource nommée
+ la méthode LF-TBAC, mais en utilisant uniquement la même expression LF-Tag
Supposons, par exemple, que l'administrateur du lac de données accorde l'autorisation suivante (en pseudo-code).
```
GRANT (SELECT ON TABLES) ON TAGS module=customers, region=west,south TO user1 WITH GRANT OPTION
```
Dans ce cas, `user1` vous pouvez attribuer des tables `SELECT` à d'autres principaux en utilisant la méthode LF-TBAC, mais uniquement avec l'expression LF-Tag complète. `module=customers, region=west,south`
+ Si un principal obtient des autorisations sur une ressource à la fois avec la méthode LF-TBAC et la méthode de ressource nommée, les autorisations que le principal possède sur la ressource sont l'union des autorisations accordées par les deux méthodes.
+ Lake Formation prend en charge l'attribution `DESCRIBE` et `ASSOCIATE` l'attribution de balises LF entre les comptes, ainsi que l'octroi d'autorisations sur les ressources du catalogue de données entre les comptes à l'aide de la méthode LF-TBAC. Dans les deux cas, le principal est un identifiant de AWS compte.
**Note**
Lake Formation soutient les subventions intercomptes aux organisations et aux unités organisationnelles en utilisant la méthode LF-TBAC. Pour utiliser cette fonctionnalité, vous devez mettre à jour les **paramètres de version entre comptes** vers **la version 3**.
Pour de plus amples informations, veuillez consulter [Partage de données entre comptes dans Lake Formation](cross-account-permissions.md).
+ Les ressources du catalogue de données créées dans un compte ne peuvent être étiquetées qu'à l'aide de balises LF créées dans le même compte. Les balises LF créées dans un compte ne peuvent pas être associées à des ressources partagées depuis un autre compte.
+ L'utilisation du contrôle d'accès basé sur les balises de Lake Formation (LF-TBAC) pour accorder un accès entre comptes aux ressources du catalogue de données nécessite des ajouts à la politique de ressources du catalogue de données de votre compte. AWS Pour de plus amples informations, veuillez consulter [Conditions préalables](cross-account-prereqs.md).
+ Les touches LF-Tag et les valeurs LF-Tag ne peuvent pas dépasser 50 caractères.
+ Le nombre maximum de balises LF pouvant être attribuées à une ressource de catalogue de données est de 50.
+ Les limites suivantes sont des limites souples :
+ Le nombre maximum de balises LF pouvant être créées est de 1 000.
+ Le nombre maximum de valeurs pouvant être définies pour une balise LF est de 1 000.
+ Les balises, les clés et les valeurs sont converties en minuscules lors de leur enregistrement.
+ Une seule valeur pour une balise LF peut être affectée à une ressource particulière.
+ Si plusieurs balises LF sont accordées à un principal avec une seule autorisation, le principal ne peut accéder qu'aux ressources du catalogue de données contenant toutes les balises LF.
+ Si l'évaluation d'une expression LF-Tag ne donne accès qu'à un sous-ensemble de colonnes de table, mais que l'autorisation Lake Formation accordée en cas de correspondance est l'une des autorisations nécessitant un accès complet aux colonnes, à savoir`Alter`, ou `Drop` `Insert``Delete`, alors aucune de ces autorisations n'est accordée. Au lieu de cela, seul `Describe` est accordé. Si l'autorisation accordée est `All` (`Super`), alors uniquement `Select` et `Describe` sont accordées.
+ Les caractères génériques ne sont pas utilisés avec les balises LF. Pour attribuer une balise LF à toutes les colonnes d'une table, vous attribuez la balise LF à la table, et toutes les colonnes de la table héritent de la balise LF. Pour attribuer une balise LF à toutes les tables d'une base de données, vous attribuez la balise LF à la base de données, et toutes les tables de la base de données héritent de cette balise LF.
+ Vous pouvez créer jusqu'à 1 000 expressions LF-Tag dans un compte.
+ Vous pouvez utiliser jusqu'à 50 expressions LF-Tag pour accorder des autorisations à un principal sur les ressources du catalogue de données.
+ Lorsque vous accordez ou révoquez des autorisations sur une expression de balise LF en ligne, la taille de l'expression de balise LF ne peut pas dépasser 900 octets. Pour accorder des autorisations sur des expressions de balise LF de plus grande taille, utilisez les expressions de balise LF enregistrées. Pour de plus amples informations, veuillez consulter [Création d'expressions LF-Tag](TBAC-creating-tag-expressions.md).
+ Pour ajouter le LF-Tag aux catalogues fédérés Redshift existants créés avant la sortie de disponibilité générale du support LF-Tag pour les catalogues fédérés, vous devez contacter l'équipe d'assistance pour obtenir de l'aide. AWS
# Considérations relatives au contrôle d'accès basé sur les attributs, limites et régions prises en charge
Les considérations et limitations suivantes s'appliquent au contrôle d'accès basé sur les attributs (ABAC).
+ ABAC ne prend pas en charge l'octroi d'accès à l'aide de politiques LF-Tag.
+ Les autorisations pouvant être accordées ne sont pas disponibles avec ABAC.
+ ABAC ne prend pas en charge l'octroi d'autorisations aux utilisateurs d'IAM Identity Center.
+ Lorsque vous utilisez des autorisations ABAC sur une table dans Lake Formation, Lake Formation n'accorde aucune `DESCRIBE` autorisation à la base de données ou au catalogue parent. Cela diffère des scénarios non ABAC, dans lesquels Lake Formation fournit des `DESCRIBE` autorisations implicites aux ressources parentes.
+ Tous les principaux dotés de la clé `AmazonDataZoneProject` tag sont toujours considérés comme ayant souscrit à Lake Formation pour toutes les ressources du catalogue de données.
+ ABAC ne prend en charge que les attributs de chaîne.