この記事は、ニフクラブログで2021-12-16に公開された記事を移転したものです。
こんにちは。富士通クラウドテクノロジーズの鮫島です。
前回の記事（前編）では、クラウドの情報セキュリティについてクラウド事業者の責任範囲を中心に解説しました。
今回は、ユーザー責任部分の情報セキュリティ（OSより上のレイヤー）について、ユーザーがやるべき対策を初心者エンジニア向けに解説します。
前編で解説したように、クラウド事業者の責任範囲においては、その管理体制、たとえばセキュリティホールに対するパッチ当てなどのルール・対応が自社のセキュリティポリシーに合致したものであるかどうかをユーザーはクラウド事業者からの情報開示によって確認する必要がありますが、ユーザーの責任範囲においては、たとえばソフトウェアに何らかの脆弱性が見つかった場合は、ユーザー自身で対応する必要があります。
一つの例ですが、WebサーバーソフトのApacheに脆弱性が発見された場合、上記の責任分解点では、ユーザーの責任範囲になります。
最近の記事ですが、実際の対策をイメージする参考にしてください。
blog.pfs.nifcloud.com
責任分界点の上半分を雑に説明するとこんな感じ
最近、ありがちな光景です。
お客様「ニフクラ/FJcloud-Vって、ゼロトラストに対応していますか？」
弊社「ニフクラ/FJcloud-Vでは標準でマイクロセグメンテーションによるゼロトラストを実現しています！」 と即答。
ニフクラ/FJcloud-Vでは、仮想マシン単位でファイアウォールのルール設定を行うことが可能なので、マイクロセグメンテーションを実現できます。
※マイクロセグメンテーションはゼロトラストの一部しか実現してないぞ！というツッコミは定期的に社内で実施しています。
なぜ、このような話をするのかというと、ゼロトラストに必要な技術要素はユーザー責任範囲で実現されることが多いからです。
「ファイアウォールは提供しますが、設定するのはお客様ご自身です。」
ユーザー責任範囲で何をどこまでやればいいの？
ニフクラ/FJcloud-Vのセキュリティホワイトペーパー(PDF)の7Pにこのような記述があります。
4.1.クラウドセキュリティの基本的な考え方 クラウドセキュリティには 2 つの側面があります。1 つはサービスの提供者がクラ ウドサービスの提供のためにどのようなセキュリティ対策を実施しているか、もう 1 つはユーザーがクラウドサービス上でどのようなセキュリティ対策を実施するか、と いうことです。
つまり、クラウド事業者が自身の責任範囲におけるセキュリティ対策を強固に行ったとしても、ユーザーが適切な対策を行わなかったら意味がないということです。
ニフクラ/FJcloud-Vのセキュリティホワイトペーパーの
6. ニフクラユーザーのためのセキュリティ関連機能
には「ユーザーに提供しているセキュリティ機能」が記載されています。
ユーザーは、これらの機能を駆使して、自身の責任範囲のセキュリティ対策を行うことになります。
「で、何をやれば安全なの？」
こういう疑問がでてきませんか？ 建前としては、ユーザー責任範囲だから自分で考えてね！ということになります。
経済産業省のクラウドサービス利用のための情報セキュリティマネジメントガイドライン2013年度版(PDF)という、クラウドの情報セキュリティでは、古典でありながら決定版ともいえるドキュメントがあります。 このドキュメントを読むと
「クラウド利用者には，クラウド事業者から情報を得た範囲で自らの責任においてリスクアセスメントを行い，対応や対策を決定する責任がある」
と、突き放したことが書いてありますが、少なくとも
「リスクアセスメントを行い対応や対策を決める
」
ことは判明しました。
リスクマネジメントとリスクアセスメント
下記は、クラウドサービス利用のための情報セキュリティマネジメントガイドラインに掲載れている、2013年当時のクラウド利用に関わるリスクを図示したものです。
2021年現在、クラウドサービス利用におけるリスクはさらに増加しているといえます。
しかし、基本的な考え方はあまり変わっていません。
「事故が起きることを前提としてその損失を最小限にとどめること」
が重要です。
こういったプロセスのことを「リスクマネジメント」と言います。
さらに、事故が発生するリスクの要因となるのは「脅威」と「脆弱性」です。
事故を無くすためには、「脅威」か「脆弱性」いずれかをゼロにする必要があります。
これらのうち、どちらのリスクをゼロにするのが効率的かを検討するプロセスが「リスクアセスメント」です。
脅威もしくは脆弱性の排除とは？
たとえば、ソフトウェアやOSの脆弱性が見つかった場合、その対策は「セキュリティパッチ適用」「最新版へのアップデート」です。
「セキュリティパッチ適用」「最新版へのアップデート」が間に合わない場合、もしくは何らかの事情でそれが実施できない場合、その脅威を排除したり回避する必要があります。
脅威に応じて、アンチウィルスソフトを導入する、WAF（Webアプリケーションファイアウォール）を導入する、などの方法がそれに該当します。
冒頭でご紹介したApacheの脆弱性に関する記事を思い出してください。
※ちなみに、脆弱性が攻撃者に知られていないものは脅威にはなりません。
ユーザーは、自身のITシステムのリスクアセスメントを正しく行い、脅威を特定し、脆弱性を洗い出すことで 「本当に必要な対策」を選択すればいいのです。
リスクアセスメントを行った結果、
「本当に必要な対策を選択する基準って何？」という疑問が湧いてくるかもしれません。
やる・やらないは費用対効果で考える
そこで、基準となるのはやはり費用対効果です。
「今風に表現するとコスパ」
情報セキュリティでは、気密性・完全性・可用性の3つの要素から、影響を費用換算します。
たとえば、ある脅威への防御のために100万円/月のコストがかかるシステムを導入する必要があるとします。
年間1,200万円です。
そのシステムを導入せずに、単純に「セキュリティパッチ適用」をだけで済ませた場合、どれくらいの損失があるか？
年間1,200万円の費用と、「セキュリティパッチ適用」が遅れた場合の損失を比較して、著しく損失額が低い場合はあえてそのシステムを導入しないという選択もあるという考え方です。
某漫画で解説する多層防御 vs ゼロトラスト
とはいえ、昨今はサイバー攻撃の種類が複雑化・巧妙化しており、リスクとして許容できないレベルのもの（ランサムウェアなど）が増加しています。 ランサムウェアの被害は、コスパなどとぬるいことを言っていられないほどの損失（社会的信用の失墜とか）になるケースがあります。
「ゼロトラストって最低限やるべき対策なんでしょう？」
という人もいらっしゃると思います。
また、ゼロトラストがなぜ必要か？
境界防御の延長線にある多層防御って無意味なのか？という疑問を持つ人が多いと聞きます。
分かりやすいたとえを思いついたのでご説明します。
気持ち悪い巨人が、壁に守られた都市を攻撃して人間を捕食する漫画
を読んだことがある人は多いと思います。
セキュリティベンダー各社が、すでにこのネタで境界型防御が時代遅れ！これからはゼロトラストが来る！と言っています。
当ブログをそんなぬるい記事と一緒にしてもらっては困ります。
私が注目しているのは、主人公の兄(敵国の人)が得意とする、壁内潜入後に巨人を発生させる攻撃です。 これこそ、境界型防御を無効化するサイバー攻撃であり、検知も極めて困難です。
主人公たちは、物語の中盤から後半にかけて、この攻撃にたびたび苦しめられます。
この攻撃は、団長みたいな人が主導で脅迫とか拷問を駆使したリスクアセスメントを行い、脅威を特定し排除することで一度は対策されます。
ゼロトラスト的な脅威への対策
・情報収集と状況把握
・攻撃者の意図の特定
・内部に侵入している巨人の特定と駆除
・新規脅威侵入の検知と防御
完全な対策(サイバー攻撃犯の逮捕とか)には至りませんでしたが、脅威(敵国の存在)を可視化できたことで、国レベルで特定ドメインをブロックするような対策を行うことが可能になりました。
残念ながら、この国に孟子が居るのか？と疑いたくなるほど性善説に基づいた行動が多いことに読者はイライラしたのではないでしょうか？ そのせいで何度か敵国人による「サイバー攻撃」を許しています。
ISMSなどは性善説に基づいているので、「ファイルはローカルに保存しない」というルールが守られなければ、サイバー攻撃にあった場合に「覚えにくいパスワード集」などをあっさり盗まれるわけです。
ローカルに「覚えにくいパスワード集」を保存している人がいるという前提で、アクセス制御をするのがゼロトラストです。
一方、双方ともに航空機で自国内に兵士や巨人の侵入を許していますが、可視化された脅威であり、境界型＆多層防御の延長線で対処された点は注目すべきでしょう。
この漫画の教訓
・性悪説に基づくゼロトラスト的アクセス制御の重要性
・可視化された脅威は、境界型＆多層防御で対処可能
ゼロトラスト志向の防御策
よって、リスクアセスメントを元に必要な境界型＆多層防御を施した上で、現在考えられる新たな脅威に対処するためにゼロトラストを志向した防御策を追加するハイブリッド方式が、現実的な情報セキュリティの構築手法と言えるでしょう。
ゼロトラスト志向の対策例
・デバイスやリソース（ネットワーク含む）の全容把握
・通信・データの暗号化
・監視や検知の強化（全リソースを対象・マイクロセグメンテーションも）
・アクセス制御の厳格化（多要素認証など）
これらの要素は、現状ではワンストップのソリューションによって実現できることは殆どありません。
クラウド事業者がサービスとして提供している機能や、OSSやセキュリティベンダーが提供する機能の組み合わせが必要です。
また、機能要件でけではなく、組織や体制による対応(ガバナンスなど)が必要なケースも出てくるはずです。 そういった場合、NIST（米国国立標準技術研究所）が提唱するサイバーセキュリティフレームワークを参考にするといいでしょう。
NISTは、「SP‐800シリーズ」と呼ばれるアメリカの政府機関向けのセキュリティガイドラインを発行している組織であり、現在の情報セキュリティのデファクトスタンダードと言えます。
まとめ
IaaSならば、ユーザーの責任範囲においてある程度の自由度でセキュリティ対策を行うことは可能です。
しかしながら、オンプレミスで実施していた対策が、移行先のクラウドでは出来なかったケースは良くあります。
例１：オンプレミスで動いていたソフトウェアがクラウドで動作しない
例２：オンプレミスのネットワーク構成がクラウドで再現できない
移行してしまった後で、それが判明するとお互い不幸な状態になります。
事前に、クラウド事業者から情報収集をすることは重要ですし、クラウド事業者としてもそういった情報の公開は極めて重要といえます。
ニフクラ/FJcloud-Vのセキュリティに関しては、こちらのページでご確認いただけます。
参考文献：クラウドセキュリティ クラウド活用のためのリスクマネージメント入門（株式会社翔泳社）
