Azure Well-Architected Framework - Security のバックアップ(No.15)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• Azure Well-Architected Framework - Security へ行く。
  • 1 (2021-02-09 (火) 22:53:13)
  • 2 (2021-02-09 (火) 23:51:22)
  • 3 (2021-02-10 (水) 15:17:35)
  • 4 (2021-02-10 (水) 15:40:41)
  • 5 (2021-02-11 (木) 00:51:42)
  • 6 (2021-02-11 (木) 13:32:12)
  • 7 (2021-02-11 (木) 23:47:40)
  • 8 (2021-02-12 (金) 00:00:17)
  • 9 (2021-02-13 (土) 00:45:47)
  • 10 (2021-02-13 (土) 11:40:51)
  • 11 (2021-02-24 (水) 11:25:08)
  • 12 (2021-02-25 (木) 09:32:43)
  • 13 (2021-02-26 (金) 22:16:29)
  • 14 (2021-03-01 (月) 20:18:14)
  • 15 (2021-03-02 (火) 21:34:47)
  • 16 (2021-03-05 (金) 13:04:01)
  • 17 (2021-03-05 (金) 16:52:24)
  • 18 (2021-03-07 (日) 23:57:34)
  • 19 (2021-03-08 (月) 17:18:26)
  • 20 (2021-03-10 (水) 23:31:47)
  • 21 (2021-03-12 (金) 23:06:32)
  • 22 (2021-03-17 (水) 17:26:54)
  • 23 (2021-03-17 (水) 20:41:14)
  • 24 (2021-03-18 (木) 16:08:44)
  • 25 (2021-04-16 (金) 15:02:27)
  • 26 (2021-07-14 (水) 20:15:40)

---

「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る
  • Azure Well-Architected Framework
  • FgCF (Financial-grade Cloud Fundamentals)

目次 †

概要 †

俯瞰すると、以下のようにサマリ出来るらしい。＋基礎

インフラ構築と運用 †

マイクロ・セグメンテーション †

中央統制と権限移譲 †

オンプレ → クラウド（Azureでは

ID管理と認証・認可 †

オンプレ → クラウド（Azureでは

システム構築とアプリ開発 †

開発プロセスへの折込 †

ツール、レビューなど。

設計とテスト †

• 脅威モデリング
  • STRIDE分析
  • OWASP Threat Dragon プロジェクト

• 脆弱性テスト
  • ネットワーク脆弱性対策
  • Webアプリケーション脆弱性対策

自動化 †

IaC (Infrastructure as Code) ＋ DevOps

セキュリティ運用 †

ISMS、ITILの

検知 †

オンプレ → クラウド（Azureでは

対応・復旧 †

オンプレ → クラウド（Azureでは

改善 †

オンプレ → クラウド（Azureでは

詳細 †

原則 †

責任共有モデル †

https://docs.microsoft.com/ja-jp/azure/architecture/framework/security/role-of-security

• 物理Data Center
  "信ぜよ、されど確認せよ"

• ソフトウェア

• インフラ・ミドル
  • Software Defined Everything(SDx)
  • Software Defined Data Center(SDDC)

• アプリケーション
  • ゼロトラストが前提
  • 設計とテストを実施

設計原則 †

https://docs.microsoft.com/ja-jp/azure/architecture/framework/security/security-principles

• 要件
  • セキュリティの優先順位をミッションに整合させる
  • 包括的な戦略を構築する

• 設計
  • シンプルさを促進する
  • 攻撃者を念頭に置いて設計する
  • ネイティブの制御を活用する
  • ID を主要なアクセス制御として使用する
  • アカウンタビリティ（真正性、責任追跡性、否認防止、信頼性）
  • 自動化を採用する
  • 情報の保護に注力する
  • 回復力を考慮して設計する
  • ゼロトラストを前提とする

• 運用
  • ベースラインとベンチマーク
  • 継続的な改善を推進する
  • セキュリティ教育を奨励する

基本 †

https://docs.microsoft.com/ja-jp/azure/architecture/framework/security/architecture-type

経験とデータを活用 †

• Security Intelligence Report
  https://www.microsoft.com/en-us/security/business/security-intelligence-report

脅威モデリングを活用 †

規制当局のセキュリティ標準 †

https://docs.microsoft.com/ja-jp/azure/architecture/framework/security/law-authority

• 規制当局のセキュリティ標準に準拠
• クラウドを想定しないケースがある。

リスク低減するセキュリティ戦略 †

https://docs.microsoft.com/ja-jp/azure/architecture/framework/security/resilience

• 攻撃のためのハードルを上げる

• 攻撃が成功した際の軽減・回復方法
  • 多層防衛
  • 早期の検知と対応

• 攻撃をうまくコントロール
  • 最小特権付与
  • 短い有効期間
  • 検知＆無効化
  • アクセス先毎の権限の細分化

役割と分担 †

ガバナンス・リスク・コンプライアンス（GRC）

ガバナンス †

https://docs.microsoft.com/ja-jp/azure/architecture/framework/security/governance

• 検討事項

• セキュリティ機能別の役割

• ネットワーク・セキュリティ
• ネットワーク管理
• サーバ VM のセキュリティ
• インシデント監視・対応
• ポリシー管理
• ID 管理

• 企業部門毎のマイクロ・セグメンテーション

• 中央（統括部門）側の作業
  • VM のセキュリティ確保
  • インシデント通知の受け取り
  • よく知られたリスクの検知・修復
  • 侵入テスト、古いプロトコルの検出
  • 定期的なアクセス監査
  • 不正な ID 利用の監視

• その他
  • 環境の作成と管理の自動化
  • 各種ベンチマークによる体制評価
  • ポリシー準拠の監査と適用

• 関連する機能

• Azure Security Center
  ・VMのパッチ適用漏れ
  ・VMのネット直接続
  ・セキュリティ・スコア
  

• Azure Policy
  グループポリシーのAzure版

• Azure ADアクセス レビュー
  グループ メンバ・アプリのアクセスを可視化および制御

• Azure Blueprints
  ARM、RBAC、ポリシーなどの成果物を
  パッケージ化、デプロイを簡略化する。

• Azure Sentinel
  SIEM機能、SOAR機能、UEBA機能

• 高度なセキュリティ機能
  ・Azure 専用 HSM
  ・Azure Confidential Computing

• 権限分掌設計

• コア・サービス
  Hub VNET, ADDS, DNS/DHCPの作成と管理
  中央（統括部門）側でも権限を持ち、管理

• セキュリティチーム
• ポリシー管理チーム
• ネットワーク管理チーム
• 緊急事態用アカウント
• 中央 IT 運用チーム

• 部門サービス
  Spoke VNET, 業務システムの作成と管理
  中央（統括部門）側でも適切に権限を持ち、管理

• セキュリティチーム
• ポリシー管理チーム
• ネットワーク管理チーム
• 緊急事態用アカウント
• IT 運用チーム
• アプリケーション管理者

※ 緊急事態用アカウント : Break Glass Account
　　2FA/MFA、条件付きアクセスは外しておく。

リスク †

保護対象に対する攻撃が成功する確率と影響

コンプライアンス †

• 標準、組織、管理、法規制
• 例：ISO27001、NIST、PCI DSS

設計と実装 †

ID 管理とアクセス管理 †

Azure AD

• 単一ディレクトリ利用
  （運用管理作業用アカウントの話）

• ID同期の設計
  （強権限 ID は同期しない）

• 外部ディレクトリの利用
  （B2B/B2C の利用）

• 認証
  • パスワード保護対策機能の利用

• レガシー認証のブロック、
  パスワードレス認証、2FA/MFA

• SSO の実施（SAML、OIDC）

• 条件付きアクセス

• 攻撃シミュレーションの実施

境界型ネットワークから脱却 †

• マイクロ・セグメンテーション

• 適切なインターネットエッジ戦略
  • Azure Firewall
  • Azure Application Gateway（WAF）
  • NVA（アプライアンス）

ネットワーク・セキュリティ †

• NIDS / NIPS / NDLPの利用

• ネットワーク通信の可視化
  Azure Sentinel（SIEM）によるログ統合
  • NSG ログ
  • WAF のログ
  • 仮想ネットワークタップ
  • Azure Network Watcher

• IP アドレス設計

• AzureのDDoS対策

• 強制トンネリング（オンプレ迂回）を避ける
  • 通信量の増大
  • レイテンシの悪化
  • コストの増加

ストレージ・データ・暗号化 †

• ストレージアクセスに利用する認証方式の選択
• プラットフォーム暗号化サービスを無効化しない

• 仮想マシンの VHD ファイルを保護
  • VHD ファイルに適切な認証・認可を設定
  • ADE （Azure Disk Encryption）でディスク暗号化

アプリケーションとサービス †

• 守りかたの基礎
  他に比べて圧倒的に重要（≒ いくらインフラで守ってもアプリで漏れる。）

• スコープの際を意識する。
  • IaaS
  • PaaS/CaaS
  • SaaS

• リスクの高い部分を意識して対策する。

• DevOps アプローチを採用する。
  Secure DevOps Kit for Azure

• ２つのアプローチ
  • ボトムアップ : ソフトウェア開発ライフサイクル（SDLC）
  • トップダウン : 脅威モデリング

• 設計・実装上のポイント
  • 基本的なセキュリティ機能を自力実装しない、
    各サービスが持つセキュリティ機能を活用する。
  • 鍵を使わずなるべく ID 認証（マネージドID）を利用する。
  • WAFを利用する（ただしそれだけに依存しない）

• コンテナのベストプラクティス
  • CaaSは Managed 型のサービスを使う。
  • コンテナ・イメージの身元を確認する。
  • コンテナを管理者権限で実行しない。
  • コンテナを監視する。

運用管理作業（Administration） †

作業特権アクセスの厳格な管理

• ベストプラクティス

• オンプレ / クラウド
  • オンプレミス AD
    https://docs.microsoft.com/ja-jp/windows-server/identity/securing-privileged-access/securing-privileged-access
  • クラウド AAD
    https://docs.microsoft.com/ja-jp/azure/security/fundamentals/steps-secure-identity

• 柱
  • 人材
  • 認証
  • 最小特権
  • 特権アクセス端末

• カテゴリ

• アカウント設計
  高い特権作業用に、別のアカウントを用意する。
  ・コンシューマ・アカウントを使わない
  ・AD LAPS、AAD PIMなどの利用
  ・OA系の権限を剥奪（Web、Office）。
  ・オンプレとクラウドの管理を適切に分断（同期しない）（→ 既出）
  ・緊急事態用アカウントを用意しておく（→ 既出）
  

• アカウント利用
  ・パスワードレス認証やMFAの義務付け
  ・条件付きアクセスの強制
  ・ライフサイクル管理の確立
  ・利用ユーザの教育

• 作業端末
  ・ハードニング（堅牢化）された端末を利用
  　・一般：専用端末、ハイセキュリティ端末
  　・高権限：隔離端末、特権アクセス端末（PAW : Privileged Access Workstation）
  ・機能
  　・MDATP
  　・Microsoft Intune
  　・Windows Autopilot
  　・Azure Sentinel
  ・参考：https://docs.microsoft.com/ja-jp/security/compass/privileged-access-devices

• 権限設計・権限付与
  ・特権付与が必要なアカウント数を管理し減らす。
  ・細かすぎる権限付与を避ける。
  　・最小特権付与も程々に。
  　・グループを活用する。
  　　・管理グループ（サブスクリプションを上回る）
  　　・リソース・グループ
  ・特権を永続的に付与しない。
  　（短い有効期間、PIM、JIT）
  ・カスタム・ロールの利用を避ける。
  　基本的にはビルトインのロールを活用する。

セキュリティ運用（SO） †

• 脅威
  • 自動攻撃や繰り返し攻撃
  • 人手による攻撃（標的型攻撃等）

• 対策
  • Detect（検出）
  • Respond（応答）
  • Recover（復旧）

• ベストプラクティス
  • 企業全体を俯瞰したセキュリティ運用を行う
  • クラウドネイティブのセキュリティ機能を使う
  • SIEM に入れるアラートやログを適切に選別する。
    • ツール（Azure Security Center, Azure Monitor, NSG フローログ, EDRなど）を活用し、
    • SIEM （Azure Sentinel, Splunk, QRader など）で情報を可視化する。
  • セキュリティ運用の目標と数値指標を定義する。
    参考：https://www.microsoft.com/security/blog/2019/02/21/lessons-learned-from-the-microsoft-soc-part-1-organization/

Fit & Gap †

1. エンプラでの慣例
2. W-AFでのスタンス
3. エンプラ・W-AF間の折衷案

NW 閉域性確保 †

1. 入出力の閉域化。
2. 入力のみの閉域化。
3. 折衷案
   • インフラ・システム
     • マイクロ・セグメンテーション
     • ハードニング（堅牢化）された作業端末
   • アプリケーションとサービス
     脆弱性テスト

NW 透明性確保 †

1. 到達経路の明確化（接続元をホワイトリスト的に絞る）が慣例。
2. W-AFには記載が無い（CDNは管理されている、...が透明性が無い）。
3. オンプレと同じ製品の仮想アプライアンス版を採用する。

権限分掌 †

1. 中央統制（野良クラウド発生の原因になる）が慣例。
2. W-AFでは柔軟な権限移譲を許可するスタンス
3. ２つの方法
   • 中央部門のスキルを向上させ対応を早める。
   • マイクロ・セグメンテーション＋権限移譲

管理者アカウントのPWDローテ †

1. 共有アカウント（root, administrator）
2. 個人アカウント（個人特定のため）
3. ２つの方法
   • 共有アカウントはオンプレ延展・延伸環境（IaaS）で利用
   • 個人アカウントはクラウド環境（PaaS、SaaS）で利用

アプリの脆弱性 †

1. 軽視されている
2. 重視されている（ただし、実践は困難）
3. 人材育成とコンサル利用

管理端末の脆弱性 †

1. OA環境との分離を想定していないケースが多い。
2. 厳格なバードニング（堅牢化）が推奨されてる。
3. OA環境からの分離とバードニング（堅牢化）の推進

参考 †

Microsoft Docs †

• セキュリティの重要な要素の概要 - Azure Architecture Center
  https://docs.microsoft.com/ja-jp/azure/architecture/framework/security/overview

nakama †

FgCF > ゼロトラスト型マルチクラウド IT 環境
' > Azure Well-Architected Framework : Security セクション概要解説

• YouTube?
  https://www.youtube.com/watch?v=Z0gqDWX6VnE

• video、ppt
  https://nakama.blob.core.windows.net/mskk/2020_06_12_AzureW-AF_Security_v0.13.zip

※ 体系はコチラ、pwdはコチラ

     

Site admin: dotNetDevelopmentInfrastructure

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.063 sec.