7
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

フューチャーAdvent Calendar 2019

Day 8

新旧Windowsの接続で知らないとハマる罠

Last updated at Posted at 2019-12-08

フューチャーアドベントカレンダー2019の8日目のエントリーです。昨日は @ya-mada さんによる真面目にシステムの品質を設計し、作り込む手順を考えるでした。

はじめに

Microsoft Windowsは、マイクロソフトが開発・販売するOSのシリーズである。1985年に初登場し、前年登場のMacOSを追い越して、またたく間にパーソナルコンピュータ市場でトップシェアを誇るようになった。現在は家庭用のコンピュータだけではなく、組み込みやサーバー、スマートフォンにまで最適化されたWindows系のOSが用意され、様々な場面において利用されている。

今回は制御系システムで扱われているWindowsを例に、新旧Windowsが混在した場合に発生する問題について2つ紹介する。

制御系システム

現在の生活にはなくてはならない計算機システムだが、工場などの制御系システムともその関わりは深い。例えば製鉄所など、複雑で膨大なプロセスを管理する必要のある工場では、大規模なシステムを構築している。工場によっては、24時間連続運転に耐えうる信頼性や、下工程にみられる高レスポンスといった要求など、非常に厳しい条件が要求される。そのため、計算機システムを導入しはじめた当初は、ハードもソフトもメーカ頼りであった。工場制御では高機能な専用システムか、リレー回路を用いるなどを行う必要があり、結果として高額な投資が必要になりがちであった。

そんな中、汎用OSの登場、特に市場に出回るPCのOSの大部分を占めたWindowsを利用することで、より複雑な制御をより安価で行えるようになった。結果、Windowsは工場の制御系システムで利用されてきており、現在まで続いている。

"塩漬け"な機器

まず制御系システムに限ったことではないが、一度オンライン化したソフトウェアにとってOSなど環境が変わることは、用意に受け入れられるものではない。外部インターネットにさらされるWeb系のシステムであれば必要に応じてパッチを当ててセキュリティーホールを埋めたりするが、制御系システムの場合、 外部から独立したNWであること1 を前提に、一切のパッチ適用処理を行わないことがある。加えて、製造業では2~30年を寿命に見込んで機械設計を行うこともあるので、結果として制御系システムも独立したNWを維持したままそれ相応の時間を一緒に過ごすことになる。

スライド1.png

スライド2.png

つまり、例えば今からあなたがWindows10をとある制御系NWに組み込もうとしたとする。すると、そのNWにはWindows Server 2003がいることがある。

塩漬け機器による弊害

シビアな制御が要求される制御系システムのPCが塩漬けにされてしまったとして、例えば新しいPCを導入したときにちゃんと通信できれば、最低限業務に利用することはできる。時代を経て新たな通信規格や技術が生まれたとしても、プロトコルなど必要な手順さえ守れば古いPCとも疎通することは実際可能なケースは多い。

それを踏まえで問題になるのが、従来利用してきた技術などに問題が発生し、その修正が行われた場合である。その場合、新しいOSと古いOSの間で特定の通信ルールが変わり、何らかの対応が必要となる。例えばLinux系のOSであれば、古いOSのイメージの利用を続け2、システム全面刷新のタイミングですべてのOSを入れ替える、などが可能であるが、Windowsの場合、入手できるOSはそのタイミングでMicrosoftが提供しているOSに限られる。つまり、例えば最新のOSで何らかのセキュリティホールが生まれMicrosoftがその修正を行った場合、すでに現場で導入されているPCとこれから新たに導入するPCの間で通信ができなくなる可能性がある。

スライド3.png

新旧Windowsの通信で注意が必要な技術

Windowsに限らず汎用OSのメリットは、いずれかのシーンで使いたくなるであろう技術が概ね搭載されていることであり、運用の場面でその技術を前提にしていることも少なくない。以下、運用の場面で使われるにも関わらず、新旧で変更が加わり注意が必要になった技術について記載する。

Windowsファイル共有

システム間でデータのやり取りを行う場合、特にシーケンシャルな処理を要求する場合はTCP通信を作成するなどの方法はあるが、Windowsで最も簡単に利用されがちなのが「Windowsファイル共有」である。これは互いがローカルのファイルを扱うかのようにソフト開発を行えるというメリットがある。

Windowsファイル共有で使用されているのが、SMB(Server Message Block)プロトコルである。2000年にMicrosoftがSMB 1.0をWindows 2000に導入して以降、各OSにて利用されてきた。しかし、その後の技術の進歩によって、暗号化強度や通信効率の面から好ましくないとされるようになった。2013年、MicrosoftはWindows Server 2012R2以降ではSMB 1.0は非推奨と定義し、2017年9月のWindows 10 Version1709でSMB 1.0を初期状態で無効とした。

2019年12月現在に入手できる最新のWindows10では、「Windowsの機能の有効化または無効化」->「SMB 1.0/CIFSファイル共有のサポート」にチェックを入れることで、SMB 1.0を使えるようになる。しかし、MicrosoftがSMB 1.0を無効にした経緯を鑑みるに、利用する際には運用方法やセキュリティの面などを十分に検討する必要がある。

リモートデスクトップ

運用担当者としては、遠隔で各マシンの様子を確認できるツールは非常にありがたい。Windowsの場合、デフォルトで入っているリモートデスクトップはその際たる例である。しかし、このリモートデスクトップにCredSSP3に関する脆弱性が発覚し、2018年3月~5月に更新プログラムが適用された。これはリモートデスクトップ時の認証手続きの順番が変わる変更であったが、結果このアップデート適用済みPCと未適用PCでリモートデスクトップができないケースが生じるようになった。特にサーバーが古いPCでクライアントが最新のWindows10だとリモート・デスクトップできないようになっており、「リモートメンテナンス用の端末を更新したら今まで管理していたサーバーにアクセスできない」ケースが生じうる。アクセスしようとして失敗すると「認証エラーが発生しました。要求された関数はサポートされません。」と表示される。回避策など含めた詳細についてはMicrosoftの技術ブログに記載されているが、使おうという場合は注意が必要である。

まとめ

Windowsは非常に優れたOSであり、便利な機能が数多く揃っている。しかしWindowsに限らずプログラムには何らかの脆弱性が見つかりうるし、それによって何らかの変更が加えられることはある。かつて使えた機能だからといって、今も同じように使えるとは限らないので、技術の採用に関しては適切に検証を行う必要がある。

  1. 基幹系との間にファイアウォールを設けるなどしていることもあるが、その際も制御系システム内はパッチを当てていないマシンの見本市である。

  2. あくまでその場しのぎ的な一つ案であり、常に古いOSに揃え続けることを良しとするわけではない。

  3. Credential Security Support Provider。認証技術。

7
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?