Skip to content

MS_AzureVDC

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 2 revisions

Azure Virtual Data Center

概要

  • VDC : Virtual Data Center（仮想データセンター）

  • 製品・サービス名ではなく、
    デザイン・パターン（リファレンス・アーキテクチャ）

    • オンプレ延伸の意味で使用される。
    • 簡単に言うと、オンプレと VPN 接続された VNET など。

  • 構成設定変更が簡単かつ素早くできるが、
    不十分な知識だと極めて危険であり、
    正しい知識を持って正しく使う必要がある。

補足（最新化 / 位置づけ）: 「VDC」という呼称は、現在の Microsoft のドキュメント体系では
Cloud Adoption Framework (CAF) の "エンタープライズ規模（Enterprise-scale）" ランディング ゾーン
に発展的に置き換えられている（VDC のドキュメントは CAF のアーカイブ扱い）。

ただし、本ページが述べている
「Hub & Spoke で共有サービスを集約し、権限とネットワークを設計してから載せる」
という考え方そのものは、現在のランディング ゾーンの中核であり、まったく古びていない。
用語だけを読み替えれば、内容は現在も有効である。

詳細

リスクとアプローチ

リスク

  • リスク

    • 外部からの攻撃、不正アクセス
    • マルウェア、不正コード混入
    • オペミス、オペレータ不正（最も多い事故）

  • 影響

    • サービス停止、乗っ取り
    • 情報奪取、情報漏洩、情報流出、高額請求

  • 評価

    • 信頼度
      ベンダー ＞ 開発者 ＞ 運用担当者

    • ゼロリスク追求
      低生産性・高コストに

※ 参考：PMP：計画 - リスク（開発基盤部会 Wiki）

  • 対応

    • Defence in Depth
      多層防衛（複数レイヤで堅牢化するのが一般的だが）

    • Weakest Link

      • 「鎖の全体強度は、個々のリングの平均ではない。」の意味。
      • ≒ 足を引っ張る（脆弱なレイヤを突破されたらオシマイ）
      • 前述の「信頼度」から、全体のバランスを取る。
      • ゼロトラストの例で言えば、従来型の境界型ネットワーク
        ・Web Apps と SQL DB 間を閉域化する意味は、この間の通信のハックの防止。
        ・このハックを成功させるより、App 脆弱性を突いたり、内部侵入した方が簡単。

補足（この節の主張の核）: 「Weakest Link」の指摘は、
閉域化に投資しても、アプリの脆弱性や運用者の権限が緩ければ意味がない
という、コスト配分に関する警告である。
「オペミス・オペレータ不正が最も多い事故」という認識と合わせると、
ネットワーク閉域化よりも、権限管理（PIM）と作業の自動化・監査に
投資した方が費用対効果が高い場面が多いという結論になる。
以降の「アプローチ」「必要な対策」はこの結論から導かれている。

アプローチ

初期構築時と、構築後の構成変更とを分けて考える。

  • 初期構築時
    多種のリソース作成が必要、比較的強い権限で作業しないと大変

  • 構築後・運用中
    限定的な変更が多いため、限られた権限で作業した方が安全

必要な対策

  • 作業内容の安全性の確認

    • その作業が技術的に
      正しく安全なものか？

    • 定義の分類

      • 入力制御（インバウンド）
        ・呼び出し制限
        ・経路開放
        ・認証・認可
        ・攻撃検知

      • ハードニング（クライアント or サーバ）
        ・不要機能を無効化
        ・機能無効化
        ・高額請求抑止
        ・マルウェア対策
        ・透過的暗号化

      • 出力制御（アウトバウンド）
        ・外部呼び出し制限
        ・経路制限
        ・不正検知

  • 不正作業の防止・牽制

    • 過失による誤作業
      故意による不正作業
      をどう防ぐか？

    • 定義の分類

      • 事前検査（→ ASC ＋ 自作ツール）
        ・パラメタ・シートを作成
        ・事前にチェックしてから変更を実施
        ・定常的な保守作業を一覧化
        ・一覧の作業をスクリプト化して自動化

      • 権限付与（→ PIM）
        ・特権の剥奪
        ・最小権限を Just-in-Time で付与
        ・カスタムロールの作成要否や牽制方法を検討

      • 環境監査（→ ASC ＋ 自作ツール）
        不正な構成変更が行われていないかを確認

自動化

  • 必要性とメリット

    • 環境構築・変更作業の自動化
      手作業ではなく、ARM テンプレートやスクリプトを使う
    • 構成チェックの自動化
      目視ではなくツールによって構成の妥当性チェックを行う

  • 利用可能な技術

補足（最新化）: 現在は「自作ツールで環境チェック」に頼らずとも、
次の組み合わせでかなりの部分が標準機能で賄える。

目的 現在の標準的な手段
構成の記述 Bicep（ARM テンプレートの後継 DSL）/ Terraform
事前検査 デプロイの What-If、az deployment ... --what-if
継続的な構成監査 Azure Policy の audit ＋ 規制コンプライアンス
自動修復 Policy の deployIfNotExists ＋ 修復タスク
特権の Just-in-Time 付与 PIM（Azure AD Privileged Identity Management）
変更履歴の追跡 アクティビティ ログ ＋ Log Analytics

認証・認可

Azure Active Directory

ネットワーク

VNET に接続する。

ゲートウェイ

DHCP と DNS

Azure Bastion

ゼロトラスト VDC

VDC は基本、オンプレ延伸であるものの、

Weakest Linkで言及したように、

  • 境界型ネットワークの危険性から、
  • ゼロトラスト型ネットワークの概念が導入された、

ゼロトラスト VDC の重要性が高まっている。

補足: ゼロトラストの具体的な実装としては、
Azure AD の条件付きアクセス（デバイス / 場所 / リスクによる制御）、
Private Endpoint によるリソース単位の閉域化、
PIM による Just-in-Time 特権
といったものが挙げられる。
「境界（VNET）を信頼しない」＝「境界を作らない」ではなく、
境界に加えて ID とリソース単位でも検証するという多層化である点に注意。

サービス

セキュア化とロックダウン。

セキュリティ

補足（最新化）: Azure Blueprints は非推奨（2026 年 7 月に廃止予定）であり、
後継として Azure Deployment Stacks ＋ Azure Policy の
組み合わせ、または CAF の
Enterprise-scale ランディング ゾーン アクセラレータ（Bicep / Terraform）が案内されている。
新規に Blueprints を採用しないこと。

Azure 関連

参考

Microsoft Learn

nakama

FgCF > ゼロトラスト型マルチクラウド IT 環境 > Azure による仮想データセンタ構築手法

※ 体系・pwd は FgCF (Financial-grade Cloud Fundamentals)を参照。

VDC 構築の進め方の全体像

（共通技術 > VDC 構築の進め方の全体像）

IaaS の構成方法

IaaS の構成方法中にも同様のトピックが含まれる。

Tags: 移行, インフラストラクチャ, クラウド, セキュリティ, 通信技術, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally