常設管理者アクセスをジャストインタイムアクセスに変換する

必要なライセンス: このプレイブックには、JIT とオンデマンドの最小権限の推奨事項の両方を含む ライセンス別機能比較 が必要です。JIT ライセンスだけでは、最小権限の推奨は含まれていません。

目的
常時の管理者アクセス権を持つユーザーは、恒久的なターゲットです。認証情報が漏洩すると、攻撃者はいつでも管理者になります。このプレイブックでは、ユーザーがそのアクセスで実際に何をするかを測定し、リクエストに応じて正確にそれを付与する JIT 使用資格を構築し、スタンディング割り当てを削除する方法を示します。

一度に 1 人のユーザーに対して実行します。[過剰なアクセス許可] ページで、管理者アクセスがアクセス許可の深刻度が [重大] と表示されているユーザーから開始します。

前提条件

始める前に

  • Tenable One Cloud Exposure で管理者ロールがあることを確認します。最小権限ポリシーの生成には 、コラボレータ または 管理者が必要です。使用資格の追加には、 管理者 または JIT 管理者が必要です。
  • 関連するクラウドプロバイダーに対して Tenable JIT アクセス許可を付与する されていることを確認してください。
  • ユーザーが SSO 経由で JIT ポータルにログインできることを確認します。
    • AWS: JIT for AWS は Identity Center ユーザーおよびグループにのみアクセス権を付与するため、ユーザーが IAM Identity Center ユーザーであることを確認してください。常任管理者が IAM ユーザーの場合は、開始する前にユーザーを Identity Center に移動します。
警告: JIT の使用資格が機能することを確認するまで、スタンディングアサインメントを削除しないでください。最初に取り消すと、ユーザーはまだ行う必要がある作業からロックされます。

ステップ 1: 使用状況の決定

クラウドサイバーエクスポージャーは、アクセス許可使用のラーニング期間 (デフォルトでは 90 日) 中使用されなかった場合、過剰なアクセス許可としてマークします。その計算の背後にある使用状況データは、JIT アクセス許可の基礎となります。

ユーザーの使用状況を確認する方法

  1. クラウドサイバーエクスポージャーコンソールで、[過剰なアクセス許可のリスク>] に移動します。
  2. 関連するユーザーについてテーブルをフィルタリングし、[Services] ( サービス ) と [Resources] (リソース) 列を確認します。これらは、ユーザーがアクセスできるもののまだ使用していないサービスとリソースの数を示します。
  3. ユーザーをドリルダウンして、使用済みと未使用のアクセス許可、およびアクセス許可のマッピングを確認します。
  4. ユーザーが学習期間よりも頻度が低いタスク (たとえば四半期決算や年次キーローテーションなど) を書き留めます。使用状況データはこれらをキャプチャしないため、 アクセス許可セットを生成するときに手動で追加する必要があります。

ステップ 2: 最小権限のアクセス許可セットを生成する

ユーザーの実際のアクティビティから 最小権限ポリシーの生成とロール ポリシーまたはカスタムロールを生成します。これは、ユーザーが JIT を通じてリクエストするアクセス許可になります。

アクセス許可セットを生成する方法

  1. クラウドサイバーエクスポージャーで、[IAM > Identity Intelligence >調査] に移動します。
  2. 関連するアイデンティティを見つけて、次のいずれかを実行します。
    • AWS: 三点リーダーメニューをクリックし、[最小権限ポリシーの生成] を選択します。ワイ ルドカードではなく特定のリソースを使用する (サポートされている AWS サービスのみ) をクリアします。特定のリソースによりポリシーは大きくなり、ポリシーは資格の インラインポリシー制限に収まる必要があります。
    • Azure: Microsoft Entra ID ユーザーの [カスタムロールの生成] をクリックします。ユーザーがアクセスを必要とする場所に一致する 範囲レベル (管理グループ、サブスクリプション、またはリソース グループ) を選択します。
    • GCP: [Google Workspace ユーザーの カスタムロールの生成] をクリックします。ユーザーがアクセスする必要がある場所に一致する 範囲レベル (組織、フォルダー、またはプロジェクト) を選択します。
  3. ユーザーの作業サイクル全体をカバーする学習期間 (Azure と GCP の場合はタイムフレーム ) を設定します。少なくとも 90 日間のデフォルトを使用します。
  4. ユーザーがグループを介して管理者アクセス権を取得した場合は、 [グループ メンバーシップ経由で付与されたアクセス許可を含める] を選択します。
  5. [生成] をクリックし、結果をコピーします。
  6. 以前に書き留めた頻度の低いタスクを追加します。
  7. (Azure および GCP のみ): 生成された定義からクラウドプロバイダーのカスタムロールを作成します。JIT の使用資格には、すべてのビルトインロールとカスタムロールがリストされるため、資格が作成される前にロールが存在している必要があります。
注意: AWS: 生成されたポリシーがAWSの最大ポリシーサイズを超える場合、 クラウドサイバーエクスポージャー はポリシーを複数のポリシーに分割します。数字は JSON ポリシーアイコンの横の括弧内に表示されます。

ステップ 3: アクセス許可セットの JIT 使用資格の作成

資格 は、 誰が、どのアカウントに対して、どのくらいの期間、誰の承認を得て、アクセス許可セットをリクエストできるかを定義します。

使用資格を作成するには:

  1. JIT ポータルで、ユーザーが必要とするアカウントを含む範囲を選択します。
  2. [資格] に移動し、[資格の追加] をクリックします。
  3. タスクを説明する [名前] (Name Prod DB Adminなど) を入力します。リクエスト者にはこの名前が表示されます。
  4. [ユーザーとグループ] で、ユーザーを選択します。
  5. [アクセス許可] で、 先ほど生成したアクセス許可セットを追加します。
    • AWS: 生成されたポリシーを [インラインポリシーの追加] に貼り付けます。インラインポリシーは 7,680 文字を超えることはできません。
    • Azure: カスタムロールを選択します。サブスクリプション以下のアクセスを制限するには、 [リソース グループのみ] を選択し、リソース グループを選択します。
    • GCP: カスタムロールを選択します。
  6. [アカウント] で、ユーザーが常時の管理者アクセス権を持っているアカウントのみを選択します。各リクエストをさらに制限するには、[リクエストごとのアカウント選択を制限する] を有効にします。
  7. [最大期間] は 、一般的なタスクをカバーする最短の期間に設定します。範囲は1〜24時間です。
  8. 承認 ワークフロー で、 承認が必要 を選択し、1 人以上の 承認者を選択します。管理者レベルのアクセスの場合、第 2 承認レベルの追加を検討してください。
  9. 正当性と判断を有効にします。
  10. [反復アクセス] で [無効] を選択するか、低く [反復日数の最大日数] の値を設定します。反復アクセスはデフォルトで最大 364 日間有効になっており、1 年間のスケジュールされた再付与はスタンディングアクセスとよく似ています。
  11. [Add] (追加) をクリックします。

ステップ 4: 資格が機能することを確認する

スタンディングアクセスが有効な状態でユーザーに使用資格をテストしてもらいます。

資格を確認するには:

  1. ユーザーに、JIT ポータル、Slack、または Teams を通じて アクセスをリクエストする し、付与されたアクセス許可で実際のタスクを 1 つ実行するように依頼します。テストを意味のあるものにするには、ユーザーはスタンディングアクセスではなく、JIT で付与された割り当てを通じてサインインする必要があります。
  2. タスクが失敗した場合は、不足しているアクセス許可を資格に追加してテストを繰り返します。
  3. JIT ポータルで、[Audit > Access Requests] (アクセスリクエストの監査) に移動し、リクエスト、承認、期間が想定どおりに表示されることを確認します。

ステップ 5: スタンディング アクセスを取り外す

クラウドプロバイダーのスタンディング割り当てを削除します。ユーザーに適した終了状態を選択します。

  • オプションA:スタンディングアクセスはゼロです。 すべてのスタンディング割り当てを削除します。JIT リクエストが承認されるまで、ユーザーはアカウントにアクセスできません。
  • オプション B: 読み取り専用ベースライン。 管理者の割り当てを、読み取り専用ロール ( ReadOnlyAccess、Azure Reader、GCP Viewer などAWS) に置き換えます。ユーザーは日常業務の可視性を維持し、変更があれば JIT にリクエストします。
注意: [過剰なアクセス許可] ページからのワンクリック修正は、どちらの終了状態にも達しません。ユーザーのポリシーを、使用済みのアクセス許可から構築された最小権限ポリシーに置き換えるため、ユーザーが実行した管理者アクションは維持されます。

スタンディングアクセスを削除するには:

  • AWS: IAM Identity Center で、管理者アクセス許可セットに対するユーザーのアカウント割り当てを削除します。ユーザーがグループを通じてアクセス許可セットを取得した場合は、そのユーザーをグループから削除します。グループの割り当てを変更しないでください (他のメンバーは引き続きその割り当てに依存しています)。オプション B では、読み取り専用のアクセス許可セットを割り当てます。
  • Azure: サブスクリプションまたはリソースグループでのユーザーのロール割り当てを削除します。オプション B では、同じスコープで Reader を割り当てます。
  • GCP: 組織、フォルダー、またはプロジェクトにおけるユーザーの IAM バインディングを削除します。オプション B では、同じレベルの Viewer を付与します。
警告: Azure: Azure では、すべてのサブスクリプションに少なくとも 1 人のアクティブな所有者を保持する必要があります。ユーザーが最後の恒久的な所有者である場合は、ユーザーを削除する前に (JIT 外部の) 恒久的な所有者を割り当てます。それ以外の場合、唯一の所有者になる JIT で付与された所有者の割り当ては期限切れになりません。詳細については 、「FAQ: JIT」 を参照してください。

ステップ 6: 結果を確認する

結果を確認する方法

  1. クラウドサイバーエクスポージャーコンソールで、[Risks > Excessive Permissions] (過剰なアクセス許可のリスク) に移動し、ユーザーが管理者レベルの過剰なアクセス許可で表示されなくなったことを確認します。ユーザーの過剰な権限の検出結果は、次の同期後にクローズされます。
  2. JIT ポータルで、2 週間後のユーザーの >アクセスリクエストの監査 を確認します。最大期間に達する要求が頻繁に発生する場合は、期間が短すぎるか、ユーザーの作業に別の資格が必要であることを意味します。リクエストが発生しない場合、そのユーザーはそのアクセス権がまったく必要ない場合があり、ユーザーはその資格を削除できます。