エッジアプリケーションの進化に伴い、悪意のある何者かによる攻撃面が増加するリスクがあります。エッジアプリケーションをデプロイする際には、security-by-design ソリューションを用意することが不可欠です。 Izuma Edge は、Izuma Cloud 製品とそのゼロトラストセキュリティ原則の長年の経験と開発に基づいて構築されています。
弊社のクラウドサービスは、エッジサーバーを含むすべてのデバイスに真の end-to-end のセキュリティを提供し、エッジアプリケーションと構成データの安全な展開を保証します。 API を使用すると、違反の可能性がある場合にゲートウェイまたはサーバーの個々またはグループを取り消すことができます。弊社のサービスでは、TPM 2.0 シリコン、その他の暗号化セキュリティモジュール、HSM など、利用可能な場合は安全なハードウェアを利用します。
展開されたアプリケーションは、組み込みの SD-WAN サービスを利用して、Izuma Cloud インスタンスのクラウド部分で実行されている他のポッドに安全なトランスポートを提供し、独自のクラウドサービスまたはエッジの特定のインターフェイスへの入口と出口を構成することもできます。これらのサービスはすべて、相互 TLS (mTLS) を使用して、信頼できる証明書 - Izuma 量産工程 または Izuma Edge インストーラーを使用して、製造プロセスまたはシステムイメージングプロセス中に確立された root-of-trust - と通信します。
エッジコンピューティングは洗練されたパラダイムであり、クラウドとエッジの両方にマシンが関与します。これらのエッジマシンはどこにでもある可能性があり、通常は高度に分散化されています。そうは言っても、エッジでのセキュリティに対して十分に考え抜かれた多層防御戦略を持つことが重要です。 サービスとしてのエッジ（Edge-as-a-Service） セキュリティ設計の主要なレイヤーについて見ていきましょう。
注: 以下では、量産工程の流れとブーストラッププロセスについて説明します。イメージは Izuma Edge ですが、これらのプロセスは Izuma Edge と Izuma Connect の両方に適用されます。
やりとりしているエッジボックスが実際に展開したエッジボックスであることを確認できなければ、他のすべてのエッジセキュリティ対策は無意味です。これは、ID 作成のための安全なプロセスを必要とする強力な ID セキュリティから始まります。
ユニークで安全な ID は、ルート証明機関 (CA) から始まります。これは、サービスの所有者が自己生成した CA にすることができます。サービスの所有者とは、Izuma Cloud インスタンスを管理する組織を意味します。このユニークな CA 証明書は、クラウドインスタンスを作成するときに Izuma Networks に提供されます。 Izuma Networks が CA の秘密鍵を必要としたり要求したりすることはありません。また、CA を作成し、安全な施設に保管された堅牢な HSM を使用してそのキーを保護することもできます。
通常、組織は中間 CA 証明書を作成します。これを Izuma 量産工程ツールが使用して、マシン/デバイスごとにユニークな証明書を生成できます。ユニークな証明書とともに、マシンをユニークに識別する追加の不変フィールドがあります。各固有の証明書には、マシンを識別する固有のフィンガープリントも付属しています。
インストールされた証明書は、マシンが使用する最終的な証明書ではありません。この証明書は、次のステップであるブートストラップで使用されます。 量産工程ツールのセットアップ中に、Izuma Cloud インスタンスのブートストラップサービスのみを使用するか、グローバルブートストラップサービスを使用するかを選択できます。デフォルトでは、ほとんどの場合グローバルブートストラップサービスを使用することをお勧めします。これにより、必要に応じてマシンを別の Izuma Cloud インスタンスに切り替えることができます。例えば、2 つ以上の Izuma Cloud インスタンスを実行している場合、または新しい代替インスタンスを展開した場合です。
ブートストラップ証明書を持つマシンは、グローバルブートストラップサービス (該当する場合) と Izuma Cloud インスタンスに到達できるネットワークに接続されるとすぐに、オンボーディングの準備が整います。クラウド自体はまだマシンについて認識していません。オンボーディング前の無期限の保管エリアまたは倉庫で、マシンを未使用のままにしておくことはまったく問題ありません。その間にこれらのマシンが有効でないと判断された場合、または単に誰もオンボーディングしたくない場合は、マシンの ID をリストに追加してオンボーディングを防ぐことができます。極端な例では、特定の中間証明書によって署名されたすべてのマシンを無効にするということもできます。
多くの実装では、Izuma Edge をインストールし、量産工程ツール (インストール方法によってはインストールプロセスに統合されます) を実行した直後にマシンを展開する場合があります。このような場合、ブートストラッププロセスは不要に見えることがあります。ただし、それでも重要な目的を提供します。ブートストラップにより、どのマシンも最初にインストールされたときと同じ状態にリセットできます。このような場合、マシンは新しい ID を引き受け、別のクラウドに切り替えることができます (グローバルブートストラップシステムの使用を選択した場合)。シリアル番号などの特定の不変フィールドは常に同じままであるため、ハードウェアを常に識別できます。
オンボーディング: ブートストラップの初期化
オンボーディングは、暗号化されたユニークなフィンガープリントによって識別されるユニークなマシンを特定のクラウドに接続許可することをクラウドに伝える簡単なプロセスです。最も単純な形式は、これは基本的ですが、サービスへの特権付きの API 呼び出しです。指紋自体はユニークであり、物理ハードウェア自体と同様に保護する必要があります。工場で製作中の機械であれば、機械にステッカーを貼ったり、箱にインサートを入れたりするのが簡単な方法かもしれません。盗まれたマシンは、API 呼び出しを行うための適切な資格情報がなければ、オンボーディングできません。 量産工程ツールは、生成されたすべてのフィンガープリントも記録します。
API 呼び出しが行われてマシンがブートストラップサービスに接続すると、グローバルブートストラップの場合は新しい資格情報が新しい証明書の形式で返されます。そこには、加えて Izuma Cloud インスタンスで使用するためにどのクラウドと通信するか、どの名前空間(「アカウント」とも呼ばれます)かといったことを含む幾つかの補助情報が含まれます。オンボーディングが発生したことを別のサービスに通知する Izuma Cloud からの通知など、特定のタスクがブートストラップで「フック」されることもあります。名前空間を使用すると、Izuma Cloud を Izuma Cloud 内のエッジマシンとユーザーをセグメント化できるマルチテナントサービスとして簡単に使用できます。
オンボーディングを達成する方法はさまざまです。社内の IT ニーズに合わせて Izuma Cloud を導入する場合は、フィンガープリントを安全な場所に保管し、弊社の管理インターフェイスを使用するだけで十分かもしれません。
マシンをまとめて展開し、サードパーティ、またはかなりの数の IT および運用以外の担当者 (例として、グローバル フィールドエンジニアリングチームなど) がマシンを展開することを想定している場合は、よりダイナミックなシステムが必要です。弊社には、例えば QR コードやバーコードをスキャンしてデバイスをオンボーディングする、社内向けまたは顧客向けのモバイルアプリを構築するのに役立つサンプルソフトウェアがあります。
ユニークな ID が作成されてエッジマシンに保存されると、この ID を構成することは非常に困難で重要な作業になります。それを達成するためのタスクをタイムリーに行なうことは非常に難しく、マシンに物理的にアクセスできない場合は特にそう言えます。
Izuma Edge と Izuma Connect はどちらも、利用可能な場合は暗号化された安全なストレージを利用します。この最も一般的な形式は TPM 2.0 で、多くのゲートウェイクラスのマシンで利用でき、ほとんどのサーバークラスのマシンではオプションコンポーネントです。一部のチップセットには、その一部として TPM が含まれています。他の形式の root-of-trust ハードウェアには、Arm PSA 準拠のハードウェアや、仮想マシンやクラウドインスタンスで使用できる vTPM などがあります。
Izuma Edge は、様々な種類の暗号化ハードウェアのサポートを柔軟にするために、様々な種類の TPM または HSM モジュールを利用できる CNCF プロジェクトである PARSEC を利用します。
セキュリティの移行
各デバイスにはユニークな ID があり、この ID を偽造するのは非常に難しいため、エッジマシンであると主張するエッジマシンは大抵の場合その主張通りであると信頼できます。
しかしながら、時には運用チームが特定のシステムの完全性を信頼できなくなる場合があるかもしれません。マシンは、フィンガープリントによって拒否リストに入れることができます。これを行うと、マシンがクラウドサービスと通信できなくなります。
Izuma Edge と Izuma Cloud が機能していれば、例えマシンが侵害されてもクラスター全体へのアクセスはできません。特定のアカウントに属するエッジマシンは、特に構成されていない限り、そのアカウントのポッドとのみ通信できます。
ブートストラップ中にマシンで受信した信頼できる ID と証明書により、マシンはすべての通信に mTLS 暗号化を使用できます。
つまり mTLS (相互 TLS) を使用すると、エッジマシンは正しいサーバーと通信していることを常に確認でき、サーバーはこの固有のエッジマシンと通信していることを確認できます。
Izuma Edge または Izuma Connect からのすべての通信は mTLS を使用します。 Izuma Edge の場合、ほとんどすべての通信で、Izuma Edge を実行しているマシンから Izuma Cloud インスタンスへの HTTPS アウトバウンドが使用されます。
展開されたアプリケーションのための SD-WAN
さらに、Izuma Cloud は、Izuma Edge を使用する任意のマシンで動作する SD-WAN サービスを提供します。この SD-WAN により、Izuma Edge マシンにデプロイされた k8s ポッドは、SD-WAN を Izuma Cloud クラスター内の特定のサービス (Izuma Cloud インスタンスのクラウド部分で実行されているポッドなど) またはオープンなインターネットに乗せることができます。これは、Izuma Edge が展開された各場所のファイアウォール/WAF に、アプリケーションに関する特定のルールが必要ないことを意味します。代わりに、トラフィックは常にインターネット上の特定の出口ポイントを経由してルーティングされます。
Izuma Edge と Izuma Cloud は Kubernetes 上に構築されており、アウトバウンドトラフィック用の SD-WAN インターフェイスを備えているため、ネットワークインターフェイスをポッドが必要とするトラフィックのみに制限することで、エッジでの攻撃面を大幅に制限することができます。
エッジにデプロイされたポッドには、適切なネットワークポリシーが必要です。これにより、エッジに展開されたアプリケーションがローカル LAN 上のサービスや不正なクライアントと通信したり、WAN を介してプローブされるリスクを回避したりできます。
デプロイされたポッドには、エッジで特定の物理インターフェイスを処理するネットワークポリシーを設定することもできます。例えば、ゲートウェイクラスのデバイスは、一方のインターフェースに「OT」ネットワーク (または制御ネットワーク) を持ち、もう一方のインターフェースにタイプ「IT」LAN を持つ場合があります。 Izuma Cloud へのアウトバウンドトラフィックは LAN インターフェイスからルーティングされますが、制御ネットワークは特定のポッド (インターネットと通信することのないポッド) によってのみ使用されます。
