英国の国防省（Ministry of Defence）より、「More secure in the public cloud（パブリッククラウドで、よりセキュアになる）」と題した公式ブログが公開されました。ブログ中、AWSにも具体的な言及があり、クラウド、特に「パブリッククラウド」と明示したかたちで、そのメリットが説かれています。
英国国防省の発表したブログ
（それでは以下、英文にて発表されたブログ”More secure in the public cloud“の全文を、アマゾンウェブサービスジャパン株式会社 パブリックセクター 統括本部長補佐（公共調達渉外担当）の小木郁夫の試訳にてお届けします：）
英国 国防デジタルサービス (Defence Digital Service* ; DDS) の責任者［Head of the DDS］である Rich Crowther *氏は、──国防省の所管する防衛分野であっても──、「OFFICIAL」に分類されたワークロードの安全性の確保に関しては、オンプレミスよりもパブリッククラウドの方がより適切に実施できると考えている理由について、次のように説明しています（＊訳注：過去にはより複雑な階梯構造を持っていた英国政府のdata classification は、OFFICIAL / SECRET / TOP SECRETの３階層に整理されています。また、文中の「*」の印は、訳出を担当した小木の判断でハイパーリンクを貼った箇所となります。印が無い箇所のハイパーリンクは、原文のリンクを踏襲しています。）。
英国 国防省では、「OFFICIAL」に分類された情報の取り扱いについて、パブリッククラウドの積極的な活用を開始しています。英国政府のデータ・クラシフィケーション・ポリシーで規定されているように 、この「OFFICIAL」という分類レベルには、高度な脅威プロファイルには該当しない日常的な業務およびサービスが含まれます。しかし直感的に、「他の組織や個人と共有するクラウドサービスが、軍事基地にあるデータセンターのそれと同等に安全だとは考えられない」と思う方もいることでしょう。 数年前に私自身（＝Rich Crowther 氏）も、「OFFICIAL」レベルのワークロードをホストする上で”クラウドはオンプレミスのデータセンターと「まったく同等に」安全性を確保できる”と述べたことがありますが、今日であれば私は次のように言うでしょう： ほとんどの状況でクラウドはオンプレミスと比較してより高い安全性を確保できる、と。（＊訳注：太字強調は原文を反映したもの）
以下は、私がそう信じる 3 つの主な理由です。
#１: セキュリティパッチをより早く適用できる
率直に言って、公的機関または民間企業であるかにかかわらず、多くの法人組織が技術的なインフラストラクチャを最新の状態に維持するために苦労しています。自社・自組織による運用であっても、サプライヤへのアウトソーシングであっても、オンプレミスのインフラストラクチャを最新の状態に維持することはとても困難です。オンプレミス環境で単一のウェブサイトを基盤とする技術構成を例として考えてみましょう: これほどシンプルな例であっても、低レイヤーのハードウェア、オペレーティングシステム、ウェブサーバーソフトウェア、そしてウェブアプリケーションなどを動作させるハードウェア、ファームウェア、基本入出力システム (BIOS = Basic Input / Output System) が含まれます。システムの稼働開始時にこれらのレイヤーすべてに漏れなくパッチを適用したとしても、継続してパッチが適用され続けるということはその後、あるうるのでしょうか? ハードウェア用の新しいバージョンの BIOS やファームウェアのリリースに、注意し続けることができるのでしょうか? おそらく読者の皆さんは注意しておられるでしょうが、私の経験では、大半の人はリリースに気付くことすらありません。
では、パッチの適用は、そもそもなぜ重要なのでしょうか? セキュリティについて断定口調で話すのは気が進みませんが、これは例外としましょう: パッチの適用が遅れた場合、そのシステムは安全ではありません。 退屈しているいたずら好きなティーンエイジャーから特定の国家まで、すべての「脅威をもたらす輩」、つまりハッカーは、パッチが適用されていないシステムを攻撃する能力を持っています。オペレーティングシステム内のコンポーネント用に新しくリリースされたセキュリティパッチがリバースエンジニアリングされ、脆弱性が特定され、これを攻撃する手段が開発されるまでに、わずか数日しかかからないこともあります。こうした攻撃手段は、「脅威をもたらす輩」によって秘匿され続けることもあれば、逆に、時には世界中で人気のあるハッキングツールに追加され、ご丁寧にもその攻撃手法がYouTube のチュートリアルで説明されてしまうこともあります。パッチを適用するまでの時間が数日程度である組織なら、多くの場合、問題はないでしょう。ところが、パッチを適用するまでに数週間または数か月かかる組織は、おそらく無防備すぎるでしょう。
事例: ”投機的実行” (別名 ”Spectre［＝幽霊］”)
オンプレミス環境でのパッチ適用の速度と、主要なパブリッククラウドベンダーが 2018 年初頭の投機的実行=Spectre*（以下「スペクター」）の脆弱性に対応した速度を比較してみましょう（＊訳注：マイクロプロセッサに存在するハードウェアレベルの脆弱性であり、正当な権限のないプロセスが保護されたメモリの領域にアクセスすることが可能になる。 命名は、投機的実行 (speculative execution) に由来しており、修復が困難なことから、相当のあいだ幽霊のように我々に取り憑くだろうと説明されている – Wikipediaより）。スペクターは、プロセッサのハードウェアレベルに存在するまったく新しいクラスの脆弱性という点で、注目に値しました。この脆弱性は 2018 年 1 月 3 日に公開されました。一部の主要なクラウドプロバイダーは事前に［顧客に対してその脅威を］通知していましたが、おそらく期待されたよりも少なかったでしょう。ここ国防省では、世界のほとんどの地域と同様に、このニュースが報じられたときに初めてこれらの脆弱性について知りました。
比較のため、アマゾン ウェブ サービス (AWS) *の対応を見てみましょう。同社はおそらくこの脆弱性への対処に関してかなり迅速なスタートを切っており、脆弱性が公開されたその日に Amazon Linux 用の更新された仮想マシンイメージを利用可能にしました*。つまり、お客様が認識していれば、すぐに仮想マシン (AWS 用語*の「EC2 インスタンス」*) を更新できたのです。翌日までに、パッチを自分で適用したかどうかに関係なく、すべてのお客様に対して、すべての EC2 インスタンスで脆弱性がグローバルに悪用されないように対応が終えられました。AWS の主力のひとつ、サーバーレスコンピューティング機能*である AWS Lambda* についても同じことが言えます。機能が安全な環境で実行されていることを確認するために、［顧客側では追加で］何もする必要はありませんでした。翌日、すべてのデータベースインスタンス*にもパッチが適用されました。このような基盤環境レベルの変更を高い信頼性で素早くロールアウトするには、[過去それらに要していた時間と比較し] 開発・テスト・監視がどれだけ必要であったかを考えると、これは驚くべき速さです。その後の数か月間、チップメーカーが、コンピューター上 (BIOS の下であっても) で実行される最低レベルのソフトウェアに適用するべきマイクロコードの更新を公開したため、さらにパッチを適用する必要があり生じました。AWS*または同水準の［パブリッククラウドに基づく］サービスを使用していた場合、これらはすべて、何も対処する必要はなく処理されました。
私の経験では、英国では、ハイパースケールのクラウドプロバイダー*と同じくらい迅速にセキュリティパッチを適用できるレベルのエンジニアリング規模と専門知識を備えている組織は、ほとんどありません。ところが、スタックのすべてのレベルで迅速にパッチを適用しないと、システムは攻撃されやすくなるのです。
このことから何が分かるでしょうか? クラウドサービスでは、仮想マシンだけに限定せず、より抽象度の高い「関数（Functions）」や「コンテナ」)を利用することをお勧めします。これは、システムへに対するパッチ適用を早め、攻撃に対する脆弱性が存在する時間を短縮することを意味します。
#２: 大規模なセキュリティコントロールのデプロイが容易である
私（＝Head of the DDSである Rich Crowther 氏）がパブリッククラウドのセキュリティを支持する 2 つ目の理由は、巨大な施設全体に対してもセキュリティ・コントロールを瞬時にデプロイするのが簡単であるからです。システムのすべてのエンドポイントにネットワーク監視タップをすぐに設ける必要がありますか?── 大丈夫です。インターネットに公開されているすべてのサーバーが、コンソールへのアクセスを世界中に公開していないことを確認する必要がありますか? ──とても簡単です。管理者のすべてのアクセスを変更できないログに記録し、無期限で保存する必要がありますか?── 了解しました。・・・こうした作業はすべてオンプレミス環境でも実行できますが、数時間、数日、いや数週間以上かかることもあります。これに対して、瞬時にクラウドで達成するのはとても簡単なことです。
ただし、注意してください: セキュリティコントロールを大規模にデプロイできることの反面として、間違いも非常に迅速に拡散されてしまうことになります。 したがって、テンプレート*や構成コードを十分に確認することが重要です。そして、「職務の分離（separation of duties）」*が組み込まれた優れた設計のワークフローを実装することにより、以下の３つめのメリットが享受可能になります：
#３: より簡単にすべてを承認し、「職務の分離」を実装できる
主要なクラウドサービスでは ID管理 と認可（authorisation）*に重点が置かれていることは、そこにインフラストラクチャをデプロイしようと試みた人なら誰でも知っています。ほとんどすべてのアクションを承認し、行われた承認決定の監査証跡を保持することが可能です。承認の決定ロジックでは、ユーザーが誰であるか、どこから接続しているかだけでなく、アクセスしようとしているリソースにメタデータを介して特定の属性が関連付けられているかどうかなど、さまざまなパラメータを組み込むことができます。──お分かりいただけたでしょうか。誰が何にアクセスできるか、そもそもアクセスしようと試みたのかを、細かくコントロールできるのです。
ただし、こうした基礎レベルの承認管理は当然のことと考えています。アーキテクチャによるコントロールがはるかに多くのことを達成可能にしたことが、クラウドが承認管理に関してより根本的な進歩を遂げるのに役立ちました。まず、必要になる直前にだけアクセスが許可される、いわば「ジャストインタイム」管理のような仕組みがあり、 Microsoftのような会社はAzureで easy な set upを可能にします。加えて、微妙な違いではありながら同様に重要なのは、壊滅的な侵害を引き起こすに足る、複数のユーザーアカウントのコントロール侵害が可能なシステムを、これまでよりも簡単に設計できてしまうということ──です。こうした事態を未然に防ぐための「職務の分離」によるコントロールは、旧来型のオンプレミス環境であったとしても技術的には実現可能でしたが、セットアップが難しく、運用には多大な費用がかかりました。現在は、パブリッククラウドを使用して、特権アクセスを取得したり、リスクを伴う操作を実行したりする場合には複数の人が連携しなければならないシステムを簡単に構築できます。これは大きな前進であり、防衛分野においてもこの種のコントロールをより広く活用できることを意味します。
「But what about…?(でも、こんな場合には？)」
読者のなかには、こう思う方もいるかもしれません──「防衛やその他の公共部門の組織なら実施できるだろうが、営利団体/民間企業ではとても実施できない”特別なコントロール”があるという傾向を、あなたは無視しているんじゃないか」──と。たしかに、たとえば明白な例として、高度な物理的セキュリティや人的セキュリティの身元調査を、防衛部門では実施することもあります。でも、誤解しないでください。これらは、軍事作戦を実行するために利用される高度に機密性の高い情報を扱うシステムなど、一部のシステムを保護するうえで非常に重要なコントロールなのです。とはいえ、ハイパースケールのクラウドプロバイダーが物理的および人的セキュリティにこれまで投入してきたオペレーションのレベルを、過小評価しないでください。たとえば、（ハイパースケール・クラウドプロバイダー各社の）規模が大きいゆえに実装可能となる「職務の分離」によるコントロールにおいては、多くの場合、壊れたディスクを交換するためにデータセンターにアクセスできるスタッフは、特定の顧客からのデータが含まれているディスクを特定できるスタッフとは、異なる人物であることを意味します。これは、オンプレミスで運用されるほとんどの「OFFICIAL」に分類されるワークロードでは、決して実現できない強力なコントロールのひとつです。
ただし、より機密性の高い (通常はSECRETおよびTOP SECRETに分類される) 情報を扱うシステムの周囲には、非常に厳格な人員および物理的コントロールを必要とするシステムが必ず存在します（＊AWS訳注：SECRET / TOP SECRETは、前掲の英国政府のデータ・クラシフィケーション・ポリシー*で規定されている３類型のうち、残りの２類型です）。こうしたシステムでは、防御態勢の一部として適切にパッチが適用されていることが重要であり、パッチを適用する作業を組織自身で、または緊密に連携する業界パートナーと共に行う必要があります。ただし、「OFFICIAL」分類相当のワークロードに対してはパブリッククラウドサービスをさらに活用し、つまりはクラウドプロバイダー［の提供する個々のサービス］に従来は手間がかかっていた作業のほとんどを任せることで、より高度な機密を扱うシステムへのパッチ適用の速度を上げるためのエンジニアリング的取り組みに、さらに戦略資源を［国防省は］集中することができます。
防衛分野へのパブリッククラウド適用
国防省のデジタルやテクノロジーの分野において、Defence Digital*の 「MODCloud*」 チームの同僚は、誰でも簡単に利用できる主要なハイパースケールのクラウドサービスのいくつかを提供しています。MODCloud チームは、さまざまな「ガードレール」と「テンプレート」を提供して、すべてのアカウントで一貫したセキュリティコントロールを確実に実施できるようにしています。（英国 国防省の）私のチームはこうしたサービスを使用してさまざまなデータセットを正常に処理し、上記の［ブログで紹介してきた］すべての手法も使用しています。高レベルの抽象化サービスを使用して、パッチ適用が主にクラウドプロバイダーによって行われるようにし、すべてのインフラストラクチャをコードからデプロイし、主要な設計要件として「職務の分離」を実現するようにシステムを設計しています。これらはすべて、Cyber Defence & Riskチームに所属する仲間や MODCloud チームとの緊密な連携で行っています。私たちは全員が一緒に学び、継続的に改善を行っています。
この投稿が、国防省の他のチームが「OFFICIAL」に分類されるワークロード (”SENSITIVE caveat*“という取り扱い条件が付された情報も含めて) に MODCloud を通じて提供されるパブリッククラウドサービスを採用することを促進し、”機密扱いの情報を取り扱うシステムの改善” 及び “セキュリティ保護”に対して、集団安全保障業務とエンジニアリングのリソースをさらに集中させていく目標達成に役立つことを願っています。
最後に、このブログの締め括りとして、NCSC (英国 The National Cyber Security Centre*)は優れたクラウドサービスのセキュリティ上の利点に関する詳細なホワイトペーパーを公開しています。このホワイトペーパーでは、さらに必要な場合に、クラウドがセキュリティを向上させる可能性についてさらに多くの議論を示しています。