相互 TLS (mTLS) 認証は、ユーザーと IoT デバイスの両方を認証するための安全なフレームワークを作成します。このガイドでは、m の実装について説明します。TLS クライアントとサーバー間の安全な双方向認証を保証します。
初期設定
相互の設定 TLS 簡単なプロセスに従います。まず、必要なサーバー証明書とクライアント証明書を生成します。次に、クライアント証明書を要求するようにサーバーを構成します。次に、クライアントに証明書を設定し、適切な証明書検証を実装します。最後に、接続をテストして、すべてが期待どおりに動作することを確認します。
一方向および相互SSL /TLS 認証
SSL /の定義機能のXNUMXつTLS プロトコルは、コンピュータネットワーク（インターネットなど）で匿名のパーティを認証する役割です。 公に信頼されているウェブサイトにアクセスしたとき SSL /TLS 証明書、ブラウザは、Webサイトの所有者がSSL.comなどの信頼できるサードパーティの認証局（CA）に対してそのドメイン名の制御を正常に実証したことを確認できます。 この検証が失敗した場合、Webブラウザはそのサイトを信頼しないように警告します。 ほとんどのアプリケーションでは、SSL /TLS この種の 一方向認証 サーバーからクライアントへ。 匿名クライアント（Webブラウザ）は、暗号化されたセッションをWebサーバーとネゴシエートします。Webサーバーは、公的に信頼されたSSL /を提示します。TLS 中に自分自身を識別する証明書 SSL /TLS 握手:
相互認証、両方のサーバー の三脚と SSL /のクライアントTLS セッションは認証され、可能であり、状況によっては非常に役立つ場合があります。 相互認証では、サーバーがハンドシェイク中に認証されると、サーバーは CertificateRequest クライアントへのメッセージ。 クライアントは、認証のためにサーバーに証明書を送信して応答します。
相互によるクライアント認証 TLS を含む証明書が必要です Client Authentication (1.3.6.1.5.5.7.3.2) 拡張キー使用法（EKU）がクライアントデバイスにインストールされています。 SSL.comのすべて メール、クライアント、ドキュメントの署名証明書 クライアント認証を含みます。
詳細な実装ガイド
相互理解 TLS
クラシックハット TLS サーバー認証と暗号化を提供しますが、相互 TLS さらに、双方にデジタル証明書の提示を義務付けています。この双方向の検証により、サーバーの信頼性が保証され、クライアント認証が可能になり、暗号化された通信チャネルが確立され、中間者攻撃が防止されます。その結果、機密性の高いアプリケーションや IoT デバイスの通信に適した、非常に安全な接続が実現します。
前提条件
実装を開始する前に、OpenSSLまたは同様の証明書管理ツールにアクセスできることを確認してください。Webサーバーがサポートしている必要があります。 TLS、または 認証局（CA） またはプライベート CA を作成する機能。クライアントは証明書ベースの認証もサポートする必要があります。
ステップ1: 証明書の生成と管理
まず、サーバーとクライアントの認証に必要な証明書を生成します。サーバー証明書の設定には、秘密鍵の作成が必要です。 証明書署名要求の生成、そして CA を使用して証明書に署名します。
# サーバーの秘密鍵を生成する
opensslの 属 -でる サーバーキー 2048
?
# サーバー証明書署名要求を作成する (CSR)
opensslの 必須 -新着 -キー サーバーキー -でる サーバー.csr
?
# CAでサーバー証明書に署名する
opensslの x509 -必須 -に サーバー.csr -CA ca.crt -CAkey ca.キー -CAcreateserial -でる サーバー.crt
クライアント証明書の場合も、同様のプロセスに従って一意の資格情報を作成します。
# クライアントの秘密鍵を生成する
opensslの 属 -でる クライアントキー 2048
?
# クライアントを作成する CSR
opensslの 必須 -新着 -キー クライアントキー -でる クライアント.csr
?
# クライアント証明書に署名する
opensslの x509 -必須 -に クライアント.csr -CA ca.crt -CAkey ca.キー -CAcreateserial -でる client.crt
ステップ 2: サーバー構成
サーバーは、クライアント証明書を要求して検証するように構成する必要があります。以下は、Nginx の構成例です。
{
聞く 443 SSL;
サーバーの名前 example.com;
?
ssl_certificate /パス/へ/ .crt;
ssl_certificate_key /パス/へ/ 。鍵;
ssl_クライアント証明書 /path/to/ca.crt;
ssl_verify_クライアント オン;
ssl_プロトコル TLSv1。2 TLSv1.3;
ssl_ciphers 高い：!aNULL:!MD5;
ssl_prefer_server_ciphers オン;
}
Apache サーバーの場合は、次の構成を使用します。
<VirtualHost *:443>
サーバーの名前 example.com
SSLエンジン on
SSL証明書ファイル /path/to/server.crt
SSL証明書キーファイル /path/to/server.key
SSLCAC証明書ファイル /path/to/ca.crt
SSL検証クライアント 必要とする
SSL 検証深度 1
ステップ3: クライアントの実装
ブラウザベースの認証では、クライアント証明書をブラウザの証明書ストアにインポートする必要があります。ブラウザごとにこのプロセスの処理方法は異なりますが、一般的にはセキュリティまたはプライバシー設定にオプションがあります。
IoT デバイスの場合、コードに証明書ベースの認証を実装する必要があります。以下は Python のリクエスト ライブラリを使用した例です。
import リクエスト
?
クライアント証明書 = ('クライアント.crt', 'クライアント.キー')
ca_cert = 'ca.crt'
?
応答 = リクエスト.取得する('https://example.com',
CERT=クライアント証明書,
確認する=ca_cert)
ステップ4: 証明書の検証
適切な証明書の検証はセキュリティにとって重要です。実装では、証明書チェーンの整合性を検証し、有効期限を確認し、失効ステータスを検証し、適切なキーの使用を保証する必要があります。実装例を次に示します。
from 暗号 import x509
from 暗号.危険物.バックエンド import デフォルトバックエンド
?
def 証明書を検証する(証明書パス):
開いた(証明書パス, 'rb') as 証明書ファイル:
証明書データ = 証明書ファイル.read()
CERT = x509.ロード_pem_x509_証明書(証明書データ, デフォルトバックエンド（））
if CERT.無効 < 日付時刻.日付時刻.今（）：
上げる 値エラー(「証明書の有効期限が切れています」)
試します:
キーの使用法 = CERT.エクステンション.クラスの拡張機能を取得する(x509.キー使用法)
if キーの使用法.値.デジタル署名:
上げる 値エラー(「証明書はデジタル署名には有効ではありません」)
以下は除く x509.エクステンション.拡張子が見つかりません:
上げる 値エラー(「必要なキー使用拡張が見つかりません」)
相互認証の使用例
相互 TLS 認証は、エンドユーザーの認証とコンピュータネットワーク上のデバイスの相互認証の両方に使用できます。ユーザー認証
企業や他の組織は、従業員、請負業者、顧客などのエンドユーザーにデジタルクライアント証明書を配布できます。 これらのクライアント証明書は、Wi-Fi、VPN、Webアプリケーションなどの企業リソースにアクセスするための認証要素として使用できます。 従来のユーザー名/パスワード資格情報の代わりに（または追加して）使用すると、相互 TLS には、いくつかのセキュリティ上の利点があります。- 相互 TLS 認証は、次のような戦術による資格情報の盗難に対して脆弱ではありません。 フィッシング詐欺. ベライゾンの 2020データ漏洩/侵害調査レポート データ漏えいのほぼ22分のXNUMX（XNUMX％）がフィッシングによるものであることを示しています。 フィッシングキャンペーンは、ユーザーのクライアント証明書の秘密鍵ではなく、Webサイトのログインパスワードなどの簡単に取得できる資格情報を対象としています。 フィッシングに対するさらなる防御として、SSL.comのすべて メール、クライアント、ドキュメントの署名 証明書には公的に信頼されたものが含まれます S/MIME 署名および暗号化された電子メール用。
- 相互 TLS 認証は、不十分なパスワードの衛生状態やパスワードに対するブルートフォース攻撃によって侵害されることはありません。 ユーザーに強力なパスワードの作成を要求することはできますが、50の異なるWebサイトで同じ「安全な」パスワードを使用していないこと、または付箋に書かれていることをどうやって知ることができますか？ A 2019 Google調査 52％のユーザーが複数のアカウントのパスワードを再利用し、13％のユーザーが同じパスワードを を アカウントの。
- クライアント証明書は明確な 信頼の連鎖、一元管理できます。 相互に TLS、どの認証局（CA）がユーザーの資格情報を発行したかの検証は、認証プロセスに直接組み込まれます。 SSL.comの オンライン管理ツール, SWS API、およびSCEPなどの標準プロトコルへのアクセスにより、これらの資格情報の発行、更新、および取り消しが簡単になります。
- XNUMXつまたはいくつかの証明書のみを必要とする個人または組織が注文できます。 メール、クライアント、ドキュメントの署名証明書 SSL.comのアラカルト。
- SCEP、EST、CMPなどのプロトコルを使用して、会社所有のデバイスとBYOデバイスのクライアント証明書の登録と更新を自動化できます。
- 大量の証明書が必要なお客様には、卸売り割引をご利用いただけます。 再販業者および大量購入プログラム.
セキュリティのベストプラクティス
強力なセキュリティには、単にmを実装するだけでは不十分です。TLS:
- 証明書が定期的に更新されるように自動証明書ローテーションを実装する
- 侵害された証明書を迅速に無効にするために証明書失効リストを維持する
- RSAキーには少なくとも2048ビットの強力なキーサイズを使用する
- 安全なものだけを受け入れるようにサーバーを設定する TLS バージョンと強力な暗号スイート
クライアントのセキュリティ戦略には、強力なアクセス制御による秘密キーの保護を含める必要があります。定期的なセキュリティ監査は、長期にわたってシステムの整合性を維持するのに役立ちます。
一般的な問題のトラブルシューティング
証明書チェーンの問題
mを実装する場合TLS、証明書チェーンの問題が発生する可能性があります。これは通常、次の原因によって発生します。
- 不完全な証明書チェーン
- 中間証明書が不適切にインストールされています
これらの問題を解決するには：
- トラストアンカーの設定が正しいことを確認する
- 必要な証明書がすべて揃っていることを確認する
接続の問題
接続の問題は多くの場合、次のことに関連しています。
- ファイアウォール設定のブロック TLS トラフィック
- 証明書の権限が正しくありません
トラブルシューティングするには：
- 証明書の名前が適切であることを確認する
- 意図した用途に適合していることを確認する
パフォーマンスに関する考慮事項
パフォーマンスの考慮は規模に応じて重要になります。パフォーマンスを最適化するには:
- 繰り返しのハンドシェイクのオーバーヘッドを削減するためにセッションキャッシュを実装する
- セキュリティとパフォーマンスのバランスが取れた効率的な暗号スイートを選択する
- 証明書検証プロセスを監視して、不要なオーバーヘッドが発生していないことを確認します。
結論
