For the complete documentation index, see llms.txt. This page is also available as Markdown.

Jira Workflow

Jiraチケットを利用したリクエスト型アクセス管理のためのKeeperボルト連携

概要

Keeper Security for Jiraは、Atlassian Forge上で動作するアプリケーションであり、JiraチケットからKeeperボルトの操作を直接管理できるようにします。本連携により、プロジェクト管理ワークフローとシークレット管理を統合し、Jira環境を離れることなく、認証情報のリクエスト、承認、実行を行えます。

また、本Jira連携では、コンパニオンITSMアプリが作成したチケットを通じて、エンドポイント特権マネージャー (KEPM) の承認およびSSOデバイス管理承認を管理できます。ボルトはNSF (階層型共有サブフォルダ) モードとClassicモードの両方に対応しています。すべての操作は、タイムスタンプおよび実行ユーザー情報付きでJiraのコメントとして記録されます。

レコード管理機能

機能
説明

新規レコード作成

認証情報、セキュアノート、支払いカード、カスタムレコードタイプを追加

レコード更新

既存のボルトレコードの情報を更新

レコード共有

チームおよびユーザーに対するフォルダ単位のアクセス管理

権限管理

共有フォルダ内のレコードに対する詳細なアクセス権を制御

共有フォルダ管理

チームおよびユーザーに対するフォルダ単位のアクセス管理

ボルトはデフォルトでNSFモードです。[従来の権限モデルを使用する] にチェックを入れるとClassicモードに切り替わります。レコードとフォルダのピッカードロップダウンにはNSF/Classicバッジが表示されます。NSFモードではロールベースの権限を、Classicモードでは個別の権限チェックボックスを使用します。ロール一覧とフラグの詳細は、ボルトモードと権限モデルをご参照ください。

エンドポイント特権管理機能

機能
説明

リアルタイム承認ワークフロー

エンドポイントからの特権昇格リクエストを確認し、承認または拒否

リクエストのリアルタイム監視

保留中のリクエストをカウントダウンタイマーおよび詳細情報とともに表示

ワンクリック操作

監査証跡を保持したまま、即時に承認または拒否

リクエスト詳細情報

ユーザー情報、アプリケーション、申請理由、有効期限の状態を表示

要件

Keeperの厳格なゼロ知識暗号化モデルを維持するため、本Jira連携では、お客様環境のVM上でコマンダーサービスモードのコンテナをホストし、Jira Cloud上でカスタマイズされたForgeアプリをホストする必要があります。

要件
説明

Keeperコマンダーサービスモード

REST APIアクセスが可能なコマンダーサービスモードを実行するサービスアカウント。リクエストのルーティングにはNgrokまたはCloudflare Tunnelを使用。

Jira Cloud管理者アクセス

Forgeアプリのインストールおよび設定には、Jira管理者またはManage Apps (アプリを管理) 権限が必要。

Jira設定 → アプリから接続設定を実施。

Jiraエンドユーザーアクセス

Keeperパネルを表示および使用するには、Edit Issues (イシュー編集) およびAdd Comments (コメント追加) 権限が必要。すべてのJira Cloudプロジェクトタイプで動作し、追加設定は不要。詳細についてはこちらのAtlassianのウェブサイトをご参照ください。

Keeper標準機能

ボルトアクセスを含むKeeperビジネス、エンタープライズ、PAMのいずれかのサブスクリプションが必要。

レコードの作成、更新、共有が可能なサービスアカウント権限が必要。

エンドポイント特権マネージャー機能

  • 有効なKeeperPAMサブスクリプションが必要。

  • Keeper環境でKEPMモジュールが有効化および設定済みであること。

  • KEPMのデプロイメント、エージェント、ポリシーが構成済みであること。

  • 詳細については、エンドポイント特権マネージャーの概要ページをご参照ください。

Keeper Security ITSMアプリ

EPMおよびSSOデバイス管理承認ワークフローに必要です。ITSMアプリがWebhook処理とJiraチケット作成を担当し、Connector Hubが検出する `ITSM_` ラベルを付与します。

セットアップおよび構成

JiraサービスとKeeper間で通信を行うには、お客様側でNgrokまたはCloudflare Tunnelを使用したKeeperコマンダーサービスモードのインスタンスをホストする必要があります。構成方法はIT要件に応じて異なります。

コマンダーサービスモードは、任意のマシン上でフォアグラウンドサービスとして実行することも、ローカルまたはリモートサーバー上でDockerコンテナとして実行することも可能です。

手順1. コマンダーのセットアップ

Keeperコマンダーをインストールし、サービスを起動するには、コマンダーサービスモードREST APIのページに記載のセットアップ手順に従ってください。Forgeアプリからコマンダーインスタンスへリクエストを正しくルーティングするため、NgrokまたはCloudflare Tunnelを使用した設定手順を必ず実施してください。コマンダーサービスモードは、CLI上で直接実行することも、ローカルマシンでバックグラウンド実行することも、リモートサーバー上でサービスとして実行することも、Dockerコンテナで実行することも可能です。Dockerの使用を推奨します。

重要事項

以下の点を必ず確認してください。

  1. リクエストキューシステム (API v2) を有効にする必要があります (例: -q=y)

  2. ボルト管理機能を使用する場合は、次のコマンドが許可リストに含まれていることを確認します。

  1. ボルト + SSOデバイス承認 + KEPM機能を使用する場合は、以下のコマンドが許可リストに含まれていることを確認します。

コマンドに関する注意:

  • list-sf: Rotate-on-Expirationフォルダの適格性チェックに必要

  • nsf-*: NSF (階層型共有サブフォルダ) モードに必要。従来型のみのデプロイメントでは省略可

  • epm: KEPM承認パネルの操作およびステータス確認に必要

  • device-approve: SSOデバイス管理承認の操作および保留中リクエストの確認に必要

  1. Ngrokトンネリングを使用する場合は、次のパラメータを含めます。

  1. Cloudflareトンネリングを使用する場合は、次のパラメータを含めます。

サービス作成後、APIキーがコンソール出力に表示されます。必ずコピーして安全に保管します。Dockerを使用している場合は、次のコマンドでログからAPIキーを取得します。

コマンダーサービスが正常に起動していれば、エンドポイントに対して以下のようにcurlリクエストを送信できます。

トンネルが稼働しており、APIキーが正しければ、次のようなレスポンスが返されます。

サービスが正常に稼働していることを確認したら、Jiraの設定手順に進みます。


手順2. Keeper Forgeアプリのインストール

連携設定を行う前に、Jira CloudインスタンスにKeeper Forgeアプリをインストールする必要があります。

詳細な手順については、Forgeアプリのインストールについてのページをご参照ください。


手順3. Jiraの構成

Atlassian Jiraインスタンスで、管理者として連携の構成を行います。

  • Jiraで [Apps] (アプリ) → Keeperに移動します。

  • API URL (/api/v2 パスを含む) およびAPIキーを入力します。

  • URLの例

    • Ngrok: https://your-subdomain.ngrok.io/api/v2

    • Cloudflare: https://your-subdomain.trycloudflare.com/api/v2

  • [Test Connection] (接続をテスト) をクリックし、成功することを確認します。

  • 設定を保存します。

Jira管理者の構成が完了しました。


手順4. EPMおよびデバイス承認のITSMチケット作成

EPMおよびSSOデバイス承認チケットは、コンパニオンKeeper Security ITSMアプリが作成します。Connector HubはEPM Webhookイベントの処理やEPMチケットの作成を行わなくなりました。ForgeアプリからEPM Webhook (ウェブトリガー) およびチケット作成フローは削除されています。

ITSMアプリによる承認フローを構成します。

  1. 同じJiraインスタンスにKeeper Security ITSM連携をインストールおよび構成します。

  2. ITSMアプリでWebhook URLと認証トークンを構成します。

  3. Keeper管理コンソール > [レポートとアラート] > [アラート] で、以下のアラートを構成します。

    • エージェントが承認リクエストを作成 (EPM)

    • 承認リクエストのステータスを変更 (EPM)

    • デバイス管理承認がリクエストされました (SSOデバイス承認)

  4. これらのアラートの受信者として、ITSMアプリのWebhook URLとトークンを追加します。

Keeper管理コンソールのWebhook構成
  1. ITSMアプリは、以下のラベル付きチケットを作成します。

  • ITSM_approval_request_created: EPM特権昇格リクエスト

  • ITSM_device_admin_approval_requested: SSOデバイス承認リクエスト

  1. Connector Hubは、ITSMアプリが作成したチケット上のこれらのラベルを検出し、適切な管理パネルを表示します。


Jiraワークフローのユーザーガイド

  • Jiraプロジェクト (例: IT Support、Security Operations) に移動します。

    • 新しいチケットを作成します。

  • Jira課題ページを開きます。

    • 画面右側のパネルにあるKeeperパネルを確認します。

    • パネルが読み込まれ、利用可能なKeeperアクションが表示されます。

    • アクションを選択します: Request Access to Record / Request Access to Folder / Request Record Permission Change。

    • フォームに必要事項を入力します (必須項目には * が付いています)。

  • ボルトモード

    • パネルはデフォルトでNSFモードです。[従来の権限モデルを使用する] にチェックを入れるとClassicモードに切り替わります。NSFではロールドロップダウン、従来型では権限のチェックボックスを使用します。詳細はボルトモードと権限モデルをご参照ください。

  • 承認のため送信します。

    • 初回送信時は、[Save Request] をクリックして管理者承認へ送信します。

    • 既存のリクエストを更新する場合は、[Update Request] をクリックして保存済みのリクエストを修正します。

    • 送信後、「Request submitted successfully」または「Request updated successfully」という確認メッセージが表示されます。

アクション
使用する場面

個別レコードへのアクセス付与または取り消し。期間限定アクセス、一時的なアクセス、チーム共有に利用。

ユーザーまたはチームに対するフォルダ単位のアクセスおよび権限の管理。一時的なプロジェクト対応や外部委託先へのアクセスに有効。

共有フォルダ内のレコードに対する詳細なアクセス権の管理。最小権限の原則やコンプライアンス要件の徹底に使用。

Create New Secret (管理者のみ)

Keeperボルトに新しいレコードを追加。新規ユーザーのオンボーディングや認証情報のプロビジョニングに最適。

Update Record (管理者のみ)

パスワード、ユーザー名、URL、カスタムフィールドなど既存レコードの情報を更新。認証情報の更新やパスワードローテーションに使用。

Endpoint Privilege Approval (管理者のみ)

エンドポイントからの特権昇格リクエストを確認し、承認または拒否。チケットはITSMアプリが `ITSM_approval_request_created` ラベル付きで作成します。

Device Admin Approval (管理者のみ)

SSOログインデバイス承認リクエストを確認し、承認または拒否。チケットはITSMアプリが `ITSM_device_admin_approval_requested` ラベル付きで作成します。

ボルトモードと権限モデル

共有および権限アクションは2つのボルトモードに対応しています。パネルはデフォルトでNSF (階層型共有サブフォルダ) モードです。[従来の権限モデルを使用する] にチェックを入れると従来型モードに切り替わります。レコードとフォルダのピッカードロップダウンにはNSFまたは従来型バッジが表示され、どちらのモデルが適用されるかを確認できます。2つのモードでは権限の表現方法が異なります。

  • NSFモードでは、権限のセットをまとめたロールeドロップダウンを使用します。

  • 従来型モード では、個別の権限チェックボックスを使用します。

NSFロール

ロール
ユーザーに付与される権限

閲覧者

コンテンツおよび参加者の表示

共有管理者

共有権限の管理、他ユーザーの招待、リクエストの承認

コンテンツ管理者

コンテンツの管理

コンテンツおよび共有管理者

コンテンツおよび共有権限の管理

全管理者

編集、共有、所有権の管理

ロールのルール: アクションが付与の場合はロールが必須です。r取り消すの場合、ロールは任意でフィルターとして機能します。フォルダの削除アクションおよびレコードの所有者 (所有権移転) アクションではロールは無視されます。

従来型権限: 従来型モードでは、各アクションごとに個別の権限チェックボックスが表示されます。

  • レコードへのアクセスをリクエスト: 共有許可、書き込み許可

  • フォルダへのアクセスをリクエスト: レコードの管理、ユーザーの管理、レコードの共有、レコードの編集

  • フォルダ内のレコード権限を更新: レコードの共有、レコードの編集、子フォルダにも適用


レコードへのアクセスをリクエスト

説明: 特定のKeeperレコードに対する共有アクセスをリクエスト

主な機能

  • メールアドレス指定でユーザーへのレコードアクセスを付与または取り消し

  • レコード所有権の移管

  • ボルトモードに応じた権限の設定

    • NSF: ロールを選択 (閲覧者、共有管理者、コンテンツ管理者、コンテンツおよび共有管理者、全管理者)。アクセス付与時は必須

    • 従来型: 共有を許可および/または書き込みを許可にチェック

  • アクセス有効期限の設定 (特定の日時または期間指定)

  • フォルダ内のすべてのレコードに対して権限を再帰的に適用

  • NSFおよび従来型ボルトモードの両方に対応 (ボルトモードと権限モデルを参照)

Request Access to Record

フォルダへのアクセスをリクエスト

説明: ユーザーまたはチームに対するKeeper共有フォルダへのアクセスをリクエスト

主な機能

  • フォルダアクセスの付与または削除 (アクション: 付与 / 削除)

  • 個別ユーザーまたはチームへの割り当て

  • ボルトモードに応じたフォルダ権限の設定

    • NSF: ロールを選択 (閲覧者、共有管理者、コンテンツ管理者、コンテンツおよび共有管理者、全管理者)。アクセス付与時は必須

    • 従来型: レコードの管理、ユーザーの管理、レコードの共有、レコードの編集のいずれかにチェック

  • アクセス有効期限の設定

  • NSFおよび従来型ボルトモードの両方に対応 (ボルトモードと権限モデルを参照)

Request Access to Folder

新しいシークレットの作成

説明: Keeper内に新しいシークレットレコードを直接作成

主な機能

  • 利用可能なレコードタイプ (ログイン情報、銀行口座、SSHキーなど) から選択

  • レコードタイプに応じたフィールドを動的に入力

  • シークレットをKeeperボルトに安全に保存

  • NSFおよび従来型ボルトモードの両方に対応

Jira管理者およびプロジェクト管理者のみ利用可能

Create New Secret - Login type record

レコードの更新

説明: 既存のKeeperレコードを更新

Jira管理者およびプロジェクト管理者のみ利用可能

主な機能

  • ボルト内のレコードを検索して選択

  • レコードフィールド (title、login、password、URL、notes など) を変更

  • 警告を上書きして更新する強制更新オプション

  • NSFおよび従来型ボルトモードの両方に対応

注: Keeperパネルを表示および使用するには、「Edit Issues」(イシュー編集) 権限が必要です。

Update Record

KEPM承認リクエストの管理

説明: Jira上でKeeperエンドポイント特権マネージャー (KEPM) のリクエストを確認し、承認または拒否

EPMチケットは、コンパニオンJira ITSMアプリが ITSM_approval_request_created ラベル付きで作成します。Connector Hubはこのラベルを検出してEPM承認パネルを表示します。ForgeアプリからEPM Webhook (ウェブトリガー) およびチケット作成フローは削除されています。

主な機能

  • リクエスター情報、アプリケーション名、申請理由を含む保留中のリクエストを確認

  • リクエストの自動失効までの残り時間を示すライブカウントダウンタイマー (30分間)

  • 特権昇格またはコマンド実行を承認または拒否

  • Jira外で既に処理済みのリクエストを自動検出

KEPM承認リクエスト

デバイス管理承認リクエストの管理

説明: Jira上でSSOログインデバイス承認リクエストを確認し、承認または拒否

ユーザーが新しいデバイスでSSOログインすると、ITSMアプリが ITSM_device_admin_approval_requested ラベル付きのJiraチケットを作成します。Connector Hubはこのラベルを検出してデバイス承認パネルを表示します。

主な機能

  • リクエスターのメールアドレス、デバイス名、マシン名、IPアドレス、クライアントバージョンを含む保留中のSSOデバイス承認リクエストを表示

  • device-approve --approve / --deny コマンドでデバイス登録を承認または拒否

  • Jira外で既に処理済みのリクエストを自動検出 (例: Keeper管理コンソール経由)

  • デバイス承認は自動失効しません (EPMリクエストとは異なります)

SSOデバイス承認

有効期限切れ時のローテーション (PAM自動ローテーション)

説明: 対象となるPAM認証情報では、期間限定の共有アクセスが失効した時点でパスワードを自動的にローテーションします。一時アクセスのために公開した認証情報が、許可期間の終了後も有効なまま残ることを防ぎます。

表示条件: レコードへのアクセスを申請またはフォルダへのアクセスを申請で有効期限を設定し、対象がローテーション対象の場合、「有効期限後にパスワードをローテーションする」チェックボックスが表示されます。有効にすると、リクエストに --rotate-on-expiration フラグが追加されます。

対象条件:

  • レコード: 選択したレコードが pamUser タイプであること

  • フォルダ: 選択した共有フォルダがROE対象 (ローテーション対象のPAMレコードを含む) であること。パネルは list-sf <uid> --roe-eligible でこれを検証するため、service-create で list-sf コマンドを有効にする必要があります

PAMレコード以外、対象外のフォルダ、有効期限未設定の場合は、チェックボックスは自動的に非表示になります。

主な機能

  • 共有アクセス失効時にPAMパスワードを自動ローテーション (手動対応は不要)

  • 日時指定 (Expire At) および期間指定 (Expire In) の両方の有効期限設定に対応

  • NSFおよび従来型ボルトモードの両方に対応

  • Jiraチケットに記録: アクションコメントに "Password will auto-rotate upon expiration" と記載

Rotate on Expirationは、有効期限付きの共有でのみ利用できます。Expire At または Expire In を設定せずに有効にした場合、リクエストは "Expiration is required when rotate-on-expiration is enabled." というメッセージで拒否されます。

対象は、ローテーションが有効化され、必要な設定が完了しているPAM Userレコードである必要があります。ローテーションが未設定の場合、構成エラーによりリクエストは失敗します。以下を確認してください。

  • レコードが pamUser タイプであることを確認

  • 当該レコードでローテーションが有効であることを確認 (pam rotation edit)

  • Keeperゲートウェイがアクティブで接続されていることを確認

トラブルシューティング

デバッグモード

コマンダーサービスモードREST APIが想定どおりに動作しない場合は、以下のようにデバッグモードを有効にして詳細ログを取得します。

Dockerの場合

デバッグモード有効時の動作

  • コンソールまたはDockerログに詳細なリクエスト/レスポンスのトレースを表示

  • 構成ミスやAPI通信の問題特定に有効

  • 機密情報を含む可能性があるため、本番環境では無効化を推奨

サービスステータスの確認

  1. CLIでコマンダーサービスモードの状態を確認します。

  1. APIの到達性およびステータス確認を確認します。

  • APIエンドポイントを検証してサービス状態を確認します (以下のコマンドを参照)。

  • サーバーが起動しており、Jiraからアクセス可能であることを確認します。

  • ファイアウォール設定でアクセスが許可されていることを確認します。

  1. コマンダーサービスモードを再起動します。

EPMおよびSSOデバイス承認チケットは、コマンダーサービスモードの状態に関係なく、Jira ITSMアプリがWebhookペイロードデータを用いて作成します。Connector Hubはこれらのチケットを作成しません。サービスモードが利用可能になると、承認パネルにKEPM承認ビューおよび device-approve コマンドからのライブステータスが反映されます。

問題の対処

エラー / 症状
原因
推奨される対処方法

Connection Failed / Timeout

コマンダーサービスモードが起動していない、またはトンネルに接続できない

コマンダーサービスモードインスタンスが稼働中でアクセス可能か確認。NgrokまたはCloudflareトンネルが有効で正しいポートを指していることを確認

401 Unauthorized / 403 Forbidden

APIキーが無効または期限切れ

コマンダーサービスモードログから正しいAPIキーを取得し、Jira設定画面で更新。余分な空白や文字が含まれていないか確認

404 Not Found

API URLが誤っている、または不完全

/api/v2 を含む完全なAPI URLを使用 (例 https://xxxxx.ngrok.io/api/v2 または https://xxxxx.mycompany.com/api/v2)。トンネルがコマンダーサービスモードと同じポートに転送していることを確認

502 Bad Gateway / 503 Service Unavailable

コマンダーサービスモードが停止している、または応答していない

コマンダーサービスモードを再起動し、完全に初期化されるまで待機。直近のログで構成や認証エラーを確認

接続成功後も操作が失敗する

必要なコマンド未有効、または権限不足

コマンダーサービスモードで必要なコマンドが有効か確認。操作実行アカウントのKeeperボルト権限を確認

フィードバックや機能のご要望がございましたら、Issueを作成してください。

最終更新