「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
俯瞰すると、以下のようにサマリ出来るらしい。＋基礎
インフラ構築と運用 †
中央統制と権限移譲 †
ID管理と認証・認可 †
システム構築とアプリ開発 †
開発プロセスへの折込 †
ツール、レビューなど。
設計とテスト †
- 脅威モデリング
- STRIDE分析
- OWASP Threat Dragon プロジェクト
自動化 †
IaC (Infrastructure as Code) ＋ DevOps
セキュリティ運用 †
検知 †
対応・復旧 †
改善 †
詳細 †
原則 †
責任共有モデル †
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
基本 †
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 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
- 外部ディレクトリの利用
（B2B/B2C の利用）
- レガシー認証のブロック、
パスワードレス認証、2FA/MFA
境界型ネットワークから脱却 †
ネットワーク・セキュリティ †
- ネットワーク通信の可視化
Azure Sentinel（SIEM）によるログ統合
- NSG ログ
- WAF のログ
- 仮想ネットワークタップ
- Azure Network Watcher
ストレージ・データ・暗号化 †
- ストレージアクセスに利用する認証方式の選択
- プラットフォーム暗号化サービスを無効化しない
- 仮想マシンの VHD ファイルを保護
- VHD ファイルに適切な認証・認可を設定
- ADE （Azure Disk Encryption）でディスク暗号化
アプリケーションとサービス †
- 守りかたの基礎
他に比べて圧倒的に重要（≒ いくらインフラで守ってもアプリで漏れる。）
- ２つのアプローチ
- ボトムアップ : ソフトウェア開発ライフサイクル（SDLC）
- トップダウン : 脅威モデリング
- 設計・実装上のポイント
- 基本的なセキュリティ機能を自力実装しない、
各サービスが持つセキュリティ機能を活用する。
- 鍵を使わずなるべく ID 認証（マネージドID）を利用する。
- WAFを利用する（ただしそれだけに依存しない）
- コンテナのベストプラクティス
- CaaSは Managed 型のサービスを使う。
- コンテナ・イメージの身元を確認する。
- コンテナを管理者権限で実行しない。
- コンテナを監視する。
運用管理作業（Administration） †
作業特権アクセスの厳格な管理
- アカウント設計
高い特権作業用に、別のアカウントを用意する。
・コンシューマ・アカウントを使わない
・AD LAPS、AAD PIMなどの利用
・OA系の権限を剥奪（Web、Office）。
・オンプレとクラウドの管理を適切に分断（同期しない）（→ 既出）
・緊急事態用アカウントを用意しておく（→ 既出）
- アカウント利用
・パスワードレス認証やMFAの義務付け
・条件付きアクセスの強制
・ライフサイクル管理の確立
・利用ユーザの教育
- 権限設計・権限付与
・特権付与が必要なアカウント数を管理し減らす。
・細かすぎる権限付与を避ける。
・最小特権付与も程々に。
・グループを活用する。
・管理グループ（サブスクリプションを上回る）
・リソース・グループ
・特権を永続的に付与しない。
（短い有効期間、PIM、JIT）
・カスタム・ロールの利用を避ける。
基本的にはビルトインのロールを活用する。
セキュリティ運用（SO） †
- 脅威
- 自動攻撃や繰り返し攻撃
- 人手による攻撃（標的型攻撃等）
- 対策
- Detect（検出）
- Respond（応答）
- Recover（復旧）
Fit & Gap †
- エンプラでの慣例
- W-AFでのスタンス
- エンプラ・W-AF間の折衷案
NW 閉域性確保 †
NW 透明性確保 †
- 到達経路の明確化（接続元をホワイトリスト的に絞る）が慣例。
- W-AFには記載が無い（CDNは管理されている、...が透明性が無い）。
- オンプレと同じ製品の仮想アプライアンス版を採用する。
権限分掌 †
- 中央統制（野良クラウド発生の原因になる）が慣例。
- W-AFでは柔軟な権限移譲を許可するスタンス
- ２つの方法
管理者アカウントのPWDローテ †
- 共有アカウント（root, administrator）
- 個人アカウント（個人特定のため）
- ２つの方法
- 共有アカウントはオンプレ延伸環境（IaaS）で利用
- 個人アカウントはクラウド環境（PaaS、SaaS）で利用
アプリの脆弱性 †
- 軽視されている
- 重視されている（ただし、実践は困難）
- 人材育成とコンサル利用
管理端末の脆弱性 †
- OA環境との分離を想定していないケースが多い。
- 厳格なバードニング（堅牢化）が推奨されてる。
- OA環境からの分離とバードニング（堅牢化）の推進
参考 †
Microsoft Docs †
nakama †
- Azure Well-Architected Framework : Security セクション概要解説
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
