データセキュリティの確保

Mendix プライベートクラウドは、複数の方法で TLS を実装することにより、データのセキュリティを確保します。

• 「イングレス TLS」 – ウェブブラウザ（または他のHTTPクライアント）と Mendix ランタイム。
• 「クライアント TLS」 – クライアント証明書（ランタイムに設定可能）は、リモートサーバーによってクライアントのIDを検証するために使用されます。 Mendix ランタイム。同時に、 Mendix ランタイムは、リモート サーバーによって提示された証明書を使用して、その ID を検証します。
• 「TLS 信頼」 – これは、データベース、ファイルストレージ、またはレジストリに接続するときにプライベートルートCAを信頼するために使用されます。信頼されたルート証明書は、リモートサーバーの信頼性を検証し、他の外部サービス（たとえば、サーバー内で消費されるRESTまたはSOAPサービス）への接続にも使用されます。 Mendix アプリ）。

それでは、サービス メッシュは何のために必要なのでしょうか。実際のところ、サービス メッシュとは何でしょうか。まずは、安全な通信の基礎を理解することから始めましょう。

TLS とは何ですか?

TLS (トランスポート層セキュリティ) は、データを暗号化し、ID を検証し、データの整合性を維持することで、信頼できない可能性のあるネットワーク上の 2 つのデバイス間の安全な通信を保証する暗号化プロトコルです。

主なコンポーネントは次のとおりです。

• 公開鍵と秘密鍵と呼ばれる 2 つの鍵。
• どちらのキーにも有効期限が設定されています。
• 公開鍵で暗号化されたデータは、秘密鍵でのみ復号化できます。
• 秘密鍵で暗号化されたデータは、公開鍵でのみ復号化できます。

TLS はどのように機能しますか?

簡単に言うと、サーバーには TLS 証明書とキー ペアがあります。プロセスは次のようになります。

1. クライアントはサーバーに接続します。
2. サーバーは TLS 証明書を送信します。
3. クライアントはサーバーの証明書を検証します (TLS ハンドシェイク)。
4. クライアントとサーバーは暗号化された TLS 接続を介して情報を交換します。

ここで重要なのは、TLS ではクライアントのみがサーバーの ID を検証することを理解することです。

さて、mTLS とは何でしょうか?

相互トランスポート レベル セキュリティ (mTLS) は TLS の上に構築されます。プロセスは非常に似ていますが、クライアントが独自の証明書とキー ペアを持ち込む点が異なります。つまり、クライアントとサーバーは互いの ID を確認します。

mTLS は次のように動作します。

1. クライアントはサーバーに接続します。
2. サーバーは TLS 証明書を送信します。
3. クライアントはサーバーの証明書を検証します (TLS ハンドシェイク)。
4. クライアントは TLS 証明書を送信します。
5. サーバーはクライアントの証明書を検証します (再び TLS ハンドシェイク)。
6. その後、安全なチャネルを介して接続が確立されます。

では、サービス メッシュとは何でしょうか?

サービス メッシュは、マイクロサービス アーキテクチャ内で動作するネットワーク インフラストラクチャです。その主な目的は、サービス間でデータが移動する際にセキュリティを強化し、データの暗号化を管理することです。

この投稿では、サービス メッシュが提供できる多くの機能のうち、次の 3 つにのみ焦点を当てます。

• サービス間暗号化: サービス メッシュは、TLS と mTLS を使用して、これらのサービス間通信を暗号化および認証します。
• 証明書管理: サービス メッシュは、証明書の発行、ローテーション、配布を自動化することで、TLS 証明書の管理を簡素化します。
• ゼロトラストネットワーキング: サービス メッシュでは多くの場合、「ゼロ トラスト」アプローチが採用されます。これは、サービス間の通信がデフォルトでは信頼されないことを意味します。TLS と mTLS は、信頼できるネットワーク内であっても通信相手の ID を検証し、データを暗号化するため、このアプローチで重要な役割を果たします。

サービスメッシュ Mendix プライベートクラウド向け

このデモンストレーションでは、 AWS EKS の公式 Terraform デプロイメント モジュール Kubernetes クラスターのプロビジョニングに使用されました。その結果、構成されたインフラストラクチャは、最初から次の主要な機能を提供します。

• A Mendix 「mendix」と呼ばれる名前空間内で構成されたオペレーターとエージェント。
• 安全な接続（TLS）が確立されました Mendix アプリケーションと、データベース、ストレージ、レジストリなどの重要なコンポーネント。
• ロードバランサーと Mendix ワークロード。

したがって、ここでの目標は、サービス メッシュがゼロ トラスト ネットワーキングを保証できるようにすることです。つまり、すべてのポッドは相互 TLS を使用して、すべての内部 Kubernetes サービスと安全に通信します。

他に何かありますか? はい、Pod にルーティングされるすべての外部トラフィックを保護するために、Ingress コントローラーも「メッシュ」に含めます。

楽しそう？

混乱するかも知れません?

おそらく、いくつかの図が役立つでしょう:

これが今の私たちの状況です…

注： Mendix エージェントと開発者ポータルは接続モードにのみ適用されます

…そしてこれが私たちが望む最終状態です:

バージョン2.5以降では、 Mendix Operator は、Connected と Standalone の両方のサービスにおいて、Istio および Linkerd と互換性があります。

簡単にするために、Linkerd のみを調べて有効にしますが、Istio のプロセスも非常に似ています。

Linkerdのインストール

フォロー 公式ドキュメント インストールするには:

• オペレーティング システムに応じて、Linkerd CLI を使用します。
• Linkerd CRD
• Linkerd 拡張機能 (viz と dashboard の両方を強く推奨)

Mendix プライベートクラウドメッシュインジェクション

かなりクールな機能 Mendix プライベート クラウドの場合、メッシュの「インジェクション」を環境ごとに有効にすることも (簡単な検証テストや分離に最適)、名前空間全体に対して有効にすることもできます。

Linkerdを有効にする方法については、下の画像を参照してください。また、公式ドキュメントもご覧ください。 コネクテッド – 　 スタンドアロン のガイドをご参照ください。

1つの環境でLinkerdを有効にする

まず、terrapp1 というアプリケーションに対して、開発者ポータルから直接 Linkerd アノテーションを有効にします。

ご覧のとおり、有効化して変更を適用すると、 Mendix Pod が再起動し、Linkerd ダッシュボードが注釈を検出し、Pod をメッシュとしてマークします。

これで、最初のアプリが Linkerd に正常に追加され、mTLS がすでに動作しています。

名前空間全体でLinkerdを有効にする

次のステップに進みましょう。 Mendix メッシュに名前空間を追加し、オペレーター、エージェント、アプリケーション間の接続を保護します。

以下のビデオに示すように、次のことが必要です。

1. Linkerdインジェクションのために名前空間全体（「mendix」と呼ばれる）に注釈を付ける
2. 構成を確認して、アノテーションが名前空間に追加されたことを確認します。

注: ポッドがメッシュに自動的に追加されない場合は、デプロイメントごとにスケールダウンおよびスケールアップすることをお勧めします。

• • kubectl スケール デプロイメント mendix-operator —replicas=0
  • kubectl スケール デプロイメント mendix-agent —replicas=0
  • 上記を繰り返してレプリカを追加します=1

やったー！これでゼロ トラスト ネットワーキングの目標に近づいてきました。開発者ポータルから新しいアプリケーションをデプロイし、メッシュに自動的に追加される様子を見てみましょう。

メッシュにNGINXイングレスを追加する

ほとんどの顧客設定では、 TLS終端 Kubernetes クラスター内にある Ingress コントローラーで構成されます。簡単に言えば、外部からの受信トラフィックが暗号化された状態で (TLS) Ingress サービスに到着し、暗号化されていない状態で (プレーンな http) Pod に提供されることを意味します。

ここでの最後のステップは、イングレスコントローラとネットワーク内のすべてのサービス間のmTLSを確保することです。 Mendix 名前空間。そのためには、次の操作が必要です。

• メッシュに NGINX Ingress コントローラーのデプロイメントを追加します。 指示に従ってください クラスターに NGINX をインストールした方法 (helm または YAML から) によって異なります。
• 必ず追加してください thenginx.ingress.kubernetes.io/service-upstream アノテーションを適切に使用して、コントローラーが Pod エンドポイントを使用せず、代わりにサービスのクラスター IP とポートを使用するようにします。

ここで、Nginx がメッシュに追加されると、ポッドへのすべてのトラフィックが mTLS を使用していることを確認します。

NGINXはメッシュ化されており、トラフィックを安全に送信しています Mendix Application

まとめ：

堅牢なサービス メッシュ アーキテクチャの重要性は強調しすぎることはありません。マイクロサービス環境内できめ細かな可視性、安全な通信、ポリシーの適用を提供できることは、データとシステムを保護する上で非常に重要です。

活用 Mendix プライベート クラウドと Istio および Linkerd とのシームレスな統合により、組織は俊敏性とセキュリティの調和を実現できます。 Mendixの迅速な開発機能は、サービス メッシュの厳格なセキュリティ対策を補完し、企業が防御態勢を損なうことなく革新を進めることを可能にします。

脅威が絶えず進化するこの時代において、サービスメッシュと Mendix プライベート クラウドは、情報セキュリティに対する将来を見据えたアプローチを体現しています。

メッシングを楽しんでください！