1ランク上の企業セキュリティを目指そう！
クラウド活用時のセキュリティでいちばん重要なのは？

業務システムのほとんどがクラウド構築、クラウドサービス利用を選択しているため、現在の企業セキュリティの多くが、クラウドセキュリティのソリューションに関係している状態にある。

クラウドセキュリティにおいて、まず考えたいのはアカウントやクレデンシャル（資格・認証）情報の管理だ。攻撃者がクラウドシステムを狙う場合、堅牢なクラウドプラットフォーム（実態は大規模データセンター）のハッキングよりも、フィッシングなどによるアカウント情報を狙うからだ。ログイン情報を得るか、セッションキーを入手してログイン中のサービスにアクセスできれば、ハッキングスキルを駆使して侵入するより簡単だからだ。

だが、ログインやセッション管理を強化しても、防げないインシデントもある。それはクラウドの設定ミス等によって、機密データなどが公開状態になっている場合だ。設定ミスは、注意すれば防げるものだが、実際のクラウドインシデントの原因は、不適切な設定、間違った設定によるものが多い。Fortinetの2023年の調査によればクラウドに対する脅威の59％（第1位）が設定ミスだと答えている。

クラウドのセットアップや設定そのものはメニュー方式が多く、GUIも洗練されていて簡単だが、正しい設定、適切な設定、安全な設定となると話は別だ。GUIや設定ウィザード機能は平均的な動作環境を半自動で構築してくれるが、詳細がブラックボックス化されていて（だから簡単なのだが）、全体の見通しが悪くなりがちだ。

とくにオンプレミス環境との接続、他社プラットフォームとの連携には注意を要する。他サービスと連携するとき、セキュリティの設定が邪魔をしてうまくつながらないトラブルは、誰もが経験したことがあるのではないだろうか。

ここに不適切な設定が生まれる要因がある。あちらを立てればこちらが立たず、といった状態になり、システムを稼働させるためアドホックな設定をして、全体の整合性や安全性が損なわれてしまう。あるいは、込みいった設定はドキュメント化やメンテナンスが面倒になるので、デフォルト設定に従うだけの導入をする。デフォルト設定を基本とするポリシーは、システムを複雑にしないので悪くないのだが、ドキュメントや注意書きの確認を怠り、不適切な設定のまま運用してしまうこともある。

この手の設定ミスで起こりがちなのが、機密データの意図しない公開、情報漏洩だ。権限のないユーザーにアクセスを許可してしまうこともある。

設定ミスによって漏洩したデータが攻撃者の目に留まれば、アンダーグラウンドマーケットで販売されたり、リークサイトに公開されたり、別の攻撃に利用されたりする。ところで、漏洩が発覚した企業は「漏洩データを悪用した攻撃は確認されていない」と発表することが多い。だが、実際にこの確認を行うのは困難で攻撃が本当に発生していないかは誰もわからない。

クラウドセキュリティでの最大の課題ともいえる設定ミス・不適切設定について、総務省がガイドライン（クラウド利用・提供における適切な設定のためのガイドライン）、およびその副読本としてガイドブック（クラウドの設定ミス対策ガイドブック）を公開している。

ガイドラインは、クラウドサービス利用者（ユーザー企業）、クラウド事業者のそれぞれに向けた内容で、ターゲットごとに章が分かれている。クラウドにおけるセキュリティ設定項目を13に分類して、それぞれの意味やリスクを解説している。たとえば、IDとアクセス管理（IAM）、オブジェクトストレージ、仮想マシン、鍵管理、コンテナといった項目がある。設定時に、関連項目の意味とリスクを理解するのに役立つ情報だ。

利用者、事業者ごとの解説では、組織体制や作業規則、各種設定管理といったトピックについて考え方と注意点を解説している。各種設定管理のセクションでは、前述13の設定項目について例を交えたベストプラクティスも掲載されている。

例えば、コミュニケーションのセクションでは「仕様変更や新機能リリースで利害関係者と協議する」「責任分担（後述）の再確認をする」といったポイントが書かれている。個別の設定項目では、「ネットワーク設定ではログ機能がデフォルトでオフになっていることがある」「設定項目の管理は値や内容の可視化ツール、機能を活用する」「復元するしくみはあるか」といった具合だ。

ガイドブックは、ガイドラインの内容をさらにわかりやすくするための副読本となっている。クラウドシステムとはなにか、どういったシステムなのか、という基本的な解説とともに、セキュリティの考え方を解説している。用語解説も基本的なものに絞って解説しているので、クラウドシステムの概要から把握するのにも使える資料となっている。

コラムページでは「よくある設定ミス」として「デフォルト設定のまま」「ユーザー権限の不適切な区分」「多要素認証の不備」を解説していたり、マルチクラウドやコンテナ利用での課題などを紹介している。

2つの参考資料をもとに、クラウドセキュリティの考え方と主な対策をまとめる。

クラウドにはオンプレミスシステム上に構築するプライベートクラウドとクラウドベンダーが提供するインフラを利用するパブリッククラウドがある。セキュリティ対策において、プライベートクラウドは、自社所有のリソースを使うことが前提となり、システムもクローズドなものになるだろう。プライベートクラウドのセキュリティは、従来型のセキュリティと本質的にはかわらないので、ここではパブリッククラウドを前提に考える。

パブリッククラウドで押さえておくべきなのは、「責任共有モデル」と呼ばれるものだ。クラウドにはIaaS、PaaS、SaaSという3つの分類方法がある。この分類は、自分がシステムをどこまで用意するかを基準にすることができる。

IaaSは、サーバーハードウェア（コンピュータ）、ネットワーク、電源設備、仮想サーバー環境の一部までを事業者が提供する仮想環境を契約・利用する。OSやシステムに必要なミドルウェア、業務アプリケーションは利用者が構築または購入して用意する。PaaSではOSやミドルウェアまで、事業者が用意しているものを利用する。SaaSになるとシステム上で動作するアプリケーションまで事業者に用意してもらう。

責任共有モデルは、上記のクラウドの利用形態によって最終的なシステムの責任範囲を考える。つまり、IaaSにおいて仮想環境の一部やOSからアプリケーションの設定、データの構築や設定は利用者が責任を負う。セキュリティも同様に考えるので、ネットワーク機器やサーバーハードウェアに関連する不備や脆弱性はクラウド事業者の責任となり、それ以外の部分の設定やセキュリティは利用者の責任となる。

具体例でいうと、IaaSではOSを最新の状態に保つのは利用者の責任で行うが、PaaSではクラウド事業者が責任をもって行うという考え方だ。ただし、実際にはサービス契約、SLAによる。PaaS利用でも、OSのアップデートは自社アプリケーションでの動作検証をしてから行いたい場合もある。

クラウドシステムは、複数の事業者のサービスやプラットフォームを混在させることが少なくない。責任共有モデルの考え方は重要なので、関連する事業者やプロバイダー、アプリベンダーが多くなると、それぞれの責任範囲を明確にしておく必要がある。

データについては、原則として利用者（企業）の資産・所有物となるが、取引先やパートナー企業の権利が生じる場合もある。顧客データは個人情報保護法の制限も受ける。データに関する設定やセキュリティ対策は、クラウド利用者とステークホルダー全体での管理を考える必要がある。

設定ミスでありがちなのはデフォルト設定のままの利用だ。システムを確実に動作させたいならデフォルト設定をなるべくいじらないことだ。その後の管理やメンテナンスでも、デフォルト状態ならトラブルも少ない。しかし、セキュリティ対策では、ユーザーやシステムリソースに正しいアクセス制御を適用することは基本である。

クラウドシステムでは、ユーザーやシステムに必要以上の権限を与えない。最小権限をデフォルトとして、必要最小限のアクセス権限を基本とする。二要素認証やリスクベース認証（状況によって追加認証を行う）も設定したい。データに対しても同様だ。設定は面倒になるが、「誰でもアクセスできる」データはなるべく作らない。基本はアクセスできない状態として、必要なユーザーやアプリケーションに対してだけアクセス権をあたえる。

クラウド環境では、簡単に仮想サーバーを立ち上げることができる。試験用環境やプロトタイプを作るのも簡単なコマンド操作、クリック操作ですぐに使えるようになる。クラウドシステムの真骨頂であるが、必要がなくなった仮想サーバーやシステムは放置されやすい。放置されたサーバーは、攻撃者の格好の標的となりシャドーITと同様にクラウドシステムのリスクとなる。

クラウド環境の設定は込みいってくると管理が難しい。ポリシーやドキュメントを整備して、設定リストやチェックリストを作っても人力では限界がある。この部分はツールやシステムの力を借りることになる。

クラウドベンダーやセキュリティベンダーが、構成管理ツールやサービスを提供している。設定情報などを可視化してくれて、ポリシー違反となる設定を抽出してくれる機能もある。セキュリティのための継続的な管理体制まで含めた対応をポスチャマネジメントと呼ぶが、大規模なクラウドシステムや、インターネットにつがなったシステムを使う場合、構成管理やポスチャマネジメントのサービスやソリューションを利用するとよい。

それでもシステム拡張やアップデートがあると、リアルタイムでの全体把握は難しくなる。別アプローチの対策としては、脆弱性診断やペネトレーションテストによる、システムの脆弱性や不適切な設定を洗い出す方法がある。脆弱性診断では稼働中のサーバーや利用しているライブラリ、サービスの銘柄、バージョンをチェックして脆弱性の有無を調べることができる。ペネトレーションテストでは、システムの状態はどうであれ、攻撃可能なポイント、侵入可能なポイントを専門家が実際にシステムにアクセスして発見する。

脆弱性診断とペネトレーションテストを、必要に応じて実施するとよいだろう。