AWSマルチアカウント環境における脆弱性診断の自動化 ―Organizationsを使わない大規模組織での安全な実装―

はじめに

エンタープライズ企業において、AWS環境が拡大する中、多くの組織では部門ごと、プロジェクトごと、環境ごと（本番・ステージング・開発）に複数のAWSアカウントを保有しています。各チームや部門が独自のAWSアカウントを持つことで、セキュリティ境界の確立、コスト管理の最適化、障害影響範囲の局所化を実現しています。

しかし、このようなマルチアカウント構成において、全社的なAWS Organizationsの管理権限は本社全体のIT部門やガバナンスチームが保持しており、個別のチームではOrganizationsを活用できないケースが一般的です。それでも、チーム内で保有する複数のAWSアカウントに対して統一的なセキュリティ管理を実現する必要があります。

本番環境の脆弱性診断における問題点

マルチアカウント環境において手動で脆弱性診断を実施する場合、数十のアカウントに対して月次で手動診断を行う工数が膨大になる他、アカウント間で診断実施時期にずれが生じてセキュリティリスクの全体把握が遅延します。また、診断処理そのものが本番環境の性能低下やサービス停止を引き起こすリスクがあり、このリスクはアカウント数に比例して増大します。手作業による診断は特定担当者への属人化も招きやすく、診断品質にばらつきが生じがちです。こうした問題を解消するために、本番環境に影響を与えない自動化されたアプローチが求められます。

本記事で提案する解決策

本記事では、AWS Organizationsを使用せずにマルチアカウント環境を運用しているチームが、本番の稼働環境に一切影響を与えずに脆弱性診断を自動化し、中央集約管理する考え方とアーキテクチャを解説します。

対象とするコンピューティングリソース：

EC2インスタンス
ECRコンテナイメージ
Lambda関数

脆弱性診断の対象リソース

本記事では、AWSマルチアカウント環境で広く利用される以下の4つのコンピューティングリソースを診断対象とします。

リソースタイプ	主な脆弱性リスク	診断ポイント	マルチアカウント特有の課題
EC2インスタンス	OS・ミドルウェアの脆弱性設定不備	パッケージバージョンセキュリティパッチ適用状況ネットワーク設定	アカウント数×インスタンス数で診断対象が膨大
ECRコンテナイメージ	ベースイメージの脆弱性依存パッケージの脆弱性	イメージレイヤーの脆弱性ライブラリ・パッケージバージョン	イメージが複数アカウントの ECRに分散保存
Lambda関数	ランタイムの脆弱性依存ライブラリの脆弱性 IAM権限の過剰付与	依存パッケージのバージョンランタイムサポート状況 IAMロール設定	大量の関数が複数アカウントに分散し全体把握が困難

これらの診断を、チーム全体で統一的かつ自動的に実施し、中央で集約管理する仕組みを構築します。

構成概要

マルチアカウント環境のアーキテクチャ全体像

本記事では、AWS Organizationsを使用しないマルチアカウント環境での脆弱性診断アーキテクチャを提案します。Organizations配下にない独立したアカウント群を、IAMクロスアカウントロールとSecurity Hubのクロスリージョン・クロスアカウント集約機能を活用して統合的に管理します。

アカウント構成の設計思想

Security/Scanning Account（セキュリティ集約アカウント）

チーム内で専用に用意するセキュリティ集約アカウントです。大量に存在するアカウントを統合的に管理するために1つのアカウントに情報を集約することを目的としています。

Security Hubの手動集約設定: Organizations APIを使わず、各メンバーアカウントをSecurity Hubに手動で関連付け（Invitation方式）
Amazon Inspector: Security Account自身のリソースをスキャンし、メンバーアカウントのInspectorからSecurity Hub経由で結果を受信
オーケストレーション機能（任意）: Step FunctionsやLambdaでクロスアカウントロールを使用した診断処理の並列実行も可能
スキャン結果の一元管理: S3バケットにレポートを集約保存し、SNSで脆弱性アラートを通知

Member Accounts（メンバーアカウント）

チーム内の各プロジェクト・環境・部門が保有する独立したAWSアカウントで以下のような役割・特徴を持つことを想定しています。

本番ワークロードの稼働: EC2、ECS (Fargate)、Lambda、ECR等のリソースが稼働
Inspector個別有効化: 各アカウントで個別にInspectorを有効化し、スキャン結果をSecurity Hubに送信
IAMクロスアカウントロール: Security AccountからのAssumeRoleを許可し、必要最小限の読み取り権限を提供
本番環境への影響ゼロ: Security Accountは読み取り専用アクセスのみで、メンバーアカウントのリソースを変更しない

Organizationsを使わない理由と対処法

なぜOrganizationsを使わないのか？

多くの大企業では、AWS Organizationsは情報システム部門やIT統括部門が全社レベルで管理しており、個別のチームや事業部門が自由にOrganizationsの構成を変更したり、デリゲート管理者を設定したりする権限を持っていません。筆者のチームも同様に、社内のOrganizationsに対する管理権限を持っておらず、チーム内で保有する複数のAWSアカウントを独自に管理しています。そのため、チームレベルで複数のAWSアカウントを管理する場合、Organizationsに依存しない独立したマルチアカウント管理手法が必要になります。

Organizations機能の代替手段

Organizations機能	Organizations非依存の代替手段
デリゲート管理者（Inspector）	各メンバーアカウントで個別にInspectorを有効化し、Security HubにFindingsを送信
Security Hubの自動集約	Security Hubの「Invitation方式」で手動で各アカウントを関連付け
CloudFormation StackSets	Terraformや独自スクリプトで各アカウントにIAMロールを個別デプロイ
組織ポリシー（SCP）	各アカウントのIAMポリシーで個別に権限制御
組織全体のAPI一括操作	クロスアカウントIAMロールを使用した個別アカウントへのAPI呼び出し

利用するAWSサービスと役割

AWSサービス	配置アカウント	役割
Amazon Inspector	全アカウント	EC2、ECS (Fargate)、Lambda、ECRコンテナの脆弱性スキャン CVEデータベースとの照合とリスク評価
AWS Security Hub	Security/Scanning （手動集約）	全メンバーアカウントの検出結果をInvitation方式で集約統合ダッシュボードでチーム全体の脆弱性を可視化
Amazon ECR	各Member	コンテナイメージの保存とEnhanced Scanningによる脆弱性検出スキャン結果のSecurity Hub自動送信
AWS Step Functions	Security/Scanning （任意）	クロスアカウントロールを使用した並列診断ワークフロー制御エラーハンドリングとリトライ制御
AWS Lambda	Security/Scanning （任意）	クロスアカウントアクセスによるリソース情報取得スキャン結果の集約・通知処理
Amazon S3	Security/Scanning	スキャンレポートの集約保存と履歴データの長期保管
Amazon SNS	Security/Scanning	Critical/High脆弱性の即時アラート通知
Amazon EventBridge	Security/Scanning （任意）	定期的なスキャン実行スケジューリング
IAM Cross-Account Roles	全Member （任意）	Security Accountからの最小権限読み取りアクセスを許可

このアーキテクチャにより、Organizationsに依存せず、チームが管理する複数のメンバーアカウントに対して統一的な脆弱性診断を自動実行し、結果をSecurity Accountで一元管理できます。

本番環境への影響を回避する設計思想

マルチアカウント環境において脆弱性診断を自動化する上で、本番環境への影響を徹底的に排除するための設計方針を採用します。

1. アカウント分離によるリソース隔離

診断処理は専用のSecurity/Scanning Accountで実行され、メンバーアカウントの本番リソースとは完全に分離されています。各メンバーアカウントからは、AMI、コンテナイメージ、Lambda関数のメタデータのみをSecurity Accountと共有し、本番リソース自体には一切アクセスしません。

2. 読み取り専用アクセスの原則

Security Accountからメンバーアカウントへのクロスアカウントアクセス（実装する場合）は、必要最小限の読み取り権限のみを付与します。EC2インスタンスの停止・起動、Lambda関数の更新、ECRイメージの削除など、本番リソースを変更する権限は一切与えません。

3. Inspectorのマネージドスキャン活用

Amazon Inspector v2は、実行中のワークロード（EC2、ECS、Lambda）に対して最小限の影響（CPU使用率1%未満）で動作するよう最適化されています。スキャンはAWSマネージドサービスとして提供され、ユーザーが追加のインフラを構築・管理する必要はありません。

4. スケジューリングによる負荷分散

大量のアカウントを一度にスキャンすると、API制限に達する可能性があるため、以下の戦略でスキャンを分散します：

非ピーク時間帯（深夜・休日）の実行
アカウントを複数のグループに分け、日を分けてスキャン
Step Functionsの並列実行制御による適切なスロットリング（実装する場合）

5. ECRスキャンのPush時自動実行

ECR Enhanced Scanningは、イメージがPushされた際に自動的にスキャンを実行し、Inspector経由でSecurity Hubに結果を送信します。追加の診断プロセスを実行する必要はなく、既存のCI/CDパイプラインへの影響はゼロです。

6. Security Hubへの統合集約

各メンバーアカウントのInspectorは、検出した脆弱性をSecurity Hub標準形式（AWS Security Finding Format: ASFF）でSecurity Accountに送信します。これにより、チーム全体の脆弱性を単一のダッシュボードで可視化し、統一的なガバナンスを実現できます。

Inspector のスキャンモード選択：エージェント vs エージェントレス

Amazon Inspector v2では、EC2インスタンスのスキャンにエージェントモードとエージェントレスモードの2つのアプローチが利用可能です。マルチアカウント環境では、運用負荷とセキュリティガバナンスのバランスを考慮してモードを選択する必要があります。

エージェントモード（Agent-based Scanning）

EC2インスタンスにSSM Agent + Inspector Agentをインストールし、継続的にスキャンを実行する方式です。インスタンス内部から直接パッケージ情報を収集するため、リアルタイムでの継続的スキャンが可能であり、ネットワーク到達性が不要（Systems Manager経由で通信）という利点があります。

項目	内容
必要な設定	SSM Agentのインストール（Amazon Linux 2、Ubuntu等は標準搭載） Inspector Agentの自動インストール（Inspector有効化時に自動デプロイ） SSM用のIAMロール（`AmazonSSMManagedInstanceCore`）をEC2にアタッチ
メリット	プライベートサブネットのインスタンスでもスキャン可能停止せずにリアルタイムスキャンより正確な脆弱性検出
デメリット	既存のEC2インスタンスにSSM Agentのセットアップが必要既に数百台のインスタンスが稼働している環境では初期導入コストが高い

エージェントレスモード（Agentless Scanning）

EC2インスタンスのEBSスナップショットを作成し、Inspector管理下の専用環境でスキャンを実行する方式です。エージェントのインストールが一切不要で、Inspectorが自動的にEBSスナップショットを作成してスキャンを行います。本番インスタンスには一切影響を与えず、新しいインスタンスが起動すると自動的にスキャン対象に追加されます。

項目	内容
必要な設定	Inspectorを有効化するのみ（エージェントのインストール不要） EBSスナップショット作成権限をInspectorに付与（自動設定）
メリット	既存インスタンスの変更が一切不要数百台のインスタンスがあっても容易に導入が可能運用負荷が低い
デメリット	スキャン実行に若干の時間がかかる（スナップショット作成時間） EBSスナップショット作成による一時的なI/O負荷（通常はほぼ無視できるレベル）スキャン頻度がエージェントモードより低い（24時間に1回程度）

どちらを選ぶべきか？

評価項目	エージェントモード	エージェントレスモード	推奨シーン
導入の容易さ	△（既存インスタンスへの設定必要）	○（設定不要）	既に多数のインスタンスが稼働している場合はエージェントレス
運用負荷	△（エージェントの管理必要）	○（管理不要）	運用リソースが限られている場合はエージェントレス
スキャン速度	○（リアルタイム）	△（24時間に1回程度）	即座の脆弱性検出が必要ならエージェント
本番への影響	△（エージェント常駐）	○（スナップショットのみ）	本番環境への影響回避を最優先するならエージェントレス
ネットワーク要件	○（SSM経由）	○（Inspectorが自動処理）	両方とも柔軟
スキャン精度	○（より詳細）	○（十分な精度）	両方とも実用十分

本記事での推奨：エージェントレスモード

マルチアカウント環境で既に多数のEC2インスタンスが稼働している場合、エージェントレスモードを推奨します。既存インスタンスへの変更が一切不要で即座に導入でき、エージェントのバージョン管理やトラブルシューティングも不要なため運用負荷が極めて低くなります。スナップショット作成以外に本番環境への負荷はなく、各アカウントでInspectorを有効化するだけでマルチアカウント環境全体に展開できます。

ただし、リアルタイムでの継続的な脆弱性監視が求められる高セキュリティ環境や、新規構築のインフラではエージェントモードの採用も検討に値します。

技術的な特徴・アーキテクチャ設計

本アーキテクチャは、マルチアカウント環境において3つの主要機能を組み合わせることで、包括的な脆弱性診断ソリューションを提供しています。

①EC2インスタンスの脆弱性診断：Amazon Inspector による実現

マルチアカウント環境でのアーキテクチャ特徴

各メンバーアカウントで個別に有効化されたInspectorが、アカウント内のEC2インスタンスを自動的にスキャンします。Inspector v2はエージェントモード（SSM Agent経由）またはエージェントレスモード（EBSスナップショット経由）をサポートしており、大規模マルチアカウント環境ではエージェントレスモードの採用を推奨します。

処理フロー（エージェントレスモード）

自動検出フェーズ: Inspector がアカウント内のEC2インスタンスを自動検出
スナップショット作成フェーズ: Inspector管理下でEBSスナップショットを自動作成
脆弱性スキャンフェーズ: スナップショットから専用環境で脆弱性を分析
結果送信フェーズ: スキャン結果をSecurity Hubに自動送信
集約フェーズ: Security/Scanning AccountのSecurity Hubで全アカウントの結果を可視化

本番環境への影響がない理由

エージェントレスモードでは本番インスタンスにエージェント導入が不要
スナップショット作成は一時的なI/O負荷のみ（通常は無視できるレベル）
本番インスタンスへの変更は一切なし

②ECRコンテナイメージの脆弱性診断：ECR Enhanced Scanning による実現

マルチアカウント環境でのアーキテクチャ特徴

各メンバーアカウントのECRリポジトリで、Enhanced Scanningを有効化することで、コンテナイメージがPushされた瞬間に自動的に脆弱性スキャンが実行されます。ECS（Fargate）で稼働するコンテナもECRからイメージを取得するため、ECRレベルでのスキャンによりECS環境の脆弱性も包括的にカバーできます。Fargateはサーバーレスコンテナ実行環境でありユーザーがOSレベルの管理を行わないため、コンテナイメージ自体の脆弱性管理が特に重要です。スキャン結果はInspector v2経由でSecurity Hubに送信され、Security/Scanning Accountで一元管理されます。

処理フロー

イメージPush: 開発者がCI/CDパイプラインからECRにイメージをPush
自動スキャン開始: Enhanced Scanningが自動的にイメージレイヤーをスキャン
CVEデータベース照合: OSパッケージとアプリケーション依存関係の脆弱性を検出
Inspector統合: スキャン結果をInspector v2経由でSecurity Hub標準形式（ASFF）に変換
クロスアカウント集約: Security/Scanning AccountのSecurity Hubに結果を自動送信

CI/CDパイプラインとの統合

ECRスキャンの結果をCI/CDパイプライン（GitHub Actions、Jenkins、CodePipeline等）に組み込むことで、脆弱性のあるイメージが本番環境にデプロイされることを防止できます。Security Accountで集約された結果を定期的にチェックし、Critical/High脆弱性が検出された場合は開発チームにアラートを送信します。

③Lambda関数の脆弱性診断：Amazon Inspector による実現

マルチアカウント環境でのアーキテクチャ特徴

Lambda関数の脆弱性診断も、各メンバーアカウントのInspector v2で自動的に実施されます。Inspectorは、Lambda関数のデプロイパッケージやレイヤーを解析し、依存ライブラリの脆弱性を検出します。

処理フロー

関数検出フェーズ: 各アカウント内のLambda関数を自動検出
コード解析フェーズ: デプロイパッケージから依存ライブラリを抽出
脆弱性照合フェーズ: CVEデータベースと照合して既知の脆弱性を特定
ランタイムチェックフェーズ: 非推奨・サポート終了のランタイムを検出
結果送信フェーズ: Security Hubに検出結果を送信し、Security Accountで集約

Lambda特有の考慮事項

Lambda関数は、ランタイムとして提供されるPython、Node.js、Java等の言語バージョンと、アプリケーションコードに含まれる依存ライブラリの両方に脆弱性リスクがあります。Inspectorは両方を自動的にチェックし、定期的に最新のCVEデータベースと照合します。

スキャン結果の確認と運用

Security Hubでの統合管理

全てのスキャン結果がSecurity Hubに集約されるため、統一されたインターフェースで確認できます。

脆弱性対応のSLA設定

検出された脆弱性への対応優先度と期限を明確にします。

重要度	対応期限	対応方針
Critical	24時間以内	即座にパッチ適用または該当リソースの隔離
High	7日以内	計画的なパッチ適用とテスト
Medium	30日以内	次回メンテナンスウィンドウで対応
Low	90日以内	四半期レビュー時に対応検討

アラート通知の設計

Critical/High脆弱性が検出された場合の通知を設計します。この方法としてはメール通知の他SlackやTeamsへの通知、更にLambda等と組み合わせた自動処理などが考えられます。

まとめ

本記事では、Organizationsを使わないマルチアカウント環境における、AWS脆弱性診断の自動化アーキテクチャを紹介しました。

記事のポイント

Organizationsに依存しないアーキテクチャ: チーム独自で管理する複数のAWSアカウントに対し、IAMクロスアカウントロールとSecurity Hub Invitation方式で脆弱性管理を実現
4つのコンピューティングリソースをカバー: EC2、ECS (Fargate)、ECR、Lambdaの包括的なスキャン
Inspectorのスキャンモード選択: エージェントモードとエージェントレスモードの特徴を理解し、環境に応じて適切に選択
本番環境への影響ゼロ: 読み取り専用アクセス、マネージドスキャン、スナップショットベースのアプローチで安全に実施
Security Hubによる統一管理: ASFF標準形式で全アカウントの脆弱性を単一ダッシュボードで可視化

セキュリティは継続的な取り組みが重要です。本記事のアーキテクチャパターンを参考に、ぜひ自社のマルチアカウント環境に合わせた脆弱性診断の自動化を検討してみてください。

参考資料