2025/12/18 日本経済新聞社　CDIO室　秋葉政人 AWS運用を効率化する！ AWS Organizationsを軸にした一元管理の実践 NIKKEI TECH TALK #41 

ハッシュタグ #nikkei_tech_talk アジェンダ 2 ● 自己紹介 ● 日経のセキュリティ関連組織 ● セキュリティチーム紹介 ● 日経のAWS環境 ● 課題 ● 対応方針 ● AWS Organizations ● 対応内容 ● ポイント ● まとめ 

ハッシュタグ #nikkei_tech_talk 自己紹介 3 ● 名前：秋葉政人 ● 所属：日本経済新聞社　CDIO室（セキュリティチーム） ○ 2024年7月中途入社 ● 職種：セキュリティエンジニア ○ クラウドセキュリティ、セキュリティ活動全般 ● キャリア ○ 通信会社、監査法人、金融機関、メガベンチャーを経て、今に至る ○ セキュリティ畑を歩んできたが、エンジニア経験なし ■ NIKKEIでチャレンジ！ ● 趣味 ○ 旅行、スポーツ観戦 

ハッシュタグ #nikkei_tech_talk 日経のセキュリティ関連組織 4 * CDIO: Chief Digital Information Officer 役割 経営企画室 （NIKKEI-SIRT） コーポレート基盤ユ ニット CDIO室 （セキュリティチーム） 日経 CSIRT Corporate Security & Governance Product Security 経営企画室長 CDIO* 日経統合システム (NAS) NSOC Security Operation Center CSIRT(NIKKEI-SIRT) ● インシデント・レスポンス ● 脆弱性アセスメント ● 全社的なセキュリティ啓発 Corporate Security & Governance ● セキュリティドキュメント ・ポリシー、標準、ガイドライン ● ITセキュリティ機器、ネットワーク Product Security ● DevSecOps ● ウェブセキュリティ ● クラウドセキュリティ NSOC(Nikkei Security Operations Center) ● セキュリティモニタリング 

ハッシュタグ #nikkei_tech_talk セキュリティチーム紹介 ● 発足：2021年1月 ● ミッション： ○ 日経のデジタルプロダクトのセキュリティリスクをコントロールして事業成長に 貢献する ● 目標： ○ DevSecOpsによりデジタル事業のサービスで保有する情報を適切に守るこ と、開発者の体験・開発速度を損なわないことを同時に目指す 5 

ハッシュタグ #nikkei_tech_talk 日経のAWS環境 6 ● 日経および一部のグループ会社のAWSアカウント数は200弱 ○ 事業ユニットごとにインフラからアプリを構築 ● セキュリティチームがセキュリティテンプレートと呼ばれるモジュールを適用 ○ IaCツール（Terraform）を通じてAWSアカウントごとに最低限のセキュリティ 用推奨設定を手動で行なうもの ○ 監査ログの取得（CloudTrail）、不正な挙動の検知（GuardDuty）、リソース設 定の評価（Config）等 manual operations Terraform 

ハッシュタグ #nikkei_tech_talk 課題 7 ● AWSアカウントごとにセキュリティテンプレートの適用を繰り返し実施する必要が あり、運用コストが拡大傾向 ○ 事業・プロダクトのスケールに対応できない状況が将来的にも予想される ● 背景 ○ 日経は2015年頃からAWSへの移行、利用が拡大 ○ 当初はセキュリティテンプレートで個別にコントロールしていたが、AWSアカウント の増加で運用に限界が近づく ○ AWS Organizationsの機能の充実により、一元管理への切り替えがより効率的か つ効果的に実現できると判断 

ハッシュタグ #nikkei_tech_talk 対応方針 8 ● 実現したい環境イメージ ○ 新規AWSアカウントは作成した瞬間（OU配置時）にセキュリティ対策が自動的に適用 される ○ 複数のAWSアカウントに対するセキュリティ設定の適用、変更も簡単（一元的）に実施 できる ● AWSサービスを用いた実装方針 ○ AWS Organizationsの機能を活用し、効率的な管理を実現 ● 検討メンバー：5名 ● 期間：1年程度 automatic operations AWS Organizations manual operations Terraform 

ハッシュタグ #nikkei_tech_talk AWS Organizations 9 サービス概要 ● 複数のAWSアカウントを一元的に管理・運用できるサービス ● 企業や組織が、事業部門やプロジェクトごとにAWSアカウントを分けて利用する 際、管理や統制を効率化するために利用される 主な機能 ● 組織単位（OU: Organizational Unit） ○ AWSアカウントをグループ化し、階層構造で管理 ● SCP（サービスコントロールポリシー）およびRCP（リソースコントロールポリシー） ○ OUやAWSアカウントごとに、利用可能なAWSサービスや操作を制限 ● セキュリティサービスとの統合 ● 一元的な請求管理 

ハッシュタグ #nikkei_tech_talk 対応内容 10 ● OU設計 ○ AWS社のリソースを活用（Link）しつつ、環境に合わせて必要なOUを作成 ○ 環境別およびセキュリティレベル別に階層化 ■ OUは一度設計すると後から大きく変更しづらいため、不変的な軸をベース に階層化する ■ OUごとのリスクや用途に応じ、セキュリティ対策の強度等を調整する 

ハッシュタグ #nikkei_tech_talk 対応内容 11 ● SCPおよびRCPの適用検討　（以下、一部抜粋） ○ 暗号化なしのボリューム/スナップショット禁止、VPN関連操作禁止 ○ パブリックアクセスブロック、ACL変更禁止 ○ パスワードポリシー変更禁止、MFA未認証時の操作禁止 ○ Organization離脱禁止 

ハッシュタグ #nikkei_tech_talk 対応内容 12 ● AWS Organizationsと統合するサービス（以下、一部抜粋）と設定内容の検討 ○ AWS CloudTrail ○ Amazon GuardDuty ○ AWS SecurityHub CSPM ○ AWS CloudFormation ■ AWS Config等、Organizations統合しても自動的に有効にならない AWSサービスもあるため、AWS CloudFormationを活用し、メンバーア カウント側で有効化 

ハッシュタグ #nikkei_tech_talk ポイント（既存設定への影響） 13 AWS CloudTrail ● 前提として、Organizations統合により、組織証跡（Link）を全てのAWSアカウン トに新規作成しました ● 以下が主な考慮ポイント ○ セキュリティテンプレートで作成した既存証跡との機能重複への対応 ○ 既存証跡に独自に変更を加えているメンバーアカウントへの対応 ○ 監視設定の変更 

ハッシュタグ #nikkei_tech_talk ポイント（既存設定への影響） 14 AWS CloudTrail ● セキュリティテンプレートで作成した既存証跡との機能重複への対応 ○ 既存証跡は停止し、組織証跡に切り替えた方がコストメリット○ ■ 切り替え時の新旧証跡の並行稼働期間は1日程度確保（Link） 

ハッシュタグ #nikkei_tech_talk ポイント（既存設定への影響） 15 AWS CloudTrail ● 既存証跡に独自に変更を加えているメンバーアカウントへの対応 ○ 既存証跡に変更を加えているメンバーアカウントの情報を取得し、個別対応を 実施（組織証跡に切り替えて問題ないか確認） ■ ログ取得イベントやログ配信先（CloudWatch Logs）を変更しているか ログ取得イベント ・管理イベント ・データイベント ・Insights イベント ・ネットワークアクティビティイベント Image 

ハッシュタグ #nikkei_tech_talk ポイント（既存設定への影響） 16 AWS CloudTrail ● 監視設定の変更 ○ 組織証跡の保存先(S3)が既存証跡から変わるため、監視設定を変更 ■ s3://<旧バケット名>/AWSLogs/<アカウントID>/ ■ s3://<新バケット名>/AWSLogs/<組織ID>/<アカウントID>/ Export Monitoring 証跡を保存するパスが変わる AWS CloudTrail 

ハッシュタグ #nikkei_tech_talk ポイント（既存設定への影響） 17 AWS SecurityHub CSPM ● すでに利用しているメンバーアカウントへの対応 ○ セキュリティチームの運用ポリシー（設定）に寄せられるか個別に確認 SCPおよびRCP ● 制御して問題ないアクションか確認 ○ CloudTrailで過去数年分のアクションを調査 ■ 制御対象のアクションを実行した形跡のあるメンバーアカウントの管理者へ ヒアリングを実施 ● 単発（一度きり）の操作か、今後も継続的に発生する操作か 

ハッシュタグ #nikkei_tech_talk ポイント（費用影響） 調整要因 18 AWS Config ● 一部のリージョンで有効化していたものを全てのリージョンで有効化 ● セキュリティチェックも実施していたが、Security Hub CSPMに移行 ● AWS Configの取得頻度を調整することでリージョンを増やしてもコスト影響を軽 微なレベルに下げる（最適化する） ● Security Hub CSPMのセキュリティチェックも必要な項目に限定 ○ 重要度レベルが高い項目に限定 増加要因 

ハッシュタグ #nikkei_tech_talk ポイント（設定適用における時短テクニック） 19 AWS CloudFormation ● AWS Configを全てのメンバーアカウント、全てのリージョンで有効化する Stacksetsについて、相応の時間が掛かることが想定された ○ AWS CloudFormationの以下のパラメータを調整し、効率化 ■ 同時アカウントの最大数 ■ 障害耐性 ■ リージョンの同時実行 ○ 2日間に分け、 全AWSアカウントに 適用作業を実施 Image 

ハッシュタグ #nikkei_tech_talk ポイント（検証環境やコーディングAIの充実） 20 ● 日経の場合、検証用のOrganizations環境が存在するため、適宜検証を行いなが ら進めることが可能であった ● 各種設定はTerraformにて実装しているが、コーディングAIエージェントの利用に より、開発生産性が向上 

ハッシュタグ #nikkei_tech_talk ポイント（Architecture Decision Recordの活用） 21 ● 重要な設計判断や運用方針はADRで記録・共有し、振り返っても当時の設計意図 を把握できる状態にした 

ハッシュタグ #nikkei_tech_talk ポイント（AWS Control Towerの利用判断） 22 ● 日経環境ではログ集約基盤等、すでに実装されているリソースや運用が存在するた め、AWS Control Towerの利用は見送った 

ハッシュタグ #nikkei_tech_talk まとめ 23 ● 実現できたこと ○ 新規AWSアカウントは作成した瞬間（OU配置時）にセキュリティ対策が自動的 に適用される ○ 複数のAWSアカウントに対するセキュリティ設定の適用、変更も簡単（一元的） に実施できる ● 大変だったこと ○ メンバーアカウントへの影響調査 ■ 地道な調査やヒアリングの実施、個別対応の案内等 ● 今後について ○ AWS SecurityHub CSPMのFindingsへの対応 ○ Organizations環境を用いたさらなるセキュリティ施策の検討