セキュリティとコンプライアンス

このページは、セキュリティレビュー担当者、IT 管理者、そして「これを導入しても安全か?」に答えなければならないすべての人のためのものです。

ひとことで言う脅威モデル

ObjectOS は あなた自身の ネットワーク内で単一の Node.js プロセスとして動作し、あなた自身の データベースと通信し、決して外部へ通信を行いません。侵害が及ぶ影響範囲は、接続先のデータベース上のデータに限られ、それ以上ではありません。

データレジデンシー

ObjectOS は、明示的に構成しない限り 外部への通信を一切行いません(OIDC ディスカバリ、メールプロバイダー、AI プロバイダー、Webhook ターゲット、外部ストレージ)。外部へのフォンホームも、ライセンスサーバーの確認も、アップデートの確認も行いません。

暗号化

認証

組み込み機能(@objectstack/plugin-auth 経由、Better Auth による):

• 検証 + リセット付きのメール / パスワード認証
• 失効機能を備えたセッション管理
• ソーシャル OAuth(Google、GitHub、Microsoft、Apple、…)
• エンタープライズ OIDC/SSO(Okta、Entra ID、Keycloak、Ping)
• 二要素認証(TOTP)
• パスキー / WebAuthn
• マジックリンク
• CLI / ブラウザのデバイスフロー
• API キー(ハッシュ化、有効期限設定可、失効可、ユーザーに紐付け)

認証 を参照してください。

認可

階層的な強制(@objectstack/plugin-security 経由):

1. オブジェクト権限 — パーミッションセットごと、オブジェクトごとの CRUD
2. 行レベルセキュリティ — クエリに注入される宣言的なポリシー式。省略不可
3. フィールドレベルセキュリティ — レスポンスから除去 / 書き込み時に拒否されるフィールド
4. 組織スコープ — マルチテナント分離。バイパスには明示的な viewAllRecords が必要

システムコンテキストの操作はチェックをバイパスするため、内部ジョブ / マイグレーションを実行できます。これらの経路は監査可能です。

権限 を参照してください。

監査とエビデンス

監査機能がロードされている場合(@objectstack/plugin-audit):

• すべてのオブジェクトにわたるすべての CRUD 操作 → 監査行。
• フィールド変更の前後の値。
• 認証、権限付与、セッション失効イベント。
• 監査行は イミュータブル です。変更はできず、アーカイブのみ可能です。
• 保持期間は構成可能です。DB のアーカイブポリシーと組み合わせてください。

これは SOC 2 CC6/CC7、ISO 27001 A.12.4、HIPAA §164.312(b)、GDPR 第 30 条のエビデンス基盤となります。

コンプライアンスフレームワーク

ObjectOS は、一般的なフレームワークが求める 技術的なプリミティブ を提供します。認証はデプロイメントの属性であってソフトウェアの属性ではありませんが、コントロールはきれいにマッピングできます。

ObjectOS そのものは 認証を取得していません。認証は実行中のデプロイメントに対するものであって、バイナリに対するものではないためです。あなたのデプロイメントは認証を取得でき、すでに多くが取得しています。

シークレットの取り扱い

シークレットをアーティファクト(objectstack.json)、Docker イメージ、compose ファイル、Git に 決して 焼き込まないでください。Console の設定 UI は環境変数で管理される値をロックして表示するため、オペレーターが誤って上書きすることはありません。

ネットワークモデル

必須のインバウンド:

• あなたのイングレス / ロードバランサーから ObjectOS への HTTPS、ポート :3000(デフォルト)。

必須のアウトバウンド(これらの機能を構成する場合のみ):

• あなたのデータベース(Postgres / Mongo / Turso / …)。
• S3 互換ストレージ(S3 アダプターで storage 機能を有効にした場合)。
• OIDC ディスカバリ URL(SSO を有効にした場合)。
• メールプロバイダー API(Resend / Postmark)。
• AI プロバイダー API(OpenAI / Anthropic / Google / …)。
• Webhook ターゲット。

これがエグレスサーフェスのすべてです。さらに削減するデプロイメントについては エアギャップ を参照してください。

AI: ツール、承認、分離

AI Builder は、あなたが公開する最もセキュリティに敏感なサーフェスであるため、上記すべてに加えて独自の強制レイヤーを備えています。

AI が状態を変更する仕組み

モデルはあなたのデータベースに 直接書き込むことはできません。状態が変化する唯一の方法は、AI サービスが受信、検証、キューイングする構造化されたツールコールを発行することです。その連鎖は次のとおりです。

user prompt
  → model emits tool call (e.g. add_field { object: 'ticket', name: 'severity', type: 'select' })
  → AI service validates payload against the tool's Zod schema
  → if the tool is "mutating": queue as pending action (no state change yet)
  → human reviewer approves → mutation applied → audit row written
  → if the tool is "read-only": run immediately, response returned to model

11 個のファーストパーティのメタデータツール(Build → AI Builder を参照)に加え、宣言された各アクションごとに 1 つの action_<name> ツールがあります。すべてのツール — ファーストパーティであれカスタムであれ — は同じライフサイクルを持ちます。

パーミッションキー

重要な区別は ai:chat ≠ ai:approve です。アシスタントが機能するように、ほとんどのユーザーには ai:chat を付与してください。ai:approve は、構造的な変更をレビューすべき管理者 / アプリ所有者のために確保してください。これにより、エンドユーザーは安全に「バイブビルド」できます。最悪の場合でも、他の誰かが受け入れなければならない不適切な変更をキューに入れるだけです。

テナント分離

• エージェント、会話、ナレッジベース、保留中アクションは、1 つの Environment(テナント)にスコープされます。同じ marketplace パッケージから同じエージェント定義がインストールされていたとしても、テナント A はテナント B の会話、AI が提案したツール、ナレッジコーパスを見ることはできません。
• メタデータツール(create_object、add_field、…)は、呼び出し元のテナント内の アクティブパッケージ に対して動作します。その外には到達できません。
• ツール入力は CEL で検証され、エンジンは予約済みのシステムパッケージ(sys.*)や他テナントのオブジェクト名への参照を拒否します。

監査イベント

監査機能がロードされている場合:

• ai.chat.message — すべてのユーザー / アシスタントメッセージ、モデル + トークン数付き
• ai.tool.call — ツール名、検証済み入力、完全な出力(またはエラー)
• ai.pending_action.queued — 提案されたミューテーション、完全な差分
• ai.pending_action.approved / .rejected — 誰が、いつ、なぜ決定したか
• ai.metadata.applied — メタデータストアへの実際の書き込み、差分付き

これらの行はイミュータブルであり、セキュリティレビューやチャージバックのためにエクスポートできます。(プロバイダー、モデル、ユーザー)ごとのトークン数はコスト配賦に利用されます。

プロンプトインジェクションへの姿勢

間接プロンプトインジェクション(例: エージェントが取得するドキュメント内の悪意あるコンテンツ)は現実的なリスクです。ObjectOS は構造上、影響範囲を低減します。

• AI は ツール検証をバイパスできません。悪意あるペイロードを発行するよう仕向けられたとしても、Zod スキーマが不正な入力をエンジンに到達する前に拒否します。
• ミューテーションを行うツールは常にキューイングされます。注入されたプロンプトが密かにデータベースへ書き込むことはできません。
• ツールコールは、モデルのサービスアカウントの権限ではなく、エンドユーザーの権限 を継承します。ユーザーは、Console や REST で自分ができないことを AI を使って行うことは決してできません。
• エージェントにロードされる Skills はバージョン管理され、明示的です。Build → IDE Skills および Build → AI Builder を参照してください。

外部 AI プロバイダーのデータフロー

プロバイダー(OpenAI、Anthropic、…)を構成した場合、ネットワークから出るのは次のものだけです。

• モデルが必要とする会話履歴(AI サービスの redact 設定に従う — Configure → AI を参照)
• ツール定義(名前、JSON スキーマ — レコードデータは含まない)
• モデルが続行するために必要なツール出力(例: ユーザーが明示的に要求したクエリ結果)

エアギャップデプロイメントの場合、AI サービスをローカルの Ollama / vLLM / TGI エンドポイントに向ければ、同じフローがあなたの境界内に留まります。

脆弱性の開示

セキュリティ問題は security@objectstack.ai へ非公開で報告してください。営業日 1 日以内に対応します。セキュリティ上の問題について、公開された GitHub issue を作成しないでください。

サプライチェーン

• 事前ビルドされたイメージは github.com/objectstack-ai/objectos から、再現可能なビルドプロビナンス付きで公開されています。
• すべての @objectstack/* パッケージは GitHub 上でソースが公開されています — Apache-2.0、難読化なし。
• 本番環境では SHA 固定のイメージタグ(sha-<short>)を使用してドリフトを回避してください。Docker を参照してください。

推奨ハードニングチェックリスト

• エッジで TLS を本物の証明書で終端している。
• OS_AUTH_SECRET は 32 バイト以上のランダム値で、シークレットマネージャーに保管されている。
• データベース接続が TLS を使用している。
• TLS 検証後に HSTS を有効化している。
• CORS オリジンが明示的である(認証情報付きで * を使用していない)。
• 認証エンドポイントにレート制限がかかっている(10/min/IP を推奨)。
• 監査の保持期間がポリシーに合致している。
• 人間のアカウントには OIDC、マシンアカウントには API キーを使用している。
• バックアップ + リストアの訓練を実施し、所要時間を計測している。
• ネガティブテスト: クロス組織アクセスが拒否される、フィールドセキュリティが維持される、期限切れセッションが拒否される。
• イメージが sha-<short> または semver タグに固定されている。
• 各リリース前に CI で os doctor がクリーンである。

本番稼働の完全なチェックリストについては 本番準備 を参照してください。