鍵・パスワードのメンテナンス

3.6.1. ID トークン署名用キーペアの更新

利用企業の認証サーバーでは ID トークン署名用の秘密鍵を厳重に管理する必要がある。秘密 鍵が漏えいした場合、第三者が偽の ID トークンを発行することにより、クラウドサービス上の 全アカウントに成りすましアクセスができるようになる。

署名用のキーペアは適切なタイミングでローテーションを行なう必要がある。たとえば、秘密 鍵の漏えいが疑われるときや、使用している鍵長が安全ではなくなったときなどに、キーペアの ローテーションが必要である。

3.6.2. SCIM エンドポイントアクセス用パスワードの更新

利用企業の ID 管理システムでは、SCIM エンドポイントアクセス用のパスワードを厳重に管 理する必要がある。パスワードが漏えいした場合、第三者がクラウドサービス上のユーザー情報 を不正に読み出したり、不正に書き換えたりすることができるようになる。

当実装ガイドでは、SCIM エンドポイントアクセス時の認証方式として、少なくともBasic認 証に対応することを求めている。

Basic 認証で用いるパスワードは、自動的にかつ定期的に交換されるものではなく、人の手を

介在して交換・設定されるものであるため、設定・運用担当者を通じた漏えいに特に注意する必 要がある。

SCIM エンドポイントアクセス用パスワードは、パスワード漏えいが疑われる場合に更新が必 要である。

3.6.3. SCIM エンドポイントアクセス時の OAuth を使った認可への対応

SCIM エンドポイントへのアクセスを保護するためには、エンドポイントアクセスのためのク レデンシャル情報（パスワードやトークン）を、人の手を介在せずに交換する方式を用いること が望ましい。このような方式として、OAuth 2.0による認可と、それによって発行されたトーク ンを利用する方式がある。

SCIM クライアントとなる利用企業の ID 管理サーバーは、一般的には ID 管理の製品を用い て実装されることが多いものの、OAuth 2.0の認可フローに対応したものが少ないという現状が ある。そこで、当実装ガイドでは、利用企業の認証システムとクラウドサービスの相互接続の実 現を早期実現するため、SCIMエンドポイントアクセス時の認証方式として Basic認証に対応を 求めることを選択した。

しかし一方で、Basic 認証で実装する場合は、すでに [3.6.2 節] でも述べたとおり、パスワー ドの交換・設定が人の手を介して行なわれるため、パスワード漏えいのリスクが残存する。

そのため、SCIM エンドポイントアクセス時の OAuth 2.0 を使った認可にも対応することを 強く推奨する。

OAuth 2.0を使った認可を実装する場合は、次のような方法を用いる。

1. 利用企業のID管理サーバーを、クラウドサービスの（OAuth 2.0が意味するところの）

クライアントとして登録する。

2. 利用企業の ID管理サーバーで SCIMクライアントの構成を行なう際に、OAuth 2.0 の

3. SCIMエンドポイントアクセス時は、発行されたアクセストークンを使用する。

4. アクセストークンの定期的な交換を実現するために、リフレッシュトークンを用いたア クセストークンの更新に対応する。

この方法のメリットは、大きく2つある。ひとつは、利用企業の管理者であることの認証を、

多要素認証などを併用したより安全な認証方式で認証できる点である。もうひとつは、SCIM エ ンドポイントにアクセスするためのトークンが、人の手を介在することなく、定期的にかつ自動 的に交換される運用を実現できる点である。