Skip to content

Latest commit

 

History

History
82 lines (58 loc) · 8.07 KB

0x17-V9-Communications.md

File metadata and controls

82 lines (58 loc) · 8.07 KB

V9 安全な通信

管理目標

この章には、エンドユーザクライアントとバックエンドサービス間だけでなく、内部サービスとバックエンドサービス間でも、転送時のデータを保護するために導入すべき具体的なメカニズムに関する要件を含みます。

この章で推進される一般的な概念は以下のとおりです。

  • コンテンツの機密性に関わらず、TLS または強力な暗号を必要としている。
  • 以下のような最新のガイダンスに従っている。
    • 構成に関する勧告
    • 優先アルゴリズムと暗号化方式
  • 最後の手段を除いて、脆弱または近い将来廃止予定のアルゴリズムや暗号化方式を避けている。
  • 非推奨または既知のセキュアでないアルゴリズムや暗号化方式を無効にしている。

これらの要件を満たすために:

  • セキュアな TLS 構成に関する業界の推奨事項は、(多くの場合、既存のアルゴリズムや暗号の壊滅的な破綻が原因で) 頻繁に変更されるため、最新の状態に保ちます。
  • 最新バージョンの TLS 設定レビューツールを使用して、優先順位とアルゴリズム選択を設定します。
  • 設定を定期的にチェックして、セキュアな通信が常に存在し有効であることを確認します。

このドキュメントでは、一般的な原則とベストプラクティスを概説するだけでなく、付録 V で暗号強度に関するより詳細な技術情報も提供しています。

V1.9 通信ドキュメント

# 説明 L1 L2 L3 CWE
1.9.1 [削除, 9.1.1, 9.2.2, 9.3.1 と重複]
1.9.2 [削除, 9.2.3, 9.3.2 と重複]

V9.1 外部向けサービスとの HTTPS 通信

アプリケーションが公開する外部向けサービスに対するすべての HTTP トラフィックが、公的に信頼できる証明書により暗号化されて送信されることを確認します。

# 説明 L1 L2 L3 CWE
9.1.1 [修正] TLS がクライアントと外部向けの HTTP ベースのサービス間のすべての接続に使用されており、安全でない通信や非暗号化通信にフォールバックしない。 ✓ ✓ ✓ 319
9.1.2 [9.4.1 へ移動]
9.1.3 [9.4.2 へ移動]
9.1.4 [追加] 外部向けサービスが公的に信頼できる TLS 証明書を使用している。 ✓ ✓ ✓ 295

V9.2 一般的なサービス間通信セキュリティ

サーバ通信は HTTP だけではありません。他のシステムとの接続も安全でなければなりません。

# 説明 L1 L2 L3 CWE
9.2.1 [9.3.2 へ移動]
9.2.2 [修正] 監視システム、管理ツール、リモートアクセス、SSH、ミドルウェア、データベース、メインフレーム、パートナーシステム、外部 API など、アプリケーションとのすべてのインバウンドおよびアウトバウンドの接続に、TLS などの暗号化プロトコルが使用されている。サーバは安全でないプロトコルや暗号化されていないプロトコルにフォールバックしてはいけない。 ✓ ✓ 319
9.2.3 [削除, スコープ外]
9.2.4 [9.4.3 へ移動]
9.2.5 [7.2.6 へ移動]
9.2.6 [追加] TLS クライアントは TLS サーバと通信する前に受信した証明書を検証している。 ✓ ✓ ✓

V9.3 内部サービス間の HTTPS 通信

内部向けサービス間の HTTP トラフィックも暗号化されるべきであり、理想的には TLS を使用します。

# 説明 L1 L2 L3 CWE
9.3.1 [追加] アプリケーション内の HTTP ベースの内部サービス間のすべての接続に TLS または別の適切なトランスポート暗号化メカニズムが使用されており、安全でない通信や暗号化されていない通信にフォールバックしていない。 ✓ ✓ 319
9.3.2 [修正, 9.2.1 から移動] 内部サービス間の TLS 接続には信頼できる証明書が使用されている。内部で生成された証明書または自己署名証明書を使用する場合、受け側のサービスは特定の内部認証局や特定の自己署名証明書のみを信頼するように構成し、それ以外の証明書はすべて拒否する。 ✓ ✓ 295
9.3.3 [修正, 2.2.5 から移動] システム内で通信するサービス (サービス内通信) は強力な認証を使用して、各エンドポイントが検証されていることを確保している。mTLS などの強力な認証方式を採用し、公開鍵インフラストラクチャとリプレイ攻撃に耐性のあるメカニズムを使用して、アイデンティティを確認する必要がある。マイクロサービスアーキテクチャの場合は、サービスメッシュを使用して証明書管理を簡素化し、セキュリティを強化することを検討する。 ✓ 295

V9.4 一般的な TLS セキュリティガイダンス

安全な TLS 構成と最新のツールを使用して構成を定期的に確認します。ワイルドカード TLS 証明書の使用は本質的に安全ではありませんが、所有するすべての環境 (実稼働、ステージング、開発、テストなど) にわたって展開される証明書の侵害は、それを使用するアプリケーションのセキュリティ態勢の侵害につながる可能性があります。可能であれば、異なる環境での個別の TLS 証明書の適切な保護、管理、使用を採用する必要があります。

# 説明 L1 L2 L3 CWE
9.4.1 [修正, 9.1.2 から移動] 最新の推奨暗号スイートのみが有効であり、最も強力な暗号スイートが優先的に設定されている。L3 アプリケーションは前方秘匿性を提供する暗号スイートのみをサポートしなければならない。 ✓ ✓ ✓ 326
9.4.2 [9.1.3 から移動] TLS 1.2 や TLS 1.3 など、最新の推奨バージョンの TLS プロトコルのみが有効である。最新バージョンの TLS プロトコルを優先オプションにする。 ✓ ✓ ✓ 326
9.4.3 [9.2.4 から移動] Online Certificate Status Protocol (OCSP) Stapling など証明書の失効を適切にチェックできる機能を設定し、有効にしている。 ✓ ✓ 299
9.4.4 [追加] Encrypted Client Hello (ECH) がサポートされており、アプリケーションの TLS 設定内で適切に構成されることで、TLS ハンドシェイクプロセス時に Server Name Indication (SNI) などの機密性の高いメタデータの開示を防いでいる。 ✓
9.4.5 [追加] アプリケーションは、認証または認可に証明書 ID を使用する前に、mTLS クライアント証明書が信頼できることを検証している。 ✓

参考情報

詳しくは以下の情報を参照してください。