Azure App Service や API Management などのアプリケーションへのトランスポート層セキュリティ (TLS) を計画して実装する

トランスポート層セキュリティ (TLS) は、暗号化、認証、およびデータの整合性を提供することで、ネットワーク経由の通信をセキュリティで保護するように設計された暗号化プロトコルです。 クライアントとサーバーの間でセキュリティで保護されたハンドシェイクを確立し、暗号スイートをネゴシエートし、信頼された証明機関によって発行された証明書を検証することで機能します。 このプロセスにより、資格情報やアプリケーション データなどの機密情報が暗号化された形式で送信され、転送中の傍受や改ざんから保護されます。 TLS は複数のバージョンで進化し、TLS 1.2 と TLS 1.3 では、以前のイテレーションと比較して、より強力な暗号化、より高速なハンドシェイク、およびプライバシーの強化が提供されました。

Azure のコンテキストでは、App Service、API Management、Azure Storage、SQL Database などのサービス全体でデータを保護する上で TLS が重要な役割を果たします。 Azure では、転送中の暗号化を確保するためにすべての接続に TLS を適用し、中間者攻撃などのリスクを軽減します。 最新の TLS バージョン (1.2 以降) が必要です。 Azure は業界のセキュリティ標準に準拠し、進化する脅威に対する回復性を強化する Perfect Forward Secrecy や認証済み暗号化などの機能を提供します。 新しいバージョンの TLS は、お客様のデータを保護するだけでなく、規制要件への準拠を確保し、TLS を Azure のセキュリティ体制の基本コンポーネントにします。

アプリケーションに対するトランスポート層セキュリティの機能

トランスポート層セキュリティ (TLS) は、クライアントとサーバーの間を移動するデータを暗号化し、傍受や改ざんを防ぎます。 ユーザーが Web アプリケーションまたは API に接続すると、TLS によって暗号化されたトンネルが作成され、認証トークン、個人データ、ビジネス トランザクションなどの機密情報が傍受から保護されます。

最新の組織では、TLS に依存して次のことが行われます。

• 規制要件を満たす: PCI DSS、HIPAA などの標準では、転送中のデータの暗号化が義務付けられています。
• 顧客の信頼を構築する: ブラウザーのセキュリティ インジケーターと証明書の警告によって、ユーザーの信頼度が直接構築されます。
• データ侵害の防止: 暗号化されていない接続は、資格情報、セッション トークン、ビジネス データをネットワーク攻撃者に公開します。

TLS は、非推奨の Secure Sockets Layer (SSL) プロトコルを置き換えます。 TLS 1.2 以降を使用するようにサービスを常に構成します。TLS 1.3 は、最適なセキュリティとパフォーマンスを実現するために推奨されます。

Azure で TLS が重要な理由

Azure サービスは、グローバル リージョン全体で毎日何百万もの顧客要求を処理します。 TLS には、次の 3 つの重要な保護が用意されています。

• 認証: 証明書はサービス ID を証明し、攻撃者がエンドポイントを偽装する中間者攻撃を防ぎます。
• 機密性: 暗号化により、トラフィックが信頼されていないネットワークを通過した場合でも、承認されたパーティのみが送信データを読み取ることができます。
• 整合性: 暗号化署名は、転送中にデータの改ざんを検出します。

TLS がないと、ユーザーと同じネットワーク上の攻撃者がサインイン資格情報、API キー、または顧客レコードをキャプチャする可能性があります。 Azure にはプラットフォーム サービス間の組み込みの TLS サポートが含まれていますが、セキュリティ要件に合わせて最小バージョンと証明書ポリシーを構成する必要があります。

Azure App Service の TLS を構成する

アプリケーション コードでは、Azure App Service に追加するパブリック証明書またはプライベート証明書にアクセスできます。 アプリ コードがクライアントとして機能し、証明書認証を必要とする外部サービスにアクセスする場合があります。 また、暗号化タスクの実行が必要になる場合もあります。

コードで証明書を使用するこの方法では、App Service のトランスポート層セキュリティ (TLS) 機能を使用します。そのためには、アプリが Basic レベル以上である必要があります。 アプリが Free レベルまたは Shared レベルの場合は、アプリ リポジトリに証明書ファイルを含めることができます。

App Service で TLS/Secure Sockets Layer (SSL) 証明書を管理できるようにすると、証明書とアプリケーション コードを個別に維持し、機密データを保護できます。

Azure App Service では、証明書の自動更新でマネージド TLS 終了が提供されます。 最小 TLS バージョンを制御し、すべての接続に HTTPS を適用できます。

TLS の最小バージョンを適用する

1. Azure portal で、App Service リソースに移動します。
2. [設定]で、[構成]を選択します。
3. [全般設定] タブを選択します。
4. 最小 TLS バージョンを 1.2 または 1.3 に設定します (1.3 をお勧めします)。
5. 保存を選択して、変更を適用します

古い TLS バージョンに接続しようとしているクライアントは接続エラーを受け取り、レガシ システムで脆弱な暗号化が使用されるのを防ぎます。

HTTPS 接続が必要

1. App Service リソースで、[設定] の下の [構成] を選択します。
2. [全般設定] タブを選択します。
3. [HTTPS のみ] を [オン] に設定します。
4. 保存 を選択します。

Azure は HTTP 要求を HTTPS に自動的にリダイレクトし、すべてのトラフィックで暗号化された接続が使用されるようにします。 暗号化された接続により、ブラウザーでのコンテンツの混在に関する警告が排除され、コンプライアンス監査が簡略化されます。

カスタム ドメイン証明書を追加する

App Service アプリは無料の *.azurewebsites.net 証明書を受け取ります。 カスタム ドメインを使用する運用ワークロードの場合:

1. ドメイン名に一致する証明書を購入またはインポートします。
2. App Service で、[設定] で [証明書] を選択します。
3. [ 証明書の追加] を選択し、ウィザードに従って証明書をアップロードするか、App Service マネージド証明書を作成します。
4. カスタム ドメインで証明書をバインドします。

マネージド証明書は、有効期限が切れる前に自動的に更新されます。 プライベート証明書には、手動による更新と再アップロードが必要です。

Azure API Management の TLS を構成する

Azure API Management は、クライアントとバックエンド API の間に配置され、認証、レート制限、変換を処理します。 TLS は、ゲートウェイ (クライアント向け) レイヤーとバックエンド (サービス間) レイヤーの両方で構成します。

ゲートウェイの最小 TLS バージョンを設定する

1. Azure portal で、API Management インスタンスを開きます。
2. [ セキュリティ] で、[ プロトコルと暗号] を選択します。
3. SSL 3.0、TLS 1.0、TLS 1.1 のチェック ボックスをオフにします。
4. TLS 1.2 が有効になっていることを確認します (TLS 1.3 のサポートはサービス レベルによって異なります)。
5. 保存 を選択します。

TLS の最小バージョンを設定すると、クライアントは脆弱なプロトコル バージョンをネゴシエートできなくなります。 古いモバイル アプリまたはレガシ システムをサポートしている場合は、TLS 1.1 を無効にする前に API コンシューマーでテストします。

API エンドポイントに HTTPS を適用する

1. API Management インスタンスの API に移動します。
2. セキュリティで保護する API を選択します。
3. [ 設定] で、[ URL スキーム ] オプションを見つけます。
4. [HTTPS のみ] を選択します。
5. 保存 を選択します。

API Management は、403 Forbidden 応答で HTTP 要求を拒否し、暗号化されていないエンドポイントが誤って公開されないように保護します。

バックエンド TLS 検証を構成する

API Management がバックエンド サービスを呼び出すときに、これらの接続で TLS も使用されていることを確認します。

1. API で [ デザイン ] を選択し、操作を選択します。
2. [ バックエンド ] セクションで、編集する鉛筆アイコンを選択します。
3. [ 証明書チェーンの検証 ] と [証明書名の検証] を有効にします。
4. バックエンドでプライベート証明書または自己署名証明書が使用されている場合は、信頼されたルート証明書をアップロードします。

バックエンド サービスからの無効または期限切れの証明書が API Management によって受け入れられないように、エンドツーエンドの暗号化を維持しつつ、バックエンド接続を確認します。

TLS 構成を計画する

TLS の変更を運用環境にデプロイする前に、次の手順を実行します。

• 既存のクライアントを監査する: TLS 1.0 または 1.1 を使用してシステムを特定し、アップグレードを計画します。
• 証明書の更新をテストする: マネージド証明書の自動更新が機能することを確認し、プライベート証明書の手動更新手順を文書化します。
• 監視の構成: TLS ハンドシェイクエラーと証明書の有効期限の警告に対して Azure Monitor アラートを設定します。
• コンプライアンス マッピングの文書化: 監査証跡の特定の規制要件を満たす TLS 設定を記録します。

古い TLS バージョンを無効にすると、レガシ クライアントとの互換性が損なわれます。 アプリケーションの所有者と調整し、API コンシューマーとの明確な通信を使用して段階的なロールアウトを計画します。

重要なポイント

• 弱い暗号化の脆弱性を防ぐために、すべての Azure サービスで最小 TLS バージョンを 1.2 以上に構成します。
• 暗号化されていないトラフィックを排除するために、App Service と API Management に HTTPS のみの接続を適用します。
• API Management でバックエンド証明書の検証を有効にして、サービスの境界を越えてエンドツーエンドの暗号化を維持します。
• 一元化された証明書管理と自動更新ワークフローには、Azure Key Vault を使用します。
• 運用環境のロールアウト前にステージング環境で TLS 構成の変更をテストし、クライアントの互換性の問題を特定します。

推奨される次の手順

• 既存の Azure App Service インスタンスと API Management インスタンスを監査して、TLS 1.0 または 1.1 を引き続き許可するサービスを特定します。
• Azure Key Vault を作成し、証明書ストレージを手動アップロードから一元化されたコンテナー ベースの管理に移行します。
• サービスの中断を防ぐために、証明書の有効期限 (有効期限の 30 日前) と TLS ハンドシェイクの失敗に関する Azure Monitor アラートを構成します。