• 戻る（Azure Subscriptionの管理@エンプラ）

FgCF は、MSKK がコンサル内容を、汎化して一般公開しているものらしい。

責任範囲	対象	対応
クラウド利用者の責任範囲	自システムの設計・運用に関する安全性（具体例： ネットワーク閉域性の維持）	自社固有のルールとしての検討が必要
クラウド利用者の責任範囲	自システムの基本的な安全性（具体例： CIS Controls への準拠）	Azure Security Center で実装
クラウド事業者の責任範囲	ファシリティ（データセンタ）とサービスの基本的な安全性（具体例： ファシリティスタンダード）	各種の規制対応状況などの情報を Web 提供

※ CIS Controls は、NIST の SP800-53 で定義されている事項のサブセットで、
　 「最初に最低限行わなければならない」ことに着眼してまとめられたフレームワーク

補足（責任共有モデル）: この表は、いわゆる責任共有モデル
（Shared Responsibility Model）を 3 段に分けたものである。
実務で問題になるのは常に最上段、
すなわち「自社固有のルールとして検討が必要」な部分であり、
ここに答えを与えようとしたのが FgCF である、という位置づけになる。

なお、Azure Security Center は現在
Microsoft Defender for Cloud に改称されている。

• 適切な技術回帰により自社の Tech Intensity（技術を自ら実践的に使いこなす力）を高める
• 競争領域に関しては、内製型アジャイル開発にシフトして、継続的に企業競争力を強化する
• 非競争領域に関しては、アウトソースを活用しながらも、開発の主導権は自社できちんと握って適切な開発を進める

• 閉鎖的な IT 環境 : 境界セキュリティを前提とした IT 環境
• 新技術導入がしにくい社内ルール : 最新技術の積極活用を拒む過度なルール
• IT 人材の技術力不足 : 最新技術を利活用できない・手を動かせないレガシー人材の増加

• IT インフラ全体を

  • 目先の話に留まらず、

    • セキュリティ強化
    • サーバ環境のクラウド化
    • リモートワーク対応

  • ゼロトラスト・モデルにモダナイゼーション

  • 企業全体の DX 推進の礎とする。

• すべての端末・サーバをマイクロ・セグメンテーションし、
  ユーザから見て、SSO で、どの端末から、どこのサーバへも行けるようにする。

• GitHub 上にインデックス・ページがある。

  • GitHub - nakamacchi/fgcf:
    Financial-grade Cloud Fundamentals
    https://github.com/nakamacchi/fgcf

• 以下のようなコンテンツを含んでいる。

  • ゼロトラスト型マルチクラウド環境を念頭に置いて、
    どのように OA 環境や DC 環境を構成すべきかという全体構成論

  • 仮想ネットワークや Azure AD、IaaS VM など、
    Azure 技術に関する実践的な視点からの解説

  • より具体的に IaaS VM や PaaS Web Apps, AKS などを利用して、
    どのようにシステムを構成すべきかのリファレンス・アーキテクチャ

先ず「ゼロトラスト型マルチクラウド IT 環境」を確認する。

• ゼロトラスト入門編
  ≒ ゼロトラスト

• OA 環境設計

  • ≒ 既存環境からの移行ステップ
  • ≠ 開発環境（...

• Azure Well-Architected Framework - Security

更に「Azure による仮想データセンタ構築手法 - 共通技術」として以下を学習する。

• VDC 構築の進め方の全体像

• ネットワーク基盤の構築方法

  • Azureの仮想ネットワーク（基礎）

    • Azure Virtual Data Center
    • Azureの高可用性設計
    • Azureによる基盤開発法

  • ARM テンプレートの利用方法

• 認証基盤の構築方法

  • Azure Active Directory
  • Azureのアクセス制御と権限
  • AzADirectoryのテナント作成方法

• IaaS の構成方法

  • Azure Virtual Data Center
  • Azureの仮想ネットワーク
  • Azureの仮想マシン

• DaaS の構成方法

• PaaS の構成方法

  • AKSをセキュアに利用するためのテクニカルリファレンス
  • AppService閉域構成テクニカルリファレンス
  • ARO (Azure Red Hat OpenShift)...（Azure Red Hat OpenShift）
  • Azure Batch...

• DevOps の構成方法

  • Azure DevOps

※ 開発環境については OA 環境と同列に語れない。

• どこかの団体で規定されるような、正式な定義が存在しない（アイディアでありコンセプトの収集）

• 長いサイクルによる複数の手段で成り立つ（それは 20 年、30 年かかるインフラかもしれない）

• コンプライアンスは事業継続において必要不可欠であるが戦略ではない。

  • セキュリティ実装と投資をしてコンプライアンスを守っても侵入され結果につながらなかった。
  • セキュリティ Outcome ではなくビジネス Outcome にフォーカスする。
    侵害があった場合、損害と失敗を引き起こす、守るべき資産を考えることが重要になる。

補足（最新化）: 「正式な定義が存在しない」という指摘は執筆時点のもので、
その後 NIST SP 800-207 "Zero Trust Architecture"（2020 年）が
事実上の参照定義として広く用いられるようになった。
ただし「製品を買えばゼロトラストになるわけではない」
「長期の取り組みである」という原文の主張は、SP 800-207 の立場とも一致しており、
後述の「微妙なゼロトラスト」の指摘は現在も有効である。

境界型ネットワークの問題

• 「中は安全、外は危険」という、ある意味では非常に雑な、バルク（セグメンテーション）保護

• ...と言う事で、クラウド活用が進む中、境界型ネットワークがアンマッチに。
  コレを維持しようとすると、「境界」をいたずらに肥大化させるようなアプローチになる。

  • 閉域縛り：オンプレのみ。
  • みなしオンプレ：VPN 接続＋閉域と同じセキュリティ・ポリシ等（オンプレ延伸）
  • みなし閉域：XaaS に、IP アドレス制限をかける

• ソリューションとして
  「ゼロトラスト型ネットワーク」がある。
  ゼロトラスト化で、以下が期待できる。

  • 社内 LAN が閉域でなくても一定の安全性を保てるようになる。
  • セキュリティ向上だけではなく IT のアジリティ向上にも役立つ。
  • それ以外にも、回線や SaaS 化によるコスト最適化につながる。

補足（「境界の肥大化」という指摘）: 3 つの「みなし」は、
いずれも境界型の発想のままクラウドを取り込もうとした結果である。
この見立ては Azure Private Endpoint や
Azure Firewall の「ユーザ・テナント単位で絞れない」
という問題と地続きで、

• 閉域化のコストと運用負荷が青天井に増える一方、
• アプリ脆弱性や内部不正には効かない、

という費用対効果の悪さに行き着く。
Azure Virtual Data Center の
「Weakest Link」の議論と併せて読むとよい。

• トラストのベースは主体（ID）の信頼性（正当性）

• 戦略的考え方

  • 新しい論理的なセキュリティ境界を作り出す技術要素を活用し、
  • ネットワークをマイクロ・セグメンテーションすることで、
  • ラテラル・ムーブメントを防ぐリバレッジ（増幅効果）を得る。
  • これは、詳細なエンフォースメント（法執行）により実行される。

• 参考：ゼロトラスト - 開発基盤部会 Wiki

• 「ネットワーク経路」は、一要素でしかない
  様々な要素を総合的に判断できる仕組み・仕掛を導入

  • クレデンシャル情報

    • パスワード
    • 多要素認証（生体認証・ワンタイムパスワード）

  • ユーザ・コンテキスト（ユーザ・プロファイル情報）

  • ロケーションに基づくポスチャ（認証後の振る舞い）

※ Azure AD の
条件付きアクセスによりこれが実現されている。

• ID 管理・権限制御

• ハードニング

  • サーバ保護
  • デバイス保護

• 情報保護・統制

  • サーバ
  • デバイス

• ログ収集・監査

  • サーバ
    サーバ保護

  • デバイス
    デバイス保護

• ゼロトラスト型ネットワーク書籍の中で語られている
  ラテラル・ムーブメントを防ぐセグメンテーション戦略

• ≒ 自宅 Wi-Fi の隔離機能
  SSID に接続している無線機器は Internet 側とだけ通信可能になる。

• 注意すべきポイント
  端末系とサーバ系とで

  • 粒度が異なる。

    • 端末系
      端末単位でセグメンテーション

    • サーバ系
      論理的（業務的）な意味で管理し易い業務システム

  • 阻害要因が異なる。

    • 端末系
      ...
    • サーバ系
      システムの重要性などに応じて、認証・認可制御の選択が必要。

• 実践；既存環境からの移行ステップ

• 原点

  • 近代的なセキュリティを考える上では最も重要（原点）
  • ラテラル・ムーブメントの防止
    • → マイクロ・セグメンテーション
    • → ゼロトラスト型ネットワーク

• 要素

  • 構成要素

    • ラテラル・ムーブメント ＝ 水平攻撃・水平移動
    • マイクロ・セグメンテーション戦略による抑止
    • その他
      ・堅牢な認証基盤による主体（プリンシパル）の確実な特定（否認の抑止）
      ・SIEM（Azure Sentinel など）による遠隔監視・制御の仕組み

  • 技術要素

補足（なぜラテラル・ムーブメントが「原点」なのか）: 侵入そのものを
100% 防ぐことはできない、という前提（Assume Breach）に立てば、
被害の大きさを決めるのは侵入後にどれだけ横に広がれるかである。

【境界型】 1 台侵害 → 内部は相互に到達可能 → 全体が危険
【ゼロトラスト】1 台侵害 → 横移動が都度検証で止まる → 被害が局所化

本文が「マイクロ・セグメンテーション → ゼロトラスト」という
順序で説明しているのは、この因果を踏まえたもので、
「ゼロトラストという製品を入れる」話ではないことを示している。

• 戦略
  ハイ・セキュアゾーン（≒境界型ネットワーク）は現行を維持

  • ハイ・セキュアゾーンを隔離して、ゼロトラスト型ネットワーク化を推進する。
  • ハイ・セキュアゾーン（≒オンプレ）も段階的にゼロトラスト型ネットワーク化する。
  • これにより、全体が閉域でないと安全性を担保できない、という状態から脱却できる。

• 構成
  ロー・セキュアゾーンをゼロトラスト型ネットワーク化して行く。

  • ロー・セキュアゾーンの拡張を原則として禁止

  • 新規開発システムはゼロトラスト型ネットワーク型で開発
    （ロー・セキュアゾーン → ゼロトラスト・ゾーン）

• VPN Gateway
• Azure ExpressRoute
• Azure Peering Service

※ IP アドレスの枯渇や、ラテラル・ムーブメントの防止などが課題

Hub & Spoke 構成の仮想ネットワークで
マイクロ・セグメンテーションした構成

• IaaS / PaaS 活用：ゼロトラスト型構成の仮想ネットワーク

• SaaS 活用：Azure Peering Service

• DaaS 活用
  ユーザは

  • ゼロトラスト・ゾーン → ハイ・セキュアゾーンの境界越えに DaaS を利用
  • ゼロトラスト・ゾーンで、ファット・クライアントを利用（→ ローカル活用）

ローカルから、ゼロトラスト・ゾーンへ侵入を許可する。

• デバイス保護が必要になる。

• 経路

  • 強制 VPN 収容（新規 VNET を作成）
  • ローカル・ブレイクアウト
    クラウドサービスのトラフィックを識別して
    企業拠点から直接インターネットに送出する方法

野良クラウド（シャドウ IT）は危ない。

• ハードニング
  Azure Security Center

• インバウンド
  AzureのGW / LB的なモノ。

  • DaaS
  • Azure Application Gateway
  • Azure Private Link / Endpoint

• アウトバウンド
  Azureのプロキシ的なモノ。

  • Azure Firewall（フィルタ / ログ）
  • Azure Private Link / Endpoint

• 最低限

  • 課金モニタリング
  • 環境モニタリング

BYOD は危ない。

• ハードニング
  EDR & TVM（Endpoint Protection、マルウェア対策的な。

  • Endpoint Detection & Response
  • Threat Vulnerability Management

• 行動制限
  安全なサービスのみに接続先を制限

  • クラウドプロキシ型
  • 端末エージェント型

• 行動ログ取得
  端末上での作業内容を記録

  • DaaS 録画型
  • 端末エージェント型

※ ローカルの完全な保護が難しいとなるので、以下の措置に行きやすい。

• ローカルネットワークの制限

  • アウトバウンド：プロキシ適用
  • インバウンド：FW 適用

• 専用のシン・クライアント端末。

ゼロトラストは、
「あらゆる要素を検証し信用を積み上げ、その信用に応じたアクセスを提供」
と言うコンセプトなので、単体での対策は ≒「微妙なゼロトラスト」となる。

• 何も信用しないゼロトラスト
  ＝思いつくセキュリティ施策を全部やる
  単に今までのセキュリティ施策を全部重ねがけしただけ。

• マイクロ・セグメンテーションでゼロトラストを実現する
  ＝サーバ単位にネットワークを隔離してハードニング
  （そしてネットワーク監視ソリューションを売り込む）

• クラウドプロキシによりゼロトラストを実現する
  ＝単にネットワークまわりの通信制御の面倒ごとを 1 box 化しただけ

• 動的認可ポリシーエンジンでゼロトラストを実現する

  • 動的認可ポリシーエンジン＝信用スコアを用いた動的な認可の制御
  • ＝考え方としては正しいものの製品が追い付いていない場合には絵に描いた餅

補足（この節が本ページの白眉）: 4 つの「微妙なゼロトラスト」は、
いずれも部分最適を全体解と称しているという共通の構造を持つ。
現在も「ゼロトラスト対応製品」の売り込みで繰り返される論法であり、
判定基準としてそのまま使える。

なお、4 番目の「動的認可ポリシーエンジン」については、
Azure AD の条件付きアクセスに
サインイン リスク / ユーザー リスク（Identity Protection）や
継続的アクセス評価 (CAE) が実装され、
執筆時点よりは「絵に描いた餅」ではなくなっている。

http://nakama.azurewebsites.net/?p=78

• https://github.com/nakamacchi/fgcf

• おうちゼロトラストから学ぶ実践的セキュリティ強化

• VDI や DaaS 等のソリューションがある。

• ハイ・セキュアゾーンへの入り口に必要。

• ユーザは

  • ゼロトラスト・ゾーンに接続し、
  • ハイ・セキュアゾーンへはシン・クライアントで入る。

---

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