(より安全な) サービスとして機能する

applicationアーキテクチャと開発には、基本的に「より小さくして効率を高める」という形をとる現代的なアプローチがいくつかあります。

マイクロサービスと Function as a Service (FaaS) はどちらも、高度に集中したコードの概念に依存しています。 現在、ほとんどの組織がapplicationsを数百のマイクロサービスや数千の機能に分解していないのは事実ですが、この設計に傾倒しています。 これは多くの場合、比較的小規模なチームで、大規模なモノリシックapplicationよりもはるかに迅速にサービスを設計、開発、改良できるため、アジャイル開発が容易になるためです。 結局のところ、100,000 行のコードを実行する大規模なapplicationよりも、1,000 行のコードを書いてテストする方がはるかに簡単です。

しかし、マイクロサービスと FaaS には、本来ほど宣伝されていないもう 1 つの興味深い利点があります。それは、セキュリティです。

インターネット上には、「業界平均」の欠陥と脆弱性の密度を確定しようとする議論が数多くあり、私はそれらのかなりの数を読みました。 オープンソース コードの実際のスキャンに基づいたものや、自己申告の数値に基づいたものなど、さまざまな推定値が見つかります。 たとえば、NASA は、スペースシャトル計画の成功の理由の 1 つとして、欠陥密度が極めて低いことを誇らしげに宣伝しています。 WhiteHat などのセキュリティ企業から客観的に収集されたデータに基づくレポートもありますが、その数値は必ずしもコード行ごとではなく、applicationごとの脆弱性に焦点を当てています。

欠陥と脆弱性の密度については、確かに存在するということ以外に、実際のコンセンサスはありません。

しかし、書くコード行数が少なければ少ないほど、欠陥や脆弱性が導入される可能性が低くなるのは当然です。 同様に重要なのは、脆弱性や欠陥を見つけるために検索しなければならないコード行数が少ないほど、脆弱性や欠陥をより早く見つけ、おそらくは修正できるということです。

これが真実である理由の 1 つは範囲です。 マイクロサービスまたは関数がビジネス ロジックの 1 つの側面をコード化することに重点を置いている場合、実装に必要なロジックとライブラリが少なくなります。 スコープが小さくなると、ロジックにエラーが発生したり、追加ロジックを実装するために必要なライブラリ (サードパーティ製など) に脆弱性が生じたりする可能性が低くなります。 別のコンポーネントを追加したり、別のサービスを呼び出す必要があるたびに、欠陥や脆弱性が生じる可能性が高まります。

関数やマイクロサービスへのインターフェースが少なくなると、コードのセキュリティも向上します。 すべてのインターフェース (API 呼び出しなどのエントリ ポイント) では、ユーザー入力を処理するため、脆弱性が生じる可能性があります。 そして、私たち全員が知っているように、ユーザー入力は常に疑わしいもの、潜在的に悪意のあるものとして扱う必要があります。

マイクロサービスによって脆弱性や欠陥の可能性が減るのであれば、機能の範囲をさらに狭めることでその可能性はさらに減るはずです。

ただし、これはマイクロサービスと FaaS が 3 層およびモノリシックなサービスよりも本質的に安全であるという意味ではありません。 いい加減なコードは、何行であっても、いい加減なコードです。 しかし、どちらのアーキテクチャも、より安全なコードにつながる開発および配信の実践に適しているのは事実です。

マイクロサービスや FaaS を評価または実装する際にセキュリティ上の利点を念頭に置くと、コードの肥大化を防ぎ、脆弱性の導入を防ぐのに役立ちます。