Back

/ 5 min read

マルチテナントでIDPを使う上で注意すべき3つのこと

背景など

プライベートでIDPを使ったテストを書いていたところ、偶然にも脆弱性ぽい挙動を見つけたので、Googleにセキュリティレポートを送ったところ、マルチテナント機能利用時のセキュリティを向上させる新機能を追加して貰いました。

本記事はこのレポートと関連して、IDPでマルチテナント機能を安全に使うためのTips集です。

TL;DL

Google CloudのIdentity Platformでマルチテナントアプリを構成する場合は以下の設定を忘れないようにしましょう。

  • メール列挙保護を有効にする
  • パスワードポリシーを有効にする
  • 必要に応じてユーザのセルフサインアップを防止する(私がレポートした結果追加された新機能)
    ※マルチテナント環境下ではGCPの設定画面からは設定変更出来ない

メール列挙保護を有効にする

IDPの新機能としてメール列挙保護が追加されました。
これは攻撃者の手によってユーザのメールアドレスを特定されることを防ぐための機能です (ブルート フォース攻撃の一種)

以下の通りプロジェクト作成時期によっては対応が必要なので注意が必要です。

2023 年 9 月 15 日以降にプロジェクトを作成した場合、メール列挙保護はデフォルトで有効になります。 2023 年 9 月 15 日より前にプロジェクトを作成した場合、メールの列挙保護は自動的に有効になりません。

参考: メールの列挙保護を有効または無効にする

パスワードポリシーを有効にする

こちらもIDPの新機能としてパスワードポリシー機能が追加されました。

今までは本当に最低限のチェックしかしてくれず細かい設定も出来なかったためクライアントサイドで自前のパスワードポリシーを実装していた方も多いと思いますが、この機能によりIDP側での柔軟なパスワードポリシー設定と検査が出来るようになりました。

パスワード ポリシーを使用すると、パスワードの複雑さの要件を適用して、アカウントのセキュリティを強化できます。パスワード ポリシーでは、次のパスワード要件がサポートされています。

参考: パスワード ポリシーの有効化、無効化、使用

必要に応じてユーザのセルフサインアップを防止する

こちらは何と、私が要望を出したことがきっかけで実装してもらった機能です。 この機能の追加前はマルチテナント環境でユーザのセルフサインアップを防止する方法がなく、攻撃者が自由にユーザを作成できてしまうという問題がありました。
(何らかの方法で攻撃者がテナントIdを推測可能な場合)

この問題はセキュリティ上の問題にも繋がりうるため簡単なレポートを書いてGoogleに報告したところ、対応してもらえることになりました。
(レポート報告後、今回の件をブログ等へ掲載する許可を貰っています)

なお、今回追加された機能は記事執筆時点ではGCPの設定画面からは設定変更出来ないため、REST APIを使用して設定変更する必要があります。 (以下のスクショ部分が追加された内容で、tenantIdを指定できることからマルチテナントに対応していることが分かります。非マルチテナント環境では従来通り設定画面から変更出来ます)

IDP

参考: エンドユーザー アカウントの作成と削除を無効にする