[ AWSセキュリティ担当者必見] Config Rules 、Lambda、SNSによる中央集権型の管理統制について

前置き

　私が勤めている会社では、約3年前からAWSの利用を積極的に検討してから、毎月のAWS利用費はもちろん、アカウントの数も急に増えてきました。自分が所属している部署もAWSの利用を推進しています。そして、AWSの社内利用において、セキュリテイ管理統制も行っています。今は(色々事情があっての)野良アカウントを除き、数十個のAWSアカウントを管理・セキュリティ統制をしています。
　AWSアカウントを作成した時に、管理統制用の設定を入れてから、AWSアカウントを渡すようにしています。しかし、管理するAWSアカウントを増えるほど、管理統制が難しくなります。チームメンバーの人数も多くないので、（各アカウントに分散されている設定やコードの運用管理など）社内AWS利用の管理統制を行うには大変な一面もあります。

概要

　二三日前に、【How to Centrally Manage AWS Config Rules across Multiple AWS Accounts】というAWSの方の記事を見ました、タイトルを見ただけで、きっと面白い内容だと思いました。その記事を一通り読みまして、こんなやり方もあるんだなと感心しました。(個人的)すごいソリューションだと思っています。そして、DeepDiveしてみました。
　その記事に書かれている内容を簡単にまとめてみますと、
　管理されるアカウントにあるConfig Rulesが
　　管理を行うアカウントにあるLambdaを呼び出し、
　　　管理されるアカウントの設定をチェックし、
　　　　その結果をConfig Rulesに表示するようにしています。

　自分の頭に浮かんできたイメージは以下の図に示す通りです。

　これって、凄くないですか？！　統制用のコード（Lambda）は admin-account(管理を行うアカウント)にしか置かず、managed-accout(管理されるアカウント)がただそれを呼び出すだけです。コードが１つのアカウントに集約され、運用管理も楽ですね。
　また、自分なりに機能増強を拡張してみて、SNSを使って、Config Rulesの評価レポートを管理者に通知するようにしました。
　全体のイメージはこんな感じです。

　今回は、【How to Centrally Manage AWS Config Rules across Multiple AWS Accounts】に紹介した例 (CloudTrailのlog fileのvalidationが可能かどうかのチェック) を沿って、一通り検証してみました。

検証の流れ

　設定の手順は後ほど紹介しますが、まず、上記の図を使って、全体の流れを説明します。

• ① : ( managed-account ) Config Rulesが ( admin-account ) Lambdaをinvokeします。

  • Config RulesがAssumeRoleのARNとevent情報をLambdaに渡しています

• ② : ( admin-account ) LambdaがConfig Rulesから渡された情報を評価します、そして、managed-accountに対してAssumeRoleします。

• ③ : ( admin-account ) LambdaがAssumeRoleで得られたアクセス権限(putEvaluations)を使って、評価結果を( managed-account ) Config Rulesに送ります。

• ④ : ( managed-account ) Config Rulesが評価結果を受け取り、SNSに通知します。

• ⑤ : ( managed-account ) SNSがConfig Rulesからの通知を受け取り、予め設定されている通知先(今回はメールアドレス)に送信します。

設定手順

( admin-account ) Lambdaの設定

1. Servicesタブ → Lambda → Lambdaを新しく作成します。
   

2. 今回はblueprintのconfig-rule-change-triggeredを使います。
   

3. このまま「Next」をクリックします。
   

4. Nameは適宜で良いです(例では、Check-LogValidation-Enabledにします)、Runtimeを「Node.js 4.3」にします。

   • blueprintのコードを変更する必要がありません。

5. Lambda用のロールを新たに作成しますので、Role欄に「Create a custom role」を選択します。

   • 既存のロールを利用して良いです。

6. Lambda用のロール名は適宜で良いです、(例では、lambda_basic_executionにします)
   

7. ロールlambda_basic_executionを作成されたことを確認し、「Next」をクリックします。

   • ロールlambda_basic_executionはあとで、managed-accountに対してAssumeRoleできるように設定します。
     • 今回権限まわりをまだ確認できていないので、ロールlambda_basic_executionにはデフォルトで設定されている権限以外に、検証用にPowerUserAccessを付けました。
   • 必要に応じて、Memoryなどのconfigurationsを変更してください。

8. Lambdaの情報を一度確認し、作成します。
   

9. Lambda(Check-LogValidation-Enabled)を作成されたことを確認します。
   

10. managed-accountのConfig RulesがCheck-LogValidation-EnabledをInvokeできるように、下記のコマンドを実行します。

    • 例では、managed-account(AccountId:2847※※※※1948)がCheck-LogValidation-EnabledをInvokeできるように設定しています。( AWSマネコンからは設定できません )

11. Lambdaの準備が終了

( managed-account ) AssumeRole用のroleの設定

1. Servicesタブ → IAM → ロール → 「新しいロール作成」をクリックします。

   • ロール名は適宜替えてください

2. クロースアカウントアクセスのロール → 「所有しているAWSアカウント間のアクセスを提供します」を選択します。
   

3. アカウントID欄に信頼する別のAWSアカウントを入力します。(自分の場合は8918****5875)

   • 「MFAが必要」のチェックを入れいないでください(入れてしまうと、クロスアカウントでコマンドを実行するたびに、MFAで２段階認証をしないといけなくなります)

4. ポリシーについては、後で設定しますので、今はこのまま「次のステップ」へ進みましょう。
   

5. 一度確認します、問題がなければ、「ロールの作成」をクリックします。
   

6. AssumeRole用のロール(config-rules-admin)が作成されましたね。
   

7. config-rules-adminをクリックして、「アクセス許可」の「インラインポリシー」で( admin-account ) Lambda用のポリシーを作成します。
   

8. カスタムポリシーを選択します。
   

9. 作成したいポリシーは以下になります。
   

10. ロールポリシーPutEvaluationsが作成されたことを確認します。
    

11. セキュリティを強化するために、信頼関係を修正しますので、「信頼関係の編集」をクリックします。
    

12. 信頼するのを( admin-account ) Lambda用のロール(例では、lambda_basic_execution)に限定しますので、以下のように修正します。
    

13. 信頼関係を修正されたことを確認します。
    

14. AssumeRole用のロールの準備が終了

( managed-account ) SNSの設定

1. AWS ConfigのSettings → Amazon SNS topicの部分を以下のように設定します。

   • Topic nameは任意の名前で良いです。(今回はEvaluations-reportとします)

2. ServicesのSNS → Topic 、Evaluations-reportを選択します。

   • 新しいTopic(Evaluations-report)が作成されていますね

3. Create subscriptionをクリックしますと、新しい欄が表示されます。
   
   　↓　↓　↓　↓　↓　↓　↓　↓　↓　↓　↓　↓　↓　↓　↓　
   ProtocolをEmailに選択し、Endpointに通知先のメールアドレスを入力して、Create subscriptionをクリックします。
   

4. Create subscriptionをクリックすると、確認用のMessageがAWSから入力されたメールアドレスに送付されます。確認を取れるまで、Subscription IDのところにはPendingConfirmationとなっています。
   

5. 送信されたメールを確認し、Confirm subscriptionをクリックします
   

6. AWSが確認を取れれると、Subscription IDのところにはSubscription IDの情報が表示されるようになります。
   

7. SNSの設定が完了

( managed-account ) Config Rulesの設定

1. Servicesタブ → Config → Rules → Add ruleにて、custom ruleを作成します。
   

2. custom ruleのconfigを設定します。

   • Nameは適宜で良いです。(例では、CloudTrail-LogValidation-Enabled)
   • AWS Lambda function ARN欄に、( admin-account ) Lambda Check-LogValidation-EnabledのARNを記入します。
   • Triggerについては、図に示す通りに設定します。
   • Rule parametersはKeyをexecutionRoleに、ValueをAssumeRole用のロールconfig-rules-adminのARNに設定します。

3. config ruleを作成されましたら、 準備が終了
   

検証の前提条件

　managed-accountに既にCloudTrailが設定されていることが必要です。当然のことなんですが、CloudTrailを設定されないと、（評価対象がないから）Config Rulesが評価できません。
　ちなみに、こんな検証用のCloudTrailを作りました。「Enable log file validation」は「No」になっています。

検証結果

Enable log file validationがNoの場合

Config Rules

　リソースCloud-Trailに対する評価はNoncompliantになっていますね。

↓　↓　↓　↓　↓　↓　↓　↓　

E-mail通知

　管理者のE-mailにConfigの評価レポートが送信されます。これで、どのリソースがNoncompliantになっているかも分かりますね！

Enable log file validationがYesに設定した場合

Config Rules

　リソースCloud-Trailに対する評価はちゃんとCompliantになりました。

↓　↓　↓　↓　↓　↓　↓　↓　

E-mail通知

　管理者のE-mailにConfigの評価レポートが送信されます。ちゃんとlogfileのvalidationをenableにしましたので、Compliantになったことを管理者に通知します。

まとめ

　今回は、LambdaとConfig Rulesを使って、CloudTrailのlogfileのvalidationをチェックし、評価結果を管理者に通知することを検証しました。意外と簡単にできます。
　Config RulesはAWSのリソースをちゃんとルールに沿っているかの確認できますので、AWSセキュリティ担当者もしくは内部統制者にとって、非常に強力な"武器"だと思っています。コンプライアンス違反になったリソースを即座に検知・通知ができますので、個人的にもさらにConfig RulesをDeepDiveして、業務にも活用したいと思います。
　現在Config Ruleに使えるマネージドルールが９つあって、GitHubにも便利そうなカスタムルール(awslabs/aws-config-rules)があります。興味がある方は一度やってみてください！

最後

　余談になりますが、少し前に、IAMユーザ・AccessKeysの運用管理に使うものを作ってみました、（トライアル運用中ですが）興味がある方は下記２つの投稿を見てください。

• Lambda & CloudWatchEvents & Slackで 長期的にログインしていないIAMユーザを検知・通知する
• Lambda & CloudWatchEvents & Slackで 長期的に利用されていないAccessKeyを検知・通知する