次の方法で共有


セキュリティ フレーム: 通信セキュリティ |緩和 策

製品/サービス [アーティクル]
Azure Event Hub
Dynamics CRM
Azureデータファクトリー
Identity Server
Web アプリケーション
データベース
Azure ストレージ
モバイル クライアント
WCF
ウェブAPI
Azure Cache for Redis
IoT フィールド ゲートウェイ
IoT クラウド ゲートウェイ

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

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

サービス アカウントの権限を確認し、カスタム サービスまたは ASP.NET ページが CRM のセキュリティを尊重していることを確認します

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

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

タイトル 詳細
コンポーネント Azure Data Factory
SDL フェーズ デプロイメント
適用できるテクノロジ ジェネリック
属性 リンクされたサービスの種類 - Azure とオンプレミス
参考文献 オンプレミスと Azure Data Factory の間でのデータの移動
手順

データ管理ゲートウェイ (DMG) ツールは、コーネットまたはファイアウォールの背後で保護されているデータ ソースに接続するために必要です。

  1. マシンをロックダウンすると、DMG ツールが分離され、誤動作しているプログラムがデータ ソース コンピューターで破損またはスヌーピングされるのを防ぐことができます。 (最新の更新プログラムをインストールする必要がある、最低限必要なポートを有効にする、アカウントのプロビジョニングを制御する、監査を有効にする、ディスク暗号化を有効にするなど)
  2. データ ゲートウェイ キーは、頻繁に、または DMG サービス アカウントのパスワードが更新されるたびに交換する必要があります
  3. リンク サービス経由のデータ転送は暗号化する必要があります

Identity Server へのすべてのトラフィックが HTTPS 接続経由であることを確認する

タイトル 詳細
コンポーネント アイデンティティサーバー
SDL フェーズ デプロイメント
適用できるテクノロジ ジェネリック
属性 なし
参考文献 なし
手順 既定では、IdentityServer では、すべての受信接続が HTTPS 経由で送信される必要があります。 IdentityServer との通信は、セキュリティで保護されたトランスポート経由でのみ行われることが絶対に必須です。 この要件を緩和できる TLS オフロードなどの特定のデプロイ シナリオがあります。 詳細については、参照の ID サーバーの展開ページを参照してください。

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

タイトル 詳細
コンポーネント Web アプリケーション
SDL フェーズ 建築する
適用できるテクノロジ ジェネリック
属性 なし
参考文献 なし
手順

SSL、TLS、または DTLS を使用するアプリケーションは、接続先のエンティティの X.509 証明書を完全に検証する必要があります。 これには、次の証明書の検証が含まれます。

  • ドメイン名
  • 有効期間 (開始日と有効期限の両方)
  • 失効状態
  • 使用法 (サーバーのサーバー認証、クライアントのクライアント認証など)
  • 信頼チェーン。 証明書は、プラットフォームによって信頼されているか、管理者によって明示的に構成されているルート証明機関 (CA) にチェーンする必要があります
  • 証明書の公開キーのキー長は、 >2048 ビットである必要があります
  • ハッシュ アルゴリズムは SHA256 以降である必要があります

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

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

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

タイトル 詳細
コンポーネント Web アプリケーション
SDL フェーズ 建築する
適用できるテクノロジ ジェネリック
属性 環境タイプ - Azure
参考文献 Azure App Service に HTTPS を適用する
手順

Azure では、ドメイン *.azurewebsites.net のワイルドカード証明書を使用して Azure アプリ サービスに対して HTTPS を既に有効にしていますが、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 にリダイレクトしますが、要求の HTTP 部分を HTTPS に置き換えます。 たとえば、 HTTP://contoso.comHTTPS://contoso.comにリダイレクトされます。

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

タイトル 詳細
コンポーネント Web アプリケーション
SDL フェーズ 建築する
適用できるテクノロジ ジェネリック
属性 なし
参考文献 OWASP HTTP Strict Transport Security Cheat Sheet
手順

HTTP Strict Transport Security (HSTS) は、特殊な応答ヘッダーを使用して Web アプリケーションによって指定されるオプトイン セキュリティ強化です。 サポートされているブラウザーがこのヘッダーを受信すると、ブラウザーは指定されたドメインに HTTP 経由で通信が送信されるのを防ぎ、代わりにすべての通信を HTTPS 経由で送信します。 また、ブラウザーでの HTTPS のクリックによるプロンプトの表示も禁止されます。

HSTS を実装するには、次の応答ヘッダーをコードまたは構成で Web サイトにグローバルに構成する必要があります。Strict-Transport-Security: max-age=300;includeSubDomains HSTS は、次の脅威に対処します。

  • ユーザーがブックマークを作成したり、 https://example.com を手動で入力したりすると、中間者の攻撃者の影響を受けます。HSTS は、ターゲット ドメインの HTTPS に HTTP 要求を自動的にリダイレクトします
  • 純粋に HTTPS を意図した Web アプリケーションに HTTP リンクが誤って含まれているか、HTTP 経由でコンテンツを提供する: HSTS は、ターゲット ドメインの HTTPS に HTTP 要求を自動的にリダイレクトします
  • 中間者の攻撃者が、無効な証明書を使用して被害者ユーザーからのトラフィックを傍受しようとし、ユーザーが無効な証明書を受け入れることを望んでいます。HSTS は、ユーザーが無効な証明書メッセージをオーバーライドすることを許可しません

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

タイトル 詳細
コンポーネント データベース
SDL フェーズ 建築する
適用できるテクノロジ SQL Azure
属性 SQL バージョン - V12
参考文献 SQL Database のセキュリティで保護された接続文字列の記述に関するベスト プラクティス
手順

SQL Database とクライアント アプリケーション間のすべての通信は、トランスポート層セキュリティ (以前は Secure Sockets Layer (SSL) と呼ばれる TLS) を使用して常に暗号化されます。 SQL Database では、暗号化されていない接続はサポートされていません。 アプリケーション コードまたはツールを使用して証明書を検証するには、暗号化された接続を明示的に要求し、サーバー証明書を信頼しないでください。 アプリケーション コードまたはツールが暗号化された接続を要求しない場合でも、暗号化された接続を受け取ります

ただし、サーバー証明書を検証できない可能性があるため、"man in the middle" 攻撃の影響を受けやすくなります。 アプリケーション コードを使用して証明書 ADO.NET 検証するには、データベース接続文字列に Encrypt=TrueTrustServerCertificate=False を設定します。 SQL Server Management Studio を使用して証明書を検証するには、[サーバーへの接続] ダイアログ ボックスを開きます。 [接続のプロパティ] タブで [接続の暗号化] をクリックします。

SQL Server への暗号化された通信を強制する

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

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

タイトル 詳細
コンポーネント Azure Storage
SDL フェーズ デプロイメント
適用できるテクノロジ ジェネリック
属性 なし
参考文献 Azure Storage Transport-Level 暗号化 – HTTPS の使用
手順 転送中の Azure Storage データのセキュリティを確保するには、REST API を呼び出すか、ストレージ内のオブジェクトにアクセスするときに、常に HTTPS プロトコルを使用します。 また、Azure Storage オブジェクトへのアクセスを委任するために使用できる Shared Access Signature には、Shared Access Signature を使用する場合に HTTPS プロトコルのみを使用できるように指定するオプションが含まれており、SAS トークンを使用してリンクを送信するすべてのユーザーが適切なプロトコルを使用することを保証します。

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

タイトル 詳細
コンポーネント Azure Storage
SDL フェーズ 建築する
適用できるテクノロジ ジェネリック
属性 StorageType - ブロブ
参考文献 Windows Azure BLOB MD5 の概要
手順

Windows Azure Blob Service には、アプリケーションレイヤーとトランスポート層の両方でデータの整合性を確保するメカニズムが用意されています。 何らかの理由で HTTPS の代わりに HTTP を使用する必要があり、ブロック BLOB を操作している場合は、MD5 チェックを使用して、転送される BLOB の整合性を確認できます

これは、ネットワーク/トランスポート層のエラーからの保護に役立ちますが、必ずしも中間攻撃では役に立つわけではありません。 トランスポート レベルのセキュリティを提供する HTTPS を使用できる場合、MD5 チェックの使用は冗長であり、不要です。

SMB 3.x 互換クライアントを使用して、Azure ファイル共有への転送中データの暗号化を確保する

タイトル 詳細
コンポーネント モバイル クライアント
SDL フェーズ 建築する
適用できるテクノロジ ジェネリック
属性 StorageType - ファイル
参考文献 Azure FilesWindows クライアントに対する 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 フェーズ 建築する
適用できるテクノロジ 汎用、Windows Phone
属性 なし
参考文献 証明書と公開キーのピン留め
手順

証明書のピン留めは、Man-In-The-Middle (MITM) 攻撃から防御します。 ピン留めとは、ホストを想定される X509 証明書または公開キーに関連付けるプロセスです。 ホストに対して証明書または公開キーが認識または確認されると、証明書または公開キーがホストに関連付けられるか、または "固定" されます。

したがって、敵対者が TLS MITM 攻撃を行おうとすると、TLS ハンドシェイク中に攻撃者のサーバーからのキーは固定された証明書のキーと異なり、要求は破棄されるため、ServicePointManager の ServerCertificateValidationCallback デリゲートを実装することで MITM 証明書のピン留めを防ぐことができます。

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(Windows Communication Foundation)
SDL フェーズ 建築する
適用できるテクノロジ NET Framework 3
属性 なし
参考文献 MSDNFortify Kingdom
手順 アプリケーション構成では、機密情報へのすべてのアクセスに HTTPS が使用されるようにする必要があります。
  • 説明: アプリケーションが機密情報を処理し、メッセージ レベルの暗号化を使用しない場合は、暗号化されたトランスポート チャネル経由でのみ通信を許可する必要があります。
  • 推奨 事項: HTTP トランスポートが無効になっていることを確認し、代わりに HTTPS トランスポートを有効にします。 たとえば、 <httpTransport/><httpsTransport/> タグに置き換えます。 セキュリティで保護されたチャネル経由でのみアプリケーションにアクセスできることを保証するために、ネットワーク構成 (ファイアウォール) に依存しないでください。 哲学的な観点から見れば、アプリケーションはセキュリティのためにネットワークに依存しないようにする必要があります。

実用的な観点から見ると、ネットワークをセキュリティで保護する担当者は、アプリケーションの進化に伴うセキュリティ要件を常に追跡するとは限りません。

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

タイトル 詳細
コンポーネント WCF(Windows Communication Foundation)
SDL フェーズ 建築する
適用できるテクノロジ .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の操作コントラクトの例 (詳細制御の場合): OperationContract レベルでProtectionLevel.Signを使用する例を次に示します。

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

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

タイトル 詳細
コンポーネント WCF(Windows Communication Foundation)
SDL フェーズ 建築する
適用できるテクノロジ .NET Framework 3
属性 なし
参考文献 MSDN
手順
  • 説明: 管理者アカウントまたは高い特権アカウントで WCF サービスを実行しないでください。 サービスが侵害された場合、影響が大きくなります。
  • 推奨 事項: WCF サービスをホストするには、最小限の特権を持つアカウントを使用します。これにより、アプリケーションの攻撃対象領域が減少し、攻撃を受けた場合の潜在的な損害が軽減されるためです。 サービス アカウントで MSMQ、イベント ログ、パフォーマンス カウンター、ファイル システムなどのインフラストラクチャ リソースに対する追加のアクセス権が必要な場合は、WCF サービスを正常に実行できるように、これらのリソースに適切なアクセス許可を付与する必要があります。

サービスが元の呼び出し元の代わりに特定のリソースにアクセスする必要がある場合は、偽装と委任を使用して、ダウンストリーム承認チェックのために呼び出し元の ID をフローします。 開発シナリオでは、特権を減らした特別な組み込みアカウントであるローカル ネットワーク サービス アカウントを使用します。 運用シナリオでは、最小限の特権を持つカスタム ドメイン サービス アカウントを作成します。

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

タイトル 詳細
コンポーネント Web API
SDL フェーズ 建築する
適用できるテクノロジ 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 フェーズ 建築する
適用できるテクノロジ ジェネリック
属性 なし
参考文献 Azure Redis TLS のサポート
手順 Redis サーバーは TLS をすぐにサポートしていませんが、Azure Cache for Redis ではサポートされています。 Azure Cache for Redis に接続していて、クライアントが StackExchange.Redis などの TLS をサポートしている場合は、TLS を使用する必要があります。 既定では、新しい Azure Cache for Redis インスタンスでは TLS 以外のポートが無効になっています。 redis クライアントの TLS サポートに依存しない限り、セキュリティで保護された既定値が変更されていないことを確認します。

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

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

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

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

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