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

1. 「これ危ない設定
じゃないでしょうか」
とヒアリングする
ための仕組み
株式会社サイバーエージェント
柿島 大貴、東 和宏

2. 柿島 大貴
カキシマ ヒロタカ
2
インフラエンジニア
共著 HBase徹底入門（翔泳社）
AbemaTV負荷対策プロマネ（2017）
好きなAWSサービス
Amazon
S3

3. 東 和宏
アズマ カズヒロ
3
インフラエンジニア
好きなAWSサービス
プライベートクラウド立ち上げ
AbemaTV コンテンツ基盤構築中
AWS
CloudFormation

4. アジェンダ
4
①
③ ④
②
統制する仕組み
新しい取り組み
組織について
悩んでいること

5. 株式会社サイバーエージェント
5

6. 技術本部
メディア事業の横断組織でパブリッククラウドの管理をしています
技術本部
メディア事業
プライベート
クラウド
提供
インフラ
SRE
パブリック
クラウド
サポート
セキュリティ
分析
機械学習
開発環境 購買など
他にも多数
のサービス
6

7. AWSアカウント発行から解約までサポート
7
アカウント発行 運用中の問題 アカウント解約

8. 管理業務の例
8
請求や契約
with 経理/法務
依頼処理 トラブル対応 セキュリティ対応
with セキュリティチーム
① ② ③ ④

9. 9
AWS担当者とのやりとり Solutions Architect
成田様
Account Manager
辻本様
Technical Account Manager
新井様
⑤
管理業務の例
いつもありがとうございます！

10. 規模感
10

11. AWS利用の規模感
11
•AWSアカウント
• プロジェクト、機能、環境（本番、開発）などで分離
• 累積 約 250 アカウント
• 現在 約 160 アカウントがアクティブ

12. メディア管轄でAWSを利用するエンジニア
12
約400名弱
約20～30名数名 300名～
セキュリティエンジニア
インフラエンジニア
SRE/ネットワーク等
サーバサイドエンジニア等

13. クラウドの管理者
13
2名

14. アジェンダ
14
①
③ ④
②
統制する仕組み
新しい取り組み
組織について
悩んでいること

15. 管理業務の中でも特にセキュリティの話
15
請求や契約
with 経理/法務
依頼処理 トラブル対応 セキュリティ対応
with セキュリティチーム
① ② ③ ④

16. 会社横断のセキュリティチームと連携
16https://www.wantedly.com/projects/203471

17. ログイン関連
17

18. 18
サーバー AWSマネージメントコンソール

19. 権限の管理
19
•LDAPを利用
• 人事データベースと同期
• 権限管理用のポータルがある
• AWSアカウントごとに権限が存在
• 役割ごとの権限も設定可能

20. サーバーへのログイン
•LDAPを使った公開鍵認証、踏み台やVPNも提供
20
LDAP
サーバー
各AWSアカウント
監査、共通基盤の
AWSアカウント
Elastic Load
Balancing
VPC
peering
EC2
EC2

21. 制限から複数のVPCを作成
21
LDAP
サーバー
各AWSアカウント
監査、共通基盤の
AWSアカウント
Elastic Load
Balancing
VPC
peering
EC2
EC2
• VPC 当たりのアクティブな VPC ピアリング接続（最大125）
• ルートテーブル当たりのルートの数（最大100）
×2
AWS PrivateLinkを検証中

22. マネージメントコンソールへのログイン
•LDAPと連携した SAMLベースのフェデレーション
•OpenAMからセキュリティチーム内製のものへ移行中
22
2FA

23. その他の取りくみ
23

24. すべてのアカウントで有効化
24
AWS
CloudTrail
Amazon
GuardDuty

25. 監査用のアカウントにデータを集約
25
AWS
CloudTrail
Amazon
S3
ログ
各AWSアカウント
共通の保管用
バケット
Amazon
GuardDuty
メンバーアカウント
Amazon
GuardDuty
マスターアカウント
各AWSアカウント

26. 面倒な設定は自動化
•GuardDutyの設定が特に大変
• アカウント、リージョンごとに招待、有効化、承認が必要
• その他の設定も含めてJenkins化
26

27. AWS Organizations
•元々、一括請求機能を使用
•最近、すべての機能を有効化
• SCPも一部導入
• ブラックリスト方式
27

28. 管理用 AWSアカウントの構成
Organizationsのマスターアカウント
• 請求 / Organizations /リザーブドインスタンスの管理
28
監査、共通基盤のアカウント
• CloudTrailのログ集約、LDAPサーバーなど

29. ツリーの構成やポリシーは試行錯誤中
29
Organizationsの
マスターアカウント
監査、共通基盤の
アカウント
多くのプロジェクトの
アカウント
一部のクリティカルな
プロジェクトのOU
Organization検証用の
プロジェクトのOU
Root

30. SCP（サービスコントロールポリシー）
嬉しいこと
• DenyしたアクションはIAM, ルートアカウントともに対象
• iam:Create* , iam:Put*, iam:Attach*の権限があっても制限可
注意点
• Resourceは*で固定
• アクションのワイルドカード指定は後ろだけ
• ボディの長さは5120 bytes（複数に分割して対応）
30

31. 他にも様々な取り組み
• SAによるレビュー
• 弊社のSREとAWS Well-
Architected Frameworkを推進
• 日々の様々な相談
31
• ルートアカウントの管理
• MFAの管理
• 脆弱性診断の申請のサポート
• エンタープライズサポート加入
• e-learning
• 新卒研修
など
AWSとの取り組み 基本的な取り組み

32. アジェンダ
32
①
③ ④
②
統制する仕組み
新しい取り組み
組織について
悩んでいること

33. 33
自由 責任
組織の文化

34. 組織の文化
サイバーエージェントは2006年から本格的にエンジニ
ア組織を強化しました。その間、100はゆうに超える新
規サービスを立ち上げてきました。
その間「自由と自己責任」というものを掲げ、担当す
るエンジニアがその時に最もベストな技術を選定し挑
戦をしてきました。（略）
エンジニアに裁量を与える代わりに説明責任を求めま
す。
34
https://www.wantedly.com/companies/abema/post_articles/33695

35. AWS製品の選択の裁量はプロジェクトにある
35

36. チャレンジの結果、事例になることも
36

37. カオスになりやすい環境
37
自由と自己責任の文化 エンジニアの数も多い 新卒も多い
新規事業も多い 異動もそれなりに

38. 責任共有モデルにより、AWSの顧客は
クラウド”における”セキュリティの責任を負う
38
Infrastructure servicesの責任共有モデルの図

39. 守るところは守る
39
管理上守りたい部分
最小権限の原則 を促す
フールプルーフを用意
AWS
CloudTrail
AWS
Config
Amazon
GuardDuty
IAM
厳格なポリシーに従う
必要のあるデータや
プロジェクト
事故が起こりやすい部分
IAM
IAMやOrganizationsで制限
（前半の説明部分など）

40. 制限と自由のバランスは難しい
40
自由すぎると問題が起こりやすい
制限をしすぎると開発スピード低下

41. どのアクションが危ないか…は難しい
41
危ないアクション安全なアクション
許可 禁止
セキュリティチームと議論して基本ポリシーは決定
例
s3:PutBucketPolicy
使い方次第

42. アジェンダ
42
①
③ ④
②
統制する仕組み
新しい取り組み
組織について
悩んでいること

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

44. なぜヒアリングなのか
44
•プロジェクトに裁量を与える
•問題がある場合には利用者に修正を依頼
•意図を確認しないと判断が難しいものが存在する

45. 仕組みは大きく2つ
45
スケジュールベースイベントベース

46. イベントベース
46

47. （再掲）監査用のアカウントにデータを集約
47
AWS
CloudTrail
Amazon
S3
ログ
各AWSアカウント
共通の保管用
バケット
Amazon
GuardDuty
メンバーアカウント
Amazon
GuardDuty
マスターアカウント
各AWSアカウント

48. システム構成（イベントベース）
48
AWS
CloudTrail
Amazon
S3
CloudTrailのログ
メディア事業部
の各アカウント
共通の保管用
バケット
イベントで
SNS通知
Amazon
SNS
AWS
Lambda
Amazon
SNS
イベントの
メッセージ
ログ取得
イベントごとに
メッセージ送信
（チェック項目ごと）
AWS
Lambda
Amazon
S3
ホワイトリストの取得
Amazon
CloudWatch
Events
イベント
Amazon
GuardDuty
メンバーアカウント
Amazon
GuardDuty
マスターアカウント
通知
イベントデータの収集 判定と通知

49. 通知の例（S3 Bucket ACLの変更）
49

50. 通知の例（Security Groupの変更）
50

51. 通知の例（GuardDutyの検知）
51

52. スケジュールベース
52

53. 53
Amazon
S3
チェック対象の
アカウント
AWS
Lambda
Amazon
SNS
結果の保存
（JSON）
（チェック項目ごと）
Amazon
CloudWatch
Events
AWS
Lambda
スケジュール
呼び出し
アカウントIDを含んだ
メッセージを送信
チェック対象の
アカウントIDのリストを取得
Amazon
S3
Amazon
CloudWatch
Events
AWS
Lambda
スケジュール呼び出し
レポートの生成
Assume Role
リソースの情報取得
JSON
HTML レポートの閲覧
AWS
Organizations
AWSアカウントと
LDAPのマッピング情報
Amazon
S3
ホワイトリストの取得
通知
LDAPサーバー
ユーザー一覧の取得
Amazon
SNS
通知タイミングごとの
SNSメッセージ
システム構成（スケジュールベース）
スケジュール生成 アカウント一覧生成 チェックと通知とレポート生成

54. 通知の例（IAMユーザーの棚卸し）
54

55. 通知の例（SESのバウンス率、苦情率）
55

56. 通知の例（LDAPユーザーの定期棚卸し）
56

57. 通知の例（SSL/TLS証明書の期限）
57

58. 診断レポート
58
• Trusted Advisorの結果
• 独自チェックの結果
• CIS AWS Foundations Benchmark
• ベンチマークに沿ったチェック結果
• コマンドベースでチェック方法記載
• 通知のしきい値の参考にもしている
• セキュリティグループの一覧

59. なぜAWS Config Rulesではないの？
59
•アクティブなルール1つごとに2 USD/月
• リージョンごと、アカウントごとに費用増
•なるべく監査側のアカウントに設定を作りたい

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

61. 今回は、利用者と一緒に受け取る方式に
61
• AWSアカウント毎に通知先を用意
• LDAPの権限を元に招待
AWSアカウントごと
のチャンネル
利用者&管理者
検知
システム
アラート

62. 起こった変化
62
自主的に対応して
くれる人が現れた
アドバイスをくれる人
が現れた
実際に棚卸しが進んだ
早期検知が出来た

63. 利用者の声
63
検知が自動化されることはもち
ろん、無駄な通知を減らしたい
がために後回しになりがちな棚
卸しをするきっかけを生んでく
れて助かっています！
サービスリライアビリティグループ
マネージャー / エンジニア 須藤 涼介

64. 今後について
• 今回の方法がベストだとは思っていない
• 情報収集と定期的な見直し
• ポリシー
• 検査項目
• 道具（コスト、便利さ、柔軟性）
• 別レイヤーのチェック
• 例: Amazon InspectorやVulsの利用普及
• 一部環境では導入済
64

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

66. 宣伝
•一緒に働いてくれる方を募集！
• https://www.cyberagent.co.jp/careers/
•CyberAgent Developers Blog
• https://developers.cyberagent.co.jp/blog/
• 各サービスのエンジニアやクリエイターの技術をお届けします
66

67. 素材利用、参考資料
•ヒューマンピクトグラム2.0
• http://pictogram2.com
•Material icons
• https://material.io/tools/icons/
• This slide includes the work that is distributed in the Apache License 2.0.
•AWSでのセキュリティ運用 ～ IAM,VPCその他
• リクルートテクノロジーズ様 の資料
• https://www.slideshare.net/recruitcojp/20160517-security-jaws-miyazakisachie
• 非常に参考にさせていただいています
67