組織全体の監査ログと構成情報の集約 動画配信を手がけるメディア企業が AWS Organizations で 80 アカウントを運用しています。監査チームは、全アカウントの API 呼び出し履歴と各リソースの構成変更履歴を 1 つの監査アカウントから横断的に検索したいと考えています。ログの保存先はログアーカイブ用アカウントの S3 バケットに集約し、メンバーアカウントの管理者がログを改ざん・削除できてはなりません。また新規アカウントが追加された際に個別設定が不要であることも求められています。最も適切な構成はどれですか。
A 管理アカウントで組織の CloudTrail 証跡を作成してログアーカイブアカウントの S3 バケットに出力し、CloudTrail の委任管理者を監査アカウントに設定する。さらに監査アカウントを AWS Config の委任管理者として組織アグリゲーターを構成する。 B 各メンバーアカウントで個別に CloudTrail 証跡と AWS Config を有効化し、それぞれの S3 バケットからクロスリージョンレプリケーションで監査アカウントへ集約する。 C 各メンバーアカウントの CloudWatch Logs にサブスクリプションフィルターを設定し、監査アカウントの Kinesis Data Firehose 経由で S3 に転送するスクリプトをアカウント作成のたびに実行する。 D 監査アカウントで AWS Security Hub を有効化し、Security Hub の検出結果のみを保存することで API 呼び出し履歴と構成変更履歴の代替とする。
解説を読む（正解: A） マルチアカウント環境では、ログの収集をアカウントごとの個別設定に任せると設定漏れや改ざんのリスクが生じるため、組織レベルの一元化機能を使うことが定石です。CloudTrail の組織証跡は管理アカウント (または委任管理者) で 1 回作成するだけで組織内の全メンバーアカウントに自動適用され、新規アカウントが組織に参加した時点で自動的に対象へ含まれます。ログ出力先をログアーカイブアカウントの S3 バケットにし、バケットポリシーで書き込み以外を制限したり Object Lock を適用したりすれば、メンバーアカウントの管理者は自アカウントの証跡設定を変更できず、保存済みログの削除もできません。AWS Config については組織アグリゲーターを監査アカウントに構成することで、全アカウント・全リージョンの構成項目と準拠状況を 1 か所から検索できます。B はアカウントごとの個別設定に依存するため設定漏れが起きやすく、メンバーアカウント側で証跡を停止できてしまい改ざん防止の要件を満たせません。C はサブスクリプションフィルターとスクリプトの自前運用が必要で、新規アカウントごとの手作業が発生するうえ CloudTrail や Config そのものの一元管理にはなりません。D は Security Hub がセキュリティ検出結果の集約サービスであり、CloudTrail のイベント履歴や Config の構成変更履歴そのものを代替するものではないため、監査要件を満たしません。
ハイブリッド環境のパッチ適用とコンプライアンス可視化 自治体の情報システム部門が、AWS 上の 400 台の EC2 インスタンスと、庁舎内データセンターの 150 台の Linux / Windows サーバーを運用しています。監査対応として、(1) すべてのサーバーに同一のパッチベースラインを適用し、承認済みのパッチのみを一定の保留期間の後に決められた時間帯で自動適用すること、(2) 適用状況を AWS 側で一元的に可視化し、非準拠のサーバーを継続的に検出して評価履歴を保持することが求められています。また、踏み台サーバーと SSH 鍵の配布は全面的に廃止する方針です。実施すべき対策を 2 つ選択してください。
A オンプレミスサーバーに SSM Agent を導入してハイブリッドアクティベーションでマネージドノードとして登録し、AWS Systems Manager Patch Manager のパッチベースラインとメンテナンスウィンドウで AWS 側とオンプレミス側の双方に同一のパッチ適用を行う B AWS Config のマネージドルールでマネージドノードのパッチコンプライアンス状態を継続的に評価し、結果を Config アグリゲーターと AWS Security Hub に集約して非準拠リソースを一元的に可視化する C 各サーバーに cron とタスクスケジューラを設定して OS のパッケージマネージャーを直接実行し、実行ログを Amazon S3 に集約して Amazon Athena で集計する D Amazon Inspector を有効化し、検出された脆弱性に対して Inspector から直接パッチを適用してサーバーを自動修復する E AWS Site-to-Site VPN 経由で全オンプレミスサーバーへ SSH 接続する踏み台 EC2 インスタンスを構築し、そこから構成管理ツールでパッチを配布する
判定する 複数選択問題です (正解 2 つ)。選んでから判定してください。
解説を読む（正解: A、B） AWS Systems Manager Patch Manager は、パッチベースラインとして「承認するパッチの分類と重要度」「自動承認までの待機日数」「明示的に承認 / 拒否するパッチ」を定義し、メンテナンスウィンドウで適用する時間帯を制御する仕組みを提供します。オンプレミスのサーバーもハイブリッドアクティベーションで SSM Agent を登録すればマネージドノードとして扱われるため、AWS 上の EC2 とまったく同一のベースラインを両環境に適用でき、要件 (1) を満たします。同じ Systems Manager の Session Manager を使えばインバウンドポートも SSH 鍵も不要な監査付きシェルアクセスが得られるため、踏み台と鍵配布の廃止方針とも整合します。一方、要件 (2) の「継続的な評価と履歴の保持」は AWS Config の役割です。AWS Config にはマネージドノードのパッチコンプライアンス状態を評価するマネージドルールがあり、評価結果を設定項目として履歴保存します。さらに Config アグリゲーターで複数アカウント / リージョンの結果を集約し、Security Hub に取り込むことで非準拠リソースを一元的なダッシュボードで確認できます。よって A と B が正解です。C は承認ワークフローも一元的なコンプライアンス評価も自前で作り込むことになり、要件の「AWS 側で一元的に可視化」を満たさず運用負荷も高くなります。D は誤りで、Amazon Inspector は脆弱性の継続的なスキャンと重大度の評価を行うサービスであり、パッチを適用してサーバーを修復する機能は持ちません。修復は Patch Manager など別の手段で実施する必要があります。E は踏み台と SSH 鍵の配布を廃止するという方針に真っ向から反し、コンプライアンス評価の履歴も得られません。
マルチアカウントのベースライン構築と AD FS 連携 ある電力インフラ事業者が、社内のシステム群を AWS クラウドへ移行しています。案件ごとに準拠すべき規制基準が異なるため、ワークロードを分離したマルチアカウント環境が必要です。ソリューションアーキテクトは、これらのアカウントのベースラインとなる基盤を整備しなければなりません。このソリューションは、ガバナンスとセキュリティの一貫したベースラインを提供しつつ、アカウントごとに異なるコンプライアンス要件へ柔軟に対応できる必要があります。さらに、既存のオンプレミス Active Directory フェデレーションサービス (AD FS) サーバーと統合し、社員が既存の資格情報でサインインできるようにする必要もあります。運用上のオーバーヘッドを最小限に抑えながらこれらの要件を満たすソリューションはどれですか。
A AWS Organizations で組織を作成する。全アカウントに適用する最小権限の SCP を 1 つだけ作成し、すべてのアカウントを単一の OU に配置する。オンプレミスの AD FS と連携する IAM ID プロバイダーを各アカウントに構成する。中央ログアカウントを用意してログイベントを集約し、中央アカウントで AWS Config とコンフォーマンスパックを有効にする。 B AWS Organizations で組織を作成する。最小権限アクセスのための SCP を作成し、OU 構造を設計してアカウントをグループ化する。AWS IAM Identity Center をオンプレミスの AD FS に接続する。中央ログアカウントを構成してログイベントを集約し、アグリゲータとコンフォーマンスパックを使って中央アカウントで AWS Config を有効にする。 C AWS Organizations で組織を作成し、その組織で AWS Control Tower を有効にする。SCP として適用されるコントロール (ガードレール) の内容を確認し、AWS Config で補うべき領域を洗い出す。オンプレミスの AD FS と連携する IAM ID プロバイダーを各アカウントに構成する。 D AWS Organizations で組織を作成し、その組織で AWS Control Tower を有効にする。SCP として適用されるコントロール (ガードレール) の内容を確認し、AWS Config で補うべき領域を洗い出す。コンプライアンス要件の違いに応じて OU を追加する。AWS IAM Identity Center をオンプレミスの AD FS に接続する。
解説を読む（正解: D） AWS Control Tower は、AWS Organizations、AWS Config、AWS CloudTrail、AWS IAM Identity Center などを組み合わせたランディングゾーンをテンプレート化して自動構築するサービスです。ログアーカイブアカウントと監査アカウントの作成、組織証跡の有効化、Config アグリゲータの構成、予防的および発見的コントロールの適用までが自動化されるため、同等の構成を個別に組み立てて維持するより運用上のオーバーヘッドを大幅に削減できます。案件ごとに規制要件が異なる場合は、要件の近いアカウントを OU 単位でまとめ、その OU に対して追加のコントロールや Config ルールを適用することで、共通ベースラインを維持しながら差分に柔軟に対応できます。ID 連携については、Control Tower が有効化する IAM Identity Center に対して AD FS を外部 ID プロバイダーとして接続すれば、既存の Active Directory の資格情報で組織内の全アカウントにシングルサインオンでき、アクセス権限セットで割り当てを一元管理できます。よって D が最適です。A は SCP と OU をそれぞれ 1 つに固定しているため異なるコンプライアンス要件に対応できず、ベースラインもすべて手作業で構築・維持することになります。B は最終的な構成としては妥当ですが、ランディングゾーン相当の仕組みを自前で設計・実装・更新し続ける必要があり、Control Tower を使う案より運用負荷が高くなります。C は Control Tower を使う点は適切ですが、OU による差分吸収に触れておらず、各アカウントに IAM ID プロバイダーを個別構成するためアカウント数が増えるほど証明書更新などの管理が煩雑になります。