リリースから半年が経ったシステムでアカウントの棚卸しをすると、高い確率で出てくる光景があります。開発期間中に権限を渡した委託先のメンバーが、既にプロジェクトを離れているのに、本番環境の管理画面にログインできる状態のまま残っている。悪用された形跡はない。ただ、誰も止めていなかった。
これは委託先の落ち度というより、構造の問題です。権限を渡すのは開発中の一瞬の判断で、止めるのは誰の仕事でもない。 渡すときには「これがないと作業が止まる」という明確な理由がありますが、止めるときには理由を作る人がいません。だから残ります。
常時権限が前提になっている状態
多くの現場では、アクセス権は「その人が担当である限り持ち続けるもの」として設計されています。役割に紐づけて付与し、離任時に外す。考え方としては素直ですが、実際には2つの穴があります。
ひとつは、離任という出来事が誰にも通知されないこと。委託先のメンバー交代は、発注側の管理台帳には反映されません。契約が続いている限り、担当者が入れ替わっても外形上は何も変わらない。
もうひとつは、常時持っている権限の大きさが、実際に使う頻度と釣り合っていないことです。本番データベースを直接参照する必要があるのは、障害調査のときだけかもしれません。年に数回のために、365日アクセスできる状態を維持している。攻撃者から見れば、そのアカウントは1年中ずっと有効な入口です。
サービスアカウントやAPIキーといった「人ではないID」で同じことが起きる話は退職者のアカウントは止めたのにで扱いました。今回は人間のアカウント、特に社外の人間のアカウントの話です。
「持たせておく」から「そのつど渡す」へ — Just-In-Time アクセス
これを反転させる考え方が Just-In-Time アクセス（JITA）です。平常時は誰も本番の権限を持たない。必要になったら申請し、審査を通ったぶんだけ、期限付きで渡される。終われば自動的に消える。
規模の大きな実例として、HubSpot がこの仕組みを再設計した事例が公開されています。同社では1営業日あたり5,500件を超えるアクセス要求が発生し、そのうち約5,100件が承認されています。残りは却下で、理由は「対応するチケットが紐づいていない」「その人の役割の範囲外である」といったものです（HubSpot Redesigns JITA Authorization with Rule Engine Architecture — InfoQ）。
数字の大きさより、却下が一定数出ていることに注目する価値があります。常時権限であれば、この400件はすべて通っていたはずのアクセスです。都度審査にしたことで、根拠のない参照がその場で止まっている。
同社が作り直したのは、判定ロジックの構造そのものです。条件分岐を積み重ねる形から、独立したルールを有向非巡回グラフとして評価する形に変え、どのルールがどう効いてその判断になったかを後から追えるようにしました。アクセス制御が複雑になるほど、「なぜ通ったのか」を説明できることが効いてきます。
中小規模で、どこから始めるか
5,500件を捌く基盤を作る話ではありません。従業員数十人規模の会社が明日から始められることに絞ります。
全部をJITにしようとしないことが最初の分かれ目です。すべての権限を都度申請にすると運用が回らず、結局は形骸化した承認ボタンが1つ増えるだけになります。対象を絞ります。
| 対象 | 常時権限のままでよいか | 理由 |
|---|---|---|
| 本番データベースへの直接接続 | 都度に切り替える | 使用頻度が低く、影響範囲が最大 |
| 決済・課金まわりの管理画面 | 都度に切り替える | 金銭に直結し、参照だけでも機微 |
| 顧客の個人情報を含む管理機能 | 都度に切り替える | 漏えい時の説明責任が重い |
| ステージング環境・ログ閲覧 | 常時でよい | 頻繁に使い、影響が限定的 |
| ソースコードリポジトリ | 常時でよい（離任時に外す運用は必要） | 日常的に使う |
この3つを都度付与に変えるだけで、残ったまま忘れられる権限のうち、最も危ないものが構造的に消えます。
仕組み自体は、既存のツールで足ります。クラウドの IAM に期限付きロールの付与機能があればそれを使う。無ければ、当面は「申請 → 承認 → 付与 → 期限が来たら手で外す」を台帳で回すだけでも、常時権限よりはるかにましです。自動化は後から足せます。都度渡す運用に切り替えることが先です。
発注側が決めておく3つ
委託先が関わる場合、この運用は契約と作業手順の側でも決めておかないと機能しません。
- 誰が承認するのか。 発注側の担当者か、委託先のリーダーか。ここが曖昧だと、実質的に自己承認になります
- どれくらいの期間で切れるのか。 「作業が終わるまで」は期限ではありません。8時間、あるいは1営業日といった具体的な長さを決めます
- 記録は誰が保管し、いつまで残すのか。 誰がいつ何のために本番に入ったかを、後から取引先や監査に説明できる形にしておきます
3番目は、事故が起きたときだけでなく、事故が起きていないことを示すときにも効きます。「本番にアクセスできる人はゼロで、直近3か月の一時付与は7件、すべて障害チケットに紐づいています」と即答できる状態は、それ自体が信用になります。
委託先のビルド環境に長期のトークンが残っている問題はnpmとActionsの対策が示すもの、社内の管理者権限を誰にどこまで渡すかは管理者権限の委任と最小権限で扱っています。
緊急時の抜け道を、先に作っておく
この手の仕組みが崩れるのは、たいてい障害対応の夜中です。承認者が寝ていて権限が下りず、対応が止まる。1度これが起きると、現場は二度と信用せず、恒久的な権限を確保しにいきます。
なので、壊れ方を先に決めておきます。 承認が得られない状況で権限を取得できる非常口を用意し、そのかわり事後に必ずレビューする。使われたら記録が残り、翌営業日に理由を説明する。抜け道を塞ぐのではなく、通ったことが必ず見える抜け道にしておくのが現実的です。
まず確認すること
新しいツールを検討する前に、いま本番環境に入れる人が何人いるかを数えてみるところからで十分です。クラウドの IAM か、管理画面のユーザー一覧を開けば数分で出ます。
その中に、この半年ログインしていない人が混じっていたら、そこが出発点です。使っていないのに持ち続けている権限は、業務上の必要ではなく、単に外す機会がなかったというだけの権限だからです。
委託先を含めたアクセス権の整理、保守契約に落とし込む形での取り決め——そうしたご相談は、グリームハブの開発・AI・自動化のご相談で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
Sources
- HubSpot Redesigns JITA Authorization with Rule Engine Architecture — InfoQ
- Building Observable Access Control at Scale: A Rule Engine Approach to JITA — HubSpot Product Blog
- Just-In-Time (JIT) Access Guide — Netwrix
- Beyond the buzzwords: why JITA, not JITP, delivers true Zero Standing Privilege — SGNL
