ゲームセキュリティ

「すべては脅威モデルから始まります」。

脅威モデリングに取り組み、記事の項目 9 に到達したら、リスクとオーバーヘッドのバランスも考慮します。リスクは、残留リスク (「事業を遂行する上でのリスク」の一部として受け入れられているもの) と重大なリスク (残留リスクにするには補償コントロールの適用を必要とするもの) に分けられます。記事で説明されているように、満足のいく程度にまでリスクを軽減するためのポリシーや、技術的および手続的なコントロールを構築および分類し (その過程で、規則および法令の要件に基づくコントロールを組み込みます。これらは、法務チームによる解釈に基づいて構築する必要がある可能性があります)、これらのコントロールを、その実現に役立ち得るサービスや機能にマッピングします。 

次のものは、このマッピングの作成に役立ちます。 

• AWS コンプライアンス
  
• セキュリティの柱 - AWS Well-Architected フレームワーク
  
• 管理とガバナンスのレンズ
  
• Game Industry Lens - AWS Well-Architected

独自のコード、AWS のサービス、そして時にはオープンソースコードを使用して自社に提供することを希望する機能もありますが、自ら管理したくない機能や AWS のサービスの範囲外の機能については、これらの機能の提供を目的としてビジネス上の関係を確立しようとするパートナーを特定するため、ポリシーとコントロールのフレームワークを使用します。例えば、ゲームにおいて、ユーザーが環境に対して認証しなければならない場合、どのフェデレーテッド ID プロバイダーをサポートする予定ですか? 

SELinux 機能プロファイル以外のインスタンス上のマルウェア対策ツールを実装することをコントロールフレームワークが要求しているために EC2 を使用している場合、インスタンスのグループを自動でスケールアップおよびスケールダウンする必要がある可能性があることを念頭に置くと、要件を満たすために、AWS Marketplace ではどのようなツールを入手できますか? 

趣味として、または暇なときに AWS の探求を開始したのではない限り、学習、開発、構築、テスト、デプロイを実行するために、さまざまな環境とそれらが保持するデータを適切に相互分離した状態を維持しつつ、適切に設計されたマルチアカウント環境が必要になります。 

マルチアカウントを使用した AWS 環境の整理を実行し、マルチアカウント構造を設計します。ゲームによってはクライアント以外のリソースを大量に消費する可能性があるため、お客様がこのようなゲームをお持ちの場合は、ゲームの人気が高まったときに、どの程度迅速に環境をスケールする必要があるかを検討します。 その方法は、ゲームがホストされている AWS のサービスの種類によって異なりますが、アカウントごとのサービスクォータには常に注意してください。 コントロールフレームワークが要求する場合は、「AWS Best Practices for DDoS Resiliency」(DDoS レジリエンシーに関する AWS のベストプラクティス) ホワイトペーパーに概説されているように、DDoS 緩和策を Organization 全体でデプロイします。

これで、Organizations のポリシーでタグ付け戦略を定義および強制し (「タグポリシー」を参照)、ポリシーと脅威モデルに基づいてモニタリングとインシデント対応のフレームワークを設定する準備が整いました。これには、特定のニーズとは無関係な検出結果の抑制も含まれます。 

インシデント対応フレームワークの推奨事項については、この「AWS Security Incident Response Guide」(AWS セキュリティインシデント対応ガイド) を参照してください。特定のインシデントのシナリオ向けのサンプルランブックは GitHub で入手できます。 

選択した対応ポリシーに、モニタリングイベントに基づいて自動化できるアクティビティが含まれている場合、その実現に役立つフレームワークおよびオートメーションのセットについては、「AWS Security Hub Automated Response and Remediation」(AWS Security Hub の自動化された対応および修復) 実装ガイドを参照してください。