クラウドおよびアイデンティティプラットフォームにおけ
特権アカウントは、攻撃者にとって格好の招待状のようなもので、盗むべき認証情報と、悪用できる権限の宝庫です。 管理者権限が使用されているかどうかにかかわらず永続的にアクティブな状態にある場合、特権アカウントは攻撃対象領域を大幅に拡大させることになります。 ゼロスタンディング特権 (ZSP) は、どのユーザーも常時昇格されたアクセス権を持たないようにすることで、そのリスクを大幅に軽減します。 永続的な特権の代わりに、特定のタスクに対して特権がリクエストされたら、定められた承認のワークフローを通じて、限られた期間だけ特権が付与され、承認された期間が終了すると自動的に取り消されます。 ZSPは、常時アクセスを一時アクセスに置き換えることで、攻撃者が悪用できる要素を減らして、近年のセキュリティにおけるより大きなトレンドを体現しています。 Keeperは、ジャストインタイム (JIT) アクセスを付与し、承認された期間の期限が切れると自動的にアクセスを取り消すことで、ZSPを強制します。これにより、ユーザーは権限ゼロの状態から、必要最小限の正確なアクセス権を得て、再び自動的に権限ゼロの状態へと戻ります。
以下では、ZSPの重要性やKeeperにおける仕組み、さらにKeeperが各環境でどのようにZSPを強制しているのかをご紹介します。
スタンディング特権がセキュリティリスクである理由
無期限でアクティブな状態が続く特権アカウントは、攻撃者に長期的な標的を提供してしまいます。認証情報は期限切れにならず、いつでもアクセスし放題であり、その権限が取り消されることもありません。 攻撃者がこれらのアカウントを乗っ取ったり、認証情報を盗み出すと、そのアカウントが保持するすべてのスタンディング特権がそのまま悪用されてしまいます。
より深刻なのは被害の及ぶ範囲です。常時アクセス可能なアカウントが侵害された場合、その影響は本来の対象システムだけにとどまるということはまずありません。 攻撃者は永続的な特権を足がかりにして横展開し、その経路上にあるサーバーやデータベース、クラウドリソースへとターゲットを次々に広げていきます。 たった1つの認証情報の漏洩であっても、ユーザーに常時アクセス権があれば、瞬く間にインフラ全体を乗っ取る足がかりとなってしまいます。 特権が永続的である場合、アクセスは特定のリクエストやタスク、時間枠に関連付けられていないため、ある瞬間に「なぜ、その人がシステムにアクセスできたのか」という明確な履歴が残りません。 そのような曖昧さがあるため、永続的な特権に関わるセキュリティインシデントの調査やコンプライアンスの立証が、より一層困難になります。
Keeperでゼロスタンディング特権が機能する仕組み
Keeperは、Keeper特権クラウドを通じてZSPの強制を徹底しています。ZSPにより、KeeperPAMのJITアクセスワークフレームがIDプロバイダや連携されているアプリケーションへと拡張されます。 Keeper特権クラウドは、恒久的な管理者権限を付与する代わりに、リクエストがあった場合のみ、承認された期間内に限り、そして自社で定義したワークフローの設定においてのみ、昇格されたアクセス権を付与します。 ユーザーはデフォルトで権限を持たない状態から、管理・監査可能な手順を通じて権限を昇格させ、タスクが完了すると再び権限ゼロの状態に戻ります。 KeeperにおけるZSPの実際の仕組みを以下に解説します。
アクセスポリシーの設定
PAMクラウドのレコード上で、管理者はJITおよびワークフローの設定を使用して、運用ルールを定義します。 これには、リクエストに承認が必要かどうか、誰がそれを承認できるのか、一度付与されたアクセス権の有効期間はどれくらいか、そしてユーザーがどのロールに昇格されるかなどが含まれます。 これらの設定により、特権アクセスのリクエスト・承認プロセスや有効期限を細かくコントロールできるようになり、管理者が設定した範囲を超えた特権昇格が行われないようにできます。

許可されたユーザーとレコードを共有
ポリシーが設定されると、アクセスをリクエストする権限のあるユーザーに、そのPAMクラウドのレコードが共有されます。 権限昇格はIDプロバイダを介して行われるため、各ユーザーはIDプロバイダとKeeperテナントの両方にアカウントが必要です。 そのレコードを共有されたユーザーは、タスクで必要になった際に昇格されたアクセス権をリクエストできるようになりますが、それまでの間は一切の永続的な特権を保持しません。
リクエストの確認と承認
ユーザーがアクセスを必要とする場合、自身のKeeperボルトまたはKeeperコマンダーCLIから直接アクセスをリクエストできます。 指定されている承認者は、Slack、Teams、Jira、ServiceNowなどのツールからリアルタイムで通知を受け取り、あらゆるKeeperクライアントからリクエストの承認または拒否を行えるため、デスクに戻ってリクエストを承認しなければならないという状況を避けられます。 ポリシーによっては、承認者はアクセスを付与する前に正当な理由とチケット番号を義務付け、すべての権限昇格の理由を文書に残すことができます。

アクセスの自動付与と自動取り消し
リクエストが承認されると、KeeperゲートウェイはIDプロバイダまたはターゲットリソース上で権限昇格を実行し、ユーザーに設定されたグループメンバーシップ、ロール、または権限を付与することで、ポリシーで許可されたアクセス権を取得できるようにします。 承認された有効期限が切れると、Keeperゲートウェイはそのアクセス権を自動的に取り消し、一時的なメンバーシップや割り当てを解除して、ユーザーをZSPの状態に戻します。 また、アクセスがリクエストされたすべての権限昇格を記録し、誰が承認したか、いつ開始され終了したかも記録されます。これにより、セキュリティチームとコンプライアンスチームは、特権アクセスがどのように付与され、使用されたかについて、リクエスト単位で明確な監査証跡を得ることができます。
Keeperがゼロスタンディング特権を強制する場所
Keeperは、ZSPをひとつのシステムやアカウントタイプに限定しません。 このJITフレームワークは、ユーザーが認証を行うIDプロバイダだけでなく、その背後にあるクラウドリソース、データベース、サーバーマシンなど、環境内のあらゆる特権アクセスが存在する場所に適用可能です。
各種IDプロバイダ全体にわたって
Keeper特権クラウドは、AWS IAM、Microsoft Entra ID、Google Identity経由のGoogle Cloud、Okta、Active Directoryなど、既存のIDプロバイダ全体にわたって、JITアクセスを拡張します。 Keeperは、既存のインフラストラクチャ内で直接、特権の付与と取り消しを行うため、ユーザーの認証方法を妨げることなく、アカウントがすでに存在する場所でそのまま権限昇格を行います。 IDプロバイダがユーザー情報の信頼できる情報源としての役割を維持しつつ、Keeperはいつユーザーを特権グループに昇格させ、いつそこから外すのかという制御のみを担います。
その適用範囲はプラットフォーム自体にとどまらず、これらのIDプロバイダを介してアクセスと認可を連携させるアプリケーションにも及びます。 ID連携アプリケーションもアクセス制御にKeeperを利用できるため、ユーザーはチームが日常的にサインインする下流のアプリに対しても、同様のJITモデルを適用できます。
クラウド環境、データベース、サーバーマシン全体にわたって
ZSPはクラウドコンソールだけの問題ではないため、KeeperPAMはIDプロバイダの枠を超えて、同じ特権昇格フレームワークを適用します。 PAMクラウド、PAMデータベース、PAMマシンのレコードを使用することで、クラウドリソース、データベース、個々のマシンに時間制限付きアクセスを拡張し、IDレイヤーの背後にあるインフラストラクチャにも同じライフサイクルをもたらすことができます。
権限昇格に加えて、Keeperゲートウェイは特権認証情報をローテーションすることで、固定された対象として残らないようにします。また、データベースとマシンに対しては一時アカウントをプロビジョニングし、サーバー側で認証情報を注入するため、ユーザーが直接、認証情報を扱うことはありません。 すべてのデータがKeeperのゼロ知識アーキテクチャ内に収められているため、認証情報やシークレットはエンドツーエンドで暗号化されたまま保護され、Keeperや他の第三者に露出されることはありません。 自動ローテーションとゼロ知識が一体となることで、特権アクセスを可能にする認証情報であっても、攻撃者が盗み出して悪用できるような形で永続的に残存しないことが保証されます。
Keeperで攻撃対象領域を最小限に抑える
ゼロスタンディング特権は、一貫して強制されてこそ効果を発揮します。そこで活躍するのがKeeper特権クラウドです。 Keeperを使用することで、セキュリティチームは、現在稼働しているIDプロバイダやインフラを通じて、必要に応じて特権アクセスを付与し、自動的に取り消すための監査可能な方法を利用できます。 管理者は、誰が何に、いつアクセスできるかを証明可能な形で制御できるようになり、ユーザーは、手動でのプロビジョニングを待ったり、不要な権限を保持し続けたりすることなく、必要なアクセス権を取得できます。
KeeperPAMのデモをお申し込みください。お客様の環境で、JITアクセスとアクセス権の自動取り消しがどのように機能するかをご確認いただけます。
よくある質問
ゼロスタンディング特権は、最小権限とどのように違うのでしょうか?
最小権限は、ユーザーのロールに必要な最低限の権限だけにアクセス範囲を絞りますが、その権限は基本的にずっと与えられたままで常時保持しているままのため、実際に使用されているかどうかにかかわらずアクティブな状態が続きます。これに対し、ゼロスタンディング特権 (ZSP) は、最小権限の考え方をさらに一歩進め、デフォルトのアクセス権を一切なくし、権限は必要なときにリクエストされ、承認された場合にのみ一時的に付与され、タスクが完了すると即座に取り消されます。簡単に言えば、最小権限がユーザーのアクセス範囲を制限するのに対し、ZSPは権限を保持する期間を極限まで削り、必要になるまでアクセス権を一切持たない、権限ゼロの状態にします。詳細については、ブログ記事「ゼロスタンディング特権と最小権限の比較」をご覧ください。
KeeperはどのIDプロバイダに対応していますか?
Keeper特権クラウドは、AWS IAM、Microsoft Entra ID、Google Identity経由のGoogle Cloud、Okta、Active DirectoryにわたってJITアクセスを強制します。 これらのプラットフォームを通じてアクセスと認可を連携するアプリケーションも、アクセス制御にKeeperを利用できるため、同じJITモデルがIDプロバイダに接続されている他のアプリにも拡張されます。
承認後、ユーザーはどのようにリソースにアクセスしますか?
アクセスリクエストが承認されると、ユーザーは安全なブラウザベースのセッションのためにKeeperのリモートブラウザ分離 (RBI)を経由してリソースにアクセスするか、AWSアクセスポータルやAWS CLIなどの既存のワークフローを引き続き使用できます。いずれの場合も、アクセスは必要と認められた期間に限られ、承認された時間枠が終了すると自動的に取り消されます。