Trend Micro Cloud One - Conformity の自動修復機能をAWS環境で試してみた

記事タイトルとURLをコピーする

概要

当エントリーでは、CSPM(Cloud Security Posture Management)製品の Trend Micro Cloud One - Conformity (以後 Conformity) の自動修復機能を設定手順と動作イメージを自分の備忘も兼ねて情報として残します。

はじめに

Conformityの自動修復機能とは、ざっくりユーザーがAWSインフラ環境に例えば会社ポリシーで許可されない設定変更を行った際にConformity がリアルタイムに検知して、Amazon SNS 経由で AWS Lambda の自動修復処理(関数)が実行される仕組みとなっています。

https://github.com/cloudconformity/auto-remediate/raw/master/images/how-it-works.png

以下にオープンソースとして公開されています。(執筆時点では 48個の自動修復処理の関数があるようです)
READMEに記載がある通り、利用については 自己責任 となります。

github.com

導入手順

当手順に関する日本語のエントリーが存在しなかった事と初見で少しわかりにくかった点もあったので整理も兼ねて執筆しているという経緯もあります。なので当エントリーは 参考程度 に捉え、実際にオペレーションをする際には、以下Trend Mircro社のオフィシャル手順を参照ください。

Trend Micro公式 - 自動修復(Auto-remediation)

www.cloudconformity.com

1.READMEの指定手順通りインストールを実施する

github.com

インストール手順で、Serverless Framework を利用するのでもし未導入の場合は、事前に導入し、 クレデンシャル周り(対象AWSアカウントにてアクセスキー発行および設定)の準備が必要です。

www.serverless.com

ただ git clone して

% git clone https://github.com/cloudconformity/auto-remediate.git

Cloning into 'auto-remediate'...
remote: Enumerating objects: 2038, done.
remote: Counting objects: 100% (223/223), done.
remote: Compressing objects: 100% (137/137), done.
remote: Total 2038 (delta 139), reused 140 (delta 82), pack-reused 1815
Receiving objects: 100% (2038/2038), 1.05 MiB | 1.82 MiB/s, done.
Resolving deltas: 100% (1366/1366), done.
%

auto-remediate の dirへ cdし

% cd auto-remediate
%                                                                                                                                  (git)-[master]
% ls -ltr                                                                                                                          (git)-[master]
total 2440
-rw-r--r--   1 ytamu  staff     1073 Aug 27 11:59 LICENSE.md
-rw-r--r--   1 ytamu  staff    18724 Aug 27 11:59 README.md
-rw-r--r--   1 ytamu  staff     3683 Aug 27 11:59 exclude-rules.json
-rw-r--r--   1 ytamu  staff      439 Aug 27 11:59 jest.config.js
-rw-r--r--   1 ytamu  staff  1117776 Aug 27 11:59 package-lock.json
-rw-r--r--   1 ytamu  staff     1550 Aug 27 11:59 package.json
-rw-r--r--   1 ytamu  staff    93581 Aug 27 11:59 serverless.yml
drwxr-xr-x@  4 ytamu  staff      128 Aug 27 11:59 utils/
drwxr-xr-x@ 12 ytamu  staff      384 Aug 27 11:59 test/
drwxr-xr-x@ 26 ytamu  staff      832 Aug 27 11:59 runners/
drwxr-xr-x@  3 ytamu  staff       96 Aug 27 11:59 images/
drwxr-xr-x@ 52 ytamu  staff     1664 Aug 27 11:59 functions/
%

npm installをして

% npm install                                                                                                                      (git)-[master]
npm WARN npm npm does not support Node.js v14.17.5
npm WARN npm You should probably upgrade to a newer version of node as we
 
### --- snip --- 
 
found 147 moderate severity vulnerabilities
  run `npm audit fix` to fix them, or `npm audit` for details
%

Serverless Framework で当該AWSアカウントの当該リージョンへ Deploy するだけです

% sls deploy --aws-profile dev-tamura --region ap-northeast-1                                                                             (git)-[master]
Serverless: Packaging service...
Serverless: Excluding development dependencies...
Serverless: [serverless-plugin-split-stacks]: Summary: 51 resources migrated in to 3 nested stacks
Serverless: [serverless-plugin-split-stacks]:    Resources per stack:
Serverless: [serverless-plugin-split-stacks]:    - (root): 155
Serverless: [serverless-plugin-split-stacks]:    - PoliciesNestedStack: 2
Serverless: [serverless-plugin-split-stacks]:    - SubscriptionsNestedStack: 1
Serverless: [serverless-plugin-split-stacks]:    - VersionsNestedStack: 48
Serverless: Creating Stack...
Serverless: Checking Stack create progress...
........
Serverless: Stack create finished...
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading artifacts...
Serverless: Uploading service auto-remediate.zip file to S3 (433.1 KB)...
Serverless: Validating template...
Serverless: Updating Stack...
Serverless: Checking Stack update progress...
............................................................................................................................................................................................................................................................................................................................................................................................................................................
Serverless: Stack update finished...
Service Information
service: auto-remediate
stage: v1
region: ap-northeast-1
stack: auto-remediate-v1
resources: 155
api keys:
  None
endpoints:
  None
functions:
  AutoRemediateOrchestrator: auto-remediate-v1-AutoRemediateOrchestrator
  AutoRemediateS3-016: auto-remediate-v1-AutoRemediateS3-016
  AutoRemediateIAM-001: auto-remediate-v1-AutoRemediateIAM-001
  AutoRemediateCT-001: auto-remediate-v1-AutoRemediateCT-001
  AutoRemediateLambda-003: auto-remediate-v1-AutoRemediateLambda-003
  AutoRemediateS3-001: auto-remediate-v1-AutoRemediateS3-001
  AutoRemediateS3-002: auto-remediate-v1-AutoRemediateS3-002
  AutoRemediateIAM-038: auto-remediate-v1-AutoRemediateIAM-038
  AutoRemediateS3-014: auto-remediate-v1-AutoRemediateS3-014
  AutoRemediateS3-003: auto-remediate-v1-AutoRemediateS3-003
  AutoRemediateKMS-002: auto-remediate-v1-AutoRemediateKMS-002
  AutoRemediateS3-004: auto-remediate-v1-AutoRemediateS3-004
  AutoRemediateRDS-023: auto-remediate-v1-AutoRemediateRDS-023
  AutoRemediateGD-001: auto-remediate-v1-AutoRemediateGD-001
  AutoRemediateS3-005: auto-remediate-v1-AutoRemediateS3-005
  AutoRemediateS3-006: auto-remediate-v1-AutoRemediateS3-006
  AutoRemediateS3-007: auto-remediate-v1-AutoRemediateS3-007
  AutoRemediateKMS-004: auto-remediate-v1-AutoRemediateKMS-004
  AutoRemediateOrganizations-002: auto-remediate-v1-AutoRemediateOrganizations-002
  AutoRemediateS3-008: auto-remediate-v1-AutoRemediateS3-008
  AutoRemediateS3-009: auto-remediate-v1-AutoRemediateS3-009
  AutoRemediateCT-003: auto-remediate-v1-AutoRemediateCT-003
  AutoRemediateRDS-006: auto-remediate-v1-AutoRemediateRDS-006
  AutoRemediateS3-010: auto-remediate-v1-AutoRemediateS3-010
  AutoRemediateS3-012: auto-remediate-v1-AutoRemediateS3-012
  AutoRemediateSQS-004: auto-remediate-v1-AutoRemediateSQS-004
  AutoRemediateRDS-008: auto-remediate-v1-AutoRemediateRDS-008
  AutoRemediateConfig-001: auto-remediate-v1-AutoRemediateConfig-001
  AutoRemediateCFM-005: auto-remediate-v1-AutoRemediateCFM-005
  AutoRemediateVPC-001: auto-remediate-v1-AutoRemediateVPC-001
  AutoRemediateEBS-009: auto-remediate-v1-AutoRemediateEBS-009
  AutoRemediateRS-001: auto-remediate-v1-AutoRemediateRS-001
  AutoRemediateEC2-002: auto-remediate-v1-AutoRemediateEC2-002
  AutoRemediateRS-019: auto-remediate-v1-AutoRemediateRS-019
  AutoRemediateEC2-003: auto-remediate-v1-AutoRemediateEC2-003
  AutoRemediateEC2-005: auto-remediate-v1-AutoRemediateEC2-005
  AutoRemediateEC2-019: auto-remediate-v1-AutoRemediateEC2-019
  AutoRemediateEC2-004: auto-remediate-v1-AutoRemediateEC2-004
  AutoRemediateEC2-006: auto-remediate-v1-AutoRemediateEC2-006
  AutoRemediateEC2-008: auto-remediate-v1-AutoRemediateEC2-008
  AutoRemediateEC2-043: auto-remediate-v1-AutoRemediateEC2-043
  AutoRemediateRS-023: auto-remediate-v1-AutoRemediateRS-023
  AutoRemediateEC2-045: auto-remediate-v1-AutoRemediateEC2-045
  AutoRemediateEC2-038: auto-remediate-v1-AutoRemediateEC2-038
  AutoRemediateEC2-040: auto-remediate-v1-AutoRemediateEC2-040
  AutoRemediateEC2-039: auto-remediate-v1-AutoRemediateEC2-039
  TrustedAdvisor-003: auto-remediate-v1-TrustedAdvisor-003
  AutoRemediateKinesis-001: auto-remediate-v1-AutoRemediateKinesis-001
layers:
  None
Serverless: stack-termination-protection:  Successfully enabled termination protection
Serverless: Deprecation warnings:

Support for "package.include" and "package.exclude" will be removed with next major release. Please use "package.patterns" instead
More Info: https://www.serverless.com/framework/docs/deprecations/#NEW_PACKAGE_PATTERNS

Resolution of lambda version hashes was improved with better algorithm, which will be used in next major release.
Switch to it now by setting "provider.lambdaHashingVersion" to "20201221"
More Info: https://www.serverless.com/framework/docs/deprecations/#LAMBDA_HASHING_VERSION_V2


Toggle on monitoring with the Serverless Dashboard: run "serverless"
%

正常に処理が完了すると、Lambda関数およびIAMロールおよび SNSトピック(&サブスクリプション) がデプロイされます。

Lambda関数

以下の内容が作成

github.com

IAMロール

以下の規則性のある名称で処理の数だけ作成

AutoRemediateXXX-YYYRole

(XXX=サービス名(EC2,S3等) 、YYY=001から始まる数字連番となります)

SNSトピック

以下の名称で1つ作成

CloudConformity

2. Conformity で Amazon SNSチャンネルを設定手順の確認

Conformityの管理コンソール側で 違反を検知した際に実行できるよう Amazon SNS の連携手順を確認します。

www.cloudconformity.com

Conformityで管理しているAWSアカウント(複数ある場合は対象のもの)を選択し、
画面右上の Settings -> Communication settings -> Update communication settings -> Configure ‘Amazon SNS’ を押下します。

f:id:swx-tamura:20210830191640p:plain

[Create an Amazon SNS channel] を押下します

f:id:swx-tamura:20210830191703p:plain

[Configure now...] を押下します

f:id:swx-tamura:20210830191714p:plain

ポップアップで SNSへのアクセスを許可する設定手順が表示されるので確認します。こちらに書かれている内容をこれから実行していきます。

f:id:swx-tamura:20210831150810p:plain

(補足) 先にこれからやる作業概要だけ説明すると SNSトピック側に、Trend Micro社指定のCMK(カスタマーマスターキー)による暗号化設定およびアクセス権限の設定を実施します。

3. Amazon KMS で CMK を作成

以下内容で新規でCMKを作成します。

項目
キータイプ 対称
エイリアス CloudConformitySNSEncryptionKey
説明 CloudConformitySNSEncryptionKey
キー管理者 administrator (権限のあるユーザー)
キーの使用アクセス許可を定義 別のAWSアカウント: 717210094962

f:id:swx-tamura:20210830191748p:plain

4. Conformity と Amazon SNSトピックの連携

Trend Micro社指定の 暗号化設定およびアクセス権限の設定を実施します。

4-1.暗号化設定

SNSトピック(CloudConformity) の編集画面より、暗号化を有効化し、カスタマーマスターキー(CMK)に上の手順で作成したCMKを指定します。

alias/CloudConformitySNSEncryptionKey

f:id:swx-tamura:20210830191832p:plain

4-2.アクセス権限の設定

同じく SNSトピック(CloudConformity) の編集画面より、アクセスポリシーを以下のように、既存(デフォルト)の内容の Statement の中だけを Trend Micro社指定の内容に差し替えます。

{
  "Version": "2008-10-17",
  "Id": "__default_policy_ID",
  "Statement": [
    {
      "Sid": "a unique statement ID",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::717210094962:root"
      },
      "Action": "SNS:Publish",
      "Resource": "arn:aws:sns:ap-northeast-1:XXXXXXXXXXXX:CloudConformity"
    }
  ]
}

f:id:swx-tamura:20210830191854p:plain

5.Conformity 側で Amazon SNSチャンネルを設定

手順3-4のSNSトピック側の設定が正常に終わっていれば、認証が通るようになるので SNSトピック(CloudConformity)のARNを入力して、[Save]を押下します。

f:id:swx-tamura:20210830191926p:plain

今回は自動修復なので Automatic notifications を ON にしておきます。 f:id:swx-tamura:20210830192040p:plain

6.自動修復を実行する処理の有効化

AWS Lambda -> 関数 より以下名称の関数を開くと、ソースコードは以下のようになっています。 auto-remediate-v1-AutoRemediateOrchestrator

f:id:swx-tamura:20210830192116p:plain

見ればわかると思いますが、Trend Micro社の管理するルールID (AWSのサービス略称 + 一意の数字連番)毎に、enabled の項目が用意されており true or false で有効/無効を制御出来ます。

{
  "AutoRemediateRDS-008": {
    "enabled": false
  },

  "AutoRemediateS3-001": {
    "enabled": false
  },

  "AutoRemediateS3-002": {
    "enabled": false
  },
 
 ### --- snip ---
  
  "AutoRemediateRS-019": {
    "enabled": false,
    "RetentionPeriod": 7
  }
}

true or falseをお好みで反映し、 Deploy したら設定は完了です。

実際に試してみる

例1 . S3バケットのパブリック公開設定の自動修復

S3バケットがパブリックアクセスで読み取りの許可設定が行われた場合に、自動修復(許可設定を無効化)を実施してみます。

こちらは意図せぬ S3バケットの公開設定から情報漏えいに繋がるケースが多い事からAWSアカウント(CSPM)管理者として把握しておくべきものとして、把握規定のリスクレベルも Very High に設定されています。

RuleID: S3-001

Risk level: Very High (not tolerated)
S3 Bucket Public ‘READ’ Access
https://www.cloudconformity.com/knowledge-base/aws/S3/s3-bucket-public-read-access.html

適当な名前で S3バケットを新規作成し、パブリックで読み取りのみ公開設定をしてみました。

f:id:swx-tamura:20210830192232p:plain

リアルタイム検知の設定を行っている環境だと、実施後に数秒程度で S3バケットが作成されたアクティビティとACL設定が変更されたアクティビティが表示されました。

同時に自分の環境の場合は、Slack通知を飛ばす設定を加えており、Very High と最上位の Extreme というリスクレベルの内容が検知された場合には以下のように通知もされます。

f:id:swx-tamura:20210830192250p:plain

誰(どのIAMユーザー)がどこで何をしたのかひと目でわかり、当該AWSアカウントにマネジメントコンソールにログインしている状態で[View resource] を押下するとすぐに当該リソースまでアクセスが出来るので大変便利です。 (ちなみに復旧通知のようなものは現時点では無いようで自分で確認する必要がありそうです)


その後、約2min程度で 自動修復のリアルタイム検知ログとして表示されました。 f:id:swx-tamura:20210830192312p:plain

ここで注目は、Idenityが オペレーションしたadministratorではなく、auto-remediation で実行されている事と 赤色のF(ルールに準拠していない=FAILURE)の数が減り、緑色のS(ルールに準拠している=SUCCESS)の数が増えている事です。

auto-remediation のアクティビティの+マークを開いて確認したところ、SUCCESSに変わっていました。

f:id:swx-tamura:20210830200543p:plain

AWSマネジメントコンソールをリロードして、当該S3バケットを再度確認したところ 想定通り、公開設定が消えていました。

例2. セキュリティグループに許可されないルールが追加された場合の自動修復

telnet (TCP:23) が Anyware(0.0.0.0/0) が公開されている セキュリティグループを検知した場合に、自動修復(当該ルールを削除) を実行してみます。

こちらのセキュリティレベルの既定値は Medium です。(OS側で当該PortがListenしている事自体がもう稀な気もしますが...)

Rule ID: EC2-038

Risk level: Medium (should be achieved)
Unrestricted Telnet Access
https://www.cloudconformity.com/knowledge-base/aws/EC2/unrestricted-telnet-access.html

セキュリティグループを以下のような内容で新規作成してみます。 下2つは削除対象とならない事の確認を兼ねたダミーのルールです。

f:id:swx-tamura:20210830192744p:plain

作成後、例1と同様にほぼリアルタイムで作成に関するアクティビティが表示された後、約2min後に自動修復が実行されているアクティビティが確認出来ました。

f:id:swx-tamura:20210830192849p:plain

セキュリティグループの中身をリロードして再度確認すると当該ルール のみが削除されている事が確認出来ました。

f:id:swx-tamura:20210830192902p:plain

ここで気をつけておきたい事は、自動修復(許可されていない設定が削除)された事は、実際にオペレーションした人に通達等はされず、大抵の場合は気が付かないであろう事です。

会社ポリシーやらルールの重大度にもよると思いますが、管理者として検知した場合に次にとるべきアクションは、当該オペレーションを実行したユーザに対して通知やら確認になると思われます。 (場合によっては事情聴取じみた感じになるのかもしれません...)

まとめ

Conformity の自動修復の手順について簡単に紹介しました。
動作イメージがざっくり伝わったなら幸いです。

そもそもとして禁止されているオペレーションが出来ないようIAMやらAWS OrganizationsのSCPやらで適切に権限を絞るという事が大切ですが、環境を維持管理する上でどうしても強い権限が必要になる場合もありますし、その権限を行使するのも人間なのでミスは起こります。

もし、Conformity を導入の際には絶対許容出来ない内容について自動修復の有効化を是非検討したいところです。