【令和5年春期 午後Ⅰ】情報処理安全確保支援士 問題別・学ぶべき知識（セキュア実装・侵害通信分析・クラウドアクセス制御）

令和5年春期 午後Ⅰで問われたセキュア実装・侵害通信分析・クラウドアクセス制御の知識を、攻撃・影響・対策の流れと、全設問で必要になる補足知識に分けて整理します。

午後Ⅰ 問１　Webアプリケーションプログラム開発

• 攻撃・原因 → 影響（成立の流れ）

  起点：攻撃者が注文番号又は得意先コードを変更

  攻撃の進行：他社の注文情報を取得

  結果・補足：セッションの得意先コードと注文ヘッダーの得意先コードをSQL条件で照合し、所有者不一致を拒否する

• 対策・確認

  注文番号をstatic変数に置くと並行リクエスト間で値が上書きされ、別利用者の注文が混ざる。

  リクエストごとのローカル変数・メソッド引数へ変更し、ファイルパスは正規化、SQLはPreparedStatementで処理する

  設問別の補足知識（全2設問）

  設問1：

  (1) 図1の13行目において、外部入力値（inOrderNo）をファイルパス文字列の連結にそのまま使用しており、ディレクトリトラバーサル脆弱性の指摘箇所となります。

  (2) 14行目で生成したストリーム変数「in」がクローズされておらず、リソース解放漏れとなっています。

  (3) プレースホルダ（?）を用いたパラメータバインドによるプリペアドステートメント（PreparedStatement）を使用することで、SQLインジェクション脆弱性を根本的に防ぎます。

  設問2：

  (1)(2) ビジネスロジッククラス内で「orderNo」が「static」クラス変数として宣言されていたため、マルチスレッド環境下で全リクエスト間で値が上書き・共有されてしまっていました。

  (3) 複数スレッドが共有変数に同時アクセスすることで実行順序により結果が狂う不具合は「レースコンディション（Race Condition / 競合状態）」と呼ばれます。

  (4) static変数を廃止し、インスタンス生成（new）およびメソッド引数渡し（getOrderInfoBean(orderNo)）に変更してスレッドセーフ化します。

  (5) 他人の注文情報を閲覧できないよう、セッション内の自得意先コードと注文ヘッダーテーブルの「得意先コード」が一致することをSQL条件に追加（認可チェック）します。

午後Ⅰ 問２　セキュリティインシデント

• 攻撃・原因 → 影響（成立の流れ）

  起点：侵害サーバで待受けるバインド型は外部から8080番への通信をFWに拒否される

  攻撃の進行：マルウェアが443番で外向き接続するコネクトバック型へ切替え

  結果・補足：許可済みHTTPS経路でC&C接続を確立する

• 対策・確認

  DNS TXT応答は任意文字列を返せるためコマンド配送に悪用される。

  攻撃者側ファイルは差替え済みの可能性があるので、受付サーバのメモリ上で稼働中の実体を保全し、プロセス・FW・DNSログと照合する

  設問別の補足知識（全3設問）

  設問1：

  DBサーバ（192.168.0.2）から製造管理サーバ（192.168.1.145:60453）に対してクライアント側からデータコネクションを開始しているため「パッシブ（PASV）モード」です。

  設問2：

  (1) SNMPv2cにおいて機器認証・グループ識別に用いられる文字列は「コミュニティ（名）」です。

  (2) バインドモード（項番2-3）で8080番ポートを待ち受け（項番3-3）ましたが、外部からの8080番アクセスがFWで拒否（項番1-3）されたため接続に失敗しました。

  (3) コネクトモード（項番2-4）で443番宛てにコネクトバックを発信し（項番3-4）、FWの443アウトバウンド許可ルール（項番1-4）によってC&Cサーバと接続確立（ESTABLISHED）しました。

  (4) ポートスキャンを実行していたプロセスは、引数に `-s -range` を指定している子プロセス「1365」（項番2-5）です。

  設問3：

  (1) AレコードはIPアドレス形式しか返せませんが、TXTレコードは任意のテキスト文字列（シェルコマンド文字列など）を格納・応答できる仕様のためです。

  (2) 攻撃者サーバ上のファイルが既に改ざん・削除・置換されている可能性があり、実際に被害サーバ上で実行されたマルウェアの実体とは異なる可能性があるためです。

  (3) 侵害された「受付サーバ」上のメモリ（`/dev/shm/logd`）から稼働中の実体バイナリを直接保全・抽出して解析に回します。

午後Ⅰ 問３　クラウドサービス利用

• 攻撃・原因 → 影響（成立の流れ）

  起点：社外端末が本社UTMを通らずSaaSへ直接接続

  攻撃の進行：URL制御・送信元制限・監査ログを回避する

  結果・補足：端末エージェントでクラウドプロキシを強制経由させ、CASBでサービスと操作を判定する

• 対策・確認

  本社UTMの固定IPだけをIdPで許可し、社外利用も同じ出口へ集約する。

  部門ごとの許可SaaS、外部ストレージへのアップロード禁止、HTTPS可視化用ルート証明書、例外申請をポリシーへ明記する

  設問別の補足知識（全3設問）

  設問1：

  (1) SAML認証連携において、未認証アクセスはSP（SaaS-a）からIdP（Lサービス）へリダイレクトされ、IdPで認証後にブラウザ（PC）経由でSAMLレスポンスがSPへ送信されます。

  (2) Lサービスの送信元制限機能により、本社のUTMのグローバルIPアドレスからのみログインが許可されているため、社外（攻撃者環境）からのアクセスは拒否されます。

  設問2：

  (1) SSL/TLS可視化（HTTPS復号）機能では、Pサービスが動的に生成するサーバ証明書（ア）を発行するプライベート認証局の証明書（ウ）を、PCの「信頼されたルート証明書（イ）」ストアに事前登録します。

  (2) クラウドサービスの利用状況の可視化・制御を行うセキュリティフレームワーク/サービスは「CASB（Cloud Access Security Broker）」です。

  設問3：

  (1) ローカルブレイクアウト/SASE構成とし、営業所から本社プロキシへのVPN集中をやめ、Pサービスへ直接接続させます。

  (2) 営業所から直接Lサービスにアクセスできるよう、営業所UTMの固定グローバルIPをLサービスの送信元許可リストに追加します。

  (3) R-PC（在宅環境）からのアクセス時は、端末制限（要件2）を満たすため端末にインストールされた証明書を用いた「（イ）TLSクライアント認証」を選択します。

  (4) 社内アクセス（要件3）にはPコネクタを用いた項番6「リモートアクセス機能」、マルウェアスキャン（要件4）には項番2「マルウェアスキャン機能」を使用します。

  (5) ホワイトリスト方式により、項番4（URL単位）で研究開発部のみに https://△△△-a.jp/ を「許可」し、続く項番3（カテゴリ単位）で全員に対して「外部ストレージサービス」を「禁止」します。