[検証!マイグレーション先としてのAWS]

移行前のアセスメント ~ 既存データセンターとAWSのセキュリティレベルを比較する

【第2回】

2017年7月10日(月)石田 知也(アイレット cloudpack事業部ソリューションアーキテクト)

前回はAWSクラウドに移行する前段階として、オンプレミス環境からAWSクラウドへのマイグレーションが意味するところ─IT担当者が心しておかなければならないポイント─について、責任共有モデルを中心に解説を行った。当たり前ではあるが、AWSクラウドでシステムを運用するということは、データセンターでラックを1本借りるのとはまったく意味が異なる。そこで今回は、ITインフラとしてのAWSクラウドは既存のデータセンターと何が異なるのか、特にクラウドに移行する上でもっとも注目されるセキュリティについて、両者における違いを掘り下げてみたい。

アセスメントは最新情報をベースに

 クラウドに限った話ではないが、ある程度の規模のシステム移行を検討する場合、事前のアセスメントは欠かせない作業である。そのクラウドサービスが安全かどうか、もし自社内に評価する基準をもたないのであれば、IPA(独立行政法人 情報処理推進機構)が公開している「中小企業のためのクラウドサービス安全利用チェックシート(http://www.ipa.go.jp/files/000011595.pdf)」を参考にするとよいだろう。また、cloudpackでもこのチェックシートをベースにした独自の評価基準を作成しており、AWSを含むすべてのクラウドサービスを定期的に評価している。

 ここであえて強調しておくが、自社の評価基準を適用するにしろ、外部のチェックシートを利用するにしろ、その情報が最新のアップデートに基づいているかに留意したい。クラウドの世界、特にAWSはイノベーションのスピードが非常に速く、数カ月前の情報がすでに陳腐化しているケースも少なくないからだ。アセスメントは最新情報を基準にする──このことをまずはしっかり頭に入れておいてほしい。

AWSをAWSたらしめる数多くの第三者認証の取得と維持

 可用性・コスト・セキュリティなど、クラウド移行アセスメントにおけるポイントはいくつかあるが、オンプレミスの利用者がもっとも気になる、というよりもイメージがつかみにくい部分がセキュリティだろう。前回触れた「責任共有モデル」についてはすでに把握済みだと思うが、もしまだであれば、前回とあわせ、AWSが公開している責任共有モデルについて書かれた内容(https://aws.amazon.com/jp/compliance/shared-responsibility-model/)に目を通しておくことを推奨する。

 責任共有モデルの解説を一読すればおわかりのように、AWSはセキュリティとコンプライアンスに関しては非常に高いプライオリティを置いている。AWSの技術革新を統括する、“Cloud Father”としても名高いヴァーナー・ボーガスCTOは「セキュリティはAWSにとってのファーストプライオリティ」と、ことあるごとに公の場で発言しているが、例えばAWSが取得している第三者認証の一覧(https://aws.amazon.com/jp/compliance/)を見れば、その言葉に真実味を感じられるだろう。

 ISO 27001やPCI DSSなどよく知られた国際的な基準はもちろんのこと、非常に厳しいセキュリティ監査で知られるSOC 2(Service Organization Controls 2: 米国公認会計士協会が定める内部統制の有効性に関する保証報告書)、さらには日本のマイナンバー法など各国のローカルルールにもきめ細かく対応している。断言してもいいが、AWSと同じレベルの認証を、自社のデータセンター上に構築することはコストや労力を考えてもまず不可能だろう。さらに特筆すべきは、AWSは常に、取得する認証を全リージョンに渡って更新し続けているという点だ。この第三者認証の取得/更新のスピードは他のクラウドベンダをも圧倒的に凌駕しており、追随を許さない。

AWSが「クラウドコンプライアンス」として公開している情報(出典:https://aws.amazon.com/jp/compliance/)2017年7月時点
拡大画像表示

 しかし、AWSがいかに高いレベルのセキュリティを維持していても、世の中にはさらにその上を行くセキュリティを望む顧客は多い。特にここ1、2年は、AWSが所有するPCI DSSのようなハイレベルなセキュリティ基準に適合したサービスの構築をシステムインテグレーターにも望む顧客が増える傾向にある。そうしたニーズに対応するため、cloudpackでは専用のセキュリティルームを設置している。物理回線は社内ネットワークから完全に隔離して運用されており、さらにSOC 2の運用に関しては物理インフラからAWSへのアクセスを専用線による完全な閉域網で構成している。

 なお、第三者認証に関しては稀に勘違いしているケースが散見されるので指摘しておくと、当然ながらAWSを利用するだけでこれらの第三者認証に準じたサービスを構築できるわけではない。責任共有モデルの考え方に従えば、ユーザがみずからの責任でもって担保すべき部分を実行することで、初めてこれらの透明性の高いサービスを受けられることを、あらためて確認しておきたい。

 余談ではあるが、ひと昔前、ちょうどパブリッククラウドが徐々に普及し、クラシックなITベンダーにとっても無視できない存在になり始めた2010年から2012年にかけて、これらのベンダーは「クラウドはオモチャ」「クラウドのセキュリティは信用ならない」と一斉にAWSに攻撃の矛先を向けていた。これに対しAWSは表立って反論するのではなく、かわりに第三者認証取得の実績をひとつひとつ、着実に積み上げていくという方針を採った。FISCやHIPPAといった非常に高いレベルの基準が要求される審査を着実に取得、準拠してきた姿勢に、そうした風評に対するAWSの無言の抵抗を見る思いがする。現在では「AWSクラウドのほうが(オンプレミスよりも)セキュリティは万全」とセキュリティ審査の厳しい金融機関からさえ言われるようになったが、それでもAWSはセキュリティへの追求を決してやめることはないだろう。

AWSクラウドへのロックインは起こりうるのか

 既存の環境とAWSの違いを考える上で、セキュリティとは別に、もうひとつの重要な、それでいてあまり丁寧に語られることのないキーワードに触れておきたい。

「AWSクラウドにロックインされたくない」

 筆者も何度か、AWSクラウドへの移行相談で、こうした顧客の不安をぶつけられることがある。そして非常に申し訳ないのだが、その言葉を聞くたびに非常に微妙な気持ちになってしまう。いったい、どういう状態に陥ってしまうことを“ロックインされた”と思うのだろうか、と。

 おそらく、このロックインへの恐怖心は顧客側が望むと望まざるにかかわらず、いったん導入したハードウェアもしくはソフトウェアを半永久的、かつ半強制的に更新し続けなければならない、というオンプレミス時代のリプレース(地獄)の経験がベースになっているのではないかと推察される。

 ハードウェアの価格もソフトウェアの年間のサブスクリプション料金も年々高くなるばかりなのに、それを拒否して別のシステムに移行することすらままならない、そんな顧客不在の状況がなぜ発生するのかというと、データやアプリケーションを動かせないからである。「仮にデータを別のシステムに移行できたとしても、システムをリプレースするよりもはるかに高額のコストがかかる」とベンダーは言う。そしてこのロックインに対するトラウマは、クラウド時代になってもまだ生きている。「IBMやOracleから動けなくなってしまったように、AWSクラウドからデータやアプリを動かせなくなることが怖い」と、そんなところではないかと筆者は見ている。

 だが、それはいまや過去の常識である。はっきり言えば、AWSクラウドに関しては既存のロックインという考え方を当てはめるのはもう意味がない。

 極端にいえば、例えばAWSが提供するマネージドサービスをいっさい使わず、Amazon EC2のインスタンス上にすべてのシステムを実装するのであれば、間違いなくロックインは避けられるだろう。またAWSから、例えばAzureに移行することも無理ではない。

 だがコトの本質はそこではない。AWSクラウドに限らず、ある特定の製品/サービスには競合他社の同等レベルの製品にはない特徴、つまり差異化要因となる機能が必ずある。その機能に惹かれて導入するとしたら、すなわちその製品だけが提供できる機能を使うのなら、それはその製品に“ロックインされた”という状態と同じである。その意味を理解せずに“AWSにロックインされることが怖い”というのは、“AWSが提供する新しいサービスを使うのが怖い”と言っているのと変わりない。その考え方自体がオンプレミスの亡霊にロックインされているのではないかとさえ思えてしまう。

 前回も触れたがAWSはあらゆるクラウドプラットフォームの中でも突出してイノベーティブな存在であり、絶え間ないイノベーションは同社のDNAに組み込まれている。したがって我々がロックインの心配をする前にAWSはあらゆるサービスを進化させてしまう。ロックインされようにも、その環境自体が変化していくので、OracleやIBMなどにロックインされていた状態になることはありえないのだ。むしろ顧客が心配すべきは、前回も強調したように、AWSの進化をキャッチアップしていく覚悟があるかどうか、である。

 もちろんマルチクラウドへの期待という傾向が強くなりつつあり、複数のクラウドへのデプロイを検討する企業が増えていることも事実だ。数年前と異なり、現在ではAWSクラウドに対抗しうる存在としてMicrosoft AzureやGoogle Cloud Platformが力を持ってきた。AWSだけにシェアが集中するのは“健全なクラウド市場の形成”という面で望ましくないという声も強く、実際、そうした意見は強い説得力を持つ。保険として複数のクラウドでデータ/アプリを扱えるようにしたいというニーズがあっても不思議ではない。だがマルチクラウドという選択は単にAWSクラウドに移行するよりも格段に難易度が上がる。過去の"ロックイン体験"を理由に選ぶべき選択肢ではないことだけは、クラウド専業ベンダーの一員としてあらためて強調しておきたい。

 

バックナンバー
検証!マイグレーション先としてのAWS一覧へ
関連記事

移行前のアセスメント ~ 既存データセンターとAWSのセキュリティレベルを比較する前回はAWSクラウドに移行する前段階として、オンプレミス環境からAWSクラウドへのマイグレーションが意味するところ─IT担当者が心しておかなければならないポイント─について、責任共有モデルを中心に解説を行った。当たり前ではあるが、AWSクラウドでシステムを運用するということは、データセンターでラックを1本借りるのとはまったく意味が異なる。そこで今回は、ITインフラとしてのAWSクラウドは既存のデータセンターと何が異なるのか、特にクラウドに移行する上でもっとも注目されるセキュリティについて、両者における違いを掘り下げてみたい。

PAGE TOP