こんにちは、SREチームの與島（よしま）です。
AWS環境において開発者がデータベースにアクセスするための仕組みを整備する際に、Amazon RDS/Aurora IAMデータベース認証を利用することは、パスワード管理が不要でかつ、データベース接続権限をIAMで一元管理できるという点で魅力的です。
しかし、IAMデータベース認証は運用方法によってはデータベース監査ログに記録されるユーザー名から実際に操作を実行した個人を追跡できないという課題があります。
この記事では、IAMデータベース認証を利用しながらこの課題に対処するために構築したジャストインタイムデータベースアクセスの仕組みについて紹介します。
IAMデータベース認証
IAMデータベース認証は、IAMポリシーによってデータベース接続の可否を検証する認証方式です。データベースに接続する際には、パスワードの代わりに認証トークンを利用します。認証トークンはクライアント側で生成します。データベースはユーザー名と認証トークンを受け取り、当該ユーザーで接続する権限を、認証トークンを生成したIAMエンティティが保持しているかどうかを検証します。
通常のパスワード認証の代わりにIAMデータベース認証を使うメリットは大きく2つあります。
- パスワード管理が不要: 認証トークンを利用する方法では、利用者がデータベース接続する際にローカルで認証トークンを生成すればよいので、ユーザー作成時のパスワード発行やメンバーへのパスワードの連絡が不要です。また、認証トークンは15分という有効期限があるので、利用者によるパスワード管理も不要です
- IAMによるデータベース接続権限の管理の一元化: 役割変更などに伴いデータベース接続権限を更新する際には、通常データベース側でのユーザーの無効化や削除が必要ですが、IAMデータベース認証ではIAMポリシーの更新で対応できます
IAMデータベース認証の課題：責任追跡性
IAMデータベース認証における課題は、運用方法によっては責任追跡性1が満たせない点です。ひとつのデータベースユーザーを複数のIAMエンティティから利用できる状況では、データベース監査ログに記録されたイベントからその操作主体を特定できません。これはデータベース監査ログに記録されるのはデータベース側のユーザー名のみであって、そのデータベースユーザーを利用して接続したIAMエンティティの情報は記録されないためです。
具体例で説明します。複数のIAMエンティティ（iam-entity-a、iam-entity-b）が、データベースユーザー dbuser を利用する権限を持つIAMロールiam-role-cにassume-roleできるとします。この場合、監査ログに記録された dbuser の操作が、iam-entity-aとiam-entity-bのどちらによるものか厳密には特定できません。2
IAMデータベース認証を利用しながら責任追跡性を満たす
IAMデータベース認証を利用しながら責任追跡性を満たそうとした場合に現時点で最もベターな運用方法は、個人に紐づくIAMエンティティごとにデータベースユーザーを作成する方法です。ここでいうIAMアイデンティティは、典型的にはIAM Identity Centerユーザーです。IAM Identity Centerユーザーごとに対応するデータベースユーザーのみを利用できるようにIAMポリシーで制限をかければ、実質的に個人とデータベースユーザーを一対一に対応させられます。これによってデータベース監査ログに記録されたユーザー名から個人を辿れるようになります。
しかし、この方式では責任追跡性が満たせる一方で、新たに考慮すべき要素としてユーザーと権限の管理が加わります。メンバーの入社時や異動時にはデータベースユーザーの作成が、役割変更時には権限の更新、退職時には削除が必要です。データベースインスタンスが複数ある場合には"メンバー数 × データベース数"分のデータベースユーザーと権限を管理する必要があり、管理対象の数が増加します。
今回取り組んだ環境はテナントごとに個別のデータベースインスタンスがあり、今後もテナントとともに増加していく予定なので、それに伴う管理コストの増加が懸念にあがりました。
責任追跡性・ユーザーと権限の管理というトレードオフ構造がある状況に対して、異なるアプローチによってIAMデータベース認証を利用しながら両者をバランスよく実現できないかを模索し、考案、実装したのがジャストインタイムデータベースアクセスの仕組みです。
ジャストインタイムデータベースアクセス
利用者がデータベースに接続したいときに、一時的なデータベースユーザーとその認証トークンを都度発行する仕組みです。中心になるのは、リクエストに応じてデータベースユーザーの作成と認証トークンの生成を行うLambda関数です。このLambda関数のことを以降はjit-db-accessと呼びます。メンバーはjit-db-accessにリクエストして一時的なデータベースユーザーと認証トークンを受け取り、その認証情報を使ってデータベースに接続します。
利用時の流れを説明したあとに、責任追跡性・ユーザーと権限の管理に対してそれぞれどのようにアプローチしているかを紹介します。
利用時の流れ
開発者Aliceがジャストインタイムデータベースアクセスの仕組みでAmazon RDS/Aurora（MySQL）のデータベースに接続するときの流れを図で示します。
- 開発者（Alice）: 接続したいデータベースを含むリクエストをAPIゲートウェイに送信
- APIゲートウェイ: IAM認証を経由してjit-db-accessをトリガー
- jit-db-access: ペイロードに含まれる接続先データベースにデータベースユーザー alice を作成
- jit-db-access: データベースユーザー alice に接続するための認証トークンを生成
- jit-db-access: データベースユーザー名と認証トークンを開発者にレスポンス
- 開発者（Alice）: データベースユーザー名と認証トークンでデータベースに接続
- データベース: IAMデータベース認証プラグインで認証トークンを検証
責任追跡性: 個人とデータベースユーザーの紐づけ
jit-db-accessにリクエストできるIAMエンティティをIAM Identity Centerユーザーのみに制限したうえで、作成するデータベースユーザー名にIAM Identity Centerユーザーの識別子を含めることで、作成する一時的なデータベースユーザーが必ず個人に紐づくようにして責任追跡性を満たしています。IAM Identity Centerユーザーのみに制限しているのは、個人のアイデンティティとして取り扱えるためです。IAMユーザーやIAMロールは、複数の開発者が共有できる可能性があり、その場合にデータベースユーザーと個人の紐づけが難しくなるので許可していません。
jit-db-accessのなかで呼び出し元のIAMエンティティを検証する必要があるため、APIゲートウェイのIAM認証を経由してjit-db-accessをトリガーすることでIAMエンティティの情報を渡しています。これは利用者が直接Lambda関数をトリガーする方法ではIAMエンティティの情報がjit-db-accessに渡らなかったためです。検証自体はLambda関数のリクエストコンテキストに含まれるリクエスト元IAMエンティティのARNがIAM Identity Centerユーザーの形式になっているかどうかを確認するシンプルな処理です。
ユーザーと権限の管理: ライフサイクル管理を自動化
ジャストインタイム方式なので事前のデータベースユーザー作成は不要です。
作成したデータベースユーザーは認証トークンの有効期限とともに使えなくなるようにしています。認証トークンの発行はリクエスト時に一度しか行われないので、認証トークンの有効期限が過ぎるとそのデータベースユーザーには新規接続ができなくなります。これによって実質的にデータベースユーザーを一時的なものにしています。ただし、そのままだとデータベースユーザーの実体は残ったままになってしまうので、手作業や自動化した仕組みによるクリーンアップは必要です。今回のケースでは、リクエスト元のIAM Identity Centerユーザーに対応するデータベースユーザーが既に存在していたら削除することでデータベースユーザーの実体が残り続けないようにしています。
IAMデータベース認証でアクセスするための権限については、認証トークンを生成するLambda関数（jit-db-access）のサービスロールにrds-db:connectを許可すればよいので、個別のIAMエンティティ側での権限管理は不要です。
まとめ
IAMデータベース認証を利用した開発者向けデータベースアクセスの仕組みとして構築したジャストインタイムデータベースアクセスを紹介しました。
ジャストインタイムデータベースアクセスでは追加のコンポーネントとしてLambda関数をデプロイすることになるので、仕組み自体の運用、障害発生時のフォールバック運用の整備など、また別の考慮事項がでてきます。
今回は責任追跡性・ユーザーと権限の管理という要素に着目して、これらを同時に満たすことが重要だったのでこのアプローチを採用しました。
