JIT アクセスを管理する

Tenable One Cloud Exposure ユーザー (「管理者」または「JIT 管理者」のロールを持つユーザー) は、アクセスに関する使用資格を管理して、有効なアクセスリクエストのパラメーターを定義し、JIT アクティビティ履歴の監査証跡を表示できます。

注意: これらの機能に関するチュートリアルビデオを見ることもできます。

資格の追加

資格を追加して、有効なアクセスリクエストのパラメーターを定義JIT を利用して特定のクラウドプロバイダーにアクセス権を付与する方法の 例については、一般的な JIT のユースケース。

選択されている場合、[資格] ページには次の 2 つのタブがあります。

  • アカウントの使用資格: アカウントへのアクセスを許可する資格を表示します。
  • AWS SSO アプリケーション利用資格: AWS Identity Center によって管理されるアプリケーションへのアクセスを許可する利用資格を表示します。このタブは AWS でのみ使用できます。

前提条件

  • クラウドサイバーエクスポージャー で使用資格を追加するには、「管理者」または「JIT 管理者」のロールが必要です。
  • 付与Tenableクラウドサービスプロバイダーの関連組織に対する JIT アクセス許可。
注意: IAM Identity Center の委任された管理者アカウント (詳細については AWS のドキュメント を参照) を使用している場合、管理アカウントの範囲に使用資格を追加することはできません。管理アカウントの範囲で以前に追加された資格は、委任されたアカウントの使用に切り替えると無効になり、編集できなくなります。そのような使用資格は、範囲内にある他のアカウントでは引き続き有効です。

使用資格を追加する方法

  1. 左側 アカウント階層とフォルダー ツリーで資格の範囲 (アカウントフォルダー) を選択します。これは、 リクエスト者が 依頼できるアカウントを定義します。
  2. クラウドサイバーエクスポージャー JIT ポータルで、[資格] に移動します。
  3. 選択した範囲が AWS アカウントにある場合は、関連するタブを選択します。
    • アカウントの使用資格: アカウントへのアクセスを許可する資格。
    • AWS SSO アプリケーション利用資格: AWS Identity Center が管理するアプリケーションへのアクセスを許可する資格。
  4. [使用資格の追加] をクリックします。
  5. 使用資格/アクセス 許可の名前を入力します 。この名前はユーザーがアクセスをリクエストしたときに表示されます。
  6. (AWS アカウントのアクセス許可)資格やアクセス許可の ID を入力します。これは一意の識別子として機能し、クラウドプロバイダーコンソールに表示されます。自動生成された ID を使用するか、独自に作成します。ID は小文字で 18 文字以内にする必要があります。
  7. (オプション)リクエスト者がアクセス許可の性質を理解できるように、わかりやすい 説明 を入力します。説明は、リクエスト者が JIT ポータル経由でのアクセスのリクエストする際に、アクセス許可の横にツールチップとしてリクエスト者に表示されます。
  8. リクエスト者が属する 組織 を選択します (JIT に複数の組織が構成されている場合)。
  9. アクセスをリクエストできる ユーザーとグループ ( リクエスト者) を選択します。複数のユーザーやグループを選択できます。
  10. (AWS/Azure/GCP)ユーザーまたはグループがリクエストできる 1 つ以上の アクセス許可 を選択します。

    • AWS アカウントのアクセス許可: 管理ポリシー を手動で選択するか、カスタマーマネージドポリシーを持つもの、またはアクセス許可の境界があるものを除く既存の IAM Identity Center アクセス許可セットを選択します。
      マネージドポリシーを使用する場合は、 インラインポリシー (カスタム JSON) を追加し、ユーザーが上記で選択したアクセス許可に加えて組織固有のアクセス許可を使用してアクセスをリクエストできるようにします。JSON ポリシーは、関連するサイズ制限とともに、標準の AWS IAM ポリシー言語に従う必要があります。

      注意: アクセス許可セットのインラインポリシーは 7,680 文字を超えることはできません。

    • Azure: すべての組み込みロールとカスタムロールはここで利用できます。複数のロールを選択した場合、リクエスト者は、リクエストを送信するときに、定義済みロールのうちどのアクセスをリクエストするかを選択できます。

      注意: サブスクリプションに 所有者ロールを付与 するアクティブなアクセスリクエストが 1 つしかない場合、このアクセスが期限切れになることはなく、取り消すことはできません。
    • GCP: すべての組み込みロールとカスタムロールはここで利用できます。複数のロールを選択した場合、リクエスト者は、リクエストを送信するときに、定義済みロールのうちどのアクセスをリクエストするかを選択できます。

  11. (アイデンティティプロバイダー)選択したユーザーとグループが参加をリクエストできる グループ を選択します。これにより、ユーザーやグループは、そのようなグループを介して付与された必要なアクセス許可を使用できます。

    注意:

    • OneLogin: ロール (グループの代わり)
    • Microsoft Entra ID: ロール割り当て可能なグループと動的グループはリストされません。
  12. ユーザーがアクセスをリクエストできる アカウント (または アプリケーション) を選択します。
    [リクエストごとにアカウント選択を制限する] を有効にすることもできます。これにより、アクセスリクエストを送信する際にリクエスト者が選択できるアカウントの数を制限できます。たとえば、使用資格で 5 つのアカウントを選択した場合、ユーザーはリクエストごとに最大 3 つまで選択できます。
  13. (Azure)使用資格を リソースグループに制限するかどうかを選択します。
    1. アクセスをサブスクリプション全体ではなく特定のリソースグループに制限するには、[リソースグループのみ] にチェックを入れます。
    2. 選択すると、[リソースグループ] ドロップダウンがアクティブになります。ユーザーがこの使用資格をリクエストしたときにアクセスできる 1 つ以上の Azure リソースグループを選択します。 [リクエストごとにアカウントとリソースグループの選択を制限する] を有効にすることもできます。これにより、リクエスト者が 1 つのリクエストで選択できるアカウントとリソースグループの数が制限されます。
    • [リソースグループのみ] が選択されていない場合は、次の点に注意してください。
      • ドロップダウンは無効になっていますが、以前に選択したグループは記憶されます。
      • リクエスト者は引き続きリソースグループへのアクセスをリクエストできますが、リソースグループに限定されるものではありません。
  14. ユーザーまたはグループがリクエストできる 最大期間 (時間単位) (1〜24) を選択します。期間は、アクセスが許可された時間から計算されます。
  15. 承認ワークフローでは、次のいずれかを選択します。
    • 承認は必要ありません。リクエストが行われた後すぐにアクセス権を付与します。
    • 承認が必要です。
  16. 承認を必要とする場合は、プロンプトに従います。
    • リクエストをレビューする 承認者 を 1 人以上選択します。承認リクエストはすべての承認者にメールで送信されます。
      • JIT 用の Slack を有効にしている場合、リクエストは Slack のプライベートメッセージを介して、定義したワークスペースに存在するすべての承認者にも送信されます。
      • JIT 用の Team を有効にしている場合、リクエストは関連する Teams チャネル内にも送信されます。
    • (オプション)承認 レベルを追加 して 複数レベルの承認ワークフローを作成し、アクセスを許可する前に別のユーザーがリクエストを承認する必要があります。
    • (オプション) 追加の通知を送信します。コラボレーションを進めるため、ここに他のユーザーを追加しておくと、メールまたは Slack チャンネルや Teams チャネル (構成されている場合) でそうしたユーザーに通知することもできます。承認者のみがリクエストを承認または拒否できます。追加した クラウドサイバーエクスポージャー Slack チャンネルや、JIT 用の Slack を有効化したときに選択したワークスペースにあるチャンネルはすべて、ここで利用できます。
  17. ユーザーがアクセスをリクエストしたときに 正当性 の入力を要求するかどうかを設定します。
  18. 反 復アクセスを有効にするかどうかを選択します。これにより、リクエスト者はスケジュールされた間隔で自動的に再付与されるアクセスをリクエストできます。
    有効にした場合、[最大反復日数] を設定して、リクエスト者がアクセスをスケジュールできる期間を制限することもできます。これは、反復アクセスリクエストの開始日と終了日の間の最大日数を定義します。たとえば、制限が 30 日で、アクセスリクエストの開始日が 1 月 1 日の場合、リクエスト者は 1 月 31 日までのみ反復アクセスをスケジュールできます。 なお、最大日数は 364 日を超えることはできません。
    デフォルトでは、すべての使用資格の 反復アクセス が有効になり、[反復の最大日数] が 364 に設定されているため、リクエスト者は追加設定を行わなくても反復アクセスを利用できます。
  19. [追加] をクリックします。

Azure 所有者の使用資格

ユーザーが Azure で所有者ロールをリクエストできるようにする資格を追加できます。ただし、Azure では、 すべてのサブスクリプションに常に少なくとも 1 つのアクティブな所有者ロールの割り当てがあることを要求します。そのため、JIT リクエストがサブスクリプションの唯一のアクティブな所有者割り当てである場合、スケジュールされた期間が終了した後でも、割り当てが期限切れになったり取り消されたりすることはありません。このキーは、別の所有者が割り当てられるまで有効です。

たとえば、3 人のユーザー (A、B、C) に 3 時間の間、所有者ロールに割り当てられる資格があるとします。必要な承認はありません。各ユーザーが所有者ロールに割り当てられるタイミングと、アクセス許可が期限切れになるタイミングの内訳を次に示します。

時間 アクション オーナー
8:00 ユーザー A が所有者ロールに割り当てられます。 A
9:00 ユーザー B が所有者ロールに割り当てられます。 A、B
11:00 ユーザー A のアクセス許可の有効期限が切れます。 B
12:00 ユーザー B のアクセス許可は期限切れになりません。他の所有者がいないこと。 B
13:00 ユーザー C が所有者ロールに割り当てられます。ユーザー B のアクセス許可の有効期限が切れます。 C

JIT 経由で付与された所有者ロールのアクセス許可が想定どおりに期限切れになるように、サブスクリプションごとに少なくとも 1 つの恒久的な所有者割り当て (JIT 外部) を持つことをお勧めします。

注意: JIT を介してすべての所有者割り当てをクラウドサイバーエクスポージャー削除する場合は、テナントの Tenable にグローバル管理者 ロールを割り当てることができます。これにより、サブスクリプションの最後の所有者割り当てを削除するために必要なアクセス許可が クラウドサイバーエクスポージャー 付与されます。

使用資格の管理

[資格] ページですべての使用資格を確認して管理できます。

  • テーブルをフィルタリングして 、必要な情報をすばやく見つけます。 たとえば、[アカウント] フィルターを使用して、特定のアカウント、フォルダー、またはアカウント ID の使用資格を表示できます。アカウント名、アカウント ID、フォルダー名でフィルタリングすることで、大きなリストを絞り込み、関連する使用資格を素早く見つけることができます。
  • テーブルの列は、 選択した範囲内のプロバイダーまたは IdP の統合に基づいて変更されます。
  • 列ピッカーを使用して表をカスタマイズし、必要に応じて列を表示または非表示にします。

資格テーブルの列

縦棒 説明
名前 使用資格の名前。
範囲 定義されている場所を簡単に識別するための、資格の完全な組織パス。
組織 資格にリンクされている組織。
プリンシパル アクセスをリクエストできるユーザーまたはグループ
アクセス許可 使用資格によって付与されるアクセス許可。(クラウドプロバイダーのみ)
インラインポリシー 資格に関連付けられているインラインポリシー。(AWS のみ)
アカウント 使用資格の範囲 (アカウントやフォルダーなど)(クラウドプロバイダーのみ)
リソースグループ 資格に含まれる Azure リソースグループ。(Azure のみ)
グループ 資格に含まれる IdP グループ。(IdP のみ)
最大期間 1 回のリクエストに対してアクセスを付与できる最大時間。
承認が必要 その資格に明示的な承認が必要かどうか。(デフォルトでは非表示)
承認者 アクセスリクエストを承認するために割り当てられているユーザー
第 2 レベル/第 3 レベルの承認者 複数レベルの承認ワークフローの追加承認者 (設定されている場合)。(クラウドプロバイダーのみ)
ステータス 使用資格の現在のステータス (アクティブ、非アクティブなど)。
正当性 リクエストを送信する際にリクエスト者が提供した説明。
反復アクセス制限 (日数) 反復アクセスを通じて、アクセスを自動的に付与できる最大日数。反復アクセスが無効になっている場合、このフィールドにはダッシュ (–) が表示されます。
アカウント/リソースグループの制限 資格で定義されている場合、リクエストごとに選択できるアカウント (または Azure ではアカウントとリソースグループを組み合わせたもの) の最大数。(クラウドプロバイダーのみ)

使用資格を管理するには

  1. クラウドサイバーエクスポージャー JIT ポータルで、[資格] に移動します。
  2. 対象の資格に移動し、三点リーダーをクリックして次のいずれかを選択します。
    • 編集します。1 つ以上の資格パラメーターを更新します。
    • 削除します。システムから資格を削除します。
    • 複製します。既存の資格を複製して新しい資格を作成し、そのパラメーターを再利用または変更できるようにします。

複数レベルの承認ワークフロー

アクセスを許可する前に追加の承認段階を必要とする複数レベルの承認ワークフローを作成できます。

資格を追加する際に、アクセスリクエストに対して明示的な承認を必須とすることを選択した場合は、第 2 レベルまたは第 3 レベルの承認者を追加することもできます。最初の承認者 (第 1 レベル) がリクエストを承認すると、第 2 レベルの承認者に通知が送信されます。第 2 承認者はその後リクエストをレビューし、承認や拒否を行うことができます。資格で定義された最終承認者がリクエストを承認した後にのみ、リクエスト者にアクセスが許可されます。

The Eligibilities table, with the second and third level approvers highlighted

  • 最大 3 つの承認レベルを追加できます。
  • 任意の承認レベル内で、1 人以上のユーザーやグループメンバーを承認者として選択できます。1 つのレベルに複数の承認者がいる場合、リクエストを次の承認レベルに進めるには、承認者のうちの 1 人の承認のみ必要です。
  • リクエストが作成されてから 12 時間以内に承認者がリクエストをレビューしなかった場合、そのリクエストは期限切れとなります。複数レベルのワークフローを構成する場合、第 1 レベルの承認者によって承認されたリクエストは、第 2 レベルの承認者によって 12 時間以内にレビューされなければ有効期限が切れます。第 3 レベルの承認者が設定されている場合も、同じロジックが適用されます。

Slack での複数レベルの承認

Slack で JIT が有効になっている場合、複数レベルのワークフローのリクエストや承認は、JIT ポータルに加えて Slack 内でも実行できます。

注意: Slack での複数レベルの承認ワークフローでは、承認者の 承認 / 拒否 ボタンは、( クラウドサイバーエクスポージャー アプリ内の) プライベートメッセージでのみ表示され、追加の通知の送信先として構成した Slack チャンネルには表示されません。

A Slack thread for an access request, showing multi-level approval and access granted

JIT アクティビティの監査

JIT 関連のアクティビティに関する監査証跡情報を、専用の監査ビューで表示します。このビューには、 資格の追加、 アクセスをリクエストする、JIT アクセス許可を持つユーザーがクラウドで実行したアクティビティに関する情報が含まれます。さらに、資格のアクティビティも一般 クラウドサイバーエクスポージャー 監査に送信されます。

現在フィルタリングされている監査証跡の結果を CSV ファイルにエクスポートできます。アクセス許可資格監査イベントテーブルとアクセス許可リクエスト監査イベントテーブルでは、列セレクターを使用して列の可視性をカスタマイズできます。列の設定は、セッション間で保存されます。

アクセス許可資格監査イベントテーブル

列 説明
時刻 アクションが実行された日時。
ユーザー アクションを実行したユーザー (アクセスをリクエストした人やリクエストを承認した人など)。
アクション 実行されたアクション (アクセスのリクエスト、リクエストの承認など)。
リクエスト者 アクセスリクエストを送信したユーザー。
資格 使用されている資格の名前。
アカウント 各資格イベントに関連付けられたアカウント (表示参照とパスなど)。
Azure リソースグループ イベントに関連する Azure リソースグループ。(Azure アカウントのみ)
リソースグループ リクエストで選択された Azure リソースグループ。
アカウントの制限 資格で定義されている場合、リクエストごとに選択できるアカウント (または Azure ではアカウントとリソースグループを組み合わせたもの) の最大数。
アクセス許可 (クラウドプロバイダー) 資格条件で付与されたアクセス許可、またはリクエスト者から要求されたアクセス許可。
[新規] グループ (IdP、デフォルトでは非表示)
期間 アクセスが許可された時間の長さ。
反復アクセス制限 (日数) (デフォルトでは非表示) 反復アクセスを通じて、アクセスを自動的に付与できる最大日数。反復アクセスが無効になっている場合、このフィールドにはダッシュ (–) が表示されます。
正当性 リクエストを送信する際にリクエスト者が提供した説明。
承認が必要 (デフォルトでは非表示) 資格が明示的な承認を必要とするか、リクエストが行われた直後に自動的に承認されるか。
承認者 リクエストの承認に割り当てられたユーザーの一覧
スケジュール時間 アクセス許可リクエストのスケジュールされたアクティブ化時刻。

アクセス許可リクエスト監査イベントテーブル

列 説明
時刻 アクションが実行された日時。
ユーザー アクションを実行したユーザー (アクセスをリクエストした人やリクエストを承認した人など)。
アクション 実行されたアクション (アクセスのリクエスト、リクエストの承認など)。
リクエスト者 アクセスリクエストを送信したユーザー。
資格 使用されている資格の名前。
アカウント 各リクエスト監査イベントに関連付けられているアカウント。
リソースグループ リクエストで選択された Azure リソースグループ。
アカウントの制限 資格で定義されている場合、リクエストごとに選択できるアカウント (または Azure ではアカウントとリソースグループを組み合わせたもの) の最大数。
アクセス許可 (クラウドプロバイダー) 資格条件で付与されたアクセス許可、またはリクエスト者から要求されたアクセス許可。
グループ (IdP、デフォルトでは非表示) 資格で付与された、またはリクエスト者によって要求された IdP グループ。
期間 アクセスが許可された時間の長さ。
反復アクセス制限 (日数) 反復アクセスを通じて、アクセスを自動的に付与できる最大日数。反復アクセスが無効になっている場合、このフィールドにはダッシュ (–) が表示されます。
正当性 リクエストを送信する際にリクエスト者が提供した説明。
承認が必要 資格が明示的な承認を必要とするか、リクエストが行われた直後に自動的に承認されるか。
承認者 リクエストの承認に割り当てられたユーザーの一覧
スケジュール時間 アクセス許可リクエストのスケジュールされたアクティブ化時刻。

JIT アクティビティを監査する方法

  1. クラウドサイバーエクスポージャー JIT ポータルで、[監査] に移動します。
  2. 目的の監査データに応じて、次のいずれかのタブに移動します。
    • アクセスリクエスト
    • 資格
  3. 関連するパラメーターに従ってテーブルをフィルタリングします。

JIT 監査ビデオ

このビデオでは、JIT アクティビティの監査証跡の表示など、JIT アクセスの監査ページの使い方を学習できます。

資格管理 JIT ビデオ

このビデオでは、JIT アクセスで使用資格を追加および管理する方法を説明できます。