はじめに
システム間の認証に自己証明書を利用した相互認証で認証を行っている場合は多いいと思います。
今回は、Anpoint PlatformのAPIプロキシとバックエンドシステム間で自己証明書を利用した相互認証が可能か実現性を調査しましたので説明します。
概要
相互認証の概要は以下の通です。
証明書ベースの相互認証の仕組み
証明書ベースの相互認証の仕組みは以下の通りです。
考慮ポイント
考慮ポイントは以下の通りです。
- 相互認証ではTLS v1.2 プロトコルの指定は必須です。
- APIプロキシ側のSSLキーストアとSSLトラストストアの作成はPCから作成できます。
- EC2のインスタンスタイプは、t2.small以上が必要です。（メモリ1.4GB必要のため）
- 相互認証を求めるバックエンドシステムの代わりにEC2上にMule4 standaloneを構築して利用しました。
- クライアントのSSLトラストストアに直接サーバ証明書を格納することで信頼の連鎖を確立しました。
- SSLキーストアとSSLトラストストで利用できるファイル形式は、PEM、JKS、PKCS12、JCEKSが利用可能です。
相互認証検証環境構築手順
証明書ベースの双方向認証環境構築手順
| No. | タスク | タスク |
|---|---|---|
| 1 | EC2 | EC2にMule 4 standaloneの構築 |
| 2 | 開発端末 | SSLキーストアとSSLトラストストアの作成 |
| 3 | 開発端末 | Muleアプリケーションの相互認証設定 |
| 4 | 開発端末 | Muleアプリケーションのエクスポート |
| 5 | EC2 | EC2にMuleアプリケーションの配置 |
| 6 | Secrets Manager | TLSコンテキストの設定 |
| 7 | API Manager | Endpoint With Proxyの設定 |
EC2にMule 4 standalone環境の構築手順
EC2にMule 4 standalone環境を構築する手順は以下の通りです。
// インスタンスタイプ : t2.small（メモリ2GiB）のEC2インスタンスの作成
$sudo apt-get update
$sudo apt-get install openjdk-8-jdk
$sudo apt-get install zip unzip
$export MULE_HOME=/opt/mule-enterprise-standalone-4.3.0
$sudo $MULE_HOME/bin/mule install
$sudo $MULE_HOME/bin/mule start
// Muleアプリケーションの配置（Muleアプリケーションの相互認証設定完了後）
$sudo mv /home/ubuntu/{Muleアプリケーション}.jar /opt/mule-enterprise-standalone-4.3.0/apps/"
SSLキーストアとSSLトラストストアの作成
SSLキーストアとSSLトラストアの作成手順は以下の通りです。
// 1. サーバキーストア作成
$keytool -alias mule-server01 -genkeypair -keystore keydir/server-keystore.jks -dname "CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown" -keypass password -storepass password -keyalg RSA -sigalg SHA1withRSA -keysize 2048 -ext SAN=DNS:{パブリックDNS（重要）},IP:{パブリックIP} -validity 9999
// 2. サーバ証明書作成
$keytool -export -alias mule-server01 -keystore keydir/server-keystore.jks -file keydir/server.crt
// 3. クライアントキーストア作成
$keytool -genkey -alias mule-client01 -keyalg RSA -keystore keydir/client-keystore.jks -dname "CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown" -keypass password -storepass password
// 4. クライアント証明書作成
$keytool -export -alias mule-client01 -keystore keydir/client-keystore.jks -file keydir/client.crt
// 5. クライアントトラストストアにインポート
$keytool -import -alias mule-client01 -keystore keydir/client-truststore.jks -file keydir/client.crt
$keytool -import -alias mule-server01 -keystore keydir/client-truststore.jks -file keydir/server.crt
// 6. サーバトラストストアにインポート
$keytool -import -alias mule-client01 -keystore keydir/server-truststore.jks -file keydir/client.crt
// 7. POSTMAN用クライアント証明書作成
$keytool -importkeystore -srckeystore keydir/client-keystore.jks -srcstoretype JKS -deststoretype PKCS12 -destkeystore keydir/client-keystore.p12
// 8. トラストストアのキーストアエントリ内容の確認
$keytool -list -keystore keydir/server-truststore.jks
$keytool -list -keystore keydir/client-truststore.jks"
Muleアプリケーションの相互認証設定
Muleアプリケーションの相互認証の設定は以下の通りです。
Endpoint With Proxy設定
Endpoint With Proxyの設定は以下の通りです。
トラブルシューティング（１）
Endpoint With Proxyのログに下記のエラーが出力された場合の原因と対策をは以下の通りです。
トラブルシューティング（２）
Cloudhubに相互認証を設定したアプリケーションやAPIプロキシーをデプロイした場合にエラーが発生します。Muleの回答では、Cloudhubにデプロイは可能だが共通ロードバランサーの利用は不可で、Workerに直接アクセスすれば利用できるが、サーバ側の相互認証を利用する場合はDLBが推奨とのお話です。
POSTMANからの確認方法
POSTMANからの確認方法は以下の通りです。
最後に
いかがだったでしょうか？
MuleSoftのAPIProxyは、自己証明書で相互認証を要求するバックエンドシステムと認証できることが分かりました。
構想段階など早い段階で考慮しておくべきポイントを明確にできることはいいですね。では