ある大企業のデータプラットフォームチームは、AWS Glue Data Catalog に 2,000 を超えるテーブルを管理しており、毎月新しいテーブルが追加されています。各テーブルにはデータ機密レベル（public / internal / confidential / restricted）と担当部署（finance / hr / sales）の分類があります。現在は AWS Lake Formation でテーブルごとに個別のアクセス許可を付与していますが、テーブル数の増加により管理コストが急増しています。最小限の管理作業で、データ分類と部署属性に基づく細かなアクセス制御を維持する方法として最も適切なものはどれですか？
AWS Lake Formation の LF タグベースのアクセス制御（LF-TBAC）は、属性ベースのアクセス制御（ABAC）を Lake Formation に適用した仕組みです。データリソース（データベース・テーブル・列）に任意のキー・バリュー形式の LF タグを付与し、IAM プリンシパルに対してタグ単位でアクセス許可を付与します。新しいテーブルに適切な LF タグを付与するだけで正しいアクセス制御が自動適用されるため、個別許可の手動設定が不要になり、数千テーブル規模でもスケールします。 選択肢AのAWS Glue Data Catalog リソースポリシーは、Data Catalog リソース全体に対するアカウントレベルのクロスアカウントアクセス制御には有効ですが、テーブル単位の細かな権限管理には不向きで、テーブル増加に伴うスケール問題を解決できません。 選択肢CのAmazon S3 バケットポリシーは、S3 オブジェクトへのアクセスを制御しますが、Glue Data Catalog のテーブルメタデータへのアクセスを制御する仕組みではありません。 選択肢DのIAM ポリシーによる ARN 列挙は、テーブルが増えるたびにポリシーを更新する必要があり、管理コストの問題を解決しません。また IAM ポリシードキュメントには文字数制限があるため、数千のテーブル ARN を列挙することは現実的ではありません。