AWS におけるセキュリティとマイクロサービスアーキテクチャ

第6章. 一般向けサービス

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

第5章では、マイクロセグメンテーションのプロセスを通じて、ネットワーク・アーキテクチャとすべてのバックエンド・サービスをきれいに分離する必要性について述べた。マイクロセグメンテーションは、クリーンでシンプルなバックエンドプロセスを徹底してセキュアにするのに適している。このドメイン分離のプロセスは、バックエンド・サービスではうまく機能するかもしれないが、エンドユーザ向けのシステムは、ユーザの要件とセキュリティを念頭に置いて設計されなければならない。これらの一般ユーザー向けサービスは、アプリケーションのエッジに存在するため、エッジ・サーバーとも呼び出される。

クリーンで分離されたエッジ・インフラを持つことは、バックエンド・サービスのドメイン設計を、進化し続けるエンド・ユーザの要求から切り離すのに役立つ。図6-1は、エッジが残りのバックエンドマイクロサービスからきれいに分離されている典型的なアプリケーションの例を示している。

図6-1. この章では、"パブリック向けエッジサーバ "領域に点を当てる。このサーバは、インターネットからサービスにアクセスしようとする人にとって、アプリケーションとの最初の接点となる。

この章を始めるにあたって、公衆向けのエッジサーバ上のサービスは、バックエンドのサービスよりも本質的に安全性が低いということを述べておこう。どのようなシステムにおいても、潜在的な脅威は3つのカテゴリーに分類することができる。理論的には多くの攻撃が可能である。バックエンド・サービスの場合、攻撃者がシステムの周囲に侵入するのを防ぐ予防的コントロールがすでに施されている可能性があるため、もっともらしいと考えられる脅威のサブセットはかなり少なくなり、可能性があると考えられる脅威のサブセットはさらに少なくなる。その結果、セキュリティ専門家は、アプリケーションの全体的なリスクを低減するために、もっともらしい脅威と可能性の高い脅威に焦点を絞ることができる。

エッジサーバはより広いインターネットに接続されているため、世界中の悪意ある行為者にとって公平なゲームとなる。エッジサーバーが公衆の目に触れることで、一見非現実的な脅威が現実のものとなる可能性が高まる。そのため、エッジ・サーバでは、起こり得る脅威と起こり得る脅威を区別することが難しくなる。セキュリティの専門家は、あらゆる可能性のある脅威と戦うことを余儀なくされ、ネットワークのエッジで制御を開発することがより難しくなる。

また、エッジで着信するリクエストを暗黙の信頼とすることも難しい。なぜなら、これらの 呼び出しはアプリケーションのコンテキストを越えて発信されるからである。これは、各リクエストが許可されるためには、独立して認証され、アクセ スコントロールポリシーと照合されなければならないことを意味する。前の章で述べたように、これはゼロトラスト・セキュリティと呼ばれる。ゼロトラストセキュリティは、確かに重要なセキュリティ概念ではあるが、それは、単一の責任原則（SRP）である1つの問題に集中して、リーンであるべきマイクロサービスに、大きなオーバーヘッドを追加する。 ...