責任共有モデルの全体像のシナリオ判断

事故や移行の場面から、どの層の作業を誰が担当するかを判断します。AWSの基盤保護と、自社が変更できる設定やコードを分けて解決策を選びます。

この単元で学ぶこと

1. まず対象を特定する「サーバーの問題」という表現だけでは担当を決められません。物理ホストの故障なのか、ゲストOSの未更新なのか、アプリの欠陥なのかを分けます。EC2の物理基盤ならAWS、利用者のゲストOSや配置したアプリなら利用者側の管理作業として整理します。

2. 通信設定の事故社内向けEC2へ広い送信元を許可してしまった場合、利用者は必要な通信を確認してルールを修正します。AWSがセキュリティグループを提供していることは、業務に必要な送信元をAWSが決める意味ではありません。機能の提供者と設定の決定者を区別します。

3. 保存場所を変える演習 EC2上のファイルをS3へ移すと、保存サービスの基盤OSへのパッチ作業はAWS側になります。一方で、顧客情報を誰が読めるか、誤って公開していないかは利用者が管理します。移行前後の責任表は作業名を置き換えるだけでなく、管理する層から作り直します。

4. DB移行後の権限 EC2上のDBをRDSへ移しても、退職者のDB利用権限を外す判断は利用者側です。接続元の制限やDB利用者の権限も確認します。AWSに基盤運用を任せた効果と、業務上誰を許可するかという責任は別に扱います。

5. 関数の更新を二段階で見る Lambdaで自作コードの欠陥が見つかった場合は利用者が修正します。コンテナ方式で新ベースイメージが出た場合も、既存の配備イメージに取り込むため再構築・再配備が必要です。更新の公開、取り込み、配備、確認をそれぞれ区別して証跡を残します。

6. 統制名と対象層監査表に「パッチ管理」とだけあるとAWSと利用者のどちらの作業か分かりません。基盤ホスト、ゲストOS、アプリの依存関係という対象を追記します。教育も対象従業員の所属を明記すると、AWS側の教育資料だけで自社教育を完了扱いにする誤りを防げます。

7. 証跡の使い方 AWSの統制資料は対象サービスや期間、評価範囲を確認して使います。自社が設定したアクセス権やデータの利用方法まで、その資料だけで証明できるわけではありません。自社構成の証跡と組み合わせ、要件ごとにどの資料が何を示すかを整理します。

8. 運用引継ぎで確認する担当表では「AWSへ任せる」だけで終えず、利用者に残る設定・更新・データ管理の担当者を決めます。サービス変更後も旧担当表をそのまま使うと抜けが生じます。具体例としてS3移行後は基盤OS更新を外し、バケット権限とデータ分類を利用者の確認事項に残します。

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。