ノードのセキュリティ
ノードのセキュリティは、安全なブロックチェーン・ネットワークの重要な側面である。 ノードの種類にもよるが、オペレーターはセキュリティに注意を払う必要がある。
- コンセンサス・ノード（CN）：CNは新しいブロックの提案と検証を行う。 侵害されたCNは、悪意のあるブロックを作成したり、ブロックチェーンを混乱させたりすることができる。 確かに、少数のノードの不正行為はBFTコンセンサスによって阻止される。 しかし、それでも不良ブロックやラウンド変更を引き起こし、ネットワークの安定性を低下させる可能性はある。 したがって、コアセル事業者は責任を持ってノードを維持すべきである。
- プロキシノード（PN）：PNはCNに代わってインターネット上のノードと通信する。 PNはそれ自体ではブロックに署名しないが、PNのセキュリティ侵害はネットワークに損害を与える可能性がある。 そのp2pキーは、CNの制限されたネットワークに接続するために使用することができる。 侵害されたPNは、スパムフィルタなどのトランザクションフィルタリングを無効にすることもできる。
- エンドポイントノード（EN）：ENはアプリケーションにネットワークへのパブリックアクセスを提供する。 ENにはブロックを操作する権限はないが、ENにセキュリティ違反があれば、信頼問題が生じる可能性がある。 侵害されたENは、ブロックデータやアカウントの状態を含む偽の情報を提供することができる。 アプリがENに直接接続されている場合、受信トランザクションをドロップしたり、検閲したりすることができる。
オペレーション・セキュリティ
可能な限り、セキュリティのベストプラクティスに従ってください。 いくつか挙げてみよう：
- オペレーティングシステムとインストールされているソフトウェアを最新の状態に保つ。
- リモート・ルート・ログインを無効にし、パスワード・ベースのログインをオフにし、公開鍵認証を選択することで、SSHセキュリティを強化する。
- ノードは常に専用マシンで運用する。 サプライチェーン攻撃によるマルウェアのリスクを減らすため、他のソフトウェア、特にインターネットに接続するソフトウェアのインストールを控える。 マシンまたは仮想マシンは、ノード操作の目的のみに使用すること。
- ファイアウォールを設置する。 オープンポートは最小限にして、メンテナンスとオペレーターのIPアドレスをホワイトリストに登録する。 SSHポート、RPCポート、デバッグ・ポートを開くときは注意してください。 CNとPNの場合、p2pポートはピアCNとPNのIPの明示的なリストに制限されるべきである。 たとえp2pスタックに脆弱性があったとしても、攻撃機会は効果的にブロックされるか、既知のノードに制限される。
- クラウドのセキュリティを優先する。 ノードがクラウド仮想マシン上で動作している場合は、クラウドプロバイダーのベストプラクティスに従って、クラウドアカウント（AWS IAMロールなど）を適切に管理する。 クラウドアカウントはSSHにアクセスできないかもしれないが、ディスクの内容をコピーしたり、シリアルコンソールを開いたりすることはできる。
キーセキュリティ
ノードが管理する暗号鍵は大きく分けて2つある。
- ノード鍵またはp2p鍵：32バイトのsecp256k1 ECDSA秘密鍵。 これはp2pのrlpx通信やブロックの署名に使われる。
- BLSノード鍵：32バイトのBLS12-381秘密鍵。 これは、ブロック内のRANDAOフィールドに署名するために使用される。
署名は無人で自動的に行わなければならないので、これらの鍵はディスクに保存するか、コマンドラインから入力しなければならない。 この時点で、鍵を盗難から守るためには、ノードのセキュリティが重要になる。
将来的には、ノードは鍵管理システム（KMS）やハードウェア・セキュリティ・モジュール（HSM）などの外部プロバイダーへの鍵の保管をサポートする可能性がある。 このような鍵管理メカニズムがあっても、ノードのセキュリティは依然として重要であることに注意されたい。 鍵はコピーできないが、侵害されたノードは悪意のあるペイロードの署名を開始することができる。 鍵の盗難に加えて、鍵の紛失も管理すべきリスクである。 ノード鍵を暗号化されたキーストア・ファイルにバックアップし、オフライン・ストレージに保存することを推奨する。