境界線の守り方 ――
JWT認証とセッション管理で実現する「ガチ」の防衛術
- SPIRAL
前回の記事では、外部サーバを使って「30秒の壁」を突破する方法を紹介しました。
しかし、システムを外部と繋ぐ以上、いかに「正当なアクセス」を担保するかが極めて重要になります。今回は、システム開発案件に求められる高水準のセキュリティ要求に対し、どのような技術スタックで応えたのかを解説します。
■【課題】外部APIの「聖域化」をいかに実現するか
SPIRAL®という「守られた箱」の外に処理を出す以上、単なるAPIキー認証だけでは不十分です。
「SPIRAL®の認証エリアから行われた正当な操作であること」を外部サーバ側でも確認し、さらにリクエスト内容の改ざんや不正な直接アクセスを防ぐ必要がありました。
■【解決】多層防御とサーバサイド中心の制御
本案件では、自治体DXに相応しい信頼性を担保するため、専門家による手動脆弱性診断を品質ゲートとして設定。
診断結果をフィードバックしながら、以下の多層的なセキュリティ実装を実装しました。
1. JWT検証 ＋ SPIRAL®トークン認証の「二重チェック」
外部サーバ側では、受け取ったJWTの署名検証を行うだけでなく、そのトークンを用いてSPIRAL® APIをオンタイムで再照会する仕組みを構築しました。
「形式上正しいトークンであること」に加えて、「SPIRAL®側の認証状態と整合していること」を確認することで、不正なリクエストを受け付けにくい構成としています。
2. セッションベースの一時ファイル・プロセス管理
処理対象の特定に、クライアント側から推測可能なIDを使用することをやめ、サーバサイドのセッションと紐付いたハッシュ化管理へ移行しました。
インポートファイルなどは推測困難なランダムトークンで管理し、処理後の一時ファイルや管理用DBレコードは速やかに削除します。
また、正常終了・異常終了を問わず後処理が実行されるよう、終了時処理を組み込み、不要なデータが残りにくい設計としました。
3. パラメータ制御による不正操作の抑止
外部サーバに渡す情報は必要最小限に絞り、処理内容の判断はできる限りPHP側で行う構成としました。
やむを得ずパラメータを受け取る場合も、ホワイトリスト形式で許可された値のみを処理対象とし、想定外の値によって処理範囲が広がらないよう制御しています。
4. SPIRAL®に適した手動脆弱性診断
本案件では、専門家による手動脆弱性診断を品質ゲートとして設定しました。
SPIRAL®はシステムとして堅牢である一方、一般的な自動診断だけでは、認証エリア内の画面遷移や外部サーバ連携を含む実際の業務フローまで十分に確認しきれない場面があります。
そのため、自動診断に頼るのではなく、SPIRAL®の仕様や構成を踏まえた手動診断・コード精査を実施。診断結果をフィードバックしながら、外部連携部分の安全性を高めました。
■まとめ：制約は「アイデアと設計」で乗り越える
SaaSの制約にぶつかったときこそ、エンジニアの腕の見せ所です。
「SPIRAL®の認証基盤」×「外部サーバの自由な計算リソース」。この2つを適切なアーキテクチャで繋ぐことで、セキュアかつパワフルなシステムは構築可能です。同じような悩みを持つエンジニアの皆さん、ぜひこの「外部連携」という選択肢を検討してみてください。