スキップしてメインコンテンツへ
キャリアで成功 (THRIVE) を。 今なら10%オフ! スタンダードおよびプレミアムのTHRIVE-ONEサブスクリプション

マイクロサービスセキュリティの概要

2022年3月28日#!30木、28 4月202215:29:47 +0000Z4730#30木、284月2022 15:29:47 +0000Z-3 +00:003030 +00:00X30 28 PM30PM-30 29:47 +0000Z3+00:003030+00:00x302022木, 28 4月 2022 15:29:47 +0000293294pm木曜日=618#!30木, 28 4月 2022 15:29:47 +0000Z+00:004#現在の#!30木, 28 4月 2022 15:29:47 +0000Z4730#/30木, 28 4月 2022 15:29:47 +0000Z-3+00:003030+00:00x30#! 30木、28 4月 2022 15:29:47 +0000Z+00:004#お知らせ

By Marco Fioretti

マイクロサービスソフトウェアアーキテクチャ 大規模なWebプラットフォームの各主要機能を、クラウドで実行される個別の小規模なサービスとして正確に実装します。セキュリティ面では、マイクロサービスとその両方の性質 アプリケーションプログラミングインターフェイス(API) この記事に要約されているユニークな機会と課題を提示します。このトピックを掘り下げる前に、このシリーズの以前の部分を最初に読んでおくとよいでしょう。 マイクロサービス:定義と主なアプリケーションマイクロサービスのAPI.

マイクロサービスは異なるサーバーに分散されているため、同じプラットフォームのモノリシック実装よりも大きく、多様な攻撃対象領域を公開することがよくあります。これにより、問題を回避するのに十分な早さで脆弱性を見つけて修正することが難しくなります。少なくとも、これには多くの異種データのリアルタイム分析が必要です。セキュリティを無視しても、相互接続された多くのマイクロサービスを設計して、そのうちの1つが失敗したり、侵害されたりしても、他のサービスが壊れたり失われたりしないようにします。 彼ら自身 内部データは非常に複雑になる可能性があります。

良い面としては、これらの同じ特性により、ピアのニーズに関係なく、可能な限り最適なセキュリティ対策を使用して、各単一のマイクロサービスを構成および実行できます。このようにして、攻撃者が1つのマイクロサービスの侵害に成功した場合、同じ技術や知識を再利用して他のマイクロサービスを侵害することができない可能性があります。

一般的な基準

安全なマイクロサービスを設計するための出発点は簡単です。設計と実装が終わったときにすべてが大丈夫かどうかを尋ねるのではなく、開発の最初からセキュリティスペシャリストを積極的に関与させます。

マイクロサービスでは、従来のWebベースのアプリケーション用に長年にわたって開発された標準のセキュリティ技術がさらに必要になります。次のような対策を参照します。

  • コマンドインジェクションを防ぐために入力データをサニタイズします
  • クラウドで実行されるマイクロサービス間では通信が「内部」ではないため、すべての通信を暗号化します
  • 同じ理由で、データをできるだけ早く暗号化し、できるだけ遅く復号化します。たとえば、他のマイクロサービス間でメッセージを中継する必要があるマイクロサービスには、ペイロードを復号化するビジネスはありません。
  • 可能な限り、マイクロサービスの接続速度を制限して、サービス拒否攻撃を防ぎます
  • アプリケーションからインフラストラクチャまで、すべてのレベルで自動化されたテスト、展開、およびロギングの手順を設定し、異常が検出されるとすぐに管理者に自動アラートを送信します

これらの基本的なベストプラクティスに加えて、マイクロサービスベースのプラットフォームに最も広く適用できるセキュリティ対策のいくつかは、次のセクションで説明するものです。

ソフトウェアを常にクリーンに保ちます。それのすべて

オリジンやライセンスに関係なく、すべてのマイクロサービスのすべてのリリースには、受け取ったセキュリティ修正をリストした適切なリリースノートが必要です。これは明白かもしれませんが、それほど明白ではなく、達成するのが非常に難しいかもしれないことは、同じ保証がすべての サードパーティコンポーネント マイクロサービスは、ソフトウェアサプライチェーン全体で使用します。現実の世界では、すべてのコンポーネントに適切な情報が付属していない限り、十分な詳細と分析が容易な標準形式でその情報を取得することは非常に困難です。 ソフトウェア部品表(SBoM).

コンテナーはマイクロサービスの友達です。彼らが本当に安全であるとき、それは

マイクロサービスの最大の利点の1つは、管理者がプラットフォームのすべてのコンポーネントをいつでも簡単にアップグレードまたはロールバックできることであり、同じプラットフォームの残りの部分への影響を最小限に抑えることができます。

この分離を実現し、カスタムセキュリティ対策を実施するための最も簡単で一般的な方法は、各マイクロサービスを独自のコンテナにデプロイすることです。実際には、これは、コンテナが適切に作成および管理されている場合にのみ期待どおりに機能します。イメージには、ソフトウェアとデータができるだけ少なく、できるだけ保護されています。たとえば、マイクロサービスのコンテナイメージには、パスワードやその他のクレデンシャルを含めることはできません(これについては以下で詳しく説明します)。さらに、それらはデジタル署名され、管理者が常に必要な正確なバージョンを取得することを保証するために接尾辞のタグが付けられ、次のような安全なバージョン管理でプライベートリポジトリに保持される必要があります 。コンテナーの実際のデプロイと管理は、Docker、crio、containerdなどのツールを使用して行うことができます。ただし、すべての場合において、これらのツールは、Dockerのように、できるだけ少ない権限で実行する必要があります。 ルートレスモード、脆弱性を最小限に抑えるために 彼ら がある可能性があり。

ホイールを作り直すことなく、すべてのアクセスを制御する

マイクロサービスは、認証されたユーザーのみを許可するようにアクセスを制限するだけでなく、それらのユーザーが本当に必要な機能とデータの最小セットのみにアクセスできるようにする必要があります。多くの場合、この種の最初の保護は、 マイクロサービスAPIゲートウェイ、これにより、攻撃者はプラットフォーム全体への高度に保護されたエントリポイントを1つだけ残します。

または、状況によっては 添加 セキュリティではなく、パフォーマンスを最大化するためにのみ使用できるAPIゲートウェイに対して、認証と暗号化の目的で独自の証明書とキーのセットを使用して、各マイクロサービスに独自の承認サーバーを与えることができます。プラットフォーム全体の管理がより複雑になり、場合によっては速度が低下する一方で、この戦略によりセキュリティと堅牢性が大幅に向上します。選択する承認戦略が何であれ、認証とアクセス制御に関する実績のあるオープンな業界標準に固執します。 OpenIDコネクト OAuth 2.0.

アクセス資格情報とキーを安全に保つ

上記のように、マイクロサービスのコンテナーイメージには、ユーザーパスワード、API認証キー、または同様に機密情報を含めることはできません。そのようなデータがクラウドにあるか、複数のリポジトリに散在していることが少ないほど、たとえそれらがプライベートなものであっても、それは良いことです。より安全で、通常は管理が容易なソリューションは、すべてのデータを1つの中央ボールトに保持し、環境変数などを介して実際に起動されたときにのみマイクロサービスコンテナーに渡すことです。

最後になりましたが、複数の防御層があります

プラットフォームのマイクロサービスはクラウド全体に分散されているため、従来のファイアウォールで適切に保護できる、明確に定義された単一の「境界」はありません。ただし、実際には、これはほとんど違いがありません。マイクロサービスプラットフォームを保護するための正しいアプローチは、常にゼロトラストアプローチを採用することであり、 多数 保護の層。常に組み合わせる、つまり、分散ファイアウォールや サービスメッシュ 最も機密性の高いデータを管理するマイクロサービスから始めて、ここで説明した他の手法を使用します。

このシリーズの次の記事を必ずお読みください。 マイクロサービスがどのように連携するか.

あなたまたはあなたのチームのサイバーセキュリティスキルを向上させたい場合は、いくつかの トレーニングコースと認定 Linux Foundation Training&Certificationが提供するこのトピックについて。

Linux Foundationのトレーニングと認定に関心をお寄せいただきありがとうございます。私たちは、中国のトレーニングサイトからより良いサービスを提供できると考えています。このサイトにアクセスするには、以下をクリックしてください。

Linux Foundationのカルチャに対するフィードバックは、より適切に、中国のカルチャウェブサイトに反映されることを期待しています。