Contenu connexe
Similaire à DeNA の AWS アカウント管理とセキュリティ監査自動化 (20)
DeNA の AWS アカウント管理とセキュリティ監査自動化
- 1. DeNA の AWS アカウント管理と
セキュリティ監査自動化
髙橋 祐真
システム本部 IT 基盤部第一グループ
株式会社ディー・エヌ・エー
- 2. 髙橋 祐真 (Yuma Takahashi)
• 所属
• システム本部 IT 基盤部第一グループ グループリーダー
• 経歴
• 2013 年 4 月 大学院修士課程修了後 DeNA 新卒入社
• 2013 年 ~ 国内向けゲームプラットフォームの運用を担当
• 2014 年 ~ エンタメ系サービスの運用を担当
• 2015 年 ~ ヘルスケア系サービスの運用を担当
• 2018 年 ~ グループリーダー (現職)
• エンタメ、ヘルスケア、ライブ配信、スポーツ、AI サービスのインフラを担当
• クラウド移行におけるセキュリティ環境整備のチームのリーダーも兼任
2
- 5. DeNA のインフラの概況
• オンプレからクラウドへ
• メインのシステム基盤はオンプレ
• 2013 年 ~ クラウド利用開始、以降適材適所でクラウドを利用
• 2015 年 ~ クラウド利用急増
• 2018 年 6 月にクラウドへの全面移行を決定
• 移行プロジェクトスケジュール
• 2018 年 ~ 移行の準備期間
• クラウドに最適化したシステム基盤の設計・実装
• クラウド利用時の本格的なセキュリティ環境整備
• 2019 年 ~ 本格移行期間
• 2020 年 ~ 完全移行、仕上げ期間
5
- 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
- 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
- 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
- 31. まとめ
• 多数の AWS アカウントに対して効率的な管理ができている
• セキュリティ標準を策定したため利用者による差異が減った
• セキュリティ監査自動化によって大幅な工数削減につながった
31
- 32. 今後の展望
• AWS Organizations の OU や SCP の有効活用
• OU と SCP を組み合わせることで設定が単純になる
• SCP は root ユーザーの行動も制御できる
• プログラマティックアクセス用の IAM ユーザーの効率的な管理
• IAM ロールが使用できない場面での IAM ユーザーの管理
• AWS セキュリティガイドの補強
• 未記載の AWS サービスの追加
• AWS セキュリティ監査自動化の対象拡大
• 上記追加項目の実装
32