セキュリティから見た産業機器で使う商用ファイルシステムの有用性

１．はじめに

本記事では、産業機器においてセキュリティの向上が求められ商用ファイルシステムへのニーズが高まっている現状について解説します。

産業機器を開発・販売するメーカーにおいて、また産業機器を（例えば）工場に設置するユーザーにおいても、セキュリティに関する関心が高まってきており、更にセキュリティの維持・向上をはっきり意識している機器メーカーや機器ユーザーも増えてきています。

このようなトレンドは、例えば制御システムセキュリティ標準の国際規格である IEC 62443 が国際電気標準会議（ IEC ）により策定されていること、制御システムに使われる製品を開発するときにはこれらの規格準拠を求められるようなりつつあることなどに現れていると言えます。

本記事において、まずは最近の産業向け機器のシステム構成がどのようなものになっているかを説明します。

次に、最近の産業向け機器のシステム構成に外付けストレージが含まれていることについて説明します。

価格的な面から、そしてセキュリティ的な観点からも、構成に含めるのは必須のデバイスだけにしたいところです。外付けストレージの配置がどのような理由によるものかを示し、その過程で外付けストレージに求められる機能や実現方法についての検討を記します。
そして最後に、外付けストレージ向けのファイルシステムに求められる要求に応える GravityCS という Tuxera 社のソリューションを紹介します。

GravityCS は、メディアへの書き込み中に不測の電源断が発生した場合や、メディアへの書き込み中にメディアを取り出した場合などでも、正常な最後の書き込みにロールバックしてファイルシステムとしての整合性を維持できるソリューションです。

２．最近の産業機器のシステム構成

工場間がネットワークで接続されていること、または工場と本社がネットワークで接続されていることは、もはや通常の構成・運用形態になっています。

生産管理システムが起点になって、「生産管理 - 本社情報」、および「生産管理 - 生産工場」、といった構成になっているケースもあり、サイバー攻撃に対する防御能力を高めていく必要があります。コンサルティングの場でよく議論されることですが、各ドメインあるいはレイヤーの独立性を高めつつドメイン間あるいはレイヤー間に設置するゲートウェイを適切に設定することで、あるドメインまたはレイヤーに対する攻撃の被害が他ドメイン・レイヤーに広がらないように工夫されるようになってきています。
いわゆる多層防御の構成です。

FS ソリューション

このような多層防御構成になっているシステムにおいて、セキュリティの観点から重要になってくるのが「内部関係者の扱い」です。外部からの攻撃に対する防御体制が整備されていく中で、内部関係者による故意または不注意による操作がサイバー攻撃に対する脆弱性を発生させる事例が増えてきています。

内部関係者による故意または不注意による攻撃に対しては、操作を含む各種ログの収集・分析がとても有効な手段です。適切なシステム操作上の役割を設定し、また操作ログの生成や保持の処理に対して適切な権限を設定し、ログに適切な電子署名を付加することで、内部関係者による攻撃に対しても追跡が可能なシステムにすることができます。

ではそのようなログはどこで生成・保持するのがよいでしょうか？
ネットワーク経由でシステム外部にログを送信して管理するのはどうでしょうか。つまりローカルに保持せず、リモート側で保持・管理するのです。

ログは工場稼働に必要なデータではなく、稼働の結果として生まれるデータですから、異なる管理区分のデータとして特定のサーバーまたはポート番号を設定するのが普通でしょうか。しかしそもそも、ネットワーク外部からの攻撃を防ぐ能力を高めるために多層防御構成をとっているのでした。
攻撃界面を増やすことになりますから、セキュリティ面からは避けたいところです。

そしてまた、ネットワークに対する DoS 攻撃などによる通信の不能化が発生した場合、ログが消失する可能性もあります。内部関係者による通信 I/F への攻撃があった場合、まさにそれをログとして残したいのに消失してしまった、というケースも考えられます。避けたいところです。

結局このようなログは、一時的か永続的かはケースによって異なりますが、ローカルに保持することになるわけです。
ローカルに保持するとして、ログという性質から以下の２点に注意する必要が出てきます。

稼働ログの更新は恒常的に行われる。
- ライン上の全ての装置のログを集約：そうでないと意味がない
- 直近の状況が重要：例えば過去１時間を保持し、それ以降は削除する、など
- 容量や価格や取り扱いの容易さなどから SD カードを使用する

ログの分析・診断は専用ソフトウェアで実施。
- メーカー提供（ Windows 版）：他の選択肢がないケースが多い

セキュリティ面からはできるだけ小さいシステム構成としたいところですが、２．の要請から外付けストレージは避けられないことになります。

そして、外付けストレージに対するログの書き込み中に不測の電源断が発生した場合を想定すると、以下のようなことが心配になります。

SD カードへのへの書き込み失敗が心配

直近データ保持のため、常に上書きが発生している。
長寿命化へのニーズは強い。
※ 設備は基本的に 24/365 稼働のため

Windows で SD カードがきちんと読めることが重要

設備は Linux を使用している。
Windows/Linux 共用は必須。

FS （ファイルシステム）の破損は絶対に避けなければならない

再稼働時は停止時の状況を把握する必要がある。
停止時は再現できないため。

これらの課題を解決または回避する施策は、どのようなものになるでしょうか？

３．外付けストレージ

ログを格納する外付けストレージに対する不測の電源断にどう対応するかを考える前に、いくつか片づけておかなくてはならないことがあります。 Linux カーネルおよびユーザーランドを構成するソフトウェアを格納するボード内フラッシュなどのストレージをどうする？という問題です。
次のような構成にするのが多いようです。

再起動時に必要なプログラムは ReadOnly 領域に格納する。
- カーネルが rootFS をマウントする時点で ReadOnly でマウントする等
- そもそも書き込まない（書き込めない）ので壊れない
ReadOnly のプログラム更新は手動で行う。
- メンテ要員が専用ハードまたは専用ソフトなどで入れ替える等
- 更新頻度が低いので問題ない
読み書きが必要なデータの格納領域は ext4 になっている。
- ジャーナル機能を有効にする等
- 不測の電源断があっても復旧できる

システムについては、すでに OSS で準備されているソリューションを上述のように組み合わせた構成で対応できそうです。

では外付けストレージに対してはどうでしょうか？課題を再掲します。

SD カードへのへの書き込み失敗が心配。
- 直近データ保持のため、常に上書きが発生している。
- 長寿命化へのニーズは強い。※ 設備は基本的に 24/365 稼働のため
Windows で SD カードがきちんと読めることが重要。
- 設備は Linux を使用している。
- Windows/Linux 共用は必須。
FS （ファイルシステム）の破損は絶対に避けなければならない
- 再稼働時は停止時の状況を把握する必要がある。
- 停止時は再現できないため。