世界の技術ニュースをリアルタイムでキャッチし、日本語でわかりやすく発信。AI・半導体・スタートアップから規制動向まで、グローバルテックシーンの「今」をお届けします。

2026-06-27

クラウドの「入ってからも見張る」認可設計がなぜ必要なのか

クラウドのセキュリティというと、多くの人は「ログイン時に本人確認をしっかりやること」を思い浮かべると思います。もちろんそれは大事です。ただ、InfoQ のこの記事が面白いのは、その先にある話を真正面から扱っているところです。つまり、「ログインしたあと、その人が本当にその操作をしていいのか」を毎回見直すべきではないか、という提案です。

この記事の要点

ふつうのクラウドシステムは、認可判断をログイン時に1回だけ行いがち
でも機密データを扱うなら、操作ごとに「今この行動は妥当か」を見たほうが安全
役割ベースの権限管理だけでは、異常な大量アクセスや不自然な行動を止めにくい
Continuous authorization は、操作ごとにリスクを評価する考え方
監査証跡は必要だが、個人情報そのものをむやみに残さない工夫も重要
ただし毎回重く判定すると遅くなるので、キャッシュや段階的な評価が要る
いきなり全社導入ではなく、段階的に広げるのが現実的

この記事の出だしはかなり生々しいです。医療系プラットフォームにアクセスしたカスタマーサポート担当が、朝9時のログイン後、10時には患者記録を5,000件CSVで書き出し、さらにそれが個人メールへ流れていく、という例が出てきます。権限上は「アクセスできた」。でも、その操作が本当にその時点で妥当だったかは別問題だ、というわけです。ここ、セキュリティの現場では本当に厄介なところで、「許可された操作だった」が「安全だった」を全然意味しないんですよね。

この記事が指摘しているのは、RBAC（Role-Based Access Control、役割に応じて権限を割り当てる方式）の限界です。RBAC は「その人の役職ならこのテーブルを読める」「このAPIを叩ける」といった判断は得意です。でも、「今この場所から」「この時間に」「この量を」「このデータに対して」やってよいかまでは、基本的に見ません。たとえばサポート担当が顧客データベースにアクセスできるとしても、実際には“担当中の顧客だけ”を見るべきで、全件検索や大量出力まで許してよいわけではないはずです。

ここで出てくるのが continuous authorization です。日本語で雑に言えば「認可の継続監視」です。認可、つまり「その操作を許すかどうかの判断」をログイン時だけで終わらせず、操作のたびにやり直す発想です。毎回の判定で見るのは、単なる権限ではありません。普段の行動パターン、勤務時間かどうか、端末がいつも使っているものか、場所はどこか、データの機微度はどれくらいか、といった文脈です。

この考え方は、言われてみればかなり筋が通っています。たとえば、ふだんは午前中に社内の管理端末から少数の患者レコードを確認している人が、深夜に海外IPから何千件も引き出し始めたら、それはもう“いつもの業務”ではない可能性が高い。人間なら違和感を覚えるのに、システムはログイン成功だけを見て「はい通りました」で終わることが多い。そこに著者は切り込んでいます。

もちろん、毎回すべてを重くチェックすればいいわけではありません。そんなことをしたら、システムはすぐ遅くなるし、現場は使い物にならなくなります。この記事では、通常の操作と高リスクな操作を分ける設計が大事だとしています。たとえば、普段のパターンに近いアクセスはキャッシュした判断を使い、逸脱があるときだけ深い評価に進める。これなら、リアルタイム性と安全性のバランスを取れる、という考え方です。私はここがかなり現実的だと思いました。セキュリティの議論は「理想的には全部厳密に」が先に立ちがちですが、現場では遅延も運用負荷も無視できません。理屈だけでなく、使い続けられる形に落とし込んでいるのがこの提案の良さです。

さらに面白いのが、監査のための証跡にも触れている点です。規制のある業界では、あとから「誰が何をしたか」を説明できないと困ります。でも、ログに敏感データそのものをべったり残すのは、それ自体が漏えいリスクになる。そこで、実データは露出させずに、監査に足る証拠を残す工夫が必要になるわけです。これは地味ですが、かなり重要です。セキュリティは「守ること」と「記録すること」がしばしば衝突するので、その両立をちゃんと考えているのは好印象でした。

クラウドならではの事情も記事は押さえています。昔のオンプレミス環境では、VPNや社内ネットワーク、管理端末といった“壁”がありました。ところが今は、遠隔勤務の社員、委託先、外部サポートなど、境界の外から同じID基盤で入ってくることが増えています。つまり、ネットワークの内側だから安全、という前提がかなり崩れている。だからこそ、認可側がもっと賢くならないといけない、という流れです。これはゼロトラストの考え方とも相性がいいです。信頼しない前提で、その都度確認する。なんだか性格が悪く聞こえるかもしれませんが、システムとしてはそのほうが健全です。

ただ、こういう仕組みをいきなり全システムに入れるのは無理があります。著者が示すのは、段階的に広げるやり方です。まずは機密性の高い操作だけに適用する。次に、行動のベースライン、つまり「普段はどう動くか」の基準を学習させる。さらに、評価対象を増やしながら、必要なところだけ厳しく見る。いきなり完璧を目指さず、被害が大きい箇所から始めるのが現実的です。こういう“割り切りの設計”は、理論よりも実務に効くと感じます。

個人的には、この手の記事が示すメッセージはかなりシンプルだと思っています。権限管理を「入場券」の発行で終わらせるな、ということです。入場後の振る舞いまで見ないと、今のクラウド時代のデータ漏えいは止めきれない。しかも、ただ厳しくすればいいわけではなく、普段の業務を壊さないバランスも必要。ここが難しいし、だからこそ設計の腕の見せどころでもあります。

セキュリティ対策は派手ではありません。ですが、この記事で扱われている continuous authorization は、事故が起きてから「権限はあったんですけどね」と言う世界を減らすための、かなり筋のいい考え方だと思います。ログイン成功をゴールにしない。その先の行動まで含めて、ようやく“本当の認可”になる。そういう視点を持つだけでも、設計の質はかなり変わるはずです。