Flex Gateway新着情報
Governance新着情報
Monitoring API ManagerTLS は、Mule アプリケーションの通信セキュリティを確保する暗号化プロトコルです。TLS には、認証キーをエクスチェンジし、データを暗号化し、メッセージの整合性を保証するための多くの方法があります。このトピックでは、Mule が TLS をどのようにサポートするか、そして Mule アプリケーションで TLS をどのように設定するかについて説明します。
TLS との互換性は、Mule デプロイメントモデルと TLS バージョンによって異なります。
TLS バージョン | オンプレミス | CloudHub | Anypoint Runtime Fabric |
---|---|---|---|
1.3 |
TLS 1.3 をサポートする JDK 上で Mule を実行する場合にサポートされますが、デフォルトでは有効化されていません |
このデプロイメントモデルでホストされている Mule アプリケーションでサポートされます |
TLS 1.3 をサポートする JDK 上で Mule を実行する場合にサポートされ、有効化されます |
1.2 |
すべてのデプロイメントモデルでサポートされ、有効化されます |
||
1.1 |
すべてのデプロイメントモデルでサポートされ、有効化されます |
tls:context
要素は、TLS をサポートするすべてのコネクタで使用します。たとえば、TLS は HTTP (サーバーとクライアント)、FTPS (クライアント)、メール (クライアント)、またはソケット (クライアント) などのコネクタで設定できます。
コネクタで TLS がサポートされる場合、Studio には次のいずれかが表示されます。
|
TLS 対応のサーバーには、非公開キーと公開証明書が含まれます。
非公開キーはサーバーの外部には送信されません。
公開証明書は TLS 経由で公開されます。
TLS 対応クライアントは、自身が保管する信頼済みの証明書を使用して公開証明書を検証することで、サーバーが信頼できるかどうかを確認します。
Mule 4 で TLS 通信セキュリティを使用するには、証明書と非公開キーをキーストアファイルにインポートします。トラストストアファイルは、慣例として信頼済みのサーバー公開証明書のみが格納されるキーストアでもあります。
標準 JRE 配布には、デフォルトの Java トラストストアはありますが、デフォルトの Java キーストアはありません。自身のキーストアを TLS コンテキストに追加してください。すでにクライアントアプリケーション用に企業の証明書があれば、新たに作成する必要はありません。これらの証明書の多くは JRE トラストストアでも使用できるため、その場合は TLS コンテキストでのセットアップは不要です。
証明書は、よく知られた証明書機関 (CA) が生成するか、またはユーザーが外部承認なしでローカルに証明書 (自己署名証明書) を生成することができます。トラストストアには、サーバーから提供された証明書をクライアントが検証するために使用する信頼済みの CA があります。
Mule 設定の tls:trust-store
要素と tls:key-store
要素は、特定の証明書とキーを参照しますが、tls:trust-store
の値を指定しないと、Mule はデフォルトの Java トラストストアを参照します。Java を更新するとデフォルトのトラストストアも更新されますので、よく知られた CA 証明書を最新に保つために、定期的な更新をお勧めします。
トラストストアとキーストアは、クライアントとサーバーのどちらで使用するかによってコンテンツが異なります。
サーバー用: トラストストアには信頼済みのクライアントの証明書、キーストアにはサーバーの非公開キーと公開キーが格納されています。
クライアント用: トラストストアには信頼済みのサーバーの証明書、キーストアにはクライアントの非公開キーと公開キーが格納されています。
キーストアとトラストストアの両方を追加すると、相互認証とも呼ばれる両方向の TLS 認証を実装できます。
キーストアには 1 つまたは 2 つのパスワードがあります。
password
はキーストアファイル全体にアクセスします。
keyPassword
は、キーストアにあるサーバーの非公開キーにアクセスします。
tls:context
に空白のトラストストアが定義されている場合は、JVM のデフォルト値 (通常は、すべての主要証明機関の証明書が格納されたトラストストア) が使用されます。次のシナリオを考えてみます。
トラストストアがインラインで定義されている場合:
<tls:context name> <tls:trust-store /> </tls:context>
トラストストアがグローバル要素を使用して定義されている場合:
<tls:context name="example"> <tls:trust-store /> </tls:context>
クライアントが接続しようとしているサーバーからの証明書を必要とする場合は、tls:trust-store
要素を追加します。path
には、信頼済みのサーバーの証明書が格納されているトラストストアファイルの場所を設定します。
サーバーがクライアントからの証明書を検証する場合は、tls:key-store
要素に、クライアントの非公開/公開キーが格納されたキーストアファイルの場所が設定された path
を組み合わせる必要があります。
設定の手順は、「Mule 4 での TLS の設定」を参照してください。
tls:context
には、HTTPS などのセキュアな接続を使用して要求をリッスンする tls:key-store
要素を指定する必要があります。path
には、サーバーの非公開/公開キーが格納されているキーストアファイルの場所を設定します。
サーバーがクライアントからの証明書を検証する必要がある場合は、tls:trust-store
要素を追加し、信頼済みのクライアントの証明書が格納されたトラストストアファイルの場所を path
に設定します。
Mule は、多くのキーストア種別をサポートします。例:
JCEKS
PKCS12
JKS
キーストア種別は JRE に指定します。
Mule アプリケーション用に TLS を完全に設定するための手順は次の通りです。
Oracle の Java keytool を使用してキーストアとトラストストアを生成します。
標準 JDK 配布には、デフォルトではキーストアが含まれていないため、keytool
を使用してキーストアおよび証明書を生成します。生成したキーストアには、非公開キーと公開証明書が格納されます。この証明書は自己署名であるため、クライアントと公開証明書を共有するまでは、クライアントには信頼されません。
Java 8 を使用してキーストアを生成します。別の JDK バージョンを使用すると非互換のキーストアが生成され、Mule アプリケーションがキーストアを読み込もうとすると無効なキーストア形式ランタイムエラーが発生します。
次の手順に従い、キーストアを生成して自己署名証明書をエクスポートします。
サーバーの証明書を公開するキーストアを生成します。
たとえば、次のいずれかのコマンドを実行します。
keytool -genkey -keyalg RSA -alias <key-alias> -keystore <keystore-name>.jks keytool -genkey -alias <key-alias> -keyalg RSA -keystore <keystore-name>.jks -storepass <password>
<key-alias>
は選択した一意の別名に置き換えます。
<password>
は選択したパスワードに置き換えます。
<keystore-name>
はキーストアに使用する名前に置き換えます。
必要に応じて、-keyalg RSA
の代わりに -keyalg EC
を指定して、暗号化アルゴリズムを ECDSA に設定できます。
暗号化アルゴリズムを指定しない場合、ツールではデフォルトで DSA が使用されます。DSA には TLS 1.2 との互換性がないため、Mule アプリケーションで HTTPS 要求を受信すると SSL ハンドシェイクが失敗します。 |
ツールの要求メッセージに応答します。応答例:
Enter keystore password: mule123 Re-enter new password: mule123
入力画面に対して他の値を入力します。目的の値を入力します。応答例:
What is your first and last name? [Unknown]: max What is the name of your organizational unit? [Unknown]: MuleSoft What is the name of your organization? [Unknown]: MuleSoft Inc What is the name of your City or Locality? [Unknown]: San Francisco What is the name of your State or Province? [Unknown]: CA What is the two-letter country code for this unit? [Unknown]: 01
次の入力画面に対して yes
と入力します。
Is CN=max, OU=MuleSoft, O=MuleSoft Inc, L=San Francisco, ST=CA, C=01 correct? [no]: yes
次の入力画面に応答します。たとえば、RETURN キーを押して同じパスワードを使用します。
Enter key password for <key-alias> (RETURN if same as keystore password):
公開キーを認証する自己署名証明書をエクスポートするために次のコマンドを入力します。
keytool -export -alias <key-alias> -keystore <keystore-name>.jks -file <certificate-name>.cer
<key-alias>
は前のステップで使用したのと同じ値に置き換えます。
<keystore-name>
は前のステップで使用したのと同じ値に置き換えます。
<certificate-name>
は証明書に使用する名前に置き換えます。
証明書に関連付けられたキーストア用にセットアップしたパスワードを入力します。
Enter keystore password: mule123
認証機関 (CA) から証明書への署名を受けるには、次の手順に従います。
証明書を標準 CSR 形式でエクスポートします。そのためには、次のコマンドを実行できます。
keytool -certreq -keystore <keystore-name>.jks -alias <key-alias> -file <certificate-name>.csr
<key-alias>
は前のステップで使用したのと同じ値に置き換えます。
<keystore-name>
は前のステップで使用したのと同じ値に置き換えます。
<certificate-name>
は証明書署名要求ファイルに使用する名前に置き換えます。
前のステップで生成された CSR ファイルを認証機関に送信し、手順に従って署名を取得します。
CA の署名を取得したら、次のコマンドを使用して署名済みの証明書ファイルをインポートできます。
keytool -import -keystore <keystore-name>.jks -alias <cert-alias> -file <signed_certificate_file>
<cert-alias>
は目的の新しい値に置き換えます。定義した別名を既存のキーにリンクさせないでください。リンクさせるとプロセスが失敗します。
<keystore-name>
は前のステップで使用したのと同じ値に置き換えます。
<signed_certificate_file>
は認証機関から受信した署名済み証明書の名前に置き換えます。
証明書を標準 PEM 形式でエクスポートします。最初にキーストア種別を確認してから証明書をエクスポートします。
keytool -list -v -keystore <keystore-name>.jks
openssl <keystore-type> -in <keystore-name>.jks -out <pem-name>.key.pem -nocerts -nodes openssl <keystore-type> -in <keystore-name>.jks -out <pem-name>.crt.pem -nocerts -nodes
<keystore-type>
はキーストア種別の形式 (PKCS12 など) で新しい目的の値に置き換えます。
<keystore-name>
はキーストアに使用する名前に置き換えます。
<pem-name>
は PEM ファイルに使用する名前に置き換えます。
標準 JRE 配布には、いくつかの主要証明機関 (CA) の証明書が格納されたデフォルトのトラストストアがあり、デフォルトで tls:trust-store 要素で使用されますが、より強力なセキュリティが必要な場合や、自己署名証明書を使用する場合には、新たにトラストストアを作成できます。
トラストストアは Oracle Java keytool で作成します。
クライアントは、信頼の連鎖 (chain of trust) が確立されることでサーバーを信頼します。信頼の連鎖は、クライアントとサーバーの間で直接 (クライアントのトラストストアにサーバーの証明書が格納されることで) 確立されるか、またはクライアントのトラストストアに証明書が格納されている署名 CA 経由で確立されます。信頼の連鎖が確立されていないと、接続が失敗します。自己署名証明書を使用する場合は、トラストストアを定義する必要があります。
Mule アプリケーションで TLS を有効にするには、次の 3 つの方法のいずれかを使用して Mule XML 設定ファイルで tls:context
要素を設定します。
どの方法を使用する場合でも、[Edit XML to Configure TLS]の情報を参照して、tls:context
の属性がどのように機能するのかを理解しておくことをお勧めします。
tls:context
要素は、Mule アプリケーションで TLS 通信を定義します。特別な要件がない限り、TLS はグローバルに設定して、HTTPS のリスンや送信といった特定の用途に適用してください。
tls:context
要素は、クライアント側とサーバー側の両方から使用できる TLS の設定を定義します。この要素は、他のモジュールの設定オブジェクトから参照したり、いずれかのオブジェクトのネストされた要素として定義したりすることができます。
ネストされた要素を最低 1 つは含めます (key-store と trust-store)。
<tls:context name="customContext">
<tls:trust-store path="trustStore" password="mulepassword"/>
<tls:key-store path="clientKeystore" keyPassword="mulepassword" type="pkcs12"
password="mulepassword"/>
</tls:context>
tls-context
要素の省略可能な属性プロトコルと暗号化スイートを指定して有効にすることができます (省略可能)。
enabledProtocols
: グローバル TLS 設定のプロトコル
enabledCipherSuites
: グローバル TLS 設定の暗号化スイート
省略可能: プロトコルと暗号化スイートの指定で説明するように、これらの値は、グローバル TLS 設定で何も指定されていないか、またはこれらの値がグローバル TLS 設定で有効化されている場合に使用されます。
trust-store
要素の属性path
を指定する場合は、password
属性が必要です。そうでない場合は省略可能です。
path
: トラストストアが格納されているファイルへのパス
type
: トラストストアの種別。デフォルトは JKS
password
: トラストストアのパスワード (path
を指定した場合は必須)
algorithm
: トラストストアが使用するアルゴリズム。デフォルトは SunX509
insecure
: トラストストアを検証するかどうかを決定するブール値。true
に設定すると検証は行われません。デフォルト値は false
です。
insecure を true に設定すると、接続が攻撃に対して脆弱になります。この設定は、プロトタイプ開発やテストにおいてのみ使用してください。本番環境では絶対に使用しないでください。
|
Design Center を使用してアプリケーション用に TLS を設定できます。たとえば、HTTP リスナー用に TLS を設定する手順は次の通りです。
Design Center にログインします。
プロジェクトを開きます。
HTTP リスナーを開きます。
[Configuration (設定)] タブで [Edit (編集)] をクリックします。
[TLS] タブで、上記の TLS 設定項目を設定します。
省略可能: プロトコルと暗号化スイートの指定の説明に従って、[Enabled Protocols (有効化されたプロトコル)] 項目と [Enabled Cipher Suites (有効化された暗号化スイート)] 項目を設定します (省略可能)。
設定内容を保存してテストします。
Anypoint Studio (Studio) を使用してアプリケーション用に TLS を設定できます。たとえば、HTTP リスナー用に TLS を設定する手順は次の通りです。
Studio Center を開きます。
プロジェクトを開きます。
HTTP リスナーを開きます。
[General (一般)] タブで、既存の設定を選択するか、または新しい設定を作成します。
[HTTP Listener config (HTTP リスナーの設定)] ダイアログで、[TLS] タブを選択します。
[TLS] タブの [TLS Configuration type (TLS 設定種別)] で [Edit Inline (インライン編集)] を選択して、値を入力します。
省略可能: プロトコルと暗号化スイートの指定の説明に従って、[Advanced (詳細)] セクションの [Enabled Protocols (有効化されたプロトコル)] 項目と [Enabled Cipher Suites (有効化された暗号化スイート)] 項目を設定します (省略可能)。
設定内容を保存してテストします。
2 つのシステムの間で TLS 通信が行われると、使用するプロトコルと暗号化スイートがネゴシエーションによって決定します。必要に応じて、管理者が使用するプロトコルと暗号化スイートを指定して、アプリケーション開発者がそれらを tls:context
で指定することができます。
使用するプロトコルと暗号化スイートは、Mule Runtime と各アプリケーションで有効化しておく必要があります。プロトコルと暗号化スイートが両方の場所で有効化されていないと、Java 環境のデフォルトのプロトコルと暗号化スイートが使用されます。 |
Mule Runtime でプロトコルと暗号化スイートを設定する手順は次の通りです。
Mule 管理者は、$MULE_HOME
の下にある /conf
ディレクトリを編集します。$MULE_HOME
は、Mule がインストールされているディレクトリを参照します。例: /opt/mule-4.0
。暗号化スイートとプロトコルを指定するための適切なファイルを選択します。
tls-default.conf
は、Mule が Federal Information Processing Standards (FIPS) セキュリティモードで動作するように設定されていない場合に使用します。
tls-fips140-2.conf
Mule が FIPS セキュリティモードで動作するように設定されている場合に使用します。
関連するファイルを開き、リストの項目をコメントまたはコメント解除することで、使用する暗号化スイートと TLS プロトコルを手動で設定します。これらのファイルを編集しないと、設定されているセキュリティマネージャーが Mule アプリケーション用の暗号化スイートとプロトコルを選択します。
これらの設定ファイルで管理者が設定したプロトコルと暗号化スイートのリストは、アプリケーション開発者がそれぞれの tls:context
要素で指定する内容によってローカルに制約できます。アプリケーション開発者は、tls:context
要素の設定値またはデフォルト値のサブセットを TLS で使用するように指定します。プロトコルと暗号化スイートは、tls:context
要素の enabledProtocols
と enabledCipherSuites
で指定します。
tls:context
要素では、Mule グローバル TLS 設定ファイルで指定されているプロトコルまたは暗号化スイート、またはデフォルトのみを参照できます。tls:context
で、Mule アプリケーション用の enabledProtocols
と enabledCipherSuite
を default
に設定します。これらの値を設定すると、TLS は次のプロトコルと暗号化スイートを使用します。
グローバル TLS 設定が存在する場合は、指定されているプロトコルと暗号化スイート
グローバル TLS 設定が存在しない場合は、Java 環境のデフォルト
暗号化スイート名は長くなることがあり、XML コードが読みづらくなります。読みやすくするためには、これらの名前を Mule プロジェクトの外部プロパティファイルに格納します。そして、プロパティを参照します。次に例を示します。
<tls:context name="serverTlsContext" enabledCipherSuites="${myCipherSuites}" >
time curl -i -k --cert ./<pem-name>.crt.pem --cert-type PEM --key ./<pem-name>.key.pem https://<anypoint-address>:<anypoint-port>
<pem-name>
は定義された値名に置き換えます。
<anypoint-address>
は Anypoint Platform によって定義された値名に置き換えます。
<anypoint-port>
は Mule アプリケーションで定義された値名に置き換えます。
TLS は、クライアントまたはサーバー用の Mule XML 設定ファイルでセットアップできます。
次の例では、トラストストアをセットアップすることで FTPS クライアントのセキュリティを確保しています。
<ftps:config name="ftps">
<ftps:connection username="anonymous" password="password" host="localhost" port="21" workingDir="/dev">
<tls:context >
<tls:trust-store path="trustStore" password="mulepassword" />
</tls:context>
</ftps:connection>
</ftps:config>
次の例では、キーストアをセットアップすることで HTTP リスナーのセキュリティを確保しています。
<http:listener-config name="nestedConfig">
<http:listener-connection protocol="HTTPS" host="localhost" port="8081">
<tls:context>
<tls:key-store path="tls/ssltest-keystore.jks" keyPassword="changeit" password="changeit"/>
</tls:context>
</http:listener-connection>
</http:listener-config>
次の例では、HTTP リスナー用に両方向認証 (相互認証) をセットアップしています。
<http:listener-config name="nestedConfig">
<http:listener-connection protocol="HTTPS" host="localhost" port="8081">
<tls:context>
<tls:trust-store path="tls/ssltest-cacerts.jks" password="changeit"/>
<tls:key-store path="tls/ssltest-keystore.jks" keyPassword="changeit" password="changeit"/>
</tls:context>
</http:listener-connection>
</http:listener-config>
次の例では、insecure
プロパティを使用して、プロトタイプ作成と開発で検証を無効化しています。
insecure は、本番環境では使用しないでください。
|
<tls:context>
<tls:trust-store path="tls/ssltest-cacerts.jks" password="changeit" insecure="true"/>
</tls:context>
次の例では、Mule 管理者がグローバル TLS 設定で何も指定していないか、または暗号化スイートとプロトコルをここで指定できるように有効化してあるという前提で、アプリケーションでプロトコルと暗号化スイートを有効化しています。
<tls:context name="tlsClientContext" enabledProtocols="TLSv1.2" enabledCipherSuites="TLS_DHE_DSS_WITH_AES_128_CBC_SHA256">
<tls:trust-store path="tls/trustStore" password="mulepassword"/>
</tls:context>