Dome9でAWS環境のセキュリティ違反項目を自動修正してみた

Dome9によるセキュリティ違反の自動修正機能を試してみました。
特集

市田善久

2019.10.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

まいど、大阪の市田です。
先日「Developers.IO 2019 in 大阪」というイベントで「Dome9ではじめるAWSセキュリティリスク管理」という話をさせていただきました。
その中でセキュリティチェック時の違反項目を 「cloud-bots」 というツールで自動修正する機能もお話しました。

今回は、その自動修正機能について具体的な手順を紹介させていただきます。

注意点

この機能はまだベータ提供です。Githubで公開されている手順とDome9の画面で異なる点もありましたので、今後変更になる場合がある点にご注意ください。

cloud-botsのアーキテクチャ

cloud-botsは下記で公開されており、そこでAWS構成も確認できます。 下記はシングルアカウント向けの構成図になります。

127-cloud-bots-arch

Dome9による定期チェックでセキュリティ違反が見つかれば、Dome9が特定のSNSトピックにメッセージをパブリッシュして、Lambdaによる修正アクションが実行される という流れになっていることが分かります。

概要

この自動修正機能を利用する場合は、大まかな流れとして次の手順が必要になります。

  • チェック対象のAWS環境へcloud-botsのデプロイ
  • Dome9側の設定
    • 通知設定
    • 修正アクションの設定
    • チェックポリシーの設定
  • Dome9の定期チェックで自動修正が発動

それでは各項目について見ていきたいと思います。

cloud-botsのデプロイ

先程の 「cloud-bots」 というツールを使って、Dome9でチェック、検知したコンプライアンス違反事項に対して、自動的に是正アクションを実行することができます。

90-cloud-bots

cloud-bots環境の構築は、CloudFormationが提供されているので上記ページにあるリンクから環境を作成します。

91-launch-stack

デフォルトでは、「N.Virginia」になるので必要に応じてTokyoリージョンに移動します。
最初の画面は、そのまま「Next」で進みましょう。

92-prerequire.png

次のパラメータ指定では、基本的にはデフォルトのままとしています。
マルチアカウントに使いたい場合は、「DeploymentMode」を「multi」にします。今回は「single」のままとします。

また「EmailAddress」では、Dome9による修正アクションを実行した際の通知先となるアドレスを指定します。オプションなので設定しなくても構いません。

93-stack-details

次のオプションでは、特に何も指定せずに次へ進みます。

94-stack-option-default

最後のレビュー画面で内容を確認します。このテンプレートではIAMリソースも作成されるので、それらの確認事項にチェックを入れて「create stack」をクリックしてスタックを作成します。

95-review-1 96-review-2

作成できたら「Outputs」タブで「InputTopicARN」を確認しておきます。このSNSトピックはDome9側の通知設定の指定に使います。

97-outputs

自動修正機能を試してみる

今回は、下記の環境を想定して確認してみます。

  • チェックポリシーは「PCI-DSS 3.2」
  • 是正アクションは以下の通り
    • S3バケットのバージョニングと暗号化が設定されていなければ設定する
    • Security GroupでSSHのinboundが「0.0.0.0/0」で許可されていれば、該当ルールを削除する

事前準備

自動修正を試すために、わざとチェック違反になる環境を用意するため、専用のS3バケットとSecurity Groupを作成します。

S3バケットは「my-dome9-test」という名前のものを作成しました。「Versioning」と「Default encryption」が無効になっていますね。

57-before-s3

次に「dome9-test-sg」というSecurity Groupを作成します。ルールはHTTPとSSHで「0.0.0.0/0」からのinboundを許可するようにしました。

58-before-sg

Dome9の設定

次にDome9側の設定を行います。まずは通知設定を行います。
「Complience & Governance」画面で「Notifications」を開いて、「ADD NOTIFICATION」をクリックします。

70-add-notification

通知の名前や通知先アドレスを入力します。複数アドレスを指定する場合はコロンで分けて指定できます。

「Scheduled Report」では決まったタイミングでチェック結果を受け取ることができます。必要に応じて設定しましょう。

71-create-notificatio-01

「SNS notification for each new finding as soon as it is discovered」では、最初に「cloud-bot」の作成時にCloudFormationで作成したSNSの「InputTopicARN」を入力します。

Dome9で検知した内容がこのSNS Topicに送られて、このトピックをサブスクライブしているLambdaが実行されます。このLambdaにて各種のRemediation Action（是正アクション）が実行されます。

72-create-notificatio-02

次にポリシーを設定します。ポリシーの設定では、監査に使いたいルールを設定します。

73-add-policy

設定したいアカウントを選択します。

74-create-new-policy

監査に使いたいルールを選択します。今回は「PCI-DSS 3.2」のみとしました。

75-create-new-policy-2

次に通知先を選択します。ここで新規に作成することもできますが、今回は先程作成したものを選択します。

76-create-new-policy-3

ポリシーが作成できました。

77-create-policy-done

この時、通知設定を再度見てみると、先程選択した通知先の「Association（連携）」として「Complience」と表示されるようになっています。

この通知設定がComplience設定に使われることを意味しています。他の機能とも連携する場合は、複数表示されます。

77-notification-complience

最後に是正アクションの内容を作成していきます。「Remediation」の画面を開いて「CREATE NEW REMEDIATION」をクリックしてください。

78-create-remediation

まずはS3に対する設定を行います。ここでは次のように指定します。

  • Ruleset
    • AWS PCI-DSS 3.2
    • ポリシーで指定したルールセットで違反項目があれば、そのルールセットに対応したRemediationが実行されます。
    • そのため、ここでは「AWS PCI-DSS 3.2」を指定します。
  • Remediate by Rule
    • 「S3 Buckets Server Side Encryption At Rest」
    • 是正アクションを実行したい項目をプルダウンから指定します。
  • Remediate by Cloud Account
    • 対象のAWSアカウントを選択してください。
  • Remediate by Entity
    • 対象バケットである「my-dome9-test」を「Entity-ID」に指定します。
    • Remediationの対象にしたいリソースを指定します。
  • CloudBots
    • CloudBotsで修正したいアクションを選択します。
    • 今回は「s3_enable_encryptio」と「s3_enable_versioning」を指定してみました。
    • 「Add Cloud Bot」より選択して「Add」をクリックします
  • Comment
    • コメントは適当に入力します。コメント入力は必須事項です。

79-create-new-remediation-2

同様にSecurity Groupに対する設定を行います。

  • Ruleset
    • AWS PCI-DSS 3.2
  • Remediate by Rule
    • 「Ensure no security groups allow ingress from 0.0.0.0/0 to SSH (TCP:22)」
  • Remediate by Cloud Account
    • 対象のAWSアカウントを選択してください。
  • Remediate by Entity
    • 対象のSecurity Groupである「dome9-test-sg」を「Entity-Name」に指定します。
  • CloudBots
    • CloudBotsで修正したいアクションを選択します。
    • 今回は「sg_single_rule_delete」を指定します。
    • このBotは一つのルールだけを削除するので、削除したいルール内容をさらに指定します。
    • split：false
    • protocol：TCP
    • scope：0.0.0.0/0
    • direction：inbound
    • port：22
  • Comment
    • コメントは適当に入力します。コメント入力は必須事項です。

80-create-remediation-sg

今回指定したBotは「sg_single_rule_delete」というものですが、このBotを指定した場合は上記のように 「split」 というの項目を指定する必要があります。
この項目で「true」を指定した場合、既存ルールで該当ポートが「より大きなポート範囲」で設定されていた場合に、削除したいポートを除いた複数指定のルールに分割することができます。

例えば、SSH(22)ポートを削除したい際に、「1-30」のポート範囲で設定されたルールがあると、新しいルールとして「1-21」「23-30」の範囲を持った2つのルールが作成されます。

これはなかなか面白い機能ですね。詳細は下記をご確認ください。

これでRemediationの作成が完了しました。

81-remediation

動作を確認してみる

ドキュメントによると継続的なチェック時に動作するようなので、しばらく待ちます。
過去の履歴を見てみると、「おおよそ1時間ごと」にチェックされているようです。

今回は、下記の「02:30 PM」(JST)のチェック実行が設定後の最新のチェック実行です。想定通りS3バケットやSecurity Groupの設定が是正されていることを見ていきます。

59-assessment

しばらく待っていると次のようなメールが2通届きます。1通目はS3のアクション結果のメールになります。

60-remediation-s3

見やすくJSONを整形すると下記のようになります。暗号化（s3_enable_encryption）とバージョニング（s3_enable_versioning）が有効化された旨のメッセージになっています。

{
    "ReportTime": "2019-10-03T05:30:37.559Z",
    "Account id": "xxxxxxxxxxxx",
    "findingKey": "xxxxxxxxxxxxxxxxx",
    "Rules violations found": [
        {
            "Rule": "S3 Buckets Server Side Encryption At Rest",
            "ID": "my-dome9-test",
            "Name": "my-dome9-test",
            "Remediation": "s3_enable_encryption",
            "Execution status": "passed",
            "Bot message": "Bucket encryption enabled: my-dome9-test \n"
        },
        {
            "Rule": "S3 Buckets Server Side Encryption At Rest",
            "ID": "my-dome9-test",
            "Name": "my-dome9-test",
            "Remediation": "s3_enable_versioning",
            "Execution status": "passed",
            "Bot message": "Bucket versioning enabled: my-dome9-test \n"
        }
    ]
}

2通目はSecurity Groupに関するものになります。

61-remediation-securitygroup

Security Groupで該当ルールを消す「sg_single_rule_delete」が実行された旨のメッセージのようです。

{
    "ReportTime": "2019-10-03T05:30:37.559Z",
    "Account id": "xxxxxxxxxxxxxx",
    "findingKey": "xxxxxxxxxxxxxxxxx",
    "Rules violations found": [
        {
            "Rule": "Ensure no security groups allow ingress from 0.0.0.0/0 to SSH (TCP:22)",
            "ID": "sg-xxxxxxxxxxxxxxxxx",
            "Name": "dome9-test-sg",
            "Remediation": "sg_single_rule_delete",
            "Execution status": "passed",
            "Bot message": "Split matching for the port to be remediated is set to False. If the port is contained within a larger scope, it will be skipped.\nThe protocol to be removed is TCP\nScope to be removed found: 0.0.0.0/0 \nThe rule to be removed is going to be for inbound traffic\nPort to be removed: 22 \nMatching rule found that is going to be deleted. Protocol:TCP Direction:inbound Port:22 Scope:0.0.0.0/0\nSecurity Group rule from port 22 to port 22 successfully removed\n"
        }
    ]
}

実際にS3のコンソールからも、バケットの「バージョニング」と「デフォルト暗号化」が有効になっていることを確認できました。

65-after-s3

Security GroupもSSHのルールだけ削除されています。

66-after-sg

さらにCloudTrailも見てみましょう。「Dome9CloudBots」というユーザがS3バケットの暗号化とバージョニング、SecurityGroupのルール削除を「02:45 PM」に実行していることが分かります。

62-remediation-cloudtrail

実行時間についてですが、Dome9によるチェックは、受信したメールにあるJSONのReportTimeでは「05:30（UTC）」となっており、Dome9の評価履歴の画面では「14:30（JST）」であることが分かります。
（Dome9の評価履歴に使われるタイムゾーンは「Local Time」となっており、JSTの時刻表記です。）

59-assessment

こちらはメールに記載の時刻です。

{
    "ReportTime": "2019-10-03T05:30:37.559Z",
    "Account id": "xxxxxxxxxxxx",
    "findingKey": "xxxxxxxxxxxxxxxxx",
    "Rules violations found": [
  （以下略）

実際にアクションが実行されたのは、CloudTrailより「02:45 PM」に実行していることが分かるので、Remediationの実行はリアルタイムではなくタイムラグがあることに注意が必要です。
（スクリーンショットは再掲）

62-remediation-cloudtrail

最後に

指定したルールセットで監査し、違反項目に対しては自動で修正アクションを実行することができました。

チェックの定期実行や、自動修正によるセキュリティインシデントの予防を機械的に行うことで、統制を保ちつつセキュアにクラウドを使うことができるかと感じました。

また、PCI-DSSやCIS、SOC2など様々なルールセットが用意されているので、自社で準拠している基準を選択できたり、環境ごとに基準が異なる場合でも柔軟に選択できるのはメリットになるかなと思います。

まだベータ提供なのでGAリリースが待ち遠しい機能だと思います。

以上です。

AWS