【AWS Audit Manager】フレームワーク、コントロールを継続的デプロイしてみた

2022.01.28

こんにちは、AWS事業本部コンサルティング部のたかくにです。

今回は、タイトルにあるとおりAudit Managerのフレームワーク、コントロールを継続的デプロイしてみようと思います。

今回行うのは以下のハンズオンです。

Continuous compliance monitoring using custom audit controls and frameworks with AWS Audit Manager

はじめにAWS Audit Managerとは

Audit Managerとは、AWSアカウント内のリソースがコンプライアンス違反していないかを継続的にチェックするリソースです。

コンプライアンス監査は非常に面倒でコストのかかるプロセスです。

  • 定期的に行う必要がある
  • 業界、企業によってルールが様々
  • 第三者の監査企業に委託するケースもある(依頼から遂行までに時間がかかる)

上記の問題の解決方法の一つとしてAWS Audit Managerが使用されます。

Audit Managerで何ができるのか

Audit Managerでは、CISベンチマークを初めとした様々なセキュリティ規格をフレームワークで管理し継続的に監視することができます。

フレームワークには、最初から作成されているStandard frameworksと自身でカスタマイズするCustom frameworksがあります。

また、Standard frameworksから派生して、Custom frameworksを作成することも可能でCustom frameworksはAWSアカウント間で共有することもできます。

セキュリティ基準のライフサイクル

前述のCISベンチマークについて取り上げてみます。

CISベンチマークのバージョンアップデート日時は以下の通りです。

バージョン 日時
Initial 2016/2/1
1.1 2016/11/9
1.2 2018/5/23
1.3 2020/8/7
1.4 2021/6/7

業界全体の大枠となる規格で、1-2年にアップデートがかかっていることがわかります。

では、企業独自の規格は、1-2年のアップデートのライフサイクルでしょうか。

企業によっては1-2年のライフサイクルよりも短く細かなアップデート(カスタマイズ部分)が起こると思います。

アップデートがあった場合、CICDを組みAWS上でもセキュリティ規格を迅速にアップデートしたくなると思います

今回の構成図

今回の構成は以下の通りです。

引用:Continuous compliance monitoring using custom audit controls and frameworks with AWS Audit Manager(Figure 1: Solution workflow)

  1. セキュリティ規格担当者(Contorol Owner)は、最新の規格をS3にアップデートします。
  2. S3イベント通知を使用して、Lambda関数を起動しAudit Managerで監視しているコントロールライブラリや、フレームワークライブラリを更新する。

前提条件

  • Audit Managerを有効化しておくこと
  • 端末にてスタック作成の権限付与されていること(構成図のリソース周り)
  • CDKを使うのでcdk bootstrapまでは完了しておくこと

Audit Manager基盤の作成

かなり自動化されていますが、構成図のリソース一式を作成します。

# ソースのダウンロード
git clone https://github.com/aws-samples/enterprise-controls-catalog-via-aws-audit-manager.git

# ソースへの移動
cd enterprise-controls-catalog-via-aws-audit-manager/

./deploy.sh

S3バケットの確認

作成されたS3バケットを確認するとframeworks/controls/フォルダが作成されていました。

フォルダ内に、テンプレートファイルをアップロードすることでAudit Managerにアップデートがかかる仕組みのようです。

Audit Managerの確認

既に、カスタムフレームワークとしてNIST Enterprise Frameworkが定義されており、コントロールも2つ定義、紐付けされている状態でした。

フレームワークのアップデート

コントロールテンプレートを作成し、Audit Managerで作成されたフレームワークをアップデートしてみようと思います。

コントロールの作成

新しいコントロールを追加するためにyamlファイルを作成し、S3バケットにアップロードしました。

example-control.yaml

name: "DataSecurity-PublicAccessProhibited"

description: "Information and records (data) are managed consistent with the organization’s risk strategy to protect the confidentiality, integrity, and availability of information."

actionPlanTitle: "All public access block settings are enabled at account level"

actionPlanInstructions: "Ensure all Amazon S3 resources have public access prohibited"

testingInformation: "Test attestations – preventive and detective controls for prohibiting public access"

tags:
  ID: "PRDS-3Subcategory: Public-Access-Prohibited"
  Category: "Data Security-PRDS"
  CIS: "CIS17"
  COBIT: "COBIT 5 APO07-03"
  NIST: "NIST SP 800-53 Rev 4"

datasources:
  - sourceName: "Config attestation"
    sourceDescription: "Config attestation"
    sourceSetUpOption: "System_Controls_Mapping"
    sourceType: "AWS_Config"
    sourceKeyword:
      keywordInputType: "SELECT_FROM_LIST"
      keywordValue: "S3_ACCOUNT_LEVEL_PUBLIC_ACCESS_BLOCKS"

新しいコントロールが作成されていることが確認できました。

フレームワークのアップデート

本ブログでは既存のフレームワークをアップデートしています。

S3バケットに作成されていた、「enterprise-framework.yaml」を以下のように更新しました。

enterprise-framework.yaml

name: "NIST Enterprise Framework"
description: "NIST Enterprise Control Framework customized"
complianceType: "NIST"
controlSets:
  - name: "DataSecurity"
    controls:
      - "DataSecurity-DataAtRest"
      - "DataSecurity-DatainTransit"
      # 更新部分 deploy.shで作成したフレームワークにコントロールを追加する
      - "DataSecurity-PublicAccessProhibited"
tags:
  Owner: AWSSamples
  Company: AWSLabs

想定通り、フレームワークに新しいコントロールが追加されていることが確認できました。

まとめ

今回のハンズオンでは、S3バケットのオブジェクトアップロードをトリガーに、Audit Managerのコントロール、フレームワークの自動作成、更新を行いました。

作り込みがさらに必要ですが、アセスメントの実行も自動化できればより迅速にコンプライアンス監視が行えそうです。

この記事が参考になれば幸いです。

以上、AWS事業本部コンサルティング部のたかくにでした!