クラウドは安全なのか危険なのか。この問題は、SaaS（サース／サーズ）やクラウドコンピューティングが市場で話題になり始めた2005年ごろから何度となく議論されてきた。しかし、現在ではAWSやAzureといったパブリッククラウドを利用する企業は多く、大手都市銀行さえ基幹業務システムにパブリッククラウドの基盤を利用するようになっている。

しかし、1月に発生したファイル転送サービスの情報漏えい事件で、そのサービスにAWSが使われていたと聞くと「やはりクラウドは安全ではないのか」と不安に思うかもしれない。クラウドは安全なのか？ パブリッククラウドのセキュリティはどう考えればいいのか。

総体的にはクラウドは安全・安心

セキュリティ関していえば、現在、オンプレミス環境を構築して維持・管理を自前で行うより安全と言っていいだろう。サイバー攻撃が今ほど高度化、多様化していなかった時代なら、業務システムやメールシステム、Webサーバーのために、自社のサーバールームにハードウェアを設置したり、データセンターのハウジングサービスを利用したりしても、ウイルス対策ソフトやファイアウォールで一定のセキュリティは確保できた。

しかし、現在、企業において安全にサーバーを管理しようとしたら、上記の対策に加え、UTMのようなセキュリティアプライアンスの導入、システムの監視、トラフィックの監視、各種ログの管理と保管、サーバールームの入退室管理など考慮すべき点は多い。加えて、BCPやシステムの信頼性を考えると、建物の耐震性、耐火・防火設備、空調設備、停電対策（UPSや非常用電源）、システムやデータのバックアップおよび冗長化なども求められる。当然、これらの対策には人と時間と予算というコスト（リソース）がかかる。

クラウド利用をすれば、これらの対策がすべて解決するわけではないが、多くの部分をクラウド管理事業者に委託することができる。しかも、AWSやAzureといったクラウドサービスは、規模のメリットを生かしてシステム全体のセキュリティや信頼性を高めている。一般的な大企業でも、同じレベルのセキュリティをオンプレミス環境で確保するのは現実的ではない。パブリッククラウドとはいえ、実体は巨大なデータセンターだ。自家発電装置や大容量の予備電源、空調設備や耐震設備、ガス消火設備（スプリンクラーや薬剤消火は燃えていない機器にもダメージを与える）、24時間体制のオペレーションセンター、厳重な入退室管理などがそろっている。

クラウドで重要な責任分界点

クラウドは安全だが、注意すべき点がある。それは責任分界点の認識と把握だ。AWSでは「責任共有モデル」などと表現している、クラウド事業者がどこまでセキュリティやサービスレベルを保証しているかという点を考える必要がある。

別の言い方をすれば、利用するクラウド環境のうち、どのリソースや機能が事業者から提供され自分で設定や制御ができないものか。どのリソースや機能が自分たちでカスタマイズできるかを考えることでもある。建物の堅牢性（耐震性、耐火性）やサーバーやネットワークなどの信頼性やセキュリティの一部は、クラウド事業者の責任で管理されている。これらの詳細を利用者から指定することはできないが、一般的に十分なレベルで安全性は確保されている。

しかし、OSのセキュリティパッチ、サーバーやネットワークの設定、インストールするミドルウェアやアプリケーションのセキュリティなどは、ユーザー側が担保する必要がある。多くのクラウド事業者は、セキュリティに関連するサービス、アクセス制御の機能、アカウント機能、認証機能、暗号化サービス、監視・監査機能を持っており、ユーザーが利用できるようにしている。これらの機能を正しく安全に設定・運用するのはユーザーの責任だ。

先ほどのファイル転送サービスの情報漏えいインシデントでいえば、ファイル転送のためにAWSを利用していたとしても、侵入された（と思われる）のはAWSを契約して利用しているユーザー企業（ファイル転送サービスのサービスプロバイダ）がインストールして構築したシステムだ。個人情報が漏えいしたのも、パスワードファイルの運用に問題があった（ハッシュ化せず平文で保存）ことも指摘されている。AWSの内部的なサーバーやシステムが侵入されたわけではなく、ユーザーが構築したシステム環境がセキュアでなかったから発生したものだ。

パブリッククラウドで提供される機能

AWSやAzureなど、多くのパブリッククラウドで提供される仮想サーバーは、一般的なイントラネットで構成される業務サーバーやデータベース、Webサーバー、メールサーバーなどDMZに設置するサーバー類、ECサイトのような外部向けのビジネスサーバー（データベース含む）を任意に構成できる。

ファイアウォールや認証サーバー（Active DirectoryやLDAP）、ロードバランサー、バックアップシステム、DNS、ルーターやスイッチ、システムのオーケストレーション（統合管理環境）に相当する機能は、クラウド上の管理サービス機能として提供される。

自動バックアップやデータの暗号化、ログの収集、トラフィックの監視、脆弱性診断なども、同様にクラウドのサービスとして提供される。

パブリッククラウドは一般的にIaaSという説明をしたが、PaaS、SaaSといったレベルの機能提供もされている。PostgreSQLやMySQLといった主だったデータベース管理システム、メッセージツールやスケジューラー、グループウェア、VDIのようなアプリケーションもメニューから選ぶ形で仮想サーバーインスタンスにインストール、または自社開発アプリケーションからAPIで利用できる。

パートナー企業がさまざまなアプリケーションを提供するアプリマーケットのような仕組みも用意されている。

クラウドセキュリティ：4つのポイント

では、パブリッククラウドを利用するとき、ユーザー側はどんなセキュリティ対策を考えればいいのだろうか。

通常、パブリッククラウドは仮想サーバーによるIaaSとして利用する。つまりサーバーハードウェアとOSまでがクラウド事業者が管理する範囲として、ユーザーがその存在を意識する必要は、原則としてない。ただし、OSについては、クラウド上に仮想サーバー（インスタンスという）を立ち上げたあとのメンテナンス、セキュリティアップデートはユーザーが行う必要がある。事業者によっては、自動アップデートのようなマネージドサービスを提供する場合もあるが、その管理主体はユーザーとなる。

パブリッククラウドのセキュリティでは、主に次の4つについて考えるとよい。

セキュリティポリシーや対策技術について、クラウドだからということで本質が変わるものではない。あくまで、自社の情報システムやリソース、守るべき情報資産から、どういうリスクに対して、どんな対策をすればいいかを考える基本は変わらない。これが決まれば、必要な保護機能、対策技術、ネットワーク構成、アカウント管理ポリシーなどは自然に決まる。

クラウド環境ならではのセキュリティ戦略

クラウド環境ということで、意識するとしたら次の点だ。システムのクラウド化を考えるなら、業務プロセスに合わせてクラウドの設定やシステムの作り込みをするより、提供されているサービスや機能の組み合わせで手順やプロセスを柔軟に対応させることを考えるべきだ。セキュリティポリシーやコンプライアンス上、どうしても譲れないルールや機能がある場合、それがクラウド事業者が提供する機能で実現できないならば、無理にクラウド利用にする必要はない。サーバーやネットワークの構成、ルーティングやアクセス制御が煩雑になり、かえって危険だ。

アカウントの管理でも注意点がある。パブリッククラウドを利用するための管理者アカウントは、インスタンスの生成やネットワークの設定などすべての権限（ルート権限）を持つもので、厳重な管理が必要だ。一般的なサーバーのアカウントと同様に、ルート権限を持つ管理者アカウントは、通常の設定、管理作業には使わない。インスタンスの生成やセキュリティの設定など、管理作業ごとに必要な権限だけを付与した別のアカウントを作成して、これを使うようにする。

クラウドの管理作業に使用するアカウントは、IDとパスワードによる保護だけでなく2要素認証を利用したい。主だったクラウド事業者は、2要素認証のための機能を提供しているので、設定を有効にしておく。アカウント情報が漏れると、クラウド内のファイアウォールの設定やサーバー・ストレージのアクセス制御などが勝手に変更されてしまうことになる。

なお、業務サーバーなどイントラネットの環境を、パブリッククラウドに移行する場合、会社のネットワークからクラウドまでの接続には、インターネットVPNを利用するか、通信事業者が提供するVPNサービスを利用する必要がある。