DeNA の AWS アカウント管理とセキュリティ監査自動化

DeNA

More Related Content

1.DeNA の AWS アカウント管理とセキュリティ監査自動化髙橋 祐真システム本部 IT 基盤部第一グループ株式会社ディー・エヌ・エー
2.髙橋 祐真 (Yuma Takahashi)• 所属• システム本部 IT 基盤部第一グループ グループリーダー• 経歴• 2013 年 4 月 大学院修士課程修了後 DeNA 新卒入社• 2013 年 ~ 国内向けゲームプラットフォームの運用を担当• 2014 年 ~ エンタメ系サービスの運用を担当• 2015 年 ~ ヘルスケア系サービスの運用を担当• 2018 年 ~ グループリーダー (現職)• エンタメ、ヘルスケア、ライブ配信、スポーツ、AI サービスのインフラを担当• クラウド移行におけるセキュリティ環境整備のチームのリーダーも兼任2
3.目次3背景DeNA のインフラの概況とセキュリティ環境整備の必要性課題を解決する施策AWS アカウント管理とセキュリティ監査自動化まとめまとめと今後の展望132
4.背景DeNA のインフラの概況とセキュリティ環境整備の必要性4
5.DeNA のインフラの概況• オンプレからクラウドへ• メインのシステム基盤はオンプレ• 2013 年 ~ クラウド利用開始、以降適材適所でクラウドを利用• 2015 年 ~ クラウド利用急増• 2018 年 6 月にクラウドへの全面移行を決定• 移行プロジェクトスケジュール• 2018 年 ~ 移行の準備期間• クラウドに最適化したシステム基盤の設計・実装• クラウド利用時の本格的なセキュリティ環境整備• 2019 年 ~ 本格移行期間• 2020 年 ~ 完全移行、仕上げ期間5
6.DeNA のインフラの組織構成6AIゲーム エンターテインメント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本番アカウントBAWS Organizations を利用したマルチアカウント管理13AWS 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 accountAmazon EC2AWS IAM同期1. IdP にログイン2. SAML レスポンス3. lAM ロール選択AWS ManagementConsole4. AWS STS token5. コンソールログインロール- step-service-account1-admin- step-service-account1-read... 通知社内ディレクトリの情報を元に定期メンテナンスデータ取得IdPSlack社内ディレクトリ
21.ID フェデレーションによる AWS コンソールログイン21ユーザーstep accountAmazon EC2AWS IAMAWS ManagementConsole5. コンソールログイン ロール- step-service-account1-admin- step-service-account1-read...通知社内ディレクトリの情報を元に定期メンテナンスデータ取得service account1AWS IAMAWS ManagementConsoleロール- AdministratorAccess- ReadonlyAccess...6. Switch RoleSlack社内ディレクトリ
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 セキュリティ監査自動化システム25security accountユーザーSSO権限制御Amazon EC2ApplicationLoad BalancerAmazon S3Amazon SES監査実施担当者 Amazon CloudWatchservice 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.jp33
34.34ご静聴ありがとうございました