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

目次

概要

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

インフラ構築と運用

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

中央統制と権限移譲

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

ID管理と認証・認可

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

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

開発プロセスへの折込

ツール、レビューなど。

設計とテスト

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

自動化

IaC (Infrastructure as Code)DevOps

セキュリティ運用

ISMSITIL

検知

オンプレ → クラウド(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

経験とデータを活用

脅威モデリングを活用

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

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 ADアクセス レビュー
    グループ メンバ・アプリのアクセスを可視化および制御
  • Azure Blueprints
    ARM、RBAC、ポリシーなどの成果物を
    パッケージ化、デプロイを簡略化する。
  • 高度なセキュリティ機能
    ・Azure 専用 HSM
    ・Azure Confidential Computing
  • 権限分掌設計
  • コア・サービス
    Hub VNET, ADDS, DNS/DHCPの作成と管理
    中央(統括部門)側でも権限を持ち、管理
  • セキュリティチーム
  • ポリシー管理チーム
  • ネットワーク管理チーム
  • 緊急事態用アカウント
  • 中央 IT 運用チーム
  • 部門サービス
    Spoke VNET, 業務システムの作成と管理
    中央(統括部門)側でも適切に権限を持ち、管理
  • セキュリティチーム
  • ポリシー管理チーム
  • ネットワーク管理チーム
  • 緊急事態用アカウント
  • IT 運用チーム
  • アプリケーション管理者

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

リスク

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

コンプライアンス

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

設計と実装

ID 管理とアクセス管理

Azure AD

  • ID同期の設計
    (強権限 ID は同期しない)
  • 外部ディレクトリの利用
    (B2B/B2C の利用)
  • 認証
    • パスワード保護対策機能の利用
  • レガシー認証のブロック、
    パスワードレス認証、2FA/MFA
  • SSO の実施(SAML、OIDC)
  • 条件付きアクセス
  • 攻撃シミュレーションの実施

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

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

  • ネットワーク通信の可視化
    Azure Sentinel(SIEM)によるログ統合
    • NSG ログ
    • WAF のログ
    • 仮想ネットワークタップ
    • Azure Network Watcher
  • IP アドレス設計
  • 強制トンネリング(オンプレ迂回)を避ける
    • 通信量の増大
    • レイテンシの悪化
    • コストの増加

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

  • ストレージアクセスに利用する認証方式の選択
  • プラットフォーム暗号化サービスを無効化しない
  • 仮想マシンの VHD ファイルを保護
    • VHD ファイルに適切な認証・認可を設定
    • ADE (Azure Disk Encryption)でディスク暗号化

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

  • 守りかたの基礎
    他に比べて圧倒的に重要(≒ いくらインフラで守ってもアプリで漏れる。)
  • スコープの際を意識する。
    • IaaS
    • PaaS/CaaS
    • SaaS
  • リスクの高い部分を意識して対策する。
  • DevOps アプローチを採用する。
    Secure DevOps Kit for Azure
  • 2つのアプローチ
    • ボトムアップ : ソフトウェア開発ライフサイクル(SDLC)
    • トップダウン : 脅威モデリング
  • 設計・実装上のポイント
    • 基本的なセキュリティ機能を自力実装しない、
      各サービスが持つセキュリティ機能を活用する。
    • 鍵を使わずなるべく ID 認証(Managed ID)を利用する。
    • WAFを利用する(ただしそれだけに依存しない)
  • コンテナのベストプラクティス
    • CaaSは Managed 型のサービスを使う。
    • コンテナ・イメージの身元を確認する。
    • コンテナを管理者権限で実行しない。
    • コンテナを監視する。

運用管理作業(Administration)

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

  • ベストプラクティス
    • 人材
    • 認証
    • 最小特権
    • 特権アクセス端末
  • カテゴリ
  • アカウント設計
    高い特権作業用に、別のアカウントを用意する。
    ・コンシューマ・アカウントを使わない
    ・AD LAPS、AAD PIM などの利用
    ・OA系の権限を剥奪(Web、Office)。
    ・オンプレとクラウドの管理を適切に分断(同期しない)(→ 既出
    ・緊急事態用アカウントを用意しておく(→ 既出
  • アカウント利用
    ・パスワードレス認証やMFAの義務付け
    ・条件付きアクセスの強制
    ・ライフサイクル管理の確立
    ・利用ユーザの教育
  • 権限設計・権限付与
    ・特権付与が必要なアカウント数を管理し減らす。
    ・細かすぎる権限付与を避ける。
     ・最小特権付与も程々に。
     ・グループを活用する。
      ・管理グループ(サブスクリプションを上回る)
      ・リソース・グループ
    ・特権を永続的に付与しない。
     (AAD PIMによるJIT)
    ・カスタム・ロールの利用を避ける。
     基本的にはビルトインのロールを活用する。

セキュリティ運用(SO)

  • 脅威
    • 自動攻撃や繰り返し攻撃
    • 人手による攻撃(標的型攻撃等)
  • 対策
    • Detect(検出)
    • Respond(応答)
    • Recover(復旧)

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. 2つの方法

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

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

アプリの脆弱性

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

管理端末の脆弱性

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

参考

Microsoft Docs

nakama

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

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


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


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2021-07-14 (水) 20:15:40 (18d)