「これ危ない設定じゃないでしょうか」とヒアリングするための仕組み

（2019/04 追記 続編としてAWS Summit Tokyo 2018で発表をしました 「これ危ない設定じゃないでしょうか」とヒアリングするための仕組み @AWS Summit Tokyo 2018）

メディア事業で、AWSやGCPといったパブリッククラウド関連の業務を担当しているインフラエンジニアの柿島大貴です。 CyberAgent Developers Advent Calendar 2016 6日目の記事です。昨日は @stormcat24 さんの「 秘技！無停止ドメイン移行芸 」でした。無停止ｶｯｺｲｲ

昨年のアドベントカレンダーでは、GCPのコスト可視化に関して投稿しました。後日談としては、可視化にはCloud DatalabではなくRedashを選び、各サービスのインフラエンジニアによるコスト監視（毎月のコスト振り返り、アラートの生成など）に利用しています。

今回は、事業部内のAWS利用者に対して、「これ危ない設定じゃないでしょうか」とヒアリングするための仕組みづくりに取り組んだ話です。

背景

私のチームは、メディア事業で利用するパブリッククラウドのアカウント管理なども担当しています。メディア事業では100を超えるAWSアカウントがアクティブになっています。これらのアカウントは利用するチームやメンバーもバラバラ、クラウドの経験やスキルもバラバラといった感じで、とても詳しいチーム/エンジニアもいれば、まったく触るのが初めてというチーム/エンジニアもいる状況です。オンプレで運用していたときと違い、従来ネットワーク、インフラ、セキュリティといったエンジニアが集中的に設定をしていた部分も、各サービスのエンジニアの判断で設定をすることができるようになりました。スピード感でのメリットもありますが、セキュリティ上問題がありそうな設定をしてしまう方もたまに現れます。

「責任共有モデル」にある通り、私たちAWSを利用する側もセキュリティ上の責任を負っています。危ういリソースの設定があれば、自分たちで発見して駆逐していく必要があります。

AWS がクラウドのセキュリティを管理している一方で、クラウドにおけるセキュリティはお客様の責任となります。お客様は、所有するコンテンツ、プラットフォーム、アプリケーション、システムおよびネットワークを保護するためにどのようなセキュリティを実装するかについて管理権限を保持しており、これはオンサイトのデータセンターのそれとなんら変わることはありません。

https://aws.amazon.com/jp/compliance/shared-responsibility-model/

危ない設定が作られないように権限を与えないという方法もありますが（一部はそうしていますが）、あまり制限をしすぎてしまうと開発速度や利便性を下げてしまう部分もあります。常に悩まされています。また、ヒアリングをしないと白黒をつけられないグレーなものもあって、一律なIAMの制限だけで解決をするのは難しいと思っています。メディア事業部では、マネージメントコンソールへのアクセスにSAML認証を利用したフェデレーションユーザを利用していますが、そのアクセス時に紐づくIAM Roleの権限は、セキュリティチームと話しながらバランスを考えて設定しています。その上で、怪しい設定が作られたときにヒアリングをして問題があれば修正してもらうために、アクションとリソースのチェックができる仕組みを検討しました。

構成検討時に考慮したこと

• 既にアカウントのCloudTrailのログは、共通のアカウントのバケットに保存する設定をしていた

• チェック対象のAWSアカウント側の設定は最低限にして、なるべくチェックを行うアカウント側に仕組みを作りたい
• チェック対象のAWSアカウント側で発生するコストは最低限にとどめたい

最終的には、チェック対象の各AWSアカウントにはクロスアカウントアクセス用のIAMロールのみ追加で作成をしました。それぞれのチェックの仕組みは以下のような構成にしました。（あんまり目新しいものではないかとは思います）

アクション実行時のチェック

1. 各アカウントのCloudTrailのログが共通アカウントのS3バケットに送られる
2. S3のObjectCreatedのイベント通知でSNSトピックにメッセージを発行
3. SNSトピックをTriggerとするLamda Functionをチェックの内容ごとに設定
4. Lambda Function内でS3からログを取得、アクションの内容をチェック
5. チェックの結果、アラートを飛ばすべき内容であれば、アラート用のSNSトピックにメッセージを発行
6. アラート用のSNSトピックをサブスクライブしているメールや、Slack通知用のLambda Function経由で通知を行う

怪しいアクションがあったら、Slackにはこんな感じで通知が来ます。

リソースの定期チェック

1. Amazon CloudWatch Eventsのイベントスケジュール機能をTriggerとした Lambda Functionを設定する。
2. Lambda Function内でチェック対象のアカウントのリストを取得して、アカウントIDごとに、アカウントIDをメッセージに含んだメッセージを発行
3. SNSトピックをTriggerに、メッセージに含まれるアカウントIDのチェックをするLambda Functionを実行
4. Lambda Function内では、チェック対象のアカウントに作成したクロスアカウントアクセス用のIAM RoleにAssume Roleをして調査対象の各種リソースの情報を取得、チェックをする
5. 判定した結果はJSON形式でバケットに保存するとともに、アラートが必要であれば、アラート用のSNSトピックにメッセージを発行
6. アラート用のSNSトピックをサブスクライブしているメールや、Slack通知用のLambda Function経由で通知を行う
7. 別のAmazon CloudWatch Eventsのイベントスケジュール機能をTriggerとした Lambda Functionで、定期的にJSON形式で保存された結果をまとめたレポートページを作成

チェックの内容は、TrustedAdvisorの結果、 CIS AWS Foundations Benchmark を参考にしたチェック、独自のチェックという感じになっています。

これらの仕組みを使って、危なそうなアクションやリソースを見つけて、確認の依頼をするということを少しずつはじめています。

なお、AWSには様々なサービスがありますので、CloudTrailのログのモニタリングや、リソースのチェックを検討されている方は以下の資料にあるような方法も合わせてご覧ください。

• Monitoring CloudTrail Log Files with Amazon CloudWatch Logs
• AWS Config Rules – Dynamic Compliance Checking for Cloud Resources
• Trusted Advisor Best Practices (Checks)
• Amazon Inspector

先日発表されたAWS Organizationsや、ベータ機能になったGCPのOrganizations など、組織でのクラウド利用に便利そうな機能が登場してきて嬉しいです。来年も開発スピードと安全のバランスを追い求め、いろいろ試行錯誤していきたいと思います。以上、「これ危ない設定じゃないでしょうか」とヒアリングするための仕組みでした。明日の CyberAgent Developers Advent Calendar 2016 は @arumani さんです。