OAuthによるクラウドネイティブなデータセキュリティ

第4章. OAuthデータ設計

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

OAuthは分散アーキテクチャであり、認証サーバは独自のデータソースを持つ。OAuth を使い始める際、早い段階で考慮すべきことは、 将来を見据えたデータ設定を可能にすることである。認証サーバとそのデータを簡単にデプロイできるようにすべきである。認可サーバからのユーザ属性は、APIがユーザのビジネスリソースへのアクセスを正しく認可できるような形でAPIに流れるべきである。

この章では、認可サーバがどのようにデータを管理するかを説明する。次に、このデータを運用するための設計上の選択肢を説明する。特に、ユーザアカウントとユーザ属性について説明する。また、APIと認可サーバ間の依存関係を適切なレベルにするための管理性についても説明する。そして、ビジネスデータが大きくなってもOAuthデータを持ち運べるように、マルチテナンシーとマルチリージョンに関するより広いトピックをカバーする。最後に、認可サーバのユーザ管理APIを使用してユーザアカウントにデータを入力する方法を説明する。まず、認証サーバが使用するデータの種類を理解しよう。

認証サーバデータ

認証サーバは、ビジネス・データとは別に管理するいくつかのタイプの ID データをストア する。これらのタイプは、 設定データ、演算子データ、 ユーザ ID データに大別される。図 4-1に、認証サーバ・データの例を示す。

図4-1. 認証サーバが管理するデータ

設定データにはクライアントのセットも含まれる。通常、トークンを受け取る前に、認証サーバにクライアントを登録する必要がある。クライアントごとに、サポートされる認証メソッドなどのポリシーを定義する必要がある。ユーザがクライアント経由でログインすると、認証サーバは設定されたポリシーに応じて適切な認証メソッドを選択する。

コンフィギュレーションは、各クライアントのアクセストークンに含まれるAPIパーミッションや、認証サーバがアクセストークンの電子署名に使用する暗号キーも制御する。秘密とキーの管理は一般的な課題であるため、多くのクラウドプロバイダは、安全な値を保存するためのVaultのようなサービスを提供している。また、例えば、ハードウェア・セキュリティ・モジュールを使用して、鍵材料を生成・保存することもできる。この方法では、認証サーバは機密性の高い鍵材料を保存する必要がない。

認可サーバは、ユーザのアクティビティによる運用データを書き込む。これには、トークンやセッション関連の情報、各種ログが含まれる。この演算子は必要な期間だけ保存する。テクニカル・ログはサポート目的で使用し、監査ログはログイン試行失敗の頻度などセキュリティ・イベントに関する洞察のために使用する。

ユーザ・アイデンティティ・データは、最も設計上の考慮が必要である。通常、認可サーバにユーザアカウントを作成し、ユーザに対して属性を格納できるようにする。認可サーバはまた、ハッシュ化されたパスワードや、より高度なタイプのログイン資格情報を検証するために使用される公開鍵など、ユーザアカウントに対する他のセキュリティ関連データもストアする。多くのユースケースでは、ユーザ作成は、ユーザがサインアップできる ...