セキュリティフレーム:通信のセキュリティ | 軽減策

[アーティクル]
06/01/2023

製品/サービス	[アーティクル]
Azure Event Hub	SSL/TLS を使用して Event Hub への通信をセキュリティで保護する
Dynamics CRM	サービスアカウントの権限を確認し、カスタムサービスまたは ASP.NET ページで CRM のセキュリティが考慮されていることをチェックする
Azure Data Factory	オンプレミス SQL Server を Azure Data Factory に接続しているときはデータ管理ゲートウェイを使用する
Identity Server	Identity Server へのすべてのトラフィックで HTTPS 接続が使用されていることを確認する
Web アプリケーション	SSL、TLS、および DTLS 接続の認証に X.509 証明書が使用されていることを確認する Azure App Service でカスタムドメインに対して TLS/SSL 証明書を構成する Azure App Service へのすべてのトラフィックに HTTPS 接続を強制する HTTP Strict Transport Security (HSTS) を有効にする
[データベース]	SQL Server 接続の暗号化と証明書の検証を確認する SQL サーバーへの通信を強制的に暗号化する
Azure ストレージ	Azure Storage への通信が HTTPS 経由であることを確認する HTTPS を有効にできない場合は、BLOB のダウンロード後に MD5 ハッシュを検証する SMB 3.0 対応クライアントを使用して Azure ファイル共有に転送中のデータの暗号化を確認する
モバイルクライアント	証明書のピン留めを実装する
WCF	HTTPS - セキュリティで保護されたトランスポートチャネルを有効にする WCF: メッセージのセキュリティ保護レベルを EncryptAndSign に設定する WCF: 最小権限のアカウントを使用して WCF サービスを実行する
Web API	Web API へのすべてのトラフィックに HTTPS 接続を強制する
Azure Cache for Redis	Azure Cache for Redis への通信が TLS 経由であることを確認する
IoT フィールドゲートウェイ	デバイスからフィールドゲートウェイへの通信をセキュリティで保護する
IoT クラウドゲートウェイ	デバイスからクラウドゲートウェイへの通信を SSL/TLS を使用してセキュリティで保護する

SSL/TLS を使用して Event Hub への通信をセキュリティで保護する

タイトル	詳細
コンポーネント	Azure Event Hub
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	Event Hubs の認証とセキュリティモデルの概要
手順	SSL/TLS を使用して Event Hub への AMQP または HTTP 接続をセキュリティで保護します

サービスアカウントの権限を確認し、カスタムサービスまたは ASP.NET ページで CRM のセキュリティが考慮されていることをチェックします

タイトル	詳細
コンポーネント	Dynamics CRM
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	サービスアカウントの権限を確認し、カスタムサービスまたは ASP.NET ページで CRM のセキュリティが考慮されていることをチェックします

オンプレミス SQL Server を Azure Data Factory に接続しているときはデータ管理ゲートウェイを使用する

タイトル	詳細
コンポーネント	Azure Data Factory
SDL フェーズ	デプロイ
適用できるテクノロジ	ジェネリック
属性	リンクされたサービスの種類 - Azure とオンプレミス
参照	オンプレミスと Azure Data Factory の間でのデータの移動
手順	データ管理ゲートウェイ (DMG) ツールは、企業ネットワークまたはファイアウォールの背後で保護されているデータソースに接続するときに必要です。コンピューターをロックダウンすると、DMG ツールが切り離され、正常に動作していないプログラムによって、データソースコンピューターが破損したりスヌーピング (のぞき見) されたりするのを防ぐことができます (たとえば、最新の更新プログラムをインストールする必要がある、最低限必要なポートを有効にする、制御されたアカウントのプロビジョニング、監査の有効化、ディスク暗号化の有効化など)。データゲートウェイのキーは頻繁に、または DMG サービスアカウントのパスワードが更新されるたびに交換する必要がありますリンクサービス経由のデータ転送は暗号化する必要があります

Identity Server へのすべてのトラフィックで HTTPS 接続が使用されていることを確認する

タイトル	詳細
コンポーネント	Identity Server
SDL フェーズ	デプロイ
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	IdentityServer3 - キー、署名、および暗号化、IdentityServer3 - デプロイ
手順	既定では、IdentityServer の着信接続はすべて、HTTPS 経由である必要があります。 IdentityServer との通信は、セキュリティで保護されたトランスポートのみを介していなければなりません。ただし、TLS オフロードのように、この要件が緩和されるデプロイシナリオもいくつかあります。詳細については、「参照」の Identity Server デプロイのページを参照してください。

SSL、TLS、および DTLS 接続の認証に X.509 証明書が使用されていることを確認する

タイトル	詳細
コンポーネント	Web アプリケーション
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	SSL、TLS、または DTLS を使用するアプリケーションは、接続先エンティティの X.509 証明書を完全に検証する必要があります。これには、以下の証明書の検証が含まれます。ドメイン名有効期間 (開始日と有効期限) 失効状態使用状況 (サーバー認証 (サーバーの場合)、クライアント認証 (クライアントの場合) など) 信頼チェーン。プラットフォームによって信頼されている、または管理者によって明示的に構成されているルート証明機関 (CA) に、証明書がチェーンされている必要があります証明書の公開キーの長さが 2048 ビットを超えていることハッシュアルゴリズムが SHA256 以上であること

Azure App Service でカスタムドメインに対して TLS/SSL 証明書を構成する

タイトル	詳細
コンポーネント	Web アプリケーション
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	EnvironmentType - Azure
参照	アプリに対する HTTPS を Azure App Service で有効にする
手順	Azure の既定では、*.azurewebsites.net ドメインのワイルドカード証明書を使用するすべてアプリに対して、HTTPS を利用できます。ただし、すべてのワイルドカードドメインと同様に、カスタムドメインに独自の証明書を使用する場合ほど安全ではありません (こちらを参照)。デプロイされたアプリへのアクセスに使用するカスタムドメインに対して、TLS を有効にすることをお勧めします

Azure App Service へのすべてのトラフィックに HTTPS 接続を強制する

タイトル	詳細
コンポーネント	Web アプリケーション
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	EnvironmentType - Azure
参照	Azure App Service に HTTPS を適用する
手順	Azure では、*.azurewebsites.net ドメインのワイルドカード証明書を使用する Azure App Service に対して、HTTPS が既に有効になっていますが、適用されていません。訪問者は引き続き HTTP を使用してアプリにアクセスするため、アプリのセキュリティが侵害される可能性があります。したがって HTTPS を明示的に適用する必要があります。 ASP.NET MVC アプリケーションは、セキュリティで保護されていない HTTP 要求が HTTPS 経由で再送信されるように強制する、RequireHttps フィルターを使用する必要があります。また、Azure App Service に組み込まれている URL 書き換えモジュールを使用して、HTTPS を適用することもできます。 URL 書き換えモジュールを使用すると、アプリケーションに渡す前に受信要求に適用するルールを開発者が定義できます。 URL 書き換えルールは、アプリケーションのルートに格納されている web.config ファイルで定義されます

例

次の例には、すべての受信トラフィックに HTTPS の使用を強制する基本的な URL 書き換えルールが含まれています

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Force HTTPS" enabled="true">
          <match url="(.*)" ignoreCase="false" />
          <conditions>
            <add input="{HTTPS}" pattern="off" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

このルールは、ユーザーが HTTP を使用してページを要求したときに HTTP 状態コード 301 (永続的なリダイレクト) を返すことで動作します。 301 は、訪問者が要求した URL と同じ URL へ要求をリダイレクトしますが、要求の HTTP 部分は HTTPS で置き換えられます。たとえば、HTTP://contoso.com は HTTPS://contoso.com に制限されます。

HTTP Strict Transport Security (HSTS) を有効にする

タイトル	詳細
コンポーネント	Web アプリケーション
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	OWASP HTTP Strict Transport Security チートシートを有効にする
手順	HTTP Strict Transport Security (HSTS) は、特別な応答ヘッダーを使用して Web アプリケーションで指定されるオプトインセキュリティ拡張機能です。サポートされているブラウザーがこのヘッダーを受け取ると、そのブラウザーでは、指定したドメインへの HTTP 経由の通信を送信できなくなり、代わりにすべての通信が HTTPS 経由で送信されます。 HTTPS クリックスルーメッセージもブラウザーに表示されなくなります。 HSTS を実装するには、コードまたは config で、応答ヘッダー Strict-Transport-Security: max-age=300; includeSubDomains を、Web サイトに対してグローバルに構成する必要があります。HSTS では、次の脅威に対応します。ユーザーは `https://example.com` をブックマークするか手動で入力し、中間者攻撃を受ける。HSTS は HTTP 要求をターゲットドメインの HTTPS に自動的にリダイレクトします。 HTTPS のみを目的とした Web アプリケーションで、うっかり HTTP リンクを含めてしまうかまたは HTTP 経由でコンテンツを提供する。HSTS は HTTP 要求をターゲットドメインの HTTPS に自動的にリダイレクトします。中間者攻撃で、無効な証明書を使用して攻撃対象ユーザーからのトラフィックを傍受しようとしており、ユーザーに不正な証明書を受け入れさせようとしている。HSTS は、無効な証明書のメッセージを上書きするユーザーを許可しません。

SQL Server 接続の暗号化と証明書の検証を確認する

タイトル	詳細
コンポーネント	データベース
SDL フェーズ	Build
適用できるテクノロジ	SQL Azure
属性	SQL バージョン - V12
参照	SQL Database 用のセキュリティで保護された接続文字列の書き込みに関するベストプラクティス
手順	SQL Database とクライアントアプリケーションの間の通信はすべて、以前は Secure Sockets Layer (SSL) と呼ばれていた Transport Layer Security (TLS) を使用して常に暗号化されます。 SQL Database では、暗号化されていない接続はサポートされません。アプリケーションコードやツールで証明書を検証するには、暗号化された接続を明示的に要求し、サーバー証明書は信頼しないようにします。アプリケーションコードやツールが、暗号化された接続を要求しない場合でも、暗号化された接続を受け付けることはできますただし、サーバー証明書は検証されず、"man in the middle" 攻撃を受けやすくなります。 ADO.NET アプリケーションコードで証明書を検証するには、データベース接続文字列で `Encrypt=True` と `TrustServerCertificate=False` を設定します。 SQL Server Management Studio を使用して証明書を検証するには、[サーバーに接続] ダイアログボックスを開きます。 [接続プロパティ] タブの [暗号化接続] をクリックします

SQL サーバーへの通信を強制的に暗号化する

タイトル	詳細
コンポーネント	データベース
SDL フェーズ	Build
適用できるテクノロジ	OnPrem
属性	SQL バージョン - MsSQL2016、SQL バージョン - MsSQL2012、SQL バージョン - MsSQL2014
参照	データベースエンジンへの暗号化接続の有効化
手順	TLS 暗号化を有効にすると、SQL Server のインスタンスとアプリケーションの間で行われるネットワーク経由データ転送のセキュリティが向上します。

Azure Storage への通信が HTTPS 経由であることを確認する

タイトル	詳細
コンポーネント	Azure Storage
SDL フェーズ	デプロイ
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	Azure Storage トランスポートレベルの暗号化 - HTTPS の使用
手順	転送中の Azure Storage データのセキュリティを確保するには、REST API を呼び出すとき、またはストレージのオブジェクトにアクセスするときに必ず HTTPS プロトコルを使用します。また、Azure Storage オブジェクトへのアクセス権を委任するときに使用できる Shared Access Signatureには、Shared Access Signature の使用時には HTTPS プロトコルのみを使用できると指定するオプションがあるので、誰でも SAS トークンを指定したリンクを送信すると適切なプロトコルが使用されます。

HTTPS を有効にできない場合は、BLOB のダウンロード後に MD5 ハッシュを検証する

タイトル	詳細
コンポーネント	Azure Storage
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	StorageType - BLOB
参照	Windows Azure BLOB MD5 の概要
手順	Windows Azure Blob service は、アプリケーション層とトランスポート層の両方のデータ整合性を確保するためのメカニズムを提供します。何らかの理由で HTTPS ではなく HTTP を使用する必要があり、ブロック BLOB を使用している場合、MD5 チェックを使用して、転送中の BLOB の整合性を検証することができますこれは、ネットワーク/トランスポート層のエラーからの保護には役立ちますが、中間攻撃には必ずしも役立つとは言えません。トランスポートレベルのセキュリティを提供する HTTPS を使用できる場合は、MD5 チェックを使用することは冗長となり、不要です。

SMB 3.x 対応クライアントを使用して Azure ファイル共有に転送中のデータの暗号化を確認する

タイトル	詳細
コンポーネント	モバイルクライアント
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	StorageType - ファイル
参照	Azure Files、Windows クライアントでの Azure Files SMB のサポート
手順	Azure Files は、REST API の使用時に HTTPS をサポートしていますが、VM にアタッチされる SMB ファイル共有として使用する方が一般的です。 SMB 2.1 は暗号化をサポートしていないので、Azure の同じリージョン内でのみ接続が許可されます。一方、SMB 3.x は暗号化をサポートしており、Windows Server 2012 R2、Windows 8、Windows 8.1、および Windows 10 で使用できるので、リージョンをまたがるアクセスや、デスクトップ上のアクセスも許可されます。

証明書のピン留めを実装する

タイトル	詳細
コンポーネント	Azure Storage
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック、Windows Phone
属性	該当なし
参照	証明書と公開キーのピン留め
手順	証明書のピン留めは Man-In-The-Middle (MITM) 攻撃に対する防御策で、ホストを、予想される X509 証明書または公開キーに関連付けます。ホストに認識または表示された証明書や公開キーは、そのホストに関連付けられます。つまり、"ピン留め" されます。 TLS ハンドシェイク中に敵が TLS MITM 攻撃を実行しようとしたとき、攻撃者のサーバーのキーが、ピン留めされた証明書のキーが異なっていると、その要求は破棄されます。したがって、MITM 証明書のピン留めを回避するには、ServicePointManager の `ServerCertificateValidationCallback` 委任を実装します。

例

using System;
using System.Net;
using System.Net.Security;
using System.Security.Cryptography;

namespace CertificatePinningExample
{
    class CertificatePinningExample
    {
        /* Note: In this example, we're hardcoding the certificate's public key and algorithm for 
           demonstration purposes. In a real-world application, this should be stored in a secure
           configuration area that can be updated as needed. */

        private static readonly string PINNED_ALGORITHM = "RSA";

        private static readonly string PINNED_PUBLIC_KEY = "3082010A0282010100B0E75B7CBE56D31658EF79B3A1" +
            "294D506A88DFCDD603F6EF15E7F5BCBDF32291EC50B2B82BA158E905FE6A83EE044A48258B07FAC3D6356AF09B2" +
            "3EDAB15D00507B70DB08DB9A20C7D1201417B3071A346D663A241061C151B6EC5B5B4ECCCDCDBEA24F051962809" +
            "FEC499BF2D093C06E3BDA7D0BB83CDC1C2C6660B8ECB2EA30A685ADE2DC83C88314010FFC7F4F0F895EDDBE5C02" +
            "ABF78E50B708E0A0EB984A9AA536BCE61A0C31DB95425C6FEE5A564B158EE7C4F0693C439AE010EF83CA8155750" +
            "09B17537C29F86071E5DD8CA50EBD8A409494F479B07574D83EDCE6F68A8F7D40447471D05BC3F5EAD7862FA748" +
            "EA3C92A60A128344B1CEF7A0B0D94E50203010001";


        public static void Main(string[] args)
        {
            HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://azure.microsoft.com");
            request.ServerCertificateValidationCallback = (sender, certificate, chain, sslPolicyErrors) =>
            {
                if (certificate == null || sslPolicyErrors != SslPolicyErrors.None)
                {
                    // Error getting certificate or the certificate failed basic validation
                    return false;
                }

                var targetKeyAlgorithm = new Oid(certificate.GetKeyAlgorithm()).FriendlyName;
                var targetPublicKey = certificate.GetPublicKeyString();
                
                if (targetKeyAlgorithm == PINNED_ALGORITHM &&
                    targetPublicKey == PINNED_PUBLIC_KEY)
                {
                    // Success, the certificate matches the pinned value.
                    return true;
                }
                // Reject, either the key or the algorithm does not match the expected value.
                return false;
            };

            try
            {
                var response = (HttpWebResponse)request.GetResponse();
                Console.WriteLine($"Success, HTTP status code: {response.StatusCode}");
            }
            catch(Exception ex)
            {
                Console.WriteLine($"Failure, {ex.Message}");
            }
            Console.WriteLine("Press any key to end.");
            Console.ReadKey();
        }
    }
}

HTTPS - セキュリティで保護されたトランスポートチャネルを有効にする

タイトル	詳細
コンポーネント	WCF
SDL フェーズ	Build
適用できるテクノロジ	NET Framework 3
属性	該当なし
参照	MSDN、Fortify Kingdom
手順	アプリケーションは、機密情報へのすべてのアクセスに対して HTTPS が確実に使用されるよう構成されている必要があります。説明: アプリケーションが機密情報を処理しており、メッセージレベルの暗号化が使用されていない場合は、暗号化されたトランスポートチャネル経由での通信のみを許可します。推奨: HTTP トランスポートが無効になっていることを確認し、代わりに HTTPS トランスポートを有効にします。たとえば、`<httpTransport/>` を `<httpsTransport/>` タグに置き換えます。アプリケーションへのアクセスチャネルを確実にセキュリティで保護したい場合は、ネットワーク構成 (ファイアウォール) には依存しないでください。論理的に言えば、アプリケーションのセキュリティをネットワークに依存するべきではありません。実際的な観点から言うと、ネットワークセキュリティ担当者は、アプリケーションの進化に伴うアプリケーションのセキュリティ要件を常に把握しているわけではありません。

WCF: メッセージのセキュリティ保護レベルを EncryptAndSign に設定する

タイトル	詳細
コンポーネント	WCF
SDL フェーズ	Build
適用できるテクノロジ	.NET Framework 3
属性	該当なし
参照	MSDN
手順	説明: 保護レベルが "none" に設定されていると、メッセージの保護が無効になります。機密性と整合性を実現するには、適切な設定レベルを使用します。推奨: `Mode=None` の場合 - メッセージ保護を無効にします `Mode=Sign` の場合 - メッセージに署名します。ただし、暗号化しません。データの整合性が重要である場合に使用します `Mode=EncryptAndSign` の場合 - メッセージに署名し、暗号化します機密性については心配がなく、情報の整合性のみを検証する場合は、暗号化を無効にして、メッセージへの署名のみを検討してください。送信者を検証する必要があるが、機密データが送信されない操作またはサービスコントラクトについては、これが役に立つ場合があります。保護レベルを下げるときは、個人データがメッセージに含まれないように注意してください。

例

次の例では、メッセージへの署名のみを行うようにサービスと操作を構成します。 ProtectionLevel.Sign のサービスコントラクトの例: サービスコントラクトレベルで ProtectionLevel.Sign を使用する例を次に示します。

[ServiceContract(Protection Level=ProtectionLevel.Sign] 
public interface IService 
  { 
  string GetData(int value); 
  }

例

ProtectionLevel.Sign の操作コントラクトの例 (詳細な制御): 次に示すのは、ProtectionLevel.SignOperationContract レベルでの使用例です。

[OperationContract(ProtectionLevel=ProtectionLevel.Sign] 
string GetData(int value);

WCF: 最小権限のアカウントを使用して WCF サービスを実行する

タイトル	詳細
コンポーネント	WCF
SDL フェーズ	Build
適用できるテクノロジ	.NET Framework 3
属性	該当なし
参照	MSDN
手順	説明: 管理者または高い権限を持つアカウントで WCF サービスを実行しないでください。サービスが侵害された場合、その影響が大きくなります。推奨: 最小権限のアカウントを使用して WCF サービスをホストします。これにより、アプリケーションの攻撃対象領域を抑え、攻撃を受けた場合の損害の可能性を低くすることができます。サービスアカウントに、MSMQ、イベントログ、パフォーマンスカウンター、ファイルシステムなどのインフラストラクチャリソースに対する追加のアクセス権が必要な場合は、WCF サービスが正常に実行されるように、こうしたリソースに適切なアクセス許可を付与する必要があります。使用しているサービスが、最初の呼び出し元に代わって特定のリソースにアクセスする必要がある場合は、偽装と委任を使用して、ダウンストリームの承認チェックのために呼び出し元の ID をフローします。開発シナリオでは、ローカルネットワークサービスアカウントを使用してください。これは、権限が制限された特別な組み込みアカウントです。運用環境のシナリオでは、最小権限のカスタムドメインサービスアカウントを作成します。

Web API へのすべてのトラフィックに HTTPS 接続を強制する

タイトル	詳細
コンポーネント	Web API
SDL フェーズ	Build
適用できるテクノロジ	MVC5、MVC6
属性	該当なし
参照	Web API コントローラーでの SSL の適用
手順	アプリケーションに HTTPS と HTTP の両方のバインドがある場合、クライアントは引き続き HTTP を使用してサイトにアクセスできます。これを防ぐには、アクションフィルターを使用して、保護された API への要求が常に HTTPS を経由するように指定します。

例

次のコードは、TLS をチェックする Web API 認証フィルターを示しています。

public class RequireHttpsAttribute : AuthorizationFilterAttribute
{
    public override void OnAuthorization(HttpActionContext actionContext)
    {
        if (actionContext.Request.RequestUri.Scheme != Uri.UriSchemeHttps)
        {
            actionContext.Response = new HttpResponseMessage(System.Net.HttpStatusCode.Forbidden)
            {
                ReasonPhrase = "HTTPS Required"
            };
        }
        else
        {
            base.OnAuthorization(actionContext);
        }
    }
}

このフィルターを、TLS を必要とする Web API アクションすべてに追加します。

public class ValuesController : ApiController
{
    [RequireHttps]
    public HttpResponseMessage Get() { ... }
}

Azure Cache for Redis への通信が TLS 経由であることを確認する

タイトル	詳細
コンポーネント	Azure Cache for Redis
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	Azure Redis TLS サポート
手順	Redis サーバーは既定で TLS をサポートしませんが、Azure Cache for Redis では TLS がサポートされます。 Azure Cache for Redis に接続しようとしていて、クライアントが StackExchange.Redis のように TLS をサポートしている場合は、TLS を使用する必要があります。既定では、新しい Azure Cache for Redis インスタンスの TLS 以外のポートは無効になっています。 Redis クライアントの TLS サポートに対する依存関係がない限り、このセキュリティで保護された既定値が変更されていないことを確認してください。

Redis は、信頼された環境の信頼されたクライアントによってアクセスされるように設計されています。つまり、Redis インスタンスを、インターネット (一般的には、信頼されていないクライアントが Redis TCP ポートまたは UNIX ソケットに直接アクセスする環境) に直接公開することはお勧めしません。

デバイスからフィールドゲートウェイへの通信をセキュリティで保護する

タイトル	詳細
コンポーネント	IoT フィールドゲートウェイ
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	IP ベースのデバイスの場合、通信プロトコルは、通常、転送中のデータを保護するために、SSL/TLS チャネルでカプセル化できます。 SSL/TLS をサポートしていないその他のプロトコルについては、トランスポート層またはメッセージ層でセキュリティを提供する、セキュリティで保護されたプロトコルバージョンがあるかどうかを調べます。

デバイスからクラウドゲートウェイへの通信を SSL/TLS を使用してセキュリティで保護する

タイトル	詳細
コンポーネント	IoT クラウドゲートウェイ
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	通信プロトコルの選択
手順	SSL や TLS を使用して HTTP/AMQP または MQTT のプロトコルをセキュリティで保護します。

セキュリティ フレーム:通信のセキュリティ | 軽減策