GRC Lake

セキュリティ証拠を、追跡可能な管理策評価とレビュー可能な監査ワークペーパーに変換します。 オープンソースでセルフホスト可能です。すでに運用しているシステムやセキュリティレイクから証拠を読み取り、バージョン管理された管理策テストを評価し、証拠と記録されたレビュー判断を結果とともに保持します。

• 追跡可能： 結果からソースレコードやルールのバージョンをたどり、記録されたマッピング判断を確認できます。スナップショットはハッシュチェーン形式の台帳を形成し、再検証できます。
• 既存環境で動作： クラウド、ID、エンドポイント、コードの各システムに直接接続するか、レイク内のOCSFテーブルをクエリできます。
• 1つの管理策を複数のフレームワークに対応： 再利用可能なセーフガードをSOC 2、ISO 27001、NISTなどにマッピングし、レビュー済みのマッピングと提案されたマッピングを分けて管理します。

ライブデモを開く → 記録済みの合成データを使ってコンソールを操作できます。ホスト型デモは読み取り専用で、システムには接続せず、ライブプロバイダーへの対応を示すものでもありません。インストールは不要です。

クイックスタート · 製品ツアー · 証拠の接続 · すでにOCSFを利用していますか？ · フレームワーク · パフォーマンス · セルフホスト · ドキュメント

クイックスタート

Python 3.11以上とuvが必要です。

uvx --from "grc-lake[server]" grc-lake demo

合成企業データを一時的なレイクに読み込み、認証なしでコンソールをlocalhost:8787で起動して、ブラウザーを開きます。Ctrl+Cで停止すると、レイクが削除されます。pipを使う場合は、pip install "grc-lake[server]"を実行してから、grc-lake demoを実行してください。

最初のタスク： 失敗している管理策を見つけ、証拠とマッピングを確認し、固定された結果をエクスポートします。サンプルデータのチュートリアルに続いて、監査人向けワークペーパーの例を確認してください。

実環境での評価については、範囲を限定したパイロットガイドに従ってください。1つのソースから始め、1つの結果を独立して確認した後、再度収集してレビューします。

grc-lake fixtures load --company golden --out ./lake --rebase-times
grc-lake serve --server --allow-insecure-no-auth --lake ./lake

git clone --branch v0.3.18 --depth 1 https://github.com/koda-ai-studio/grc-lake.git
cd grc-lake && docker compose up

git clone https://github.com/koda-ai-studio/grc-lake.git
cd grc-lake && uv sync --frozen --extra dev --extra server && make demo-local

pip install "grc-lake[server,mcp]"
GRC_LAKE_LAKE=./lake grc-lake-mcp

収集 → 評価 → 解決 → エクスポート。 これらのコンソール画面は、0.3.17 リリース向けに更新された、同梱の合成企業データを使用しています。ソースの動作を示すものであり、公開パッケージの検証については リリース記録をご覧ください。

評価の概要から始める

評価済みのカバレッジ、未解決の指摘事項、エビデンスの鮮度、優先アクションを1つの画面で確認できます。

フレームワークのカバレッジを確認する

カタログ登録済み、マッピング済み、レビュー済み、評価済みの要件は、フレームワークごとに個別の指標として扱われます。

コントロールの結果とエビデンスを調べる

結果、担当者、またはフレームワークで絞り込み、コントロールを開いてエビデンス、指摘事項、鮮度、信頼度を確認できます。

コントロールファミリーと CCF をナビゲートする

Common Control Framework（CCF）は、再利用可能なセーフガードをファミリーにまとめ、フレームワーク要件にリンクします。提案されたマッピングは証明の対象にはなりません。 共通セーフガードの仕組み。

エビデンスグラフで指摘事項を追跡する

コントロール、セーフガード、エビデンス、リポジトリ、アセット間の正確なレコードをたどり、詳細を確認したり、集約表示したりできます。

AI アセットと次のアクションを確認する

担当者、環境、ガバナンスシグナル、次のアクションが表示されたモデルとエージェントです。 記録されたリネージはエビデンスの存在を示すものであり、コントロールに合格したことを示すものではありません （AI インベントリの意味）。

5分間のコンソールツアー · エビデンス調査の仕組み

アーキテクチャ

読み取り専用の収集データを決定論的な評価に取り込み、コンソール、REST API、CLI、MCP で共通のエビデンスおよび評価モデルを使用します。

flowchart LR
  Sources["Cloud · identity · code · existing lakes"] --> Collect["Read-only collection"]
  Collect --> Evaluate["Version-pinned control tests"]
  Evaluate --> Assessments["Assessment generations"]
  Assessments --> Review["Console · API · CLI · MCP"]
  Assessments --> Export["Snapshots · workpapers · OSCAL"]

エクスポート： 移植可能な CCF/OSCAL バンドル、 フレームワークカバレッジレポート、および検証可能な 監査人向けワークペーパー。復旧動作と API の制限については、 アーキテクチャガイドと評価コントラクトをご覧ください。

証拠を接続する

直接接続を使用するか、 既存のレイクを読み込みます。どちらも読み取り専用で、 評価証拠はお客様が運用するストレージに保持されます。

すでに OCSF をお使いですか？

テレメトリがすでにOCSFに正規化されている場合、 たとえば Amazon Security Lake や Databricks、Snowflake の OCSF テーブルにある場合は、GRC Lake からそれらのテーブルを指定してください。既存のソース取り込みパイプラインはそのままご利用いただけます。GRC Lake は 読み取り専用クエリを実行し、マッピング済みのコピーを保持して、インポートした行を評価します。組み込みプリセットはイベントを CCF のセーフガードに紐付け、 フレームワークの要件は、レビュー済みのクロスウォークに従って各セーフガードに紐付きます。

flowchart LR
  A["OCSF Authentication 3002<br/>successful Logon, is_mfa"] --> S1["SG-IDENTITY-001<br/>Logical access and MFA"]
  B["OCSF Account Change 3001<br/>Attach Policy"] --> S2["SG-IDENTITY-002<br/>Access review"]
  G["OCSF Group Management 3006<br/>Add User, Assign Privileges"] --> S2
  V["OCSF Vulnerability Finding 2002<br/>EC2 instance, ECR image"] --> S3["SG-VULNERABILITYMANAGEMENT-001<br/>Vulnerability management"]
  C["OCSF Compliance Finding 2003<br/>EC2 instance"] --> S4["SG-CONFIGBASELINE-001<br/>Hardened configuration baselines"]
  S1 --> R1["SOC 2 CC6.1 · NIST 800-53 IA-2<br/>CIS AWS 1.10 · …"]
  S2 --> R2["SOC 2 CC6.2 · ISO 27001 A.8.2 · …"]
  S3 --> R3["SOC 2 CC7.1 · ISO 27001 A.8.8<br/>NIST 800-53 RA-5 · …"]
  S4 --> R4["NIST CSF PR.PS-01 · …"]

CREDS='{"host":"dbc-example.cloud.databricks.com","warehouse_id":"abc123","catalog":"security",
        "schema":"ocsf","client_id":"<sp-client-id>","client_secret_ref":"DATABRICKS_CLIENT_SECRET"}'
OPTS='{"mappings":[{"preset":"ocsf/authentication","source":{"table":"ocsf_events"}},
                   {"preset":"ocsf/account_change","source":{"table":"ocsf_events"}}]}'
grc-lake connectors probe --lake ./lake --connector-id databricks-evidence-lake \
  --credentials-json "$CREDS" --options-json "$OPTS"
grc-lake connectors configure --lake ./lake --connector-id databricks-evidence-lake \
  --state enabled --credentials-json "$CREDS" --options-json "$OPTS"
grc-lake connectors sync --lake ./lake --connector-id databricks-evidence-lake
grc-lake frameworks assessment --lake ./lake

カバレッジにはいくつかの異なる意味があります。要件のカタログ登録、レビュー済みのマッピング、評価済みの結果は、それぞれ別のものです。まずはフレームワークごとのカバレッジマトリックスをご確認ください。提案段階のマッピングでは、証明済みの合格を示すことはできません。

フレームワークカバレッジ · 共通セーフガード · 監査への準備状況 · 適格性

パフォーマンスと適格性

承認済みのローカルグラフプロファイルでは、 最大10k件の合成レコードを持つ2つのテナントと、4つの同時接続クライアントを使用します。 制限は、ウォーム状態で正常に完了したリクエストのp95が≤500 ms、初回または期限切れの読み取りが≤5 seconds、 プロセスのRSSが≤1 GiBであり、過負荷時も両方のテナントで処理が進み続けることです。 記録された3回の実行はいずれも合格しました。受付時およびレート制限による拒否は別々に報告されます。 過負荷時にすべてのリクエストが成功するという保証ではありません。

このプロファイルの対象は、ローカルのSQLite上での認証済み深度1グラフ読み取りです。 インタラクティブな100k件の使用、ブラウザーでのレンダリング、外部ストレージ、本番環境の サイジングは適格性評価の対象外です。プロバイダーの適格性評価と 検証済みリリース記録は、それぞれ別途ご確認ください。

範囲を限定したライブ実行は、すべての判定をプロバイダーに照合したレシートとして記録されています。 AWSとGitHubのパイロット では、フレームワークの結果がない状態から、要件103件の不合格と証明済みの合格1件へと移行しました。 また、監査ログが入力済みのDatabricks実行も記録されています。 いずれも対象は1つのアカウントまたはワークスペースであり、プロバイダー全体の適格性を評価するものではありません。

セルフホスト

自分で管理するインフラストラクチャに、Docker または Helm を使ってデプロイできます。

• ローカル： ファイルシステムレイクを使用する、書き込み可能なレプリカを 1 つ配置します。
• 分散型： API レプリカとテナントワーカーで、PostgreSQL と S3 互換ストレージを共有します（分散型のガイド）。
• 本番環境： SSO とスコープ付き認証情報、保持期間、バックアップ／復元。

リリースには、署名済みの来歴情報と SBOM が含まれます（アーティファクトの検証）。 TrustOps からアップグレードする場合は、移行ガイドをご覧ください。

エンジニアリングレビュー

1 つのコントロールから始め、その証拠をたどって検証済みのワークペーパーを作成します。 合成アクセス／変更ワークフローでは、合格、不合格、欠落、古いデータ、矛盾、不完全な母集団のケースを実行します。

ドキュメント

すべてのドキュメント · ライセンス：Apache 2.0