相互認証
相互認証 とは何ですか?
相互認証通信する双方(クライアントとサーバー、または 2 つのサービス)がデータ交換前に互いの身元を暗号学的に証明する認証方式。
相互認証(双方向認証)は、サーバーがクライアントに対して自分を証明するだけでなく、両端が互いの身元を検証することを求めます。現在主流の実装は TLS 1.3 を扱う RFC 8446 で規定される mutual TLS(mTLS)で、双方が X.509 証明書を提示し、プライベート CA で検証します。他には Kerberos の AP-REQ/AP-REP、SSH のホスト+鍵認証、証明書ベースの IPsec IKEv2、attestation を含む FIDO2/WebAuthn セレモニーなどがあります。Istio、Linkerd、Consul などのサービスメッシュや、Google BeyondCorp に代表されるゼロトラスト構成では、すべてのワークロード間呼び出しを短命な SPIFFE ID で認証することが標準です。なりすまし、中間者攻撃、不正サービスの抑止に寄与します。
● 例
- 01
Kubernetes クラスタ内の全マイクロサービス間で mTLS を強制する Istio サービスメッシュ。
- 02
OAuth トークンに加え、銀行のプライベート CA が発行したクライアント証明書を必須とする銀行 API。
● よくある質問
相互認証 とは何ですか?
通信する双方(クライアントとサーバー、または 2 つのサービス)がデータ交換前に互いの身元を暗号学的に証明する認証方式。 サイバーセキュリティの ID とアクセス カテゴリに属します。
相互認証 とはどういう意味ですか?
通信する双方(クライアントとサーバー、または 2 つのサービス)がデータ交換前に互いの身元を暗号学的に証明する認証方式。
相互認証 はどのように機能しますか?
相互認証(双方向認証)は、サーバーがクライアントに対して自分を証明するだけでなく、両端が互いの身元を検証することを求めます。現在主流の実装は TLS 1.3 を扱う RFC 8446 で規定される mutual TLS(mTLS)で、双方が X.509 証明書を提示し、プライベート CA で検証します。他には Kerberos の AP-REQ/AP-REP、SSH のホスト+鍵認証、証明書ベースの IPsec IKEv2、attestation を含む FIDO2/WebAuthn セレモニーなどがあります。Istio、Linkerd、Consul などのサービスメッシュや、Google BeyondCorp に代表されるゼロトラスト構成では、すべてのワークロード間呼び出しを短命な SPIFFE ID で認証することが標準です。なりすまし、中間者攻撃、不正サービスの抑止に寄与します。
相互認証 からどのように防御しますか?
相互認証 に対する防御は通常、上記の定義で述べたとおり、技術的統制と運用上の実践を組み合わせます。
相互認証 の別名は何ですか?
一般的な別名: 双方向認証, ミューチュアル TLS, mTLS。
● 関連用語
- network-security№ 1159
TLS(トランスポート層セキュリティ)
IETF が標準化した暗号プロトコルで、ネットワーク上の 2 つのアプリケーション間の通信に機密性・完全性・認証を提供する。
- network-security№ 157
証明書ピン留め
期待する証明書や公開鍵をアプリ側にハードコードし、それと一致しない TLS 接続を拒否することで、不正に発行された CA 証明書を無効化する手法。
- network-security№ 878
公開鍵基盤(PKI)
ポリシー・ソフトウェア・ハードウェア・信頼された機関の総体で、身元と公開鍵を結びつけるデジタル証明書を発行・配布・検証・失効させる。
- network-security№ 156
認証局(CA)
公開鍵をドメイン名や組織などの検証済みの身元と結びつけ、デジタル証明書を発行・署名する信頼された機関。
- identity-access№ 584
Kerberos
対称鍵暗号と信頼された鍵配布センターを用いたチケットベースのネットワーク認証プロトコルで、サービス横断のシングルサインオンを安全に実現する。
- identity-access№ 076
認証
アクセス権を与える前に、利用者・端末・サービスが本当に名乗っているとおりの実体であることを確認するプロセス。