クラウドは、ビジネスの進め方や、ソフトウェアとインフラの開発やデプロイ方法を変革しました。クラウドへの移行は、セキュリティ上どのようなメリットが得られるのでしょうか？また、クラウド特有の懸念事項とは何でしょうか？企業は、クラウド利用を安全に保つために何を為すべきでしょう？このサイバーセキュリティサウナのエピソード21では、ホストのJanne Kauhanen（ヤンネ・カウハネン）に、エフセキュアのLaura Kankaala（ローラー・カンカーラ）とAntti Vaha-Sipila（アンティ・ヴァハ・シピラ）が加わり、クラウドネイティブの意味や、なぜクラウドで侵害が発生するのかについて話を聞きました。
Janne：それではまず、クラウドとの関わりについて教えてください。
Laura：私とクラウドとの関りは長期に渡っています。ほとんどがAWSでしたが、クラウド上で開発案件に何件か携わりました。初めてAWSに出会って以来、インフラの構築方法等についての私の見方は大きく変わりました。そして、クライアントと多くの仕事をする中で、セキュリティ面での問題やクラウドに対する懸念を払しょくする手助けをしようと努めてきました。そのため、クラウドインフラに関しては数多くのアセスメントや監査を経験しています。
Antti：私の場合は、主にクラウドサービスを有料で利用する顧客としての立場になります。しかし、個人的にはソフトウェアのセキュリティプロセス、DevOpsなど、多くの作業を行っています。そして今では、モダンなクラウドサービスなしでは、ほとんど何もできないだろうと感じています。特にDevOpsにとっては必須だと思います。そして、私もクラウドにおけるセキュリティには大変興味を持っています。
先に進む前に、本質的にクラウドとは何かについて話し合いましょう。それについては誰もが話題にしていますが、ひとつの決まった定義はないようです。クラウドとは何かという問いに取り組む上で、建設的な方法があるでしょうか？
Laura：おそらく、クラウドをデータセンターモデルとを比較するのが最も簡単だと思います。従来型データセンターでは、常勤の担当者がいて彼らに「ファイアウォールの設定で、これとこれの変更を行ってください」と連絡する必要があります。あるいは、インフラを取り扱うチームを抱えている企業もあるでしょう。一方でクラウドを利用する場合、インフラチームがプロバイダー側に存在するため、ユーザー側ではDevOpsのスタッフを揃えたり、開発者を自社システムのインフラ担当にアサインすることができます。
Antti：その通りですね。それがクラウドを利用する主な理由だと思います。強く望まない限り、根底にあるインフラに触れる必要はありません。しかし、ほとんどのクラウドプロバイダーには、『責任共有モデル』と呼ばれるものがあります。そのため、プロバイダーはインフラのどの部分のセキュリティを担っているかが明確に示されており、残りの部分はユーザー側の担当領域になります。この責任分界点は、プロバイダーによって異っており、さまざまなレイヤー上に存在しています。
Laura：確かにそうですね。どのようなクラウドでも、『責任共有モデル』が大雑把だと、ユーザー側にとって問題となり、自分で安全性を確保する必要が生じます。しかし、触れることができないものはすべて、つまりデータセンターとハードウェアは、言うまでもなくユーザー側の問題ではありません。したがって、ユーザーはそれらに対しての責任を持つ必要はありません。
しかし、私たちはこれまでさまざまな種類のサービスモデルについて見聞きしてきました。IaaS, PaaS, SaaSがありますが、それらはクラウドなのでしょうか、それとも別のものでしょうか？
Antti：それはユーザーのニーズに依存しています。つまり、ソフトウェアだけの利用が必要な場合は、SaaSを利用することになります。しかし、ユーザーの観点からすると、SaaSが自社のデータセンターのオンプレミスで実行されていても、パブリッククラウドで実行されていても、実際には何の違いもありません。いずれにしても、同じ種類のソフトウェアを利用することができます。そのため、対象とするレイヤーによっては、自社のデータセンターの場合でも、クラウドのようなサービスを受けることができます。
Laura：そうです。また、アプリケーションの拡張性についても話すべき点は多くあります。今は『責任共有モデル』について話しているのですが、クラウドサービスを実際に構成しているものや、クラウドサービスそのものは非常にスケーラブルです。アプリケーションを実行することを考えてみましょう。ある時点まではそれほど能力を必要としていない場合でも、オンラインストアを開設することで運営のために今まで以上のサーバーの能力が必要になることがあります。この場合でも、クラウドならWebアプリケーションをクラッシュさせることなく、すぐにリソースをスケールアップすることができます。
Antti：まさにその通りです。したがって、単にソフトウェアをサービスとして使用したいだけで、サービスの負荷が非常に安定している場合は、サーバーの使用を止める場合を除いて、クラウドからはまったくメリットを得られない可能性があります。ただし、弾力性を確保し、ワークロードを拡大や縮小したい場合は話が異なります。自社でハードウェアを所有しているのでしたら、ある時点でサーバーが不足するので、ラックにサーバーを増設する作業が必要になります。一方で、通常パブリッククラウドプロバイダーのハードウェアが枯渇することはありません。
それではクラウドプロバイダーとデータセンターの運用で、セキュリティに関して明白な違いは何でしょうか？
Laura：それがクラウドにおける『責任共有モデル』の存在だと思います。開発者がインフラをより詳細に制御できるので、より多くのセキュリティ制御機能を実装できます。また、従来型のデータセンターの場合は、交わしている契約によります。
その制御とは具体的にどのような内容ですか？
Laura：はい、私が話している制御とは、さらに多くのセキュリティ機能を実装できるということです。多くのクラウドサービスは、ユーザーがコードをビルドすることで、セキュリティ要件やコンプライアンス要件を環境に適用するサービスを提供しています。これにより、コードをデプロイした後は、単なるアドオンではなく、セキュリティ機能の一部として環境を監視することができます。つまり、ライフサイクル全体の不可欠な部分になります。
Antti：それに加えて、自動的にデプロイできる場合は、人員を投入する必要がほとんどなくなります。さまざまなコンソールでクリックしたり、CLI（コマンドラインインターフェース）で作業しなくてもよいので安全性が一層高まります。したがって、デプロイメントをロックダウンすることができます。
Laura：はい、おっしゃる通りです。インターネットに多くの情報をさらさなくても済みます。したがって、何者かがSSHでサーバーに接続することもなくなります。
Antti：このサービスを提供できるのは、必ずしもパブリッククラウドだけではないことは理解しておくべきです。つまり、このロックダウンデプロイメントとセキュリティの自動処理は、オンプレミスクラウドでもほぼ同様に実行できます。これは、サーバーが自社またはパブリッククラウドプロバイダーによって所有されているかどうかに関係なく、同じソフトウェアスタックとして実行可能です。
お二人は、クラウドプロバイダーとその顧客の間の共有責任について話されました。では、顧客のデータを安全に保つための、それぞれの責任とは何でしょうか？
Antti：端的に言うと、クラウドプロバイダーはサービスに責任があり、顧客はサービスの構成に責任があります。これはすべてのレイヤーに当てはまります。たとえば、インフラの場合は、クラウドプロバイダーが担うのはローネットワークです。そして顧客はポートを開くことを含め、ネットワークの構成をチェックする必要があります。
つまり、これは古くからあるサービスとしてのインフラモデルのようなもので、要するにベアメタルですね。取り扱いには注意したいです。
Antti：そうです。そして上位レイヤーについては、たとえば、マネージドKubernetesなどのサービスとしてプラットフォームを利用している場合は、安全なKubernetesが望まれますが、その上にどのようにワークロードをデプロイするかはユーザー側の問題になります。
なるほど。S3バケットをオープンにしたままにするかはユーザー次第と言うことですね。
Antti：はい。Kubernetes上で脆弱なアプリケーションを実行することを決断した場合は、プロバイダーであるKubernetesは何も助けてはくれません。
Laura：そうですね。したがって明確な特質としては、しっかりとテストして自分のコードが適正であること、そして攻撃対象領域を過度に露出していないことを把握しない限り、クラウドや従来型のデータセンターにおいては、本質的に安全なものは何もないということです。たとえば、S3バケットがインターネットに開かれているとします。それをテストして、構築する方法に注意を払う必要がありますが、それはユーザー次第です。
クラウド自体は安全とは言い切れませんが、まったく安全ではないとも言えませんね。
Antti：ええ、まさにそうです。ですから、特別な手段を講じない限り、考えられるものの中では一番安全だと思います。つまり、大手のクラウドプロバイダーは、非常に厳しいセキュリティを要求するクライアントを抱えています。国の認可を必要とするような要件もあります。
そして管理者は一日中このような要件の対応に追われています。
Antti：その通りです。そして今、プロバイダーはユーザーが個人だからというだけでセキュリティを疎かにすることはありません。したがって、ユーザーは真にセキュリティを重視する顧客のために実装されたすべての機能から恩恵を受けることができるのです。
Laura：そうですね。そして指摘しておきたいことは、多くのプロバイダー、たとえばAWS、Azureなど、主要なクラウドプロバイダーは、さまざまなコンプライアンス要件を満たす必要があるということです。したがって、少なくとも誰かが入念に調べて、問題がないこと、安全であることを確認しているはずです。
Antti：はい。しかしその一方で、入念に調べるといっても限界があります。したがって、極めて難易度の高いセキュリティニーズに対しては、監査会社によって書かれたホワイトペーパーやPDFの束を読むしかありません。
Laura：ええ、それは良い指摘です。
Antti：そして、ユーザーはそれを信用するしかありません。自分で内部を見ることはできません。データセンターを訪ねたところで内部を知ることはできません。
Laura：はい。たとえるならば、ここにマシンがあり、電源がオンになります。
Antti：すると、ライトが点滅し、すべてが安全に保たれるということです。
これまでの話で多少触れましたが、クラウドに移行する場合、具体的にはセキュリティ上でどのようなメリットがありますか？
Laura：クラウドに移行する場合と、ソフトウェアをクラウドにデプロイする場合は、いくつかのメリットがあると思います。たとえば、コンプライアンスを監視し、アカウント上の構成のセキュリティステータスを監視するサービスを利用することができます。また、AWSには、AWSアカウントの構成方法を監視するconfigがあります。ロギングや、意図したとおりに機能しているかどうかを確認するためのオプションが豊富にあります。これは素晴らしいことだと思います。特に、自社の環境で起こっていることはしっかりと認識する必要があり、たとえば、個人を特定できるデータなど、非常に機密性の高いデータを処理している場合には極めて有効です。この従来型のデータセンターモデルでは実装が困難だった監査証跡（ログ）を提供するための多くのオプションがあります。データセンターの環境では、可視性を得るには新しい機器かアプリケーションを購入しなければなりません。
それでは、クラウドに伴う懸念、リスク、脅威については如何ですか？
Antti：クラウドサービスを利用している場合、構成を間違えるとリスクにつながります。そのため、サービスのレイアウト方法と、適用する必要のある構成オプションを熟知する必要があります。
これはクラウドに限ったことではありませんね。普遍的な問題でしょう。
Antti：はい、確かにそうです。しかしクラウドは、今までにないようなツールを提供しています。パブリッククラウドプロバイダーから新たに提供されるサービスの種類を見ると、それらを確実に把握するのはフルタイムジョブになるでしょう。さらに、これらすべてのセキュリティ構成に精通するには、おそらく2、3人が専任で対応することになります。
したがって、これらの素晴らしいツールが並んでいるのを見ているだけで、それらを賢く使って何かをする準備を整える前に、すぐ使いたいという誘惑に駆られるでしょうね。
Antti：はい。もし輝く鎚矛が地面に落ちていたら、絶対に拾いたくなりますよね。
仮に、ある会社がクラウドプロバイダーを1社選択したとしましょう。Lauraは、データのセキュリティをさらに評価するために侵入テストを行うことを勧めていましたが、それはどのように実行されるのですか？あなたが他人のコンピュータに侵入テストを試みていると仮定して、その環境が他の顧客とも共有されている場合はどうでしょうか？
Laura：はい。つまり、AWSやAzure自体をテストするのではなく、自社のアプリケーションをテストする場合ですね。クラウドプロバイダーに関しては、さまざまなプロセスがあります。AWSの場合は、「自社のアプリケーションへの侵入テストを実施する」という申請を出す必要があるので、プロバイダーはユーザーがテストを実施することを知ることができます。テストする必要があるのは、従来のソフトウェアでも同様で、それがどれほど安全であるかを知るべきです。そして、自社のサービスをどこでホスティングしているかに関係なく、この作業から逃れることはできません。
基本的にこれは責任共有の分担に帰着します。自分が責任を担っている部分に対して侵入テストしても、クラウドプロバイダーの責任部分には触れることができません。あなたが話されたように、信用するしかないのですね。
Antti：はい。監査会社から提供されたPDFを読んで、それを信頼するかは自分で判断するのです。
セキュリティの責任をクラウドプロバイダーと共有することへの影響について、企業はどの程度気付いているのでしょうか。
Antti：まあ、多くの企業は積極的に気付こうとはしていないようです。似たようなことは、ソフトウェア開発でも起こっています。サードパーティに委託しているケースが多いからです。彼らは基本的に、自社製品に組み込んでいるすべてのソフトウェアのうたい文句に書いていることを盲目的に信用しています。
それはオープンソースですから、誰かが確認したことはあると思います。
Antti：はい。ほとんどの場合、確認している人がいるはずです。しかし、その後誰かがソースコードを変更したかどうかは別問題です。
またはエクスプロイトを書き込んだかもしれませんね。
Laura：誰かがプルリクエストしたにもかかわらず、誰もマージしないこともあります。（笑）
Antti：なるほど。しかし、所謂「クラウドネイティブ」の企業や、最初からクラウドサービスを使っている企業のほとんどは、共有責任について非常によく認識しているという印象があります。そして、パブリッククラウドプロバイダーは、共有責任に関して素晴らしい教育を提供しています。ですから、もはやベールに包まれているような状況ではないと思います。
したがって、クラウドに移行中で「クラウドに置いたので、誰かが面倒を見てくれているから心配する必要はない。」とやみくもに信じているような従来型の企業はほとんど見かけなくなりました。
Antti：クラウドに飛びついた多くの企業の認識は、まさに正反対です。彼らは自社で制御することができなくなったことを危惧しています。
Laura：人々は、まだ少しためらっているのです。「自社のデータを預かっているのは大手企業なので、全幅の信頼を置くべきでしょう。」という考え方も良くありません。AWSにデータを保存するときもユーザー側で暗号化することができ、暗号化キーも所有できるのですから。したがって、「自分のデータは自分でしっかりと管理している。」という心の安らぎを得ることもできるでしょう。もちろんそれは常に信頼に帰着します。そのため、クラウドでも、従来型のデータセンターであっても、使用しているプロバイダーを信頼することも大切です。
しかし、その信頼には根拠があるのでしょうか？クラウドでセキュリティ侵害が発生する最も一般的な理由は何でしょうか？そして、通常その問題に対する責任は、クラウドプロバイダーと顧客のどちらにあるのでしょうか？
Laura：私はこれまでに、AWSやAzureのデータセンターへの侵害について聞いたことがありません。実際にそのハードウェアに侵入してデータを搾取するような侵害のことです。したがって、もしそのような侵害が発生するとしたら、クラウドプロバイダーの人為的ミスか、構成ミスによるものだと思います。また、アプリケーションの構築方法や、アプリケーションに含まれる一般的な脆弱性も考えられます。このケースでは、そのようなソフトウェアを構築した会社の過失だと言えます。
クラウドプロバイダーによる多くのミスというのは見たことがありません。
Antti：しかし、彼らは侵害があったとしても公表するでしょうか？
はたして侵害の事実を隠蔽することはできるのでしょうか？たとえば、流行中のウイルスによりクラウドプラットフォームのセキュリティに問題が生じた場合、誰かに気付かれるのではないでしょうか？
Antti：これは、情報セキュリティのリスク分析において、私たちが抱えている問題のひとつです。たとえば、ハッキングされる可能性がどの程度あるかなどの統計値などを分析するだけのデータは十分にありません。企業はそのような情報は積極的に開示しません。開示を強制するような規制はありますが、すべての情報を誰でも見られるようにはなっていません。当局に報告するだけでしょう。
クラウドサービスは、ソフトウェア開発とインフラのデプロイ方法をどのように変えましたか？
Antti：はい。それは重要で、とても良い質問ですね。驚くほどの影響をもたらしたと思います。私たちが耳にするトレンドやバズワードとしての「クラウドネイティブ」、「クラウドネイティブアーキテクチャ」、「クラウドネイティブコンピューティング」などは、クラウドのさまざまな局面を活用することで、開発チームの運用も容易にします。
Laura：はい、クラウドサービスは人々の役割も変えます。たとえば、sysadminはサーバーに座って構成を行うだけですから、このような仕事はある時点で消え去るでしょう。コードとしてのインフラストラクチャ（Infrastructure as Code）を運用すると、コードからインフラをデプロイすることが可能になります。
Antti：具体的に言うと、クラウドインフラの見え方を記述しているテキストファイルがあり、一部ロボットによる自動化でテキストファイルを取得して、実際の見え方を確認できます。 また、変更がある場合は、ユーザーに代わってその変更が実装できます。
つまり、あなたが言いたいことは、見え方を記述すると、実際にそのようになるということですね。
Antti：その通りです。
まるで魔法ですね。
Laura：何をデプロイしているか、そして、何が起こっているのかを正確に把握できるのが素晴らしい点だと思います。それがクラウドの美しさであり、自動化の美しさです。それだけでなく、その周りに独自のテスト環境を構築でき、自分のソフトウェアの機能を実際にテストすることができます。また、さらに一歩踏み出して、セキュリティテストを適用することもできます。とても美しいと思います。
Antti：そして、クラウド、つまりサービスとしてのプラットフォーム（Platform as a Service）の中で、さらに多くのシステム間接続（Plumbing）ができるようになりました。所謂サービスメッシュですが、たとえば、実際には非常に入り組んだネットワークレイヤー構成をファイルに記述して適用するだけで良いのです。これを手作業で維持するのは悪夢のようなものです。
あなたが話したように、クラウドネイティブはよく耳にする流行語になりました。今回の会話の目的から、私たちがクラウドと言っているときは、最初からクラウドネイティブになるように開発されたアプリケーションについて話しています。それがクラウドネイティブの意味することでしょうか？
Antti：クラウドネイティブの意味に関して、私は少なくとも3つの異なる定義を目にしました。凖公式的な定義です。意味合いとしては、実行したいアプリケーションやワークロードがあり、それらの実行に必要なすべての依存関係と共にコンテナと呼ばれるボックスにパッケージ化でき、それらを実行するある種の統合管理システムを持っています。これが典型的なサービスとしてのプラットフォームです。そして、すでにこの段階で多くのセキュリティ上のメリットが得られます。アプリケーションがどのようにレイアウトされているか実際のアーキテクチャに踏み込む必要はありません。
それでは、具体的にどのようなメリットがありますか？このようなアプローチを取る意味は何ですか？
Laura：ひとつには、自社のサービスが巨大なシステムを必要としていない場合にメリットがあります。たとえば、マイクロサービスのように、管理しやすい小さなサービスを構築できます。それらを簡単にデプロイしたり、ニーズに応じて簡単に拡張したり縮小したりできるようになります。したがって、オンラインストアに突然多くの訪問者が押し寄せた場合は、実行中のコンテナの数を増やすだけで、すべての顧客を処理できるようになります。過負荷でストアを閉める必要はなくなります。つまり、少なくとも可用性に対するメリットがあります。たとえばコンテナについて話すと、コンテナを適切に実行していて、デプロイに使用するイメージをしっかり制御している場合は、これらのサービスもまた分離できるため、非常に安全なソリューションを構築できると思います。すべてのサービスを同一のサーバー上で実行する必要はありません。したがって、攻撃者がこれらのサービスのひとつに脆弱性を発見し、コードを実行したり、何らかの方法で悪用した場合、影響はそのサービスとコンテナだけに限定されます。
Antti：マイクロサービスアーキテクチャは、通常クラウドネイティブと併せて語られるビルディングブロックのひとつです。そして、データ侵害を回避するうえで、これは非常に興味深い手法と言えます。すべてのユーザーは、明確に定義されたAPIを要求するでしょう。そして、堅牢で十分にテストされたAPIを望むことでしょう。また、各マイクロサービスはそれ自身のデータも所有していますので、誰かがそのデータをダンプするために使用するようなデータベースへのバックドアアクセスを提供することはありません。したがって、攻撃者はAPIを介してアクセスするしかありません。このようなマイクロサービスのチェーンがあり、ひとつのサービスが別のサービスを呼び出す場合、それらの間のネットワーク接続をロックダウンすると、かなり堅牢な基本アーキテクチャができあがります。これは重要なポイントです。
これらすべてのマイクロサービス間の動的Webについては如何ですか？作成する動的なエンティティは、常に動いているホグワーツの階段のようなものです。そうすると、何が起こっているのか、どこに行くのかなどを攻撃者が理解することが難しくなりませんか？
Laura：コンテナを実行していて、アプリケーションがコンテナ内にある場合、コンテナのライフサイクルはそれほど長くないでしょう。したがって、攻撃者コンテナを使用することすらもできない場合もあります。たとえば、AWS LambdaやAzureを使用するかもしれません。Azure関数を使用してAPIとして動作させるか、バックエンドで呼び出しを行うサーバーレス関数もあります。したがって、サーバーレス関数がない場合には悪用されることはそれほど多くありません。長期間存続することを指定しない限り、関数やLambdaを呼び出している時間だけ存続します。結局、そこに攻撃をかけることはあまりありません。
Antti：すると、少なくとも攻撃は直ちに行う必要がありますね。
Laura：はい、そうです。
Antti：つまり、サーバーはすぐに消えてしまうので、誰かのサーバーに家を建てるようなことはできないのです。しかし、攻撃側も従来のSQLインジェクションのように多くのことを行う必要もないのです。もし攻撃に対して脆弱ならば、一種のエフェメラルノードが有っても役には立ちません。
エフェメラルノードをスピンアップするたびに、脆弱性が現れるでしょう。
Antti：まさにその通りです。そして、すぐに悪用されるのです。
間違いないですね。
Laura：私は個人的にLambdaに関して研究を行ってきました。もちろん、脆弱なコードをLambdaとして実行している場合は、当然のことながら、それを悪用する方法があります。少なくとも短時間で永続性を獲得する方法があるのと同じことです。しかし、ほとんどの場合、これはまだ仮説に過ぎません。そして、Lambdaまたは関数として実行するコードの安全性を評価するとしたら、極めて安全だと思います。
しかし、今では、開発者がこれらのクラウドネイティブなもので継続的インテグレーションを実行しているので、セキュリティ担当者と開発者の間のギャップがますます狭くなっているのではありませんか？
Antti：まあ、そうだと思います。ある種の操作を実行できるようになった開発者は、ある種のセキュリティ操作も実行できるようになるということです。しかし、繰り返しになりますが、創造的な攻撃者が防御側を狙っているのなら、防御側も創造的になる必要があります。また、堅牢なサービスを構築することもできますが、さまざまな種類のリスクを予測するためには、セキュリティのバックグラウンドが役に立ちます。創造的なリスク評価を行うことができるためです。しかし、それを開発者ができない理由はありません。ですから、いずれセキュリティ作業は、開発者のデスクワークへと移行することになると予想されます。
Laura：なるほど。開発者にとっても、自分の開発の安全性が良く分かるようになるので、とても良いことだと思います。彼らはコードの内側も外側もよく知っています。したがって、セキュリティ担当者と開発者の役割が近づくと、アプリケーションの安全性がさらに高まります。なぜなら開発者は「この脆弱性やこの古いNPMモジュールを使用することの意味合いはこういうことか」などのように完全な理解を得ることができるからです。
これまでセキュリティ部門の背後に隠れたり、セキュリティを外部委託することができた開発者は、この先はもはやそうすることができなくなり、自分自身でセキュリティの考え方を十分に取り入れる必要がありますね。
Antti：別の見方をすれば、セキュリティ部門は開発者にセキュリティを実行する権限を与える必要があるかもしれません。私の経験では、ほとんどのエンジニア、ほとんどの開発者は実際にセキュリティを適切に実行したいと考えています。彼らはセキュリティを実現したいのですが、それを行うには時間が必要です。しかし、その時間と権限は外部の委託先に奪われてきました。
Laura：はい。そして、開発者は未だにコーディングを行う必要があり、ソフトウェア開発を行う必要がありますが、セキュリティ機能を実装するための余分な時間も与えられていません。
クラウドサービスを利用している企業に対して、セキュリティに関してどのようなアドバイスをしますか？
Laura：そのままお使いくださいと言います。（笑い）つまり、クラウドを使用し続けることをお勧めします。特にスケーラブルなアーキテクチャが必要で、俊敏性を求めているのでしたら、コンプライアンス上の問題などがない限り、使用しない理由はないと思います。サービスを通じて、あるいはサービスとしてのインフラストラクチャを通じて、クラウドにセキュリティを適用する方法は数多くあります。ですから、それが未来だと思います。それは、万人とっての未来でもあります。
Antti：そして、どこかのサーバーで実行されるソフトウェアを開発する会社で（違う種類のソフトウェアも数多くあります）新しいプロジェクトを始めるなら、理論的にパブリッククラウドにデプロイできるように設計してください。別の選択肢もあります。お望みでしたら、これらすべてをインハウスで実行することもできます。
Laura：ええ、同じ自動化ツールを使用することもできます。
Antti：そうですね。
それは理にかなっていると思います。今回は、ご参加いただきありがとうございました。
Laura：ありがとうございました。
Antti：ありがとうございました。とても楽しかったです。
カテゴリ