はじめに
この文章は技術書典7で頒布されたCookpad Tech Book に寄稿させてもらったものの転載になります。基本的に加筆などはしていませんが、一点だけSecurityHubに関する記述に間違いがあった（自動通知の機能がない、という誤った情報を記載していた）のでその点だけ修正しています。
御存知の通り、2019年12月初旬に開催されたAWS re:Invent 2019において色々な新しいサービスが発表されました。なかでもAmazon Detective やAmazon Fraud Detection はセキュリティ関連サービスの中で注目すべき存在になっており、今後のAWS セキュリティ監視の中で重要なポジションになる可能性があります。この文書は2019年9月ごろ書かれたものなので当然それらの内容には触れていませんが、それについてはまたいずれ別の形でアウトプットしたいと考えています。
クラウド の時代になってもセキュリティのやっていきは必要です。クラウド 上だと多くのマネージドサービスが提供されているためオンプレミスの環境よりもセキュリティの機能を実現しやすい側面はありますが、それでもまだすべてを頼り切ってよいほど進化しているとはいえないのが現状です。やらないといけないセキュリティの機能はさまざまですが、ここではAWS 、およびセキュリティ監視（セキュリティ被害の発生の兆候を検知し分析すること）に焦点を当てて、マネージドサービスを活用したセキュリティ監視の小さなはじめかたについて解説したいと思います。また、マネージドサービスの初期設定方法についての解説は世の中に多くありますが、継続的に使っていくためにはどうすればいいか？ということを説明したものはあまりないため、ここではそういった運用に焦点をあてて説明します。
セキュリティ監視
この文章における「セキュリティ監視」とは「自分達が運用しているシステムやサービスに発生しうるインシデントの兆候を検知し、それを分析して監視対象の環境に影響があるかを判断すること」とします。
インシデントとはある人物による作為的な攻撃によって、システムやサービスに何かしら変化が発生し、それによってビジネスや仕事に悪い影響が発生することとします。
わかりやすい例として、業務用PCがマルウェア に感染してしまったり、サービスに侵入されてしまう、という状況を想像してもらえるとよいかと思います。
侵入口を潰したり攻撃そのものを遮断したりする「防御」とは異なり、何かが起きた際にそれを迅速に発見し対応できるようにすることを目的としています。
なぜセキュリティ監視するのか
はじめにそもそもなぜセキュリティ監視が必要なのか？という理由について簡単に説明したいと思います。
すべての攻撃を完璧に防ぐのは不可能である : 「監視などするまえにそもそも防いでしまえばいいのでは」という説はありますが、システムに侵入しようとする攻撃の手法やそれをとりまく環境は日々変化し続けており、それに完璧に追従するのは困難です。特に攻撃に利用される脆弱性 は次々と新しいものが発見されており、長年使われていたオープンソース のソフトウェアでも例外ではありません。攻撃を防ぐためにはどのような攻撃がくるかということをあらかじめ知っている必要があり、日々状況が更新されていくような環境では防御だけにすべてを頼るのは厳しいといえます。防御の対策は利便性を阻害しがちである : それでも防御を重要視していこうとすると、今度はユーザーの利便性が阻害されてしまいます。防御とは攻撃と疑われる行為を発見したらそれを止める対策です。防御でなるべく多くの攻撃を止めようとすると、ちょっとでも不審な動きがあればその動きを遮断するような方向に調整しなければなりません。それによって正規のユーザーによる正常な動作も不審とみなされてしまい（これを False Positive と呼びます）システムやサービスへのアクセスを止められてしまいます。極端な例として、パスワードを一度間違えたら1日はアクセスできなくなってしまうサービスを想像してみてください。うかつなパスワードを設定していても突破される可能性は低くなりますが、本来のユーザーによる正規のアクセスも妨げてしまいます。もちろんこのような措置が必要な場合もありますが、多くの場合は利便性とのバランスを考えなければなりません。
以上の理由により、防御となる対策を入れることはもちろん重要なのですが、防御だけですべての攻撃から守ろうとするのはあまり現実的ではありません。監視と併用することによって利便性、安全性、コストのバランスのとれたセキュリティを実現していくことができるようになります。
セキュリティ監視を構成する「検知」と「分析」（と「対応」）
セキュリティ監視というプロセスは主に「検知」と「分析」、そして「対応」という3つのフェイズからなっています。これらはそれぞれがキッチリと分離しているわけではなく、検知と分析が被る部分、分析と対応が被る部分がそれぞれあり、互いに影響しあっていると考えてもらえればと思います。
aa
セキュリティの製品やサービスでは検知に特化したもの、分析に特化したもの、両方の性質を兼ね備えたものなど、いろいろな種類のものがあります。ただ、今回は特に検知と分析がそれぞれわかれたサービスについて説明します。
用語の定義
インシデント : ある人物による作為的な攻撃によって、システムやサービスに何かしら変化が発生し、それによってビジネスや仕事に悪い影響が発生することイベント : サービスやシステム内で発生する事象を一括にした呼び方。Webサービス へのアクセスからプロセスの起動など、粒度はさまざまアラート : セキュリティ監視のためのプロダクトやサービスが、インシデントの可能性があるイベントを発見し、それについて発報したものログ : イベントとして発生した事象の詳細を記録として残したもの
セキュリティ監視の説明に出てくる要素の関係性。抽象化しているためこのモデルに当てはまらないものもあるが、おおよその関係性ということでご容赦願いたい
検知
監視している対象のサービスやシステム内で発生したイベントの情報から、セキュリティ上問題がある事象をみつけだすことを「検知」とします。たとえばアンチウィルスソフトウェアはディスクに保存されたファイルの内容からマルウェア を検知するというのが分かりやすい事例かと思います。他にもイベントが記録として残ったログを集めて分析し、不審な行動を探し出すSIEM（Security Information and Event Manager）も検知の機能があるといえます。また、機械ではなく人間がログや現在進行中のイベントなどをみて根性で怪しい現象に気づく、というのも検知にあたります（定常的にこれをやるのはあまりお勧めできません）。
しかし、これらはあくまで「可能性」であり実際にサービスやシステムに影響を及ぼしていると断定した形で報告されることは稀です。そこで、発見された事象が本当にインシデントなのかを判断する作業が必要になります。
分析
検知された事象が実際にサービスやシステムに影響を及ぼしたのかを調べるのが「分析」です。検知のためのサービスやプロダクトはインシデントの可能性が高い事象を発見してくれますが、これはあくまで可能性にすぎません。
本来は検知の段階でインシデントであることを確定させてから通知してくれればいいのですが、残念ながら現代のセキュリティ監視のサービスやプロダクトをそのまま使うだけでインシデントを正確に発見するのは困難です。
これはなぜかというと、組織ごとにルールやサービス・システムの運用方法の違い、業務内容の違いがあるからです。
たとえば、AWS のコンソールに普段は見られない国に所属しているIPアドレス からのアクセスがあり、ログインに成功したとします。
後述する Amazon GuardDuty はこういった通常見られない不審なアクセスをアラートとして発報してくれます。
このアラートではIDとパスワードなどの認証情報が盗まれ、第三者 が不正にAWS のコンソールにログインした可能性を示唆しています。
では、このアラートがあがった時点でそれをインシデントと断じることができるでしょうか。
ある組織のルールとして「業務は必ずオフィス内で実施すること」と決まっていたとしたら、自国外からのログインはかなりの確度でインシデントとみていいでしょう。
しかし、リモートワークが前提の組織であったとしたらどうでしょうか。スタッフは場合によっては他の国にふらっと旅行にいって、旅先で仕事をしているかもしれません。
そうした場合、通常と違う国からのアクセスが一概に危険とは言い難いです。また、ルールが厳しい前者の組織であってもたまたま出張にでていて例外としてアクセスしていた可能性もあります。
このように組織のルールや内部事情などによって発見された「インシデントの可能性があるもの」が本当にインシデントなのかを、他のデータと突き合わせながら判断するフェーズを「分析」と呼んでいます。
分析では業務内容などに照らし合わせてアラートの判定をする他に、サービスやシステムのログをみてアラートの内容を精査するというアプローチがあります。
さきほどの例から考えると、直接本人に「今、旅行中ですか」と尋ねる方法もありますが、一方で他の社内システムのログを検索することで「しばらく前からいつもと違う国で仕事していたのだな」ということを確認できます。（もちろん、AWS へのアクセスとその社内システムの認証系が別になっていることが前提ですが）
他にも「ある人物による不審な動きが観測された」というようなアラートがあったときに、具体的にどういった動きがあったのかを確認できれば、それが通常の業務の範囲内なのか、それとも逸脱した行為をしているのかということを判断できます。
こういった判断を重ね、発報されたアラートから本当に自組織に対して被害を及ぼすインシデントを発見する、というステップが必要です。実際にインシデントと判断できるものを発見した場合、「対応」のフェーズに移っていきます。
対応（余談）
「対応」は実際に何かしらの被害が発生した際、被害状況をまとめる、被害を軽減する、被害から回復させるといった行動です。
もちろんこれはサービスやシステムを運用する上で重要な対策ではあります。
ただ、やり方がサービスやシステムの構成に大きく依存しており、さらに直接的にこれを支援するAWS のサービスは（今の所）あまりないようなので、今回の解説からは省きます。
ただ今回ひとつ触れておきたいのは、冒頭で述べたとおり分析と対応はきれいに分離されている訳ではない、ということです。
実際の現場では、インシデントと確証はないがかなり怪しいとなったら影響の少ない範囲ですばやく対応を開始する場合も多いです。
これについては筆者もそこまで経験が豊富ではないためあまり多くは語れませんが、発生している事象のリスクと周りに対する影響などを判断しつつ、バランスをとりながら対応することは必ずしも容易ではありません。
セキュリティ監視に使えるAWS サービスとその役割
前置きが長くなりましたが、今回のテーマである「セキュリティ監視を既存（2019年9月現在）のAWS でどうミニマムに実現できるか？」に話を移していきたいと思います。
「AWS セキュリティ」でググってみていただくと分かると思いますが、当然ながらセキュリティは監視だけにあらずで、さまざまなサービスがでてくると思います。
今回はここまで説明した監視だけに絞り、サービスそのものと構成の例について説明したいと思います。
まず次の4つのサービスについて簡単に説明します。各サービスの詳細についてはそれぞれ公式ドキュメントをご覧ください。
検知に役立つAWS サービス
Amazon GuardDuty はAWS 上で起こる不審な挙動を検出してくれるサービスです。
詳細な動作について細かなアルゴリズム などは公開されていませんが、一部設定のセキュリティ上の問題をみつけてくれる他、機械学習 を利用して通常と異なる動作（EC2インスタンス による普段と異なる通信、AWS コンソールへの不審なアクセス）を検知してくれます。
具体的な検知内容については https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html をご覧ください。
GuardDutyは基本的にはCloudTrailのログ、VPC Flow Logs、そして内部DNS の問い合わせデータを利用して検知をしており、それらのデータから見えないイベントは見ることができないようです。
たとえば、インスタンス 内部に悪性プログラムが静かに潜んでいるのを検出するといったようなことはできないはずです。（通信が発生すれば別ですが）
そのためAWS 内で発生するすべてのインシデントを網羅できるわけではないのですが、
それでもCloudTrailから見えるAWS リソースの操作、
およびVPC 内部での通信状況に関しては監視できるため、
AWS 利用の中でそれなりに大きな部分をカバーできるといえます。
また、利用料金も全体のAWS 利用料のおおよそ1%程度になるといわれており、
一般的な商用セキュリティサービス・プロダクトに比べてかなりリーズナブルになっています。
AWS Security HubAWS Security Hub はGuardDutyをはじめとするAWS 、あるいはサードパーティ のセキュリティ監視検知結果を統合する機能を持っています。
また、AWS のベストプラク ティスを元にしたCIS（Center for Internet Security）ベンチマーク という機能もあり、AWS 上のセキュリティ関連設定の不備について通知してくれます。
AWS Security Hub はそれ自身が検知をする機能を提供しているわけではないのですが、サードパーティ のセキュリティ監視サービスやプロダクトからのアラートを統合してくれる点に強みがあります。
セキュリティ監視をするうえで手間がかかることのひとつは複数のサービスやプロダクトを利用する際に、ちゃんと統合して使えるようにすることです。
これはSIEM（Security Information & Event Manager）という製品がより上位の機能を提供しているので、状況によってはSIEMを使ったほうがよいかもしれませんが、Security Hubの方が機能が限定的な代わりに多くの場合SIEMより安価なので、今回は Security Hubを軸として説明します。
仮にGuardDutyしか使っていない状況だったとしても、今後セキュリティ監視に利用するサービス・プロダクトを容易に追加するために最初から導入しておくのがお勧めです。
分析に役立つ（データを蓄積してくれる）AWS サービス
AWS 上で分析をするにあたり、なるべく多くのログを保存できたほうがいいのはいうまでもありません。
しかしサービスなどから出力されるログは環境によってまちまちで、一概に説明するのは難しいものです。
そのため、ここでは共通して利用したほうがよいサービスについてのみ解説します。
CloudTrail
CloudTrailはAWS 上での操作をAPI 単位で記録するサービスです。
AWS ではコンソールを含むすべての操作がAPI 経由で実行されており、そのログを追うことでどのリソースがいつ作成、変更、削除されたのかを追いかけることができます。
CloudTrailはAWS 上でのユーザーの挙動を追跡したり、リソースに関する履歴を調べるのに役立ちます。
アラートの分析をしていると「このユーザーは何をしようとしていたのか」「このリソースはいつ誰が作ったのか」などを確認する必要がたびたびあります。
そのユーザーやリソースについて自分達が記憶していたり、すぐに聞いて分かる状態であればいいのですが、ちょっと前のことになると人は記憶を失ってしまうため、ちゃんとログに頼って検証できる状態にしておくのが望ましいです。
CloudTrailは利用しているアカウントの全リージョンに対し一括有効化できる機能があるため、ひとまず有効化しておいてよいサービスかと思います。
VPC Flow LogsVPC Flow LogsはVPC 内の通信を記録してくれるサービスです。
記録と言ってもその名のとおりフローの情報 のみ、つまり送信元IPアドレス 、宛先IPアドレス 、ポート番号、転送データ量、パケット数、といったような通信の一部の情報のみで、通信の内容については取得されません。
もし通信の内容を取得したい場合は、VPC Traffic Mirroringを利用できます（詳しくは @{Webサービス へのログを取得する} で解説します）
VPC Flow Logsは現状だと一括で有効化する方法は提供されておらず、VPC ごとに個別に設定をしていく必要があります。
全VPC で設定を有効化したい場合は、AWS Configを使ってFlow Logsが有効になっていないか探すか、（手前味噌ですが）次のようなツールを使って一気に有効化するというのがよさそうです。
AWS におけるセキュリティ監視の構成例では、実際にこれらのサービスをどのように使うかを、検知と分析それぞれの観点から説明したいと思います。
それぞれのサービスを有効化する方法などは公式ドキュメントやWeb上の記事に多く解説がありますので、ここでは触れません。
代わりにどのような構成で使うのがよさそうかという、筆者の視点からみたベストプラク ティスについて説明します。
検知のための構成
検知のための構成
検知をするためのお勧めの最小構成が上記の図です。
Security Hubを中心として、GuardDutyを有効にし、さらに他のセキュリティ監視サービスやプロダクトを使っており、Security Hubとの統合機能が提供されているのであれば、それも統合していきます。
GuardDutyは有効化されていれば自動的に統合されるはずですが、念のためSecurity HubのSummaryページから統合されているか確認してみてください。
これによって検知に関する情報がSecurity Hubに集約され、Security Hubのダッシュ ボードを見るだけで、対応すべきアラートの一覧を確認できます。
セキュリティ監視サービス・プロダクトが2、3程度だと実感しにくいかもしれませんが、コンソールが別々に分離しているとサービスやプロダクトの数が増えることで作業の手間が指数関数的に煩雑化していきます。
セキュリティ監視の対応（特にアラートの分析まで）は日常のルーチンワーク になりがちなので、こういったコストを低減できるうちに取り組んでおくことに価値があります。
Security HubのFinding（本文書でいうところの「アラート」）はCloudWatch Eventsからイベントを発行できるため、Lambdaでそれを受信し各所に通知するなどの自動対応に繋げることができます。
分析のための構成
分析のための構成
分析のための構成はよりシンプルです。
ここまでで説明したCloudTrail、およびVPC Flow LogsをそれぞれS3 Bucket に保存します。
図中では同じS3 Bucket に保存していますが、監視対象の規模が大きい場合はオブジェクト数が多くなるため別Bucket にするのがよいでしょう。
それぞれ、標準でS3 Bucket に直接ログを出力する機能があるので、それを利用してください。
そして保存したログを検索する方法についてですが、まずはAmazon Athenaを利用することをお勧めします。
詳しい説明は公式ドキュメントなどに譲りますが、簡潔に説明するとS3 Bucket 上にあるログデータなどを並列で一気に読み込み、記述したSQL のような命令にしたがって検索、集計、表示をするサービスです。
このサービスが今回のセキュリティ監視に適している理由として、サービスの料金が読み込んだデータ量の従量課金である、ということが挙げられます。
セキュリティ監視における分析は重要なタスクですが、業務時間において四六時中発生している状態は望ましくありません。（もしアラートがひっきりなしに発生している、という状況であれば @{対応するアラートを選別する} をご参照ください）
そのため事業内容のデータ分析などと違い、特定の瞬間のみログを検索できるような仕組みのほうがリーズナブルです。
Athenaはこういった要件によくマッチしていることもあり、まずセキュリティ監視の仕組みを作る初期段階にお勧めできます。
具体的な検索の手順などについては次のドキュメントをそれぞれご参照ください。
特に「S3パスの日付を指定して、ある特定の日付からのみ検索する」というテクニックを使うことで、検索範囲を狭め（＝読み込むデータ量を減らし＝安い料金で）検索結果もより高速に取得することができるようになります。
さらに一歩進んだ監視をしたい場合
今回紹介したのはあくまで最初に取り組む、いわば初期装備とでもいうべき構成となっています。
いずれ何らかの形で改めて紹介したいと考えていますが、セキュリティ監視をより充実させるためにできそうな取り組みのポイントだけ取り上げたいと思います。
また、解説という体になってはいますが、筆者もまだ試行錯誤を続けている段階のものが多くあるため、よい解決方法などをお持ちの方がいたらぜひご教示ください。
AWS を利用する目的として、かなり多くの方々が「Webサービス の提供」を挙げられるのではないかなと想像しています。
Webサービス を提供している場合「攻撃のための侵入口」としてWebサービス そのものが利用されるのは現代においては自明といってもいいでしょう。
そのため、自分達が提供しているWebサービス まわりのリソースについてのアラートが発報された場合、Webサービス でどのようなことが起こったのか調査できるように、ログを取得・保管しておくことが望ましいです。
通常、セキュリティ監視が目的でなかったとしてもWebサービス に関連するログの一部は取得している場合が多いのではないかと想像しています。
特に次の3点については監査やトラブルシューティング のために何らかの形で保管していることが多いと思われるため、それらをセキュリティ監視の分析でも使えるようにするというのが最初のステップかと考えられます。
Reverse Proxy、Load BalancerなどWebアプリの手前の中継機能のログ
HTTPサーバなどのミドルウェア のログ（あれば）
Webアプリ本体のログ
多くの場合、これらのログは送信元のIPアドレス やリクエス トが送信された対象のホスト、URI 、一部のクエリなどが含まれており、分析に最低限必要な情報は取得できます。
しかし一方でPOSTリクエス トなどに含まれるBodyのデータは見えなかったり、リクエス トのヘッダ部分の情報が一部欠落しているケースが多く、そういった部分に攻撃コードが含まれるような場合は追跡が難しくなってしまいます。
（これらの欠落してるデータはデータ量が多い、センシティブなデータが含まれる、というケースがあるので当然といえば当然なのですが）
これについては筆者も最適解はまだわかっていませんが、現状AWS サービスで解決するとしたら次の2つを検討します。
AWS WAFを使うAWS WAF（Web Application Firewall ）は防御の機能だけでなく、どのようなリクエス トが発生してどのルールにマッチしたか・しなかったのか、をログとして残すことができます。ログを残す目的だけ（＝トラフィック を止めないの）であればAWS WAFはCloudFront、あるいはALBに関連付けするとすぐ使えるようになるので、既存Webサービス がこれらを使っていた場合は非常に容易に展開ができます。ただし現状（2019年9月現在）はリクエス トのBodyの内容は取得できないため、POSTなどによる攻撃の追跡は難しいという欠点があります。VPC Traffic Mirroringを使うVPC Traffic Mirroring機能はWebサービス に限らずEC2インスタンス などENI（Elastic Network Interfaces）の通信をパケットレベルですべてコピーし、別のインスタンス などに送信できるサービスです。完全な通信のコピーを取得できますが、パケット単位で通信が送られてくるため、HTTPリクエス トの形に直すためにはツールなどでうまくTCP セッションを復元してあげる必要があります。また通信量も莫大になるため、よりシビアにコスト計算をしたり、運用時のパフォーマンスを考えねばならず、全体的に負荷は高めといえます。
どちらの方法もかなりの量のデータを取り扱うことになるため、どの程度の料金が発生するかなどを事前によく試算してから利用することを強くお勧めします。
その他使えそうなAWS サービス
今回は紹介しませんでしたが、その他セキュリティ監視に利用できそうなサービスをご紹介します。
Amazon Macieバージニア ）と us-west-2 （オレゴン ）のみでしか利用できないので今回は対象外にしました。Amazon Inspectorインスタンス にインストールされている脆弱なパッケージなどを報告してくれるサービスです。どちらかというと予防の側面が強かったため今回は取り上げませんでしたが、これも利用できると分析時に「この攻撃に対して対象のEC2インスタンス は脆弱だったか？」という検証がしやすくなるため、セキュリティ監視に取り込む検討をしてもよさそうです。
Webサービス に対するリクエス ト同様に、今回のセキュリティ監視の構成で取得できていないものとしてインスタンス 内部のイベントに関するログがあります。
GuardDutyは「あるインスタンス で不審な活動があった」ということまでは教えてくれますが、インスタンス の中のどのプロセスがその不審な活動をしたか、までは教えてくれません。
（このあたりについて詳しく知りたい場合はAWS の責任共有モデルを調べてみることをお勧めします）
そのため、インスタンス の中のイベントのログは自分で取得しないと、どのプロセスが不審な活動をしたのかがわからず、それがインシデントなのか判断できずじまい、ということになりがちです。
これを解決するような製品やOSS は近年増えてきています。
osquery、sysdig、auditbeatなどのOSS も、本格的な運用の話は国内であまり聞こえていませんが、開発も盛んになってきている印象です。
この領域については筆者もいまだ試行錯誤しているため、明確な構成や運用のベストプラク ティスなどを語れる立場にありません。
ただ、実際にこのようなログを取り込んだいた場合のアラート分析は著しく捗ることはわかっているため、今後も取り組みを続けたいと考えています。
対応するアラートを選別する
検知の仕組みを入れた後に起こりがちなのが、アラートが大量すぎて対応しきれなくなるというものです。
冒頭でも述べたようにセキュリティ監視は監視する対象のサービス、システム、業務によってやり方が大きく変わってくるため多くの監視サービスやプロダクトは多様なアラートを発報します。
「セキュリティ」というものに取り組んでいると、どうしてもセキュリティ監視サービスやプロダクトが発報したアラートについてひととおり目を通して安全であることを確認しないと気がすまない、という状況に陥りがちです。
確かに些細に見えるアラートが大きなインシデントの兆候を示していた、というケースもありえなくはありません。
しかしそれを理由にすべてのアラートをこと細かに分析してチェックしようとしはじめると現場が疲弊してしまい、本来見るべきだったものを見逃してしまうリスクの方が大きくなります。
これを回避するためには必ずアラートのチューニングをしていく必要があります。
アラートのチューニングにおいて重要になることを2つほど説明させてください。
アラートの内容を機械的 に判断して要・不要を判断する : アラートのリスクを判断するときは基本的に人間の直感などに頼らず、判断するための根拠があるはずです。その根拠は同種類の別のアラートにも適用できるはずであり、それをちゃんと言語化 しルールとして次のアラートに活かしていかなければなりません。たとえばいつもと違う国からアクセスがあった、というアラートがあってもそれが本人が持っているデバイス からであるという確認がとれれば、それがアメリ カからでもイギリスからでも大差はないはずです。（緊張関係にある国だった場合はまた別かもしれませんが、それも言語化 すべきルールといえます）このルールをできれば監視のシステム自体に組み込めれば担当者の負荷も劇的に下がると思われますが、それができないシステムも多いので、その場合は基準を作って担当者間で共有するだけでも機械的 に対処できることになり、負荷は下げられると考えられます。機械的 な判断に必要な情報を（なるべく自動的に）揃える機械的 に判断するためには、ログをはじめとしてアラート外の情報との組み合わせが必要になるケースが多くあります。これらの外部情報の取得作業をいかに簡易化できるかというのも、ある意味チューニングの一部といえます。アラートが発生した際、何を基準に判断するかが明確になっていれば、その判断に必要な情報は何か？という問いの答えも明確になるはずです。何が必要かわかっているなら、あとは機械的 （自動的ならなおよし）に取得できるはずで、これによって自動的にアラートの判断ができないまでも、担当者の負荷を下げることにはつながるはずです。
まとめ
AWS をはじめとするクラウド サービスではセキュリティのマネージドサービスが多く提供されており、セキュリティを向上させるための土台はオンプレミス環境より豊富になっていると思います。
しかし一方で、マネージドサービスの個別の使い方についての説明は多く世の中に出回っているものの、運用まで含めた統合的な使い方の説明はあまりないなと常々思っていたため、今回文章にしてみた次第です。
まだ拙い内容なのでわかりにくい部分なども多いと思うのですが、今後もこうした情報発信をしていきたいなと思いますので、ぜひお気持ちのある方々と一緒にやっていければなと思う今日この頃です。
