前置き
私が勤めている会社では、約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の設定
- Servicesタブ → Lambda → Lambdaを新しく作成します。
- 今回はblueprintのconfig-rule-change-triggeredを使います。
- このまま「Next」をクリックします。
- Nameは適宜で良いです(例では、Check-LogValidation-Enabledにします)、Runtimeを「Node.js 4.3」にします。
- blueprintのコードを変更する必要がありません。
- Lambda用のロールを新たに作成しますので、Role欄に「Create a custom role」を選択します。
- 既存のロールを利用して良いです。
- Lambda用のロール名は適宜で良いです、(例では、lambda_basic_executionにします)
- ロールlambda_basic_executionを作成されたことを確認し、「Next」をクリックします。
- ロールlambda_basic_executionはあとで、managed-accountに対してAssumeRoleできるように設定します。
- 今回権限まわりをまだ確認できていないので、ロールlambda_basic_executionにはデフォルトで設定されている権限以外に、検証用にPowerUserAccessを付けました。
- 必要に応じて、Memoryなどのconfigurationsを変更してください。
- Lambdaの情報を一度確認し、作成します。
- Lambda(Check-LogValidation-Enabled)を作成されたことを確認します。
- managed-accountのConfig RulesがCheck-LogValidation-EnabledをInvokeできるように、下記のコマンドを実行します。
- 例では、managed-account(AccountId:2847※※※※1948)がCheck-LogValidation-EnabledをInvokeできるように設定しています。( AWSマネコンからは設定できません )
- Lambdaの準備が終了
( managed-account ) AssumeRole用のroleの設定
- Servicesタブ → IAM → ロール → 「新しいロール作成」をクリックします。
- ロール名は適宜替えてください
-
クロースアカウントアクセスのロール → 「所有しているAWSアカウント間のアクセスを提供します」を選択します。
-
アカウントID欄に信頼する別のAWSアカウントを入力します。(自分の場合は8918****5875)
- 「MFAが必要」のチェックを入れいないでください(入れてしまうと、クロスアカウントでコマンドを実行するたびに、MFAで２段階認証をしないといけなくなります)
-
ポリシーについては、後で設定しますので、今はこのまま「次のステップ」へ進みましょう。
-
一度確認します、問題がなければ、「ロールの作成」をクリックします。
-
AssumeRole用のロール(config-rules-admin)が作成されましたね。
-
config-rules-adminをクリックして、「アクセス許可」の「インラインポリシー」で( admin-account ) Lambda用のポリシーを作成します。
-
カスタムポリシーを選択します。
-
作成したいポリシーは以下になります。
-
ロールポリシーPutEvaluationsが作成されたことを確認します。
-
セキュリティを強化するために、信頼関係を修正しますので、「信頼関係の編集」をクリックします。
- 信頼するのを( admin-account ) Lambda用のロール(例では、lambda_basic_execution)に限定しますので、以下のように修正します。
- 信頼関係を修正されたことを確認します。
- AssumeRole用のロールの準備が終了
( managed-account ) SNSの設定
- AWS ConfigのSettings → Amazon SNS topicの部分を以下のように設定します。
- Topic nameは任意の名前で良いです。(今回はEvaluations-reportとします)
- ServicesのSNS → Topic 、Evaluations-reportを選択します。
- 新しいTopic(Evaluations-report)が作成されていますね
- Create subscriptionをクリックしますと、新しい欄が表示されます。
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
Protocolを**Email**に選択し、Endpointに通知先のメールアドレスを入力して、Create subscriptionをクリックします。
- Create subscriptionをクリックすると、確認用のMessageがAWSから入力されたメールアドレスに送付されます。確認を取れるまで、Subscription IDのところにはPendingConfirmationとなっています。
- 送信されたメールを確認し、Confirm subscriptionをクリックします
- AWSが確認を取れれると、Subscription IDのところにはSubscription IDの情報が表示されるようになります。
- SNSの設定が完了
( managed-account ) Config Rulesの設定
- Servicesタブ → Config → Rules → Add ruleにて、custom ruleを作成します。
- 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に設定します。
- 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の運用管理に使うものを作ってみました、（トライアル運用中ですが）興味がある方は下記２つの投稿を見てください。