ホーム テクノロジー 開発 非公開: マイクロサービスを保護するための 13 のベスト プラクティス

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


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

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

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

モノリシック アーキテクチャとマイクロサービス アーキテクチャ
モノリシック vs マイクロサービス アーキテクチャ Image Redhat

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

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

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

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

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

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

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

対処すべき一般的な分野には次のようなものがあります。

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

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

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

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

次に、効果的なマイクロサービスのセキュリティ実践をいくつか見てみましょう。

#1.最初からセキュリティを構築します 👮

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

#2.多層防御メカニズムを使用する

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

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

多層防御の多層セキュリティ
多層防御の多層セキュリティ 画像: Imperva

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

#3.コンテナ 📦 レベルでセキュリティを導入する

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

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

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

典型的な画像スキャン ツールには、 ClairAnchoreなどが含まれます。

#4.多要素認証を導入する 🔒

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

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

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

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

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

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

#6. APIゲートウェイを作成する

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

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

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

マイクロサービス API ゲートウェイ Image Livebook

一般的な API ゲートウェイには、 NGINXKongTykAmbassadorAWS API ゲートウェイなどが含まれます。

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

#7。デプロイメントゾーンに基づいたプロファイル API

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

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

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

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

一般に、サービス間通信を保護するために使用できる主な手法は 3 つあります。これらは、 「ネットワークを信頼する」JSON Web トークン( JWT)、および相互トランスポート層セキュリティ( mTLSまたは相互 TLS ) です。 

JWT によるサービス間通信の保護
JWT Image Livebookによるサービス間通信の保護

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

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

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

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

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

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

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

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

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

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

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

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

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

マイクロサービスオーケストレーション層
マイクロサービス オーケストレーション レイヤー – Image Globallogic

典型的なオーケストレーション管理ツールには、 KubernetesIstioAzure Kubernetes Service (AKS)などが含まれます。

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

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

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

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

Grafana プロメテウスの視覚化
Grafana プロメテウスの視覚化
Grafana プロメテウスの視覚化

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

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

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

#12.セキュリティ活動を自動化する

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

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

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

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

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

結論

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

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

「マイクロサービスを保護するための 13 のベスト プラクティス」についてわかりやすく解説!絶対に観るべきベスト2動画

クラウド導入のベスト プラクティス – Cloud Adoption Framework 概要 – cafbc01 | 日本マイクロソフト
【AWS Black Belt Online Seminar】AWSにおけるマイクロサービスアーキテクチャの設計パターン