監査記録がないと、セキュリティ関連のインシデントを検出して対応する機能が制限され、フォレンジック調査が妨げられます。

ログ機能を損なう構成設定には次のものが含まれますが、これらに限定されません。
- 監査ログを意図的に無効にする
- 特定のユーザー、グループ、またはプロセスのアクションをログから除外する
- ログの整合性を不適切に保護する
- オプションの監査ログを有効にしない
- ログのサンプリング レートを下げる

Terraform 構成は、ログ オプションを指定せずに仮想マシン サブネットをセットアップします。これらのログには、ネットワーク監視、フォレンジック、リアルタイムのセキュリティ分析、およびコスト最適化に役立つ貴重なデータが含まれています。

権限の管理を誤ると、制限されたデータへの不正アクセスや改変のリスクが高まり、サービスの可用性が損なわれます。

サービス アカウントは、個人ではなくアプリケーションまたは VM によって使用される特別な Google アカウントで、エンド ユーザーに代わって自動化されたプロセスを実行したり API リクエストを行うために、機密性の高いアクセス許可を使用します。信頼性を確保するために、慎重に管理、制御、および監査する必要があります。サービス アカウント ロールを IAM ユーザー (通常は人を表す) に割り当てると、セキュリティ制御が弱まります。

不要なネットワーク トラフィックのブロックに失敗すると、クラウド サービスの攻撃対象領域が拡大します。一般に公開されているサービスは、悪意のあるエンティティによるほぼ継続的なスキャンとプロービングの対象になります。

カスタマーマネージド暗号鍵 (CMEK) は、保存データに対して有効になっていません。

デフォルトでは、Google Cloud はランダムに生成されたデータ暗号鍵 (DEK) を使用して保存データを暗号化します。CMEK 機能を使用すると、組織は、選択した暗号化キーを使用して DEK を暗号化できます。これにより、組織は暗号化プロセスをより適切に制御し、ログに記録できます。

そのため、CMEK は通常、次のような要件 (これに限らない) に対処するソリューションの一部です。
- 機密データへのアクセスの監査ログ
- データ所在地
- キーの交換、無効化、または破棄
- 改ざん防止ハードウェア セキュリティ モジュール

カスタマーマネージド暗号鍵 (CMEK) は、保存データに対して有効になっていません。

デフォルトでは、Google Cloud はランダムに生成されたデータ暗号鍵 (DEK) を使用して保存データを暗号化します。CMEK 機能を使用すると、組織は、選択した暗号化キーを使用して DEK を暗号化できます。これにより、組織は暗号化プロセスをより適切に制御し、ログに記録できます。

そのため、CMEK は通常、次のような要件 (これに限らない) に対処するソリューションの一部です。
- 機密データへのアクセスの監査ログ
- データ所在地
- キーの交換、無効化、または破棄
- 改ざん防止ハードウェア セキュリティ モジュール

URL マップは、受信 HTTP(S) リクエストを特定のバックエンド サービスにルーティングするための一連のルールです。デフォルトでは、URL マップは、暗号化されていない接続やセキュリティ保護されていない接続を受け入れます。このような接続では、データが不正アクセス、盗難、改ざんの危険にさらされます。

例 1: 次の例は、https_redirect を false に設定することで、クライアントが通信で HTTP を使用することを許可する URL マップを定義する Terraform 構成を示しています。

resource "google_compute_url_map" "urlmap" {
...
  default_url_redirect {
...
    https_redirect = false
...
  }
...
}

DNSSEC は、DNS 応答の検証にデジタル署名を使用する機能を提供することにより、DNS 偽装を防止します。ただし、SHA-1 を使用する DNSSEC 署名アルゴリズムは、増え続ける攻撃のリスクには脆弱です。SHA-1 は、デジタル署名で使用される場合、安全なハッシュ アルゴリズムとは見なされなくなりました。

例 1: 次の例は、安全ではない署名アルゴリズム rsasha1 を使用して DNSSEC を有効にする Terraform 構成を示しています。

resource "google_dns_managed_zone" "zone-demo" {
...
  dnssec_config {
    default_key_specs {
      algorithm = "rsasha1"
      ...
    }
  }
...
}

GKE は、2 つのクラスター ネットワーク モード (ルートベースと VPC ネイティブ) をサポートします。VPC ネイティブのクラスターは、エイリアス IP アドレスの範囲を使用して、ノード内のあるポッドから別のポッドにトラフィックをルーティングします。これにより、ポッドに対する正確な IP ベースのポリシーとファイアウォール ルールが可能になります。一方、ノード全体で詳細なレベルの制御を実現するのがルートベースのクラスターです。

例 1: 次の Terraform 構成の例では、networking_mode を ROUTES に設定しているため、VPC ネイティブのクラスターが有効になっていません。

resource "google_container_cluster" "cluster_demo" {
...
  networking_mode = "ROUTES"
..
}

X-XSS-Protection は、他のブラウザーで採用されたために Microsoft が導入した HTTP ヘッダーです。これは、Cross-Site Scripting 攻撃が成功しないようにするものですが、図らずも安全な Web サイトを脆弱にしてしまうことになりました [1]。このため、この HTTP ヘッダーは以前のバージョンの Internet Explorer では使用しないでください。また、ヘッダーを 0 に設定して無効化する必要があります。

例 1: 次の例では Express アプリケーションで Helmet ミドルウェアを不適切に設定してすべてのバージョンの Internet Explorer でこれを有効にします。

var express = require('express');
var app = express();
var helmet = require('helmet');

...
app.use(helmet.xssFilter({ setOnOldIE: true}));
...

MIME スニッフィングとは、バイト ストリームのコンテンツを調べて、そのストリーム内のデータのファイル フォーマットを推定する手法です。

MIME スニッフィングが明示的に無効化されていないと、攻撃者が一部のブラウザーを操作して意図されない方法でデータが解釈されるようにすることがあるため、Cross-Site Scripting 攻撃が許容されてしまいます。ユーザーが制御可能なコンテンツを含む可能性がある各ページに対しては、HTTP ヘッダー X-Content-Type-Options: nosniff を使用する必要があります。

例 1: 次のコードでは、Spring Security で保護されるアプリケーションで MIME スニッフィング保護を無効化するよう設定します。

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-type-options disabled="true"/>
        </headers>
	</http>

次の場合にコンパイラ最適化エラーが発生します。

1. 機密データがメモリに格納されている場合。

2. 機密データが、内容を上書きすることによってメモリから消し去られる場合。



3. ソースコードが最適化コンパイラを使用してコンパイルされている場合。最適化コンパイラは、そのメモリがそれ以降使用されないという理由で、内容を上書きする関数を無駄な格納域と識別して削除します。
例 1: 次のコードでは、ユーザーからパスワードを読み込み、パスワードを使用してバックエンドのメインフレームに接続してから、memset() を使用してパスワードをメモリから消し去ろうと試みています。

  void GetData(char *MFAddr) {
  char pwd[64];
  if (GetPasswordFromUser(pwd, sizeof(pwd))) {
   if (ConnectToMainframe(MFAddr, pwd)) {
		 // Interaction with mainframe
	 }
  }
  memset(pwd, 0, sizeof(pwd));
}

この例のコードは、逐語的に実行される場合は適切に動作しますが、コードが Microsoft Visual C++(R) .NET や GCC 3.x などの最適化コンパイラを使ってコンパイルされた場合、バッファ pwd が値の上書き後に使用されないため、memset() のコールは無駄な格納域として削除されます [2]。バッファ pwd には機密性の高い値が含まれるため、データがメモリに常駐したままになるとアプリケーションが攻撃に対して脆弱になる場合があります。攻撃者がメモリの適切な領域にアクセスできる場合、パスワードを回復してシステムを制御できる可能性があります。

攻撃者にシステムの機密事項がわからないように、メモリで操作されるパスワードや暗号鍵などの機密性が高いデータは上書きするのが普通です。しかし、最適化コンパイラを使用した場合、プログラムはソースコードのみが推奨する方法で常に動作するとは限りません。この例の場合、書き込み先のメモリがそれ以降使用されないため、明確にセキュリティ上の理由があるにも関わらず、コンパイラは memset() のコールを Dead Code と解釈しています。ここでの問題は、多くのコンパイラやプログラム言語では、効率の向上を目指すあまり、個別的なセキュリティ上の懸念材料が考慮に入れられていない点にあります。

攻撃者は通常、このタイプの脆弱性を悪用して、コアダンプまたはランタイムメカニズムを利用し、特定のアプリケーションが使用するメモリにアクセスして機密情報を回復します。機密情報にアクセスした攻撃者は比較的簡単にさらにシステムを悪用することができ、アプリケーションとやり取りする他のリソースが危険にさらされるおそれがあります。

配列チェックにおいて、不正なポインターの計算およびそのポインターが境界外にあるかどうかの判断が実行される場合、一部のコンパイラでは「プログラマが意図的に不正なポインターを作成することは決してない」という前提のもとに、このチェックが最適化によって削除されます。

例 1:

  char *buf;
  int len;
  ...
  len = 1<<30;

  if (buf+len < buf)  //wrap check
    [handle overflow]

buf + len という操作は 2^32 よりも大きいため、結果の値は buf よりも小さくなります。しかし、ポインタ上の算術オーバーフローは未定義の動作であるため、一部のコンパイラでは buf + len >= buf だと判断され、ラップ チェックが最適化で削除されます。そのような最適化が実行された結果、このブロックの後に続くコードが Buffer Overflow に対して脆弱にある可能性があります。

Django アプリケーションは、実運用環境に配置するように設計されていない static files アプリケーションの serve ビューを開示します。Django のマニュアルには次のように記載されています。

「static files ツールは、大部分において、実運用に静的ファイルを配置する作業を支援する目的で設計されています。これは多くの場合、ローカルで展開するときに大変な経費となる別個の専用静的ファイル サーバーを意味します。そのため、静的ファイル アプリに簡易ヘルパー ビューが付属します。これを利用し、開発にローカルにファイルを提供できます。

このビューは DEBUG が True の場合にのみ機能します。

そのため、このビューは著しく非効率的であり、おそらく安全ではありません。ローカルでの開発のみを意図しており、実運用では決して使用しないでください。」

機密情報が含まれる、または特権機能を提供するアプリケーション リソースは、一般的に危険にさらされる可能性が高くなります。調査の段階で、攻撃者はそのようなファイルやディレクトリを見つけようとします。そのようなリソースに予測可能な命名規則を利用すると、攻撃者はリソースの位置を簡単に発見できます。認証、管理タスク、個人情報の取り扱いなど、機密機能に関連するアプリケーション リソースはすべて、発見されないように十分に保護する必要があります。

例 1: 次の例では、admin アプリケーションが予測可能な URL に配置されます。

from django.conf.urls import patterns
from django.contrib import admin

admin.autodiscover()

urlpatterns = patterns('',
    ...
    url(r'^admin/', include(admin.site.urls)),
    ...

データの保存を担当するリソースは、アプリケーション機能を実装するリソースから離す必要があります。プログラマーは一時的なリソースまたはバックアップ リソースを作成するときに注意する必要があります。

ほとんどの Web アプリケーションは、セッション ID を使用してユーザーを一意に識別します。これは通常 cookie に保存され、サーバーと Web ブラウザー間で透過的に送信されます。


セッション ID を cookie に保存しないアプリケーションは、HTTP リクエスト パラメーターとして、または URL の一部としてセッション ID を送信することがあります。URL で指定されたセッション ID を受け入れると、攻撃者はセッション ID 固定化攻撃を実行しやすくなります。

URL にセッション ID を含めると、アプリケーションに対するセッション ハイジャック攻撃の成功率も高くなります。セッション ハイジャック攻撃は、攻撃者が被害者のアクティブなセッションまたはセッション ID を制御すると発生します。Web サーバー、アプリケーション サーバー、および Web プロキシが要求された URL を保存するのは一般的な動作です。セッション ID が URL に含まれている場合、それらはログにも記録されます。セッション ID が表示および保存される場所が増えると、攻撃者に侵害される可能性も高くなります。

Tomcat を使用して認証を実行している場合、Tomcat 配置ディスクリプタファイルで、認証に使用される「レルム (Realm)」が指定されます。次のようになります。

例 1:

  <Realm className="org.apache.catalina.realm.JAASRealm"
         appName="SRN"
         userClassNames="com.srn.security.UserPrincipal"
         roleClassNames="com.srn.security.RolePrincipal"/>

この Realm タグでは、ログレベルを示す debug と呼ばれる属性をオプションで使用できます。数字が大きいほど、ログメッセージが詳細になります。デバッグレベルに非常に高い数字が設定されると、Tomcat ではログファイルにすべてのユーザー名とパスワードが平文で書き込まれます。Tomcat の JAASRealm に関連するデバッグメッセージの境界は 3 (3 以上は不適切、2 以下は適切) ですが、Tomcat で提供される他の種類のレルムでは、この境界が異なることがあります。

Struts や Spring などの Web フレームワークを使用して構築されたアプリケーションで Java Server Pages (JSP) に直接アクセスし、アクションまたはサーブレットを使用してリクエストを JSP に委任すると、未処理の例外やシステム情報の漏洩が発生する可能性があります。実装や設定が不十分なアプリケーション サーバーは、http://host/page.jsp%00 や http://host/page.js%2570 などの特別に細工されたリクエストを介して、ソース コードの詳細情報の漏洩に利用されてきました。さらに悪いことに、ユーザーによる任意のファイルのアップロードをアプリケーションが許可していると、攻撃者はこのメカニズムを使用して悪意のあるコードを JSP の形式でアップロードし、アップロードされたページに、悪意のあるコードをサーバー上で実行するように要求する可能性があります。

例 1: 次の例は、ロール名に "*" を含む JSP への直接アクセスを明示的に許可する、不十分な構成のセキュリティ制約を示しています。これは、対応する Web リソースへのアクセスをすべてのユーザーに許可することを示しています。

<security-constraint>
    <web-resource-collection>
        <web-resource-name>JSP Access for Everyone!</web-resource-name>
        <description>Allow any user/role access to JSP</description>
        <url-pattern>*.jsp</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>*</role-name>
    </auth-constraint>
</security-constraint>

セキュリティ ロールの重複には意味がありません。特定のセキュリティ ロールの最後の定義のみが適用されるためです。
例 1:web.xml ファイルのエントリは、2 つの admin ロールを定義します。

<security-constraint>
    <web-resource-collection>
        <web-resource-name>AdminPage</web-resource-name>
        <description>Admin only pages</description>
        <url-pattern>/auth/noaccess/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Administrators only</description>
        <role-name>admin</role-name>
    </auth-constraint>
</security-constraint>
...
<security-role>
    <description>Administrator</description>
    <role-name>admin</role-name>
</security-role>

<security-role>
    <description>Non-Administrator</description>
    <role-name>admin</role-name>
</security-role>

サーブレット マッピングの重複には意味がありません。複数のサーブレット マッピングで同じ URL パターンが使用されていても、最後のエントリのみが適用されるためです。

例 1: 次の例では、2 つの異なるサーブレット マッピングで、URL パターン /servletA/* が使用されます。

<servlet-mapping>
    <servlet-name>ServletA</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>ServletB</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>