View
0
Download
0
Category
Preview:
Citation preview
「これ危ない設定じゃないでしょうか」
とヒアリングするための仕組み
株式会社サイバーエージェント
柿島大貴、東和宏
柿島大貴カキシマヒロタカ
2
インフラエンジニア
共著 HBase徹底入門（翔泳社）
AbemaTV負荷対策プロマネ（2017）
好きなAWSサービス
Amazon
S3
東和宏アズマカズヒロ
3
インフラエンジニア
好きなAWSサービス
プライベートクラウド立ち上げ
AbemaTVコンテンツ基盤構築中
AWS
CloudFormation
アジェンダ
4
①
③ ④
②
統制する仕組み
新しい取り組み
組織について
悩んでいること
株式会社サイバーエージェント
5
技術本部
メディア事業の横断組織でパブリッククラウドの管理をしています
技術本部
メディア事業
プライベートクラウド提供
インフラSRE
パブリッククラウドサポート
セキュリティ分析機械学習
開発環境 購買など
他にも多数のサービス
6
AWSアカウント発行から解約までサポート
7
アカウント発行 運用中の問題 アカウント解約
管理業務の例
8
請求や契約with経理/法務
依頼処理 トラブル対応 セキュリティ対応with セキュリティチーム
① ② ③ ④
9
AWS担当者とのやりとり Solutions Architect
成田様Account Manager
辻本様Technical Account Manager
新井様
⑤
管理業務の例
いつもありがとうございます！
規模感
10
AWS利用の規模感
11
•AWSアカウント•プロジェクト、機能、環境（本番、開発）などで分離
•累積約250 アカウント
•現在約160 アカウントがアクティブ
メディア管轄でAWSを利用するエンジニア
12
約400名弱
約20～30名数名 300名～
セキュリティエンジニアインフラエンジニアSRE/ネットワーク等
サーバサイドエンジニア等
クラウドの管理者
13
2名
アジェンダ
14
①
③ ④
②
統制する仕組み
新しい取り組み
組織について
悩んでいること
管理業務の中でも特にセキュリティの話
15
請求や契約with経理/法務
依頼処理 トラブル対応 セキュリティ対応with セキュリティチーム
① ② ③ ④
会社横断のセキュリティチームと連携
16https://www.wantedly.com/projects/203471
ログイン関連
17
18
サーバー AWSマネージメントコンソール
権限の管理
19
• LDAPを利用•人事データベースと同期
•権限管理用のポータルがある
• AWSアカウントごとに権限が存在•役割ごとの権限も設定可能
サーバーへのログイン
• LDAPを使った公開鍵認証、踏み台やVPNも提供
20
LDAPサーバー
各AWSアカウント
監査、共通基盤のAWSアカウント
Elastic Load
Balancing
VPC
peering
EC2
EC2
制限から複数のVPCを作成
21
LDAPサーバー
各AWSアカウント
監査、共通基盤のAWSアカウント
Elastic Load
Balancing
VPC
peering
EC2
EC2
• VPC 当たりのアクティブな VPC ピアリング接続（最大125）
•ルートテーブル当たりのルートの数（最大100）
×2
AWS PrivateLinkを検証中
マネージメントコンソールへのログイン
• LDAPと連携した SAMLベースのフェデレーション
•OpenAMからセキュリティチーム内製のものへ移行中
22
2FA
その他の取りくみ
23
すべてのアカウントで有効化
24
AWS
CloudTrail
Amazon
GuardDuty
監査用のアカウントにデータを集約
25
AWS
CloudTrail
Amazon
S3
ログ
各AWSアカウント
共通の保管用バケット
Amazon
GuardDuty
メンバーアカウント
Amazon
GuardDuty
マスターアカウント
各AWSアカウント
面倒な設定は自動化
•GuardDutyの設定が特に大変•アカウント、リージョンごとに招待、有効化、承認が必要
•その他の設定も含めてJenkins化
26
AWS Organizations
•元々、一括請求機能を使用
•最近、すべての機能を有効化• SCPも一部導入
•ブラックリスト方式
27
管理用 AWSアカウントの構成
Organizationsのマスターアカウント
•請求 / Organizations /リザーブドインスタンスの管理
28
監査、共通基盤のアカウント
• CloudTrailのログ集約、LDAPサーバーなど
ツリーの構成やポリシーは試行錯誤中
29
Organizationsのマスターアカウント
監査、共通基盤のアカウント
多くのプロジェクトのアカウント
一部のクリティカルなプロジェクトのOU
Organization検証用のプロジェクトのOU
Root
SCP（サービスコントロールポリシー）
嬉しいこと
•DenyしたアクションはIAM, ルートアカウントともに対象
• iam:Create* , iam:Put*, iam:Attach*の権限があっても制限可
注意点
• Resourceは*で固定
•アクションのワイルドカード指定は後ろだけ
•ボディの長さは5120 bytes（複数に分割して対応）
30
他にも様々な取り組み
• SAによるレビュー
•弊社のSREとAWS Well-
Architected Frameworkを推進
•日々の様々な相談
31
•ルートアカウントの管理
• MFAの管理
•脆弱性診断の申請のサポート
•エンタープライズサポート加入
• e-learning
•新卒研修
など
AWSとの取り組み 基本的な取り組み
アジェンダ
32
①
③ ④
②
統制する仕組み
新しい取り組み
組織について
悩んでいること
33
自由 責任
組織の文化
組織の文化
サイバーエージェントは2006年から本格的にエンジニア組織を強化しました。その間、100はゆうに超える新規サービスを立ち上げてきました。
その間「自由と自己責任」というものを掲げ、担当するエンジニアがその時に最もベストな技術を選定し挑戦をしてきました。（略）
エンジニアに裁量を与える代わりに説明責任を求めます。
34https://www.wantedly.com/companies/abema/post_articles/33695
AWS製品の選択の裁量はプロジェクトにある
35
チャレンジの結果、事例になることも
36
カオスになりやすい環境
37
自由と自己責任の文化 エンジニアの数も多い 新卒も多い
新規事業も多い 異動もそれなりに
責任共有モデルにより、AWSの顧客はクラウド”における”セキュリティの責任を負う
38Infrastructure servicesの責任共有モデルの図
守るところは守る
39
管理上守りたい部分
最小権限の原則を促す
フールプルーフを用意
AWS
CloudTrail
AWS
Config
Amazon
GuardDuty
IAM
厳格なポリシーに従う必要のあるデータやプロジェクト
事故が起こりやすい部分
IAM
IAMやOrganizationsで制限
（前半の説明部分など）
制限と自由のバランスは難しい
40
自由すぎると問題が起こりやすい
制限をしすぎると開発スピード低下
どのアクションが危ないか…は難しい
41
危ないアクション安全なアクション
許可 禁止
セキュリティチームと議論して基本ポリシーは決定
例s3:PutBucketPolicy
使い方次第
アジェンダ
42
①
③ ④
②
統制する仕組み
新しい取り組み
組織について
悩んでいること
43
「これ危ない設定じゃないでしょうか」
とヒアリングするための仕組み
なぜヒアリングなのか
44
•プロジェクトに裁量を与える
•問題がある場合には利用者に修正を依頼
•意図を確認しないと判断が難しいものが存在する
仕組みは大きく2つ
45
スケジュールベースイベントベース
イベントベース
46
（再掲）監査用のアカウントにデータを集約
47
AWS
CloudTrail
Amazon
S3
ログ
各AWSアカウント
共通の保管用バケット
Amazon
GuardDuty
メンバーアカウント
Amazon
GuardDuty
マスターアカウント
各AWSアカウント
システム構成（イベントベース）
48
AWS
CloudTrail
Amazon
S3
CloudTrailのログメディア事業部の各アカウント
共通の保管用バケット
イベントでSNS通知
Amazon
SNS
AWS
Lambda
Amazon
SNS
イベントのメッセージ
ログ取得イベントごとにメッセージ送信
（チェック項目ごと）
AWS
Lambda
Amazon
S3
ホワイトリストの取得
Amazon
CloudWatch
Events
イベント
Amazon
GuardDuty
メンバーアカウント
Amazon
GuardDuty
マスターアカウント
通知
イベントデータの収集 判定と通知
通知の例（S3 Bucket ACLの変更）
49
通知の例（Security Groupの変更）
50
通知の例（GuardDutyの検知）
51
スケジュールベース
52
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メッセージ
システム構成（スケジュールベース）スケジュール生成 アカウント一覧生成 チェックと通知とレポート生成
通知の例（IAMユーザーの棚卸し）
54
通知の例（SESのバウンス率、苦情率）
55
通知の例（LDAPユーザーの定期棚卸し）
56
通知の例（SSL/TLS証明書の期限）
57
診断レポート
58
• Trusted Advisorの結果
•独自チェックの結果
• CIS AWS Foundations Benchmark
• ベンチマークに沿ったチェック結果
• コマンドベースでチェック方法記載
• 通知のしきい値の参考にもしている
•セキュリティグループの一覧
なぜAWS Config Rulesではないの？
59
•アクティブなルール1つごとに2 USD/月•リージョンごと、アカウントごとに費用増
•なるべく監査側のアカウントに設定を作りたい
2016年にブログで公開、でも一度は失敗
•すべてのアラートを管理者だけで受け取った
•プロジェクトとの連絡手段が確立できていなかった
60
今回は、利用者と一緒に受け取る方式に
61
• AWSアカウント毎に通知先を用意
• LDAPの権限を元に招待
AWSアカウントごとのチャンネル
利用者&管理者
検知システム
アラート
起こった変化
62
自主的に対応してくれる人が現れた
アドバイスをくれる人が現れた
実際に棚卸しが進んだ早期検知が出来た
利用者の声
63
検知が自動化されることはもちろん、無駄な通知を減らしたいがために後回しになりがちな棚卸しをするきっかけを生んでくれて助かっています！
サービスリライアビリティグループマネージャー / エンジニア 須藤 涼介
今後について
•今回の方法がベストだとは思っていない
•情報収集と定期的な見直し•ポリシー•検査項目•道具（コスト、便利さ、柔軟性）
•別レイヤーのチェック•例: Amazon InspectorやVulsの利用普及
• 一部環境では導入済
64
まとめ
•増え続けるAWSアカウントの”責任”をどう果たすか
•制限と自由のバランスは常に悩んでいる
•ぜひ情報交換をさせてください
65
宣伝
•一緒に働いてくれる方を募集！
• https://www.cyberagent.co.jp/careers/
•CyberAgent Developers Blog
• https://developers.cyberagent.co.jp/blog/
•各サービスのエンジニアやクリエイターの技術をお届けします
66
素材利用、参考資料
•ヒューマンピクトグラム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
Recommended