
AWS 環境チェックツール「Service Screener v2」を使ってみたので使用感を紹介
いわさです。
先日 Service Screener の使用感を確認する機会があり、少し触ってみたのでこのツールについて紹介したいと思います。
Service Screener は、AWS 環境で自動チェックを実行し、推奨事項を提供するオープンソースツールです。
aws-samples 内のリポジトリとして管理されています。
Service Screener は現在は v2 であり、v1 が存在していました。
v1 と v2 の違いですが、大きくはチェック対象の AWS サービスや、サポートするコンプライアンス/フレームワークが異なっています。
v1 では EC2, RDS, S3, Lambda, EKS, OpenSearch, IAM のみがサポートされていましたが、v2 になって CloudFront, CloudTrail, DynamoDB, EFS, Elasticache, GuardDuty, KMS, CloudWatch, Redshift, API Gateway も追加されています。
また、フレームワークも AWS Well-Arhcitected Framework 以外に様々なものが追加されています。
実行方法
実行方法ですが、チェック対象の AWS 環境上にて CloudShell 上でセットアップして実行する方法がセットアップ手順として紹介されています。
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
python3 unzip_botocore_lambda_runtime.py
alias screener="python3 $(pwd)/main.py"
セットアップ後はscreener
コマンドが使えるようになります。
リージョンや対象サービスを指定することも可能で、今回は東京リージョンの全サービスを対象に実行してみました。
私の検証環境では 5 分くらいでチェックが完了しました。IAM ロールのチェックが一番時間かかってた気がします。
レポートの確認
実行が完了すると次のようにレポートが生成されるのでダウンロードしましょう。
出力パスをコピーし、CloudShell のアクションメニューからファイルのダウンロードを行います。
レポート(Zip)が出力されたパスを貼り付けてダウンロードボタンです。
ダウンロード出来たらローカル上で展開しましょう。
AWS アカウント ID のフォルダ内にいくつか HTML ファイルが出力されています。たぶん index.html を見るのが良さそうなのでこちらをブラウザで開きます。
どうやらこちらが生成されたレポートのようです。ドクロマークが印象的です。
左側のメニューをざっとみていってみましょう。
FINDINGS
名前のままですが検出結果を確認することが出来ます。
ここからだとリソースとチェック項目の概要、重大度くらいで詳細の確認は出来ません。
正直 Home のダッシュボードほど見栄えも良くないので後述の機能などで整理しながら俯瞰して見ていったほうが良いと思います。
MODERNIZE
ここはおそらくモダナイズの余地をレコメンドしてくれる機能です。まだベータ機能のようです。
私の検証環境だとコンピューティングリソースがほとんど Lambda だったこともあり、あまり推奨事項で出てきませんでした。Lambda = モダナイズ済みなのか?とはちょっと思いましたが。
いくつか EC2 インスタンスがあり、上記から見づらいと思いますがそれらについてはコンテナ化ができるとか、AMD に移行できそうだとか、いくつか推奨事項っぽいものが表示されています。
この機能では EC2 とデータベース周りが対象となるようです。
TA
TA ってなんだろう?と思ったのですが、内容見る感じおそらく Trusted Advisor です。
表示されている内容も私の環境の Trusted Advisor と同じ内容っぽかったので、Trusted Advisor から情報を抜いている感じだと思われます。
Compliances / Frameworks
いくつかのコンプライアンスやフレームワークベースで対応状況をレポートしてくれる機能があります。
ちょっと整理してみたのですが、本日時点では以下が実装されているようです。
個人的にはワークロードが FTR 基準でどう対応されているのかここからチェックできるのは非常に興味深いです。
メニュー名 | 名称 | 詳細(日本語訳) | 関連リンク |
---|---|---|---|
CIS | CIS Amazon Web Services Foundations Benchmark | AWSアカウントとリソースのセキュリティ構成のベストプラクティス集。アイデンティティとアクセス管理、ログ記録とモニタリング、ネットワーキング、データ保護、インシデント対応をカバーしています。 | ドキュメント |
FTR | Foundational Technical Review | AWSパートナーのソリューションを、顧客の成功に最も重要なセキュリティ、パフォーマンス、運用プロセスに関するAWSのベストプラクティスに対して評価します。 | チェックリスト |
MSR | MSR baseline checks | パートナー移行セキュリティ要件(MSR)は、パートナーが顧客のワークロードをAWSに安全に移行するのを支援するAPJコアチームのイニシアチブです。アイデンティティとアクセス管理、ログ記録とモニタリング、インフラストラクチャセキュリティ、データ保護、インシデント対応の5つのコアセキュリティテーマに沿った要件を詳述しています。 | - |
NIST | National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5 | [作業中] NISTの特別出版物800-53改訂5は、組織の運用と資産、個人、他の組織、および国を様々な脅威(敵対的なサイバー攻撃、自然災害、構造的障害、人的ミスなど)から保護するための連邦情報システムと組織向けのセキュリティおよびプライバシー管理のカタログを提供します。 | ドキュメント |
RMIT | Bank Negara Malaysia (BNM) Risk Management in Technology (RMiT) | リスク管理テクノロジー(RMiT)は、マレーシアの金融機関向けにテクノロジーリスク管理のガイダンスを提供するマレーシア中央銀行(BNM)が発行したポリシー文書です。これらのルールに準拠するために特定のリソースに対して取るべきアクションを特定するためのガイダンスとして使用できます。 | ベストプラクティス |
SPIP | AWS Security Posture Improvement Program(SPIP) | クラウドセキュリティ態勢管理の6つの重要フェーズ(インフラストラクチャ保護と可視性、ID保護、資産管理、検出と緩和、DevSecOps、一元化)にわたる包括的なレビューを含みます。 | - |
SSB | AWS Startup Security Baseline | AWS Startup Security Baseline(SSB)は、ビジネスの俊敏性を損なうことなくAWS上で安全に構築するための最小限の基盤を作成する一連の管理策です。これらの管理策はセキュリティ態勢の基礎を形成し、認証情報の保護、ログ記録と可視性の有効化、連絡先情報の管理、基本的なデータ境界の実装に焦点を当てています。 | ガイダンス、ワークショップ |
WAFS | AWS Well-Architected Framework - Security Pillar | このフレームワークはセキュリティの柱に焦点を当てています。現在のAWSの推奨事項に従うことで、ビジネスおよび規制要件を満たすのに役立ちます。CTOs、CSOs/CISOs、アーキテクト、開発者、運用チームメンバーなどの技術職向けです。セキュリティの柱では、セキュリティ態勢を改善できるようなデータ、システム、資産を保護するためのクラウドテクノロジーの活用方法について説明しています。 | - |
CIS であれば次のような感じですね。カテゴリやルール ID あわせてステータス、説明が表示されています。これは結構使いやすそうです。
CISの例
FTR はこんな感じです。チェックリストベースでステータス出してくれるの非常に良くないですか。これはかなり使えそうだ。
FTRの例
サービスごと
References
メニュー以下ではサポートされているサービスごとの推奨状況や観点ごとのステータスを表示してくれます。この画面はかなり使いやすいです。
以下は Lambda の例で、ヘッダー情報としてリソースがどの程度あって、検出項目やエラーステータス、ツールが調査にかかった時間などが出力されています。
チェック観点がそれぞれ表示されています。ここではセキュリティ以外にも様々な Pillar がサポートされているようですね。
エラーが出ているlambdaNotInUsed30Days
を確認してみると、長期間未使用の Lambda がどれでってのを教えてくれます。ここから不要そうな関数を棚卸し、メンテナンスコスト削減のために削除しましょうという感じですね。
あるいはページの下部に進むとリソースごとの対応状況もチェックできます。
前述したようにセキュリティ以外のチェックもしてくれるので、パフォーマンスやコストなど様々な観点での環境自動チェックツールとして利用することが出来そうです。
パフォーマンス
コスト
さいごに
本日は AWS 環境チェックツール「Service Screener v2」を使ってみたので使用感を紹介しました。
Service Screener では実際の環境ベースでの自動チェックがこちらで行えるので、既存 AWS 環境の課題を自動でサッとレポート作成するのに使ったり、Well-Arhicted Tools で机上確認したあとの補足ツールとして使えそうです。
今後、フレームワークのところでセキュリティ以外も対応してくれると嬉しいですね。個人的には FTR がサポートされているのがありがたいです。