GS2-Guard

チート対策・WAF・ブロッキングポリシー機能

GS2-Guard は GS2 のAPIエンドポイントに対するアクセスを保護するための機能を提供します。 特定の国や地域、IPアドレス、匿名化されたIP、ホスティング事業者のIP、評判の悪いIPなど、さまざまな条件で送信元を判定し、API リクエストを許可・拒否する仕組みを構築できます。

不正利用やチート行為、攻撃的なトラフィックからゲームサーバーを守るための、いわばゲーム向けの軽量な WAF (Web Application Firewall) として機能します。

GS2-Guard はゲームクライアントから直接利用する機能ではなく、運営側でブロッキングポリシーを定義し、他のGS2マイクロサービスのAPIに対して適用するための仕組みです。

ブロッキングポリシー

GS2-Guard のネームスペースには BlockingPolicyModel を1つ設定でき、ここにアクセス制御のルールを記述します。 GS2の各マイクロサービスのネームスペースから、対象の GS2-Guard ネームスペースを参照することで、そのマイクロサービスへの API リクエストにブロッキングポリシーが適用されます。

ブロッキングポリシーで設定できる主な項目は以下の通りです。

  • 既定の制限 (defaultRestriction): 既定で API リクエストを許可するか拒否するか
  • 例外的に許可するサービス (passServices): 制限を適用しないGS2のサービス名のリスト
  • 地理的制限 (locationDetection / locations / locationRestriction): リクエストの送信元の国・地域を判定し、特定の国・地域だけ許可・拒否する
  • 匿名IP制限 (anonymousIpDetection / anonymousIpRestriction): Tor出口ノードやVPNなど、匿名化サービス経由のリクエストを判定し、許可・拒否する
  • ホスティング事業者のIP制限 (hostingProviderIpDetection / hostingProviderIpRestriction): クラウド事業者などホスティング由来のIPからのリクエストを判定し、許可・拒否する
  • 評判の悪いIPの制限 (reputationIpDetection / reputationIpRestriction): 攻撃の踏み台として知られるなど、悪評のあるIPからのリクエストを判定し、許可・拒否する
  • 個別IPアドレス制限 (ipAddressesDetection / ipAddresses / ipAddressRestriction): 任意のIPアドレス・CIDRレンジを指定して、許可・拒否する
graph LR
  Client["ゲームクライアント"] -- API リクエスト --> Guard["GS2-Guard<br/>(ブロッキングポリシー判定)"]
  Guard -- 許可 --> Microservice["他のGS2マイクロサービス"]
  Guard -- 拒否 --> Block["403 / アクセス拒否"]

検出と制限の分離

各検出条件 (Detection) は「無効」「有効」のいずれかを取り、検出条件が有効な場合に「対応する制限 (Restriction)」が適用されます。 これにより、検出だけ行ってログに残しておき、しばらく状況を確認したのちに本格的に拒否を有効化する、といった段階的な運用が可能です。

既定の挙動とホワイトリスト / ブラックリストの使い分け

defaultRestriction を「許可」にしたうえで個別の判定条件で「拒否」を組み合わせることで、ブラックリスト型のポリシーを構築できます。 逆に defaultRestriction を「拒否」にしたうえで passServices や ipAddresses で例外を許可することで、ホワイトリスト型のポリシーを構築できます。

他のマイクロサービスへの適用

GS2-Guard は単独で使うサービスではなく、他のマイクロサービスのネームスペースから参照されて初めて効果を発揮します。 各マイクロサービスのネームスペース設定で GS2-Guard のネームスペースを指定すると、そのネームスペース宛てのAPIリクエストに対して、設定されたブロッキングポリシーが適用されます。

複数のマイクロサービスから同じ GS2-Guard ネームスペースを参照することで、横断的にアクセス制御を統一できます。

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

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

マスターデータ管理

GS2-Guard は GS2 で一般的な「マスターデータのインポート/エクスポート」ではなく、ネームスペース自身の設定としてブロッキングポリシーを保持します。 ブロッキングポリシーはマネージメントコンソールから設定する他、GS2-Deploy を使って CI から登録するようなワークフローを組むことも可能です。

ブロッキングポリシーの登録の YAML 例は以下のような形になります。

blockingPolicy:
  defaultRestriction: Allow
  passServices:
    - account
    - version
  locationDetection: Enable
  locations:
    - JP
  locationRestriction: Deny
  anonymousIpDetection: Enable
  anonymousIpRestriction: Deny
  hostingProviderIpDetection: Enable
  hostingProviderIpRestriction: Deny
  reputationIpDetection: Enable
  reputationIpRestriction: Deny
  ipAddressesDetection: Enable
  ipAddresses:
    - 203.0.113.0/24
  ipAddressRestriction: Deny

実装例

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

ネームスペースの作成・取得や、ブロッキングポリシーの設定といった操作は、ゲームクライアントから直接呼び出すのではなく、以下のいずれかの手段で操作することを推奨します。

  • マネジメントコンソール
  • GS2 CLI
  • 各種言語向け一般SDK (C# / Go / Python / TypeScript / PHP / Java)
  • GS2-Deploy によるテンプレート管理

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

より実践的な情報

段階的なポリシー導入

新規にブロッキングポリシーを導入する際は、いきなり全項目を拒否設定にすると、想定外の正常なプレイヤーを締め出してしまう恐れがあります。 最初は検出のみ有効にし、ログから影響範囲を確認したうえで、段階的に拒否設定に切り替えていく運用が推奨されます。

サービスごとの例外設定

passServices を活用すると、特定のGS2マイクロサービスに対してはブロッキングポリシーを適用しない、といった例外設定が可能です。 たとえば、ログイン処理やバージョンチェックは厳しめのIP制限を緩めておき、課金やランキングなど不正の影響が大きいAPIにのみ厳しいポリシーを適用する、といった運用ができます。

詳細なリファレンス

GS2-Guard リファレンス