|
| 1 | +[](https://github.com/OpenNHP/opennhp/blob/master/README.md) |
| 2 | +[](https://github.com/OpenNHP/opennhp/blob/master/README.zh-cn.md) |
| 3 | +[](https://github.com/OpenNHP/opennhp/blob/master/README.de.md) |
| 4 | +[](https://github.com/OpenNHP/opennhp/blob/master/README.ja.md) |
| 5 | +[](https://github.com/OpenNHP/opennhp/blob/master/README.fr.md) |
| 6 | +[](https://github.com/OpenNHP/opennhp/blob/master/README.es.md) |
| 7 | + |
| 8 | + |
| 9 | +# OpenNHP: ゼロトラストネットワークインフラストラクチャ隠蔽プロトコル |
| 10 | +攻撃者からサーバーとデータを隠すためのOSI第5層に位置する、軽量の暗号化駆動型ゼロトラストネットワークプロトコルです。 |
| 11 | + |
| 12 | + |
| 13 | + |
| 14 | + |
| 15 | + |
| 16 | +--- |
| 17 | + |
| 18 | +## セキュリティの利点 |
| 19 | + |
| 20 | +OpenNHPは*OSIセッション層*でゼロトラストの原則を実装しているため、次のような大きな利点があります。 |
| 21 | + |
| 22 | +- インフラの隠蔽による攻撃面の削減 |
| 23 | +- 不正なネットワーク偵察の防止 |
| 24 | +- 脆弱性の悪用を防ぐ |
| 25 | +- 暗号化されたDNSによるフィッシング防止 |
| 26 | +- DDoS攻撃に対する防御 |
| 27 | +- 細粒度のアクセス制御を実現 |
| 28 | +- アイデンティティベースの接続追跡 |
| 29 | +- 攻撃の帰属 |
| 30 | + |
| 31 | +## アーキテクチャ |
| 32 | + |
| 33 | +OpenNHPのアーキテクチャは[NISTゼロトラストアーキテクチャ標準](https://www.nist.gov/publications/zero-trust-architecture)に触発されています。以下の図に示すように、3つの主要なコンポーネント（**NHP-Server**、**NHP-AC**、**NHP-Agent**）を持つモジュール設計に従います。 |
| 34 | + |
| 35 | + |
| 36 | + |
| 37 | +> アーキテクチャとワークフローの詳細については、[OpenNHPドキュメント](https://opennhp.org/)を参照してください。 |
| 38 | +
|
| 39 | +## コア: 暗号化アルゴリズム |
| 40 | + |
| 41 | +暗号化はOpenNHPの中心にあり、強力なセキュリティ、高いパフォーマンス、およびスケーラビリティを提供するために最新の暗号化アルゴリズムを利用しています。以下は、OpenNHPで使用されている主要な暗号化アルゴリズムとフレームワークです。 |
| 42 | + |
| 43 | +- **[楕円曲線暗号（ECC）](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography)**：効率的な公開鍵暗号に使用されています。 |
| 44 | + |
| 45 | +> RSAと比較して、ECCは短い鍵長で強力な暗号化を提供し、ネットワーク伝送と計算パフォーマンスを向上させます。以下の表は、RSAとECCのセキュリティ強度、鍵長、および鍵長の比率の違いを示し、それぞれの有効期間を示しています。 |
| 46 | +
|
| 47 | +| セキュリティ強度（ビット） | DSA/RSA鍵長（ビット） | ECC鍵長（ビット） | 比率：ECC対DSA/RSA | 有効期限 | |
| 48 | +|:------------------------:|:-------------------------:|:---------------------:|:----------------------:|:--------:| |
| 49 | +| 80 | 1024 | 160-223 | 1:6 | 2010年まで | |
| 50 | +| 112 | 2048 | 224-255 | 1:9 | 2030年まで | |
| 51 | +| 128 | 3072 | 256-383 | 1:12 | 2031年以降 | |
| 52 | +| 192 | 7680 | 384-511 | 1:20 | | |
| 53 | +| 256 | 15360 | 512+ | 1:30 | | |
| 54 | + |
| 55 | +- **[ノイズプロトコルフレームワーク](https://noiseprotocol.org/)**：安全な鍵交換、メッセージの暗号化/復号化、および相互認証を可能にします。 |
| 56 | + |
| 57 | +> ノイズプロトコルは[ディフィー・ヘルマン鍵共有](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange)に基づいており、相互およびオプションの認証、アイデンティティの隠蔽、前方秘匿性、ゼロラウンドトリップ暗号化などの最新の暗号化ソリューションを提供します。そのセキュリティとパフォーマンスは、[WhatsApp](https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf)、[Slack](https://github.com/slackhq/nebula)、および[WireGuard](https://www.wireguard.com/)などの人気アプリケーションで既に証明されています。 |
| 58 | +
|
| 59 | +- **[アイデンティティベース暗号（IBC）](https://en.wikipedia.org/wiki/Identity-based_cryptography)**：大規模な鍵配布を簡素化します。 |
| 60 | + |
| 61 | +> 効率的な鍵配布は、ゼロトラストの実装に不可欠です。OpenNHPはPKIとIBCの両方をサポートしています。PKIは数十年にわたって広く使用されてきましたが、アイデンティティの確認と鍵管理に中央集権的な認証局（CA）に依存しており、時間とコストがかかることがあります。一方、IBCは、アイデンティティの確認と鍵管理を分散型で自己管理可能な方法で行うことができ、リアルタイムで何十億ものデバイスやサーバーを保護し、オンボーディングする必要があるOpenNHPのゼロトラスト環境において、よりコスト効率的です。 |
| 62 | +
|
| 63 | +- **[証明書レス公開鍵暗号（CL-PKC）](https://en.wikipedia.org/wiki/Certificateless_cryptography)**：推奨されるIBCアルゴリズム |
| 64 | + |
| 65 | +> CL-PKCは、鍵エスクローを回避し、アイデンティティベース暗号（IBC）の制限に対処することでセキュリティを強化するスキームです。ほとんどのIBCシステムでは、ユーザーの秘密鍵は鍵生成センター（KGC）によって生成され、これは重大なリスクをもたらします。KGCが侵害された場合、すべてのユーザーの秘密鍵が公開される可能性があり、KGCへの完全な信頼が必要です。CL-PKCは鍵生成プロセスを分割し、KGCは部分的な秘密鍵のみを知っているため、CL-PKCはPKIとIBCの両方の強みを組み合わせ、中央集権的な鍵管理の欠点なしに強力なセキュリティを提供します。 |
| 66 | +
|
| 67 | +詳細について： |
| 68 | + |
| 69 | +> OpenNHPで使用されている暗号化アルゴリズムの詳細な説明については、[OpenNHPドキュメント](https://opennhp.org/cryptography/)を参照してください。 |
| 70 | +
|
| 71 | +## 主な機能 |
| 72 | + |
| 73 | +- デフォルトで「すべて拒否」ルールを適用することにより、脆弱性の悪用を軽減 |
| 74 | +- 暗号化されたDNS解決を通じてフィッシング攻撃を防止 |
| 75 | +- インフラの隠蔽によるDDoS攻撃の防御 |
| 76 | +- アイデンティティベースの接続による攻撃の帰属 |
| 77 | +- 保護されたリソースに対するすべてのアクセスをデフォルトで拒否 |
| 78 | +- ネットワークアクセス前にアイデンティティおよびデバイスベースの認証 |
| 79 | +- DNSハイジャックを防止するための暗号化されたDNS解決 |
| 80 | +- DDoS攻撃を緩和するための分散インフラ |
| 81 | +- 分離されたコンポーネントによるスケーラブルなアーキテクチャ |
| 82 | +- 既存のアイデンティティおよびアクセス管理システムとの統合 |
| 83 | +- さまざまな展開モデルをサポート（クライアント対ゲートウェイ、クライアント対サーバーなど） |
| 84 | +- 最新のアルゴリズム（ECC、ノイズプロトコル、IBC）を使用した暗号化によるセキュリティの確保 |
| 85 | + |
| 86 | +<details> |
| 87 | +<summary>機能の詳細を表示</summary> |
| 88 | + |
| 89 | +- **デフォルト拒否のアクセス制御**：すべてのリソースはデフォルトで隠蔽され、認証と認可が行われた後にのみアクセス可能になります。 |
| 90 | +- **アイデンティティおよびデバイスベースの認証**：既知のユーザーと承認されたデバイスのみがアクセス可能です。 |
| 91 | +- **暗号化されたDNS解決**：DNSハイジャックとそれに伴うフィッシング攻撃を防止します。 |
| 92 | +- **DDoS緩和**：分散型インフラ設計により、分散型サービス拒否攻撃を防御します。 |
| 93 | +- **スケーラブルなアーキテクチャ**：分離されたコンポーネントにより柔軟な展開とスケーリングが可能です。 |
| 94 | +- **IAM統合**：既存のアイデンティティおよびアクセス管理システムと連携します。 |
| 95 | +- **柔軟な展開**：クライアント対ゲートウェイ、クライアント対サーバーなど、さまざまなモデルをサポートします。 |
| 96 | +- **強力な暗号化**：ECC、ノイズプロトコル、IBCなどの最新アルゴリズムを使用して強力なセキュリティを提供します。 |
| 97 | +</details> |
| 98 | + |
| 99 | +## 展開 |
| 100 | + |
| 101 | +OpenNHPは、さまざまなユースケースに合わせた複数の展開モデルをサポートしています。 |
| 102 | + |
| 103 | +- クライアント対ゲートウェイ：ゲートウェイの背後にある複数のサーバーへのアクセスを保護します |
| 104 | +- クライアント対サーバー：個々のサーバー/アプリケーションを直接保護します |
| 105 | +- サーバー対サーバー：バックエンドサービス間の通信を保護します |
| 106 | +- ゲートウェイ対ゲートウェイ：サイト間接続を保護します |
| 107 | + |
| 108 | +> 詳細な展開手順については、[OpenNHPドキュメント](https://opennhp.org/deploy/)を参照してください。 |
| 109 | +
|
| 110 | +## SPAとNHPの比較 |
| 111 | +[クラウドセキュリティアライアンス（CSA）](https://cloudsecurityalliance.org/)がリリースした[ソフトウェア定義境界（SDP）仕様](https://cloudsecurityalliance.org/artifacts/software-defined-perimeter-zero-trust-specification-v2)には、シングルパケット認証（SPA）プロトコルが含まれています。NHPは、最新の暗号化フレームワークとアーキテクチャを通じてセキュリティ、信頼性、スケーラビリティ、拡張性を向上させ、[AHAC研究論文](https://www.mdpi.com/2076-3417/14/13/5593)で示されているように従来の技術の限界を克服しています。 |
| 112 | + |
| 113 | +| - | SPA |NHP | NHPの利点 | |
| 114 | +|:---|:---|:---|:---| |
| 115 | +| **アーキテクチャ** | SPAサーバーのパケット復号化およびユーザー/デバイス認証コンポーネントがネットワークアクセス制御コンポーネントと結合されています。 | NHP-Server（パケット復号化およびユーザー/デバイス認証コンポーネント）とNHP-AC（アクセス制御コンポーネント）が分離されています。NHP-Serverは別のホストに展開でき、水平スケーリングをサポートします。 | <ul><li>パフォーマンス：リソース消費の多いコンポーネントNHP-Serverが保護されたサーバーから分離されています。</li><li>スケーラビリティ：NHP-Serverは分散またはクラスター化モードで展開可能です。</li><li>セキュリティ：認証が成功するまでは、保護されたサーバーのIPアドレスがクライアントには見えません。</li></ul>| |
| 116 | +| **通信** | 単方向 | 双方向 | アクセス制御のステータス通知による信頼性の向上 | |
| 117 | +| **暗号化フレームワーク** | 共有シークレット | PKIまたはIBC、ノイズフレームワーク |<ul><li>セキュリティ：MITM脅威を軽減する証明された安全な鍵交換メカニズム</li><li>低コスト：ゼロトラストモデルにおける効率的な鍵配布</li><li>パフォーマンス：高パフォーマンスの暗号化/復号化</li></ul>| |
| 118 | +| **ネットワークインフラストラクチャ隠蔽能力** | サーバーポートのみ | ドメイン、IP、ポート | 脆弱性、DNSハイジャック、DDoS攻撃など、さまざまな攻撃に対する強力な防御 | |
| 119 | +| **拡張性** | なし、SDP専用 | 汎用 | あらゆるサービス暗黒化の必要があるシナリオに対応 | |
| 120 | +| **相互運用性** | 利用不可 | カスタマイズ可能| NHPは既存のプロトコル（例：DNS、FIDOなど）とシームレスに統合可能 | |
| 121 | + |
| 122 | +## コントリビューション |
| 123 | + |
| 124 | +OpenNHPへの貢献を歓迎します！貢献方法の詳細については、[コントリビューションガイドライン](CONTRIBUTING.md)を参照してください。 |
| 125 | + |
| 126 | +## ライセンス |
| 127 | + |
| 128 | +OpenNHPは[Apache 2.0ライセンス](LICENSE)の下でリリースされています。 |
| 129 | + |
| 130 | +## 連絡先 |
| 131 | + |
| 132 | +- プロジェクトウェブサイト：[https://github.com/OpenNHP/opennhp](https://github.com/OpenNHP/opennhp) |
| 133 | +- メール：[opennhp@gmail.com](mailto:opennhp@gmail.com) |
| 134 | +- Slackチャンネル：[Slackに参加する](https://slack.opennhp.org) |
| 135 | + |
| 136 | +詳細なドキュメントについては、[公式ドキュメント](https://opennhp.org)をご覧ください。 |
| 137 | + |
| 138 | +## 参考文献 |
| 139 | + |
| 140 | +- [ソフトウェア定義境界（SDP）仕様 v2.0](https://cloudsecurityalliance.org/artifacts/software-defined-perimeter-zero-trust-specification-v2)。Jason Garbis、Juanita Koilpillai、Junaid Islam、Bob Flores、Daniel Bailey、Benfeng Chen、Eitan Bremler、Michael Roza、Ahmed Refaey Hussein。[*クラウドセキュリティアライアンス（CSA）*](https://cloudsecurityalliance.org/)。2022年3月。 |
| 141 | +- [AHAC：高度なネットワーク隠蔽アクセス制御フレームワーク](https://www.mdpi.com/2076-3417/14/13/5593)。Mudi Xu、Benfeng Chen、Zhizhong Tan、Shan Chen、Lei Wang、Yan Liu、Tai Io San、Sou Wang Fong、Wenyong Wang、Jing Feng。*応用科学ジャーナル*。2024年6月。 |
| 142 | +- ノイズプロトコルフレームワーク。https://noiseprotocol.org/ |
| 143 | +- 脆弱性管理フレームワークプロジェクト。https://phoenix.security/web-vuln-management/ |
| 144 | + |
| 145 | +--- |
| 146 | + |
| 147 | +✨ OpenNHPにご関心をお寄せいただき、ありがとうございます！皆様の貢献とフィードバックをお待ちしております。 |
| 148 | + |
0 commit comments