従来型のオートメーションとITの邂逅: パート 3

産業界以外では、「安全性」と「セキュリティ」は同じ意味として使われることが多い。そこでまずは、オートメーション業界でこの用語がどのように理解されているかを説明する。

安全性とは、想定外の被害から保護することによって確立される状態だ。ここで想定外の被害とは、意図せず引き起こしてしまった望ましくない結果のことを指す。安全性装置の例として分かりやすいのが自動車のエアバックだ。自殺でない限り、車の衝突は運転手が意図したものではない。つまりエアバッグは安全性を確保するための手段といえる。

一方でセキュリティは、意図された攻撃から保護することによって得られる状態だ。そのような被害は、目的のある侵入、悪用、又は破壊といった行為によって生じる。セキュリティ装置の例として分かりやすいのは、自動車のエンジン始動ロックシステムだ。所有者を自動車の盗難から守ってくれる。簡単にまとめると、「安全性は事故から守り、セキュリティは攻撃者から守る」と言える。

今回の記事では、この「安全性」と「セキュリティー」が従来の生産工場でどのような意味を持つか見ていこう。

セキュリティは工場保安部門の担当領域であり、往々にして非常に独立性の高い領域である。保安部門の任務は、特定の場所への侵入、工場内の物品の持ち出し又は持ち込み、工場の資産の改ざんを防止することだ。今日の工場保安の最重要分野はITセキュリティであるため、IT部門が工場保安員と協力して任務にあたることも多くなっている。侵入・悪用・破壊は工場のコンピュータネットワークにアクセスして遠隔操作で行うほうがはるかに効果的だ。工場のネットワークをインターネットに接続することで、「サイバーセキュリティ」という新たな問題が生じる。いわゆる「ファイアウォール」は、工場の境界を超えた場所からの不正なデータトラフィックを防止するために必要となる。ファイアウォールを間に挟んだ(非武装地帯(DMZ)のような)セキュリティゾーンを設置することで、この封じ込めの原則をさらに強化できる。自宅を強盗から守るのと同じで、頑丈なドアや窓で外の世界からしっかり分離する必要がある。高価なものは金庫のような「ディープシェル」で封じ込めてさらに保護する必要がある(念のために付け加えると、これは安全性装置ではなくセキュリティ装置だ)。

工場の安全性は、長らくFA技術者と衛生安全部門の担当領域だった(これも非常に独立性の高い領域だ)。特に「機能的安全性」は高度化されたため、研修を積んだエンジニア(CSMEなど)が必要となる。安全性を確立するための典型的なワークフローは潜在的障害の分析から始まる。FMEA (failure mode and effects analysis:故障モードと影響分析)やFTA (fault tree analysis: フォルトツリー解析)などの手法は、故障や事故の潜在的リスクを発見することができるため安全性設計に役立つ。「RPN」(Risk Priority Number: リスク優先度)のような評価システムはリスク評価に有用だ。まずはシステム上の有害な状態をリスト化するとともに、故障について考えられるすべての原因・発生頻度・検知方法のリストを作る。そして次に、故障の原因となる事象の発生を予測するシステムの反応または手段の決定、つまり故障防止の準備を行なう。

通常は、システムに機器を追加する(例えば、特定の機能を冗長にする)か、低故障率を誇る優れた「安全性認証」機器を使用するだろう。例えば、フィールドバスの「安全」版であるProfibus (ProfiSafe)などがある。マスタースレーブ(パート2参照)は、周期的に安全性関連データを特別なテレグラムで交換する。高い冗長性(CRC)によってデータがチェックされるので、不正なテレグラムを検出することができる。安全性装置(スレーブ)内部に追加されたウォッチドッグは、短い指定期間内にマスターから有効なテレグラムを受信していないと、すぐにアラームを発報して装置を「安全状態」に設定する。

NEVER CHANGE A RUNNING SAFE SYSTEM

NEVER MISS A SECURITY UPDATE!

確立されたセーフティシステム(安全性システム)に新しい手順やコンポーネントを導入する際は、安全性解析と認証を一新する必要がある。そのためセーフティシステムについては「実行中のシステムに触らない」というのが原則だ。一方でセキュリティシステムには、「侵入者がハッキング手段を見つける前に、常に最新のシステムにアップデートする」ことが求められる。この2つは相反する戦略に見えるが、実際にはどちらの領域も現実に対応する方法がある。

オートメーションにおいては、セーフティシステムのコンポーネントを「非安全」(すなわち安全な運用として承認されていない)部分から切り離し(カプセル化)しようとする。つまり、新たな安全性のリスクを取り込まない限り、そして安全部分の被害防止を阻止しない限り、システムのパーツを追加したり交換したりすることができる。
例えば、作業員が回転部品に触れないように、保護筐体のフタが開くとすぐに回転を止めるというシステムでは、安全機能に関係のないキャビネット内外の物はどれでも変更できる。筐体、筐体が開いていることを検出するセンサ、回転を停止させる電子機器、あるいは回転を起こすドライブを変更することはリスク及び故障解析の要因を変化させる可能性がある。そのため、これらのパーツはセーフティコンセプトの一部と見なされる。ただし、状態をクラウドに伝えるセンサを追加することは、作業員が回転部品を触れないよう保護する安全性には影響しない。

セキュリティ技術では、コンピュータエンジニアはシステムの境界を超えてインターネット経由でも分散型システム間のセキュアな通信を確立するセキュアな方法を見つける必要があった。それ以来、暗号化はこの問題の解決策であり続けている。家から葉書を送る代わりに、暗号化された情報を封筒に入れて封をして送るようなものだ。この暗号を解読するには、事前に指定した鍵を持っていなければならない。もちろん攻撃者は、常にこの暗号を破りたがっている。そのためセキュリティにおいては、暗号化方法を常に強化しつづける必要がある。とはいえ、暗号化は他のインターネットベースのシステムに比べればはるかに安定している。インターネットプロトコルと標準ツールであるHTMLやJavaなどの言語は脆弱性の問題があり、予期せぬバックドアを提供してしまうことも多い。ハッカーはそうしたバックドアを突いてくる。そのため、こうしたコンポーネントを定期的にアップデートして、既知のリスクを取り除いた新バージョンにすることが欠かせないというわけだ。セキュリティアップデートが疎かでインターネットに接続しているシステムは、攻撃者にとって格好の的だ。

IIoTについてはこうした事実にどのように対処するのだろうか？分離、暗号化、OTA (無線通信経由でのアップデート)は、オートメーション業界において安全性とセキュリティを兼ね備える効率的な方法だ。

分離は、M2M通信用内部バスを搭載したコントロールシステムをゲートウェイモジュールに接続することで実現できる。このモジュールは、オートメーション側のデータトラフィックをインターネット経由のデータトラフィックから厳密に分離する。これはセーフティコンセプトの一部となることはないため、アップデート可能なファームウェアを持つことが可能であり、必須でもある。こうしたアップデートが必要となることはめったになく(最新の暗号化方法の場合など)、むしろ相互運用性の程度に左右される。例えば、ゲートウェイに統合ウェブサーバーがある場合、システムへの未知の攻撃方法が多数ある可能性があり、方法が分かり次第すぐに排除する必要がある。

しかし、専用ゲートウェイ(ファイアウォールの原則といくつかの点で似ている)を使用する代わりに、インターネット経由で直接通信する追加の専用センサを使用して分離を行なうこともできる。いずれのシナリオにせよ、サイバーセキュリティを確立するには暗号化と認証手段が必要だ。AWSやAzure などのクラウドサービスでは、サーバー側で認証と暗号化のために充実したツールボックスを提供している。ところがセンサやゲートウェイは、元来ITの領域より組み込みの領域の話だ。システムはリソースやCPU電源の小型化が進み、暗号化処理に必要とされる膨大な計算能力に苦戦することが多い。しかし、チップ業界がこのニーズに気付き、SoC (System on a Chip)に暗号化用コプロセッサを搭載したり、特別な「暗号チップ」をシステム設計に使用したりする製品も、すでに多く登場している。暗号化・認証方法を組み込みシステムに適用する際の最大の障害は、組み込みプログラミング技術とITセキュリティ手法の両方に精通した熟練のハードウェアおよびソフトウェアエンジニアの不足だ。熟練のITプログラマと話をしても、産業用制御システムやセーフティシステムからデータを抽出することの難しさを理解してもらえないことが多い。一方、ITプログラマも「実行中のシステムに触らない」というオートメーション技術者の原則に難色を示しがちだし、そもそも産業用システムはスマートフォンやサーバーのハードウェアのようにたった2年しか使わないものではない。ITプログラマは、数十年も稼働してきたという事実を尊重しない傾向が見られる。

IIoTが早急に必要としているのは、ITとオートメーションのエンジニア同士が協力・教育し合う新しい文化だ。どちらの分野もI4.0に欠かせないものであり、エンジニアはお互いの出発点を理解して尊重し、学び合うべきである。概念がかけ離れているため、オートメーションエンジニアがサイバーセキュリティの世界に入っていくことには苦労があると思われるが可能ではある。企業は自社のプログラマにセキュリティスキルを磨くよう奨励すべきだ。そしてITセキュリティ専門家は、配属されたエンジニアと話しをする時の言葉遣いを初心者レベルに合わせる努力をすべきだ。相手が「プライベートキー」や「認証」の意味を知っているだろうと思い込むのはやめよう。愚痴を言わずに親切に説明してあげよう。

最終パートでは、オープンソースについて取り上げ、認証とIIoTを組み合わせた時に知的財産の共有を恐れるべきではない理由について説明する。

以前のパート Part 1 & Part 2

次のパート Part 4