AWSと利用者の責任分界のシナリオ判断
同じ「セキュリティ事故」でも、公開設定の誤り、アプリケーションの欠陥、物理設備の故障では担当と対処が異なります。EC2とS3で社内申請システムを運用する例を使い、問題の層を見つけて具体的な対策を決めます。
この単元で学ぶこと
- 運用事例から担当範囲と未実施の作業を特定できる
- サービス移行で減る作業と残る作業を区別できる
- 事故の原因に直接対応する対策を選べる
本文解説
事例の構成 申請画面はEC2上で動き、添付ファイルはS3へ保存しています。社員は申請に必要なファイルだけを閲覧します。EC2の物理ホストとS3基盤はAWS側ですが、EC2内のOS・申請アプリと、S3ファイルを誰が読めるかは利用者側の設計です。画面と保存先を同じ「AWS上」とまとめないことが出発点です。
問題1：EC2のOS更新が止まっている 担当者は「AWS上なので更新は不要」と考えていました。EC2ではゲストOS管理が利用者の担当なので、更新対象と現在の版を調べ、検証・適用・失敗時の復旧手順を用意します。インスタンスを別のAZへ移しても、同じ未更新OSを使えば弱点は残ります。
問題2：添付ファイルを外部から読める バケットの公開設定やポリシーが業務要件に合わない可能性を調べます。非公開にするファイルへ外部読み取りを許可していたなら、その許可を取り消します。物理ディスクがAWS管理であることや暗号化の設定だけを理由に、公開範囲の確認を省略してはいけません。
問題3：アプリの入力処理に欠陥がある 申請画面へ不正な入力を送ると意図しない処理が起きる場合、利用者はアプリの入力検証やクエリ処理を修正します。Web防御の機能は緩和策になり得ますが、コードの欠陥が自動的に消えるわけではありません。AWSの物理機器交換を待つ問題ではありません。
変更例：EC2の一部処理をマネージドサービスへ移す サービスが管理するOSの運用負担は減ります。一方、入力するデータ、業務ロジック、サービス操作の権限をどう扱うかは引き続き確認します。新しいサービスに任せられる機能を把握し、旧来のEC2作業一覧をそのまま移さず、担当表を作り直します。
証跡を分けて確認する 基盤の安全性についてはAWSの該当資料を利用し、自分の設定については権限の一覧や変更記録、更新の実行結果を確認します。AWS側の基盤に関する説明だけでは「自社の添付ファイルが社員以外から読めない」ことまでは証明できません。実際の許可と拒否の両方を検証します。
例題：異動後も閲覧できる社員 申請部門から異動した社員が以前のファイルを読める状態です。直接見直すのは所属や職務に応じたアクセス権限です。保存先を別のリージョンへ移すことや、EC2を増やすことでは許可の誤りは直りません。担当者は異動時の権限見直しと、不要な権限を除去できたことの確認を組み込みます。
解答の組み立て 「S3のファイル／社員以外にも許可／権限の誤り／利用者が公開範囲を修正」のように、対象・状態・原因・対策を並べます。この形で答えると、暗号化やバックアップなど有用でも今回の原因を取り除かない対策を区別できます。複数の対策が必要なときも、何を解決する対策かを一つずつ説明します。
図解
重要ポイント
- サービス名だけでなく問題が生じた層を調べる。
- OS更新・アプリ修正・権限修正は、それぞれ原因に対応して実施する。
- 移行でOS管理が減っても、データと権限の管理は続く。
- 許可すべき操作と拒否すべき操作を実際に確認する。
間違えやすい点
- AZを変えることをOSの欠陥修正と取り違えない。
- 暗号化済みのデータでも誤った主体に許可していないか確認する。
- AWSの基盤の説明だけで自社の設定確認を終えない。
用語解説
- 責任共有モデル
- AWSが保護する基盤と、利用者が管理するデータ・設定・アプリケーションなどの分担。利用サービスによって境界が変わる。
- ゲストOS
- EC2インスタンス内で利用者が使うオペレーティングシステム。物理ホストのOSや仮想化層とは別である。
- マネージドサービス
- 基盤の運用の一部をAWSへ任せて利用するサービス。データや権限の管理まで無条件に任せる意味ではない。
- アクセス権限
- 誰がどの資源にどの操作をできるかを定めた許可。認証情報を守ることと、必要最小限の操作へ絞ることは別の対策である。
関連教材
参考資料
教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。
確認問題の出題・採点や学習履歴の保存にはログインが必要です。