なぜなら、1 つの腐ったリンゴが、その山全体を腐らせる必要はないからです。
データセンターはデジタルトランスフォーメーションによって変化を遂げています。 クラウド、コンテナ、そして壊滅的な侵害により、早急に変化に重点を置く必要が生じています。 焦点の多くは、従来のデプロイメント スケジュールに大混乱をもたらす可能性のある継続的デリバリーとアプリごとのデプロイメントの影響にあります。 伝統的なスケジュールと現代のスケジュールを調整しようとすると、ヨセフスのような数え上げの問題を解くことに慣れている数学者でさえ、手を上げてその試みを断念することになるだろう。
継続的デプロイメントに関して、アプリケーション サービスとインフラストラクチャにアプリごとのアーキテクチャ アプローチを実装することのメリットだけでは、その方向に進むのに十分でない場合は、そうすることでセキュリティ上の大きな利点もあることを考慮してください。
データ センターとそのセキュリティ境界を樽に例え、その中にリンゴ (それぞれが展開した数百のアプリの 1 つを表します) を詰め込むと、1 つのリンゴが他の多くのリンゴに触れていることに気付くでしょう。 全部ではありませんが、いくつかあります。 そして、リンゴの 1 つが腐ると、それに触れている人々にも腐りが広がります。 どれが他の樽に触れ、どれが他の樽に触れ、というように樽全体が腐るまで続きます。
1 つの Apple (アプリ) が故障したときに、データ センターでの処理が同じくらい遅くなればよいのですが。 しかし、デジタルのスピードのおかげで、リスクを警告する格言のリンゴよりもはるかに速く、腐敗がネットワークを通じて他のアプリに広がります。
これは、アプリごとの展開スケジュールを採用していない(または採用しない予定である)場合でも、アプリごとのアーキテクチャを採用する最も優れたセキュリティ上の理由の 1 つです。
アプリごとのアーキテクチャを採用することは、樽に放り込む前にリンゴを一つ一つ個別に包むようなものです。 たとえ腐敗したとしても、接触している他のものから隔離され、それらも感染しないようにします。 確かに、リスクがゼロの世界は好ましいですが、私たちのほとんどは虹とユニコーンの国に住んでいるわけではなく、つながりのある世界には常にリスクがあることを認識しており、私たちの目標はリスクを可能な限り最小限に抑えることです。
アプリごとのアーキテクチャを採用することで、特定のアプリケーションの爆発半径を可能な限り多くの脅威に対して制限し、その目標を達成できます。
データセンターでのアプリごとのアプローチにより、ボット、資格情報の盗難、資格情報の詰め込み、アプリケーション層の DDoS 攻撃 (GET、PUSH、POST フラッドなど)、およびよく知られている OWASP トップ 10 の脆弱性によるリスクを軽減するように設計された、さまざまなアプリケーション固有のセキュリティ サービスを導入できます。
Alert Logic はこれを「アプリケーション レベルのセグメンテーション」と呼び、クラウドにおけるベスト プラクティスとして急速に普及しつつあると指摘しています。
このアプローチはデータ センターでも同様に機能し、侵入が成功した場合に横方向の移動からアプリを保護するために同様に(おそらくはそれ以上に)重要です。
アプリごとのアーキテクチャは、特定の個々のアプリを保護するだけでなく、展開した他のすべてのアプリを保護することにも重点を置いていないというのは皮肉に思えるかもしれません。しかし、このアプローチを採用すると、潜在的なエントリ ポイントであること、および他のすべてのアプリ (内部) が攻撃者である可能性があることを認識しながら、個々のアプリのセキュリティ保護に重点を置くことになります。
アプリごとのアプローチは、クラウド (または複数のクラウド) とデータ センター内の自宅の両方に展開できるクラウド対応アプリケーション サービスでさらに効果的に機能します。 アプリケーション サービス ソリューションの標準化とは、組織がデジタル変革の取り組みの一環としてパブリック クラウドを導入する際に必要な一貫したセキュリティを保証するポリシーの統一を意味します。
クラウド(または複数のクラウド)を使用している場合でも、データ センター内にいる場合でも、アプリごとのアーキテクチャは、セキュリティ面で双方にメリットのあるアプローチであり、個々のアプリのリスクを軽減すると同時に、全体を保護して、デジタル経済におけるビジネスの競争力を維持できます。