この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
みなさん、快適なセキュリティ運用してますか？(挨拶
出たときにはフーン（ ´_ゝ`）ぐらいに思っていたのですが使ってみるとなかなか神機能なSecurity Hubの新しい仕組みがリリースされました。
AWS Security Hub で自動化された応答と修復ソリューションの一般提供が開始に
これまでSecurity HubはAWS環境のセキュリティリスクを具体的にチェックする仕組みをセキュリティ基準(standard)として提供していましたが、この自動修復と手動修復がメチャクチャ簡単に行えるようになりました！
とりあえず本番環境には例外なく突っ込んでおいたほうがいい機能だと思います！(私なら全環境に入れる)
今回は複数あるセキュリティ基準の中からCIS AWS Foundationsベンチマークに対応した修復ができるようになっているのですが、このリリース文の書きっぷりでは他のセキュリティ基準についてもいずれ対応してくれるような期待が持てる感じです！(￣ー￣)ﾆﾔﾘ
とりあえず解説していきます。
Security Hubとは？
まずSecurity Hubのおさらいをします。
Security HubはAWS上の様々なセキュリティイベントを集約管理する機能を持つサービスです。GuardDutyやMacieなどのイベントを一箇所に集約してインシデントの調査や対応に役立てることが可能です。
イベント集約以外にもセキュリティ基準をチェックする機能もあり、下記のようなコンプライアンス基準に沿ったチェックが可能です。
- CIS AWS Foundations Benchmark
- PCI DSS v3.2.1
- AWS Foundational Security Best Practices
この中でもCISのチェック項目はベーシックな内容で比較的すべての環境に適用しやすいセキュリティチェックがまとまっています。なのでセキュリティチェックを始めるときはまずCISのチェックをしてみるのが選択肢の一つです。
Security HubやCISベンチマークを使ったセキュリティチェックの詳細は下記をご確認ください。
自動修復の概要
今回のリリースはSecurity Hubの新機能！というわけでは厳密にはありません。既存の仕組みの組み合わせで提供されています。
具体的にはCloudFormationからデプロイして仕組みを作ります。ソリューションページに構成図があるので引用します。
Security HubではイベントをFindingsと呼びますが、図の左側にあるようにSecurity HubのFindingsが検知されたところから始まり、CloudWatch Eventsのルールがトリガーを引きLambdaとSSM Automationで自動修復を行います。
なので、これまでも頑張れば自動修復の仕組みを作ることができました。ただ設定や運用がだいぶ大変でした。
今回のソリューションはこの仕組をいい感じに自動的に設定・展開・管理できることにメリットがあります。マルチアカウントへの展開もできます。
セキュリティに問題のある設定を自動修復する仕組みをAWSが提供してくれていることに意味があります。自動修復が一気に民主化された感じですね。今まで自動修復をやってこなかった人たちも気軽にやってみることができるという点ではすごく革新的だと思いませんか？
現状自動修復できる項目は下記CISの項目です。
- 1.3 – 90日以上使用されていない資格情報を無効にする
- 1.4 –アクセスキーが90日以下でローテーションされるようにする
- 1.5 – IAMパスワードポリシーに少なくとも1つの大文字が必要であることを確認します
- 1.6 – IAMパスワードポリシーに少なくとも1つの小文字が必要であることを確認します
- 1.7 – IAMパスワードポリシーに少なくとも1つの記号が必要であることを確認します
- 1.8 – IAMパスワードポリシーに少なくとも1つの番号が必要であることを確認します
- 1.9 – IAMパスワードポリシーに最低14以上の長さが必要であることを確認します
- 1.10 – IAMパスワードポリシーがパスワードの再利用を防ぐようにする
- 1.11 – IAMパスワードポリシーのパスワードが90日以内に期限切れになるようにする
- 2.2 – CloudTrailログファイルの検証が有効になっていることを確認する
- 2.3 – S3バケットのCloudTrailログが公開されていないことを確認する
- 2.4 – CloudTrail証跡がAmazon CloudWatch Logsと統合されていることを確認する
- 2.6 – CloudTrail S3バケットでS3バケットアクセスログが有効になっていることを確認します
- 2.8 –お客様が作成したCMKのローテーションが有効になっていることを確認します
- 2.9 –すべてのVPCでVPCフローロギングが有効になっていることを確認します
- 4.1 –セキュリティグループが0.0.0.0/0からポート22への進入を許可しないことを確認する
- 4.2 –セキュリティグループが0.0.0.0/0からポート3389への進入を許可しないことを確認します
- 4.3 –すべてのVPCのデフォルトのセキュリティグループがすべてのトラフィックを制限するようにする
やってみた
それでは実際に設定して自動修復していきたいと思います。設定方法はこちらのドキュメントにあります。
全体の流れとしては以下のようになります。
- (事前に)Security Hubを有効化しCISベンチマークのスタンダードを有効化する
- 1つ目のCloudFormationからService Catalogを展開する
- Service CatalogからCISの自動修復の仕組み(プレイブック)を展開
- 2つ目のCloudFormationから自動修復に必要なIAMリソースを展開
今回は2つのCloudFormationテンプレートが用意されています。
Security HubやCISベンチマークの有効化は下記をご確認ください。
Service Catalog展開
まずは最初に利用するCloudFormationからService Catalogを展開します。
Service Catalogってなんぞや？と思う人もいると思いますが(あまり使われないので)後ほど軽く説明します。
ソリューションのページからLaunch in the AWS Confoleを押す、あるいはドキュメントからLaunch SolutionあるいはテンプレートをダウンロードしてCloudFormationの作成を行います。
リンクから開いたときには右上のリージョンを確認しましょう。自分の展開したいリージョンに切り替えて続けます。あとは作成まで特に設定するパラメータなどは無いです。
Service CatalogからCISプレイブック展開
Service Catalogのポートフォリオを開きます。
CloudFormationのスタックが作成されたらリソースタブからAWS::ServiceCatalog::Portfolioタイプのリソースを探してリンクをクリックします。
ポートフォリオは後ほど説明する「製品(Products)」を管理する入れ物で製品に対するアクセス権を管理できます。先程のスタックで2つのIAM Groupが作成されており、ドキュメントではこれをIAMユーザーに割り当てる方法が紹介されています。ただ私はIAM Roleを利用していてGroupを割り当てられないこともありポートフォリオのアクセス権を直接変更していきます。どちらの方法でやるかはお好みでいいと思います。
ポートフォリオの詳細ページを開いたら、「グループ、ロール、およびユーザー」タブを選んで「グループ、ロール、またはユーザーの追加」を押して流れに沿ってIAM Roleを追加します。
追加できたら左カラムから「製品」を開きます。ここで注意事項ですが「管理者」配下の「製品」ではなく一番上の「製品」を選びます。これはService Catalogの一般ユーザーと管理者のメニューが両方表示されているためこの様になっています。
「製品」ページに移動すると利用できる製品のリストが表示されます。製品を選択して起動すると、用意されている仕組みから自動的に目的の環境が作成できます。今回はCISのチェックを行うためのリソースが展開されますが、Service Catalogではこのように様々な製品を管理者が用意しておいて、ユーザーがそれを利用するような構造がとれます。
例えばベーシックなVPCや3層アーキテクチャのWebサイトを構築する製品を用意しておいてService Catalogで展開すると、CloudFormationを理解していないユーザーでもポチポチっと簡単に環境が作れます。また、製品のバージョンを管理したりITサービスマネジメント (ITSM)ツールとの接続が可能であったりします。
今回はCISという製品が用意されているので左側の「…」から「製品の起動」を行います。
適当な名前を入れバージョンを選びます。今回はv1.0.0しかないのでそれを選び次へ。
次のオプションでは各CISのチェック項目に対してそれぞれ自動修復を行うかどうかを選択できます。デフォルトでは全てDISABLEDになっており、最初はそのままで利用することを推奨します。自動修復は展開されればすべてのリソースに対して強制的に実行されるので、動作をよく理解してからENABLEDにしましょう。DISABLEDで展開する意味はあるの？と思われるかと思いますが、簡単な手動修復(半自動の修復)に活用できます。
タグは特に何もせず進みます。通知もそのままで次へでいいです。SNSの設定をすると展開されるCloudFormationのアップデートの通知が鳴り止まなくなるので気をつけてください。(1敗)
確認して作成します。製品の詳細ページでしばらくして更新ボタンを押してみると状況が成功になります。
修復するIAMの展開
2つ目のCloudFormationから修復を実行するIAMを展開します。ドキュメントのStep 4.にあるテンプレートをダウンロードします。
CloudFormationでファイルをアップロードして作成していきます。
スタック名は適当に、パラメータは自身のAWSアカウントIDを入力します。マルチアカウントで展開する際にはスタックセットを利用してパラメータはSecurity Hubを集約している親アカウントのIDを入力します。
これで展開は完了しました。
手動(半自動)で修復してみる
今回はSecurity GroupでSSHのポートを全開放(0.0.0.0/0のアクセス許可)を修復していきます。(間違ってもEC2に設定しないように)
まず既に全開放のSecurity GroupがありSecurity HubのCISチェックで検知している状態です。Security Hubのセキュリティ基準画面からCIS AWS Foundations Benchmark v1.2.0に入り、「[CIS.4.1] どのセキュリティグループも 0.0.0.0/0 からポート 22 への侵入を許可していないことを確認する」を選ぶと下記の画面になります。ステータスが失敗になりワークフローのステータスがNEWになっているリソースがあります。
該当のSecurity Group(リスト一番上はアカウント自体の検知内容になっていて本命のSecurity Groupは上から二つ目です)を選択して、「アクション」を選びます。アクションの中には先程のService Catalogから展開された修復アクションが登録されています。今回はCIS4.1なのでCIS4.1 & 4.2を選択します。
画面上部に「CloudWatch Eventsへ正常に送信しました」とメッセージが出たら修復をトリガーできています。自動修復にしていない場合、このトリガーする部分を手動でやる必要があります。ただこの後は自動で修復されます。
実際に修復されたかをSecurity Groupに確認しに行きます。インバウンドルールを確認してルールが消えていることを確認できればOKです。今回はSSHの0.0.0.0/0のルールのみだったので空っぽですが、実際にはSSHの0.0.0.0/0だけ消してくれます。どのような仕組みになっているかは展開されているLambdaなどを確認するとわかりますが、SSM Automationで各CISに対応したオートメーションドキュメントを実行している形です。動作原理の詳細が知りたい場合はそちらを確認していくといいです。
しばらくするとSecurity Hubのステータスも成功に変わっています。修復完了です。
完全自動修復してみる
続いて完全に自動修復するように変更してみます。
まずService Catalogの「プロビジョニングされた製品のリスト」へアクセスし、先程展開した製品の「…」から更新を選択します。
バージョンはそのまま次へ。
先程の自動修復オプションです。今回対象のCIS4142(4.1と4.2が合わさったパラメータ)をENABLEDに変更します。そのまま進んで更新を完了します。
テストしてみます。先程のSecurity Groupをもう一度SSH全開放します。
しばらくするとSecurity Hubでワークフローのステータスが「解決済み」に変わっていました。
実際にSecurity Groupのルールも削除されていたのでConfigからどれくらいで修復されたか確認してみます。
Configの設定タイムラインを確認すると、全開放の設定変更した3分以内に修復が完了していました。速い！
実はSecurity Hubのステータスはすぐに切り替わらないため、先に解決済みにするという処理を自動修復のLambdaの中で実行しているようでした。つまり「解決済み(RESOLVED)」になっていたら実際には対応は完了していて成功確認待ち、という状態のようです。動いているLambdaを確認した画面を下記につけておきます。
[2020/08/27 追記] 完全自動修復の設定のまま自動修復に失敗すると、Lambdaがループして無限に実行されて請求が跳ねる事象が起きます。(起きました) これは修復アクションはSSM Automationドキュメントの内容に依存し、どのような設定でも修復できるわけではないためです。事前のテストを十分に行い完全自動修復をどこまで信頼するかを確認したり、ループが発生したことをLambdaの実行件数や料金アラートなどで検知できる体制を検討する必要があります。用法用量を守った完全自動化ライフを！
活用方法の考察
ここまでSecurity Hubの自動修復の設定と動作を見てきました。
まずCISベンチマークにある様々なセキュリティチェック項目を自動修復する仕組みが簡単に展開できるのは非常に強力だと感じました。この仕組を自分で作ろうとしたら大変ですが、AWSから提供されているのは非常に心強いですね。
そして修復のアクションを完全に自動で行うか、手動でトリガーするかを選ぶことができるので修復の仕組みへの理解度やどこまで強制力を効かせたいかに合わせて使い分けることができるのも幅広い環境で使えると思います。
例えば下記2つのパターンで活用できると思います。
AWS環境のセキュリティを強化し始める時
AWSのセキュリティを強化しようと思った時、最初にSecurity Hubを有効化してCISベンチマークに沿って環境をチェック・是正していくといいです。
その際にこの仕組も一緒に展開すると、問題があるリソースを確認した後の修復が簡単に行なえます。
この場合はすべてDISABLEDのままでも問題ありません。
大規模にAWS環境のガバナンスを効かせる
多数のAWSアカウントをAWS Organizationsの仕組みで管理しており、4.1 Security Groupの全開放などを明確に禁止している場合、ポリシーとして禁止するだけでなく違反があった場合に自動修復することが可能です。
各CloudFormationをマルチアカウントで展開し必要な項目を自動修復するように設定します。
違反があってもすぐに修復し、必要に応じSSM AutomationのログをCloudWatch Logsに取得しておき違反を追尾したりすることも可能です。
あくまで一例の考察ですが、とりあえず入れておくだけでもいざというときに修復が簡単にできますし、セキュリティ運用をより簡単にできるツールとしても、よりいろんなものを自動化していく最初の足がかりとしても活用できると思います。
まとめ
Security Hubで検知したCISベンチマークの違反を自動修復するソリューションとその活用方法を紹介しました。
夢のセキュリティ運用の自動化がすごく簡単に試せるのは、非常に強力であると思います。
入れるだけなら簡単で影響もないので、まずは入れて使ってみてはいかがでしょうか？
9
