OAuthクライアントシークレットは発行よりローテーションが重要
B2B SaaSのOIDCクライアントシークレットを安全に保管し、停止せずに更新し、監査可能なライフサイクルで運用する方法を解説します。
SSO連携時に発行したOAuthクライアントシークレットを、何年も同じまま使用していませんか。近年のIAMセキュリティでは、ユーザーだけでなく、アプリケーション、API、自動化ツールなどの非人間アイデンティティに対する認証情報管理が重要になっています。クライアントシークレットもアプリケーションがIdPに自身を証明する認証情報です。発行、保管、更新、廃止までを一つのライフサイクルとして管理する必要があります。
クライアントシークレットはアプリのパスワード
OIDCのコンフィデンシャルクライアントは、トークンエンドポイントへリクエストする際、クライアントIDとシークレットで自身を認証します。シークレットがソースコード、共同編集文書、CIログに漏れると、攻撃者が正規アプリになりすましてトークンを要求するおそれがあります。複数のサーバーやデプロイ環境に複製されやすいため、漏えい箇所の特定も簡単ではありません。
ブラウザやモバイルアプリのように値を隠せないパブリッククライアントへ、シークレットを埋め込んではいけません。PKCEなどクライアント種別に合う方式を選び、サーバー側で安全に保管できるコンフィデンシャルクライアントに限って使用します。OIDCの役割とSAMLとの違いはOIDCとSAMLの比較をご覧ください。
ローテーションは事故後ではなく定常運用で行う
シークレットのローテーションとは、新しい値へ切り替え、以前の値を廃止する作業です。定期的に更新すれば、漏えいを把握できていない場合でも認証情報の有効期間を限定できます。担当者の退職、リポジトリの公開、デプロイログへの出力、委託契約の終了など、信頼境界が変わった場合は予定日を待たずに更新してください。
サービスを止めない更新手順
- アプリの責任者と、利用中の本番・ステージング環境を確認します。
- 新しいシークレットを発行し、シークレット管理基盤へ登録します。
- アプリケーションへ新しい値をデプロイし、トークン発行とログインを検証します。
- 全インスタンスの切り替えを確認してから、以前のシークレットを廃止します。
- 発行者、変更日時、対象アプリ、検証結果を監査記録に残します。
新しい値のデプロイ前に以前の値を無効化すると、ログイン障害につながります。一方、移行期間を無期限にすると攻撃可能な時間も延びます。短く明確な移行期間とロールバック基準を決めることが重要です。
マルチテナントでは顧客ごとに影響を分離する
複数の顧客が同じシークレットを共有すると、一件の漏えいが全テナントへ波及しかねません。顧客・アプリ単位で認証情報を分離し、本番とステージングも分けて管理します。アクセスできる担当者を最小限にし、平文をチケット、チャット、ログへ残さない運用も必要です。顧客境界の設計はマルチテナントIdPの分離原則も参考にしてください。
AxiPassは、マルチテナント環境でOIDC/OAuth2アプリの登録とシークレットのローテーション、グループベースのアクセスポリシー、MFA、監査ログをまとめて管理できるよう支援します。SAMLアプリ、SCIMプロビジョニング、SSO非対応アプリ向けのSWAも一元管理することで、人とアプリの認証情報に関する変更を一貫して追跡できます。監査準備についてはSaaSセキュリティ監査とIdPもご覧ください。