AWS Audit ManagerにAWS Well-Architected Frameworkが追加されていたので、新機能のダッシュボードと併せて使ってみた

いわさです。

Audit Managerは監査用にAWS環境のエビデンスを集めてレポート作成などを行うことが出来る機能です。
臼田佳祐さんが以下の記事で使い方などを詳しくご紹介されています。

先月あたりにこのAudit Managerにダッシュボード機能が追加されたようだったので眺めていたのですが、どうやら当時よりも標準フレームワークが追加されているようで、その中にAWS Well-Architected Frameworkが追加されていました。

せっかくなのでダッシュボードの紹介を兼ねて、この標準フレームワークを使ってみました。

ダッシュボード

まずはダッシュボードを紹介したいと思います。

ダッシュボードを使うと、準拠状況が視覚的にすぐにわかるので、レポートをエクスポートしたりアセスメント結果からエビデンスを細かくチェックしなくても、全体の評価状況を俯瞰した確認と問題の特定を迅速に行うことが出来ます。
なお、今回のアップデートでダッシュボードはAudit Managerのファーストビューになっています。

デフォルト状態では複数のアセスメント結果がサマリで表示されています。
フィルターコントロールを使うことで、アセスメントごとの結果を表示することも出来ます。

ダッシュボードの表示にはアクティブなアセスメントが必要です。
アセスメントの結果が出力されるので開始して24時間後になるので、アセスメントの開始直後はダッシュボードには何も表示されません。

AWS Well-Architected Framework

今回はアセスメントのフレームワークに標準フレームワークの"AWS Well-Architected Framework"を選択しました。
Well-Architected何なのかについてはこの記事では詳しくは触れません。以下から参考情報をご確認頂ければと思います。

AWS Well-Architected Framework の記事一覧 | DevelopersIO

本記事では、Audit Managerで何が出来るのかを見ていきます。

標準フレームワークAWS Well Architected Frameworkにはコントロールセットが2個、コントロールが合計16個です。
詳細を見てみましょう。

この標準フレームワークの中で監査対象として自動抽出出来る項目は以下の16個になります。
※ベストプラクティスの質問内容はWell Architected Toolから引用しています。

• Reliability Pillar(信頼性の柱）
  • REL-1: サービスクォータと制約はどのように管理しますか?
  • REL-2: ネットワークトポロジをどのように計画しますか?
  • REL-6: ワークロードリソースをモニタリングするにはどうすればよいですか?
  • REL-7: 需要の変化に適応するようにワークロードを設計するには、どうすればよいですか?
  • REL-8: 変更はどのように実装するのですか?
  • REL-9: データはどのようにバックアップするのですか?
  • REL-10: ワークロードを保護するために障害分離をどのように使用しますか?
• Security Pillar(セキュリティの柱)
  • SEC-1: ワークロードを安全に運用するには、どうすればよいですか?
  • SEC-2: ユーザー ID とマシン ID はどのように管理したらよいでしょうか?
  • SEC-3: 人とマシンのアクセス許可はどのように管理すればよいでしょうか?
  • SEC-4: セキュリティイベントをどのように検出し、調査していますか？
  • SEC-5: ネットワークリソースをどのように保護しますか?
  • SEC-6: コンピューティングリソースをどのように保護していますか?
  • SEC-7: どのようにデータを分類していますか?
  • SEC-8: 保管時のデータをどのように保護していますか?
  • SEC-9: 転送時のデータをどのように保護していますか?

これらのAudit Managerのコントロールで監査エビデンスを取得しています。

実体は全てAWS Configルールです。
それぞれのコントロールにAWS Configがデータソースとして定義されている形です。

アセスメントしてみる

前提として、Audit ManagerではAWS Configルールを自動で有効化してくれるわけではありません。

今回でいうとAWS Configを使用するので、まずConfigの有効化が必要です。
その上で、関連するConfigルールを個別に有効化するか、あるいは監査に関連するコンプライアンス標準の適合パックをデプロイする必要があります。

今回使用するフレームワークに限っていうと、以下の２つの適合パックサンプルテンプレートとConfigルールが一致していますのでこちらをデプロイすれば検出できるようになります。

Configルールを有効化し、Audit Managerのアセスメントも開始して24時間待ちましょう。
アセスメント詳細画面からコントロール毎のエビデンスが確認できるようになります。

エビデンスの中身を確認していくと、どのConfigルールで不適合となったか、ちゃんとわかるようになっています。

この後の流れとしてはこのエビデンスを選択して、それらを組み合わせて監査用のレポートを作成し活用しますが、レポート作成は既存機能なので今回は割愛します。

さいごに

本日はAudit ManagerでAWS Well-Architected Frameworkに対応した標準フレームワークを使ってみました。
特定の監査ユースケースで使う機能かと思っていましたが、様々なユースケースに適用できるベストプラクティスもフレームワークに含まれているので、汎用的なレポートとして利用することも出来そうですね。

他にもAudito Managerのフレームワークはカスタムすることも可能なので、継続的な監査目的での収集が必要な場合は利用を検討してみてください。