V12: 安全な通信
Last updated
Was this helpful?
Last updated
Was this helpful?
この章には、エンドユーザクライアントとバックエンドサービス間だけでなく、内部サービスとバックエンドサービス間でも、転送時のデータを保護するために導入すべき具体的なメカニズムに関する要件を含みます。
この章で推進される一般的な概念は以下のとおりです。
コンテンツの機密性に関わらず、TLS または強力な暗号を必要としている。
以下のような最新のガイダンスに従っている。
構成に関する勧告
優先アルゴリズムと暗号方式
最後の手段を除いて、脆弱または近い将来廃止予定のアルゴリズムや暗号方式を避けている。
非推奨または既知の安全でないアルゴリズムや暗号方式を無効にしている。
これらの要件を満たすために:
安全な TLS 構成に関する業界の推奨事項は、(多くの場合、既存のアルゴリズムや暗号方式の壊滅的な破綻が原因で) 頻繁に変更されるため、最新の状態に保ちます。
最新バージョンの TLS 構成レビューツールを使用して、優先順位とアルゴリズム選択を設定します。
構成を定期的にチェックして、安全な通信が常に存在し有効であることを確認します。
このドキュメントでは、一般的な原則とベストプラクティスを概説するだけでなく、 で暗号強度に関するより詳細な技術情報も提供しています。
安全な TLS 構成と最新のツールを使用して構成を定期的に確認します。ワイルドカード TLS 証明書の使用は本質的に安全ではありませんが、所有するすべての環境 (実稼働、ステージング、開発、テストなど) にわたって展開される証明書の侵害は、それを使用するアプリケーションのセキュリティ態勢の侵害につながる可能性があります。可能であれば、異なる環境での個別の TLS 証明書の適切な保護、管理、使用を採用する必要があります。
9.4.2
[9.1.3 から移動] TLS 1.2 や TLS 1.3 など、最新の推奨バージョンの TLS プロトコルのみが有効である。最新バージョンの TLS プロトコルを優先オプションにする。
1
v5.0.be-9.4.2
9.4.1
[修正, 9.1.2 から移動] 最新の推奨暗号スイートのみが有効であり、最も強力な暗号スイートが優先的に設定されている。L3 アプリケーションは前方秘匿性を提供する暗号スイートのみをサポートしなければならない。
2
v5.0.be-9.4.1
9.4.5
[追加] アプリケーションは、認証または認可に証明書 ID を使用する前に、mTLS クライアント証明書が信頼できることを検証している。
2
v5.0.be-9.4.5
9.4.3
[9.2.4 から移動] Online Certificate Status Protocol (OCSP) Stapling などの適切な証明書失効が有効かつ構成されている。
3
v5.0.be-9.4.3
9.4.4
[追加] Encrypted Client Hello (ECH) がサポートされており、アプリケーションの TLS 設定内で安全に構成されることで、TLS ハンドシェイクプロセス時に Server Name Indication (SNI) などの機密性の高いメタデータの開示を防いでいる。
3
v5.0.be-9.4.4
アプリケーションが公開する外部向けサービスに対するすべての HTTP トラフィックが、公的に信頼できる証明書により暗号化されて送信されることを確認します。
9.1.1
[修正, 1.9.1 をカバー] TLS がクライアントと外部向けの HTTP ベースのサービス間のすべての接続に使用されており、安全でない通信や非暗号化通信にフォールバックしない。
1
v5.0.be-9.1.1
9.1.4
[追加] 外部向けサービスが公的に信頼できる TLS 証明書を使用している。
1
v5.0.be-9.1.4
サーバ通信は HTTP だけではありません。他のシステムとの接続も安全でなければなりません。
9.2.2
[修正, 1.9.1 をカバー] 監視システム、管理ツール、リモートアクセス、SSH、ミドルウェア、データベース、メインフレーム、パートナーシステム、外部 API など、アプリケーションとのすべてのインバウンドおよびアウトバウンドの接続に、TLS などの暗号化プロトコルが使用されている。サーバは安全でないプロトコルや暗号化されていないプロトコルにフォールバックしてはいけない。
2
v5.0.be-9.2.2
9.2.6
[追加] TLS クライアントは TLS サーバと通信する前に受信した証明書を検証している。
2
v5.0.be-9.2.6
内部向けサービス間の HTTP トラフィックも暗号化されるべきであり、理想的には TLS を使用します。
9.3.1
[追加, 1.9.1 をカバー] アプリケーション内の HTTP ベースの内部サービス間のすべての接続に TLS または別の適切なトランスポート暗号化メカニズムが使用されており、安全でない通信や暗号化されていない通信にフォールバックしていない。
2
v5.0.be-9.3.1
9.3.2
[修正, 9.2.1 から移動, 1.9.2 をカバー] 内部サービス間の TLS 接続には信頼できる証明書が使用されている。内部生成証明書や自己署名証明書が使用されている場合、受け側のサービスは特定の内部 CA および特定の自己署名証明書のみを信頼するように構成する必要がある。それ以外はすべて拒否される。
2
v5.0.be-9.3.2
9.3.3
[修正, 2.2.5 から移動] システム内で通信するサービス (サービス内通信) は強力な認証を使用して、各エンドポイントが検証されていることを確保している。mTLS などの強力な認証方式を採用し、公開鍵インフラストラクチャとリプレイ攻撃に耐性のあるメカニズムを使用して、アイデンティティを確認する必要がある。マイクロサービスアーキテクチャの場合は、サービスメッシュを使用して証明書管理を簡素化し、セキュリティを強化することを検討する。
3
v5.0.be-9.3.3
詳しくは以下の情報を参照してください。
セクション 9.4 への準拠を達成する理想的な方法は や などのガイドを見直し、望ましいセキュリティレベルを得るために、既知で最新の TLS 評価ツールを使用することです。