最小権限、JIT、強力な認可について

私はセキュリティの専門職として20年以上働いてきました。「最小権限」という言葉を口にした回数は、数え切れません。それは小さなマントラのようなもので、「多層防御」や「内部脅威」と同じベンチに座っています。

しかし、誰かに最小権限を徹底するよう伝えて部屋を出ていくのは、医師が保険の健康診断であなたを不合格にしながら「もっと健康的な食事を」とだけ告げ、過剰な請求をする前に部屋を出ていくのと同じことです。

最小権限は現実的な手法です。重要です。90日ごとのパスワード変更とは異なり、セキュリティの改善に実質的な効果をもたらします。

最小権限は同時に、非常に難しいものでもあります。特に大規模環境では困難です。そして、最も重要なユーザーには機能しません。

なぜでしょうか。 なぜなら最小権限とは、その時点で必要な最小限の権限ではなく、業務を遂行するうえで「いつか」必要になるかもしれない最小限の権限だからです。そして、権限が最初にマッピングされた時点の範囲を超える作業が必要になると、複数のチームや管理者をまたぐ遅い変更プロセスが始まります。

あるいは、アクセス権をもらうためにBobを説得しなければならないこともあります。しかもBobは誰も信用せず、あなたが失敗したときに責任を問われたくないので、やや防御的で扱いにくい人物です。

最小権限を適用していても、攻撃者がその認証情報を入手すれば（クラウドネイティブ環境における侵害の主要な原因です）、依然として悪意ある行為が可能になる可能性が高いままです。平均的なユーザーや従業員に対して最小権限を実装することはそれほど困難ではないとしても、設計上より多くの権限を必要とする開発者や管理者に対して徹底することは非常に困難だからです。

強力な認証のためにMFAがあるのと同様に、私たちには次のものが必要です。強力な認可です。

ここでジャストインタイム（JIT）が役割を果たします。必要な権限をすべて事前に洗い出そうとするのではなく、任意のタイミングで期限付きの権限を要求できるようにするのです。私は現在、JITこそが管理者アクセスや機密性の高いアクセスの標準であるべきだと考えています。

最小権限は一般ユーザーのアクセスには優れた考え方ですが、クラウドにおける管理者／開発者／機密レベルのアクセスにはJITの方が適していると考えます。

ジャストインタイム

JITはPIM／PAMの一形態です。特権アクセス管理および特権ID管理は、ユーザーの権限を昇格させるために設計されたシステムです。これらは通常は低い権限レベルで動作し、昇格が必要になったときに複数の手法を用いて、多くの場合は時間制限付きのセッションとして拡張アクセスを提供します。細かなニュアンスに立ち入るのは今回の趣旨ではありませんが、その利点はセキュリティを維持しつつ柔軟性を確保できる点にあります。追加の権限が必要なときには要求が必要となるため、認証情報が侵害された場合でも攻撃者の行動は制限されます。

「JIT」（ジャストインタイム）は、PAM／PIM（実際には、あらゆるアクセス）のための手法の一つです。ユーザーは何にもアクセスできないベースの認証情報を持ち、要求に応じて権限が昇格されます。私たち自身もJITを利用しており（Cloud Defenseでも利用可能です）、また Netflixは社内ツールをベースにしたConsoleMeというオープンソースツールを公開しています。AzureにはEntra ID Privileged Identity Managementという組み込みのサービス（ただし追加料金が必要）があります。（Entra IDは、ブランディングのために数百万の顧客を混乱させるのが良い考えだと誰かが判断する前は、Azure ADと呼ばれていたものです。）他にも選択肢はあり、これらは一例にすぎません。

セキュリティを強化するには、JITは帯域外の承認フローを用い、時間制限付きのアクセスを提供する必要があります。これが基本です。要求と承認は、MFAの一形態のように、通常の認証とは異なる経路を通るべきです。違いは、MFAが認証（自分が名乗るとおりの人物であることの証明）のための帯域外の要素であるのに対し、JITは認可（何かを行う許可を要求し、受け取ること）の一形態であるという点です。

摩擦の管理

最小権限もJITも摩擦を生みます。もっとも、セキュリティで行うことはすべて何らかの摩擦を生みます。特にBobは。最小権限における主な摩擦は、権限を定義して展開するためのオーバーヘッドと、必要な権限が与えられていないときに何が動かなくなるかという点です。JITにおける摩擦は、申請して承認を受けるプロセスです。

最小権限とJITの両方を長年にわたって使用し、研究してきた中で、摩擦を減らす手法を学んできました。場合によっては、従来のやり方よりも速く優れたプロセスが実現します

• 要求と承認のフローはリアルタイムである必要があります。つまり、ChatOps、テキストメッセージ、あるいは新型コロナワクチンとともに埋め込まれた5Gチップ経由での承認ということです。
• 一部のログへの読み取りアクセスのような権限の低いアクセスについては、自己承認をサポートできますし、そうすべきです。それがなぜ役に立つのでしょうか。帯域外のプロセスを使うことに変わりはなく、攻撃者が紛失・盗難・流出した認証情報を悪用する余地を減らせるからです。
• 自己承認のためにクリックする必要すらない自動承認をサポートすることもできます。それがなぜ役に立つのでしょうか。自動承認としつつ、帯域外チャネルを使って権限が昇格されたことを通知できるからです。NetflixやHuluでアカウントにデバイスを追加したことがあれば、目にしたことがあるはずです。気づかせるだけでも、驚くほど効果的です。
• 開発者向けであれば、コマンドラインや彼らが使用する他のツールをサポートする必要があります。彼らのところへ出向くのです。極めて使いやすくしてください。セキュリティツールへのログインを強制すれば、そのプロジェクトは失敗します。
• 承認者の反応が即座でなければ、失敗します。Bobを唯一の承認者にしてはいけません。

開発者や管理者が既に使っているツールの中で、この機能を提供してください。速く、摩擦のないものにしてください。理想的には、パスワードマネージャーを開いたり、374個のクラウドアカウントから選ぶSSOポータルをクリックして回ったりするよりも、簡単で速くすることです。Bobにクッキーを買ってあげてください。チョコチップの。（いや待ってください、それは私でした。）

最小権限アクセスの摩擦を減らすために自動化を活用することもできます。Duckbill GroupはChris Farrisの協力のもと、異なる技術を用いて独自の自動化された最小権限の仕組みを実装しました。AWS Access Advisorのようなツールは、使用されている権限を監視し、範囲を絞り込むのに役立ちます。自動化は大規模環境での最小権限の実装を支援し、JITを補完するものにもなり得ます。

どちらをいつ使うか

最小権限は決して過去の概念ではありません。ある程度一貫したレベルのアクセスを必要とする日常的なユーザーや従業員にとっては、依然としてゴールドスタンダードです。JITは、より高い権限を伴うアクセス、特に本番環境へのアクセス、とりわけ認証情報の流出が侵害の最大の原因となっているクラウドにおいて最適です。私たち自身の利用例は次のとおりです。

• 開発者による本番環境への読み取りアクセス。
• 開発者による本番環境への変更アクセス（CI/CD以外）。より多くの承認者を必要とし、はるかに厳しく制限されています。
• 本番アカウントへの管理者アクセス。
• インシデント対応のためのアクセス。
• 一部の開発アカウントへのアクセス。特にコマンドラインで作業している場合、SSOポータルに戻るよりも速いためです。

私はもはや、強力なMFAを使用している場合でも、クラウド（IaaS／PaaS）における相応の特権アクセスに対して最小権限だけで十分な概念だとは考えていません。大規模環境で、時間の経過とともに権限を適切にスコープし続けることは困難すぎます。こうしたユースケースでは、JITの方がはるかに優れた選択肢です。最小権限は、時間を通じて一貫した権限が必要な場合には依然として非常に有効であり、適切なアクセスログとMFAと組み合わせれば特に有効です。JITはMFAの相棒です。それは強力な認証と対をなす強力な認可です。より重要な業務をインターネットに公開された管理プレーンへ移行し続ける中で、JITこそが進むべき道です。