最小特権アクセスは、ゼロ・トラスト・アーキテクチャーの中核的な構成要素の1つです。これは、必要最小限のアクセス権を必要な期間だけ付与することを意味します。その他のゼロ・トラストコンポーネントは以下の通り：マイクロセグメンテーション：環境を小さなセキュリティゾーンに分割し、アクセス範囲を制限します。環境のコンパートメントごとに個別のセキュリティ管理策を維持（これらの管理策の分散管理が必要）。多要素認証（MFA）：リソースにアクセスするために 2 つ以上の検証要素を必要とし、現在のリスク状 態に基づいてより高い ID 保証を要求。APIの制御と監視：ユーザーとのインタラクションレベルだけでなく、プログラムレベルでも適切な制御を保証します。いくつの異なるデバイスやAPIがリソースにアクセスしようとしているかを制御します。適応型：コンテキストを認識し、継続的にリスクを評価することで、脅威の早期発見と迅速な対応を可能にします。現在の環境と過去の活動の文脈の中で、現在の状態に動的に対応します。

概要

最小特権は、ゼロトラスト・セキュリティの基本的な考え方であり、必要なアクセスのみを許可するという基本理念がある。当初はネットワーク・セキュリティ戦略の一環として議論されたが、消費可能なリソース（アプリケーション、サービス、データなど）のアプリケーション層にゼロ・トラスト・セキュリティを適用する方がはるかに効果的である。このアプローチにより、特定のリソース・アクセス・ポリシーを、それらにアクセスする人々やプログラムに結びつけることができる。

最小特権の原則

最小特権のセキュリティによって対処するのが最適な脅威の種類は何か？

最小特権アクセスとは、アイデンティティ、人、およびプロセスが、生産的であるために必要な、つまりプログラム上のアクセスの場合は機能的であるために必要な、最小レベルの権限を確実に付与されることに焦点を当てたセキュリティ戦略である。NIST（米国国立標準技術研究所）は、情報セキュリティの入門書 800-12R1の中で、最小特権が扱う共通の懸念事項を指摘しています：

悪意のあるインサイダー： このタイプの脅威は発見が困難なことが多く、有害な活動が数カ月から数年間も気づかれないことがある。内部の悪者は、請負業者、従業員、さらには管理者やあらゆるレベルの管理者である可能性がある。最小特権は、組織に与えるダメージや悪用の範囲を制限するための、主要なセキュリティアプローチである。
悪意ある共謀：これは、2人以上の悪意ある行為者が悪意ある活動を連携させた場合に発生する可能性がある。このタイプの搾取は、通常一個人が行うよりはるかに大きな被害をもたらすことが多い。規制当局や組織がこの種の悪用から守るために職務分離（SoD）を採用しているのはそのためだ。SoDでは、1つのタスクを完了するために複数の人間が必要である。金融サービスの文脈で考えられることが多いが、同じ原則がさまざまな形態の詐欺、妨害行為、窃盗、機密情報の悪用から守ってくれる。
過失のある内部者：悪意はないものの、組織をリスクにさらすようなミスを犯す行為者。不注意な行動には、重要なデジタルサービスを不注意で停止させたり、機密情報をウェブに公開したりする設定ミスが含まれる。この種の事件は日常的にメディアに掲載されている。
侵害された内部者：これは、内部関係者の認証情報が何らかの形で侵害された場合であり、一般的にはフィッシングによって侵害される。アカウントのアクセス範囲が広く、広範囲に及べば及ぶほど、組織に対する潜在的なダメージは大きくなる。そのため、エグゼクティブがターゲットにされることが増えている（捕鯨）。

特権クリープの主な原因は何ですか？

特権のクリープとは、ユーザーが組織内での役割の正当性を超えて資格を蓄積することである。これは通常、時間をかけて徐々に発生し、多くの場合、規制対象情報や機密情報を保護する必要がある組織に影響を及ぼす。個人の役割が変わると、その人の生産性を上げるために権限が迅速に付与されることが多いが、責任が長引く可能性があるため、以前の権限はそのままにされることが多い。最小権限を評価する必要があるリソースの種類には、以下のようなものがある：

コア・アプリケーションとサービス
非構造化データ
システムとプラットフォーム

ある時点で、リーダーシップ・チームは、中核サービスや機密情報への特権的アクセスを管理する必要があることに気づく。セキュリティチームに優先順位をつけ、情報所有者と協力して特権アクセス虎の巻チームを結成するようスポンサーする。プロジェクトは開始され、目標が定義される。アクセス要求と承認を自動化するために新たに設計されたアイデンティティ・ガバナンス環境では、そのメンテナンスは運用に任されている。しかし、自動化されたリクエストと承認であっても、特権のクリープは潜在的なリスクです。

ビジネス・ダイナミクスが定義されたガバナンス・ポリシーから乖離するにつれ、特権のクリープが生じることがよくある。パーミッションのワークフローは、組織が変化し、責任が移動するにつれて拡大する傾向がある。特権クリープの最も一般的な原因には、次のようなものがある：

承認：情報所有者であることが望ましい承認者は、許可要求を正確に評価していない。多忙な承認者は、リクエストしたユーザーが誰で、どんなニーズがあるのかを正確に理解するのに必要な時間をとれないかもしれない。
不適切なレビュープロセス：これは、定期的なレビューの欠如や、アクセス要求の適切性を適切に審査または評価する能力を持たない者によるレビューが含まれる。
リスクの高いユーザー： 組織にとって受け入れがたいリスクをもたらすレベルのエンタイトルメントを長期にわたって蓄積する可能性があるユーザーもいる。これは、ユーザーが一時的に様々なプロジェクトや役割を引き受け、その遂行にエンタイトルメントが必要となり、その後それらのエンタイトルメントが保持されることで発生する。

特権のクリープは、組織がその組織に課せられた様々な力学に適応したり対応したりする上で、ほぼ避けられないものである。しかし、これは組織を部外者から保護するために設計されたゼロ・トラストの重要なテナントに違反しており、事実上あらゆる業界で増え続けている巨額の情報漏洩コストの一因となっている。

特権のクリープを制御する方法

特権のクリープを防ぐ最も難しい側面のひとつは、多くのことに責任を持つレビュアーが他のことに集中している間に、特権のクリープがしばしば時間をかけて起こることです。ある時点で観測できるものではなく、比較的長いスパンで見なければならない。あるアカウントが、検知されることなく、許容できないリスクレベルに変化する可能性があるという微妙な点を認識した上で、どの程度セキュリティ上の懸念をもたらすかは、ユーザー数、ユーザーの変更回数、保護される情報の機密性によって異なる。表計算ソフトでは解決できないセキュリティ上の課題だ。

職務分掌の維持

職務分掌や規制遵守のための企業方針はガバナンス・ルールにうまく反映されるが、リスク基準はより主観的である。最も一般的なものを紹介しよう：

あまりに多くの組織が、脱退プロセスを導入していない。その代わりに、これらの組織は基本的なプラットフォーム・アカウント管理ツールに頼っている。通常、彼らの権限管理は、組織から離れたアカウントを無効にすることに他ならない。リスク管理はこれらの組織にとって最優先事項ではない。
長期間にわたってさまざまな役割を担う、組織全体から選ばれた人物が特権クリープの最有力候補となることは珍しくありません。一般的な使用例としては、点線での報告、さまざまな虎の子のチームでの貢献、異なる部門にまたがるさまざまなプロジェクトへの参加などがある。このような人材に権利を割り当てる際には、生産性を高めるための力があからさまに作用する一方で、セキュリティへの配慮は控えめなことが多い。通常、パーミッションを削除する場面は散在しているが、パーミッションを受けているユーザーを混乱させるのではないかという恐れが、そうしない理由となることが多い。
一般化されすぎた役割は、特権のクリープのもう一つの要因となりうる。ここでは、適切なリクエストに許可を与えることよりも、むしろそれを割り当てるために使用されるロールの過剰な拡張や一般化が問題なのだ。効果的な役割とは、適切に区分され、それぞれが適切なレベルの権限で区別されているものである。パーミッションの適用に使われるロールの定義や一般化が不十分であることはよくある誘惑だ。

リスク・クリープからの保護

レビュアーにとって、時間の経過とともに流れたパーミッションを特定するのはかなり難しい。このような評価には、経時変化の自動分析が役立つ。レビュアーはダッシュボードやレポートでその情報にアクセスできる。組織全体の全ユーザーを評価することは不可能だが、最もリスクの高い上位数十名を効果的にレビューし、吟味することは可能である。

自動生成されるその他のタイプのリスク警告やレポートは、管理されたリソースの分析から導き出される。定期的なレビューが行われていない機密情報を含むリソースには、より高いリスク・スコアが割り当てられる。これらすべてのアラートに対して、今日支配的なガバナンスの革新は、環境全体にわたるリスク領域の特定と強調表示である。

最小限の特権がゼロ・トラストにどのように適合するのか？

最小特権アクセスは、ゼロ・トラスト・アーキテクチャーの核となる構成要素のひとつである。これは、必要最小限のアクセス権を必要最小限の期間だけ与えることを意味する。

その他のゼロ・トラスト・コンポーネントは以下の通り：

マイクロセグメンテーション：環境を小さなセキュリティゾーンに分割し、アクセス範囲を制限する。環境のコンパートメントごとに個別のセキュリティ管理策を維持する（これらの管理策の分散管理が必要）。
多要素認証（MFA）：リソースにアクセスするために 2 つ以上の検証要素を必要とする。現在のリスク状態に基づき、より高い ID 保証を必要とする。
APIの制御と監視：ユーザーとのインタラクションレベルだけでなく、プログラムレベルでも適切な制御を確保する。いくつの異なるデバイスやAPIがリソースにアクセスしようとしているかを制御する。
適応型：コンテキストを意識した継続的なリスク評価 - 脅威の早期発見と迅速な対応が可能。現在の環境と過去の活動の文脈の中で、現在の状態に動的に対応する。