【サイバーエージェント様ご登壇事例】【レポート】「これ危ない設定じゃないでしょうか」とヒアリングするための仕組み #AWSSummit

AWS Summit Tokyo 2018。Day2 で開催された『【サイバーエージェント様ご登壇事例】「これ危ない設定じゃないでしょうか」とヒアリングするための仕組み』についてレポートします。

スピーカー

• 柿島 大貴さん
  • 株式会社サイバーエージェント 技術本部 ソリューショングループ エンジニア
• 東 和宏さん
  • 株式会社サイバーエージェント 技術本部 ソリューショングループ エンジニア

セッション概要

株式会社サイバーエージェントのメディア事業でクラウドの管理者として働く 2 人の日々の悩みや試行錯誤の様子を共有させていただきます。ベストプラクティスや驚くような技術とは言えないかもしれないですが、組織でのクラウド利用に おける開発スピードや柔軟性と安全のバランスを目指している １ つの事例として紹介をさせていただきます。

スライド

（聴講後、スライドが公開されていました） [slideshare id=99689231&doc=awssummit2018cakakishimaazuma-180531064912]

アジェンダ

• 組織について
• 統制する仕組み
• 悩んでいること
• 新しい取り組み

組織について

サイバーエージェント様では、「メディア事業」「インターネット広告事業」「ゲーム事業」の３つがあり、それぞれ独立してパブリックラウドを管理している。今回は、「メディア事業」のクラウドを管理されているお二人のご登壇でした。

パブリククラウドの管理

パブリッククラウドの管理では以下のようなことを行っている。

• アカウント発行
• 運用中の問題をサポート
• アカウントの解約

管理業務とは以下のような業務。

• 請求や契約
• 依頼管理（IAMユーザの作成依頼など）
• トラブル対応
• セキュリティ対応
• AWS 担当者とのキャッチアップ

規模感

• AWS アカウント数は約 250
  • アクティブアカウント数も 160 はある。
• 傾向
  • プロジェクト、機能、環境（本番、開発など）で AWS アカウントを分離している
  • アカウント数は増え続けてる
• メディア事業で 400 弱のユーザが利用中
• これらの環境を、登壇者のお二人だけで管理してる
  • 管理者は非常に強い権限を持つため、むやみに管理者を増やすことは出来ない

統制する仕組み

セキュリティの専門ではない、と仰るお二人が、どのように AWS アカウントを統制する仕組みを作ってきたかについて。

AWS 環境へのログイン

• サーバへのログイン
• AWS マネジメントコンソールへのグイン

LDAPの利用

権限の管理に LDAP を使い、人事データベースと同期させている。また、権限管理用のポータルが存在し、各プロジェクトの管理者が自由に改廃できるようになっている。

サーバへのログインは LDAP

• 各LDAP の前段には ELB を配置し、分散させている。
• LDAP が所属する VPC は管理用に分離されており、利用者の AWS アカウントから VPC ピアリングで接続し、LDAP を参照できるようにしている。
• クライアント側では、UserData や、Packer などを利用し、LADAP のクライアント設定を行っている。

大規模ならではの問題もあった。

• VPC あたりのアクティブなピアリング接続が、最大 125 であること
• ルートテーブルあたりのルート数が、最大 100 であること

やむなく、同じような LDAP 認証基盤用の VPC を新規に作り、なんとか対応している。今後、PrivateLink を使い、うまく出来ないか検討している。

マネジメントコンソールへのログイン

これまでは、OpenAM を利用していたがセキュリティチーム内製に移行中。LDAP と連携した SAML ベースのフェデレーション　を使用。

その他の取り組み

AWS CloudTrail、Amazon GuardDuty

• 全アカウントで有効にしている。
• ログは管理用の AWS アカウントにすべて集約している
• 面倒な設定は自動化
  • Amazon GuardDuty の設定が特に大変。
  • アカウント、リージョンごとに招待、有効化、承認が必要。
  • その他の設定を含めて Jenkins で回している。

AWS Organizations

これまで一括請求のために使っていたが、最近は、すべての機能を有効化にした。。SCP（サービスコントロールポリシー）も一部、ブラックリスト方式で利用している。

• 管理用 AWS アカウントの構成
  • Organizations のマスターアカウント
    • 請求、Organizations、リザーブドインスタンスの管理
  • 監査、共通基盤のアカウント
    • CloudTrailのログ集約、LDAP サーバなど
• ツリーの構成や、ポリシーは試行錯誤中

SCP（サービスコントロールポリシー）

• うれしかったこと
  • Deny したアクションは IAM 、ルートアカウントともに対象になる。
• 注意点
  • IAM のようにリソース毎の指定できない。

悩んでいること

組織の文化は 「自由」と「責任」

サイバーエージェントは2006年から本格的にエンジニア組織を強化しました。その間、100はゆうに超える新規サービスを立ち上げてきました。その間「自由と自己責任」というものを掲げ、担当するエンジニアがその時に最もベストな技術を選定し挑戦をしてきました。そのマインドは決して失われることなく、サイバーエージェントグループのエンジニアにしっかりと引き継がれています。

AWS の選択の裁量はプロジェクトにあり、チャレンジの結果、事例になることもある。ただし、カオスになりやすい。

• 自己責任
• エンジニアの数が多い
• 新卒も多い
• 新規事業
• 異動もそれなりに多い

責任共有モデルにより、AWSの顧客はクラウドにおけるセキュリティの責任を負う部分があるため、守るところは守る必要がある。しかしながら、制限と自由のバランスは難しい。

• 制限しすぎると開発スピード低下
• 自由すぎると問題は起こりやすい

どのアクションが危ないかを判断することは難しい

• 例えば、S3PutBucketPolicy 権限が「危ない」か、「安全」は使い方次第
• セキュリティチームと相談してポリシーを決定している

新しい取り組み

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

• なぜヒアリングするのか
  • プロジェクトに裁量を与えてる
  • 意図を確認しないと判断が難しい
• 仕組みは大きく２つ
  • イベントベース
  • スケジュールベース

イベントベース

監査用のアカウントにデータを集約しているし、イベントをトリガーにチェックしている。

• 例：S3イベント →　Lambda → 問題あれば Slack 通知など
  • 何が危険か、どう対応すればよいかの案内リンクも一緒におくる
• 例：セキュリティグループの通知例
  • 会社の管理IP以外からの「許可」が登録され場合に通知するなど
• 例:GuardDuty
  • リモートワークなど自宅環境が増えると誤検知はある。対策の仕組みも進めている。

スケジュールベース

• 例：アクセスキーが90日以上使われてない場合、通知する
• 例：SES のバウンス率、苦情率 の報告
• 例：LDAP ユーザの定期棚卸し
• 例：SSL/TLS 証明書の期限

診断レポート

• Trusted Advisorの結果
• 独自チェックの結果
• CIS AWS Foundations Benchmark
• セキュリティグループの一覧

なぜ AWS Config Rules ではないの？

• アクティブなルール１つごとに $2/月
  • リージョンごと、アカウントごと
• なるべく監査用のアカウントに設定を作りたい

2016 年にブログで公開。でも一度は失敗した - すべてのアラートを管理者だけで受け取った - プロジェクトとの連絡手段を確立できていなかった

今回は、利用者と一緒に受け取る方式に変えた 起こった変化 - 自主的に対応してくれる人が現れた - アドバイスをくれる人があらわれた - 実際に棚卸しが進んだ、早期検知ができた

今後について 今の方法がベストだと思ってない。情報収集と定期的な見直す。 - ポリシー - 検査項目 - ツール 別レイヤーのチェックも取り組みたい - Amazon Inspector - Vuls　

まとめ

• 増え続ける AWS アカウントの責任をどう果たすか
• 制限と自由のバランスは常に悩んでいる
• 情報交換させてください！

さいごに

大規模な AWS アカウントを管理するうえでの試行錯誤が詰まっており、とても参考になるセッションでした！CIS AWS Foundations Benchmark を使ったチェックされているとのことなので、弊社の 「insightwatch」をお試しいただき、フィードバックが欲しいと思った次第です！（個人的な意見です）

以上！大阪オフィスの丸毛（@marumo1981）でした！