Amazon Redshift、連邦権限環境でのセキュアロギング用に新「DEBUG」権限を導入

Amazon Redshiftは、きめ細かなアクセス制御（FGAC）と連邦権限を使用している環境において、セキュアロギングのマスキングを制御できる新しい「DEBUG」権限を導入しました。これにより、セキュアロギングを有効にしたまま、特定のIAMユーザーやロール、IAM Identity Centerのユーザー/グループに対して、書き換えられたクエリテキストやエラーメッセージなどの機密情報が含まれるシステムテーブルのレコードを、マスキング（非表示化）せずに表示させることが可能になります。

🛠️ 技術的な課題と解決策

これまで、FGAC（きめ細かなアクセス制御）を利用してデータを保護している場合、セキュリティを担保するためにセキュアロギングがクエリテキストやエラーメッセージ内の機密値を自動的にマスキングしていました。しかし、これでは**「トラブルシューティングをしたい管理者」や「監査を行いたい監査人」が、肝心な情報が見えない**という、セキュリティと運用性のトレードオフが発生していました。

今回のDEBUG権限の導入により、セキュアロギング機能をオフにすることなく、特定のアイデンティティに対してのみ「非マスキングのログ」へのアクセスを許可できるようになります。これにより、「データ保護」と「高度なオブザーバビリティ（観測性）」の両立が可能になりました。

🇯🇵 日本国内での利用状況

最新のリージョン状況を確認したところ、東京リージョン（ap-northeast-1）および大阪リージョン（ap-northeast-3）の両方で利用可能です。Amazon Redshiftがサポートされているすべてのリージョンで展開されています。

💡 運用上のアドバイス

• 最小権限の原則を徹底: DEBUG権限は、クエリの内容（機密情報を含む可能性がある）をそのまま閲覧できる強力な権限です。IAMユーザーやロールに対して付与する際は、必ず監査ログを併用し、「誰がDEBUG権限を使ってログを見たか」を追跡できるようにしてください。
• S3 Tablesへのエクスポート: システムテーブルのデータをAmazon S3 Tablesにエクスポートする場合でも、DEBUG権限を持つ管理者のレコードはマスキングされずに保持されます。データレイク側での監査プロセスも考慮に入れておきましょう。

🚀 次のアクション

まずは、現在のトラブルシューティングフローにおいて、ログのマスキングが原因で調査が難航しているケースがないか確認してください。検証環境にて、標準のGRANTコマンドを用いてDEBUG権限を付与し、意図した通りに非マスキングのログが取得できるかをテストすることをお勧めします。

📖 参照ドキュメント

• Amazon Redshift documentation: federated permissions
• Amazon Redshift documentation: Usage Notes
• Amazon Redshift documentation: secure logging