セキュリティのベスト プラクティスは、特に注目度の高いハッキングやサイバーセキュリティの侵害がリスクを増大させるため、企業にとって依然として最優先事項となっています。モルガン・スタンレーのCIO 調査(2021年) によると、2021年のIT 支出は 4.4% に達すると見込まれており、クラウド コンピューティングとセキュリティ ソフトウェアが主要な用途となっています。業界を越えて急速に進むこのデジタル トランスフォーメーションは、企業にチャンスをもたらすと同時に、新たな課題も生んでいます。

デジタル トランスフォーメーションにおける注目すべきトレンドの 1 つは、モノリシック アーキテクチャからマイクロサービスへの移行です。

マイクロサービスベースのアーキテクチャにはいくつかのメリットがありますが、同時に固有のセキュリティ上の課題もあります。境界防御に重点を置いた従来のサイバーセキュリティ モデルは、複数のコンテナーからの攻撃対象領域が広いマイクロサービスには転用できません。マイクロサービスがセキュリティ侵害を受けると、従来のセキュリティ モデルでは、ネットワーク内の他のサービスを効果的に保護することはできません。その代わりに、企業ではアプリケーションを保護するために多層防御戦略を採用する必要があります。

この記事では、多層防御とは何かについて学び、それがマイクロサービスにどのように適用されるかを見ていきます。その途中で、役立つツールもいくつかご紹介します。このガイドでは、特にクラウドにホストされた Kubernetes クラスター上で実行されるコンテナー化されたマイクロサービスに注目します。

多層防御 (DiD) とは ?

多層防御とは、国家安全保障局 (NSA) が考案したサイバーセキュリティ モデルで、複数レベルの保護対策を (レイヤー状に) 重ねることに重点を置いています。理論的には、多層防御セキュリティは、複数の独立した制御対策を展開してセキュリティを多層化させることで、攻撃が成功する可能性を低減させます。多層防御の制御には、次の 3 つの主要カテゴリがあります。

1. 物理カテゴリ

このカテゴリでは、IT システムへの物理的なアクセスを保護することに重点を置いています。これには、機密性の高いデータ センター周辺のフェンスや常勤警備員などの物理的な予防策や、温度管理、無停電電源装置などが含まれます。クラウドで自社のシステムを運用しているほとんどの企業は、この責任をクラウド プロバイダーや FISMA 準拠のデータ センターに委任できます。

2. 管理カテゴリ

管理制御面では、次のようなポリシーと手順に重点を置いています。

• 最小権限の原則
• ロールベースのアクセス制御 (RBAC)
• 属性ベースのアクセス制御 (ABAC)
• ID およびアクセス管理 (IAM)
• 強力なパスワード ポリシー

また、強力なセキュリティ チームは、脅威のモデリング (モデル化) 演習を行い、脆弱な領域をレビューすることになります。

3. 技術カテゴリ

技術制御面では、ハードウェアとソフトウェアの両システムを対象としています。ここには、以下のものを利用することが含まれています。

• ハードウェア セキュリティ モジュール (HSM) やトランスポート層セキュリティ (TLS) など使用した暗号化
• Web アプリケーション ファイアウォール （WAF） などのファイアウォール
• ネットワークおよびホストの侵入防止システム
• API ゲートウェイ

また技術制御には、機械学習を利用した脅威の検出や、ロギングやモニタリングの実施など、より高度なアクティビティも含まれます。

これら 3 つのカテゴリはすべて、強固な多層防御戦略を実現するために重要なものです。

この記事では、主にクラウド上の Kubernetes ベースのアーキテクチャで運用されているマイクロサービスの技術的制御に焦点を当てます。

マイクロサービスによる多層防御

企業が管理するデータ センターで稼働している従来のモノリシック アプリケーションと比較すると、クラウドの Kubernetes で稼働しているマイクロサービスは、攻撃対象領域が極めて広くなります。この攻撃対象領域を理解するためによく使用されるアプローチは、クラウド ネイティブ セキュリティの 4C を検討することです。

1. クラウド (Cloud)

この最も外側に位置するレイヤーは、クラウド アカウントを保護し、アカウントとサービスが侵害されるリスクを軽減することを目的としています。このレベルの保護には、次のような管理制御が含まれます。

• 環境、プロジェクト、またはロールに基づくクラウド アカウントの分離
• 最小権限の原則に従った IAM ポリシーの設定

各アカウントは多要素認証で保護し、FIDO2 準拠の規格を使用してフィッシング攻撃を防止する必要があります。各サービスをセキュリティ保護するプロセスには、ロード バランサー、ネットワーク ポリシー (ネットワーク ACL やファイアウォールの使用)、およびキー管理や HSM サービスを使用した暗号化スキームの設定が含まれます。

2. クラスター (Cluster)

クラウド アカウントをセキュリティが確保できれば、次に優先されるのは Kubernetes クラスターの保護することです。ほとんどのクラウド プロバイダーは、安全なコントロール プレーンを備えたマネージド Kubernetes クラスターを提供しています。ただし、クラスター管理者は、CIS Kubernetes ベンチマークのセキュリティ ガイドラインに従ってクラスターを強化する必要があります。まず、ほとんどの Kubernetes ディストリビューションで、デフォルトでは無効になっている暗号化機能と監査ログ機能をオンにします。

初期設定以外にも、Kubernetes 管理者はネットワーク ポリシーとアドミッション コントローラーも設定する必要があります。これらの作業により、不正な通信や権限昇格のリスクが抑えられます。この設定を簡素化するために、オープンソース ツールを利用することもできます。たとえば、デフォルトのセキュリティ コンテキストを挿入して pod exec をブロックし、名前空間全体とクラスター全体の両方で権限の昇格を防止できるツールもあります。

最後に、基盤となるホストの OS を保護する必要があります。このためには、攻撃対象領域が大きい汎用の Linux ノード (AWS Bottlerocket や GKE COS など) ではなく、コンテナーに最適化された専用 OS を選択します。

3. コンテナー (Container)

クラウドとクラスターを保護すれば、次のレイヤーはコンテナーです。マルチステージ ビルドを使用して、必要なコンポーネントのみを含んだコンテナー サイズを縮小します。

ディストリビューションベースのコンテナー イメージを使用している場合は、対応する CIS ベンチマークを使用してイメージをハードニングします。または、必要なバイナリのみを含める場合は、ディストロレスまたはスクラッチ イメージを使用します。コンテナーのセキュリティをさらに高めるには、Pod定義のsecurityContextセクションに Linux カーネル機能 (SELinux、AppArmor、seccomp など) を追加します。

実行時に、ホスト侵入検出システムを利用して Linux システムコールを解析し、脅威が検知されたときに警告を表示できます。システムによっては、侵害されたワークロードから守るセキュリティ対策がさらに提供されています。

4. コード (Code)

最後に、コード自体に脆弱性がないことを確認する必要があります。これには次のものが含まれます。

• コードをスキャンしてセキュリティの脆弱性を検出する。
• アプリケーション コードからコンテナーを作成するために使用するツールや依存関係のサプライチェーンを保護する。

ソフトウェア サプライ チェーンを保護することで、ビルド プロセス中にアプリケーション コードが改ざんされることがなくなります。ソフトウェア サプライ チェーンのメタデータを監査するオープンソース ツールなど、一般的に使用できるコード スキャン ツールは多数あります。

この時点で、Kubernetes クラスターをセキュアに設定できしました。これによって、コンテナー化されたコードを使ってクラウド上で実行することができます。しかし、リクエストを受信しながら実行時のセキュリティを確保するには、どのように多層防御モデルを拡張すればよいのでしょうか ?

API ゲートウェイとサービスメッシュを使用したマイクロサービスの保護

Kubernetes で動作するコンテナー化されたマイクロサービスの場合、API ゲートウェイとサービス メッシュを実装することが、システム アーキテクチャ全体にセキュリティ チェックポイントを追加する最適な方法です。さらに、これらのコンポーネントを使用することで、クラスター管理者やアプリケーション開発者は、セキュリティに関する多くの責任が軽減されます。

API ゲートウェイ

API ゲートウェイは API 管理ソフトウェアで、リクエストを受け取り、それを適切なバックエンド サービスにルーティングします。API ゲートウェイは、あらゆるアップストリーム アプリケーションの前に配置され、内部アプリケーションのエンドポイントを公開することなく、イングレス を可能にするシングル エントリー ポイントとして機能します。

また、これを集中管理することで、API ゲートウェイでは認証と許可、入力検証、レート制限などの横断的なセキュリティ対策を容易に行うことができるようになります。そしてこれを活用すれば、アプリケーション開発者はアプリケーション コードのビジネス ロジックに集中でき、イングレスセキュリティを API ゲートウェイに任せられます。

クラウドホスト型 API ゲートウェイの多くは、WAF を備えたロードバランサーの背後に配置され、自動サービス検出、レスポンスのキャッシュ、ロード バランシングなどの機能などを提供しています。

サービス メッシュ

API ゲートウェイは、クラスターへのイングレスを保護するのに役立ちますが、サービス メッシュは、コンポーネント間のクラスター内通信を保護するのに役立ちます。

サービス メッシュは、マイクロサービス間の通信を助けるプロキシのネットワークです。一般的なサービス間通信機能 (サービス検出、暗号化、アプリケーション コードへの再試行など）を実装する代わりに、アプリケーション コンテナーと一緒に実行されるプロキシ (「サイドカー」とも呼ばれる) にこれらの機能をオフロードできます。サービス メッシュは、サービス間の安全な通信を行います。これで開発者は、アプリケーションの作成や、ゼロトラスト アーキテクチャの一元的な実装が容易に行えるようになります。

API ゲートウェイとサービス メッシュは相互に補完するテクノロジーです。Kubernetes クラスターは、API ゲートウェイを使用してイングレス リクエストを制御し、サービス間通信を制御するために内部でサービスメッシュを使用できます。また、マルチリージョンやマルチクラスターのユース ケースでは、クラスター間接続にも使用できます。

まとめ

アプリケーション内のマイクロサービスの数が増えるにつれて、セキュリティ侵害のリスクも高まります。

この記事では、多層防御戦略について学習しました。これは、さまざまなセキュリティ対策をレイヤーで重ねて冗長性を確保するものです。そして、クラウドで動作するマイクロサービスを保護するために、クラウドネイティブなセキュリティの 4C とともに、多層防御の制御 (物理面、管理面、技術面）の 3 つのカテゴリについても学びました。最後は、API ゲートウェイとサービス メッシュを使用して、エンジニアがスケーラブルな抽象化レイヤーとして、セキュリティ上の責任を専用のソフトウェア コンポーネントにオフロードする方法について見てきました。

Kong API ゲートウェイ (Kong Enterprise として自己管理、または Kong Konnect を使用した SaaS ソリューションとして利用可能) と Kong Mesh は、クラウドネイティブなワークロード用としてエンタープライズに対応したセキュリティ ソリューションです。Kong Enterprise と Kong Konnect は、認証からトラフィック制御まで、事前に設定されたプラグインが充実している API セキュリティを提供します。Kong Mesh は、Kuma をベースにしたサービス メッシュで、マルチクラウド、マルチクラスター Kubernetes、VM を横断して統合できます。Kong Konnect または Kong Enterprise と Kong Mesh を組み合わせば、機能がすべて揃った多層防御セキュリティ ソリューションを採用する際に役立ちます。今すぐ個別デモをご覧ください。

原文：Guide to Defense in Depth Security
著者：Eric Pulsifer