ある小売企業は全国の販売データを Amazon Redshift の sales テーブルに統合管理しています。各地域の営業マネージャーは担当地域のデータのみ参照でき、他地域のデータは一切見えない必要があります。テーブル設計を変更せず、ユーザー属性に基づく行単位の参照制御をデータベース内で完結させる最も適切な方法はどれですか？
Amazon Redshift の行レベルセキュリティ（RLS）は、テーブルへのアクセス時にユーザーの属性（セッション変数や current_user など）に基づいてフィルタリング条件を自動適用するデータベースネイティブ機能です。CREATE RLS POLICY でフィルター条件を定義し、ATTACH RLS POLICY ON テーブル TO ロール でアタッチするだけで、ビューや別テーブルを作成せずに行単位のアクセス制御が実現できます。ユーザーは自分が参照権限を持つ行のみを受け取り、他の行の存在も認識できません。テーブル設計を変更せずデータベース内で完結するため、要件に最も適した構成です。 選択肢Aの地域別ビューは機能しますが、地域が増えるたびにビューを新規作成・管理する必要があり、スケーラビリティに欠けます。 選択肢CのAWS Lake Formation の行レベルフィルターを Redshift Spectrum 外部テーブルに適用すること自体は技術的に可能ですが、既存のローカル sales テーブルを Spectrum 経由の外部テーブルへ移行する必要があります。これは「テーブル設計を変更せず」という要件に反するほか、Lake Formation と Spectrum の追加構成が必要で Redshift RLS よりも複雑な実装となります。 選択肢DのAmazon Redshift の動的データマスキングは列の値を変換・隠蔽する機能であり、行単位で異なるユーザーに異なるデータセットを返す行レベルフィルタリングとは目的が根本的に異なります。