午前I問題

クラウドサービスの責任共有モデル（Shared Responsibility Model）において、IaaS・PaaS・SaaSの各サービス形態を比較したとき、一般的に利用者側の責任範囲が最も広いのはどれか。

ア）IaaS　イ）PaaS　ウ）SaaS　エ）サービス形態にかかわらず常に同じ

午前I の解答・解説を見る

正解： ア）IaaS

解説：

  • ア）正解。IaaS（Infrastructure as a Service）は仮想サーバ・ストレージ・ネットワークなどのインフラのみをクラウド事業者が提供し、OS以上のミドルウェア・ランタイム・アプリケーション・データの管理は利用者の責任となる。したがって利用者側の責任範囲が最も広い。
  • イ）不正解。PaaS（Platform as a Service）はOSやミドルウェア、実行環境までクラウド事業者が管理するため、利用者の責任はアプリケーションとデータの管理に限定され、IaaSより責任範囲は狭い。
  • ウ）不正解。SaaS（Software as a Service）はアプリケーションまでクラウド事業者が提供するため、利用者の責任はデータとアクセス管理などごく一部にとどまり、責任範囲は最も狭い。
  • エ）不正解。サービス形態によって事業者と利用者の責任分界点は明確に異なり、常に同じではない。

午前II問題

FaaS（Function as a Service）を用いたサーバーレスアーキテクチャにおけるセキュリティ対策の説明のうち、最も適切なものはどれか。

ア）1つの関数に付与するIAMロールには、その関数が実行する処理に必要な権限だけでなく、将来の機能追加を見越して広めの権限を付与しておくべきである。

イ）コールドスタート時に発生する初期化処理の遅延を悪用したタイミング攻撃やDoS的な誘発リスクがあるため、実行時間・同時実行数の制限や監視を行う必要がある。

ウ）FaaSはサーバ管理が不要であるため、OSやミドルウェアの脆弱性対策は事業者の責任範囲であり、利用者が対策すべき点は存在しない。

エ）関数間でグローバル変数や一時ファイルを共有することで、実行環境（コンテナ）の再利用を促進し、機密情報を安全にキャッシュできる。

午前II の解答・解説を見る

正解： イ）

解説：

  • ア）不正解。IAMロールは最小権限の原則に基づき、その関数が必要とする最小限の権限のみを付与すべきである。将来を見越した広めの権限付与は、関数が侵害された際の被害範囲（Blast Radius）を不必要に拡大させる典型的なアンチパターンである。
  • イ）正解。コールドスタートとは、一定時間呼び出されなかった関数の実行環境（コンテナ）が破棄された後、次回呼び出し時にゼロから初期化される現象を指す。この遅延を悪用して大量リクエストを送りコールドスタートを連鎖的に誘発させることで、レイテンシ悪化やコスト増大を狙うDoS的な攻撃リスクがあるため、同時実行数の上限設定やタイムアウト・監視による対策が必要となる。
  • ウ）不正解。FaaSではホストOSの管理は事業者責任だが、関数コードやその依存ライブラリの脆弱性、過剰なIAM権限、環境変数への機密情報のハードコードなどは利用者の責任範囲であり、対策が必要である。
  • エ）不正解。実行環境（ウォームコンテナ）の再利用時にグローバル変数や一時ファイルに機密情報を残すと、次に同じコンテナが別の呼び出し（場合によっては別テナントの処理）に再利用された際に情報が漏洩するリスクがある。機密情報のキャッシュは推奨されず、シークレットは都度取得し不要になったら破棄すべきである。

午後問題

ソーシャルゲームを提供するC社は、画像アップロード処理をAWS Lambdaによるサーバーレスアーキテクチャで実装している。ユーザがアップロードした画像はS3バケットに保存され、それをトリガーとしてLambda関数がサムネイル生成・不適切画像の自動検知を行い、結果をDynamoDBに書き込む構成である。

セキュリティ診断の結果、次の問題点が指摘された。

  • サムネイル生成用のLambda関数に付与されているIAMロールには、S3の全バケットに対するフルアクセス権限（s3:*）と、DynamoDBの全テーブルに対するフルアクセス権限（dynamodb:*）が付与されていた
  • 外部の画像検知APIを呼び出す際のAPIキーが、Lambda関数のソースコード内に直接記述されていた
  • 各Lambda関数の実行ログにはリクエスト内容が出力されているが、異常なエラー率の急増を検知する仕組みがなく、障害やコスト急増に気づくのはユーザからの問い合わせが発端であった

設問1

サムネイル生成用Lambda関数のIAMロールについて、最小権限の原則に基づき見直すべき内容を、S3・DynamoDBそれぞれについて具体的に述べよ。

設問1の解答・解説を見る

正解例：

  • S3：フルアクセス（s3:*）ではなく、処理対象の特定バケット（アップロード用バケットからのs3:GetObject、サムネイル保存用バケットへのs3:PutObject）のみに限定した権限に変更する。
  • DynamoDB：全テーブルへのフルアクセス（dynamodb:*）ではなく、結果を書き込む特定のテーブルに対するdynamodb:PutItemなど、必要な操作のみに限定した権限に変更する。

解説・採点基準（計15点）：

採点項目キーワード配点
S3権限をリソース（バケット）単位で限定する点に言及特定バケット・ARN指定4点
S3権限を操作（アクション）単位で限定する点に言及GetObject／PutObjectなど必要最小限の操作4点
DynamoDB権限をリソース（テーブル）単位で限定する点に言及特定テーブル・ARN指定4点
DynamoDB権限を操作単位で限定する点に言及PutItemなど必要最小限の操作3点

いずれも「最小権限の原則（Principle of Least Privilege）」というキーワードへの言及があれば加点対象とする。関数が侵害された場合の被害範囲（Blast Radius）を抑える効果に触れていればなお良い。

設問2

Lambda関数のソースコードに直接記述されている外部APIキーについて、セキュアな管理方法を1つ挙げ、その理由を述べよ。また、実行ログとコスト急増の検知に関する運用上の改善策を1つ述べよ。

設問2の解答・解説を見る

正解例：

  • APIキー管理：AWS Secrets Manager（またはSSMパラメータストア）等のシークレット管理サービスにAPIキーを保管し、Lambda関数の実行時にAPIを呼び出して動的に取得する方式に変更する。理由は、ソースコードへの直接記述はバージョン管理システムへのコミットによる漏洩リスクや、コードレビュー時・ログ出力時の意図しない露出リスクがあり、また鍵のローテーションもコード変更なしに行えるため。
  • 運用改善：CloudWatch等でLambdaの呼び出し回数・エラー率・実行時間・同時実行数に対するアラート（しきい値監視）を設定し、異常な急増を検知した場合に運用担当者へ自動通知する仕組みを導入する。

解説・採点基準（計15点）：

採点項目キーワード配点
シークレット管理サービスの利用に言及Secrets Manager／パラメータストア等5点
コード直書きのリスク（漏洩・ローテーション困難）に言及リポジトリ漏洩・鍵ローテーション4点
メトリクス監視・アラート設定に言及CloudWatchアラーム・しきい値監視4点
異常検知後の通知・自動対応に言及自動通知・エラー率監視2点

環境変数への格納のみを回答した場合は部分点（3点）とする。環境変数自体もIAMポリシーで閲覧を制限しない限り漏洩リスクが残るため、シークレット管理サービスの利用がより望ましい解答となる。

重要キーワード

用語説明
FaaSFunction as a Service。関数単位でコードをデプロイし、イベント駆動でサーバ管理不要に実行できるサーバーレスの一形態
責任共有モデルクラウド事業者と利用者の間でセキュリティ責任範囲を分担する考え方。IaaS/PaaS/SaaSでその境界が異なる
コールドスタート一定時間未使用の関数実行環境が破棄された後、次回呼び出し時にゼロから初期化が発生し遅延が生じる現象
最小権限の原則主体に対して業務遂行に必要な最小限の権限のみを付与するセキュリティの基本原則
Blast Radiusある要素が侵害された際に影響が及ぶ範囲。過剰な権限付与はこの範囲を不必要に拡大させる
シークレット管理サービスAPIキーやパスワード等の機密情報を安全に保管・取得・ローテーションするための専用サービス（鍵管理も参照）

まとめ

  • 午前I視点： 責任共有モデルはIaaS・PaaS・SaaSの順に利用者側の責任範囲が狭まる。クラウド形態ごとの分界点を正確に把握することが基礎。
  • 午前II視点： FaaSでは最小権限のIAM設計とコールドスタートに起因する運用リスク（DoS誘発・遅延）の両方が頻出論点。実行環境の再利用による情報残留リスクも押さえておく。
  • 午後視点： サーバーレス環境の実務対策は「IAMロールのリソース・操作単位での限定」「シークレットの外部管理」「メトリクス監視によるインシデントの早期検知」の3点が核心となる。