産業用IoTのセキュリティ：接続されたデバイスと、それらが送信する電子メールの保護

コネクテッドファクトリーは、温度や振動から故障や生産停止に至るまで、あらゆる重要な変化を報告するデバイスに依存しています。メッセージはセンサーから発信され、ゲートウェイを経由して、最終的にエンジニアの受信箱にメールとして届くこともあります。これにより時間は節約されますが、その一方で、攻撃者が認証情報を盗んだり、データを改ざんしたり、信頼できる送信者を装ったりできる機会も増えてしまいます。

コネクテッドオペレーションの近代化を進める製造業者にとって、堅牢な 産業用IoT（IIoT）セキュリティ 計画は、デバイスの識別、ネットワークアクセス、クラウドの権限、API、暗号化、および監視を網羅するものです。また、組織は、IIoTイベントを運用アラートに変換する下流のシステム、およびそれらを配信するために使用される電子メールインフラストラクチャについても考慮する必要があります。 

このより広範な見解は、現在のOTガイダンスと合致している。2026年9月の NIST SP 800-82 リビジョン4の の初版公開草案では、その適用範囲に産業用IoT（IIoT）およびクラウドの融合が追加されています。また、資産管理、ネットワーク監視、ゼロトラストセキュリティ設計の重要性も強調されています。業界にとっての教訓は明らかです。すなわち、接続されたデバイスは、単一のシステムの一部として管理される必要があるということです。

IIoTのセキュリティがデバイスだけにとどまってはならない理由

あらゆるつながりが、信頼に関する判断を生み出す

IIoTデバイスが単独で動作することはほとんどありません。デバイスは計測値を収集し、それをゲートウェイに送信し、ブローカーに接続して、データをクラウドに転送することがあります。その後、ルールをトリガーして、メールによるアラートを送信することもあります。各ステップにおいて、次のシステムは、通信の相手方が誰であるか、その送信元が許可されているか、そしてそのデータが信頼できるかどうかを把握していなければなりません。

したがって、資産の可視化は基本的な管理措置となります。各チームは、どのデバイスが使用されているか、それらが何に接続されているか、そして所有者が誰であるかを把握しておく必要があります。ゲートウェイ、クラウドアプリ、サービスアカウント、API、メール送信元についても、同様の記録を整備する必要があります。

有用な基準としては、以下の点を網羅すべきである：

• 共有のデフォルト設定の代わりに、一意のデバイス識別子と認証情報；
• 安全な設定に加え、鍵のローテーションや失効を管理された方法で実施すること；
• OT、IT、クラウド、および外部サービス間のネットワークセグメント；
• デバイスおよびプロトコルが対応している場合、暗号化されたトラフィック；
• ロールバック計画を含む、署名済みかつ検証済みの更新プログラム；
• デバイスイベントと、ゲートウェイ、アプリ、およびメールのアクティビティを関連付けるログ。

これらの制御機能は、1件の侵害がどこまで拡大するかを制限し、チームが不審なメッセージを追跡するのを支援します。

メールアラートは新たな攻撃対象となる

電子メールは、多くの場合、IIoTワークフローの最終段階に位置します。圧力センサー自体がSMTPメールを送信することはありません。その代わりに、ゲートウェイや監視プラットフォームがイベント情報を読み取り、メールサービスを利用してスタッフに通知します。送信元は別のマシンIDであるため、そのIDも把握・管理する必要があります。

攻撃者がアラート送信元のドメインを偽装できる場合、機器に問題がないにもかかわらず、偽のメンテナンス警告が本物のように見えてしまう可能性があります。また、認証が不十分な正当な送信者によって、別の問題が発生する可能性があります。つまり、緊急のアラートがスパムフォルダに振り分けられてしまうのです。目標は、運用メールの信頼性と確実性を両立させることです。

影響の大きい決定については、電子メールは通知手段として活用すべきであり、変更が正当であることを示す唯一の証拠としてはならない。

接続されたデバイスとその電子メール通信を保護する方法

フロー全体にわたるIDとアクセスのマッピング

まずは、マシンからメールボックスまでの経路を把握することから始めましょう。どのコンポーネントがイベントを開始し、どのサービスがメールを作成し、どのドメインが「差出人」欄に表示されるかを記録してください。これにより、デバイスだけの検証では見落とされがちな不備が明らかになる場合があります。

システム群が拡大し、ベンダーが変更されるにつれて、セキュリティ対策はシステムのライフサイクル全体を通じて実施されなければなりません。そのため、アクセス制御、暗号化、監査ログ、および安全な更新は、後からの修正ではなく、設計段階からの考慮事項として扱う必要があります。リリース後も、パッチ適用、鍵のローテーション、監視、定期的な見直しを通じて、同様の取り組みが継続されます。

実用的な順序は次のとおりです：

1. インベントリ対象のデバイス、ゲートウェイ、アプリ、サービスアカウント、および送信ドメイン。
2. 各コンポーネントには、その役割に必要なアクセス権のみを付与してください。
3. OTトラフィックは、一般的なオフィスネットワークやインターネットに接続されたネットワークとは分離してください。
4. ソースコードや共有ファイルには、秘密情報や鍵を含めないでください。
5. インシデントが発生する前に、更新および復旧の手順をテストしておきましょう。
6. 新しい連携機能については、デバイスとメールの両面からリスクを検証してください。

これにより、OTチームとITチームは、各統制について明確な責任分担を持つことになります。

デバイスと同様に、メールの送信経路についても慎重に認証を行う

送信元が認証され、特定されれば、メール認証によってそのドメインを保護することができます。SPFは、どのメールサーバーがそのドメインの代わりにメールを送信できるかを指定します。DKIMは暗号署名を付加するため、受信システムは署名元のドメインを検証し、署名された内容の改ざんを検出することができます。DMARCは、表示されている「From」ドメインが、SPFまたはDKIMによって認証された身元と一致しているかどうかを確認します。そして、検証に失敗したメールに対して、受信者がどのように対応すべきかを指示することができます。

IIoTのアラートについては、クラウド監視ツール、チケット管理システム、またはリレーが、企業に代わって送信を行う場合があります。DMARCの適用が厳格化される前に、その送信元をインベントリに登録しておく必要があります。そうしないと、拒否ポリシーへの移行により、実際に機械によって生成されたアラートがブロックされてしまう可能性があります。

各チームは、SPFおよびDKIMの設定が適切であることを確認し、DMARCレポートを精査し、より厳格な適用を行う前に不明な送信元を削除する必要があります。サブドメインを分離することで、各拠点やアプリ間の所有権関係を明確化できます。

OTおよびEメールに関する変更にご注意ください

産業用システムは常に変化し続けています。新しいゲートウェイの導入、ファームウェアのリリース、クラウドへの移行、あるいは保守ベンダーの変更などにより、ネットワークトラフィックや電子メールの挙動が変化する可能性があります。数ヶ月前には有効だった制御策が、実際のシステム状況に合わなくなっている可能性があります。

監視では、OTイベントと、ID、ネットワーク、アプリケーション、および電子メールのデータを組み合わせて分析する必要があります。不明な送信元IPアドレス、繰り返される認証失敗、あるいは新しい経路を使用しているデバイスは、設定ミスである可能性もあれば、侵害の初期兆候である可能性もあります。

産業用IoTのセキュリティは、接続されたデバイスと、それらが引き起こすメッセージを「信頼の連鎖」として扱うことで、最も強固なものとなります。デバイスを保護し、デバイスが利用可能な経路を制限し、デバイスを代表して通信を行うシステムの認証を行い、フロー全体に変化がないか監視します。そうすることで、接続された運用は有用性を保ち、信頼され続けるのです。

最終的な感想

産業用IoTのセキュリティ対策は、工場内のデバイスを保護するだけでは不十分です。業務ワークフローに関わるすべてのゲートウェイ、クラウドアプリケーション、API、通信チャネルが、セキュリティリスクをもたらす可能性があります。 特に電子メールには細心の注意を払う必要があります。なぜなら、改ざんされたり認証されていないアラートは、重要な運用情報に対する信頼を損なう恐れがあるからです。デバイスレベルの保護策に、ネットワーク監視、アクセス制御、およびSPF、DKIM、DMARCといった電子メール認証プロトコルを組み合わせることで、製造業者はより信頼性の高いセキュリティフレームワークを構築できます。その目的は、接続されたデバイスだけでなく、産業運用を支える通信の全チェーンを保護することにあります。