セキュリティ フレーム:通信のセキュリティ | 軽減策
製品/サービス | [アーティクル] |
---|---|
Azure Event Hub | |
Dynamics CRM | |
Azure Data Factory | |
Identity Server | |
Web アプリケーション | |
[データベース] | |
Azure ストレージ | |
モバイル クライアント | |
WCF | |
Web API | |
Azure Cache for Redis | |
IoT フィールド ゲートウェイ | |
IoT クラウド ゲートウェイ |
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) ツールは、企業ネットワークまたはファイアウォールの背後で保護されているデータ ソースに接続するときに必要です。
|
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 証明書を完全に検証する必要があります。 これには、以下の証明書の検証が含まれます。
|
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 では、次の脅威に対応します。
|
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 アプリケーション コードで証明書を検証するには、データベース接続文字列で |
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 の |
例
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 が確実に使用されるよう構成されている必要があります。
実際的な観点から言うと、ネットワーク セキュリティ担当者は、アプリケーションの進化に伴うアプリケーションのセキュリティ要件を常に把握しているわけではありません。 |
WCF: メッセージのセキュリティ保護レベルを EncryptAndSign に設定する
タイトル | 詳細 |
---|---|
コンポーネント | WCF |
SDL フェーズ | Build |
適用できるテクノロジ | .NET Framework 3 |
属性 | 該当なし |
参照 | MSDN |
手順 |
機密性については心配がなく、情報の整合性のみを検証する場合は、暗号化を無効にして、メッセージへの署名のみを検討してください。 送信者を検証する必要があるが、機密データが送信されない操作またはサービス コントラクトについては、これが役に立つ場合があります。 保護レベルを下げるときは、個人データがメッセージに含まれないように注意してください。 |
例
次の例では、メッセージへの署名のみを行うようにサービスと操作を構成します。 ProtectionLevel.Sign
のサービス コントラクトの例: サービス コントラクト レベルで ProtectionLevel.Sign を使用する例を次に示します。
[ServiceContract(Protection Level=ProtectionLevel.Sign]
public interface IService
{
string GetData(int value);
}
例
ProtectionLevel.Sign
の操作コントラクトの例 (詳細な制御): 次に示すのは、ProtectionLevel.Sign
OperationContract レベルでの使用例です。
[OperationContract(ProtectionLevel=ProtectionLevel.Sign]
string GetData(int value);
WCF: 最小権限のアカウントを使用して WCF サービスを実行する
タイトル | 詳細 |
---|---|
コンポーネント | WCF |
SDL フェーズ | Build |
適用できるテクノロジ | .NET Framework 3 |
属性 | 該当なし |
参照 | MSDN |
手順 |
使用しているサービスが、最初の呼び出し元に代わって特定のリソースにアクセスする必要がある場合は、偽装と委任を使用して、ダウンストリームの承認チェックのために呼び出し元の 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 のプロトコルをセキュリティで保護します。 |