本文へスキップ

Kurahi Guardian

English: Kurahi Guardian

Guardian は Kurahi Core のセキュリティ機能で、すべてのエディションで使えます。実績のあるエンジンと 決定的な検査が問題を見つけ、エージェントが日本語または英語で説明し、すべての検知が署名付きの証跡を 持つインシデント案件になります。対応を決めるのは人です。

Guardian は EDR(Microsoft Defender for Endpoint、CrowdStrike など)を補完するものです。EDR や 認定ウイルス対策製品ではなく、検知率の約束もしません。

  1. 判定は検査、説明は AI。 マルウェアかどうか、検査に合格したかを AI が決めることはありません。 検査は verdict OK または verdict ESCALATE で終わり、コードが判定します。
  2. 実績のあるエンジン。 検査は ClamAV、Microsoft Defender、YARA で行います。
  3. 失敗は要確認。 タイムアウト、異常終了、読めない結果、未設定、enabled: false は ESCALATE であり、OK にはなりません。
  4. 封じ込めは限定的。 自動で行うのは Kurahi 内のことだけです(ランサムウェアシールドによる全 エージェントの停止、共有フォルダ検査での隔離コピーの保存)。端末の隔離、バックアップからの復元、 社内ファイルの移動・削除は人が決めます。Kurahi はファイルを削除しません。
  5. すべてに証跡。 検査、スキャン、シールドの作動、判断はハッシュチェーンの監査ログに残ります。

ゲートウェイ設定の guardian にまとめて記述します。設定例と各項目は 英語版 と同じです。

項目 既定値 意味
enabled true false ですべての検査が ESCALATE になり、共有フォルダはシールド対象外に
shares[] なし ランサムウェアシールドと検査の対象となる社内フォルダ(絶対パス)
scan.engine auto 検査エンジン。YARA は明示したときだけ
scan.quarantine.mode copy copy は原本を残す。move は原本も隔離フォルダへ移動(同一ドライブのみ)
posture.backups[] なし バックアップの鮮度(maxAgeHours、既定 26 時間)と任意の復元テスト
posture.secretScanRoots なし 鍵・トークン・パスワードの置き忘れを探すフォルダ
posture.allowedPorts なし 待ち受けを許可する TCP ポート。それ以外は検知
posture.credentialWarnDays 14 この日数以内に期限切れとなる Kurahi のサインインを検知
siem 無効 監査ログと Guardian のイベントを syslog で送信
advisories 無効 JPCERT/CC・IPA の注意喚起と、照合する製品名
exposure 無効 自組織の確認済みドメインの外部露出チェック(下記)

共有フォルダのランサムウェアシールド

「共有フォルダのランサムウェアシールド」の見出し

シールド(おとりファイル、エントロピーの急上昇、脅迫文)は 2.0 から Kurahi 自身のフォルダを守って きました。guardian.shares を設定すると、社内の共有フォルダも守ります。作動するとすべての エージェントを停止して記録します。サーバー上の他のプログラムには触れません。

検査 内容
guardian_backup 各バックアップが maxAgeHours より新しいか
guardian_restore_test restoreTest のバックアップからサンプルを復元し、ハッシュが一致するか(tar・zip)
guardian_secrets secretScanRoots 内のファイルに残った鍵・トークン・パスワード
guardian_ports 待ち受け中の TCP ポートと allowedPorts の照合
guardian_integrity Kurahi 自身のファイルの完全性
guardian_credentials Kurahi が保存するサインインの有効期限
guardian_scan 共有フォルダの差分検査。感染ファイルは SHA-256 とシグネチャで記載

インシデント案件:core-guardian パック

「インシデント案件:core-guardian パック」の見出し

セキュリティ — Kurahi Guardian(core-guardian)からプロジェクトを作成します。

  • セキュリティインシデント キュー(情報システム部門、目標 24 時間)
  • チェック:概要と証跡が必須。人が確認する前に「駆除済み」「復旧済み」「安全」と書くことを拒否
  • 承認ルート:情報セキュリティ担当が 4 時間以内に確認(8 時間で部門長へエスカレーション)。 優先度 high・urgent は経営層の判断も必要
  • 要確認となった検査は必ず案件になります。AI が取り上げなかった場合も、Kurahi が検査結果を添えて起票します。 共有フォルダ検査で問題がなければ、AI は呼び出しません。
  • ルーチン(L1 準備のみ):guardian-posture 毎晩 2:15、guardian-shares 毎晩 1:30

guardian.siem を設定すると、ゲートウェイが記録する監査ログと Guardian の検査結果を、RFC 5424 (構造化データ kurahi@32473)または CEF 形式の syslog で、TCP・TLS(ca 指定)・UDP により送信 します。送信がゲートウェイを止めることはなく、値は送信前にマスクされます。

guardian_advisories は許可された URL の JPCERT/CC と IPA のフィードだけを読み(リダイレクト不可)、 advisories.products の製品名を含む注意喚起に印を付けます。

Microsoft 365 コネクタのオプション security.alerts を true にすると、m365_security_alerts (Microsoft Graph Security alerts_v2、読み取りのみ、権限 SecurityAlert.Read.All)が使えます。

外部露出チェック(Exposure check)

「外部露出チェック(Exposure check)」の見出し

外部露出チェックは、組織自身の外部からの見え方を調べる防御目的の OSINT です。攻撃者が最初に 見つけるものを、先にこちらで見つけます。対象は組織が申告し、所有を証明した資産だけで、公開情報を 読み取るだけです。設定例は英語版と同じです。

  • 自組織の資産だけ。 対象は exposure.domains のドメインとそのサブドメイン、 exposure.emailDomains のメールドメイン、exposure.brandTerms のブランド名だけです。人名の 自由検索、SNS 横断のユーザー名探索、人物調書(ドシエ)、ログインが必要なページの取得は行いません。 検知は組織の資産についてであり、個人を対象にしません。
  • 先に所有を確認。 申告ドメインへの TXT 照会 1 回を除き、確認前には何も取得しません。確認方法は ドメインの TXT レコード kurahi-exposure-verify=<トークン>(インストールごとのトークン。 kurahi guardian exposure verify で表示)、または管理者の宣誓 (kurahi guardian exposure attest <domain> --by <管理者>、管理者名とともに監査ログに記録)です。 未確認のドメインは「domain not verified」として ESCALATE し、何も取得しません。
  • 読み取りのみ・節度ある取得。 公開情報のみ、レート制限、リクエストごとの時間・サイズ上限、 HTTPS のみ、範囲外へのリダイレクトは追わない、クロール時は robots.txt を守る、User-Agent は Kurahi-Guardian-Exposure/2.6 (+https://kurahi.com/security/)。攻撃、ログイン試行、 ポートスキャンは行いません。
  • 秘密情報は保存も出力もしない。 見つかった認証情報は URL、行、検知器名、マスクしたプレビュー (先頭 2 文字と末尾 2 文字)、値の SHA-256 だけで報告します。値そのものはどこにも残しません。
  • 失敗時は要確認。 無効、ドメイン未設定、未確認、情報源の失敗(crt.sh・DNS・HIBP・GitHub)、 上限で止まったクロール、robots.txt を読めないサイトは ESCALATE です。OK はすべてを実行し、 何も見つからなかったときだけです。
項目 既定値 意味
exposure.enabled false 外部露出チェックを有効にする
exposure.domains[] なし 自組織の apex ドメイン(小文字、ワイルドカード不可、最大 20)
exposure.emailDomains[] なし 漏えい検索のメールドメイン(確認済みドメインかその配下)
exposure.brandTerms[] なし コード検索に使うブランド名
exposure.crawl 200 / 50 MiB / 3 クロールのページ数・バイト数・深さの上限
exposure.lookalikes.max 300 ドメインごとの類似ドメイン候補数。ignore は自社保有の類似ドメイン
exposure.hibp.enabled false HIBP のドメイン検索(キー guardian.exposure.hibpApiKey)
exposure.github.enabled false GitHub コード検索(トークン guardian.exposure.githubToken)
exposure.people 無効 同意に基づく個人の露出チェック(下記)

キーとトークンは kurahi secrets set <名前> で秘密情報ストアに保存します。ログや出力には出ません。

検査 内容
guardian_exposure_subdomains 証明書の透明性ログ(crt.sh)からサブドメイン一覧を作成し、状態フォルダに保存。前回から新しく現れたものと総数を報告(初回は基準)
guardian_exposure_dns SPF の有無と +all でないこと、DMARC の有無とポリシー(none は検知)、MX の有無、CAA(参考)、既知サブドメインの CNAME が乗っ取られやすいホスティング(Azure・Heroku・GitHub Pages・S3・Vercel・Netlify など)を指し、その先が解決できない場合は「サブドメイン乗っ取りの可能性」
guardian_exposure_web_secrets https://<domain>・www・確認済みサブドメインの自社サイトを巡回(同一オリジンのみ、robots.txt 遵守、HTML/JS/JSON/テキストのみ、上限あり)。鍵・トークン、値の入ったパスワード欄、パスワード:・Senha:・Password: などのラベルの隣の値(隣のログイン ID も)を検知。マスク表示
guardian_exposure_lookalikes タイプミス・似た文字・TLD 変更・ハイフン挿入の候補を DNS だけで確認。MX を持つ登録済み類似ドメイン(フィッシングメールの返信を受け取れる)を先に報告。類似ドメインのサイトは取得しません
guardian_exposure_breaches 任意。HIBP のドメイン検索。事実行は漏えいごとの件数のみ。該当アドレスは状態フォルダの証跡ファイル(権限 0600)にだけ保存し、パスで参照
guardian_exposure_code 任意。ドメインやブランド名と password などの語が並ぶ公開コードを GitHub で検索。リポジトリとファイルの URL のみ報告し、内容は取得しません

core-guardian パックのルーティン guardian-exposure(毎週月曜 03:40、L1)が上の 4 検査を集め、 マスクした証跡とともに セキュリティインシデント に案件を起票します。任意の検査は有効化してキーを 保存するまで「off」として ESCALATE します。kurahi guardian exposure run [--check <name>] で 今すぐ実行できます。

個人の露出チェック(同意に基づく)

「個人の露出チェック(同意に基づく)」の見出し

目的:社員と役員をフィッシング、なりすまし、アカウント乗っ取りから守ること。希望した本人のための デジタルリスク対策であり、人物検索ではありません。

  • 同意がある場合だけ登録。 本人が登録するか、管理者が本人を指定して登録し、本人が自分で同意を 確定します(people consent-text を読んだうえで people confirm <id> --code <コード> --accept <版>)。 同意が確定するまで何も検査しません。
  • 識別子は本人が証明。 メールはワンタイムコード(8 桁、30 分、5 回まで、ソルト付きハッシュでのみ 保存)で証明します。2.6 ではエージェントのコネクタ以外にメール送信経路がないため、CLI はコードを 登録した管理者に表示し、管理者が本人に渡します(中継方式)。中継方式は管理者がコードを本人に渡す ことを前提とする制約があり、監査ログに管理者名が残ります。ハンドルは本人が申告し、確認済みメールの もとで確定します。電話番号は SMS 経路がないため申告のみ・未確認として扱い、検査しません。 未確認の識別子は検査しません。
  • 同意記録。 登録者、同意者、識別子、検査の種類、日時、同意文の版を記録し、登録・同意・撤回・ 削除のすべてを(識別子をマスクして)監査ログに残します。
  • いつでも撤回可能。 people revoke <id> で検査はただちに止まり、記録と結果は people.retentionDays(既定 30 日)後に削除されます。未確定の登録も同じ期間で削除されます。

検査(guardian_exposure_people)

「検査(guardian_exposure_people)」の見出し

同意した本人ごとに、同意した検査だけを、確認済みの識別子にだけ行います。

  • 漏えい:確認済みメールを HIBP breachedaccount で照会(people.hibp.enabled とキーが必要)。
  • ハンドル:本人のハンドルが、厳選した公開プラットフォーム(既定:GitHub、GitLab、npm、PyPI、 Docker Hub、Keybase、DEV、Qiita、Zenn、note、はてな)に存在するかを、公開プロフィール URL の HTTP ステータスだけで確認。プロフィール内容は読まず、リンクもたどりません。
  • なりすまし:同じプラットフォームでハンドルの類似形が存在するかを同じ方法で確認。表示名の類似は 主要プラットフォームではログインが必要な検索になるため行いません。X、Instagram、Facebook、 LinkedIn、TikTok はログインなしで判定できないため対象外です。
  • Web:本人の確認済みメールが組織自身の確認済みサイトに載っていないか(同じクローラ、マスク表示)。

事実行では本人を登録 ID(pe-…)でだけ示し、件数とプラットフォーム名だけを載せます。メール アドレスや電話番号は載せません。詳細な結果は本人とセキュリティ担当のために、状態フォルダの所有者のみ 読めるファイル(0600)に保存し、削除時に消去します。

案件はルーティン guardian-exposure-people(毎週、L1)から sec-personal キューにだけ起票され、 一般のキューには入りません。経路は security ロールの確認 1 段だけで、エスカレーションも経営層の 段もないため、読めるのはセキュリティ担当、起票者、特権オペレーターだけです。本人の結果は Kurahi アカウント(--principal)にひも付きます。本人向けの画面は 2.6 には含まれません。

個人情報保護法(APPI)・LGPD との整合

「個人情報保護法(APPI)・LGPD との整合」の見出し
  • 利用目的の限定:フィッシング、なりすまし、アカウント乗っ取りからの保護だけ。
  • 同意:本人による明示的で、説明を受けた(版付き同意文)、撤回可能な同意。
  • データ最小化:本人が証明した識別子だけ。事実行は件数・プラットフォーム名・登録 ID だけ。 プロフィール内容の取得や集約はしません。
  • 削除:撤回で処理を止め、保存期間の後に削除します。
  • 登録して同意を確定していない人は一切検索しません。
  • 人名の自由検索、人物検索サイトやデータブローカーでの住所・電話番号の照会はしません。
  • 人物調書への集約、顔・写真検索はしません。
  • 家族や第三者を対象にした検査はしません。
  • 端末の EDR やウイルス対策ソフトの代わりにはなりません。
  • ファイルの削除・駆除・復元、端末の隔離は行いません。
  • サインイン情報の更新や書き換えは行いません。
  • 外部露出チェックは侵入試験、ポートスキャン、ログインを行わず、未確認のドメインや同意していない人を 対象にしません。