Introducing Dhal

概要

現代のAPIシステムは、単一の境界だけでは保護できない。プロダクションのSaaSは、CDN、リバースプロキシ、API Gateway、認証レイヤー、アプリケーションのミドルウェア、データベースポリシー、オブザーバビリティ基盤、インシデント対応プロセスの背後で動作することが多い。それぞれのレイヤーが見ている情報は異なる。エッジは通信量、送信元、ネットワーク上のシグナルを見る。認証レイヤーはアイデンティティを見る。アプリケーションは、ルート、リクエストボディ、テナント、APIキー、レスポンス結果、ビジネスフロー、失敗パターンを見る。

Dhalは、アプリケーションだけが見ることのできるセキュリティ領域のために作られた。

Dhalは、Node.js向けのアプリケーションネイティブなWeb Application Firewallであり、リクエストセキュリティ・ミドルウェアである。リクエストパスの内部で動作し、Express、Fastify、NestJS、Koa、Node.js上のHono、そしてraw node:httpアプリケーションに対して、決定論的でルートを理解した制御を提供する。DhalはCDN、エッジ、ネットワーク、認証、認可、バリデーション、インフラ制御を補完するものであり、DDoS対策、アプリケーション固有の認可、安全な開発実践を置き換えるものではない。

本稿では、なぜDhalを構築したのか、どのようなギャップを埋めるのか、どのような設計上の仮説に基づいているのか、そしてアプリケーションに近いリクエスト保護の将来像を述べる。

なぜDhalを作ったのか

Rokadが扱うプロダクションシステムでは、セキュリティ課題が単一の明白な脆弱性として現れることは多くない。より頻繁に見られるのは、実務的な問題である。チームは適切なインフラを持ち、主要なフレームワークを使い、認証も導入し、CDNやプロキシの背後にデプロイしている。それでも、アプリケーション内部でリクエストレイヤーのセキュリティポリシーを明確に表現する方法がない。

そのギャップは、日常的なエンジニアリング上の問いとして表れる。

• ログインルートは公開コンテンツルートとは異なるレート制限を持つべきか。
• 認証失敗が繰り返された場合、その後のリクエスト評価を変えるべきか。
• 怪しいUser-Agentは全体でブロックすべきか、内部ルートだけでブロックすべきか、それとも記録に留めるべきか。
• JSON APIは、想定外のContent-Typeをルートロジック実行前に拒否すべきか。
• 新しいポリシーはmonitorモードから始め、replayテスト後にblockへ移行すべきか。
• セキュリティ判断は、機密情報を露出せずに構造化されたテレメトリを出すべきか。
• 水平スケールされたNode.jsインスタンスは、カウンターとセキュリティシグナルを共有すべきか。

これらは大企業だけの問題ではない。小規模SaaS、内部ダッシュボード、公開API、AIプロダクト、マーケットプレイス、開発者向けプラットフォーム、受託開発のシステムでも同じ問題が起きる。アプリケーションはより良い判断に必要な文脈を持っていることが多い。しかし実際の判断は、場当たり的なミドルウェア、ルートハンドラー、プロキシ設定、コピーされたレート制限ヘルパー、インシデント後のパッチに分散してしまう。

Dhalは、この分断を減らすために生まれた。

私たちは、単にいくつかの攻撃シグネチャを追加するだけのパッケージを作りたかったわけではない。設定をプロダクションの成果物として扱うリクエストセキュリティ層を作りたかった。つまり、明示的で、バージョン管理可能で、観測可能で、再現可能で、段階的に安全に展開できるものだ。そのためDhalはmonitorモードから始まり、ルートプロファイルを持ち、診断を提供し、分散ストアと統合し、構造化イベントを出し、安定したv1契約を定義している。

中心的な仮説：エッジはすべてを見られない

エッジ制御は不可欠である。CDN、リバースプロキシ、クラウドWAF、ネットワークファイアウォール、レート制限ゲートウェイ、DDoSプロバイダーは、アプリケーションがCPUを消費する前に大量の不要なトラフィックを処理できる。ネットワーク規模の制御の多くは、そこで行うのが正しい。

しかしエッジシステムは、通常、アプリケーションの完全な意味論を持たない。/api/loginがパスワードエンドポイントであること、/api/invoices/:idがテナントに属すること、あるリクエストが直近1分間に5回認証失敗していること、ユーザーが匿名か内部ユーザーか、リクエストボディがすでにフレームワークによってパースされているか、あるルートが他より厳しいモードを選んでいるかを知らない場合がある。

この違いは重要である。API悪用の多くは文脈依存だからだ。OWASP API Security Top 10には、Broken Authentication、Unrestricted Resource Consumption、Unrestricted Access to Sensitive Business Flows、SSRF、Security Misconfigurationなどが含まれる。OWASP Automated Threatsは、Credential Stuffing、Scanning、Scraping、Token Cracking、Carding、Scalping、Denial of Inventoryなどを、単一の実装バグの悪用ではなく、正当なWeb機能の自動化された悪用として整理している。

Dhalの仮説は単純である。エッジセキュリティを維持しつつ、アプリケーション文脈を使えるアプリケーションネイティブな層を加えるべきである。

Dhalが埋めるギャップ

Dhalはすべてのセキュリティ製品を置き換えるものではない。Dhalは、インフラ制御とアプリケーションコードの間にある特定のギャップを埋める。

1. ルートを理解したポリシー

公開ルート、ログイン、Webhook、ファイルアップロード、管理API、GraphQLエンドポイントは同じリスクを持たない。グローバルな単一ポリシーは、重要ルートには弱すぎるか、通常トラフィックには厳しすぎる。

Dhalはルートプロファイルを導入する。モード、制限、ルール、レスポンス、タグ、抑制、ポジティブセキュリティ制御をルート単位で設定できる。アプリケーション全体はmonitorモードのまま、レビュー済みの認証ルートだけをblockモードにすることもできる。

2. Monitor-firstな展開

セキュリティ制御は、証拠が少ないまま強制されると失敗する。False Positiveは単なる不便ではなく、可用性インシデントになり得る。そのためDhalのロールアウトは観測から始まる。

monitorモードでは、Dhalはブロックしたであろうリクエストを記録しながら、実際には通過させる。チームはwouldBlockイベントを確認し、正常トラフィックと悪性トラフィックをreplayし、抑制を調整し、その後ルート単位でblockへ移行できる。これは本番でリスクを下げる実際のやり方に近い。まず測定し、その後に強制する。

3. 実運用向けの分散状態

単一プロセスのデモでは、メモリ上のカウンターで十分かもしれない。しかし本番では、複数のNode.jsインスタンスが同じAPIを提供することが多い。各インスタンスがリクエストの一部しか見ない場合、レート制限、Credential Stuffingのシグナル、レピュテーション判断は弱くなる。

DhalはRedisまたはValkeyによる共有カウンターと共有シグナルをサポートする。また、設定上はRedisベースの制限を宣言しているのに、分散ストアが渡されていないenforcement構成では起動を拒否する。この拒否は意図的である。セキュリティツールは、誤解を招く姿勢へ静かに劣化してはならない。

4. 振る舞いを考慮した保護

シグネチャは有用だが、現代の悪用はしばしば振る舞いとして現れる。Credential Stuffingは1つの怪しいpayloadではなく、認証結果の繰り返しから見える。Bot活動も、単一のUser-Agent文字列だけではなく、スコアリング、複数のシグナル、False Positive制御を必要とする。

Dhalは、SQL Injection、XSS、Path Traversal、SSRF、RCE、SSTI、GraphQL probes、Bot scoring、honeypots、Credential Stuffing、Content-Type検証、header制御、payload size制限、ルート単位のポリシーを組み合わせる。目的は完全な攻撃検知を主張することではない。プロダクションチームが説明し、調整できる一貫した判断面を提供することである。

5. 観測可能でプライバシーを意識した判断

セキュリティ判断は、運用者が説明できなければ不完全である。一方で、テレメトリは過剰に収集されるとプライバシーリスクになる。Dhalは構造化イベント、OpenTelemetry、署名付きwebhook、IP、identity、user-agentなどのredaction制御を提供する。

目的は機密リクエストデータを大量に記録することではない。目的は運用記録を残すことだ。どの判断が行われたのか、なぜそうなったのか、どのルールが関与したのか、どのルートが影響を受けたのか、そしてどう再現・調整できるのかを示す。

6. レビュー可能な自動化

Dhalには、dhal addによるガイド付きオンボーディング、dhal doctorによる診断、dhal readiness --productionによる準備状況評価、OpenAPIの検査とポリシー生成が含まれる。設計上の制約は、生成されたセキュリティ設定が常にレビュー可能であることだ。

生成されたポリシーはmonitorモードのまま維持される。所有者が管理しているルートプロファイルは保持される。Dhalは明示的なwriteコマンドなしにアプリケーションコードを自動変更しない。自動化は有用であるべきだが、見えないenforcementになってはならない。

設計の前提

第一に、セキュリティポリシーには局所性が必要である。ポリシーが保護対象の振る舞いに近いほど、テスト、レビュー、保守が容易になる。ルート単位の設定はアプリケーションの近くに属する。アプリケーションこそがルートの意味を所有しているからだ。

第二に、本番安全性は可用性の性質でもある。正当なユーザーを頻繁に壊すセキュリティ層は、回避されるか無効化される。monitorモード、replay、抑制、health bypass、内部エラー時の挙動、bounded telemetryは、セキュリティを展開可能にするための仕組みである。

第三に、ツールは境界を明確にしなければならない。DhalはNode.jsプロセス内で動作する。帯域枯渇、TLS handshake枯渇、kernel/socket枯渇、またはアプリケーションに届かないトラフィックを止めることはできない。Dhalの役割はアプリケーション層のリクエスト評価である。

第四に、オープンソースのセキュリティ基盤は検査可能であるべきだ。ポリシーフォーマット、CLIの挙動、リリース成果物、互換性マトリクス、v1契約は可視でなければならない。信頼は検査可能性と再現性から生まれる。

第五に、セキュリティ設定はエンジニアリングコードである。保存され、差分管理され、移行され、テストされ、説明され、レビューされるべきである。dhal.jsonは単なる設定ファイルではなく、ポリシー成果物である。

現在のDhal

Dhal v1.1.0は、Node.js向けの安定したアプリケーションネイティブWAFとして、ルートを理解した保護、分散制御、runtime safety、本番診断、安定したv1契約を提供する。

現在の表面には、Express、Fastify、NestJS、Koa、Node.js上のHono、raw node:httpのアダプター、IP allowlist/blocklist、IPv4/IPv6 CIDR、任意のreputation check、Redis/Valkeyによる分散rate limitと共有シグナル、injection probes、traversal、SSRF、RCE、SSTI、GraphQL、automation、bot、honeypot、credential stuffingに対するルール、JSON API向けのpositive security、ルート単位のmodeとlimit、OpenTelemetry、構造化イベント、署名付きwebhook、redaction、ガイド付きオンボーディング、保守的な修復、framework presets、OpenAPI policy generationが含まれる。

価値は単一のルールではない。価値はライフサイクルにある。慎重に生成し、monitorで始め、観測し、replayし、調整し、狭くblockし、段階的に広げ、説明可能性を保つ。

Dhalが意図的にしないこと

Dhalは認証を置き換えない。信頼されたidentity値を使ってrate limit、signal、telemetry、route policyを改善できるが、ユーザーが特定のビジネスオブジェクトへアクセスできるかを判断するものではない。

Dhalは認可を置き換えない。Broken Object Level AuthorizationやBroken Function Level Authorizationは、アプリケーションロジック、ドメインポリシー、または専用の認可レイヤーで解決されるべきである。

Dhalはバリデーションを置き換えない。アプリケーションスキーマ、型チェック、入力制約、ドメインバリデーションは引き続き必要である。

DhalはDDoS保護を置き換えない。トラフィックがNode.jsプロセスに到達した後に動作するため、アプリケーション実行前の大規模なトラフィックを吸収できない。

Dhalは安全な開発を置き換えない。リクエストの検査、スコアリング、制限、観測、ブロックを助けるが、安全でないコードを自動的に安全にするものではない。

私たちが考える将来

Dhalの長期的な方向性は、現代のJavaScript/TypeScriptシステムのためのアプリケーションネイティブなセキュリティ基盤である。その中で、決定論的な挙動、monitor-first rollout、明確な境界、プライバシーを意識したテレメトリ、レビュー可能なポリシーという約束は維持されるべきである。

より広いruntimeとframeworkへの対応

Node.jsエコシステムは、もはやExpressとFastifyだけではない。プロダクションアプリケーションは、meta-framework、server functions、Fetch風handler、file-based routing、混合デプロイ環境を使う。今後の作業では、これらの表面での採用を容易にしながら、保護境界を曖昧にしないことが重要になる。Dhalはどこで検査し、どのrequest objectを受け取り、どのresponse outcomeを観測でき、どの状態を共有できるのかを明確にすべきである。

アプリケーション構造からのより良いポリシー生成

OpenAPIからのポリシー生成は初期段階である。セキュリティ設定は実際のアプリケーション構造から導かれるべきだが、盲目的に強制されるべきではない。今後は、ルート分類、schema-aware positive security、提案型suppression、owner-managed override、confidence annotationを改善していくべきである。

Deceptionと悪用耐性

アプリケーションネイティブなセキュリティは、自動化を特定する低リスクなシグナルを作ることができる。honeypot header、route、parameter、deceptive pathは初期の例である。今後はbot、scanner、credential attack、token enumeration、business-flow automationに対するより構造化されたdeception controlを発展させられる。

フォームとビジネスフローの保護

重大な攻撃の多くは古典的なinjectionではない。login、signup、reset、checkout、referral、voucher、waitlist、inventoryなどのフローを狙う。Dhalはビジネスロジックをアプリケーション内に保ちながら、悪用されやすいフローを保護しやすくすべきである。form shield、token control、attempt sequencing、flow-level rate limit、user journeyを表すroute groupなどが将来の方向になり得る。

隠れたテレメトリのない運用インテリジェンス

Dhalは隠れたパッケージテレメトリを避け続けるべきである。セキュリティツールには信頼が必要だ。一方で、チームはより良いローカルかつ所有者制御のインサイトを必要としている。より安全なredaction、deployment posture scoring、replay analysis、false-positive summary、policy drift detectionなどである。

正しい方向は、所有者が制御するインサイトであり、静かなデータ抽出ではない。

結論

Dhalが存在する理由は、現代のAPIにはIPアドレスや静的シグネチャ以上を理解するセキュリティ層が必要だからである。アプリケーションは、エッジが通常持たない文脈を持っている。ルート、identity、body、response outcome、tenant、API key、deployment assumption、business-flow semanticsである。この文脈は、散在するミドルウェアやインシデント後のパッチにセキュリティロジックを埋め込むことなく利用できるべきである。

正しいモデルは、エッジセキュリティかアプリケーションネイティブセキュリティか、ではない。両方である。

Dhalの役割は、アプリケーション層のリクエスト保護を明示的で、観測可能で、テスト可能で、安全に展開できるものにすることだ。最初の安定リリースがNode.jsに集中しているのは、このエコシステムが大きく、多様で、運用上も分断されているからである。将来はさらに広い。より多くのframework、より良いpolicy generation、より安全なbusiness-flow protection、より強いdiagnostics、そしてプロダクションチームが検査し拡張できるopen-source foundationである。

Dhalは単なるパッケージリリースではない。Dhalは、リクエストセキュリティをどのように作るべきかについてのRokadの立場である。アプリケーションに近く、境界に誠実で、rolloutに慎重で、本番に対して責任を持つという立場だ。

参考資料

• Dhal repository: https://github.com/rokadhq/dhal
• Dhal npm package: https://www.npmjs.com/package/@rokadhq/dhal
• Dhal documentation: https://rokad.co/en/docs/dhal
• Dhal product page: https://rokad.co/en/open-source/dhal
• OWASP API Security Top 10 2023: https://owasp.org/API-Security/editions/2023/en/0x00-header/
• OWASP Automated Threats to Web Applications: https://owasp.org/www-project-automated-threats-to-web-applications/
• NIST SP 800-53 Rev. 5: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final