ニフクラ ブログ

ニフクラやクラウドの技術について、エンジニアが語るブログです。

情報セキュリティの観点(リスクベースアプローチ)でニフクラの可用性向上を考える

こんにちは、富士通クラウドテクノロジーズの鮫島です。 ニフクラブログを隅から隅までチェックしている一部の熱心な読者の皆様からは、ニフクラ エンジニアミートアップの事務局の人だと認識されているかもしれません。 もう一つ関わっていることがあって、特定非営利活動法人 日本セキュリティ監査協会が運営する「JASA-クラウドセキュリ ティ推進協議会」という組織で各種ワーキンググループに所属して、クラウドセキュリティの普及啓蒙活動に協力しています。

そこで、学習した情報セキュリティに関する知識を少しでも、ニフクラユーザーの皆様に還元できれば…と考えまして今回は情報セキュリティの観点からリスクベースアプローチによつニフクラの可用性向上について説明してみます。

情報セキュリティの三原則「機密性」「完全性」「可用性」

情報セキュリティにおいて、管理の三原則として挙げられるのは「機密性」「完全性」「可用性」です。
f:id:sameshima_fjct:20181106111642j:plain 「機密性」はずばり「情報が漏洩しないようにする」ことです。

例:ファイアウォールの設定に不具合があり、外部から情報が誰でも取り出せる状態になっていた。

こういうのは、「機密性」に問題がある状態です。

「完全性」は、「情報資産(たとえばデータ)が正しい状態で管理されている」ことです。

例:マルウェアに感染して、データが改ざんされた。

こういうのは、完全性に問題がある状態です。

クラウドにおける可用性とは?

それでは、「可用性」とはどういう意味でしょうか?

「いつでも必要な人が必要な時に使える状態にある」ことです。

例:サーバーにアクセスが集中して、業務システムに接続しづらい。

これは可用性に問題がある状態です。

「可用性だけセキュリティっぽくないよね…」と思った人が多数だと思います。確かにその通りですね。 分かりやすくする方法があります。

「機密性のリスク」「完全性のリスク」「可用性のリスク」という言いかえをしてみましょう。

クラウドにおける「可用性のリスク」とは、より簡単な表現をすると「サーバーが使えなくなるリスク」です。

可用性のセキュリティリスクと対策

「一般的に」下記のようなリスクがあると考えられています。 ※もちろん他にもさまざまなパターンがあり得ます。

 ・クラウド事業者のメンテナンスによるシステム停止
 ・クラウド事業者のハードウェア障害
 ・クラウド事業者のデータセンターの、大規模災害による機能停止。
 ・自分の仮想マシンが搭載されている物理サーバーを共有する他のユーザーの高負荷で影響がでる

どうです?クラウドにおける可用性がどんなものかイメージしやすくなりましたね? 情報セキュリティ監査の世界では、リスクを基準に管理策を考える方法をリスクベースアプローチと呼んでいます。この方法のメリットとしては、リスクを見える化して共有できるため、予防策・再発防止策が取りやすいこと、対策の目的が明確になり、セキュリティへの過剰投資を抑制できることなどがあります。

リスクをどのようにコントロールするか…クラウドの場合、クラウド事業者と利用者が共同責任モデルという考え方で責任分担をすることはご存知の方もいらっしゃると思います。   詳しくは下記の記事をどうぞ。

blog.pfs.nifcloud.com

クラウドの共同責任モデルを認識したうえで、ニフクラにおいて、どのようにクラウドの可用性を高められるかを考えてみましょう。

クラウド事業者のメンテナンスによるシステム停止

ニフクラを構成するコンポーネント(サーバー、ディスク、ネットワーク)はすべて完全二重化されており、特にストレージについては、RAID6相当の冗長化を行っています。

これによりニフクラのサービスを安定して継続提供し、お客様の情報資産を守っています。すべての機器が冗長化されているため、ニフクラ側でのメ ンテナンス時にお客様の仮想サーバーを停止することもありません。

クラウド事業者のハードウェア障害

クラウドといえど、データセンターでは物理サーバーが動いています。お客様がクラウド上に作成した仮想サーバーを搭載している物理サーバーが故障する可能性があります。

ニフクラの場合、約5分以内にほかの物理ホスト上に移動させ、再稼働させるHA機能を標準で提供しています。

ただし、最大5分のサーバー停止が生じますので、わずかな時間の停止も許容できないミッションクリティカルな システムにおいては、コストは増加しますが、サーバーを冗長化構成にすることで対策を行います。

クラウド 構成例(複数ゾーンでDBサーバーを冗長化する構成例) | ニフクラ

上記の構成例でも使用していますが、冗長化構成でサーバーを設置する場合、おすすめしたいのがサーバーセパレートという機能で、指定したサーバー2台を異なる物理ホスト上に分離的に配置できます。ご利用いただくことにより、冗長化用途のサーバーが物理ホスト障害の影響を同時に受ける確率を軽減します。

クラウド 構成例(ゾーンを跨いだ負荷分散の構成例(ゾーンコネクトを利用)) | ニフクラ

ニフクラの機能を利用して可用性を保つ方法は、eBook「ニフクラユーザーのための可用性向上のポイント」に簡単にまとめてありますので、ぜひダウンロードしてご確認ください。

無料eBookのダウンロードはこちら

クラウド事業者のデータセンターの、大規模災害による機能停止。

オンプレの場合と同様に、クラウドであってもクラウド事業者のデータセンターそのものが物理的に破壊されてしまうケースもあるでしょう。

ニフクラのデータセンターは、国土交通省のハザードマップを元に災害リスクの少ない場所に設置しています。

さらにデータセンターの建築は耐震構造であり、電源は2回線以上から引き込み、停電時でも稼働するようUPS(非常用電源)と自家発電設を冗長構成で備えています。しかし、データセンターの堅牢性は高くとも「想定を超える規模の自然災害」などで、データセンターそのものが完全に機能を停止するケースはあり得ます。  

ニフクラは複数のデータセンター(リージョン)を持っておりますので、例えば東日本リージョンでメインのシステムを構築している場合、西日本リージョンのバックアップを起動できるようにDRの対策をしておく必要があります。 詳しくは、下記の記事を参考にしてください。

blog.pfs.nifcloud.com

複数リージョンを利用してバックアップを取る構成例

閉域網や専用線経由でセキュアにリージョン間接続する構成例

自分の仮想マシンが搭載されている物理サーバーを共有する他のユーザーのリソース大量消費で影響がでる

これは、昔から「クラウド反対派」がよく気にするリスクの一つです。

IaaS(パブリッククラウド)は基本的にサーバーリソースを共有するのが特徴です。もちろん、ニフクラも物理サーバーを使用している以上、そのリスクを持っています。

しかし、ニフクラでは、ほかのお客様のサーバーによってリソースを大量に消費されるようなケースを想定して、稼働中の物理サーバーの負荷状況を監視してニフクラ内部で自動的にリソースの再配置が行なわれ、負荷障害を未然に防止します。

コストはかかりますが、さらなる高可用性を求めるならば、前述のサーバーセパレートを用いてゾーンを跨いで冗長化構成にすることでリスクを軽減させることもできます。

ゾーンを跨いだ負荷分散の構成例(サーバーセパレートを利用)

まとめ

今回の記事では、情報セキュリティ監査でよく使われるリスクベースアプローチでクラウドの可用性向上の方法について 解説しました。さらに詳しく可用性を考慮したクラウドでのシステム構築の考え方を知りたい方は、無料eBook『ニフクラユーザーのための可用性向上のポイント』を提供していますので、ダウンロードしてご利用ください。

https://lp.cloud.nifty.com/availablepoint.html?utm_source=fjct&utm_medium=blog&utm_campaign=iaas_ebook_availability

eBookのダウンロードはこちら