Skip to content
KitploitKITPLOIT
ツールエクスプロイトブログ
Log in
提出
ツールエクスプロイトブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに!

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

··フィード·お問い合わせ·プライバシー·© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
engagement-mgr — Engagement Managerは、オフェンシブセキュリティエンゲージメントを追跡するためのWebアプリケーションです。Next.js、Prisma、PostgreSQLで構築されたモダンなUIを備えています。 | Kitploit
ツール/GitHubGitHub/leebaird/engagement-mgr
防御ツール脆弱性分析ウェブセキュリティペネトレーションテストユーティリティとフレームワーク学習と教育レッドチーミングインシデントレスポンス
GitHubleebaird/engagement-mgr

engagement-mgr

Engagement Managerは、オフェンシブセキュリティエンゲージメントを追跡するためのWebアプリケーションです。Next.js、Prisma、PostgreSQLで構築されたモダンなUIを備えています。

リポジトリを見る
24382日前Kitploit レビュー済み

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有

Engagement Manager

Engagement Managerは、オフェンシブセキュリティエンゲージメントを追跡するためのWebアプリケーションです。Next.js、Prisma、PostgreSQLで構築されたモダンなUIを備えています。このアプリには、カレンダー、エンゲージメント、クライアント、連絡先、所見、オペレーターが含まれます。

License: MIT

  • Twitter Follow Lee Baird @discoverscripts
  • Twitter Follow Jay "L1ghtn1ng" Townsend @jay_townsend1

スクリーンショット

Dashboard

目次

  • スクリーンショット
  • 所見の作成とPDFレポートの生成
    • レポートのセキュリティとデプロイ
    • 検証
  • 前提条件
  • 環境設定
  • データベースのセットアップ
    • 開発
    • 本番
  • インストール
    • 自動セットアップ (Ubuntu)
      • 堅牢化セットアップとバックアップのアップグレードに関する注意事項
    • 手動セットアップ
  • アプリケーションの実行
  • 本番デプロイ
    • 要件
    • デプロイ手順
    • 本番チェックリスト
  • デフォルトの認証情報
  • サーバーマイグレーション (バックアップ / リストア / リセット)
  • 実装計画とアーキテクチャ
    • 技術スタック
    • データベーススキーマ
    • 新しいフィールドの追加
    • セキュリティアーキテクチャ

所見の作成とPDFレポートの生成

  • 執筆ワークスペース: 所見のWrite & reviewリンクを開くと、Markdown編集と安全なプレビューが利用できます。プライベート下書きは15秒間の非操作後、またはオンデマンドで保存されます。これらはブラウザのローカルストレージではなく、サーバーに保存されます。再度開いた後、下書きを明示的に復元してください。保存の競合が発生した場合、エディターのテキストは保持され、現在のリビジョンとの比較が必要になります。テキストのリビジョンは検査および復元できますが、復元しても削除された証拠は復元されません。
  • 再利用可能なテンプレート: 承認済みの文言をタイトル、カテゴリ、または重大度で検索できます。ユーザーはテンプレートを提案でき、管理者がそれらを精査して承認します。テンプレートを適用すると、空の観察事項、影響を受けるホスト、証拠を持つ独立したエンゲージメント所見が作成され、別のエンゲージメントの証拠を誤って再利用することを防ぎます。
  • 証拠: 最大4つのPNG/JPEG画像をまとめてアップロードまたは貼り付け、キャプションを追加し、執筆ワークスペースでキャプション/順序を編集できます。画像はデコードされ、メタデータが削除され、最大2000 × 2000ピクセルにリサイズされ、PNGとして保存されます。元のバイト列やメタデータが必要な場合は、元のフォレンジック証拠を別途保管してください。
  • レビュー: 完全な所見をDraft/Changes RequestedからReadyに送信します。現在の作成者以外の割り当てられたレビュアーまたは管理者が、承認または変更を要求できます。管理者がレビュアーを割り当てます。テキスト、証拠、復元されたリビジョンの変更は承認をクリアします。レビューキュー、コメント、準備状況チェックリスト、リビジョン履歴が引き継ぎを支援します。
  • PDFレポート: Reportsでエンゲージメントを選択し、エグゼクティブサマリーを作成し、所見を選択/並べ替えて設定を保存します。下書きPDFは目に見える形でマークされます。最終PDFを発行できるのは管理者のみであり、選択されたすべての所見が承認され、準備状況チェックに合格している必要があります。発行された各バージョンは、そのPDF、明示的なコンテンツスナップショット、SHA-256ダイジェストを保存します。その後の編集では再生成されません。親エンゲージメントを削除すると、既存のライフサイクルを通じてそのレポートも削除されます。
  • スキャナーインポート: エクスポートをプレビューし、所見を選択してから確定します。インポートはスキャンを実行したり、ターゲットに接触したりすることはありません。サーバー側のフィンガープリンティングにより、同じエンゲージメント内の一致する所見はスキップされます。すべての新規レコードはDraftとして開始され、オペレーターによる確認が必要です。

エクスポートは2 MB、1回のインポートあたり500所見に制限され、ユーザーごとのプレビューと確認のレート制限があります。アプリケーションは、手動作成、テンプレート、スキャナーインポートを通じて、合計最大10,000所見、1つのエンゲージメントにつき500所見を受け入れます。グローバルのFindingsリストは1ページあたり100行を読み込み、エンゲージメント/レポートの所見クエリは同じエンゲージメントごとの制限によって上限が設定されます。不明なレイアウトは、サイレントに成功したインポートとして扱われるのではなく、目に見える形で失敗します。スキャナーの重大度は提案です。承認前にそのコンテキストを確認してください。参照されたURL、HTML、埋め込みリモート画像は取得または実行されません。

レポートは1〜100所見、最大100の証拠画像 (各5 MB、合計入力20 MB)、500ページ、25 MBの出力を許可します。発行はエンゲージメントあたり50バージョン、アプリケーション全体で発行されたPDFは1 GBに制限されます。プレビューと発行にはユーザーごとのレート制限があり、アプリケーションプロセスごとに一度に1つのPDFレンダリングのみが許可されます。所見は最大1000リビジョンと500コメントを保持します。制限に達すると、履歴を上書きせずに失敗します。DejaVuフォントとその再配布ライセンスはassets/fontsに含まれています。デプロイメントはこれらのアセットを保持する必要があります (Nextの出力トレースに含まれます)。

Next.js Server Actionsは、証拠アップロード用に単一の25mbボディサイズ制限 (next.config.tsで設定) を共有します。ログインは、認証またはデータベース処理の前に4 KBのストリーミング制限を持つ専用の同一オリジンURLエンコードルートを使用します。

レポートのセキュリティとデプロイ

これは、新しいクライアントごとのテナンシーモデルではなく、既存の共有認証ワークスペースを維持します。すべての新しいページ、アクション、PDFダウンロードは、現在のデータベースに裏付けられたセッションをチェックします。下書きはその所有者にスコープされ、レビュー、テンプレート承認、発行の権限はサーバー側で強制されます。機密PDFレスポンスはprivate/no-storeです。最終PDFには、明示的なレポートフィールドの許可リストのみが含まれ、プライベート下書き、レビューコメント、無関係なエンゲージメントは含まれません。

実装はOWASP Top 10:2025チェックリストを使用しています: アクセスチェック (A01)、プライベートレスポンスと既存のCSP/CSRFコントロール (A02)、固定された依存関係とCI (A03)、既存のセッション/シークレット保護とレポート整合性チェック (A04/A08)、不活性なMarkdown/XMLとパラメーター化されたデータベースアクセス (A05)、境界付き処理と独立したレビュー (A06)、ライブセッションチェック (A07)、コンテンツフリーの監査イベント (A09)、失敗時のクリーンアップを伴うトランザクション変更 (A10)。ダイジェストは偶発的な破損を検出しますが、デジタル署名やデータベース管理者からの保護ではありません。これはコンプライアンス認証ではありません。本番環境では依然としてHTTPS、保護されたデータベース/バックアップストレージ、監査出力の運用監視が必要です。

このアップグレードをデプロイする前に、通常のアプリケーションバックアップを取得し、追加的な20260904221808_reporting_workflowおよび20260906194500_add_revocable_sessionsマイグレーションをnpm run db:migrateで適用してから、Prisma Clientを再生成してリビルドします。既存の所見はバージョン1のDraftとして開始され、既存のブラウザCookieはサーバーに裏付けられたセッションIDを受け取るために再度サインインする必要があります。既存のデータベースをリセットしないでください。バックアップには、既存のフルデータベースエクスポートを通じて新しいテーブルと発行されたPDFが含まれます。

検証```bash

npm test npm run lint npx tsc --noEmit --noUnusedLocals --noUnusedParameters npm run build npm audit

root@kitploit:~
`npm test` は Node の非分離テストモードを `tsx` と共に使用するため、個々の TypeScript テストケースが実行され、ファイルサブプロセスの成功を報告するだけにはなりません。明示的なアサーションの合計を CI で可視化したままにしてください。

データベースとブラウザのリグレッションには、マイグレーションが適用された **`reporting_tests` という名前の専用ローカルデータベース** が必要です。これらのテストは自身のフィクスチャ行を作成および削除します。これらのテストをアプリケーションのデータベースに向けないでください。`REPORTING_TEST_DATABASE_URL` をそのテストデータベースに設定し、次を実行します:```bash
DATABASE_URL="$REPORTING_TEST_DATABASE_URL" npx prisma migrate deploy
npm run test:reporting
npx playwright install chromium
npm run test:browser

ブラウザスイートは、テスト専用のセッションシークレットを使用してポート3317で独自のループバック開発サーバーを起動します。既存のサーバーの再利用は拒否します。必要に応じて、インストール済みのChromium実行ファイルをREPORTING_TEST_BROWSERに設定してください。このスイートは、下書きのプライバシー、競合する編集、証拠のアップロード、独立したレビュー、PDFの権限/不変性、JavaScriptなしでのテンプレート作成、および選択的な重複排除インポートをテストします。統合テストでは、実際のトランザクション競合とロールバックを検証します。これらのスイートは、リモートLAN、Safari、または本番デプロイメントの検証を代替するものではありません。

前提条件

このアプリケーションはUbuntu上で動作するように設計されており、以下が必要です:```bash sudo apt update && sudo apt install -y nodejs npm postgresql postgresql-client postgresql-contrib zip

root@kitploit:~
`postgresql-client` は `pg_dump`、`pg_restore`、`psql` を提供し、`zip` はバックアップアーカイブを作成します。リストア時の展開は、厳格なエントリおよびサイズの検証を伴ってアプリケーション側で処理されます。

パッケージをインストールしても、PostgreSQL が常に稼働状態になるとは限りません。ロールを作成したりアプリを起動したりする前に、サービスを起動して有効化してください:```bash
sudo systemctl enable --now postgresql
sudo systemctl status postgresql --no-pager

アプリが後で Can't reach database server at 127.0.0.1:5432 で失敗する場合は、sudo systemctl start postgresql を実行し、pg_isready -h 127.0.0.1 -p 5432 で確認してください。

アプリには Node.js ^22.12.0 または >=24.0.0 が必要です(package.json の engines を参照)。OS のパッケージが古い場合は、setup.sh を実行する前に署名を検証した信頼できるパッケージソースからサポート対象のリリースをインストールしてください。

環境設定

Prisma またはアプリを実行する前に、プロジェクトルートに .env ファイルを作成します:```bash cat > .env << 'EOF' DATABASE_URL="postgresql://em_admin:em_pass@localhost:5432/engagement_manager?schema=public" JWT_SECRET="replace-with-a-long-random-secret-at-least-32-characters" EOF chmod 600 .env

root@kitploit:~
| 変数 | 必須 | 備考 |
|----------|----------|-------|
| `DATABASE_URL` | はい | PostgreSQL 接続文字列。Prisma は `schema=public` クエリパラメータを使用します。バックアップとリストアはオーナー専用の一時的な pgpass ファイルを使用するため、パスワードがサブプロセスの引数に含まれることはありません。 |
| `JWT_SECRET` | 本番環境では必須 | **32文字**以上である必要があります。本番環境ではこれがないとアプリは起動を拒否します。これをローテーションすると既存のすべてのセッションが無効になります。 |
| `TRUST_PROXY` | いいえ | `X-Forwarded-For` / `X-Real-IP` および `X-Forwarded-Host` を**上書き**するリバースプロキシの背後にアプリがある場合にのみ、`1`(または `true`)に設定します。このモードでは、ログインのオリジンチェックは存在する場合に `X-Forwarded-Host` を使用します。これには、使用時にデフォルト以外のポートを含む、1つのパブリックホストが含まれている必要があります。それ以外の場合、プロキシはパブリックな `Host` ヘッダーを保持する必要があります。これは、ソースごとの正確なログイン制限のために必要な本番トポロジーです。未設定の場合、スプーフィングを防ぐためにヘッダーは無視され、ログインはより高い1分間の共有フォールバックバジェットを使用するため、1つのクライアントが15分間のグローバルロックアウトを課すことはできません。 |
| `ALLOWED_DEV_ORIGINS` | いいえ | **開発専用。** `/_next` アセットの読み込みを許可する追加のホスト名(カンマ区切り)。サーバーの現在の LAN IPv4 アドレスは自動的に許可されます。安定した DNS 名を使用する場合にこれを使用します。本番ビルドではこれは無視されます。 |

強力なシークレットを生成します:```bash
openssl rand -base64 32

データベースのセットアップ

まず PostgreSQL が実行されていることを確認してください(前提条件を参照)。自動化された ./setup.sh がサービスの起動を行います。以下の手動ステップでは、すでに起動していることを前提としています。

開発

以下のコマンドを実行して、PostgreSQL データベースとユーザーを作成します:```bash sudo -u postgres createuser --pwprompt em_admin sudo -u postgres psql -c "ALTER USER em_admin CREATEDB;" sudo -u postgres createdb --owner=em_admin engagement_manager sudo -u postgres psql -c "GRANT ALL PRIVILEGES ON DATABASE engagement_manager TO em_admin;"

root@kitploit:~
### 本番環境

**最小権限**を持つ専用のデータベースユーザーを使用してください — `CREATEDB` やスーパーユーザー権限を付与しないでください:```bash
sudo -u postgres createuser --pwprompt em_app
sudo -u postgres createdb --owner=em_app engagement_manager

DATABASE_URL を em_app(または任意のユーザー名)を使用するように設定します。マイグレーションは npm run db:migrate を介してこのユーザーとして実行されます。

注記: データベースファイルは PostgreSQL のデータディレクトリ(通常は /var/lib/postgresql/<version>/main/)に保存されます。

インストール

自動セットアップ(Ubuntu)

リポジトリのルートから、次を実行します:```bash chmod +x setup.sh ./setup.sh

root@kitploit:~
スクリプトは前提条件をインストールし、PostgreSQL サービスを起動して有効化し、データベースのユーザー名とパスワードを入力させ、`chmod 600` の `.env` を書き込み、PostgreSQL のロールとデータベースを作成し、マイグレーションを適用し、デフォルトの管理者アカウントをシードします。本番モードではさらに `npm run build` を完了し、本番用の起動コマンドのみを出力します。リモートのシェルスクリプトから Node.js をインストールすることはありません。先にサポートされている Node.js リリースをインストールしてください。

ヘッドレスまたは CI での使用:```bash
sudo install -d -m 700 -o "$USER" /secure
openssl rand -base64 24 > /secure/db-password
chmod 600 /secure/db-password
./setup.sh -y --db-user=em_admin --db-pass-file=/secure/db-password

すべてのオプションについては ./setup.sh --help を実行してください。

ハードニングされたセットアップとバックアップに関するアップグレードノート

  • --db-pass=... は、コマンドラインのシークレットが他のプロセスから見えるため削除されました。パスワードは所有者のみがアクセスできるファイルに記述し、古い引数を --db-pass-file=/secure/db-password に置き換えてください。上記の自動セットアップ例はそのままコピー&ペーストで使用できます。
  • setup.sh は Node.js をインストールしなくなりました。実行する前に、信頼できるパッケージソースからサポート対象の Node.js リリース(^22.12.0 または >=24.0.0)をインストールしてください。
  • 依存関係のインストールは npm ci を使用するようになったため、package-lock.json が存在し、package.json と同期している必要があります。
  • レガシーな .sql バックアップは復元できません。古いサーバーを廃止する前に、構造化されたアプリケーションバックアップを作成できるバージョンにアップグレードし、データを .zip として再エクスポートしてください。

手動セットアップ

  1. Node.js の依存関係をインストールします: ```bash npm ci
    root@kitploit:~
  2. データベースマイグレーションを実行してテーブルを作成します: ```bash npx prisma migrate dev
    root@kitploit:~
  3. デフォルトのAdminアカウントを作成するためにデータベースをシードします: ```bash npx prisma db seed
    root@kitploit:~

アプリケーションの実行

プロジェクトディレクトリから、1つのコマンドでパッケージの更新をインストールし、PostgreSQLが停止している場合は起動し、アプリを起動します:```bash ./run.sh

root@kitploit:~
そのウィンドウは開いたままにしてください。表示された Local または Network アドレスを使用します。

代わりに自分で起動する場合: PostgreSQL が実行されている必要があります(必要に応じて `sudo systemctl start postgresql`)。その後、開発サーバーを起動します:```bash
npm run dev

起動時にループバックURLとこのマシンのLANアドレスの両方が表示されます:```

  • Local: http://localhost:3000
  • Network: http://192.168.1.20:3000
root@kitploit:~
`npm run dev` と `npm start` は `0.0.0.0` にバインドするため、Network URL は LAN 上で機能します。LAN アクセスは信頼できるネットワーク上のラボ専用として扱ってください。開発モードはパブリックインターネット向けに堅牢化されていません。

**ホスト名**(IP ではなく)でアプリを開いた際に、リモートブラウザが真っ白なページになる場合は、その名前を `.env` に追加して再起動してください:```bash
ALLOWED_DEV_ORIGINS=dev.office.example

本番環境へのデプロイ

要件

  • Node.js ^22.12.0 または >=24.0.0(package.json の engines を参照)
  • PostgreSQL と最小権限のアプリユーザー(データベースのセットアップを参照)
  • アプリの前段に HTTPS(nginx や Caddy などのリバースプロキシ)。本番環境ではセッション Cookie に Secure が付与されます。
  • uploads/ ディレクトリ(所見のスクリーンショット)用の永続ストレージ

デプロイ手順

  1. リポジトリをクローンし、依存関係をインストールします: ```bash npm ci

    root@kitploit:~
  2. 本番環境の値(DATABASE_URL、JWT_SECRET は32文字以上)を設定した .env を作成します。

  3. データベースマイグレーションを適用します: ```bash npm run db:migrate

    root@kitploit:~
  4. デプロイ前チェックを実行します: ```bash npm run audit npm run typecheck npm run build

    root@kitploit:~
  5. NODE_ENV=production でアプリケーションを起動します: ```bash NODE_ENV=production npm run start

    root@kitploit:~

実際のサーバーでは、これをプロセスマネージャー(systemd、PM2 など)の下で実行し、TLS 終端用のリバースプロキシを前に配置してください。

  1. データベースシード(開発専用)またはバックアップからの復元によって、最初の管理者アカウントを作成します。アプリをユーザーに公開する前に、一時的なシードパスワードを直ちに変更してください。

本番環境チェックリスト

  • JWT_SECRET が 32 文字以上で、git にコミットされていない
  • 実行中のプロセスに NODE_ENV=production が設定されている
  • HTTPS が構成されており、HTTP は HTTPS にリダイレクトされる
  • データベースユーザーに CREATEDB 権限やスーパーユーザー権限がない
  • uploads/ が永続ディスク上にあり、バックアップに含まれている
  • 管理者が Backup を使用する場合、backups/ が永続ディスク上にある
  • 管理者が Backup/Restore を使用する場合、pg_dump、pg_restore、zip が利用可能である

デフォルトの認証情報

データベースをシードした後、生成された一時的な管理者アカウントを使用してログインできます:

  • ユーザー名: admin
  • パスワード: npx prisma db seed / npm run db:seed によって、所有者のみが読める initial-admin-credentials.txt に一度だけ書き込まれます

注記: 初回ログイン時にこの一時パスワードを変更する必要があります。その後、直ちに initial-admin-credentials.txt を削除してください。すべてのパスワードは 16 文字以上で、大文字、小文字、数字、記号を含める必要があります。

サーバーマイグレーション(Backup / Restore / Reset)

  • サイドバーは、各ブラウザの日付形式とタイムゾーンの設定をローカルに保存します。タイムゾーンは閲覧者のオペレーティングシステムに従うか、UTC でタイムスタンプを表示できます。エンゲージメントスケジュールの日付は変更されず、カレンダー上の日付のままです。
  • 管理者は Admin ページ(/dashboard/users)からアプリケーションの全データをバックアップおよび復元できます。
  • 古いサーバーから新しいサーバーへ移行する際にこれを使用します:新しいホストでアプリをクローンし、古いホストからバックアップを復元します。

Admin では、Database パネルに Backup、Restore、Reset ボタンが表示されます。Users パネルにはアカウントが一覧表示され、ユーザーを追加するための New User ボタンがあります。Appearance パネルでは、管理者がアプリケーション全体のハイライト色を選択できます。

Backup には管理者パスワードが必要で、em-backup-YYYY-MM-DD-HHMM.zip という名前の .zip をアプリケーションディレクトリ内の backups/(engagement-mgr/backups/)に保存します。エクスポートが成功したら、Admin ページの Download を使用します。短命な署名付きグラントが HttpOnly Cookie に保持され、バックアップを作成した管理者に対してのみ機能します。

  • タイムスタンプは、アプリを実行しているサーバーのローカル時刻を使用し、秒は含まれません。例:em-backup-2026-06-02-1430.zip。
パス内容
engagement-manager-backup/database.dumppg_dump による完全な PostgreSQL カスタム形式ダンプ(スキーマ、テーブル、データ、enum、リレーション)
engagement-manager-backup/uploads/データベースで参照されている Finding のスクリーンショットファイル
  • Restore は Backup によって作成された .zip のみを受け付け、現在のデータベースと uploads/ フォルダを置き換えます。ブラウザからの復元は 8 MB に制限されているため、展開が Web プロセスを独占することはありません。より大きなアーカイブの場合は、アプリケーションを停止し、アプリケーションユーザーとして npm run db:restore -- /absolute/path/to/em-backup.zip を実行してください。オフラインコマンドは作業ディレクトリから .env を読み込み、.env または環境に空でない DATABASE_URL が必要です。最大 500 MB の通常ファイルを受け付け、各アーカイブエントリを展開後サイズの制限までストリーミングします。データベースの復元は 1 つのトランザクションで実行されます。アーカイブエントリの数、パス、圧縮率、展開後サイズは、ファイルがインストールされる前に検証されます。バックアップ、復元、リセット、スクリーンショットファイルの変更は、排他的なメンテナンスロックを共有するため、データベースのコミットとファイルシステムのスワップが重複することはありません。確認には管理者パスワードが必要です。
  • Reset はすべてのアプリケーションデータを消去し、デフォルトの赤いハイライト色を復元し、admin を再作成します。RESET と入力し、確認する管理者の現在のパスワードを再入力する必要があります。そのパスワードは再作成されたアカウントの一時パスワードとなり、初回ログイン時に変更する必要があります。

古いサーバー

  1. Admin ユーザーとしてログインします。
  2. Admin を開き、Backup(Database の下)をクリックします。
  3. .zip を保存し、新しいサーバーにコピーします(例えば scp や rsync を使用): ```bash scp em-backup-2026-06-02-1430.zip user@new-server:/path/to/
    root@kitploit:~

新しいサーバー

  1. 前提条件をインストールし、リポジトリをクローンします。
  2. DATABASE_URL と JWT_SECRET を含む .env を作成します(環境設定を参照)。
  3. 空の PostgreSQL データベースとユーザーを作成します(データベースのセットアップを参照)。
  4. 依存関係をインストールします: npm ci。
  5. マイグレーションを実行し、管理者がサインインできるように一度シードします。リストアはこのブートストラップデータをバックアップで置き換えます。
  6. 本番モードでアプリをビルドして起動します(本番デプロイを参照): ```bash npm run build NODE_ENV=production npm run start
    root@kitploit:~
  7. オーナー専用の initial-admin-credentials.txt を使用して admin としてログインし、一時パスワードを変更して、認証情報ファイルを削除します。
  8. Admin (/dashboard/users) を開き、Database の下にある Restore をクリックし、古いサーバーから取得した .zip を選択して、管理者パスワードを入力し、確認します。
  9. アプリがすでに実行中の場合は再起動して、復元されたデータを読み込ませます。

注意事項

  • 機密性の高い操作: Backup、Restore、Reset はすべて管理者パスワードの再確認が必要です。Restore と Reset は既存のデータベース行を置き換え、uploads/ ディレクトリも上書きします。
  • JWT_SECRET: 新しいサーバーでは異なる場合があります。古いサーバーからの既存のブラウザセッションは移行されません。ユーザーはインポートされたデータベースのアカウントで再度サインインします。
  • アプリケーションコード: 新しいサーバーで git clone (または同じリビジョンをデプロイ) して、バックアップが想定するスキーマとアプリを一致させます。古いサーバーがクローンしたコードより新しいスキーマで動作していた場合は、インポート前にバージョンを揃えてください。
  • ツール: バックアップと復元には、Prerequisites に記載されている CLI ツールがインストールされている必要があります。

実装計画とアーキテクチャ

このセクションでは、Engagement Manager アプリケーションのアーキテクチャ、データベーススキーマ、セキュリティ対策、および完了した開発フェーズについて説明します。

技術スタック

  • フルスタックフレームワーク: Next.js 16+ (React)、App Router を使用。
  • データベース: PostgreSQL。
  • ORM: Prisma。
  • 認証: 厳格なセッション Cookie (ブラウザを閉じるとクリア) と Argon2id によるパスワードハッシュを使用したカスタム実装。パスワードは最低 16 文字で、記号、数字、大文字小文字の混在が必須です。
  • スタイリング: ページパネルにグラスモーフィズムのダークモード美学を採用したバニラ CSS。モーダルは Modal.tsx と globals.css の .modal-panel により完全に不透明です。

データベーススキーマ

レポーティング関連の追加: Finding は version、reviewStatus、authorId、reviewerId、templateId、importFingerprint も保存します。Screenshot は sortOrder を保存します。FindingTemplate はレビュー済みの再利用可能な文言を保持し、FindingRevision は不変のテキストリビジョンを保持し、FindingDraft は競合バージョン付きのユーザーごとのプライベートドラフトを保持し、FindingComment はレビュー議論を記録し、EngagementReport はレポートタイトル、エグゼクティブサマリー、および順序付けられた finding ID を保持し、IssuedReport は発行された各バージョンの不変の PDF、コンテンツスナップショット、SHA-256 ダイジェストを保存します。ユーザーの author/reviewer リレーションシップは SetNull を使用します。プライベートドラフトは、そのユーザーが削除されると削除されます。レポーティングレコードは、親の engagement/finding のライフサイクルに従います。

  • User: id、username、passwordHash、role (Admin, User)、lastPasswordChange、lastLogin、sessions、createdAt、updatedAt。
  • Session: id、userId、expiresAt、createdAt — サーバー側のレコードにより、署名された各ログインセッションをログアウト時に個別に無効化できます。
  • LoginRateLimit: key、count、 — アトミックなソースおよびパスワード確認試行の予約。パスワード検証には上限付きの同時実行制限もあります。

新しいフィールドの追加

既存のモデルに新しいフィールドを追加するには (例: Engagement の focus):

  1. prisma/schema.prisma を開き、目的のモデルにフィールドを追加します: ```prisma model Engagement { id String @id @default(uuid()) codeName String focus String? // new field ... }
    root@kitploit:~
  2. prisma/schema.prisma への変更はすべて、次のコマンドを実行する必要があります: ```bash npx prisma migrate dev --name describe_your_change
    root@kitploit:~

これによりマイグレーションが作成され、データベースが更新され、Prisma Client の型が再生成されます。

  1. 影響を受ける UI コンポーネント、フォーム、バリデーションロジック、またはサーバーアクションを必要に応じて更新します。

セキュリティアーキテクチャ

  1. 認証とアカウント: デフォルトの admin アカウントは Prisma seed を介して生成されます。Admin ロールはすべてのレコードに対して完全な作成/編集/削除アクセス権を持ちます。User ロールは findings と screenshots の作成、編集、削除が可能です。その他すべてのエンティティ(engagements、clients、contacts、operators)はユーザーにとって読み取り専用です。すべてのダッシュボードページは、機密データを読み取る前にデータベースに対してセッションを更新します。管理者のみが Admin ページ(/dashboard/users)にアクセスし、アカウントを管理し、アプリケーション全体のハイライトカラーを変更し、データベースのバックアップ、復元、リセットを行うことができます。バックアップ、復元、リセットにはパスワードの再確認が必要です。バックアップの作成は Server Action です。ブラウザのダウンロードは GET /api/db/backup?file=… を使用し、Admin セッションと HttpOnly Cookie 内の 5 分間の署名付きグラントを伴います。
  2. セッション管理: セッションは HttpOnly、SameSite=Lax Cookie に保存された jose JWT と、ログアウトで失効する対応するサーバー側の Session 行を使用します。Cookie の有効期限は意図的に省略され、ブラウザセッションの動作を維持します。署名付きトークンとデータベースレコードの両方が 1 日後に期限切れになります。トランザクション的なアドミッションは、アカウントごとに最大 10 個のアクティブセッションを保持します。
  3. アプリケーションセキュリティ:
    • Next.js Edge Proxy(src/proxy.ts)は、すべての保護されたルートに対してセッションチェックと 90 日間のパスワードローテーションを強制します。
ツールをダウンロード
スキャナー/エクスポートファミリー受け入れられるエクスポート
Burp SuiteIssues XML (不活性な内部スキーマDTDを含む)
Nessus / TenableNessus v2 XML (.nessus)
NmapXML。開いているポートとそのスクリプト出力は情報提供の観察事項となり、推測された脆弱性ではありません
OpenVAS / GreenboneネイティブXMLレポートまたはGMP get_reports_response
OWASP ZAPサイトとアラートを含む従来のJSONレポート
NucleiJSON Lines (-jsonl)
Qualysスキャン結果XML (SCAN/IP構造)。別個のホスト検出API形式ではありません
Semgrep / CodeQL およびその他のSARIFプロデューサーSARIF JSONのruns、rules、results
resetAt
  • ApplicationSetting: highlightColor (Red、Blue、Teal、Green、Purple、Amber のいずれか) と updatedAt を持つ、アプリケーション全体のシングルトン設定レコード。
  • Engagement: id、codeName、clientId、chargeCode、status (Prep、Recon、Testing、Reporting、Complete)、focus、type (AI、Code_Review、Firewall、Multi、Pentest、Phishing、Physical、Purple_Team、Red_Team、USB_Drop、Vishing、Web_App、Wireless)、location (Internal、External)、startPrep、endPrep、startRecon、endRecon、startTesting、endTesting、startReporting、endReporting、outbrief、objectives、targets、exclusions、notes、operators (M:N)、contacts/trustedAgents (Contact との M:N)、findings、findingContexts、createdAt、updatedAt。
  • Client: id、company (DB カラム: companyName)、address、city、state、zip、phone (DB カラム: phoneNumber)、website、notes、contacts、engagements、createdAt、updatedAt。
  • Contact: id、clientId、name、title、email、phone (DB カラム: phoneNumber)、notes、assignedEngagements、trustedEngagements、createdAt、updatedAt。
  • Finding: id、engagementId (任意)、title、category、severity、background、remediation、supportingData (DB カラム: supportingLinks)、screenshots、engagementContext、createdAt、updatedAt。
  • EngagementFindingContext: id、engagementId、findingId、observation、affectedHosts、createdAt、updatedAt。
  • Screenshot: id、findingId、filePath、description、createdAt。
  • Operator: id、name、title、email、phoneNumber、discord、github、notes、engagements (M:N)、createdAt、updatedAt。
  • Next.js Server Actions は、組み込みの同一オリジン保護により CSRF リスクを軽減します。
  • Prisma は、すべてのクエリをパラメータ化することで SQL インジェクションを自動的に緩和します。
  • React は、レンダリング時に HTML 要素を自動的にエスケープすることで XSS を緩和します。
  • スクリーンショットは所有者のみの権限と、上限付きの集約/ファインディングごとのクォータで保存されます。削除には復元可能な保留マーカーを使用します。ダッシュボードの起動、アップロード、バックアップは、ディスク上のファイルをデータベース参照と照合し、クリーンアップの失敗は監査出力に記録され、詳細なエラーはサーバーログに記録され、管理者に警告が表示されます。失敗したダッシュボードの照合は、プロセスごとに 1 分あたり最大 1 回再試行されます。アップロードとバックアップは引き続きストレージを即座に検証します。認証された /api/uploads ルートは IDOR を防止し、no-store レスポンスを返します。