AWSで今日から始めるゲームのセキュリティ対策

こちらは[AWS for Games Advent Calendar](https://qiita.com/advent-calendar/2022/aws-for-games) 16日目の記事です。

# はじめに
ゲーム業界の皆さん、セキュリティ対策はしていますか？一口にセキュリティ対策と言っても、その幅は広く、何から始めたらいいのかわからないという方も多いのではないでしょうか。この記事では、そんなあなたでも今日からすぐに始められるAWSのセキュリティ対策を、「インフラ」「アプリケーション」それぞれの観点からご紹介します！

(免責) 本記事の内容は個人の意見であり、所属する企業や団体を代表するものではありません。

# インフラのセキュリティ
「インフラ」という言葉が指すものは、時と場合によって変わりますが、ここでは、アプリケーションレイヤー以外の全てのことを指すこととします。つまり、インフラのセキュリティとは、トラフィックの制御などネットワークレイヤーでの保護や、暗号化によるデータの保護、そしてAWSのアカウント保護など、たくさんのやるべきことを含んでいます。

そんな広範囲のセキュリティ対策にあたって、まずすべきことはなんでしょうか。それは、**セキュリティチェックによるリスクの可視化**です。現状のシステムが抱えているリスクを明らかにし、取るべき対策の優先順位やどこまでやるかを判断していくことが最初のステップになります。

また、オンラインゲームはリリースして終わりではありません。ゲームのイベントやアップデートに伴って、サーバーの機能追加や構成変更が継続的に行われていきます。さらに、新たなマルウェアの出現や脆弱性の発見など、ゲームを取り巻く環境も変わっていきます。つまり、リリース時にはなかったリスクが後から出てくる可能性もあるということです。セキュリティチェックによるリスクの可視化は、最初のステップであり、継続的に行なっていくべきことでもあります。

そして、そのためにおすすめするのが、[AWS Security Hub](https://aws.amazon.com/jp/security-hub/)を使用したセキュリティチェックです。

## AWS Security Hubとは
AWS Security Hubは、AWSのセキュリティチェックの自動化およびセキュリティ検出結果の集約を行うことができるサービスです。

Security Hubを使用すると、AWSのリソースがセキュリティのベストプラクティスやフレームワーク(セキュリティ標準)に沿っているかどうかを**自動で継続的に**チェックすることができます。Security Hubでは以下のセキュリティ標準に対応しています(2022/12/15現在)。AWS基礎セキュリティのベストプラクティスは、AWSのセキュリティエキスパートによって精査されたセキュリティのベストプラクティス集です。
* AWS基礎セキュリティのベストプラクティス
* CIS AWS Foundations Benchmark
* PCI DSS

また、Security Hubは、他のAWSサービスやAWSパートナーのセキュリティソリューションによって検出されたセキュリティアラートを集約し、改善のためのアクションにつなげることができます。

## AWS Security Hubの有効化
Security Hubを使ったセキュリティチェックは、ほんの数ステップで開始することができます。

1. AWS Configの有効化
Security HubはセキュリティチェックにAWS Configを使用するので、Security Hubを有効化する前に、AWS Configでリソースの記録を有効化しておく必要があります。

1. チェックするセキュリティ標準を選択
AWSが提供するセキュリティ標準のうち、チェックを行うものを選択します。これは後で変更することができます。迷ったらまずはAWS基礎セキュリティのベストプラクティスを有効にすると良いでしょう。
![](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2958281/176baf82-a350-16f9-0c5b-78d799bc5c5a.png)


1. 上記のステップをAWSリソースが存在する全てのリージョンで行う
Security Hubは、他の多くのAWSサービスと同様に、リージョン単位のサービスなので、セキュリティチェックを行うリージョン全てにおいて有効化する必要があります。
セキュリティチェックの結果もリージョンごとに出力されますが、指定したリージョンに集約してまとめて確認することができます。

## セキュリティチェックの結果を確認
セキュリティ標準を有効化すると、2時間以内に全てのセキュリティチェックが開始されます。しばらく待ってから、結果を確認してみましょう。
コンソール画面の`セキュリティ基準`から、各セキュリティ標準のセキュリティスコアを確認することができます。`結果を表示する`をクリックすると、各項目についての結果を確認することができます。
![](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2958281/48f43725-4327-5d68-cef2-53947ab75d75.png)
![](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2958281/20c86dea-1886-a315-4999-66267f801582.png)

項目のタイトルをクリックすると、リソースごとの結果を確認することができます。また、`修復手順`からこの問題を修復するためのドキュメントを参照することができます。
![](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2958281/61a5025a-e74a-c587-7cb2-e850badb7493.png)

このようにして、Security Hubのセキュリティチェックによってリスクを可視化することができました。

## セキュリティチェックの結果をレビュー
Security Hubによってセキュリティチェックを行ない、リスクを可視化することはできました。しかし、これで終わっては意味がありません。重要なことは、セキュリティチェックの結果をもとに、セキュリティ対策をどこまでやるか、どれからやるかを決めることです。そのために、検出結果をレビューしましょう。

まず、`コンプライアンスのステータス`が`失敗`となっていて、項目の重要度が高いもの(`CRITICAL`や`HIGH`)のものから対処していくと良いでしょう。
![](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2958281/147cbcea-12a4-2c5e-bbed-90f70a4523a4.png)

レビューを進めていくと、重要度が低く、会社のルールにそぐわないものや、AWSの利用状況に合わない項目が出てくると思います。そういったものは、対応が必要か検討した上で、個別に項目を無効化しましょう。項目の無効化はセキュリティチェックのコストを最適化するだけでなく、関連性の低い検出結果の海に溺れることを防ぐ効果もあります。
![](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2958281/8410861e-6256-9320-9f6d-841baa8e9a51.png)

このようにして、対応すべき項目を決定し、それに応じたセキュリティチェックが実施されるように設定をしましょう。

## 継続的なチェックと対応
Security Hubは、セキュリティチェックを継続的に行なってくれます。セキュリティチェックが行われるタイミングはリソースによって異なりますが、定期的に行われるものと、リソースの変更が行われた時に行われるものがあります。
`コンプライアンスのステータス`が`失敗`となったものについては対応し、常にセキュアなAWS環境を保ちましょう。

また、Security Hubが提供するセキュリティ標準も随時更新されます。項目のレビューも定期的に行なうとよいでしょう。

## より便利な使い方
今回ご紹介したのはSecurity Hubの基本的な使い方です。はじめにご紹介した他のソリューションとの統合や、検出結果に対する自動修復の実行など、さらに便利な使い方もあります。詳しく知りたい方は、[Security Hubのドキュメント](https://docs.aws.amazon.com/securityhub/latest/userguide/index.html)をご確認ください。

# アプリケーションのセキュリティ
ゲームのワークロードにおいて、アプリケーションレイヤーの脅威にはどんなものがあるでしょうか？ここでは、DDoS対策とBot対策にフォーカスしてご紹介します。

## DDoS対策
まず、DDoS攻撃とはどんな脅威でしょうか？[AWSの公式サイト](https://aws.amazon.com/jp/shield/ddos-attack-protection/)ではこのように説明されています。
> サービス拒否 (DoS) 攻撃は、正当なエンドユーザーに対するウェブサイトやアプリケーションなど、対象システムの可用性に影響を与える悪意のある試みです。通常、攻撃者は最終的に標的システムを圧倒する大量のパケットまたはリクエストを生成します。分散型サービス拒否 (DDoS) 攻撃の場合、攻撃者は複数の侵害または制御されたソースを使用して攻撃を生成します。

つまり、Webアプリケーションに対して、分散された複数のリソースを使用して大量のリクエストを送り、アプリケーションをスローダウンさせたり、停止に追いやったりする攻撃です。攻撃に使われるリソースを確保する手段として、ボットネットが使われるケースもあります。

このDDoS攻撃は、攻撃対象となるネットワークレイヤーによって大きく以下の2つに分類することができます。
* インフラレイヤー(L3/L4)への攻撃
* アプリケーションレイヤー(L6/L7)への攻撃

それぞれAWSではどんな対策ができるでしょうか。

### インフラレイヤーへの攻撃対策
こちらはインフラのセキュリティに該当する部分ですが、ここで簡単に紹介します。
AWSには[AWS Shield](https://aws.amazon.com/jp/shield/)というDDoS攻撃に対する保護を行うマネージドサービスがあります。
このサービスにはStandardとAdvancedの2つのTierがありますが、このうちStandardはAWSにデフォルトで組み込まれています。つまり、**AWSを使っているだけでDDoS攻撃からの保護を受けられる**ということです。Shield StandardはL3/L4を対象に発生するSYNフラッド攻撃やリフレクション攻撃といった一般的な攻撃からの防御を提供します。

### アプリケーションレイヤーへの攻撃対策
HTTPフラッド攻撃など、アプリケーションレイヤーを標的にしたDDoS攻撃も存在します。これらの攻撃では、ネットワークやアプリケーションサーバーだけでなく、データベースなどシステム全体に高い負荷がかかることがあるため、注意が必要です。
アプリケーションレイヤーへの攻撃対策としては、Web Application Firewall(WAF)の活用が有効です。AWSでは、[AWS WAF](https://aws.amazon.com/jp/waf/)というマネージドWAFサービスが提供されていますので、これを活用するというのが対策の最初のステップになります。

## Bot対策
一般に、Botと呼ばれるものにはどんなものがあるでしょうか？例えば、検索エンジンのクローラーや、Webサイトの外形監視に使われるプログラムがこれに含まれます。これは善良なBotの例ですが、不正ログインや脆弱性スキャンなどを目的とした悪意のあるプログラムもBotと呼ばれます。
これに加えて、ゲームの世界では、ゲームのアカウント作成やゲームプレイを自動で行うことを目的として、ゲームのAPIなどを直接操作する非正規のクライアント(ここではGame Botと呼ぶことにします)も存在します。Game Botも他のBotと同様にサーバーに必要以上の負荷をかけたり、一般プレイヤーのゲーム体験を損なったりすることがあり、ゲーム開発者は対策を求められます。

Bot対策として一般的なのは、WAFなどによってトラフィックを検査しシグネチャベースでBotトラフィックを防御する方法や、CAPTCHAを利用する方法などがあります。誰しも一度は、会員登録の際に読みづらい文字を入力させられたり、「私はロボットではありません」というチェックボックスをクリックさせられた経験があるのではないでしょうか？
![](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2958281/22b8c3b3-fc77-a618-5189-dfce917b48cc.png)

### Botとマクロ
ゲームの自動プレイを行うために、マクロツールを使って操作を記録し、それを再生するという行為が存在しますが、この記事ではこれをGame Botと区別して考えます。マクロによるゲームプレイは正規のクライアントを使用しているなどの理由から通常のプレイヤーと区別しづらく、Game Botとは異なる対策をとる必要があります。

## AWS WAFによるDDoS・Bot対策
ここからは、AWS WAFを使ってすぐにできるDDoS・Bot対策をご紹介します！

### AWSマネージドルールの活用
AWS WAFでは一般的な脅威からアプリケーションを保護するために事前に設定されたルール(AWSマネージドルール)が提供されており、すぐに使い始めることができます。
ここでは、AWSマネージドルールからDDoS・Bot対策に使えるものをいくつかピックアップしました。
* 既知の不正な入力マネージドルールグループ
入力として無効なことがわかっており、脆弱性の悪用や発見を試行するような入力のパターンを検出することができます。例として、Log4jの脆弱性を悪用しようとする入力などが挙げられます(まだ記憶に新しいですね)。脆弱性を悪用しようとするBotからの保護に役立ちます。

* Amazon IP評価リストマネージドルールグループ
Amazon内部の脅威インテリジェンスをもとに、BotやDDoSなどの脅威に関連づけられているIPアドレスを検出することができます。

* 匿名IPリストマネージドルールグループ
Torノードなどクライアントの情報を匿名化することがわかっているソースのIPアドレスや、ホスティングプロバイダーおよびクラウドプロバイダーのIPアドレスを検出することができます。一般ユーザーのリクエストは通常こういったIPアドレスからは送信されないので、DDoS・Bot攻撃の緩和に役立ちます。

* AWS WAF Bot Controlルールグループ
IPアドレスやユーザーエージェント文字列などをもとに、Botと思われるトラフィックを検出します。ここで検出されるBotには、検索エンジンのクローラーなど善良なBotも含まれ、個別にトラフィックを制御することができます。また、AWSによって善良であると検証されたBotはデフォルトでブロックされませんが、他のトラフィックと区別するためのラベルが付与されるため、ラベルをもとにブロックすることもできます。
![](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2958281/2f4cdac8-c366-9285-9b66-4abd2910703c.png)

### レートベースのルールの活用
AWS WAFを使用して、高いレートでリクエストを送信するIPアドレスを検出することができます。具体的には、5分間あたりのリクエスト数の上限を設定し、それを超えるリクエストを送信したIPアドレスからのトラフィックを検出します。これは、DDoS攻撃や、高いレートでリクエストを送るBot攻撃の緩和に役立ちます。
![](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2958281/b057cfbd-f92f-7c8e-88b1-e05d99734fac.png)

### AWS WAF CAPTCHAの活用
各種ルールによって検出されたリクエストに対して、CAPTCHAによるテストを行うことができます。ゲームのAPIサーバーはプログラム(ゲームアプリ)からアクセスされることが普通なので適用するのは難しいですが、Webページ上でホストされるゲームに対するBot攻撃の緩和に役立ちます。(画像は[AWS公式ドキュメント](https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/waf-captcha-challenge.html)から引用しています)
![](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2958281/2d7702f5-0273-f257-7e9b-daf3eb8c65ce.png)

## カウントモードの活用
WAFによって、正規のクライアントからのリクエストが不正である(偽陽性)と検出されるというケースがあります。偽陽性によってトラフィックを遮断してしまうと、善良な一般ユーザーに影響が出てしまうことになります。したがって、WAFを導入する際には、偽陽性が発生しないように十分注意する必要があります。
事前の検証を行う際や、本番環境で偽陽性が発生してしまった場合の緩和策としては、カウントモードが有効です。これは、各種ルールによって検出されたリクエストに対して、リクエストの許可もブロックも行わず、ラベルを付与するというものです。カウントモードにしたら、アクセスログを記録してリクエストの詳細を見ながら、追加で行う対応を決めると良いでしょう。

# まとめ
この記事では、今日からすぐに始められるAWSのセキュリティ対策として、Security Hubを使用したセキュリティチェックとWAFを利用したDDoS・Bot対策をご紹介しました。もちろん、セキュリティ対策の道のりはこれで終わりではありません。今日皆さんは長い道のりの第一歩を踏み出したのです。私も道半ばですが、皆さんと一緒にゲームのセキュリティについて考えていきたいと思います。頑張っていきましょう！