GS2-Identifier

GS2-Identifier は、GS2 マネージメントコンソールおよび GS2 の API にアクセスするためのクレデンシャルを管理するサービスです。

GS2 のオーナーアカウントに紐づくユーザー、各ユーザーに付与される権限 (セキュリティポリシー)、そして実際の API 呼び出しに利用するクライアントID / クライアントシークレットを発行・管理します。

GS2-Identifier はゲームクライアントから直接呼び出すことを想定していないサービスであり、運営側のセットアップやデプロイ自動化、CI/CD パイプラインなどで利用されます。

IAM 的な設計

GS2-Identifier は、クラウドサービスにおける IAM (Identity and Access Management) に相当する概念を提供します。

主要な要素は次の通りです。

• ユーザー: GS2 オーナーアカウント配下に作成する個別の利用主体
• セキュリティポリシー: 操作可能なリソースとアクションを記述したポリシー文書
• セキュリティポリシーのアタッチ: ユーザーに対してセキュリティポリシーを紐づけ、権限を付与
• クライアントID / クライアントシークレット: ユーザーごとに発行される API 認証情報

graph TD
  Owner["GS2 オーナー"] --> User["ユーザー"]
  User -->|アタッチ| Policy["セキュリティポリシー"]
  User -->|発行| Credential["クライアントID<br/>クライアントシークレット"]
  Credential -->|認証| API["GS2 API"]
  Policy -->|権限制御| API

セキュリティポリシー

セキュリティポリシーは、JSON 形式で記述された権限定義です。許可するリソース GRN と、許可するアクション (Gs2Account:CreateAccount のような操作識別子) を記述することで、そのポリシーがアタッチされたユーザーに対してどのような操作を許可するかを表現します。

開発・運用の各フェーズに応じて適切なポリシーを設計し、ユーザーごとに最小権限を付与する運用が推奨されます。

クライアントID / クライアントシークレット

ユーザーに対して発行されるクライアントIDとクライアントシークレットは、GS2 API を呼び出す際の認証情報として利用されます。1ユーザーに対して複数のクレデンシャルを発行することができ、用途やデバイスに応じて使い分けることができます。

クライアントシークレットは発行時にのみ取得可能であり、それ以降は GS2 から取り出せません。万一漏洩した場合は当該クレデンシャルを削除し、再発行してください。

GS2-Version と連動した権限の段階的付与

GS2-Identifier では、ユーザーに紐づくクレデンシャルに「ガード」として GS2-Version の Project Token 発行を要求することができます。

具体的には、アプリケーション組み込みのクライアントID / クライアントシークレットには「ログインとバージョンチェックを実行できる程度」の弱い権限のみを与えておき、バージョンチェックに成功した後で発行される強い権限のクレデンシャルを使ってゲーム本編にアクセスする、という設計が可能です。

graph TD
  App["アプリケーション内蔵<br/>クレデンシャル<br/>(最小権限)"] -->|バージョンチェック| Version["GS2-Version"]
  Version -->|Project Token 発行| App
  App -->|Project Token を用いた認証| Strong["強い権限の<br/>クレデンシャル"]
  Strong -->|ゲーム本編 API 呼び出し| API["GS2 API"]

このフローにより、古いアプリケーションバイナリや、サポートを終了したアセットバージョンで動作しているクライアントが、ゲーム本編の API にアクセスし続けることを防止できます。詳細は GS2-Version のドキュメントを参照してください。

二要素認証

GS2 マネージメントコンソールへのログインユーザーに対して、二要素認証を有効化することが可能です。GS2-Identifier では二要素認証の設定情報を管理します。

トランザクションアクション

GS2-Identifier ではトランザクションアクションを提供していません。

マスターデータ管理

GS2-Identifier ではマスターデータの登録はありません。セキュリティポリシーやユーザー、クレデンシャルなどはマネージメントコンソールや GS2-Deploy、API を通じて直接管理します。

実装例

GS2-Identifier は管理API/サーバーサイドAPI中心のマイクロサービスです。ゲームエンジン用 SDK (Unity/Unreal Engine) には専用の Domain クラスが提供されていません。

ユーザー・セキュリティポリシー・クレデンシャルの管理操作は、運営側のセットアップやデプロイ自動化、CI/CD パイプラインから実行することを想定しているため、以下のいずれかの手段で操作することを推奨します。

• GS2 マネージメントコンソール (GUI でユーザー・ポリシー・クレデンシャルを操作)
• GS2-Deploy のテンプレートにユーザー・ポリシー・クレデンシャルの定義を記述し、CI から反映
• 各種言語向け一般SDK (C# / Go / Python / TypeScript / PHP / Java) による運営ツールからの管理 API 呼び出し
• GS2 CLI

各種SDKの詳細は対応するリファレンスページを参照してください。

Project Token の取得

例外的に、ユーザーに対するログイン (Project Token の発行) はアプリケーション側で実行するケースがあります。組み込みのクライアントID / クライアントシークレットを用いて Login API を呼び出し、取得した Project Token を GS2 API の認証情報として利用することで、ユーザーに紐づくセキュリティポリシーの範囲で API を呼び出せます。

ログイン API はゲームエンジン用 SDK の Domain 経由ではなく、各種言語向け一般SDK (C# / Go / Python / TypeScript / PHP / Java) を用いて呼び出してください。GS2-Version と組み合わせる場合は、バージョンチェック後に Project Token を発行することで権限の段階的付与が実現できます。

より実践的な情報

運営フェーズごとの権限分離

開発フェーズと本番フェーズでは、必要となる権限の種類や強さが異なります。GS2-Identifier ではユーザーごとに異なるセキュリティポリシーをアタッチできるため、次のようなアカウント設計が考えられます。

• 開発者ユーザー: 開発環境のリソースに対する読み書き権限のみ
• 運用ユーザー: 本番環境のリソースに対する読み取りと限定的な書き込み権限
• CI ユーザー: GS2-Deploy の実行に必要な権限
• ゲームクライアント組み込みユーザー: ログインとバージョンチェックのみ実行可能

利用主体ごとに専用のクレデンシャルを発行し、最小権限の原則に従って運用することで、万一クレデンシャルが漏洩した際の影響を限定できます。

クレデンシャルのローテーション

セキュリティを維持するため、クライアントID / クライアントシークレットは定期的にローテーションすることを推奨します。新しいクレデンシャルを発行してから古いクレデンシャルを削除する手順を踏むことで、無停止での切り替えが可能です。

詳細なリファレンス