新たに出てきたセキュリティ上の不安「CPUの脆弱性」にどう対応するのか
ここまで、主にクラウドを頻繁に活用することになったことから起きる新しいセキュリティインシデントについて語られた。そして、次々と起こる多様なインシデントに対応するには、場当たり的ではなく、しっかりとセキュリティポリシーを策定し、それに基づいてガバナンスをきかせていくということが大切、というのが参加者の共通認識のようだ。こうしたルール作りが、セキュリティの可視化を促し、新しい脅威への迅速な対応が可能になる。
新しい脅威といえば、2018年初頭に発見された「CPUの脆弱性問題」がある。「Spectre」や「Meltdown」が話題となった。この脆弱性はCPUのアーキテクチャーにかかわるもので、現在多くの企業で利用されているコンピュータ全体に影響があると言われており、この脆弱性を突くことで、さまざまな重要データが読まれてしまう危険性があるとされている。現在考えられている対応策としては、パッチの適用やソフトウェア側からの防御策などが提供されている。
今回実施した調査では、「近年CPUの脆弱性問題などが発覚していますが、ハードウェアレベルのセキュリティリスクを意識していますか？」という質問を投げかけ、「意識している」が46％、「意識していない」が54％と、ほぼ半数に分かれた。そこで、CPUの脆弱性への対応について話してもらった。
図４：近年CPUの脆弱性問題などが発覚していますが、ハードウェアレベルのセキュリティリスクを意識していますか？
※クリックすると拡大画像が見られます
A氏
CPUの脆弱性に対応すると、パフォーマンスが低下する懸念がある。期待していたパフォーマンスがどれだけロスするのかも分析した上で、かつそのサーバの役割、VM、インスタンスの役割を再考しなくてはならない。それは、パフォーマンスが劣化してはいけないものなのか、劣化しても別にいいものなのかをまず考えるのと、あとはいかに周りの保護がちゃんとできているかということですね。
結局、今回のCPUの脆弱性は、メモリも含めて取られてしまう。その本質を理解した上で、どの役割のサーバをどう対応すればいいのかをちゃんと決めるしかない。結果として、Spectreに対してパッチをあててないところもありますし、あてたところもあります。
CPUの状態は常に監視する。状態を見て、20％ロストしても危険域にならないなど、インフラの人たちとも相談しています。結局、セキュリティでやりたいのは情報が盗まれないこと。でも、それに対してコストに関わるところは、餅は餅屋で話をしながら会社としてどうするのかという結論がちゃんと出ればいいと思っています。
C氏
うちも実は、静観しているところはあります。話題にはなったのだけど、パフォーマンスや、あとは使っているミドルウェアで、これを入れると保証しませんと言われて。結果としてやはり、周りでセキュリティ対策をしているからいいということになりました。
F氏
セキュリティで何を本当に対策しなければならないのかという軸がないと、結局こういうCPUの脆弱性とか出てきたときに、何かやっておかないといけないんじゃないとなって、結局あいまいな対応になってしまいます。
A氏
リスクレベルを会社ごとに測っておくことが大切です。「ここまでのリスクだったら許容する」「ここからは許容しない」ということですね。そして対策をするなら、これだけコストがかかるということも理解してもらわないといけないですね。
特定のハードウェアごとの危険性などは、ちゃんと分析して判断する必要があります。噂レベルの話に踊らされないことも重要ですね。
日本ではこの人が言ったからと、有名とか権威のある人に右にならえになってしまうことがあります。セキュリティは会社ごとに守るべき対象とかレベル感とか予算のかけ方も違うわけで、その上で対策を考える必要がある。本当に大切なのは、ITガバナンスなどルール作りの方です。
最終的に今回話題になったテーマは、エンジニアがポリシーをちゃんと作っていれば済むことですよね。上から言われたからではなく、俺たちはこんなものを作っていくというビジョンをちゃんと持って、そのためにこんなポリシーが必要だと。ポリシーがきちんと醸成されて改善されていくと、それに当てはめるものはオンプレミスであってもパブリッククラウドでもいい。そういうところがちゃんと定義できるかできないかによってくるのではないでしょうか。
今回の調査で、ハードウェアのセキュリティへの対応については、「情報収集など動向に注目していく」（63.5％）、「具体的な対策方法を検討していく」（14％）、「意識啓発や注意喚起を図っていく」（10％）、「特に考えていない」（12.5％）という結果となった。
「Spectre」や「Meltdown」などは、CPUの高速化手法の機能にまつわる問題で、マルウェアなどを外部から仕掛けられて起こる脅威ではない。より機能強化しようと設計されたハードウェアから見つかった脆弱性のため、ユーザーにとっては「寝耳に水」のような話だった。そしてこうした問題は、今後も発生すると予見される話題であったに違いない。
座談会での発言にもあったように、ハードウェアの設計上で発生する問題であっても、セキュリティポリシーの構築が重要になる。脆弱性とそれに関連する脅威の第一報に慌ててしまうことなく、冷静に、どうすれば、被害やリスクを最大限低減させることができるかを検討し、素早く施策を打たなければならない。
調査では、こうした問題に対しては「情報収集など動向に注目していく」という回答が多かった。これは、現実的にいえば「それしか方法がいまのところ見当たらない」という本音が潜んでいると思われる。しかし、情報収集について自社だけで対処しているのではなく、ハードウェアの脆弱性についてより専門的な知見を持ったパートナーを選んでおくのも重要だ。こうしたパートナーがいることで、正確な情報を把握するだけでなく、その後の適正な対応プランも構築しやすい。
そうしたことを考えると、ハードウェアの選定では、グローバルレベルでセキュリティインシデントの情報をいち早く把握し、製品やサービスに対策措置を迅速に組み込めるベンダーのものを選んだ方がいいだろう。また、運用側の手間をかけさせず適切にセキュリティ対策を講じることができる自動化サービスなどの最新機能があるか、ヘルプデスクがしっかりしているか、ということもポイントとなる。インシデントそのものの情報収集も大切だが、こうした脅威への対応を見逃さず適切な対応策を説明できるベンダーをパートナーとして選定することが、最終的には、リスクを軽減させるバックボーンとなる。
プライベートクラウドを構築したばかりの段階で、このようなハードウェアの脆弱性が発見されたら、購入したばかりのサーバ製品などをすべて取り換えるというわけにもいかない。また、脆弱性が解消された製品はまだ販売されていないというケースも考えられる。このような場合には、座談会の参加者からも意見が出されたように、まず脆弱性に対する理解を素早く行い、そのうえでシステムのどの部分を別の代替システムに移すか、あるいは、ソフトウェア側からの対処で済ませるかを検討する必要がある。
この代替システムは、パブリッククラウドという案も出てくるだろう。では移行をしていくにはどうすればいいのか、すぐに具体的なプランを出していく必要がある。もし、システム更新時にハイブリッドクラウドを選択していれば、こうした緊急避難策をすぐに実行することが可能だ。このように考えると、例えば、「メインはプライベートクラウドで運用するが、データバックアップや災害対策用としてパブリッククラウドも併用する」という選択肢は、セキュリティ対策の一環としても有用ではないだろうか。
今後ますますハイブリッド環境化が進む中、現実的な脅威として迫るハードウェアを狙う攻撃への対策が組み込まれているか、万一の際の検知と復旧が可能であるか。EOSをきっかけに、自社に最適なシステムの在り方を検討を始めてはいかがだろうか。
