「先月退職した社員のアカウントで、まだデータが見られる状態だった」——機微な情報を扱う受託システムで、こうしたヒヤリとする報告が上がることがあります。原因の多くは、認可（その人がその操作をしてよいか、の確認）をログインの瞬間にしか行っていないことにあります。ログイン時に「この人は管理者だ」と確認したら、あとはセッションが切れるまで再確認しない。だから、ログイン後に権限を剥奪しても、退職処理をしても、すでに開いている画面やセッションでは操作が通ってしまう。認証（本人かどうか）はしっかりしているのに、認可が「入口で一度きり」になっている——これは、機微なシステムで見落とされがちな穴です。
この「入口で一度きり」を改める考え方が、継続的認可（Continuous Authorization）です。InfoQ が 2026 年 6 月に公開した Designing Continuous Authorization for Sensitive Cloud Systems（InfoQ） は、クラウド上の機微なシステムで、操作のたびに認可を確かめ続ける設計を整理しています。本記事では、受託で機微なデータを扱うシステムを作る・引き継ぐときに、認可を「入口で一度」から「操作のたび」へどう移すかを整理します。
なぜ「ログイン時だけの認可」が穴になるのか
ログイン時に権限を確認し、その結果をセッションに焼き付けて使い回す——この設計は、実装が簡単で動作も軽い。問題は、現実には権限がセッションの途中で変わるからです。
第一に、権限の変更が即座に効かない。管理者から一般ユーザーへ降格しても、退職して無効化しても、すでに発行されたセッションには「ログイン時点の権限」が刻まれたまま。変更が反映されるのは、次にログインし直したとき、つまり相手が再ログインを選ぶまでです。
第二に、長く開きっぱなしの画面が危ない。業務システムは、画面を開いたまま放置されることがよくあります。ログイン時の権限で固定されていると、その間に組織変更や退職処理があっても、開いていた画面からは操作が通り続けます。
第三に、「文脈」を一切見ていない。ログイン時の判定は「この人は管理者か」だけを見ます。しかし機微なデータでは、「いつもと違う場所からアクセスしていないか」「この時間帯に大量にダウンロードしていないか」といった文脈も、本来は認可の判断材料になり得ます。入口で一度きりの判定では、こうした途中の異変を捉えられません。
トークンに権限を焼き付けて持ち回ることのリスクは、セッションの持ち方の問題とも重なります。どこに認証情報を保持し、どう失効させるかについては、JWTとセッションの記事で扱った論点がそのまま関わってきます。
継続的認可の基本 — 「操作のたびに確かめる」へ寄せる
継続的認可の考え方はシンプルで、重要な操作のたびに、その時点の権限を確かめ直すことです。ログイン時の判定を信頼し続けるのではなく、操作の直前に「いま、この人はこれをしてよいか」を最新の情報で問い合わせます。
従来（入口で一度きり）:
ログイン → 権限を確認 → セッションに焼き付け
以降の操作 → セッションの権限を信頼（再確認しない）
継続的認可:
ログイン → 認証（本人確認）
重要な操作のたびに → その時点の権限を都度確認
（無効化されていれば即拒否）実装の要は、認可の判断を、アプリのあちこちに散らさず、一か所の「判定する場所」に集約することです。各画面が自前で「この人は管理者だから OK」と判断していると、権限の確認ロジックがコード中に散らばり、ある画面だけ再確認を忘れる、という事故が起きます。判定を一か所に集めれば、「重要な操作の前には、必ずここを通って最新の権限を確かめる」という規律を一律にかけられます。
| 観点 | 入口で一度きり | 継続的認可 |
|---|---|---|
| 権限変更の反映 | 次回ログインまで遅延 | 次の操作で即反映 |
| 退職者の締め出し | 再ログインまで通る | すぐに拒否できる |
| 判定の場所 | 各画面に散在しがち | 一か所に集約 |
| 文脈の考慮 | できない | アクセス状況も判断材料にできる |
注意したいのは、「都度確認」と「毎回重い問い合わせ」は別だということです。すべての操作で権限基盤に問い合わせると遅くなるので、現実には「短い有効期限の判定を、こまめに更新する」「重要度の高い操作だけ厳密に都度確認する」といった、性能と安全のバランスを取る設計をします。すべてを最重要として扱う必要はなく、機微な操作にメリハリを付けるのが実務的です。
受託で導入するときの落とし穴
弊社がセキュリティ改修を引き継いだある人事系の受託システム（社名は伏せます）では、まさに冒頭の事故が起きていました。退職者の無効化処理は人事側で行われていたのに、システムは権限をログイン時に焼き付けていたため、退職者が開きっぱなしにしていた画面から、しばらくの間データが閲覧できる状態だったのです。幸い実害はありませんでしたが、監査で指摘される前に直す必要がありました。
私たちは、全機能を一度に作り替えるのではなく、機微なデータに触れる操作だけを継続的認可の対象にしました。閲覧や編集など「機微な情報を扱う操作」の直前に、その時点の権限を都度確認する関所を一つ設け、無効化されたアカウントはその場で弾く形に。一般的な画面遷移までは厳密化せず、リスクの高い操作に絞ったことで、性能への影響を抑えつつ、退職者が即座に締め出される状態を作れました。やったのは、入口で一度きりだった判定を、機微な操作の手前に移しただけです。
この改修で一番効いた学びは、認可の判定は「許可されている明確な根拠」がないなら拒否する、を既定にすることでした。判定する場所に問い合わせて答えが曖昧だったとき、「とりあえず通す」設計にすると、基盤が一時的に応答しないだけで全員が管理者並みに通ってしまいかねません。逆に「根拠がなければ拒否」を既定にすれば、最悪でも「使えない」で止まり、データが漏れる側には倒れません。API の境界で権限チェックを取りこぼす危うさについては、APIゲートウェイの認可バイパスの記事で扱った事例が、入口の検査がいかに抜けやすいかを示しています。
もう一つの落とし穴は、認証の強化と混同しないことです。継続的認可は「この人がこれをしてよいか」を確かめ続ける仕組みで、「本人かどうか」を強くするパスキーなどの認証強化とは役割が違います。両者は補い合う関係で、認証をパスキーで固め、認可を継続的に確かめる、と組み合わせると効果的です。認証の側面については、パスキー移行の記事が参考になります。
どこから着手するか
機微なデータを扱うシステムで、認可がログイン時に固定されているなら、まずは「最も守りたい操作」から継続的認可に寄せる価値があります。全機能を一気に作り替える必要はありません。
最初の一歩としては、システムの中で「ここから漏れたら最も困る」操作を一つ特定し、その直前に、その時点の権限を都度確認する関所を一つ設けること。そして、その判定を「根拠がなければ拒否」を既定にしておくこと。これだけで、退職者や降格されたユーザーが、開きっぱなしの画面から機微な操作を続けられる、という最悪の穴を一つ塞げます。効果を確かめながら、対象とする操作の範囲を段階的に広げれば、性能への影響も抑えられます。
退職者のアカウントが残っていないか不安、権限を変えても即座に反映されない、機微なデータを扱うのに認可が入口で一度きりになっている——そうしたお悩みがあれば、グリームハブのお問い合わせからご相談ください。現行システムの認可の仕組みを拝見し、機微な操作から継続的認可へ段階的に寄せる設計を、性能とのバランスを見ながらご一緒に組みます。
