一方向および相互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 認証は、エンドユーザーの認証とコンピュータネットワーク上のデバイスの相互認証の両方に使用できます。
ユーザー認証
企業や他の組織は、従業員、請負業者、顧客などのエンドユーザーにデジタルクライアント証明書を配布できます。 これらのクライアント証明書は、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などの標準プロトコルへのアクセスにより、これらの資格情報の発行、更新、および取り消しが簡単になります。
SSL.comは、クライアント証明書の発行と管理のための複数のオプションを提供します。
- XNUMXつまたはいくつかの証明書のみを必要とする個人または組織が注文できます。 メール、クライアント、ドキュメントの署名証明書 SSL.comのアラカルト。
- SCEP、EST、CMPなどのプロトコルを使用して、会社所有のデバイスとBYOデバイスのクライアント証明書の登録と更新を自動化できます。
- 大量の証明書が必要なお客様には、卸売り割引をご利用いただけます。 再販業者および大量購入プログラム.
IoTデバイスの認証
相互 TLS 認証は、マシン間認証にも広く使用されています。 このため、モノのインターネット（IoT）デバイス向けの多くのアプリケーションがあります。 IoTの世界では、サーバー上の保護されたリソースにアクセスするために、「スマート」デバイスが安全でないネットワーク（インターネットなど）を介して自身を認証する必要がある場合が多くあります。
例：「スマート」サーモスタット
相互の簡単な例として TLS IoTについては、インターネットに接続された家庭用の「スマート」サーモスタットを設計しているメーカーを検討します。 顧客の自宅でインターネットに接続すると、製造元はデバイスが会社のサーバーとの間でデータを送受信できるようにします。これにより、顧客は会社のWebサイトのユーザーアカウントを介して自宅の温度条件とサーモスタット設定にアクセスできます。 /またはスマートフォンアプリ。 この場合、メーカーは次のことができます。
- 一意の暗号化キーペアとクライアント証明書を備えた各デバイスを発送します。 すべての通信はサーモスタットと会社のサーバー間で行われるため、これらの証明書は 個人的に信頼されている、証明書の寿命などのポリシーに追加の柔軟性を提供します。
- 一意のデバイスコードを提供する （シリアル番号やQRコードなど）顧客がスキャンするか、製造元のWebポータルまたはスマートフォンアプリでユーザーアカウントに入力して、デバイスを自分のアカウントに関連付けることができます。
デバイスがユーザーのWi-Fiネットワークを介してインターネットに接続されると、相互接続が開かれます TLS 製造元のサーバーとの接続。 サーバーはサーモスタットに対して自身を認証し、サーモスタットのクライアント証明書を要求します。これは、ユーザーがアカウントに入力した一意のコードに関連付けられています。
接続のXNUMXつのパーティ（サーバーとサーモスタット）が相互認証され、SSL /を使用してメッセージを送受信できるようになりました。TLS 次のようなアプリケーション層プロトコルでの暗号化 HTTPS およびMQTT。 ユーザーは、サーモスタットのデータにアクセスしたり、Webポータルアカウントまたはスマートフォンアプリで設定を変更したりできます。 XNUMXつのデバイス間で認証されていないメッセージやクリアテキストのメッセージが必要になることはありません。
SSL.comがIoTデバイスを保護し、相互にユーザーのセキュリティを向上させるのにどのように役立つかについて専門家と話す TLS、下のフォームに記入して送信してください。
