情報処理安全確保支援士試験 令和6年度 春期 午後 問1
今回は、多くのシステムで採用されているAPIのセキュリティをテーマにした【令和6年度 春期 午後 問1】を徹底解説していきます。 この問題は、APIの脆弱性に対して、原因を分析し、適切な対策を立案する能力が問われる、まさに支援士として必須のスキルを試す良問です。
採点講評では「全体として正答率は平均的」とされていますが、一部正答率が低い設問もありました。 つまり、基本をしっかり押さえつつ、応用的な部分でいかに差をつけられるかが合格へのカギとなります。
この記事を通して、問題のポイント、解答に至る思考プロセス、そして関連知識をしっかり身につけていきましょう！
【出典：情報処理安全確保支援士試験 令和6年度 春期 午後 問1（一部、加工あり）】
問1 APIセキュリティに関する次の記述を読んで、設問に答えよ。
G社は、ヘルスケアサービス新興企業である。利用者が食事、体重などを入力してそのデータを管理したり、健康リスクの判定や食事メニューのアドバイスを受けたりできるサービス（以下、サービスYという）を計画している。具体的には、クラウドサービス上にサービスY用のシステム（以下、Sシステムという）を構築して、G社が既に開発しているスマートフォン専用アプリケーションプログラム（以下、G社スマホアプリという）からアクセスする。Sシステムの要件を図1に示す。
G社は、Sシステムの構築をITベンダーF社に委託した。F社との協議の結果、クラウドサービスプロバイダE社のクラウドサービス上にSシステムを構築する方針にした。
[APIの設計]
Sシステムには、将来的には他社が提供するスマートフォン専用アプリケーションプログラムからもアクセスすることを想定し、RESTful API方式のAPI（以下、SシステムのAPIをS-APIという）を用意する。RESTful APIの設計原則の一つにセッション管理を行わないという性質がある。この性質を（a）という。
E社が提供するクラウドサービスのサービス一覧を表1に、サービスYのシステム構成を図2に、S-API呼出し時の動作概要を図3に、S-APIの仕様を表2に、Sシステムの仕様を図4に、それぞれ示す。
問題の舞台設定：ヘルスケアサービス「サービスY」
まずは、物語の背景となるG社の新サービス「サービスY」のシステム構成を把握しましょう。ここを正確に理解することが、後々の設問を解く上での土台となります。
- サービス内容: 利用者が食事や体重などを記録・管理し、健康リスク判定や食事メニューのアドバイスを受けられるヘルスケアサービスです。
- システム構成:
- システム基盤は、E社のクラウドサービス上に構築されています（Sシステム）。
- 利用者は、スマートフォンにインストールした「G社スマホアプリ」からインターネット経由でSシステムにアクセスします。
- APIの採用:
- 将来的に他社アプリとの連携も視野に入れ、RESTful API方式の「S-API」を開発します。
- 利用者区分:
- 全機能が使える「有償利用者」と、一部機能が制限される「無償利用者」の2種類が存在します。
- アーキテクチャ:
- APIリクエストはAPIゲートウェイ（サービスK）で受け付け、イベント駆動型のコンピューティングサービス（サービスL）で処理を実行し、データベース（サービスM）でデータを読み書きする、サーバーレスに近い構成です。
【設問1】RESTful APIの超基本原則
では早速、ウォーミングアップとなる最初の設問から見ていきましょう。
【設問1】 本文中の (a) に入れる適切な字句を答えよ。
問題文の該当箇所
RESTful APIの設計原則の一つにセッション管理を行わないという性質がある。この性質を (a) という。
解答
ステートレス
解説：なぜ「ステートレス」なのか？
この設問は、RESTful APIの最も重要な設計原則の一つを問う、基本的な知識問題です。
キーワードは「セッション管理を行わない」
本文に「セッション管理を行わないという性質」とあるのが最大のヒントです。
- ステートフル（Stateful）: サーバー側がクライアントの状態（ステート）、つまり過去のやり取りの文脈を覚えている（セッションを保持している）状態です。例えば、オンラインショッピングで商品をカートに入れた後、別のページに移動してもカートの中身が保持されているのは、サーバーが「このユーザーはカートに何を入れているか」という状態を覚えているからです。
- ステートレス（Stateless）: 一方、ステートレスは「状態（State）を持たない（less）」という意味で、サーバー側はクライアントの過去のリクエスト情報を一切保持しません。各リクエストは、それ単体で完結する自己完結型である必要があります。
ステートレスアーキテクチャのメリット
では、なぜRESTful APIではステートレスが原則なのでしょうか？
- スケーラビリティの向上: サーバーがクライアントの状態を管理する必要がないため、リクエストをどのサーバーに送っても同じように処理できます。これにより、サーバーの台数を増やして負荷を分散させる「スケールアウト」が非常に容易になります。クラウドサービスとの相性が抜群に良いのです。
- 可用性の向上: あるサーバーに障害が発生しても、クライアントの状態はそのサーバーに依存していないため、すぐに別の正常なサーバーが処理を引き継ぐことができます。システム全体の信頼性が高まります。
- シンプルさ: サーバー側で複雑なセッション管理ロジックを持つ必要がなくなり、システム全体の設計や実装がシンプルになります。
「じゃあ、誰からのリクエストかどうやって判断するの？」
ここで疑問に思うのが、「状態を保持しないなら、どうやってログイン状態などを維持するの？」という点です。
その答えは、「クライアントが、リクエストのたびに必要な情報を全て送信する」ことです。 今回の問題でも、認証後に発行されるJWT（JSON Web Token）を、G社スマホアプリがリクエストの都度、Authorizationヘッダに含めて送信することで、Sシステムは「誰からのリクエストか」を識別しています。 このJWTの仕組みが、ステートレスな認証・認可を実現する鍵となります。（この話は、設問2でさらに深く掘り下げていきます！）
いかがでしたでしょうか。 設問1は、RESTful APIの「ステートレス」という基本概念の理解を問う問題でした。この原則が、本問で登場する様々な脆弱性やその対策を考える上での大前提となります。
次回は、このステートレスな環境で発生した脆弱性の診断結果を分析し、具体的な対策を考えていく【設問2】を解説します。お楽しみに！