マイクロサービスを保護するための 13 のベスト プラクティス

マイクロサービス アーキテクチャは、アプリケーションの他の部分に影響を与えることなく、柔軟性、スケーラビリティ、およびソフトウェア コンポーネントを変更、追加、または削除する機能を提供します。

ソフトウェア開発サイクルの短縮、チームの小規模化、柔軟なプログラミング言語オプションに加えて、他のコンポーネントに干渉することなく、特定の機能やサービスのスケーリングやトラブルシューティングを行うことができます。

一般に、マイクロサービスを使用すると、大規模な一夫一婦制のアプリケーションを個別にデプロイ可能な個別のサービスに分割できます。 ただし、これらの小規模な独立したサービスでは、コンポーネントの数が増えるため、それらを保護することが複雑になり、困難になります。

モノリシック vs マイクロサービス アーキテクチャ イメージ レッドハット

通常、典型的なマイクロサービスの展開には、ハードウェア、サービスまたはアプリケーション、通信、クラウド、仮想化、およびオーケストレーション レイヤーがあります。 これらにはそれぞれ、特定のセキュリティ要件、制御、および課題があります。

マイクロサービスに関連するセキュリティの課題

通常、マイクロサービスは、アクセス ルールが複雑で、監視するトラフィックが多く、攻撃対象領域が広い、広く分散されたシステムです。 さらに、マイクロサービス クラウドのほとんどは、さまざまなセキュリティ構成と制御を備えたクラウド環境で実行されます。

多数の API、ポート、およびコンポーネントが公開されているため、従来のファイアウォールでは適切なセキュリティが提供されない場合があります。 これらの問題により、マイクロサービスの展開は、中間者攻撃、インジェクション攻撃、クロスサイト スクリプティング、DDoS などのさまざまなサイバー脅威に対してより脆弱になります。

ネットワーク セキュリティは、マイクロサービスのもう 1 つの課題です。 特に、ID とアクセス制御は、新しいレベルの複雑さを前提としています。 その他の脆弱性には、安全でないコードやサービス検出システムの欠陥が含まれます。

マイクロサービスを保護することは、モノリシック アプリケーションよりも困難ですが、適切な戦略を確立し、ベスト プラクティスに従うことで効果的に保護できます。

理想的には、アーキテクチャには、さまざまなコンポーネントをすべてカバーする分散型アプローチが必要です。

対応する典型的な分野は次のとおりです。

• アプリケーション、マイクロサービス、ユーザーの保護
• ID とアクセス管理の保護
• データの保護
• サービス間の通信セキュリティを強化する
• マイクロサービスとセキュリティ システムの監視

マイクロサービスを保護するためのベスト プラクティス

最良の戦略の 1 つは、ベスト プラクティス、ツール、およびコントロールを組み合わせて使用​​して、エコシステム全体を保護することです。 実際のアプローチは、サービス、アプリケーション、ユーザー、環境、およびその他の要因の種類によって異なる場合があります。

マイクロサービスを使用することにした場合は、サービス、接続、およびデータに対するすべてのセキュリティ要求を満たしていることを確認する必要があります。

それでは、効果的なマイクロサービスのセキュリティ プラクティスをいくつか見てみましょう。

＃1。 最初からセキュリティを構築する 👮

セキュリティを開発サイクルの一部にします。 理想的には、最初からセキュリティをマイクロサービスの開発と展開に統合します。 この方法でセキュリティに対処することは、ソフトウェア開発が完了に近づいたときにセキュリティを追加するのを待つよりも、簡単で効果的で安価なアプローチです。

＃2。 多層防御メカニズムを使用する

多層防御 (DiP) は、サービスとデータに複数のセキュリティ レイヤーを適用する手法です。 このプラクティスにより、攻撃者が複数のレイヤーに侵入することが難しくなり、サービスとデータに強力なセキュリティが提供されます.

ファイアウォールなどの境界セキュリティ ソリューションとは異なり、多層防御の概念は異なります。 ウイルス対策、ファイアウォール、パッチ管理、スパム対策ソフトウェアなどのツールの組み合わせに依存して、システム全体に分散された複数のセキュリティ レイヤーを提供します。

多層防御の多層セキュリティ イメージ: インパーバ

このアプローチでは、最初に機密性の高いサービスを特定する必要があります。その後、適切なセキュリティ レイヤーを適用します。

＃3。 コンテナ 📦 レベルでセキュリティをデプロイする

ほとんどの場合、マイクロサービスはコンテナ テクノロジに依存しています。 そのため、内部と外部の両方でコンテナーを保護することは、攻撃対象領域とリスクを軽減する 1 つの方法です。 理想的には、最小特権のセキュリティ原則を目指すことは良い習慣であり、以下を含むがこれらに限定されない戦略の組み合わせが必要です。

• アクセス許可を必要最小限に制限する
• sudo または特権アカウントを使用してサービスなどを実行することは避けてください。
• 利用可能なリソースへのアクセスと消費を制限または制御します。 たとえば、コンテナーによるオペレーティング システム リソースへのアクセスを制限すると、データの盗難や侵害を防ぐことができます。
• コンテナ ディスクにシークレットを保存しないでください。
• 適切なルールを使用して、リソースへのアクセスを分離します。

また、コンテナー イメージに脆弱性やセキュリティの問題がないことを確認することも重要です。 コンテナーの定期的なセキュリティおよび脆弱性スキャンは、リスクの特定に役立ちます。

一般的な画像スキャン ツールには、 クレア、 アンカー、 もっと。

＃4。 多要素認証の導入 🔒

多要素認証を有効にすると、フロントエンドのセキュリティが強化されます。

アクセスするユーザーは、別の形式の確認に加えて、ユーザー名とパスワードの詳細を提供する必要があります。たとえば、電話に送信されるコードや指定された電子メール アドレスなどです。 この手法により、盗まれた、またはハッキングされた資格情報を使用している可能性のある攻撃者は、2 番目の認証を提供する方法がないため、マイクロサービスにアクセスすることが難しくなります。

＃5。 ユーザー ID とアクセス トークンを使用する

マイクロサービスの展開では、多数のアプリケーションとサービスが安全な承認とアクセス制御を必要とします。 OAuth 2.0 や OpenID などの承認フレームワークを使用すると、トークンを安全に処理できるため、マイクロサービスを保護できます。 その結果、サードパーティのアプリケーションが他のサービスやユーザーのデータにアクセスできるようになります。

一般的な展開では、メイン アプリケーションはユーザーにサード パーティ サービスの承認を求めるプロンプトを表示します。 これを受け入れると、アプリケーションはセッションのアクセス トークンを生成します。

特に、OAuth は、ユーザー ID とアクセス制御の最も効果的な戦略の 1 つです。 他にもいくつかの承認プロトコルがあり、独自の承認プロトコルを作成することもできますが、ベスト プラクティスとしては、 OAuth より標準的で、安定しており、広く受け入れられているので。

＃6。 API ゲートウェイを作成する

一般に、マイクロサービスは、さまざまなネットワークに分散され、さまざまなシステムやクライアントからアクセスできる複数のコンポーネントで構成されています。 マイクロサービスを公開すると、脆弱性とセキュリティ リスクが増大します。 それらを保護する 1 つの方法は、外部システムおよびクライアントからのすべてのアクセスを一元化するのに役立つ単一の安全なエントリ ポイントを作成することです。

これを実現するには、API ゲートウェイをデプロイして、すべての着信要求をスクリーニングしてセキュリティの問題を調べてから、それらを適切なマイクロサービスにルーティングします。 API ゲートウェイは、クライアント アプリケーションとマイクロサービスの間に位置します。 次に、認証、SSL ターミネーション、プロトコル変換、モニタリング、リクエスト ルーティング、キャッシングなどの追加のリクエスト管理機能を提供しながら、マイクロサービスの公開を制限します。

このアプローチでは、API ゲートウェイはすべての外部サービスをマイクロサービスにルーティングすると同時に、多層防御のセキュリティ原則もサポートします。

マイクロサービス API ゲートウェイ イメージ ライブブック

一般的な API ゲートウェイには次のものがあります。 NGINX、 コング、 ティク、 大使、 AWS API ゲートウェイ、 もっと。

API セキュリティの詳細については、API エンドポイントを保護する理由と方法に関するガイドをご覧ください。

＃7。 デプロイ ゾーンに基づいて API をプロファイリングする

ユーザーが必要な API とサービスにのみアクセスできるようにすることで、役割ベースの制限を実装します。 ほとんどの悪意のあるソフトウェアは、多くの場合、より多くの人にサービスを公開するため、許可されたユーザーのみにアクセスを制限することでリスクが軽減されます。 露出を減らす 1 つの手法は、API にアクセスできるユーザーに基づいて API にラベルを付けることです。 一般に、API は次のようになります。

• イーサネット API – データセンター外の外部世界に公開されるサービス用。
• コーポレート ゾーン API – これらは、内部のプライベート トラフィック用です。
• DMZ API – インターネットから発信されるトラフィックを処理する
• ハイブリッド ゾーン API – データ センターの展開用

#8。 サービス間の通信を保護する

効果的なプラクティスには、2 つのマイクロサービスが通信しているときにリクエストを認証および承認することが含まれます。

一般に、サービス間通信を保護するために使用できる主な手法は 3 つあります。 これらは、Trust the network、JSON Web Token (JWT)、Mutual Transport Layer Security (mTLS、または Mutual TLS) です。

JWT Image によるサービス間通信の保護 ライブブック

3 つのうち、最も一般的なのは mTLS です。 このアプローチでは、各マイクロサービスが公開鍵と秘密鍵のペアを保持する必要があります。 次に、クライアント マイクロサービスはキー ペアを使用して、mTLS を介して受信マイクロサービスに対して自身を認証します。

認証中に、各マイクロサービスは証明書を生成します。 その後、各マイクロサービスは、他のマイクロサービスからの証明書を使用して自身を認証します。

TLS は、転送中のデータの整合性と機密性を提供すると同時に、クライアントがマイクロサービスを識別できるようにします。 通常、クライアント マイクロサービスは他のマイクロサービスを認識しています。 ただし、TLS は一方向であるため、受信マイクロサービスはクライアント マイクロサービスを検証できず、攻撃者はこの欠陥を悪用できます。 一方、mTLS は、各マイクロサービスが相互に識別できる手段を提供します。

#9。 レート制限 🚏 クライアント トラフィック

外部トラフィックを制限することで、サービス拒否 (DoS) 攻撃や、一部のクライアントがアプリケーション帯域幅の大部分を消費するインスタンスなどの問題を防ぎます。 1 つのアプローチは、IP、時間などに基づいてクライアントから送受信されるトラフィックのレートを監視および制御できるさまざまなルールを適用することです。

API へのログイン試行の失敗やその他の不審なアクティビティが複数回検出された場合にサービスの速度が低下するように構成します。

遅いシステムは、攻撃者の気をそらし、おそらくサービスへのアクセスを断念するでしょう。 API ゲートウェイ、コード、またはその他の手法を使用して、レート制限を行うことができます。 通常、ほとんどの SaaS 環境には、ユーザーによる悪用や攻撃を最小限に抑えるための API レート制限があります。

#10。 オーケストレーション マネージャーを使用する

オーケストレーション マネージャーを使用すると、セキュリティを強化するだけでなく、構成、調整、およびその他のマイクロサービス管理タスクを自動化できます。 通常、ツールを使用すると、複数のコンテナーの管理、メタデータ アクセスの制限、ワークロードの分離、ログの収集などを行うことができます。

一部のオーケストレーション ツールには、開発者が SSL 証明書、暗号化キー、パスワード、ID トークンなどの機密情報を保存および共有できるようにする追加機能があります。

効果的なマイクロサービス オーケストレーションのために一般的に使用される 2 つの方法は次のとおりです。

• オーケストレーションをマイクロサービスとしてコーディングする
• API ゲートウェイを使用してオーケストレーション レイヤーを提供する

API ゲートウェイを介したオーケストレーションは、サービスをスケーリングする必要がある場合の課題のため、お勧めしません。

マイクロサービス オーケストレーション レイヤー – イメージ グローバルロジック

一般的なオーケストレーション管理ツールには、 Kubernetes、 イスティオ、 Azure Kubernetes サービス (AKS)など

詳細については、DeOps のコンテナ オーケストレーションをご覧ください。

#11。 すべてのシステムとサービスを監視する

マイクロサービスは分散システムに依存しているため、個々のコンポーネントすべてに対して信頼性が高く効果的な監視戦略が必要です。

継続的な監視を展開すると、セキュリティ リスクを適切なタイミングで検出して対処できます。 これに向けて、以下を含む幅広いマイクロサービス監視ソリューションがあります。 プロメテウス、 統計、 流入DB、 ログスタッシュなど

マイクロサービス アーキテクチャ内の監視

適切なツールを使用して、内部システムとサービスを監視します。 いくつかのベスト プラクティスは次のとおりです。

• アプリケーション層でロギングを有効にします。 あなたはできる スプランク、 グラファナ、 ELK スタック、およびアプリケーション、コンテナ、ネットワーク、およびインフラストラクチャ レベルでログを収集するその他のツール。
• 使用状況の指標を監視する
• CPU、メモリ、応答時間、エラー、通知などのメトリックの傾向を使用して、既存または潜在的な攻撃を示す異常なアクティビティを検出します。
• 着信クライアント リクエスト、データベース レコード、コンテナーなどの領域のログを監査して、矛盾や異常なアクティビティを特定します。

#12。 セキュリティ アクティビティの自動化

アップデートの展開、脆弱性スキャン、監視、ポリシーの適用、その他のアクティビティなどのセキュリティ プロセスを自動化します。 さらに、アップデートをチェックして、それらが安全であり、新しい脆弱性を導入していないことを確認してください。

更新後、セキュリティ ソフトウェアは理想的には、すべてのコンテナーとマイクロサービスに対してテストを実行して、以前に発生した脆弱性やセキュリティの問題があったかどうかを確認する必要があります。

#13。 常に 🛡️ データを保護

転送中および保存中のデータを保護します。 理想的には、転送中のデータを保護するためにすべての通信に HTTPS の使用を強制し、保管中のすべての機密データを暗号化します。 コードの外部にあるプレーン テキストのパスワード、キー、資格情報、および機密データを送信および保存しないようにします。

最善の戦略は、標準テクノロジを使用してすべての機密データをできるだけ早く暗号化することです。 また、露出を減らすために、できるだけ遅くデータを復号化します。

結論

マイクロサービスは、分散コンポーネントに依存して、より高い柔軟性や展開オプションなどの利点を提供します。 ただし、マイクロサービスを使用する場合、組織は内部のセキュリティ ポリシーと戦略を、よりクラウドネイティブで分散型のアプローチに向けて調整する必要があります。

理想的には、攻撃対象領域を減らし、マイクロサービス環境、API、アプリケーション、およびデータを保護することを目指します。