公開WebリスナーなしでHMIへリモートアクセスする

マシンのステータスページをブラウザのタブに表示することは、その背後の機器を制御することとは違います。HMIは非公開のままにし、ポリシーに縛られた小さなサービスが、利用者に必要な一つの操作だけを仲介するべきです。製品を選ぶ前に、操作・ID・取り消しの経路を決めてください。トランスポートは差し替えやすい部分ですが、認可モデルはそうではありません。

トランスポートより先に操作を選ぶ

ステータスページの閲覧、承認済みレポートの取得、設定値の変更は三つの異なる要求です。一つ目は読み取り専用の表示で満たせ、最後のものは機器の状態に触れるため、所有者の明示的な承認、保守時間帯、現地での監督が必要です。これらをリモートアクセスとしてまとめると、その違いが隠れ、通常は作業が必要とするより広い経路が生まれます。操作、それを実行できる役割、実行された証拠を名付けてください。

次に、トランスポートは操作から導かれ、その逆ではありません。読み取り専用のニーズが対話的な制御を正当化することはまれであり、対話的な制御がHMI自身のリスナーを公開することを正当化することもまれです。操作が文書化されれば、アクセスモデルは製品の既定値ではなく判断になります。

ブローカーを名前付きの単一リソースの前に置く

リソースゲートウェイは利用者を認証し、ポリシーを適用し、一つの非公開サービスへの接続を開きます。HMIはリスナーを非公開ネットワーク上に保ち、インターネットからのセッションを一切受け付けません。ゲートウェイは暗号化されたセッションを終端するため、誰かが管理し監視しなければならない平文の信頼境界になります。

その境界は設計そのものであり、副作用ではありません。暗号化がどこで終わるのか、ゲートウェイの鍵を誰が持つのか、どのチームがポリシーを変更できるのかを書き留めてください。

各行は異なる故障モードを伴います。ゲートウェイはポリシーと証明書チェーンに、現地のワークステーションは物理的およびローカルアカウントの管理に、外向きコネクタはブローカーへの到達性に依存します。操作に合う行を選び、それが持ち込む依存関係を文書化してください。

アドレスは経路、IDは認可

トンネルのアドレスやDNS名は、パケットをどこへ送るかをネットワークに伝えますが、利用者がどのマシンを意図したかはブローカーに伝えません。各HMIや拠点コネクタを個別のIDで登録し、そのIDを棚卸しの記録に結び付けてください。アドレスが変わっても、IDは正しい資産を選び続けます。IDが廃止されれば、棚卸しの項目に失われたアクセスが示されます。

動的DNSはレコードを更新するだけで、それ以外は何もしません。利用者の認可も、上流の各変換器を通る経路も提供せず、これをアクセス制御として扱うことが、廃止後も古い名前が動き続ける原因です。対応する外向きコネクタは新たな求められていない内向き経路を避けますが、ネットワーク所有者の承認と、ブローカーに到達できないときの文書化された挙動が依然として必要です。

セッションの範囲を定め、取り消しを証明する

利用者ごとに別のIDを与え、多要素認証を要求し、操作に必要な操作だけを許可してください。保守時間帯はカレンダーのメモではなくポリシーに設定します。セッションが触れる資格情報と業務データを保護し、無関係な利用者活動を収集せずにアクセスイベントを保持してください。

取り消しはセッションが有効な間に試さなければなりません。利用者の権利を外し、ブローカーからセッションを終了し、HMIがその経路から到達できなくなったことを確認してください。

次に、計画が耐えると主張する故障を実際に試します：ブローカーを止めるかトンネルを切って、現地の運用と復旧がなお機能することを確認してください。リモート経路が健全な間しか機能しない設計は、リモートアクセスの計画ではありません。次のレビュー担当者は意図ではなく証拠を求めるので、日付、作業者、結果を記録してください。