Skip to Content
Solutionsリモートメンテナンス

マシンのリモートメンテナンス:ポート開放なしのセキュアなリモートアクセス

マシンが停止し、顧客から電話が入る — しかし最寄りのサービス技術者は数百キロ先にいます。機械メーカーや保全チームにとって、リモートメンテナンスはもはや選択肢の1つではなく、採算の取れるサービスの前提条件です。問われているのは「やるかどうか」ではなく「どうやるか」です:顧客のITセキュリティを損なうことなく — そして設備ごとに個別のVPNプロジェクトを立ち上げることなく — 顧客ネットワーク内のマシンにどう到達するか。

本ガイドでは、IronFlockによるリモートメンテナンスの仕組みを紹介します:マシン側に開放ポートを一切設けず、アウトバウンドの暗号化された接続だけで実現します。

従来のリモートメンテナンスが限界に達する理由

確立された従来のアプローチには、繰り返し現れる問題があります:

  • 拠点間VPNはソリューションではなくプロジェクトです。 顧客接続のたびに、2つのIT部門間の調整、ファイアウォールルール、IPアドレス設計、そして継続的な保守が必要になります。これは数百拠点にはスケールしません。
  • 開放された受信ポートは攻撃対象領域です。 マシン上で外部から到達可能なサービス — SSH、HTTP、VNC — はすべて潜在的な侵入口であり、多くのOTネットワークではそもそも承認が下りません。
  • リモートメンテナンスルーターは孤立したソリューションを生みます。 マシンごとの保守モジュールは、専用ハードウェア、個別の管理、個別のアクセス経路を意味します — そしてフリート全体を横断する共通のビューは得られません。
  • 追跡可能性が欠けています。 誰がいつどの設備にアクセスしたのか?漏れのない記録がなければ、顧客や監査担当者にほとんど答えられません。

原則:内から外への接続

IronFlockは接続の方向を逆転させます。マシン上 — あるいはその隣のエッジデバイス上 — でIronFlockのデバイスエージェントが動作します。エージェントはすべての接続をアウトバウンドでプラットフォームに向けて開始し、TLSで暗号化します。これには直接的な効果があります:

  • デバイスに開放ポートがありません。 マシンはインターネットから発見することも、直接アドレス指定することもできません。攻撃者がスキャンできるサービスが存在しないのです。
  • 顧客側の受信ファイアウォールルールが不要です。 アウトバウンドのHTTPS/WSS接続が1本あれば十分 — あらゆるブラウザが使うのと同じ種類の接続です。企業プロキシの背後での運用もサポートされています。
  • リバーストンネルによるリモートアクセス。 ローカルのWebインターフェースやサービスにアクセスする際は、プラットフォームがマネージドリバースプロキシアーキテクチャを介し、既存のチャネル経由で接続を確立します — 元の接続の方向はアウトバウンドのままです。

このゼロトラストアーキテクチャの詳細は、セキュリティドキュメントに記載されています。

リモートから到達できるもの

リモートアクセスは1つのプロトコルに限定されません。アプリとデバイスごとに、さまざまなサービスへのトンネルを有効化できます:

プロトコル主なユースケース
http / httpsマシンHMI、ローカルWebインターフェース、ダッシュボード、設定ページ
tcpリモートデスクトップ(VNC)、データベースアクセス、Siemens TIA Portal、CODESYS、TwinCATによるPLCプログラミング
udpビデオストリーミング、VPNサービス、LoRaWANゲートウェイ管理

さらに、システムレベルの2つのアクセス手段が用意されています:

  • ホストアクセス — デバイスのホストOS上で動くブラウザベースのターミナル。システム診断、ネットワークデバッグ、Docker管理に使えます。現地での作業も、現地への出動も不要です。
  • SSHアクセス — 鍵認証による高度なデバッグ用。パスワードログインはデフォルトで無効です。

トンネルは埋め込みウィジェットとしてボードに直接組み込むこともできます:サービスチームはフリートのデータを監視しながら、同じダッシュボードの中で個々のマシンのWebインターフェースを操作できます。

実際のセットアップ手順

IronFlockでのリモートメンテナンスは、3つのステップでセットアップできます:

  1. ポートを宣言する。 アプリ開発者がport-template.ymlで、アプリが提供するポートとプロトコル — 例えばポート8080のHMI — を記述します。これはアプリ内で一度だけ行えばよく、マシンごとの作業は不要です。
  2. トンネルを有効化する。 権限を持つユーザーが、デバイスのアプリ設定でトンネルを有効にします — スイッチ1つで、ネットワーク設定は不要です。
  3. セキュアなURLを使う。 プラットフォームが保護されたURLを生成し、その背後でローカルサービスに到達できます — 認証済みかつ権限のあるユーザーだけが利用できます。

ネットワーク接続が切断されても、エージェントとトンネルは自動的に再接続します — エージェントは接続性とレジリエンスを重視して設計されており、再接続を無制限に試行します。

典型的なサービスケース

機械メーカーのサービスチームで日常的に起こるような一連の流れを見ると、その感覚がつかめます:

  1. 通知。 アラームまたは顧客からの電話で、フランスにある設備の障害が報告されます。プロジェクトを開けば、技術者はすぐに確認できます:デバイスはオンライン、アプリは稼働中です。
  2. ボードでの一次診断。 マシンのボードでは、ライブデータと履歴チャートから、いつその挙動が始まったのかが分かります — この時点で原因が絞り込めることも少なくありません。
  3. HMIへのアクセス。 技術者はHTTPSトンネルを有効にし、ブラウザでマシンの操作画面を開きます — 現場のオペレーターが見ているのと同じ画面です。
  4. 必要ならさらに深く。 それで足りなければ、PLCプログラミング環境のためにコントローラへのTCPトンネルを使うか、ホストアクセスでコンテナ、ネットワーク、システム負荷を確認します。
  5. 記録を残して完了。 すべてのステップが監査ログに残ります。顧客は、誰がいつ自社の設備にアクセスしたかをいつでも確認できます。

VPNクライアントも、顧客IT部門の待機対応も、現地への移動も不要 — 順調にいけば、現地対応の計画を立てるより先に設備は再稼働しています。

従来のアプローチIronFlockの場合
ネットワーク統合拠点ごとのVPNプロジェクトアウトバウンドのTLS接続だけで十分
デバイスの開放ポート多くの場合必要なし
アクセス制御共有のVPNアカウントユーザーとデバイスごとの権限
追跡可能性手作業で不完全トンネル使用ごとの監査ログ
フリートへのスケール工数が線形に増加1つのアプリで全マシン

セキュリティとコントロール:誰が何をできて、誰が何をしたのか

リモートアクセスは信頼の問題です。IronFlockはそれを制御可能かつ追跡可能にします:

  • きめ細かな権限。 トンネルを有効化できるのは、そのデバイスに対して少なくとも更新権限を持つユーザーだけです。権限モデルは、包括的な管理者ロールではなく、アセットごとの個別の権限で機能します。
  • 漏れのない監査証跡。 トンネルの有効化と使用はすべて、デバイスの監査ログに記録されます — 誰が、いつ、どのポートを、実際のプロキシ接続まで含めて。
  • 一貫した暗号化。 ブラウザからデバイスまで、すべてのコンポーネントがTLSで保護されたチャネルで通信します。ログインはOpenID Connectで行われ、オプションで二要素認証を利用できます。
  • アクセスはいつでも取り消し可能。 外部のサービスパートナーへの権限は細かく付与でき、いつでも剥奪できます — データ主権はプロジェクト所有者が保持します。

機械メーカーの皆様へ:リモートメンテナンスを製品の一部に

マシンを出荷する側は、拠点ごとにサービスを一から作り直したくはありません。IronFlockを使えば、リモートメンテナンスはマシンそのものの一部になります:

よくある質問

顧客のIT部門はファイアウォールのポートを開放する必要がありますか?

いいえ。デバイスエージェントは、アウトバウンドのTLS暗号化接続のみを確立します — ブラウザがWebサイトを開くのと同じ要領です。受信ファイアウォールルール、ポートフォワーディング、固定IPアドレスは不要です。企業プロキシのある環境もサポートされています。

PLCをリモートからプログラミングできますか?

はい。TCPトンネルを介して、使い慣れたエンジニアリングツール — Siemens TIA Portal、CODESYS、TwinCATなど — でコントローラに接続できます。ローカルネットワークにいるのと同じ感覚です。ポートはアプリ内で一度宣言し、デバイスごとに個別に有効化します。

リモートアクセスはどのように記録・制御されますか?

トンネルを有効化できるのは、そのデバイスに対する該当の権限を持つユーザーだけです。有効化と使用はすべて、デバイスの改変不可能な監査ログに記録されます — ユーザー、時刻、ポートを含めて。これにより、誰がいつアクセスしたかを顧客や監査担当者にいつでも証明できます。

マシンがオフラインになったり、接続が切れたりしたらどうなりますか?

デバイスエージェントは再接続を無制限に試行し、ネットワーク断の後はリモートアクセストンネルを自動的に復旧します。メモリやディスクが逼迫した状況でも、エージェントはリモートからの到達可能性を最優先で維持します — デバイスはリモート管理可能なままです。

次のステップ

初めてのリモートアクセスへの最短ルートはこちらです:はじめにガイドに沿ってプロジェクトを作成し、デバイスを接続してトンネルを有効化してみてください — 数分で完了し、クラウドでは無料です。技術的な詳細は、リモートアクセスセキュリティのドキュメントをご覧ください。

Last updated on