製品/サービス | [アーティクル] |
---|---|
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) ツールは、コーネットまたはファイアウォールの背後で保護されているデータ ソースに接続するために必要です。
|
Identity Server へのすべてのトラフィックが HTTPS 接続経由であることを確認する
タイトル | 詳細 |
---|---|
コンポーネント | アイデンティティサーバー |
SDL フェーズ | デプロイメント |
適用できるテクノロジ | ジェネリック |
属性 | なし |
参考文献 | なし |
手順 | 既定では、IdentityServer では、すべての受信接続が HTTPS 経由で送信される必要があります。 IdentityServer との通信は、セキュリティで保護されたトランスポート経由でのみ行われることが絶対に必須です。 この要件を緩和できる TLS オフロードなどの特定のデプロイ シナリオがあります。 詳細については、参照の ID サーバーの展開ページを参照してください。 |
SSL、TLS、および DTLS 接続の認証に使用される X.509 証明書を確認する
タイトル | 詳細 |
---|---|
コンポーネント | Web アプリケーション |
SDL フェーズ | 建築する |
適用できるテクノロジ | ジェネリック |
属性 | なし |
参考文献 | なし |
手順 | SSL、TLS、または DTLS を使用するアプリケーションは、接続先のエンティティの X.509 証明書を完全に検証する必要があります。 これには、次の証明書の検証が含まれます。
|
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.com
は HTTPS://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 は、次の脅威に対処します。
|
SQL Server 接続の暗号化と証明書の検証を確認する
タイトル | 詳細 |
---|---|
コンポーネント | データベース |
SDL フェーズ | 建築する |
適用できるテクノロジ | SQL Azure |
属性 | SQL バージョン - V12 |
参考文献 | SQL Database のセキュリティで保護された接続文字列の記述に関するベスト プラクティス |
手順 | SQL Database とクライアント アプリケーション間のすべての通信は、トランスポート層セキュリティ (以前は Secure Sockets Layer (SSL) と呼ばれる TLS) を使用して常に暗号化されます。 SQL Database では、暗号化されていない接続はサポートされていません。 アプリケーション コードまたはツールを使用して証明書を検証するには、暗号化された接続を明示的に要求し、サーバー証明書を信頼しないでください。 アプリケーション コードまたはツールが暗号化された接続を要求しない場合でも、暗号化された接続を受け取ります ただし、サーバー証明書を検証できない可能性があるため、"man in the middle" 攻撃の影響を受けやすくなります。 アプリケーション コードを使用して証明書 ADO.NET 検証するには、データベース接続文字列に |
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 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 フェーズ | 建築する |
適用できるテクノロジ | 汎用、Windows Phone |
属性 | なし |
参考文献 | 証明書と公開キーのピン留め |
手順 | 証明書のピン留めは、Man-In-The-Middle (MITM) 攻撃から防御します。 ピン留めとは、ホストを想定される X509 証明書または公開キーに関連付けるプロセスです。 ホストに対して証明書または公開キーが認識または確認されると、証明書または公開キーがホストに関連付けられるか、または "固定" されます。 したがって、敵対者が TLS MITM 攻撃を行おうとすると、TLS ハンドシェイク中に攻撃者のサーバーからのキーは固定された証明書のキーと異なり、要求は破棄されるため、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(Windows Communication Foundation) |
SDL フェーズ | 建築する |
適用できるテクノロジ | NET Framework 3 |
属性 | なし |
参考文献 | MSDN、Fortify Kingdom |
手順 | アプリケーション構成では、機密情報へのすべてのアクセスに HTTPS が使用されるようにする必要があります。
実用的な観点から見ると、ネットワークをセキュリティで保護する担当者は、アプリケーションの進化に伴うセキュリティ要件を常に追跡するとは限りません。 |
WCF: メッセージ セキュリティ保護レベルを EncryptAndSign に設定する
タイトル | 詳細 |
---|---|
コンポーネント | WCF(Windows Communication Foundation) |
SDL フェーズ | 建築する |
適用できるテクノロジ | .NET Framework 3 |
属性 | なし |
参考文献 | MSDN |
手順 |
機密性を考慮せずに情報の整合性を検証する必要がある場合にのみ、暗号化を無効にし、メッセージに署名することを検討してください。 これは、元の送信者を検証する必要があるが、機密データが送信されない操作またはサービス コントラクトに役立つ場合があります。 保護レベルを下げる場合は、メッセージに個人データが含まれていないことに注意してください。 |
例
次の例では、メッセージにのみ署名するようにサービスと操作を構成します。
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 |
手順 |
サービスが元の呼び出し元の代わりに特定のリソースにアクセスする必要がある場合は、偽装と委任を使用して、ダウンストリーム承認チェックのために呼び出し元の 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 プロトコルをセキュリティで保護します。 |