AWSの利用で以下の課題はありませんか？ ・多数のAWSアカウントがあり管理が難しい ・セキュリティ標準がなく設定者により差異がでる ・セキュリティ監査工数が膨大になる これらの対策として ・多数のAWSアカウント管理を効率化した方法 ・AWS利用のセキュリティ標準策定や監査の自動化 などをご紹介した資料になります。

1. DeNA の AWS アカウント管理と
セキュリティ監査自動化
髙橋 祐真
システム本部 IT 基盤部第一グループ
株式会社ディー・エヌ・エー

2. 髙橋 祐真 (Yuma Takahashi)
• 所属
• システム本部 IT 基盤部第一グループ グループリーダー
• 経歴
• 2013 年 4 月 大学院修士課程修了後 DeNA 新卒入社
• 2013 年 ~ 国内向けゲームプラットフォームの運用を担当
• 2014 年 ~ エンタメ系サービスの運用を担当
• 2015 年 ~ ヘルスケア系サービスの運用を担当
• 2018 年 ~ グループリーダー (現職)
• エンタメ、ヘルスケア、ライブ配信、スポーツ、AI サービスのインフラを担当
• クラウド移行におけるセキュリティ環境整備のチームのリーダーも兼任
2

3. 目次
3
背景
DeNA のインフラの概況とセキュリティ環境整備の必要性
課題を解決する施策
AWS アカウント管理とセキュリティ監査自動化
まとめ
まとめと今後の展望
1
3
2

4. 背景
DeNA のインフラの概況とセキュリティ環境整備の必要性
4

5. DeNA のインフラの概況
• オンプレからクラウドへ
• メインのシステム基盤はオンプレ
• 2013 年 ~ クラウド利用開始、以降適材適所でクラウドを利用
• 2015 年 ~ クラウド利用急増
• 2018 年 6 月にクラウドへの全面移行を決定
• 移行プロジェクトスケジュール
• 2018 年 ~ 移行の準備期間
• クラウドに最適化したシステム基盤の設計・実装
• クラウド利用時の本格的なセキュリティ環境整備
• 2019 年 ~ 本格移行期間
• 2020 年 ~ 完全移行、仕上げ期間
5

6. DeNA のインフラの組織構成
6
AI
ゲーム エンター
テインメント
eコマース ソーシャルLIVE
スポーツオート
モーティブ
ヘルスケア
インフラ部門 & 監査実施部門
インフラ部門 ... 上記サービスのインフラ運用だけでなく各種契約まわりも管理

7. AWS 利用のセキュリティ環境整備の必要性
• DeNA の抱える課題
• 多数の AWS アカウントを多数のラインで様々な用途で利用しているため管理が難しい
• 利用者によってセキュリティレベルに差異がでてしまう
• セキュリティ監査の工数が膨大にかかる
7

8. 課題を解決する施策
AWS アカウント管理とセキュリティ監査自動化
8

9. 課題を解決する施策
• 課題と施策
• 多数のAWSアカウントを多数のラインで様々な用途で利用しているため管理が難しい
• AWS アカウント管理
• root ユーザー管理
• IAM ユーザー管理
• 利用者によってセキュリティレベルに差異がでてしまう
• AWS セキュリティ標準の策定
• セキュリティ監査の工数が膨大にかかる
• AWS セキュリティ監査自動化
9

10. AWS アカウント管理
• 課題
• 多数のAWSアカウントを多数のラインで様々な用途で利用しているため管理が難しい
• AWS アカウント数は約 250 個
• 月に 10 個のペースで増加
• 利用部門数は約 60
• 対策
• AWS アカウントの一元管理と開発自由度の両立
• インフラ部門が全社横断の管理部門として一括で集中管理している
• 各サービス担当から 1 人ずつ集めたパブリッククラウド管理チーム
• 基本的に全ての設定や操作は利用者サイドでできるようにしている
• あくまで管理は「薄く」、最低限守るべきラインを担保するのみに留めている
• AWS Organizations を利用したマルチアカウント管理
• AWS アカウントの情報を管理するシステムを作成
• AWSアカウントの作成粒度や命名規則のガイドラインを作成
• AWS アカウント作成時の初期設定や設定変更方法の整備
10

11. AWS Organizations を利用したマルチアカウント管理
• アカウントの作成を AWS Organizations から実施
• aws organizations create-account コマンドで作成
• 連絡先情報やクレジットカード情報の入力が不要
• AWS Organizations のすべての機能を有効にしている
• 一括請求 (Consolidated Billing)
• アカウントの請求と支払いを統合
• リザーブドインスタンスの共有
• 組織内のすべてのアカウントは、他のアカウントで購入したリザーブドインスタン
スを共有することができ「余さずに」使える
• サービスコントロールポリシー (SCP) の利用
• 間違った使い方がコストに大きく響いてしまう機能について明示的 deny を適用
• そういったものはインフラ部門で集中管理対象としている
11

12. AWS Organizations を利用したマルチアカウント管理
• マスターアカウント
• すべてのアカウントに対する AdministratorAccess 権限
• 請求と支払い管理
• ロギングアカウント
• 全 AWS アカウントの CloudTrail のログを保管
• 監査アカウント
• セキュリティ監査実施元
• 各種共有サービスアカウント
• 共有ネットワーク用アカウント
• ハブアンドスポーク型による管理の簡略化と運用コスト削減
• CDN 用アカウント
• DNS 用アカウント
• 踏み台用アカウント
12

13. 本番
アカウントC
本番
アカウントB
AWS Organizations を利用したマルチアカウント管理
13
AWS Organizations
ロギング
アカウント
マスター
アカウント
監査
アカウント
踏み台用
アカウント
本番
アカウントA
本番
アカウントC
本番
アカウントB
ステージング
アカウントA
本番
アカウントC
本番
アカウントB
開発
アカウントA
監査実施担当者
開発者
請求管理者

14. AWS アカウントの情報を管理するシステムを作成
• システムアセット管理システム
• 全てのパブリッククラウドのアカウントを管理
• 全体でアカウント数は数百以上
• AWS アカウントの様々な情報を管理
• 案件名、利用部門、担当グループ、連絡先、など
• 社内におけるパブリッククラウドアカウントのマスタとして管理会計や監査時などにも
利用
• API 連携機能
• 検索機能
14

15. システムアセット管理システム
15

16. AWSアカウントの作成粒度や命名規則のガイドラインを作成
• アカウントの命名規則
• プロジェクト名や環境名の組み合わせ方を決めておく
• 例: hoge-dev、fuga-prod
• アカウントの粒度
• サービスやプロジェクトごとにアカウントを作成
• 基本的には開発環境用と本番環境用を分ける
• セキュリティ要件等でさらに分けたい場合は複数作成可能
• アカウントの連携方法
• VPC Peering は原則利用しない
• すべてのアカウントをTransit Gateway を利用して制御
• インターネットを利用した API 経由での連携は許可
16

17. AWS アカウント作成時の初期設定や設定変更方法の整備
• アカウントの作成と解約はすべてインフラ部門が実施
• 事業部から申請をもらってから作成
• コマンドひとつでアカウント作成と初期設定
• 初期設定
• MFA 登録
• IAM パスワードポリシーの適用
• セキュリティログ保管用アカウントに S3 バケットの作成
• CloudTrail 設定
• 各種必要なロールの設定
• アカウント設定変更用ロール
• セキュリティ監査用ロール、など
• 上述の設定が正しい状態か監視している
• 全アカウントに対する設定変更スクリプトも作成
17

18. root ユーザー管理
• 課題
• 異動・退職者に対するケアができていない
• 各ラインに root 権限を渡して長年経過すると行方不明になることもしばしば
• 対策
• root でログインは基本的に禁止とし、ログインされた場合に気付けるようにする
• 一度 root 権限を得た場合、その権限を確実に削除するにはパスワードまたは MFA
を変更する必要がある
• これらを機械的に変更する方法があれば良いが、今の所 API の提供がなく変更作
業は手動で行わざるを得ない
• root はインフラ部門で一括管理する
• パスワードはクラウドストレージで権限を設定し管理
• MFA token は権限を絞ったサーバ上で生成
18

19. IAM ユーザー管理
• 課題
• IAM ユーザーが増えすぎて異動退職に伴う棚卸を効率的にやるのが難しい
• IAM ユーザーの分類
• プログラマティックアクセス用の IAM ユーザー
• AWS マネジメントコンソール用の IAM ユーザー
• 今回の対象はこちら
• 対策
• ID フェデレーションによる AWS コンソールログイン
• 社内ディレクトリで管理されるフェデレーティッドユーザーを利用した AWS マネ
ジメントコンソールログイン
• SAML 2.0 を使用した ID フェデレーション
• 退職時は社内ディレクトリから自動で削除されるため自動で棚卸しがされる
19

20. ID フェデレーションによる AWS コンソールログイン
20
ユーザー
step account
Amazon EC2
AWS IAM
同期1. IdP にログイン
2. SAML レスポンス
3. lAM ロール選択
AWS Management
Console
4. AWS STS token
5. コンソールログイン
ロール
- step-service-account1-admin
- step-service-account1-read
... 通知
社内ディレクトリ
の情報を元に
定期メンテナンス
データ取得
IdP
Slack
社内ディレクトリ

21. ID フェデレーションによる AWS コンソールログイン
21
ユーザー
step account
Amazon EC2
AWS IAMAWS Management
Console
5. コンソール
ログイン ロール
- step-service-account1-admin
- step-service-account1-read
...
通知
社内ディレクトリ
の情報を元に定期
メンテナンス
データ取得
service account1
AWS IAMAWS Management
Console
ロール
- AdministratorAccess
- ReadonlyAccess
...
6. Switch Role
Slack
社内ディレクトリ

22. AWS セキュリティ標準の策定
• 課題
• 利用者によってセキュリティレベルに差異がでてしまう
• 設定の指針が無く利用方法の相談を都度する必要があり、工数や業務スピードに問
題が生じていた
• 対策
• 社内向けの AWS セキュリティガイドを作成
• DeNA には Group Information Security Policy (GISP) というポリシがある
• AWS を利用する上で GISP を守るために必要な点をリスト化したもの
• 外部協力会社への提供も可能
• AWS サービスごとに項目を分類し、要件、推奨レベルがある
• サービス
• IAM、VPC、EC2、S3、KMS、RDS、etc.
• 推奨レベル
• 必須、条件付き必須、推奨
22

23. AWS セキュリティガイド項目例
• [root] ルートユーザーに対して MFA を有効化すること
• [root] ルートユーザーのアクセスキーは利用せず、発行した場合は削除すること
• [IAM] 利用が完了し使われてないアクセスキーは無効化・削除すること
• [IAM] パスワードポリシーで GISP に従ったポリシーを設定すること
• [EC2] ELB のアクセスログを有効化すること
• [RDS] インターネットからのアクセスが不要な場合はパブリックアクセシビリティを無効
にすること
23

24. AWS セキュリティ監査自動化
• 課題
• アカウント数や監査項目数が多いためセキュリティ監査の工数が膨大にかかる
• 対策
• AWS セキュリティ監査自動化システム
• システムは独自実装
• AWS マネージドサービスではカバーできない範囲を実装
• 低コストで運用を実現
• AWS CLI 等で情報を取得して判定
• 通知宛先はアカウント管理者
• アカウント、ルール、リソースごとに指定期間の通知停止設定が可能
• 自動化が難しい項目は監査実施担当者がコンソールから直接設定を確認
• 長期間通知が無視されているものや通知停止理由も定期的に確認
24

25. AWS セキュリティ監査自動化システム
25
security account
ユーザー
SSO
権限制御
Amazon EC2
Application
Load Balancer
Amazon S3
Amazon SES
監査実施担当者 Amazon CloudWatch
service account1
ユーザー
service account2
ユーザー
service account3
ユーザー
...
自動監査
通知
長期間通知が無視されているものや通知停止理由を確認
自動監査できないものは手動確認
異常を通知
IdP

26. AWS セキュリティ監査自動化システム
26

27. AWS セキュリティ監査自動化システム
27

28. AWS セキュリティ監査自動化システム
28

29. AWS セキュリティ監査自動化システムの実装例
• [root] ルートユーザーに対して MFA を有効化すること
• 認証情報レポートでルートユーザに対して mfa_active が true であるか確認
• [IAM] 利用が完了し使われてないアクセスキーは無効化・削除すること
• list-access-keys で Status が Active なものの中で、 get-access-key-last-used か
ら得られる LastUsedDate が特定の期間内であるか確認
• [EC2] ELB のアクセスログを有効化すること
• describe-load-balancer-attributes で AccessLog の Enabled が true であるか確認
• [RDS] インターネットからのアクセスが不要な場合はパブリックアクセシビリティを無効
にすること
• describe-db-instances で PubliclyAccessible が false であるか確認
29

30. まとめ
まとめと今後の展望
30

31. まとめ
• 多数の AWS アカウントに対して効率的な管理ができている
• セキュリティ標準を策定したため利用者による差異が減った
• セキュリティ監査自動化によって大幅な工数削減につながった
31

32. 今後の展望
• AWS Organizations の OU や SCP の有効活用
• OU と SCP を組み合わせることで設定が単純になる
• SCP は root ユーザーの行動も制御できる
• プログラマティックアクセス用の IAM ユーザーの効率的な管理
• IAM ロールが使用できない場面での IAM ユーザーの管理
• AWS セキュリティガイドの補強
• 未記載の AWS サービスの追加
• AWS セキュリティ監査自動化の対象拡大
• 上記追加項目の実装
32

33. 最後に
• 今後インフラ部門では Twitter やブログで継続的にノウハウを発信していきます
• Twitter
• @DeNAxTech
• ブログ
• https://engineer.dena.jp
33

34. 34
ご静聴ありがとうございました