概要
当エントリーでは、CSPM(Cloud Security Posture Management)製品の Trend Micro Cloud One - Conformity (以後 Conformity) の自動修復機能を設定手順と動作イメージを自分の備忘も兼ねて情報として残します。
- 概要
- はじめに
- 導入手順
- 2. Conformity で Amazon SNSチャンネルを設定手順の確認
- 3. Amazon KMS で CMK を作成
- 4. Conformity と Amazon SNSトピックの連携
- 5.Conformity 側で Amazon SNSチャンネルを設定
- 6.自動修復を実行する処理の有効化
- 実際に試してみる
- まとめ
- 関連エントリー
はじめに
Conformityの自動修復機能とは、ざっくりユーザーがAWSインフラ環境に例えば会社ポリシーで許可されない設定変更を行った際にConformity がリアルタイムに検知して、Amazon SNS 経由で AWS Lambda の自動修復処理(関数)が実行される仕組みとなっています。
以下にオープンソースとして公開されています。(執筆時点では 48個の自動修復処理の関数があるようです)
READMEに記載がある通り、利用については 自己責任 となります。
導入手順
当手順に関する日本語のエントリーが存在しなかった事と初見で少しわかりにくかった点もあったので整理も兼ねて執筆しているという経緯もあります。なので当エントリーは 参考程度 に捉え、実際にオペレーションをする際には、以下Trend Mircro社のオフィシャル手順を参照ください。
Trend Micro公式 - 自動修復(Auto-remediation)
1.READMEの指定手順通りインストールを実施する
インストール手順で、Serverless Framework を利用するのでもし未導入の場合は、事前に導入し、 クレデンシャル周り(対象AWSアカウントにてアクセスキー発行および設定)の準備が必要です。
ただ 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関数
以下の内容が作成
IAMロール
以下の規則性のある名称で処理の数だけ作成
AutoRemediateXXX-YYYRole
(XXX=サービス名(EC2,S3等) 、YYY=001から始まる数字連番となります)
SNSトピック
以下の名称で1つ作成
CloudConformity
2. Conformity で Amazon SNSチャンネルを設定手順の確認
Conformityの管理コンソール側で 違反を検知した際に実行できるよう Amazon SNS の連携手順を確認します。
Conformityで管理しているAWSアカウント(複数ある場合は対象のもの)を選択し、
画面右上の Settings -> Communication settings -> Update communication settings -> Configure ‘Amazon SNS’ を押下します。
[Create an Amazon SNS channel] を押下します
[Configure now...] を押下します
ポップアップで SNSへのアクセスを許可する設定手順が表示されるので確認します。こちらに書かれている内容をこれから実行していきます。
(補足) 先にこれからやる作業概要だけ説明すると SNSトピック側に、Trend Micro社指定のCMK(カスタマーマスターキー)による暗号化設定およびアクセス権限の設定を実施します。
3. Amazon KMS で CMK を作成
以下内容で新規でCMKを作成します。
| 項目 | 値 |
|---|---|
| キータイプ | 対称 |
| エイリアス | CloudConformitySNSEncryptionKey |
| 説明 | CloudConformitySNSEncryptionKey |
| キー管理者 | administrator (権限のあるユーザー) |
| キーの使用アクセス許可を定義 | 別のAWSアカウント: 717210094962 |
4. Conformity と Amazon SNSトピックの連携
Trend Micro社指定の 暗号化設定およびアクセス権限の設定を実施します。
4-1.暗号化設定
SNSトピック(CloudConformity) の編集画面より、暗号化を有効化し、カスタマーマスターキー(CMK)に上の手順で作成したCMKを指定します。
alias/CloudConformitySNSEncryptionKey
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" } ] }
5.Conformity 側で Amazon SNSチャンネルを設定
手順3-4のSNSトピック側の設定が正常に終わっていれば、認証が通るようになるので SNSトピック(CloudConformity)のARNを入力して、[Save]を押下します。
今回は自動修復なので Automatic notifications を ON にしておきます。
6.自動修復を実行する処理の有効化
AWS Lambda -> 関数 より以下名称の関数を開くと、ソースコードは以下のようになっています。
auto-remediate-v1-AutoRemediateOrchestrator
見ればわかると思いますが、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バケットを新規作成し、パブリックで読み取りのみ公開設定をしてみました。
以下blogを参考にReal-time Threat Monitoring(以後RTM)の設定を行っている環境だと、実施後に数秒程度で S3バケットが作成されたアクティビティとACL設定が変更されたアクティビティが表示されました。
同時に自分の環境の場合は、Slack通知を飛ばす設定を加えており、Very High と最上位の Extreme というリスクレベルの内容が検知された場合には以下のように通知もされます。
誰(どのIAMユーザー)がどこで何をしたのかひと目でわかり、当該AWSアカウントにマネジメントコンソールにログインしている状態で[View resource] を押下するとすぐに当該リソースまでアクセスが出来るので大変便利です。 (ちなみに復旧通知のようなものは現時点では無いようで自分で確認する必要がありそうです)
その後、約2min程度で 自動修復のRTM検知ログとして表示されました。
ここで注目は、Idenityが オペレーションしたadministratorではなく、auto-remediation で実行されている事と 赤色のF(ルールに準拠していない=FAILURE)の数が減り、緑色のS(ルールに準拠している=SUCCESS)の数が増えている事です。
auto-remediation のアクティビティの+マークを開いて確認したところ、SUCCESSに変わっていました。
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つは削除対象とならない事の確認を兼ねたダミーのルールです。
作成後、例1と同様にほぼリアルタイムで作成に関するアクティビティが表示された後、約2min後に自動修復が実行されているアクティビティが確認出来ました。
セキュリティグループの中身をリロードして再度確認すると当該ルール のみが削除されている事が確認出来ました。
ここで気をつけておきたい事は、自動修復(許可されていない設定が削除)された事は、実際にオペレーションした人に通達等はされず、大抵の場合は気が付かないであろう事です。
会社ポリシーやらルールの重大度にもよると思いますが、管理者として検知した場合に次にとるべきアクションは、当該オペレーションを実行したユーザに対して通知やら確認になると思われます。 (場合によっては事情聴取じみた感じになるのかもしれません...)
まとめ
Conformity の自動修復の手順について簡単に紹介しました。
動作イメージがざっくり伝わったなら幸いです。
そもそもとして禁止されているオペレーションが出来ないようIAMやらAWS OrganizationsのSCPやらで適切に権限を絞るという事が大切ですが、環境を維持管理する上でどうしても強い権限が必要になる場合もありますし、その権限を行使するのも人間なのでミスは起こります。
もし、Conformity を導入の際には絶対許容出来ない内容について自動修復の有効化を是非検討したいところです。
