はじめに

社内情シスの業務の中でも、特に慎重な対応が求められるのが次のような作業です。

新任インフラエンジニアやシステム管理者のオンボーディング対応
エンドユーザーのパスワードリセット処理の自動化

これらは「作って終わり」ではなく、パスワードポリシーやローテーション、配布方法まで含めて正しく運用する必要があります。とはいえ、毎回 UI をポチポチ操作して設定していると、時間もかかるしミスも起こりがちです。

KeeperPAM（特権アクセス管理）と Keeperコマンダー（CLI ツール）の自動化コマンド credential-provision を組み合わせると、こうした特権アカウントのパスワード管理と配布を 1 つの YAML ファイルと 1 コマンド に集約できます。

本記事では、主に社内情シスの方向けに：

credential-provision コマンドがどんな処理を自動化してくれるのか
YAML ファイルに何を書けばいいのか
パスワードローテーションをどう設計・運用すればよいか
テンプレート化して「新任管理者オンボーディング」を楽にする方法

本記事の内容は筆者個人の見解であり、所属する組織の意見を代表するものではありません。

`credential-provision` は「特権アカウント用」の自動化コマンド

最初に整理しておきたいポイントは、credential-provision は 既に存在する PAMユーザー（特権アカウント／管理用アカウント）のパスワード管理と安全な配布を自動化するためのコマンド だということです。

一般ユーザーの Keeper アカウントや、全社員の通常アカウントを作成する用途ではありません。
Microsoft Entra ID 側のユーザーアカウント作成は別のプロビジョニングで行う必要があり、credential-provision は「既に存在するアカウントのパスワード管理と配布」を自動化するためのコマンドです。

この記事では、次のようなシナリオを想定します。

「新任のシステム管理者に対して、すでに Entra ID 側で作成済みの Microsoft Entra ID ユーザー（特権ロール付きアカウント）の資格情報を Keeper 側で安全に管理し、その後も自動ローテーションする」

`credential-provision` が自動化してくれること

credential-provision を 1 回実行すると、裏側ではおおよそ次の処理が実行されます。

PAMユーザーの重複チェック
パスワード生成
PAMユーザーレコード作成
ローテーション設定
即時ローテーション
ワンタイム共有 URL の生成
メール送信

本来であれば、これらを UI・スクリプト・メールなど複数の手段でバラバラに実施する必要がありますが、credential-provision によって、

「特権アカウントのパスワード管理〜ローテーション設定〜安全な配布」

を 1 つのワークフローとして扱えるようになります。

利用前に必要な前提

credential-provision を利用するには、あらかじめ以下が準備されている必要があります。

KeeperPAM の有効なライセンス
対象システム（AD / Entra ID / AWS / GCP 等）向けの PAM 構成
対象となる Microsoft Entra ID ユーザーアカウントが、あらかじめ Entra ID 側で作成済みであること（credential-provision ではアカウント自体は作成しない）
対象にパスワードローテーションを実行できる Keeperゲートウェイ
メール送信用の メール構成（SMTP / SendGrid / SES / OAuth 等）

すでに KeeperPAM を使ってパスワードローテーションを回している環境であれば、ほとんどの前提は整っているはずです。そこに credential-provision を追加するイメージです。

YAML で定義する 5 つのブロック

credential-provision は、指定した YAML ファイルを読み取り、その内容に従って特権アカウントを発行します。

YAML は大きく次の 5 つのブロックで考えると理解しやすくなります。

user
特権アカウントを渡す「人」（新任管理者）の情報
account
ターゲットシステム上のアカウント情報（Microsoft Entra ID ユーザーアカウントなど）
vault
Keeperボルト上で PAMユーザーレコードを保存する場所
pam
パスワードローテーションのポリシー
email
メール送信と共有リンクのパラメータ

この 5 ブロックを 1 ファイルにまとめることで、「誰に」「どの特権アカウントを」「どのポリシーで」「どう渡すか」を一元的に定義できます。

YAML サンプル（Microsoft Entra ID ユーザー）

ここでは、Microsoft Entra ID 環境の例として、すでに Entra ID 側で作成済みのユーザーアカウントに対して、Keeper 側で資格情報を管理・配布するための YAML のサンプルを示します。

補足：credential-provision は Entra ID ユーザー自体は作成せず、「既存ユーザーのパスワードローテーションと安全な配布」を自動化するコマンドです。

user:
  first_name: Taro
  last_name: Keeper
  personal_email: newhire@gmail.com
account:
  username: taro@company.com
  pam_config_uid: XyZ9AbCd_12345678
pam:
  rotation:
    schedule: "0 0 0 * * ?"          # 毎日 0:00 にローテーション
    password_complexity: "32,5,5,5,5" # 長さ 32 文字で、大文字・小文字・数字・記号を各 5 文字以上
email:
  config_name: "AWS-SES"
  send_to: "newhire@gmail.com"
  subject: "マイクロソフトログイン情報のご案内"
  share_url_expiry: "7d"

実行手順：YAML + コマンド 1 行

YAML ファイルを作成したら、Keeperコマンダー上で次のように実行します。

My Vault> credential-provision --config="onboarding-admin-yamada.yaml"

※補足：credential-provision コマンドのヘルプは、次のように確認できます。

My Vault> cp -h
usage: credential-provision [-h] (--config CONFIG | --config-base64 CONFIG_BASE64) [--dry-run] [--output {text,json}]

Automate PAM User credential provisioning with password rotation and email delivery

options:
  -h, --help            show this help message and exit
  --config CONFIG       Path to YAML configuration file
  --config-base64 CONFIG_BASE64
                        Base64-encoded YAML configuration content (for API/Service Mode usage)
  --dry-run             Validate configuration and preview actions without making changes
  --output {text,json}  Output format: text (human-readable) or json (machine-readable)

重複する PAMユーザーがすでに存在する場合は、次のようなメッセージが表示され、処理はロールバックされます（例）：

✅ Configuration validated
❌ Duplicate PAM User found (by username in folder):
   Username: adminuser01@example.com
   Folder: PAM Users/Default
   Existing UID: AbCd-1234EfGhIjKlMnOpQr
   Title: PAM: Entra Admin01 - adminuser01@example.com
Duplicate PAM User already exists for username: adminuser01@example.com
Rolling back provisioning changes
credential-provision: Duplicate PAM User already exists for username: adminuser01@example.com

正常に実行された場合は、次のようなメッセージが表示されます（例）：

✅ Configuration validated
Selected 1 PAM record(s) for rotation
✅ PAM User created and linked
✅ Password rotation submitted
✅ Share URL generated for PAM User
[EMAIL] Sending email to newhire@example.com via ses
[EMAIL] SES email sent to newhire@example.com, MessageId: 0000000000000000-11111111-2222-3333-4444-555555555555-000000
✅ Email with one-time share sent

パスワードローテーション運用の考え方

特権アカウントは一度発行して終わりではなく、組織のポリシーに沿って定期的にパスワードを更新することが重要です。credential-provision を使えば、発行時点でローテーションのスケジュールや複雑度を YAML にまとめておけるため、「いつ・どの強度でローテーションするか」をテンプレートとして標準化でき、担当者ごとの運用ばらつきや設定漏れを防ぎやすくなります。

情シス向け：テンプレートとして運用するベストプラクティス

毎回 YAML をゼロから書くのは大変なので、実運用では 「テンプレート YAML」 を用意しておくのがおすすめです。

1. 特権アカウント種別ごとにテンプレートを用意

例えば、次のように役割ごとにテンプレートファイルを用意します。

template-ad-admin.yaml（AD 管理者）
template-entra-admin.yaml（Entra ID 管理者）

テンプレート内では、次の項目だけを「後で埋める」想定にしておきます。

first_name, last_name, personal_email, department
account.username（必要なら distinguished_name）
email.send_to

それ以外（pam_config_uid, vault.folder, rotation.schedule, password_complexity, email.config_name など）は、セキュリティチームと合意した値を固定で入れておきます。

2. 新任管理者ごとにコピー＆編集 → コマンド実行

新任管理者が着任するたびに、流れはシンプルです。

テンプレートをコピー
例：template-entra-admin.yaml → onboarding-entra-admin-yamada.yaml
可変項目（氏名・メール・username 等）だけを編集

Commander で次のように実行：

My Vault> credential-provision --config="onboarding-ad-admin-yamada.yaml"

これで、UI 操作なしで、統一されたポリシーで特権アカウントを発行できます。

3. Git 等でテンプレートを管理

テンプレート YAML を Git リポジトリで管理すると、

誰がいつどのポリシーを変更したか履歴が残る
Pull Request でセキュリティチームのレビューを挟める
本番用テンプレートと検証用テンプレートを分けやすい

といったメリットがあり、IaC（Infrastructure as Code）的な管理が可能になります。

まとめ

本記事では、Keeperコマンダーの credential-provision コマンドを用いて、新任管理者向けの特権アカウント（PAMユーザー）を、統一されたパスワードポリシー・ローテーションポリシーのもとで YAML 1 ファイル＋コマンド 1 回で自動発行する方法を、情シスの視点で整理しました。credential-provision は特権アカウント用の自動化コマンドであり、YAML を user / account / vault / pam / email の 5 ブロックで設計してテンプレート化・Git 管理することで、発行からローテーションまでの運用を一貫して標準化でき、特権アカウント運用における手作業・ミス・セキュリティリスクをまとめて削減しやすくなります。