AWS Security Hubでセキュリティリスクを自動修復する

記事タイトルとURLをコピーする

クラウドインテグレーション部の村上です。

最近セキュリティに強くなりたいなと思い、その第一歩としてAWS Security Hubを検証してみましたので紹介します。

AWS Security Hubとは

AWS Security Hubは、組織内の様々なセキュリティデータを集約して、一元的に可視化するサービスです。 Amazon GuardDutyやAmazon Inspectorなど複数のサービスのデータを集約することができるので、煩雑になっていた管理を改善してくれます。

AWS Security Hubの概要や検出可能な項目、有効化の手順は、弊社ブログと動画で紹介されていますので、詳しくは以下を参考にしてください。

blog.serverworks.co.jp

使ってみた

まずは有効化してセキュリティ状況をチェック

有効化の手順は、さきほど紹介したブログと動画で解説されていますので割愛します。 Security Hubを有効化すると、選択したセキュリティ基準に従って、以下のような検出結果が表示されます。

f:id:swx-murakami:20201104190711p:plain

おそらく(というか十中八九)、たくさんの検出結果が表示されると思います。 あまりの数に多さに引いてしまうかもしれませんが、Security Hubを嫌いにならないでください!

重要度が高いものから確認しよう

一番左側の列に重要度というものがあります。この項目をソートして、重要度がCRITICALHIGHになっているものから確認するようにしましょう。

f:id:swx-murakami:20201104190616p:plain

これだけでもかなり見やすくなるはずです。

ワークフローのステータスを活用しよう

重要度が低いものなど、項目によっては「これは対応不要だな」というものがあるはずです。 そういうときはワークフローのステータスを活用して、今後検出されないようにしましょう。

対応不要な項目をチェックし、ワークフローのステータスから「抑制済み」を選択すれば、ステータスがSUPPRESSEDに更新されます。

f:id:swx-murakami:20201104191600p:plain

これで以後は表示されないようになりますので、うまく活用して管理を楽にしたいですね。 ワークフローのステータスについては、以下のブログに詳細がありますのでご覧ください。

blog.serverworks.co.jp

自動修復の紹介

もちろん検出結果はただ確認するだけでなく改善することも必要です。 ここではAWSソリューションで紹介されている自動修復の方法を紹介します。

f:id:swx-murakami:20201105090327j:plain
「AWS Security Hub の自動化された応答と修復」から引用

AWS Security Hub の自動化された応答と修復 | 実装 | AWS ソリューション

このソリューションではSecurity Hubのセキュリティ基準のひとつであるCIS AWS Foundations Benchmarkに対応することができます。 以下の手順に沿って実装してみます。

docs.aws.amazon.com

手順その1 Service Catalogの製品をデプロイ

ドキュメントで提供されているCloudFormationテンプレートを展開すると、Service CatalogにCISという製品が含まれたポートフォリオが作成されます。 f:id:swx-murakami:20201105094259p:plain

同時に、このポートフォリオにアクセスできるIAMグループも作成されますので、使用しているIAMユーザーをこのIAMグループに追加します。 なお、スイッチロールでオペレーションする場合は、使用するIAMロールをポートフォリオに追加する必要があります。

手順その2 製品を起動

CISを展開すると自動修復に必要なLambdaがデプロイされます。

  • まずは製品のメニューからCISを選択し、製品を起動します。 f:id:swx-murakami:20201127190802p:plain

  • 次の画面では各CIS項目ごとに、自動修復を有効(ENABLED)にするか決定します。 f:id:swx-murakami:20201127191330p:plain

例えばCIS43AutoRemediationはVPCのデフォルトのセキュリティグループに関する項目ですが、これをENABLEDに設定すると、デフォルトのセキュリティグループですべてのトラフィックを許可するなど、推奨されていないルールが存在すると自動的にルールが削除されます。

知らないところで修復アクションが実行されるのが嫌な場合はDISABLEDに設定しましょう。 DISABLEDに設定した場合の修復方法は後ほど紹介します。

手順その3 Lambdaの実行ロールを作成する

最後に2つめのCloudFormationテンプレートのスタックを作成すると、修復アクションを行うLambdaの実行ロールが作成されます。 f:id:swx-murakami:20201127233024p:plain クロスアカウントでの利用も想定されるので、Service Catalogの製品からは切り離されているんですね。

Service Catalogから作成されたLambdaのIAMロール自体にリソースを修復する権限はなく、代わりに本手順で作成するIAMロールを引き受ける権限が付与されています。 f:id:swx-murakami:20201127232525p:plain

以上で実装は完了です。

自動修復をDISABLEDにした場合の修復方法

やり方はとても簡単。Security Hubの検出結果の画面からワンクリックで修復アクションを実行するだけです。

  • アクションから該当するCISの項目を選択します。 f:id:swx-murakami:20201128081900p:plain

これだけで裏ではAmazon EventBridge経由でLambdaがキックされ修復アクションが実行されます。 f:id:swx-murakami:20201128081916p:plain f:id:swx-murakami:20201128081937p:plain

今回CIS4.3で検証しましたが、セキュリティグループで全トラフィックを許可するルールを作成してからSecurity Hubで検出されるまで数分、Security Hubで修復アクションを実行してから修復されるまで数秒(リロードしたら修復されていた)、といった感じでした。

まとめ

  • AWS Security Hubを使えば、複数のアカウント・複数のセキュリティサービスで煩雑になっていた管理を一元管理することが可能です。
  • 自動修復の機能を使えば、簡単にセキュリティリスクを軽減することができます。

管理するアカウント数やCIS項目の種類によって、自動修復するのか人の手を介在させるのか決定し、上手に管理していきたいですね。

村上博哉 (執筆記事の一覧)

2020年4月入社。機械学習が好きです。記事へのご意見など:hiroya.murakami@serverworks.co.jp