2026/08/24 11:23

【Keeper】BreachWatchの危険なパスワード数を毎月自動レポート出力してみた

» 技術 » Keeper

kusumin

はじめに

こんにちは、ネクストモード株式会社のSaaSおじさん久住です。

KeeperのBreachWatchは、ダークウェブ上に漏洩したパスワードを検知し、危険なパスワードの数を可視化してくれる便利な機能です。

今回は「BreachWatchで検出された危険なパスワード数を、APIを使わずに定期的にファイル出力したい」という要望を実現するために試した方法をまとめます。

背景・やりたかったこと

BreachWatchの危険なパスワード数を、社内で定期的に可視化・共有したい
ただし、開発リソースをかけてAPIを直接叩く仕組みを作るのは避けたい

検討した非API方式の選択肢

Keeper Commanderでbw reportコマンドを定期実行する
カスタムレポート・アラートを設定する
管理コンソールのダッシュボードを手動で確認する

今回は、最も手軽かつ柔軟に自動化できる「①Keeper CommanderのCLIをOSのスケジューラで定期実行する」方式を、実際にMacで動くところまで検証してみました。

Keeper Commanderの準備

まずKeeper CommanderにログインしPersistent Login（永続ログイン）を設定します。
これにより、以降はパスワードやOTPの入力なしでコマンドを実行できるようになります。

keeper shell --config-file
login --config-file admin@xxxx.com

this-device register
this-device persistent-login on
this-device ip-auto-approve on
this-device timeout 30d

設定後は、ログインし直してもパスワード入力を求められなくなり、非対話的にコマンドを実行できるようになります。例えば以下は、BreachWatchのレポートをCSVファイルとして出力するコマンドです。

    keeper --config "/path/to/config.json" -c "bw report --format csv --output /path/to/output.csv" 
  

このコマンドの各要素は以下の通りです。

--config "/path/to/config.json"：先ほどのPersistent Login設定（デバイストークンなどの認証情報）が保存された設定ファイルを指定します。これによりパスワードやOTPの入力なしで認証されます
-c "..."：対話型シェルを起動せず、指定したコマンドを1回だけ実行して終了するオプションです。スケジューラからの自動実行に適しています
bw report：BreachWatchのレポート（漏洩が検出されたレコードの一覧）を生成するコマンドです
--format csv：レポートの出力形式をCSVに指定します
--output /path/to/output.csv：レポートの出力先ファイルパスを指定します

macOSでの自動化：launchdでの定期実行

Macではcronよりもlaunchdの利用が推奨されています（cronはmacOSのセキュリティ制限に引っかかりやすいため）。

1. 年月付きファイル名で出力するラッパースクリプトを作成

ファイル名にレポート出力月を含めたかったため（例：breachwatch-report-202607.csv）、日付を都度計算するシェルスクリプトを用意しました。

     #!/bin/bash
DATE=$(date +%Y%m) 
/usr/local/bin/keeper --config "/Users/xxxx/Library/Application Support/.keeper/config.json" -c "bw report --format csv --output /Users/xxxx/keeper-reports/breachwatch-report-${DATE}.csv"  
  

2. launchd用のplistを作成（毎月1日朝7時に実行）

    <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.xxxxx.breachwatch-monthly</string>
  <key>ProgramArguments</key>
  <array>
    <string>/bin/bash</string>
    <string>/Users/xxxx/keeper-reports/run_breachwatch_report.sh</string>
  </array>
  <key>StartCalendarInterval</key>
  <dict>
    <key>Day</key>
    <integer>1</integer>
    <key>Hour</key>
    <integer>7</integer>
    <key>Minute</key>
    <integer>0</integer>
  </dict>
  <key>StandardOutPath</key>
  <string>/tmp/breachwatch_monthly.log</string>
  <key>StandardErrorPath</key>
  <string>/tmp/breachwatch_monthly_error.log</string>
</dict>
</plist>
  

3. ジョブを登録・動作確認

launchctl load ~/Library/LaunchAgents/com.xxxxx.breachwatch-monthly.plist

毎月1日を待たなくても、launchctl startコマンドで即座にテスト実行できるのが地味に便利でした。

launchctl start com.xxxxx.breachwatch-monthly

実行後、~/keeper-reports/にbreachwatch-report-202607.csvのようなファイルが生成され、エラーログも空であることを確認し、無事自動化に成功しました

運用上の注意点：永続ログインは「30日間未アクセスで自動ログアウト」

this-device timeout 30dは、公式ドキュメントにも明記されている設定可能な上限値（最大30日）です。ただしこれは絶対的な有効期限ではなく、「その日数の間まったくアクセスがなければ自動ログアウトする」という非アクティブタイマーです。

月次実行（例：毎月1日）の場合、月によっては前回実行から31日空くことがあるため、タイムアウトの30日をわずかに超え、2回目以降の実行で再ログインが必要になってしまう可能性があります。

対策：レポート用ジョブとは別に、こまめな「活動」用ジョブを仕込む

タイムアウトはアクセスのたびにリセットされるため、月次のレポート出力とは別に、毎週や隔週など30日より十分短い間隔で軽量なコマンド（keep-aliveやwhoamiなど）を実行するジョブをlaunchdにもう1つ追加しておくと安全です。

    <key>Label</key>
<string>com.nextmode.breachwatch-keepalive</string>
<key>ProgramArguments</key>
<array>
  <string>/bin/bash</string>
  <string>-c</string>
  <string>/usr/local/bin/keeper --config "/Users/xxxx/Library/Application Support/.keeper/config.json" -c "keep-alive"</string>
</array>
<key>StartCalendarInterval</key>
<array>
  <dict>
    <key>Weekday</key>
    <integer>1</integer>
    <key>Hour</key>
    <integer>7</integer>
    <key>Minute</key>
    <integer>0</integer>
  </dict>
</array>
  

このように毎週アクセスを発生させておけば、30日のタイムアウトに引っかかることなく、月次のレポート出力も安定して自動実行を継続できます。

まとめ

BreachWatchの危険なパスワード数は、APIを使わなくてもKeeper CommanderのCLI + OSのスケジューラで定期出力が可能
macOSで自動化する場合はcronではなくlaunchdを使うのが安全
出力先をDesktopなどの保護フォルダにすると権限エラーになるので注意
ファイル名に年月を含めたい場合は、日付計算をラッパースクリプト側で行うと良い
永続ログインのタイムアウト（最大30日）は非アクティブタイマーのため、月次実行だけだと稀にタイムアウトを超える可能性がある。定期的な軽量アクセス（keep-aliveなど）を別途仕込んでおくと安心

開発コストをかけずに、まずは非APIな方法でBreachWatchの状況を定期的に可視化したい、という場合の参考になれば幸いです。