Go to Qiita Advent Calendar Top
LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@wf-kenji-ikeda

クラウドインフラ・アプリケーションセキュリティ設計書 目次構成案

Posted at

1. システム概要とアーキテクチャ定義

  • 1.1 全体システム構成図

    • (VNet、Bastion、VM、ACR の配置図)

    • 後で図化

      ・開発環境
- インターネットより、Azure bastionを経由してAzureVm(windows)へリモートデスクトップする
- AzureVm(windows)ではコンテナ上でアプリを稼働させる
- コンテナイメージは内部のコンテナレジストリから取得する

・検証環境
- インターネットよりHTTP接続し、Azurevm(Linux)でdify entra id認証を行う
- AzureVm(Linux)ではコンテナ上でアプリを稼働させる
- コンテナイメージは内部のコンテナレジストリから取得する
- 検証環境には、プライベートネットワークを介して開発環境からアクセス可能

  • 1.2 環境定義と通信フロー

    • 開発環境（Bastion 経由 RDP、コンテナ稼働、インターネット遮断）
    • 検証環境（HTTP 経由 Dify 利用、Entra ID 認証、インターネット遮断）
    • 内部連携（開発 VNet⇔ 検証 VNet 間の許可された通信）

  • 1.3 ネットワーク境界定義

    • インターネット境界（Inbound のみ許可/Outbound 完全遮断）
    • セグメント間境界（NSG による開発・検証間の最小権限アクセス）

2. 保護対象資産の特定

  • 2.1 情報資産
    • Dify ナレッジデータ（機密性：高）
    • ユーザー認証情報（Entra ID トークン、VM 管理者 ID）
    • コンテナイメージ・ソースコード（知的財産）
  • 2.2 重要機能
    • Dify アプリケーションの応答機能（可用性）
    • 開発環境の作業継続性

3. 脅威分析（リスクアセスメント）

  • 3.1 外部からの攻撃シナリオ
    • [cite_start]不正アクセス: Bastion や Web 公開部に対する総当たり攻撃、脆弱性悪用 [cite: 160]
    • なりすまし: Entra ID 認証の突破、セッションハイジャック
    • [cite_start]DoS 攻撃: 認証基盤や Web エンドポイントへの負荷攻撃 [cite: 178]
  • 3.2 内部・サプライチェーンの脅威
    • ラテラルムーブメント: 開発環境を踏み台とした検証環境への侵入
    • 汚染イメージの混入: 脆弱性やマルウェアを含むコンテナイメージの展開
    • 内部不正: 開発者によるデータの持ち出し
  • 3.3 インターネット遮断環境特有のリスク
    • パッチ未適用: 外部リポジトリに接続できないことによる OS・ライブラリの陳腐化

4. テクニカルセキュリティ対策要件

本資料の「3.2 セキュリティ対策の検討」および IPA「クラウドセキュリティガイドライン」を統合

  • 4.1 アイデンティティとアクセス管理 (IAM)
    • Entra ID 設計: 条件付きアクセス（社内 IP 制限、デバイス認証）、多要素認証(MFA)の強制
    • 特権 ID 管理: VM 管理者アクセスの Just-In-Time (JIT) VM Access 利用検討
    • Managed Identity: VM から ACR/KeyVault へのパスワードレス接続
  • 4.2 ネットワークセキュリティ
    • Azure Bastion: NSG による接続元 IP 制限、標準 SKU を用いた運用
    • NSG 設計: Outbound Deny All 設定と、Azure 基盤通信（AzurePlatformDNS 等）のみの許可
    • Private Link: ACR および Key Vault へのプライベートエンドポイント接続
  • 4.3 コンピューティング・コンテナ保護
    • OS 堅牢化: 不要サービスの停止、CIS Benchmark 等の適用
    • コンテナセキュリティ: 特権コンテナ(Privileged)の禁止、ReadOnly Root Filesystem の検討
  • 4.4 データ保護と暗号化
    • 保存データの暗号化: Managed Disk の暗号化(ADE/SSE)
    • [cite_start]通信の暗号化: HTTPS(TLS 1.2 以上)の強制 [cite: 207]
    • [cite_start]鍵管理: Azure Key Vault を用いた証明書・シークレットの一元管理とアクセス制御 [cite: 1121]

5. セキュアな運用・保守プロセス（閉域網対応）

  • 5.1 安全な資材搬入・更新プロセス（Secure Import Pipeline）
    • コンテナイメージ搬入: 検疫済みレジストリから ACR へのインポート手順
    • OS パッチ適用: オフライン WSUS 構築またはイメージ再作成（Immutable Infrastructure）方式の採用
  • 5.2 脆弱性管理
    • スキャン: ACR Upload 時の脆弱性スキャン（Defender for Cloud 等）の実施
    • 対応フロー: 検知された脆弱性の修正と再デプロイの流れ
  • 5.3 ログ監視と監査
    • 監査ログ: Entra ID サインインログ、ACR アクセスログの保存
    • 操作ログ: Bastion のセッション録画または操作ログの取得

6. 可用性と災害復旧 (BCP)

本資料の脅威分析における「可用性の侵害」への対策

  • 6.1 バックアップ計画
    • VM イメージおよびデータディスクのバックアップ頻度と保存先（Azure Backup）
  • 6.2 復旧手順
    • 障害時の切り戻し手順、再構築手順

7. 付録：設定詳細・チェックリスト

  • 7.1 暗号技術利用チェックリスト (本資料「付録 C」準拠)
    • [cite_start]採用する TLS バージョン、暗号スイート、鍵長の定義 [cite: 1459]
  • 7.2 ネットワークアクセス制御リスト (ACL)
    • NSG ルール詳細定義書

以下に、Azure VM における代表的なセキュリティ対策を 5 つの主要なカテゴリに分けて解説します。

1. ネットワークセキュリティ（侵入を防ぐ）

外部からの不正アクセスを防ぐ、最も基本的かつ重要なレイヤーです。

  • Network Security Groups (NSG) の適用
    • 概要: ファイアウォールのような機能で、通信の許可/拒否を制御します。
    • 対策: 不要なポートは全て閉じ、必要なポート（Web サーバーなら 80/443 など）のみを許可します。インターネット全体（Any）からの接続許可は極力避けます。
  • Azure Bastion の利用（管理ポートの保護）
    • 概要: ブラウザ経由で安全に VM へ RDP/SSH 接続するサービスです。
    • 対策: VM にパブリック IP アドレスを付与せず、管理ポート（3389/22）をインターネットに公開しないようにします。これにより、総当たり攻撃（ブルートフォース攻撃）を無効化できます。
  • Just-in-Time (JIT) VM Access
    • 概要: 必要な時だけ、必要な時間だけ管理ポートを開放する機能です（Microsoft Defender for Cloud の一部）。
    • 対策: 常時ポートを開けておくリスクを排除します。

2. ID とアクセスの管理（権限を絞る）

誰が VM を操作できるかを厳密に管理します。

  • RBAC (ロールベースのアクセス制御)
    • 概要: ユーザーやグループごとに、必要な権限のみを付与する仕組みです。
    • 対策: 全員に「所有者」権限を与えるのではなく、運用担当者には「仮想マシン共同作成者」などを付与し、最小特権の原則を徹底します。
  • マネージド ID (Managed Identity) の活用
    • 概要: VM 自体に Azure AD（Entra ID）上の ID を持たせる機能です。
    • 対策: アプリケーションコード内に接続文字列やパスワードをハードコーディング（直書き）する必要がなくなり、クレデンシャル漏洩のリスクを防ぎます。

3. ホストと OS のセキュリティ（脆弱性を塞ぐ）

VM 内部および OS レベルでの対策です。

  • 更新プログラムの管理 (Azure Update Manager)
    • 概要: Windows/Linux のセキュリティパッチ適用を管理します。
    • 対策: OS の脆弱性を放置しないよう、定期的なパッチ適用を自動化または一元管理します。
  • マルウェア対策 (Microsoft Defender for Servers)
    • 概要: 旧 Azure Defender。ウイルス対策や EDR（脅威検知と対応）機能を提供します。
    • 対策: 不正なプロセスや怪しい挙動を検知し、アラートを発報・ブロックします。
  • Trusted Launch (信頼された起動)
    • 概要: 第 2 世代 VM で利用可能な、ブートキットやルートキットを防ぐ機能です。
    • 対策: セキュアブートや vTPM を利用して、OS 起動時の改ざんを防ぎます。

4. データの保護（情報を守る）

万が一侵入された場合や、物理ディスクが盗難された場合に備えます。

  • Azure Disk Encryption (ADE)
    • 概要: OS ディスクおよびデータディスクを暗号化します（Windows は BitLocker、Linux は DM-Crypt を使用）。
    • 対策: 仮想ハードディスクファイル自体が流出しても、データの中身を読み取れないようにします。
  • Azure Backup
    • 概要: VM 全体のバックアップを取得します。
    • 対策: ランサムウェア感染やデータ破損時に、正常な状態へ素早く復元できるようにします。

5. 可視化と統制（状況を把握する）

セキュリティの状態を常に監視し、設定ミスを防ぎます。

  • Microsoft Defender for Cloud (CSPM)
    • 概要: 環境全体のセキュリティスコアを可視化し、推奨事項（レコメンデーション）を提示します。
    • 対策: 「管理ポートが開いています」「ディスクが暗号化されていません」といった設定ミスを自動的に指摘してくれるため、これに従って修正することでセキュリティレベルを維持できます。

ご提示いただいたセキュリティ設計書作成計画のテキストを、可読性の高いマークダウン形式に整理しました。

セキュリティ設計書作成計画：Azure コンテナ・VM 環境

1. はじめに

本ドキュメントは、提示された Azure クラウド環境（開発・検証）のセキュリティ設計書を作成するための詳細な目次および検討事項のガイドラインである。

対象システム概要

  • 開発環境: Azure Bastion 経由での Windows VM 利用、コンテナ開発。
  • 検証環境: インターネット公開（HTTP）、Linux VM での Dify 稼働（Entra ID 認証）、開発環境からの内部アクセス。
  • 共通: 内部コンテナレジストリ（ACR 想定）の利用。

2. ネットワークセキュリティ設計

このセクションでは、不正アクセス防止と通信経路の保護について定義します。

2.1 境界防御 (Perimeter Security)

開発環境へのアクセス (Azure Bastion)

  • NSG (Network Security Group) 設計: Bastion サブネットへの Inbound 制限（特定の管理者 IP のみ許可するなど）。
  • Bastion SKU: Basic または Standard の選定（ログ記録や同時接続数の要件による）。
  • RDP アクセスの制限: VM 側でパブリック IP を持たず、Bastion 経由のみに限定する設定。

検証環境へのアクセス (HTTP/Web)

  • DDoS 保護: Azure DDoS Protection (Basic/Standard) の適用方針。
  • Web 層の保護: VM に直接パブリック IP を付与するか、前段に Azure Application Gateway (WAF) または Azure Load Balancer を配置するかの決定。

    推奨: VM への直接 HTTP 接続は避け、WAF またはリバースプロキシを配置して SQL インジェクションや XSS を防ぐ。

  • NSG 設計: HTTP (80) / HTTPS (443) のみを許可し、SSH 等の管理ポートはインターネットから遮断する。

2.2 内部ネットワークと環境間接続

VNet Peering (開発 ⇔ 検証)

  • 通信制御: 開発環境から検証環境へのアクセス要件の整理。全ポート開放ではなく、必要なポート（例: アプリ確認用ポート、DB ポート）のみを許可する NSG ルールを作成。
  • 分離: 開発環境が侵害された場合に検証環境へ波及しないためのセグメンテーション。

コンテナレジストリ (ACR) への接続

  • Private Endpoint (Private Link): コンテナイメージ取得において、インターネットを経由せず、Azure バックボーンネットワークのみを使用する構成。
  • ファイアウォール設定: ACR 側でパブリックアクセスを無効化し、特定の VNet からのみアクセス可能にする。

3. 認証・認可 (Identity & Access Management)

ユーザー認証とリソースへのアクセス権限を定義します。

3.1 アプリケーション認証 (Dify / Entra ID)

Microsoft Entra ID (旧 Azure AD) 統合:

  • アプリ登録 (App Registration): 検証環境アプリケーション（Dify）用のサービスプリンシパル作成。
  • 認証フロー: OIDC (OpenID Connect) または SAML の適用。
  • 条件付きアクセス (Conditional Access): 特定の場所、デバイス、MFA（多要素認証）の強制ポリシー策定。
  • RBAC (Role Based Access Control): Dify アプリ内での権限管理と Entra ID グループのマッピング。

3.2 インフラストラクチャ管理権限

Azure RBAC:

  • 開発者には「開発環境リソースグループ」への貢献者権限。
  • 検証環境へのアクセスは「閲覧者」または特定の操作のみに制限。
  • JIT (Just-In-Time) VM Access: Defender for Cloud を利用し、管理ポートへのアクセスを必要な時間だけ許可する運用（オプション）。

4. コンピューティング & コンテナセキュリティ

ホスト OS およびコンテナランタイムの保護について定義します。

4.1 VM (Host) セキュリティ

Windows VM (開発環境)

  • マルウェア対策: Microsoft Defender for Servers の有効化。
  • ディスク暗号化: Azure Disk Encryption (ADE) の適用。
  • パッチ管理: Windows Update の運用方針。

Linux VM (検証環境)

  • SSH 設定: パスワード認証の無効化（公開鍵認証のみ）、または Bastion 経由のみとする。
  • OS 強化: 不要なサービスの停止、最小権限の原則。

4.2 コンテナセキュリティ

コンテナイメージ管理

  • 脆弱性スキャン: ACR にプッシュされたイメージに対する自動脆弱性スキャン（Defender for Containers）。
  • 信頼されたベースイメージ: 公式イメージまたは検証済みイメージの使用義務付け。

ランタイムセキュリティ

  • 特権コンテナの禁止: privileged モードでの実行禁止。
  • リソース制限: CPU/メモリのリミット設定（DoS 対策）。
  • 環境変数: 機密情報（API キー、DB パスワード）をコードに埋め込まず、環境変数または Azure Key Vault から注入する仕組み。

5. データセキュリティ

5.1 データ保護

  • 保存データの暗号化 (Encryption at Rest): VM の Managed Disk、ACR のストレージ等の暗号化（デフォルトでプラットフォーム管理キーが使用されるが、顧客管理キー(CMK)が必要か検討）。
  • 転送データの暗号化 (Encryption in Transit):
    • 開発端末 ⇔ Azure Bastion (HTTPS)
    • インターネット ⇔ 検証アプリ (HTTPS 化の要否。HTTP のみの場合はリスク受容または SSL オフロードの導入)。
    • コンテナ ⇔ レジストリ (HTTPS)。

5.2 キー管理

  • Azure Key Vault: 証明書、接続文字列、API キーの集中管理。VM 内のコードや設定ファイルに直接クレデンシャルを書かない設計。

6. 運用・監視 (Operations & Monitoring)

6.1 ログ管理と監視

Azure Monitor / Log Analytics:

  • VM のシステムログ（Event Log, Syslog）。
  • NSG フローログ（ネットワークトラフィックの可視化）。
  • Entra ID サインインログ（不正アクセスの検知）。
  • Bastion の監査ログ。

アラート設定:

  • 異常なトラフィック、ログイン失敗の連続、マルウェア検知時の通知フロー。

6.2 バックアップと復旧

  • Azure Backup: VM および永続化データの定期バックアップスケジュール。

7. 設計書作成のためのチェックリスト

  • ネットワーク構成図の作成: サブネット、NSG、Peering、Bastion、Private Endpoint の位置関係を可視化。
  • 通信要件一覧: 「どこから」「どこへ」「どのポートで」の許可リスト作成。
  • Entra ID 設計: Dify 連携に必要な Redirect URI、Client Secret 管理方針の決定。
  • コスト試算: Bastion, Defender for Cloud, Key Vault などのセキュリティサービス利用に伴うコスト確認。

8. 【重要】設計・実装上の推奨事項

設計書を作成するにあたり、以下のリスクと対策を特に考慮してください。

8.1 HTTP 接続と SSL/TLS 化

  • 現状の課題: 要件に「インターネットより HTTP 接続」とありますが、認証情報（Entra ID トークンなど）を HTTP で送信するのは重大なセキュリティリスクです。
  • 推奨対策:
    • 必須: HTTPS 化を行うこと。
    • 方法: Azure Application Gateway 等のリバースプロキシで SSL オフロードを行うか、VM 内の Web サーバー（Nginx 等）で Let's Encrypt などの証明書を設定してください。

8.2 コンテナレジストリの閉域化

  • 現状の課題: コンテナイメージにはアプリケーションのコードや依存ライブラリが含まれるため、インターネット公開は避けるべきです。
  • 推奨対策: Azure Private Link (Private Endpoint) を使用し、ACR へのアクセスを VNet 内部（開発 VNet および検証 VNet）からのプライベート IP 接続のみに制限してください。

8.3 Dify と Entra ID の設定

  • 認証フロー: Dify の SSO 設定において、Azure Portal の「アプリの登録」で生成される「クライアント ID」と「クライアントシークレット」および「リダイレクト URL」を正しく Dify 側に設定する必要があります。
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?