クラウドネイティブアプリケーションセキュリティへのアプローチ

クラウド ネイティブ アプリケーションを保護するには、マイクロサービスによってさまざまな消費者に公開されるインターフェース (境界) を適切に理解する必要があります。適切なレベルのセキュリティを実現するには、各境界に適切なツールとメカニズムを適用する必要があります。アプリケーションを実行するインフラストラクチャを適切に保護することも非常に重要です。これには、コンテナ イメージの保護、コンテナ ランタイムの安全な実行、コンテナ オーケストレーション システム (Kubernetes) の適切な構成と使用が含まれます。

マイクロサービスのセキュリティ環境

マイクロサービス以前の時代では、ほとんどのアプリケーションは MVC アーキテクチャに従っていました。現在、これらをモノリシック アプリケーションと呼びます。このようなアプリケーションとは対照的に、クラウド ネイティブ アプリケーションは、図 1 に示すように、高度に分散されています。

図 1: モノリシック アプリケーションとクラウド ネイティブ アプリケーション

モノリシック アプリケーションには通常、単一のエントリ ポイントがあります。それ以外では、データベース呼び出しや同様のやり取りを除いて、すべてが 1 つのプロセスで実行されます。対照的に、クラウド ネイティブ アプリケーションの露出面ははるかに大きくなります。図 1 に示すように、クラウド ネイティブ アプリケーションには通常、ネットワーク経由で通信する複数のコンポーネント (サービス) があります。特定のコンポーネントへのすべてのエントリ ポイントを適切に保護する必要があります。

アプリケーション境界の保護

アプリケーションの境界についてさらに詳しく説明し、実際に考慮する必要がある境界を理解しましょう。

クラウドネイティブアプリケーションにおける通信境界の特定

一般的なクラウドネイティブ アプリケーションのバックエンド アーキテクチャには、複数のビジネス ドメインが含まれます。各ビジネス ドメインは、一連のマイクロサービスをカプセル化します。小売システムを例に挙げてみましょう。注文処理と在庫管理は、それぞれ独自のマイクロサービス セットを持つ 2 つのビジネス領域になります。

ビジネス ドメイン内のマイクロサービスは、境界なく安全に相互通信できるようになります。これは図 2 に「ドメイン内東西トラフィック」として示されています。このドメイン内で安全な通信を実現するには、相互 TLS を使用できます。相互 TLS はサービス メッシュを使用して実装できます。より軽量なアプローチとしては、ゲートウェイの 1 つによって発行された認証トークンを渡すことが考えられます。このアプローチについては、この記事の後半で説明します。

図2: クラウドネイティブアプリケーションアーキテクチャ

ビジネス ドメイン間のマイクロサービスは、API として公開され、明示的に通信を許可しない限り、自由に相互に通信できないようにする必要があります。

これは図 2 に「ドメイン間東西トラフィック」として示されています。ビジネス ドメイン境界の概念については、「セルベース アーキテクチャ」という論文でさらに詳しく説明されています。

すべてのマイクロサービスとクライアント アプリケーション (Web/モバイル アプリ) の間には明確な境界があります。これは図 2 では「南北トラフィック」として示されています。

API と API ゲートウェイを使用してクラウド ネイティブ アプリケーションを保護する

次に、API とマイクロサービスとして定義するものを特定しましょう。特定の境界の外部に公開する必要があるマイクロサービス (ま​​たはマイクロサービスのコレクション) は、API として定義する必要があります。 API には通常、OpenAPI、GraphQL、AsyncAPI などの仕様があります。API Gateway は境界を越えて API を公開するために使用されます。 API ゲートウェイの主なタスクは次のとおりです。

• 呼び出しクライアントからのメッセージを受け入れます。
• クライアントに適切なレベルの認証/承認があることを確認します。
• メッセージを正しい宛先 (マイクロサービス) に転送します。

図 2 に示すように、API ゲートウェイは、ドメイン間の東西チャネルだけでなく、南北チャネルでもクラウド ネイティブ アプリケーションを保護します。

クラウドネイティブアプリケーションのセキュリティ確保におけるOAuth2.0の役割

API を呼び出すクライアントは、API と通信する前に、トークン サービスから OAuth2.0 アクセス トークンを取得する必要があります。 API ゲートウェイはトークンを検証し、宛先へのアクセスを許可する前に信頼できる機関によって発行されたものであることを確認します。これを図 3 に示します。API へのアクセスは一般的ですが、トークンの種類と取得方法は、トークンの使用例によって異なります。

図3: OAuth2.0アクセストークンの取得と使用のワークフロー

OAuth2.0 仕様には、アクセス トークンを取得するための手順を定義する「許可タイプ」と呼ばれる概念があります。 Prabath Siriwardena 著の『Advanced API Security』は、OAuth2.0 の概念とその使用例を理解するのに適した本です。

クラウドネイティブアプリケーション認証

有効なアクセス トークンを所有することが、クライアントが API にアクセスするための主な要件です。アクセス トークンの主な利点の 1 つは、API を呼び出すことができるだけでなく、それを使用して実行できる操作の種類を指定できることです。

OAuth2.0スコープを使用した認証

製品カタログ API に、製品リストを取得するための操作 (GET /product-list) と製品リストを変更するための操作 (PUT /product-list) の 2 つの操作があるとします。小売店アプリケーションでは、すべてのユーザーが製品リストを取得できる必要がありますが、製品リストを変更できるのは選択されたユーザーのみである必要があります。

API 上でこれをモデル化する標準的な方法は、製品リストの更新操作には特別な「スコープ」が必要であると言うことです。この API へのアクセスに使用されるトークンにこのスコープがない場合、リクエストは許可されません。 OpenAPI 仕様では、スコープを操作にバインドできます。

クライアントは、操作にアクセスするために特定のスコープが必要であることを認識すると、必要なスコープを持つトークンを発行するようにトークン サービスに要求します。要求元のユーザー/クライアントが要求されたスコープを取得する権限を持っていることを検証する場合、トークン サービスは関連するスコープをトークンにバインドします。このワークフローを図 4 に示します。

図4: スコープを使用してAPIにアクセスする

認証と承認は API ゲートウェイで終了することがわかります。しかし、場合によっては、実際のマイクロサービスでは、ビジネス ロジックを実行するためにユーザー/クライアントがサービスにアクセスする方法の詳細を知る必要があります。この要件は、API ゲートウェイがセカンダリ JWT 形式のトークン (アクセス トークンではない) を発行し、それをターゲット サービスに転送することによって実現されます。このセカンダリ トークンは、ドメイン内のマイクロサービス間で渡され、ドメイン内で相互信頼を確立するために使用できます。

OPA 認可

権限に加えて、クラウド ネイティブ アプリケーションに他の承認ルールを実装する必要がある場合もあります。平日の午前 8 時から午後 6 時の間に利用可能な特定のアプリケーション機能へのアクセスを制限することを検討してください。これはマイクロサービスのソース コードに実装できますが、良い方法ではありません。

これらは変更可能な組織戦略です。ベストプラクティスは、このようなポリシーをコードから外部化することです。

Open Policy Agent (OPA) は、マイクロサービスに依存しない軽量の汎用ポリシー エンジンです。承認ルールは Rego に実装し、OPA にマウントできます。

図 5 は、OPA が認可ルールに使用できるパターンを示しています。

図5: OPAを使用した認証

Docker によるコンテナのセキュリティ保護

Docker は、マイクロサービスをパッケージ化して配布するための最も人気のあるツールです。 Docker コンテナはマイクロサービスとその依存関係をカプセル化し、コンテナ レジストリ (プライベートまたはパブリック) に保存されます。

図6: Dockerビルドとプッシュ

アプリケーションシークレットの外部化

マイクロサービスは、多くの場合、データベース、サードパーティ API、他のマイクロサービスなどに依存します。これらの種類のシステムに接続するために、マイクロサービスは証明書やパスワードなどの機密情報 (シークレット) に依存する場合があります。モノリシック アプリケーションでは、このタイプの情報はサーバー構成ファイルに保存されます。

特権ユーザーのみがサーバー構成ファイルにアクセスできます。しかし、マイクロサービスの世界では、開発者は通常、この情報をマイクロサービス コードとともにプロパティ ファイルに保存します。開発者がこのようなコンテナを構築し、コンテナ レジストリにプッシュすると、この情報はコンテナ イメージにアクセスできるすべてのユーザーが利用できるようになります。

これを防ぐには、アプリケーション シークレットをコードから外部化する必要があります。これを実行する Java プログラムの Dockerfile の例を見てみましょう。

 openjdk から: 17 - jdk - alpine
 ADD ビルド/ サンプル- java - program.jar \
 サンプル- java - program.jar
 環境変数CONFIG_FILE = /opt/configs/service.properties
 ENTRYPOINT [ "java" 、 "-jar" 、 "sample-java-program.jar" ] 

この Dockerfile の 3 行目は、Docker に CONFIG_FILE という環境変数を作成し、それを /opt/configs/service.properties の場所を指すように指示します。ソース コードにシークレットをハードコーディングしたり、固定のファイルの場所から読み取ったりするのではなく、この環境変数の値を参照して構成ファイルの場所を特定し、その内容をメモリに読み込むようにマイクロサービスのコードを記述します。これにより、コード内の秘密をうまく回避できます。このファイルを使用して Docker コンテナを構築する場合、機密情報は含まれません。次に、必要な値を外部化する方法を見てみましょう。

上記の Dockerfile から構築された Docker イメージを実行する前に、正しい値を持つ実際の構成ファイルの場所にマウントする必要があります。これは次の Dockerrun コマンドで実行できます。

 :\ > docker run - p 8090 : 8090 -- マウントタイプ= bind 、\ ソース= "/hostmachine/configs/service.properties" \
 ターゲット= "/opt/configs/service.properties" 

ソース セクションには、コンテナー ホスト上のファイル システムへのパスが含まれます。ターゲット部分には、コンテナのファイル システム上のパスが含まれます。 --mount コマンドは、Docker ランタイムにソースをターゲットにマウントするように指示します。つまり、service.properties ファイルをホストのファイルシステム上で安全に維持し、コンテナーを起動する前にコンテナー ランタイムにマウントできるようになります。このようにして、Docker 上のマイクロサービス自体から機密情報を外部化します。

Docker コンテンツ トラスト

現代のソフトウェアは多くの依存関係で構成されています。ソフトウェア サプライ チェーンは、アプリケーション コードから CI/CD、さらには本番環境に至るまでのソフトウェア依存関係の集合です。マルウェアが依存関係チェーンを通じてアプリケーション ランタイムに侵入するため、ソフトウェア サプライ チェーン攻撃は非常に頻繁に発生します。

Docker 上で実行されるクラウドネイティブ アプリケーションは、1 つ以上のリポジトリから取得された Docker イメージに依存します。疑いを持たない開発者が悪意のある Docker イメージに依存し、その結果アプリケーションが危険にさらされる可能性があります。これを防ぐために、Docker は Docker Content Trust (DCT) と呼ばれるメカニズムを導入しました。これにより、イメージ発行者は暗号化キーを使用してイメージに署名でき、Docker イメージのユーザーは使用前にイメージを検証できます。開発および CI/CD プロセスで DCT を使用すると、クラウド ネイティブ アプリケーションで信頼できる検証済みの Docker イメージのみを使用するようになります。

開発者は、Docker を使用するすべての環境で DCT を適用するために、DOCKER_CONTENT_TRUST という環境変数を設定し、その値を 1 に設定する必要があります。たとえば: :\> export DOCKER_CONTENT_TRUST=1.この環境変数が設定されると、push、build、create、pull、run の各 Docker コマンドに影響します。つまり、検証されていないイメージに対して docker run コマンドを発行しようとすると、コマンドは失敗します。

Docker 権限

どのオペレーティング システムにも、root と呼ばれるスーパーユーザーが存在します。デフォルトでは、すべての Docker コンテナは root ユーザーとして実行されます。 Linux カーネルの名前空間のパーティション分割のおかげで、これは必ずしも悪いことではありません。ただし、コンテナ内でファイルマウントを使用すると、コンテナランタイムにアクセスできる攻撃者によって非常に危険な状態になる可能性があります。ルート アクセスでコンテナーを実行する場合のもう 1 つの問題は、攻撃者がコンテナー ランタイムにアクセスして、コンテナーに追加のツールをインストールできるようになることです。これらのツールは、開いているポートをスキャンするなど、さまざまな方法でアプリケーションを危険にさらす可能性があります。

Docker は、権限のないユーザーとしてコンテナを実行する方法を提供します。 Linux のルート ユーザー ID は 0 です。Docker では、ユーザー ID とグループ ID を渡すことで Docker コンテナを実行できます。次のコマンドは、ユーザー ID 900 およびグループ ID 300 で Docker コンテナを起動します。これは非ルート ユーザーであるため、コンテナで実行できるアクションは制限されています。

 Docker 実行-- 名前sample - program -- ユーザー900 : 300 nuwan / sample - program : v1 

結論は

クラウドネイティブ アプリケーションを適切に保護することは簡単ではありません。 API ゲートウェイと相互信頼は、通信チャネルの安全性を確保し、ゼロトラスト アーキテクチャを実現するための鍵となります。 OAuth2.0、スコープ、OPA (または類似のもの) は、API が適切に認証および承認されるようにするための基本です。

この範囲を超えて、Kubernetes での正しいセキュリティのベスト プラクティスの使用、シークレット (パスワード) の正しい処理、イベント駆動型 API の保護などにも重点を置く必要があります。 API、マイクロサービス、コンテナは、クラウドネイティブ アプリケーションの基盤です。すべての開発者は、最新のセキュリティの進歩とベスト プラクティスを常に把握しておく必要があります。​