コンテンツの編集
「コンテンツの編集」ボタンをクリックしてコンテンツを編集/追加します。

【 第3章 -Part2 】クラウド移行は危険?

  目次


オンプレのセキュリティ

 オンプレはもちろんすべてのセキュリティはユーザー側で担保することになります。データセンターの運用(入退室管理、外部からの侵入経路監視など)、サーバ・ストレージ・ネットワーク機器の調達、OSインストール作業などすべて自分たちの設計通りのインフラを構築できるというメリットはあるものの、ほぼすべてのセキュリティに関する事項をユーザー側で手配する必要があります。特にネットワーク機器、サブネット、VPNなどの構成から設計するため、各ハードウェア、OS、製品ごとのセキュリティ項目を理解して適切に設定することが必要となってくるため、高度なスキルが要求されます。


IaaSのセキュリティ

 IaaSではサーバー、ストレージ、ネットワークなどのハードウェア周りはすべてクラウドベンダーが提供してくれます。そしてOSをインストールするためのAWS Nitro Systemなどに代表されるサーバー仮想化層も提供され、ユーザーは自分の利用したいOSのインストール以降の上位層に関するセキュリティに対して責任を持ちます。ユーザーはコンソールもしくはコマンドベースで仮想マシンのスペック(CPU、メモリ、起動ディスクなど)を指定し、さらにOS(Linux、Windowsなど)の種類、バージョン、Linuxの場合はディストリビューションなども選択可能となっています。各OSやWebサーバー、アプリケーション・サーバーなどへのセキュリティ対策からユーザー責任となります。AWSの場合EC2、GCPではGoogle Compute Engine(GCE)などが仮想マシンとなります。

 このIaaSの責任範囲には各CSPがお客様のアプリケーションやデータに関して、「データはお客様の持ち物」という基本的な考え方がベースになっています。例えばパブリッククラウド利用中に何かわからないこと、うまく動かない場合などにサポートに連絡すると思います。その際にお客様の変わりに管理コンソールへログインして作業した方が早い場合があります。しかしその際にサポートは殆どの場合、明示的に管理コンソールへのログインに関してはあくまでもサポート目的でお客様からの許可があった場合のみ管理コンソールへログインします。勝手にサポートが知らない間にお客様のデータを見たり、ましてやアクセスして作業をしていたことを知ったらどうでしょう。

 CSPはあくまでも土地を貸すだけで、お客様がその上に建てた家には勝手に入ることが出来ないのです。ですので、家の中のセキュリティに関しては警報装置や監視カメラなどを自分で設置して、自分の家を守ると行ったルールが責任共有モデルの基本的なコンセプトとなります。そのため各CSPでは様々なセキュリティをサポートするサービスを提供し、お客様のセキュリティ維持をサポートするためのツール提供をしています。【 第7章 】のマルチクラウド対応でAWSが提供するセキュリティサービス一覧をご紹介していますが、非常に豊富なサービスをツールとして提供しています。これらのサービスを自分たちのセキュリティ要件に合わせて組み合わせて導入することにより、自分たちで1から作成するよりもこれらのサービス活用をした方が効率的に運用できるかもしれません。


PaaSのセキュリティ

 GoogleのApp Engine(GAE)に代表されるPaaS環境では、ユーザーはOSを意識することなくコードとデータのみに責任を持ちます。例えばGAEを利用すると、OSのインストールはもちろんロードバランサーの設定、ネットワークの設定などもすべてGoogle側でやってくれます。ネットワーク経由でアプリケーションへのアクセスが急激に増えても、GAE側でスケールさせてくれるのでアプリケーションのコードさえ正しく書けばよく、開発に集中ができます。OSやロードバランサー、ネットワークの設定までやらなくていいということは、逆に言うとそこに独自のセキュリティ設定を入れたくても出来ないということになります。GAEの場合であればGoogle側にそのへんのセキュリティまで委ねることになります。一方でOSに依存するフレームワークやクラスライブラリなどは使えなかったり、ローカルファイルへの書き込みなどが制限されているため、それらの条件が受け入れられる場合であればセキュリティ面では優位性がある選択と言えます。


SaaSのセキュリティ

 SaaSはIaaSやPaaSとは少し趣が違います。SaaSはユーザー側で開発や仕様の変更、追加などは基本的には出来ません。これまでPCにインストールして使っていたアプリケーション、例えばメールクライアント、オフィス製品、業務アプリケーションなど、ある特定のサービスを提供するアプリがクラウド上に稼働しており、ユーザーはブラウザやモバイルアプリからインターネット経由でログインだけすれば目的の作業ができるといった特徴があります。そういった意味ではログインさえできればSaaSで提供されているすべての機能が利用可能になってしまいます。

 ユーザー側として責任を持つとすれば、強度の高いパスワードや2要素認証などを導入することにより、アカウントの乗っ取りなどによるアプリケーションの不正利用やデータ流出に留意することが必要となります。また複数のSaaSを利用すると、それぞれ別のベンダーで提供されたサービスとなることもあるためログインアカウントがベンダーごとに違うものを使用しなければならず、別々のパスワードや認証方法により運用しなければならなくなり、パスワードの管理が複雑になることにより利用者側の負担となったり、同じパスワードを使い回すなどしてセキュリティ的にも問題になってくる。そこで、それらの認証方法を一括して提供可能なOktaAuth0などのシングルサインオンの仕組みを、3rdパーティ製サービスなどを導入することにより、利便性とセキュリティ向上を目的として導入するなどもセキュリティ的には有効となります。

 オンプレと比較したIaaS、PaaS、SaaSでのセキュリティ範囲を理解できたでしょうか。オンプレではセキュリティに関してすべての責任を追わなければいけなかったのが、クラウドを利用することにより負担が軽減できることを理解していただけたと思います。次のセクションでは各クラウドベンダーが提供している、パブリッククラウド利用時のセキュリティベストプラクティスに関してご説明いたします。


各CSPによるセキュリティベストプラクティス、セキュリティホワイトペーパーを参考にする

 各CSPからもセキュリティに対する基本的なセキュリティ設定項目のガイドラインが公開されています。前のセッションでご説明した、責任共有モデルも各CSPからそれぞれ公式に発表されています。特にパブリッククラウドのセキュリティに対する各CSPが提唱するガイドラインを事前にきちんと理解することにより、大部分のセキュリティに対する不安の払拭や自社のセキュリティ課題を解決することが出来る可能性があります

 オンプレの場合、責任共有モデルでも説明しましたが自分たちでデザイン、機器の発注、設置などを行うため、ある意味ホワイトボックスとしてセキュリティの監査が出来る状況でしたが、パブリッククラウドの場合、個々の顧客に対して基本的にデータセンター内への立ち入りは許可されていません。たとえ許可されてGoogleやAmazonのデータセンターへ立ち入ったとしても、実際に自分たちのデータが格納されているサーバーを特定することは出来ず、中央で管理されている管理コンソールのようなソフトウェア越しに仮想環境の状況を見ることしか出来ず、それを持って監査と見なして判断するしかないのです。

 また各種OSのバージョンやセキュリティパッチなどの適用状況などのチェックなどオンプレ時代の静的な監査項目はクラウドでは意味をなさないようになっています。以前はRFPやRFIにそれらのOSや利用している各種オープンソースのバージョンなどの記載要求がありましたが、クラウドによるアジャイル開発などにより、日々運用や開発方法も変わっており、ある時点でのバージョンの確認などは出来たとしても、それがセキュリティ監査項目として意味をなさなくなっているのです。

 ではパブリッククラウド環境を監査することは全く出来ないかというと、それに代わる方法で理解することになります。GoogleではGCPやGoogle Workspaceなどのクラウドサービスに関してお客様から監査要求があった場合、以前はセキュリティホワイトペーパーにより開示可能なデータセンター内での運用や暗号化などの仕組みを外部に対して説明する資料があり、その内容で自社の監査要求を満たしているかを最終的には自分たちで判断するといった内容でした。そして現在は以下のような各種国際基準の認定の取得や、個別の監査レポートをNDA(Non-Disclosure Agreement:秘密保持契約)ベースでCSPが指定した監査法人より提示することも可能になりました。

 

 現在のGoogle Cloudではホワイトペーパーはもちろん、コンプライアンス状況*というWebページで最新のコンプライアンス認証やベストプラクティスを公開しています。以下はその一部となりますがGCPだけでなくAWSなども同じような情報公開ページによりこれら情報を公開しており、自社のコンプライアンス、セキュリティ監査基準がどの認証で満たすことが出来るかを確認し、静的な詳細監査項目でチェックするのではなく、このような国際的な監査認証などの取得状況を確認することにより、各CSP自体のインフラ監査を代替することを検討し、自社のクラウド戦略として、特定のCSP、もしくは複数のCSPをあわせて利用するマルチクラウド戦略を採用するなどを。

Follow me!

PAGE TOP