はじめに
今回は前回のSecurityHubと同様、GuardDutyを有効化してAuditアカウントに委任する設定を行います。私たちはその後個別protection(保護プラン)を有効にしました。
保護プランとは？
現在は以下7つのプランが設定可能です。
https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/what-is-guardduty.html (←詳細はドキュメントに)
S3 Protection★
EKS Protection★
ランタイムモニタリング
EC2のMalware Protection★
S3のMalware Protection
RDS Protection★
Lambda保護★
今回は★がついている、5つのプランを適用しました。
各保護プランの却下理由は以下の通りです。
ランタイムモニタリング→エージェントを導入することが必須であったため。導入方法について、手動か自動化は選べる。
※ランタイムモニタリングとEKS Protectionの違いは、現在進行形で行われているものを見に行っているかログを見ているかです。←の違いでエージェントの有無が変わります。
S3のMalware Protection→S3バケットを指定しなければならず、リージョンやアカウント単位での監視が不可能だったため。
GuardDutyを設定する
Organizations＞サービスを押下し、「統合されたサービス」の中からGuardDutyを選択します。
【信頼されたアクセスを有効にする】を押下します。
ポップアップが表示されるので、チェックを入れて【信頼されたアクセスを有効にする】を押下します。
【Amazon GuardDutyに対する信頼されたアクセスを正常に有効にしました】と画面上部に表示されたらOKです。
GuardDutyのサービスページに行き、【今すぐ始める】を押下します。
少しスクロールして・・・
委任された管理者の部分にAuditアカウントのアカウントIDを入れ、【委任】を押下します。
画面が更新されたら、【GuardDutyを有効にする】を押下します。
ここで「委任された管理者」枠に「許可 委任された管理者が～」という記載がありますが、ここも有効化(ボタンをクリックし、青く活性化する)します。
【ポイント】
記載の通りですが、これは今後個別保護プランを有効化した際に、EC2 MalwareProtectionにおいて個別のアカウントで有効化できようにするか、設定をする部分です。
ここを活性化しないと、メンバーアカウントに対してEC2 MalwareProtectionを行うことが出来なくなってしまいます。
「GuardDutyが正常に有効になりました」と表示されたら、委任設定は完了です。
委任されていることが確認できますね。(これは管理アカウントから見ています)
Auditアカウントに入り直し、GuardDutyを各アカウントでも有効化していきます。
有効化したいアカウントを選択し、アクション＞アカウントを追加する を選択します。
ポップアップが表示されるので、【メンバーを追加】を押下します。
「2個のアカウントを正常に有効になっているGuardDutyしました」と表示されたらOKです！
【ポイント】
画面上部に青い帯で表示される、「このリージョンで～」を有効にすると、ControlTowerに組み込まれているか否かに関係なく、Organizationsに含まれているアカウントはすべてGuardDutyが自動有効化されてしまいます！そのため、個々に有効化していきたい場合はとっても注意です。
そしてもう一つ注意なのが、この青い帯の設定はSecurityHubの中央設定に似ているように思えます。ですが、GuadDutyはリージョナルサービスなので、つまりリージョンごとに有効化する必要があります。つまりつまり、この青い帯に従って設定しても中央設定のように全部のリージョン・アカウントに対して有効化されるわけではないのです。
ここまでの状況では、東京リージョンでのみ全アカウントに対して有効化されたことになります。
ここは結構罠だと思うので気を付けてください。
管理アカウントのみ有効化されなかったので、【招待によるアカウントの追加】を押下します。
追加したいアカウントのアカウントIDとメールアドレスを追加して、【次へ】を押下します。
緑帯が出ていたらOKです！
どちらのアカウントも「有効」となったら設定完了！
この後、ControlTowerに入れるべきアカウントがすべて揃ったので、先ほどの「このリージョンの～」で全体設定を行いつつ(保護プランの枠で説明しています)、保護プランを有効にしていきます。
LogArchiveアカウントから入りなおして、委任設定がされている(Audit以外のアカウントからは細かい設定が見れない)ことを確認できます。
最後に『統合』を確認します。
SecurityHub＞統合を押下し、スクロールするとGuardDutyが「ステータス 結果を受け入れる」となっていればOKです！
【ポイント】
はじめ、設定したのになぜかデータなしとなっている！？となりましたが、正常な動きでした。ただでさえ少ないリソースの中で有効化させたので、あんまり引っかからなかったんですね・・・だいたい引っかかるのはrootでアクセスしたかとかなので、そこで反応するか見てみてもいいと思います。右上のプルダウンで表示させる日付の数を選べるので、そこで一旦見てみてからの方がおすすめです。
急にデータなしになるとConfig有効化したじゃん！？などと不安になりますよね。。。ご安心ください。。。
ここまでの設定はベーシックにGuardDutyを有効化していく、というものになります。保護プランを有効化しない方は、ここまでで大丈夫です。
ただ先ほども補足しましたが、GuarDutyはリージョナルサービスのため、任意のリージョンごとに設定は必要です。
保護プランを有効化する
では先ほどから温めておいた、青い帯で表示されている「GuardDutyを有効にする」の【有効にする】を押下します。
するとポップアップが表示されるため、【有効にする】を押下します。
すると先ほどの画面に戻り、画面上部に「X個のアカウントを有効にしました」という旨の緑の表示が現れます。
何回か画面更新を行うと、画面中央より左寄りに先ほどの画面で「自動有効化がオフ」と書かれているところがありますが、そこが以下の画像のように「新しいアカウントの自動有効化」となります。
その隣にある【編集】を押下します。
すると自動有効化設定の管理画面が現れるため、設定していきます。
まずGurardDutyの自動有効化設定を「すべてのアカウントについて有効にする」とします。
次に、冒頭で説明したように、S3 Protection,EKS Auditログのモニタリング、EC2のMalwareProtection,RDSログインイベントモニタリング、Lambdaネットワークアクティビティモニタリングを「すべてのアカウントについて有効にする」とします。ランタイムモニタリングは「自動有効化しない」とします。
最後に【変更を保存】を押下します。
先ほどの画面に戻り、画面上部に「変更は保存された」旨が表示されたらOKです。
先ほど【編集】を押した隣の緑の文字が、「新規および既存アカウントの自動有効化」となっています。
ここまでで、個別保護プランの設定は以上です。
このプラン有効化には最大24時間かかることが明示されており、具体的に何時間で終わるかは明記されていません。
実体験では、3,4時間程度で完全に有効化されました。本当に少しずつ有効化されていくので、一旦数時間放置するくらいの気持ちで大丈夫だと思います。
ここで過去に一度GuardDutyを停止させたアカウントも一気に有効化させることができています。
ちなみに、個別にアカウントを指定して、保護プランを編集＞各保護プラン＞X個の選択したアカウントについて有効にする を選択すると、同様に保護プランのみを有効化することが可能です。
ここからの設定に限って言えば、全体設定を行うよりも早いです。
すぐ有効化されます。
【ポイント】
唯一面倒なのは、あくまで個別に有効化しているため、ここで表示されているアカウントをすべて有効化した後Auditアカウントは個別で有効化する必要があるのです。面倒な人は一括設定を行い、個別には有効化しないことをおすすめします。
有効化できた場合は以下のような画面になっています。
ではここから、有効化された最終画面を確認していきます。
GuardDuty＞保護プランより、各保護プランの画面です。
ちゃんと設定されていますね。
アカウントページからも、ステータスがすべて有効になり、個別の保護プランも任意のものが有効になっていることも確認できます。
以上でGuardDutyの設定は終了です。
保護プランも、もちろんリージョナルサービスなのでリージョンごとに有効化していくことを忘れないでくださいね。