Databricksが委任IAM権限でAmazon S3接続を簡素化

Databricksは、委任されたIAM権限を使ってAmazon S3データを接続し、長期資格情報の配布を減らす方法を紹介しました。

要点

• AWS側の役割とDatabricks側の管理対象を結び、秘密鍵の直接管理を避けます。
• バケット全体ではなく、用途に必要な場所と操作へ権限を絞ります。
• 信頼関係、外部識別子、Unity Catalogの権限を一続きで検証します。

今回のブログ記事で語られていること

S3データをDatabricksから利用する際、アクセスキーを作って複数の作業領域へ配布すると、更新、失効、所有者、漏えい時の影響範囲が複雑になります。委任IAM権限は、AWSの役割を必要時に引き受ける構成にし、固定資格情報をアプリやノートへ置かずに接続します。クラウド管理者とデータ管理者の責任を分けやすくすることが主題です。

AWS側では、対象バケットや接頭辞に必要な読み書きだけを許可し、Databricksが役割を引き受けるための信頼関係を設定します。Databricks側では、その資格情報を外部ロケーションやカタログの権限へ接続します。クラウド側で許可されていてもUnity Catalog側で利用者へ付与されていなければ使えず、逆にカタログ権限があってもIAMが拒否すれば到達できません。

導入時は読み取り、書き込み、一覧、削除を分けて試し、想定外の接頭辞や別バケットが拒否されることも確認します。複数アカウントでは外部識別子と信頼主体を厳密にし、役割の連鎖と最大継続時間も把握します。監査ログでは誰のDatabricks操作がどのAWS役割を使ったかを対応付けられるようにします。

既存のアクセスキーから移行する場合は、役割経路を並行で試し、処理量、権限、費用を比較してから鍵を失効します。鍵を残したままでは攻撃面が減らないため、利用ログで旧経路がゼロになったことを確認し、秘密情報管理から削除するところまでを移行完了とします。

役割や外部ロケーションを作った後も、利用されていない設定を定期的に棚卸しします。バケット方針、暗号鍵、ネットワーク境界を変更した際には接続試験を再実行し、拒否された操作が別の広い役割へ自動的に切り替わらないことも確認します。

今回のブログ記事が関係する人

DatabricksとAWSの基盤担当、Unity Catalog管理者、クラウド権限を監査するセキュリティチームに関係します。

結局、今回のブログ記事をどう読むべきか

S3接続の便利機能ではなく、固定鍵から短期の役割引き受けへ認証方式を変える提案です。両側の権限を最小化し、旧鍵の廃止まで完了させる必要があります。