[レポート] Amazon Game Tech Night #14 〜ゲーム企業向け AWS セキュリティ〜 に参加してきました #AmazonGametech

こんにちは 園部です。

今回は、7月23日に開催されました Amazon Game Tech Nigh #14 への参加レポートとなります。 現地で聴きながら書いた内容となりますので、誤った理解や記載がある場合はご容赦ください（およびご連絡ください）。資料公開され次第確認を行う予定です。

7月26日に資料案内をいただきましたので、「資料：」欄に追記しています。

Amazon Game Tech Night

AWS でのGameに関するイベントを定期的に開催されています。

• Connpass
  
• Twitter

＃１４ イベント概要

いざセキュリティ対策に力を入れようとしても、次のような悩みに直面してしまうことはないでしょうか？

* セキュリティ対策としてやれることはいくらでもあるので際限がない。
* いろいろあって何から手を付けていいか判断できない。

このセミナーでは、上記のような悩みに対してはじめの一歩を踏み出すための AWS の知識と考え方を提供することを目的としています。またAWS利用事例セッションとして、株式会社ディー・エヌ・エー様にクラウドへの移行におけるセキュリティ面での取り組みについてお話しいただきます。

（引用： 募集サイト ）

ここから始めるAWSセキュリティ ~リスク可視化と分析による継続的セキュリティの実践~

• スピーカー： Senior Security Solutions Architect, Amazon Web Services Japan 桐山 隼人 さん
• 資料： 後日公開予定
  ここから始めるAWSセキュリティ

概要

AWSをご利用の皆様の中には、セキュリティ対策を何をどこまでやればよいか分からないという課題を抱えている方もいるのではないでしょうか？そのような方が最初にやるべきことは、何が適切なセキュリティ対策かを判断するために、今の環境を可視化することです。本セッションでは、AWS環境の可視化のために必要なステップを紹介します。AWSサービスの特長であるサービス連携と自動化を上手に使って、人手に頼らなくても済むような継続的なセキュリティを実践していきましょう。

（引用：募集サイト）

セッション内容

• タイトル 「ここから始める」 に込めた意味
  • これからAWS を始めるユーザーにとっては、多くサービスから、どのサービスがマッチするのかを悩まれるケースは多く、その悩みへの一つの回答としています
• 「継続的セキュリティ」
  • セキュリティ界隈ではバスワードであり、重要な内容です
• 継続的セキュリティ（Continuous Security）とは？
  • DevOps.com より
    • APIs で管理できるプラットフォーム
    • 自動化されている
    • CI/CD を提供
• 継続的セキュリティをやる意義
  • 環境変化適応
    • 対策は実施した瞬間から危殆化（きたいか）する
      • 外部環境は常に変化しているため、対策も常に必要
  • スピード
    • 現在では攻撃側の方がモチベーションが高い（金銭目的による影響）
      • 新しい技術・ツールが進化している
  • コスト最適
    • セキュリティへのコスト感覚は青天井の部分の面があり、それが一つの課題とされている
      • どこまで行うのが適正・適切の判別つけ難い
        • リスクベースのアプローチの活用
          • 発生した際のリスクを考え、その高低で対策を検討する
• セキュリティリスクの方程式
  • ３要素の掛け算
    • 脅威（Threats）
      • 有名にあることで対象とされるケースもある（オリンピックのスポンサーになった）
    • 脆弱性（Vulnerabilities）
      • セキュリティホールだけでなく、「設定ミス」や「（人の）心理的要素」もある
    • 情報資産（Assets）
      • 対象システムが扱っている情報資産によって必要な対策も異なる（例えば、生体情報は変更できないため重視される）
• リスク分析と可視化
  • リスク分析
    • 脅威分析：Amazon GuardDuty
    • 脆弱性分析： Amazon Inspector
    • 情報資産分析： Amazon Macie
• Amazon GuardDuty
  • AWSサービスの中でも、リリース後の成長率が高いサービスの一つ
  • 機械学習を用いたクラウドネイティブな脅威検知サービス
  • VPC Flow Logs, DNS Logs（R53）, API ログ（AWS Cloudtrail）をデータソースとして脅威を検出する
  • まずは有効にするのがおすすめ
  • Amazon GuardDuty では多様な種類の脅威を検出できる
• Amazon Inspector
  • ホスト型脆弱性診断サービス
  • 業界ベンチマークやCVEから設定リスクを評価する
  • エグゼクティブサマリー含めた評価レポート機能
  • エージェント導入が必要
    • エージェントレスでも評価できる項目が追加となっている（ネットワーク到達可能性のルール）
  • ネットワーク到達可能性とは？
    • ネットワークはシステム規模の拡大に比例して複雑となります
    • PCI DSS 1.3 Prohibit direct public access などでもコントロールを要求されている
      • 一般的に、外部との接続有無で重要度を判断するケースが多いが、そもそもその対象インスタンスがパブリックなのか？プライベートなのか？ を明確にするためにもネットワーク到達可能性チェックは有用です
      • 自動推論による評価を行なっている
        • AWSでは、Inspector 以外にも S3 パブリックリードチェックなどでも利用している
• Amazon Macie
  • 情報漏洩防止（DLP）＋ユーザー振る舞い分析（UEBA）
  • 個人特定情報（PII）、個人医療情報（PHI）、知的財産（IP)、ソースコード、認証情報をチェックする
  • ユーザーの振る舞い検知（いつもと違う。アクセス増）
  • 東京リージョンは未対応
• Security Hub
  • 以前は、上記のようなサービスをそれぞれチェックする必要があったが、それを一元管理する
  • リスク分析ダッシュボード
  • AWS環境のセキュリティ・コンプライアンス状態を可視化
• まずはここから - その1 -
  • AWS 環境におけるリスクを要素分解して可視化しよう
  • １. GuardDuty を全リージョンで有効か
    • 普段利用しないリージョンこそ攻撃者は狙っています
    • 従量課金なので何もなければ課金されない
  • ２. Inspector でEC2インスタンスを評価
    • エージェント導入して脆弱性診断
    • エージェント導入しなくてもネットワーク到達可能性評価は可能
      • 意図しないインスタンスが外部に接しているケースなどで早急に発見できる
  • ３. Macie でS3 にある重要データの棚卸
    • 特定リージョンのみ提供
  • ４. Security Hub でデータ集約して可視化
    • セキュリティ担当者の負担軽減
• リスクベースアプローチによる優先順位づけ
  • 現時点でのリスクの偏在を監視
  • リスクベースアプローチだけでは不足
  • ベースラインアプローチと合わせて行う（リスクベースアプローチとは補完的な関係）
    • コンプライアンスルール（業界標準、社内ルール）
• AWS Config
  • 構成変更を記録
  • Config（Rules） を利用したベースラインアプローチ
• まずはここから - その2 -
  • ５. Config で全リソースの設定変更記録を開始
    • ベースラインアプローチを行うための情報として取得
  • ６. Security Hub でCompliance Standards を有効化
    • Config も管理（2019年4月時点では CIS AWS Foundations のみ）
• Q. AWS Config アグリゲーターとSecurity Hub はどちらがおすすめですか？
  • どちらも似た仕組みを用いているので、優劣はなくケースによって採択するのが良いです
  • Security Hub はある程度処理をAWSに任せているので簡易利用が可能
  • Config アグリゲーターはある程度コントロールしたいケースにはフィットする
• ガバナンス
  • 監視と評価に基づく意思決定と指示
  • ガバナンス
    • AWS Organizations, AWS Single-Sign-On, AWS CodePipeline, AWS Service Catalog
    • 組織内で、ガバナンスが意識されるきっかけとしてアカウント増加が多い
  • セキュリティリスク
  • コンプライアンスルール
• マルチアカウント
• Landing Zone
  • AWS からの一つの回答
  • マルチアカウント戦略
    • AWS Organizations によるアカウント作成・管理
      • マスターアカウント
      • 共有サービスアカウント
      • ログ管理用アカウント（アーカイブ用）
      • セキュリティアカウント（常に監視用）
    • ログ管理用アカウントとセキュリティアカウントは別ける方がいい
      • 用途が異なる。同一にしている場合に、振る舞い検知において課題となる
  • Account Vending Machine（AWS Service Catalog）
    • デザインパターン
    • AWS Service Catalog を利用し、事前定義したリソース・ベースラインが適用されたアカウントを払い出す
    • 自動販売機に似たイメージ
  • セキュリティ管理者の通知
    • Security Hub でメンバーアカウントを登録し、カスタムアクションを設定する
    • CloudWatch Events が利用されている
• まずはここから - その3 -
  • ７. セキュリティアカウントを作成
    • AWS Oraganizations のマスターアカウントとは異なる
  • ８. Security Hub 上で監視対象のメンバーアカウントを追加
  • ９. Security Hub カスタムアクションでFindings の対応
    • まずは管理者への通知が第一歩
• Appendix
  • 次に何する
    • １. Findings の種類・量を見る
    • ２. Amazon SNS トピックで通知する
    • ３. アーカイブルールで、必要な Findings に絞る
    • ４. 既存システム（SEAMなど）のワークフローに統合する
    • ５. CloudWatch Events でLambda を実行し、コンテキスト情報を付加する
    • ６. CloudWatch Events でLambda を実行し自動処理する
  • 既存セキュリティツールと連携させたい
    • AWS Security Hub のパートナー
  • 脅威検知した後の対応を学びたい
    • AWS セキュリティワークショップ
  • 継続的セキュリティのユースケースを知りたい
    • AWS によるセキュリティ・オートメーションの実践
    • DevSecOps on AWS

雑感

AWSは非常に多くのサービスが提供されており、これから利用するユーザーだけではなく、既存利用者でも適切なサービスを選択するのは簡単ではないケースがありますかと思います。そのため、今回のような まずはここから というメッセージと内容は非常に有益な情報だと思いました。

また、セッション開始前に機器トラブルの間に、スピーカーで桐山さんがおっしゃっていた内容が個人的には非常響いた内容でした。

あるスタートアップのお客様（SRE）のインタビュー記事の中で、「AWSの環境がどういう構成になっているのか把握できことが理由で、積極的に新しい施策などの利用に踏み込めない」とコメントされていた。

• リスクがわからないと先に進めないという考え方自体は、本質的な部分（セキュリティだけでなくビジネスでも同様）である
• プロアクティブに進めれるチームや人は、リスクと限界（ここまではOK・NG、これを実行するとここに影響が出る）を把握している

もちろん色々な見方・意見はあるかと思いますが、私個人も自分の理解や責任の取れる裁量の範囲では大きく動くことはできますが、見えない部分やリカバリーには多くのリソースが必要なケースでは動きが鈍くなることがあります。仕方ないという結論ではなく、その部分を埋める＆カバー（仕組み、チーム体制、積極的にトライすることでの理解）することの大切さとナルホドという反芻しながら帰路につきました。

DeNA の AWS アカウント管理とセキュリティ監査自動化

• スピーカー： 株式会社ディー・エヌ・エー システム本部 IT 基盤部第一グループ グループリーダー 髙橋 祐真 さん
• 資料： 後日公開予定
  DeNA の AWS アカウント管理とセキュリティ監査自動化

概要

DeNA は 2018 年 6 月にメインのシステム基盤をオンプレからクラウドへ全面移行することを決定しました。AWS を大規模に利用していくにあたって、以下のような課題がありました。

・多数の AWS アカウントがあり管理が難しい ・セキュリティ標準がないため設定者によって差異がでる ・セキュリティ監査の工数が膨大にかかる

本セッションではそれら課題への対策として、多数の AWS アカウント、root アカウント、IAM の管理を効率化した方法に加えて AWS 利用におけるセキュリティ標準の策定やその監査を自動化した内容についてお話します。

（引用： 募集サイト）

セッション内容

• 課題背景
  • オンプレミスからクラウドへ全面移行中
  • クラウドに最適化したシステム基盤への設計・実装を実施
  • クラウド利用時の本格的なセキュリティ環境整備を実施
• 組織構成
  • DeNAでは多様なサービスを提供している
  • 各サービス開発はそれぞれの環境、インフラ部門＆監査実施部門が共通的を対応している
• 環境整備の必要性
  • 増加するアカウント管理
  • 利用者によるセキュリティレベル差異
  • セキュリティ監査コストが増加
• 増加するアカウント管理が難しい
  • AWSアカウント管理
    • 一元管理と開発自由度の両立が重要
      • Organizations によるマルチアカウント管理
      • 請求、RI共有、SCP を活用
      • マスターアカウント、ロギングアカウント、監査アカウント、各種共有サービスアカウント（ネットワーク、CDN、DNS、踏み台）
      • 最低限守るべきラインを引いて、あとは開発に任せることでビジネススピードを落とさない
    • システムアセット管理システム
      • 社内利用のパブリッククラウドのアカウントを管理
      • AWSアカウントでは、「案件名」、「利用部門」、「担当グループ」、「連絡先」 などの情報を管理
      • 社内パブリッククラウドアカウントのマスタとして 管理会計や監査時にも利用
        • API での（参照）利用
    • アカウント作成の粒度や命名規則のガイドラインを作成
      • 命名規則
      • 粒度
        • サービス・プロジェクト単位で作成
        • 開発・本番もアカウントで分割作成
      • アカウントの連携
        • VPC Peering は原則利用しない
          • コントロールできない
        • Transit Gateway でコントロール
        • API経由は許可
    • アカウント作成はインフラ部門
      • コマンドによる自動化
      • 初期設定を定義（MFAなど）
    • 設定が変更されていないかを監視
  • root ユーザー管理
    • 課題
      • 異動や退職者対応
      • 長期利用アカウントでの紛失
    • 対策
      • root は利用禁止
      • root はインフラ部門が一括管理
  • IAM ユーザー管理
    • 課題
      • 棚卸しがつらい
    • 対策
      • 社内のディレクトリ連携をした管理
• 利用者によるセキュリティレベル差異
  • 課題
    • 利用者の理解・習熟度によってレベルにばらつきが出ている
  • 対策
    • 社内向けのAWSセキュリティガイドを作成
    • DeNA にあるポリシーを守るためにリスト化したもの
    • サービス、要件、推奨レベルを付与している
• セキュリティ監査コストが増加
  • 監査自動化システムの実装
    • 低コストで運用を実現
    • CLIで情報取得
    • 通知先はアカウント管理者
    • 自動化が難しい項目はコンソールから直接確認

所感

私自身は現在自社サービスを担当してはいませんが、あるあるという内容が沢山盛り込まれた内容だったのではないでしょうか。そして、それらに対して目的（ガバナンスとアジリティを確保した）を持って対策を検討・実施（時には内作まで）されており、素晴らしいと個人的には思いました。「システムアセット管理システム」や「ガイドライン」 はもう少し見てみたかったです。

今回は以上となります。