この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
こんにちは植木和樹＠上越妙高オフィスです。AWS re:Invent 2017で発表されたGuardDutyを早速してみよう！ということでやってみました。
Amazon GuardDuty は、VPC フローログおよび AWS CloudTrail イベントログを分析および処理する継続的なセキュリティモニタリングサービスです。
GuardDutyでどのように脅威を検知するのか、技術的な解説については下記のブログをご参照ください。
https://dev.classmethod.jp/cloud/aws/aws-reinvent2017-guardduty-intro-sid218/
前準備
前述したとおり対象のAWSアカウントでCloudTrail, VPC Flowlog, DNSクエリログが有効になっている必要があります。
- 新サービス『AWS CloudTrail』のユーザーガイドを読んでみた / Trail(証跡)の作成と更新 ｜ Developers.IO
- 【新機能】VPC Flow LogsでVPC内のIPトラフィックを監視することができるようになりました! ｜ Developers.IO
- Route53 でクエリログが取得できるようになりました ｜ Developers.IO
また必須ではありませんが、メンバーアカウントのrootユーザーに設定しているメールアドレスを知っておいてください。（後述）
2018/02/05 訂正
GuardDutyを利用するにあたって、個別のログ設定が必要というのは誤った情報でした。GuardDutyは独立した仕組みでログを収集しているため個別のログ出力設定は不要です。
Q: Amazon GuardDuty の AWS CloudTrail、VPC フローログ、および DNS ログを有効にする必要はありますか?
いいえ。Amazon GuardDuty は、AWS CloudTrail、VPC フローログ、AWS DNS ログから独立したデータストリームを直接取得します。 Amazon GuardDuty についてよくある質問 – アマゾン ウェブ サービス (AWS)
マスターアカウントで複数アカウントを集中管理
多くの会社では、AWSアカウントを本番用と開発用のように複数利用していると思います。GuradDutyではマスターアカウントにメンバーアカウントの結果を集約し一箇所で表示することができます。
なおGuardDutyのマスターとメンバー はAWS Organizationsの関係性とは別に設定することができます。
設定手順
まずはマスターとなるAWSアカウントでGuardDutyを有効にします。
次にアカウントからメンバーアカウントのアカウントIDとEメールアドレスを入力します。Eメールアドレスは rootユーザーのメールアドレスを入力してください。入力したらアカウントの追加をクリックしましょう。
追加したいメンバーアカウント情報をすべて追加したら完了ボタンをクリックします。
メンバーアカウント一覧が表示され、追加したアカウントには招待リンクが表示されます。これをクリックしましょう。
メッセージを入力して通知を送信をクリックします。マスターアカウントのrootメールアドレスから、メンバーアカウントのrootメールアドレスにメールで招待が通知されます。
マスターアカウントからの招待が済むと、メンバーアカウントのステータスがPendingになります。
次に別のブラウザウィンドウでメンバーアカウントのマネージメントコンソールを開きましょう。メンバーアカウントでもGuardDutyを有効化してください。
アカウント画面を開くと、マスターアカウントからの招待を確認することができます。
ACCEPTのスライドをオンにし招待を承諾するをクリックすればマスターアカウントとの紐付け作業は完了です。
動作確認
試しにメンバーアカウントから全般 - 結果サンプルの生成 ボタンをクリックすると、結果コンソールにサンプルのログが表示されます。
マスターアカウントにも同時に同じログが出力されているため、メンバー・マスター間の遅延は気にしなくて良さそうです。
なおマスターアカウント側の画面にはアカウントID列が追加され、そのログがどのメンバーアカウントから通知されたのか分かりやすくなっています。
脅威を検知したらどうすればいいの？
脅威が検知された場合には原因調査・対応を行いましょう。詳しくはAWSのマニュアルに記載があります。
また検知ログを選ぶと、画面右側に詳細な情報が表示されます。その上にこの結果という指のマークがあります。
検出された脅威が正しいのかどうかのフィードバックをこちらから行うことで学習してくれるようです。
補足： メンバーアカウント数の制限について
GuardDuty メンバーアカウント は100 が上限です。ハードリミットのため上限緩和することもできません。
一般的な用途であれば問題になりませんが、社員一人ひとりにAWSアカウントを発行しているような企業だと100は足りないかもしれません。はい、まさに弊社のケースですね。
アカウント個別の設定だと、そこで検知された問題は利用者（社員個人）の管理になってしまうので統制が効きません。ここは、いくつかのマスターアカウントを用意して集中管理したいところです。
補足： メンバーアカウント招待時のメールアドレスについて
（2017年12月5日 時点の情報です）
メンバーアカウントを招待する時はAWSアカウントIDとrootユーザーのメールアドレスを入力します。
このメールアドレス、実際はrootユーザーのメールアドレスでなく「任意のメールアドレス」でも問題なく招待処理を続けることができます。
ただしrootユーザーのメールアドレス以外を使った場合には、そのアドレス宛に招待メールが届きません。
なお招待メールが届かなくても、メンバーアカウントのAWSマネージメントコンソールを開くと、招待を受け付ける処理自体は行なえます。
（2024年1月31日 更新）
2024年時点では 「ルートユーザーのメールアドレスにのみ招待が可能」 となっていますので、ご注意ください。
まとめ
社内サーバーが10台程度の社内環境だと1日 0.15 ドルくらいでした。1ヶ月で 4.5ドル（500円くらい）になりそうです。安い。
いまの状態だと、毎日GuardDutyのコンソール画面を見に行かなければならないので、たとえば「重要度 High の検知は即時通知、Medium は1日1回検知数を通知」などしたいですね。メールでなくチャット通知がうれしいです。CloudWatch Eventsと組み合わせるとできるようなので課題としたいと思います。
GuardDutyは学習型のサービスのようですので、まずはサービスを有効にして検出を開始してみるのがいいのでは？と感じました。
ひとまず社内アカウントについてはすべて有効にする方向で検討したいと思います！
14
