パイプラインを守る：イベントレイヤーにおけるゼロトラスト

SchemaBridge Team · 2026-01-03 · Security, Zero Trust

長時間実行ワークフローを守る。参照のみのシークレット、ジャストインタイム注入、ゼロトラストなアイデンティティ。

見えない境界：従来のセキュリティがイベントレイヤーで通用しない理由

モノリシックなアプリケーションの世界では、セキュリティは単純でした。サーバーの周りにファイアウォールという「要塞」を築き、ネットワーク、ハードウェア、ソフトウェアを自分で管理していました。入口にアイデンティティプロバイダー（IdP）を置き、いったん内側に入ったリクエストは「信頼済み」とみなされました。これが Castle-and-Moat（城と堀）型のセキュリティモデルです。

しかし、分散した長時間実行のビジネスライフサイクル——私たちがイベントレイヤーと呼ぶもの——の時代に入り、城壁は崩れ去りました。アプリケーションはもはや一か所には存在しません。マイクロサービス、サードパーティの SaaS API、外部からの Webhook で起動されるヘッドレスなワーカーの群れです。境界はありません。データは常に移動しており、自分が書いていないコードによって変換され、完全には管理できないデータベースに保存されます。

このように断片化した環境では、古い堀は役に立ちません。エンジン自体の命令セットに組み込まれた、新しいセキュリティパラダイムが必要です。私たちはこれをトランザクショナル・ゼロトラストと呼んでいます。

セキュリティの悪夢：認証情報の漏えい

アーキテクトとして、あなたはイベントレイヤーで根本的かつ存亡に関わる脅威に直面します。中でも最も深刻なものの一つが認証情報の漏えいです。

連携には API キーが必要です。Stripe のキー、Salesforce のトークン、社内データベースのパスワードなどがあります。「グルーコード」のスクリプトでは、これらのシークレットは環境変数に保存されたり、JSON ペイロードで受け渡されたりすることがよくあります。開発者がデバッグのためにうっかり console.log(payload) を追加したり、ログ基盤が侵害されたりすれば、本番の重要なシークレットが外部に露出します。漏えいした、あるいは管理の甘い認証情報は、クラウドにおける侵害の主要な原因の一つです。

SchemaBridge のセキュリティスタック：インフラレベルでの分離

SchemaBridge では、「良いコーディング慣行」だけに頼るのではなく、インフラによる制約でこれらの脅威に対処するようにセキュリティモデルを設計しました。たとえばテナントのスクリプトは、認証情報を持たずネットワークの外向き通信（egress）もできない分離されたスクリプトランナー上の GraalVM で実行されます。そのため、スクリプトが試みたとしても、あなたのシークレットやプラットフォームのデータベースには到達できません。

ゼロトラストなアイデンティティ：API キーを超えて

分散したジャーニーでは、アイデンティティは動的かつスコープが限定されたものでなければなりません。すべてのワーカーで単一の「ルート」API キーを使うことは、壊滅的なリスクです。

SchemaBridge は認証情報に参照のみのモデルを採用しています。

1. 暗号化されたシークレットストア：本番の API キーがワークフローの設定や状態に保存されることはありません。キーは暗号化されたシークレットストア（EntitySecretRepository）に置かれ、保存時に AES-256-GCM で暗号化され、キーローテーションにも対応しています。

2. 参照のみ：ビジュアルグラフ上に表示されるのは、名前によるシークレットへの参照（例：{{ secrets.STRIPE_KEY }}）だけです。名前は意図的に静的です。式はサポートしていません。計算された名前を許すと、どの認証情報を読むかをペイロードが選べてしまうからです。

3. ジャストインタイム注入：Gateway Vertex が HTTP リクエストを送信するその時点で初めて、エンジンは参照を解決し、トークンを復号して、送信ヘッダーまたはボディに埋め込みます。シークレットは設定式やスクリプトからは読み取れず、名前付きシークレットが vertex の設定やワークフローの状態にコピーされることもありません。

{
  "type": "GATEWAY",
  "config": {
    "url": "https://api.stripe.com/v1/refunds",
    "method": "POST",
    "headers": {
      "Authorization": "Bearer {{ secrets.STRIPE_KEY }}"
    }
  }
}

さらにいくつかのガードレールがあります。プラットフォームの外に出られるのは bearer、API キー、ヘッダーマップ型のシークレットだけであり（HMAC 署名鍵は決して外に出ません）、プラットフォーム管理のシークレットをワークフロー作成者が注入することはできません。

一つの例：シークレット漏えいを減らした決済アグリゲーター

大規模な加盟店基盤の送金を扱い、いくつかの決済プロバイダーと連携している、仮想の決済アグリゲーターを考えてみましょう。

課題

Kubernetes Secrets 上に構築された旧システムを想像してください。各プロバイダーのキーは環境変数として Node.js ワーカーに読み込まれています。ある日、開発者がデバッグ用のログを追加し、失敗したリクエストに対して誤って process.env オブジェクトを出力してしまいます。このような構成では、プロバイダーのキーがエンジニアリングチーム全員がアクセスできる ELK スタックに漏れ出す可能性があります。これは重大なセキュリティ侵害であり、大規模なキーローテーションと規制当局への正式な報告が必要になるでしょう。

SchemaBridge によるアプローチ

では、同じチームが決済フローを SchemaBridge に移行したと想像してみましょう。

1. シークレットストアへの移行：プロバイダーのキーを SchemaBridge のシークレットストアに移し、認証情報ごとに名前付きシークレットを一つ作成します。

2. 名前による参照：各 Gateway vertex は、自身の認証情報を値ではなく名前（{{ secrets.stripe-key }}）で参照します。

3. よりクリーンなログ：Gateway は外向き送信の時点でのみ値を埋め込むため、ログにはシークレットの参照しか表示されません。開発者がステップのペイロード全体をログに出力したとしても、そこにシークレットの値が入っていたことは一度もありません。

想定される結果

未来：標準としてのゼロトラスト・オーケストレーション

今後 10 年で、「Castle-and-Moat」モデルは完全に姿を消すと私たちは考えています。分散システムの個々の vertex が、それぞれ独自のマイクロ境界として扱われるようになるでしょう。セキュリティは「レイヤー」から命令そのものの性質へと移っていきます。

私たちはその方向に向けて SchemaBridge を開発しています。信頼できないコードの分離（テナントのスクリプトは認証情報も外向き通信も持たない分離されたランナーで実行されます）と、参照のみのシークレット注入を組み合わせることで、認証情報に触れるすべてのコンポーネントに生の認証情報を渡すことなく、複雑な連携を構築できるようにすることを目指しています。

安全なオーケストレーションのための専門家チェックリスト

「実戦で鍛えられた」イベントレイヤーを構築するには、次の 3 つの譲れないルールに従ってください。

1. シークレットを反転させる：シークレットはコードにもワークフローのペイロードにも置くべきではありません。可能な限り最後の瞬間に解決し、ログに記録されるものからは遠ざけてください。

2. 最小権限のアクセス：配送ラベルを処理するワーカーが、請求ゲートウェイの API キーを持つべきではありません。プラットフォームが許す限り、認証情報のスコープを狭くしてください。（SchemaBridge ではシークレットのスコープはワークスペース単位なので、認証情報を共有してはならない職務を分けるには、ワークスペースを分けてください。）

3. すべてのアクセスを監査する：一般的なプラクティスとして、誰がどのシークレットに、なぜアクセスしたかを記録しましょう。改ざん不可能な監査証跡は、フォレンジック調査における最良の防御です。SchemaBridge は現時点ではシークレットへのアクセスごとの監査イベントを発行していないため、それが必要な場合は独自の管理策と組み合わせてください。

結論：信頼は意図ではなくインフラの上に築かれる

「教育」だけで安全なシステムにたどり着くことはできません。人為的なミスは避けられません。本当のセキュリティは、誤った操作を偶然に行うことを難しくする構造的な制約の上に築かれます。SchemaBridge はそうした制約のいくつかを提供しており、認証情報が漏れ出す経路を減らしながら、機能開発に集中できるようにします。

関連記事：永続的な遅延 — 数週間から数か月にわたる時間ベースのビジネスライフサイクルを管理する。

詳しく見る