0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Screener SchedulerでService Screener v2をスケジュール実行してみた!

Posted at

はじめに

以前、私の記事でService Screener v2というツールを紹介しました。

Service Screener v2とは、AWS 環境を自動でチェックし、セキュリティやコスト最適化の観点から推奨事項を提供するツールです。
詳細については以下の記事をご覧ください。

記事の中では、Service Screener v2をCloudShellから手動で実行する方法を紹介しています。
セキュリティチェックやコスト最適化の観点でとても便利なツールですが、このようなツールは手動実行よりスケジュールした時間帯に自動で実行して結果を取得したいものですよね。

Service Screener v2はスケジュール実行するためにScreener Schedulerというツールも提供しています。
今回はこのツールを使ってService Screener v2をスケジュール実行してみたいと思います。

Screener Schedulerの概要

Screener Schedulerは、Service Screener v2をスケジュール実行するための環境をCDKで構築するテンプレートになります。

アーキテクチャ図は以下になります。
image.png

デプロイされるリソースは以下になります。

サービス 説明
DynamoDB スケジューラの各種設定を保存
Lambda(設定更新) 設定変更を検知し、スケジュールと通知先を自動更新
EventBridge Scheduler AWS Batchをトリガーしてスケジュール実行
AWS Batch ECS FargateでService Screenerを実行するためのジョブ
ECS Fargate コンテナ環境上でService Screenerを実行
S3 Service Screenerの実行結果を保存
EventBridge Email S3のイベントに基づいてトリガー
Lambda(結果処理) 前回の実行結果との比較分析
SNS 実行結果をメール送信

実行コマンド

CloudShell上で以下のコマンドを実行することで、Screener Schedulerをデプロイすることができます。

cd /tmp
python3 -m venv .
source bin/activate
python3 -m pip install --upgrade pip
rm -rf service-screener-v2
git clone https://github.com/aws-samples/service-screener-v2.git
cd service-screener-v2
pip install -r requirements.txt

# 環境変数設定(適宜変更)
export NAME="sample-scheduler"               # スケジューラー名
export EMAIL_LIST="scheduler@example.com"    # 結果通知先メールアドレス
export SERVICES=""                           # チェック対象サービス(空欄は全サービス)
export REGIONS="ALL"                         # チェック対象リージョン(ALLは全リージョン)
export FREQUENCY="cron(0 9 ? * FRI *)"       # 実行スケジュール(cron(UTC)形式)
export CROSSACCOUNTS=""                      # クロスアカウント設定(空欄は無効)
export BUCKET_NAME="your-bucket"             # 結果保存用S3バケット名
export AWS_DEFAULT_REGION=ap-northeast-1     # リソースデプロイ先のデフォルトリージョン 

# インフラ準備
cd usecases/scheduler/src/infra
pip install -r requirements.txt
cd ../lambda/ssv2_resultProcesser
pip install -r requirements.txt -t .
cd ../../infra
cdk synth

# CDKデプロイ
cdk bootstrap                               #既に環境にCDKToolkitが存在している場合は不要です。
cdk deploy

# 初期設定
chmod +x ./deploy.sh
./deploy.sh

やってみる

事前準備

デプロイには以下が必要です。

  • Python3.12とpip3
  • awscli と awscdk
  • Docker

上記はすべて、Cloudshell 環境にすでにプリインストールされています。

以下の手順でPython仮想環境を作成し、リポジトリをクローンします。

# 作業ディレクトリに移動
cd /tmp
# Python 仮想環境の作成とアクティベート
python3 -m venv .
source bin/activate

# pip のアップグレード
python3 -m pip install --upgrade pip

# リポジトリのクローン
rm -rf service-screener-v2
git clone https://github.com/aws-samples/service-screener-v2.git
cd service-screener-v2

# 依存関係のインストール
pip install -r requirements.txt

環境変数の設定

スケジューラ機能の設定に必要な環境変数を設定していきます。
※環境に合わせて適宜変更してください。

export NAME="sample-scheduler"               # スケジューラーの名前
export EMAIL_LIST="scheduler@example.com"    # 結果通知先メールアドレス
export SERVICES=""                           # チェック対象サービス(空欄は全サービス)
export REGIONS="ap-northeast-1"              # チェック対象リージョン(今回は東京リージョン)
export FREQUENCY="cron(0 9 ? * FRI *)"       # 実行スケジュール(cron(UTC)形式)
export CROSSACCOUNTS=""                      # クロスアカウント設定(空欄は無効)
export BUCKET_NAME="your-bucket"             # 結果保存用S3バケット名
export AWS_DEFAULT_REGION=ap-northeast-1     # リソースデプロイ先のデフォルトリージョン

インフラストラクチャの準備

CDKを使ってインフラを準備していきます。

# インフラストラクチャの依存関係をインストール
cd usecases/scheduler/src/infra
pip install -r requirements.txt

# Lambda 関数の依存関係をインストール
cd ../lambda/ssv2_resultProcesser
pip install -r requirements.txt -t .

# CDK の合成
cd ../../infra
cdk synth

cdk synthコマンドは、CloudFormationテンプレートを生成します。これによりデプロイする前に生成されるリソースを確認することができます。

インフラストラクチャのデプロイ

CDKの実行準備ができたら、実際にインフラをデプロイしていきます。

# CDK のブートストラップ
cdk bootstrap          #既に環境にCDKToolkitが存在している場合は不要です。

# CDK のデプロイ
cdk deploy

これでリソースがデプロイされていきます。
時間がかかるので気長に待ちましょう。

初回設定の挿入

# デプロイスクリプトの実行権限を付与
chmod +x ./deploy.sh

# 初回設定を DynamoDB に挿入
./deploy.sh

出力結果はInitial item inserted successfullyが表示されたらOKです。

メール送信についてはSNSトピックのSubscribeが必要なので必ず実施しましょう。
image.png

動作確認

処理が正常実行されると、指定したメールアドレスに結果が送信されてきます。
image.png

メール結果では調査対象リソースで重要度が 「HIGH」 の件数がサマリーとして表示されています。
また、前回の内容と比較して差分で 「New Finding」 と 「Resolved」 として新たな検知件数と解決済み件数も表示されるようです。

レポート内容については、指定したS3バケットに日付.output.zipで保存されています。
(バケット名 : servicescreenerautomations-<環境変数で指定したバケット名><乱数>
バケット名がどう表示されるかわからずで長くなってしまいました…
image.png

また、アカウントIDのフォルダには、 workItem.xlsx というExcelファイルが保存されます。
image.png
この中身は、Service Screener v2の実行結果をExcelファイルとして保存したもので、リソースを一覧で確認する場合にはこちらを参照したほうが見やすいかもですね。

料金

実際にかかるコストは、実行頻度、設定数、リソース量、スキャン対象アカウント数によって異なります。
GitHubには以下のように記載されています。

  • 構成: 5、スケジュール: 毎週。月額 0.42 ドルまたは年額 5 ドル
  • 構成: 1、スケジュール: 毎週。月額 0.1 ドルまたは年額 1.2 ドル
  • 構成: 1、スケジュール: 月次。月額 0.025 ドルまたは年額 0.3 ドル

参考:https://github.com/aws-samples/service-screener-v2/tree/main/usecases/scheduler#costs

気になること

Q. Service Screener v2が更新された時にCDKの再デプロイが必要なのか?
A. AWS Batchトリガー時に最新のコンテナイメージを取得する設計になっているため不要です。

最後に

Service Screener v2のスケジューラ機能を使うことで、AWS環境のセキュリティチェックやコスト最適化の観点で定期的にチェックできるようになりました。

個人的には以下の観点でカスタマイズすることができないか気になっています。
1.実行結果のメール内容をカスタマイズして見やすくしたい
2.S3に格納されるzipはあらかじめ展開された状態で格納されるようにできないか

今後のアップデートに期待したいとおもいます。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?