AZ-104 解説シート

AZ-104 試験対策 解説シート

この解説シートでは、試験範囲を網羅的に確認し、各トピック毎に機能や、ユースケース等についてそれぞれ解説します。

---

1. Azureのアイデンティティとガバナンスの管理

1.1 Microsoft Entra ID (旧 Azure Active Directory)

Microsoft Entra ID は、クラウドベースのアイデンティティおよびアクセス管理サービスであり、ユーザーの認証とアクセス権限を管理します。以下に、主要な機能と管理方法について詳しく説明します。

1.1.1 ユーザーとグループの管理

• ユーザーの作成と管理

  • ユーザー作成：Azureポータル、PowerShell (New-AzADUser)、Azure CLI (az ad user create) を使用して新しいユーザーを作成。
  • 属性の管理：ユーザーのプロファイル情報（名前、メールアドレス、役職、部署など）を更新。例えば、Azureポータルの「ユーザー」セクションから直接編集可能。
  • ユーザー削除と無効化：不要なユーザーアカウントの削除や、一時的な無効化（アカウントロックやパスワードリセット）。

• グループの作成と管理

  • セキュリティグループ：リソースへのアクセス制御を統合的に管理。たとえば、特定のリソースグループへのアクセスをセキュリティグループに限定。
  • Office 365グループ：コラボレーションツール（Teams、SharePoint、Exchange）と連携したグループ作成。メールディストリビューションリストとしても機能。
  • 動的グループ：ユーザー属性（例：部署、役職）に基づいて自動的にメンバーシップを管理。Azureポータルからルールを定義し、自動的にメンバーが追加・削除される。

1.1.2 ロールベースのアクセス制御 (RBAC)

• RBACの概念

  • ロール：事前定義された権限セット（例：オーナー、共同作成者、閲覧者）やカスタムロールを使用。たとえば、オーナーロールはフルアクセス権限を持ち、共同作成者ロールはリソースの作成と管理が可能。
  • スコープ：ロールの適用範囲（管理グループ、サブスクリプション、リソースグループ、個々のリソース）。例えば、特定のサブスクリプション全体にロールを割り当てる場合。

• ロールの割り当て

  • ユーザーやグループへのロール割り当て：Azureポータルの「アクセス制御 (IAM)」からユーザーやグループに対してロールを割り当て。
  • カスタムロールの作成：必要に応じて独自の権限セットを定義。JSON形式で権限を詳細に指定することが可能。

1.1.3 多要素認証 (MFA)

• MFAの導入方法

  • ユーザーごとの有効化：個別のユーザーに対してMFAを強制。Azureポータルの「ユーザー」セクションから設定可。
  • 条件付きアクセスポリシー：特定の条件下（例：外部IPからのアクセス時）でのみMFAを要求。Azure ADの「条件付きアクセス」からポリシーを作成。

• 利用シナリオ

  • リモートアクセスのセキュリティ強化：外部からのAzureポータルアクセスやVPN接続時にMFAを要求。
  • 高機密データへのアクセス保護：特定のリソースグループやストレージアカウントへのアクセスにMFAを必須化。

• ベストプラクティス

  • MFAの強制：すべての重要なアカウントに対してMFAを有効化。一部の例外を除き、全ユーザーに適用する。
  • ユーザー教育：MFAの重要性と使用方法をユーザーに周知し、スムーズな導入を支援。

1.1.4 Microsoft Entra Connect

• Microsoft Entra Connectの概要

  • オンプレミスディレクトリとクラウドディレクトリの同期。Active Directoryとのハイブリッドアイデンティティを実現。
  • シングルサインオン (SSO)：ユーザーはオンプレミスの資格情報を使用してクラウドサービスにシームレスにアクセス可能。

• 設定と管理

  • 同期ルールの設定：どの属性を同期するかを定義。例：ユーザー名、メールアドレス、部署情報を同期。
  • フィルタリング：特定の組織単位 (OU) や属性に基づいて同期対象を制限。例えば、特定のOU内のユーザーのみを同期。

• セキュリティと可用性

  • 同期サービスの高可用性：複数のサーバーでEntra Connectを冗長化し、同期サービスの継続性を確保。
  • セキュアな接続：TLS暗号化を使用してオンプレミスとAzure間の同期データを保護。

1.1.5 ライセンス管理

• ライセンスの割り当て

  • ユーザーごとの割り当て：個々のユーザーに直接ライセンスを割り当て。管理が煩雑になるため、動的グループやグループベースの割り当てが推奨。
  • グループベースの割り当て：動的グループを使用して自動的にライセンスを割り当て。グループメンバーシップの変更に応じてライセンスが自動的に適用・解除。

• ライセンスの種類

  • Microsoft 365 ライセンス：Officeアプリケーション、Teams、SharePoint、OneDriveなどの利用権。
  • Azure AD Premium ライセンス：条件付きアクセス、MFA、自己サービスパスワードリセット、高度なセキュリティ機能。

• ライセンスの最適化

  • 不要なライセンスの削減：使用されていないライセンスを特定し、再割り当てまたは削除。
  • ライセンス利用率の監視：Azureポータルの「ライセンス」セクションで利用状況をモニタリングし、最適なライセンス配分を確保。

---

1.2 ガバナンス

ガバナンスは、組織全体でのリソースの統制と管理を確立し、コンプライアンスと効率性を保証するための枠組みです。以下に、Azureのガバナンス機能について詳しく解説します。

1.2.1 Azure Policy

• Azure Policyの概要

  • ポリシー定義：リソースが組織の基準に従ってデプロイされるよう制御するルール。例えば、「すべてのストレージアカウントは暗号化を有効にする」など。
  • イニシアティブ：複数のポリシーをまとめた一連のポリシーセット。例えば、セキュリティ強化のための複数のポリシーを一括適用。

• ポリシーの作成と適用

  • ポリシー定義の作成：JSON形式で条件と効果を指定。Azureポータルの「ポリシー」から新規定義を作成。
  • ポリシーの適用：スコープ（管理グループ、サブスクリプション、リソースグループ）を選択してポリシーを適用。例えば、特定のサブスクリプション全体にポリシーを適用。

• コンプライアンスの強制

  • 評価と修復：ポリシー違反を検出し、自動修復機能を設定。たとえば、特定のタグが付与されていないリソースにタグを自動的に追加するなど。

• 例と実践

  • 制限されたリージョンでのリソース作成：指定されたリージョン以外でリソースが作成されるのを防ぐポリシーを設定。
  • タグ付けの強制：すべてのリソースに「環境」タグを強制し、リソース管理を容易にする。

1.2.2 管理グループとサブスクリプション

• 管理グループの役割

  • ポリシーの一括管理：複数のサブスクリプションに対して一括でポリシーを適用するための階層構造。
  • 階層構造：組織の構造に合わせて管理グループを階層化。例えば、「グローバル管理グループ」内に「地域別管理グループ」を作成。

• 管理グループの作成と管理

  • 作成手順：
    1. Azureポータルで「管理グループ」を選択。
    2. 「新しい管理グループ」をクリックし、名前とIDを指定。
    3. 必要に応じて既存のサブスクリプションを追加。
  • 管理グループの階層化：トップレベルの管理グループに下位の管理グループを追加し、ポリシーを階層的に適用。

• サブスクリプションの設定

  • リソースの分離：異なるプロジェクトや部門ごとにサブスクリプションを分けることで、管理と課金を分離。
  • アクセス制御：サブスクリプション単位でRBACを設定し、異なるサブスクリプションに異なるアクセス権限を割り当てる。

• ベストプラクティス

  • 階層構造の設計：組織のニーズに合わせて管理グループの階層を設計し、効率的なポリシー適用を実現。
  • 統一されたポリシー管理：共通のポリシーをトップレベルの管理グループに適用し、下位のサブスクリプションに継承させる。

1.2.3 Azure Blueprints

• Azure Blueprintsの概要

  • テンプレート化された環境構築：ポリシー、ロール、リソーステンプレートを組み合わせて一貫性のある環境を迅速にデプロイ。
  • コンプライアンスの確保：組織の規範やコンプライアンス基準に準じた設定を自動的に適用。

• Blueprintの作成と管理

  • Blueprint定義の作成：
    1. Azureポータルで「Blueprints」を選択。
    2. 「Blueprintの作成」をクリックし、テンプレートを選択（空白、スタート済みなど）。
    3. ポリシー、ロール、リソーステンプレートなどのアーティファクトを追加。
  • Blueprintのバージョニング：変更を加える際にはバージョンを更新し、以前のバージョンにロールバック可能にする。

• 利用シナリオ

  • 新しいプロジェクトや部門の立ち上げ：Blueprintを使用して一貫性のある環境を迅速に構築。例えば、開発用サブスクリプションの標準設定をBlueprintで自動適用。
  • コンプライアンスの維持：定期的にBlueprintを適用し、環境が常に組織のコンプライアンス基準に従っていることを確認。

• 具体例

  • セキュリティ基準の適用：Blueprintにセキュリティポリシー、監視設定、ネットワーク構成を定義し、新しいサブスクリプションに自動適用。
  • リソースグループの標準設定：Blueprintを使用して、一貫したリソースグループ構造とタグ付けポリシーをデプロイ。

---

2. Azure Virtual Machines (VM) の管理

2.1 仮想マシンのデプロイと設定

2.1.1 Azure Marketplaceを使用したVMの作成

• Azure Marketplaceの利用

  • テンプレートの選択：Windows Server、Linuxディストリビューション、特定用途向けのイメージ（例：SQL Server、SharePoint）。
  • カスタムイメージの使用：企業独自にカスタマイズしたOSイメージを使用してVMをデプロイ。事前にAzure Marketplaceやストレージアカウントにアップロードしたカスタムイメージを選択。

• VMの作成手順

  1. Azureポータルにサインイン。
  2. 左側のメニューから「仮想マシン」を選択し、「作成」をクリック。
  3. Marketplace から適切なイメージを選択（例：Ubuntu Server 20.04 LTS）。
  4. 基本設定：
     • サブスクリプション：適切なサブスクリプションを選択。
     • リソースグループ：既存のリソースグループを使用するか、新規作成。
     • VM名：一意で識別しやすい名前を設定。
     • リージョン：リソースの利用者に近いリージョンを選択。
     • 可用性オプション：可用性セット、可用性ゾーンを選択。
     • イメージ：使用するOSイメージを選択。
     • サイズ：必要なCPU、メモリ、ディスクサイズに基づいてVMサイズを選択。
     • 認証タイプ：パスワードまたはSSH公開キーを選択。
  5. ディスク設定：
     • OSディスクタイプ：Standard HDD、Standard SSD、Premium SSDから選択。
     • 追加ディスク：必要に応じてデータディスクを追加。
  6. ネットワーク設定：
     • 仮想ネットワーク：既存のVNetを選択または新規作成。
     • サブネット：適切なサブネットを選択。
     • パブリックIP：パブリックIPアドレスを持たせるかどうか選択。
  7. 管理オプション：
     • 監視：Azure Monitorの設定（診断拡張機能の有効化）。
     • Auto-shutdown：不要な時間帯に自動でシャットダウン設定。
  8. 確認および作成：設定を確認し、「作成」をクリックしてVMをデプロイ。

• 重要ポイント

  • イメージの選択：用途に応じた適切なOSイメージを選ぶ。セキュリティパッチが最新のものを選択。
  • 認証方法：SSHキーの使用推奨。パスワードはセキュリティリスクが高いため、可能な限りSSHキーを利用。
  • ディスクの冗長性：データディスクの種類（Standard vs Premium）を選択し、パフォーマンス要件に合わせる。

2.1.2 VMのサイズ変更とスケールセット

• VMサイズの変更

  • スケールアップ/スケールダウン：Azureポータルの「サイズ変更」機能を使用して、VMのCPU、メモリ、ネットワーク帯域幅を調整。
  • 制約：一部のサイズ変更ではVMの再起動が必要。リソースの利用可能性（同じリージョン内でのリソース制限）を確認。

• スケールセットの利用

  • 標準スケールセット
    • 自動スケーリング：負荷に応じて自動的にVMインスタンスを追加・削除。
    • 統一されたテンプレート：同一のVMテンプレートを用いることで、一貫性のあるデプロイメントが可能。
    • 負荷分散：Azure Load BalancerやApplication Gatewayと連携してトラフィックを分散。
  • アベイラビリティセットとの違い：アベイラビリティセットは可用性の確保を目的とし、スケールセットは可用性に加え自動スケーリングを提供。

• スケールセットの設定手順

  1. Azureポータルで「スケールセット」を選択。
  2. 「作成」をクリックし、スケールセットの基本情報（名前、リージョン、イメージ、サイズ）を設定。
  3. インスタンス数の設定：初期数、最小・最大数を定義。
  4. スケーリングポリシーの設定：メトリック（CPU使用率など）に基づいてスケールルールを設定。
  5. ネットワーク設定：仮想ネットワーク、サブネット、負荷分散の設定。
  6. 確認および作成：設定を確認し、スケールセットをデプロイ。

• 実践的な例

  • Webアプリケーションのスケーリング：アクセス量に応じてスケールセットを使用してVMインスタンスを増減。急増するトラフィックにも自動的に対応。
  • バッチ処理のスケーリング：処理量に応じてスケールセットを利用し、効率的にリソースを割り当てる。

2.1.3 可用性セットとゾーン

• 可用性セットの概要

  • フォルトドメイン：物理ホストの障害リスクを分散。データセンター内の異なる物理サーバーにVMを配置。
  • 更新ドメイン：メンテナンス時の同時再起動を防止。Azureは異なる更新ドメインに対して順次再起動を実施。

• 可用性セットの利用

  • フォルトドメインと更新ドメインの設定
    1. Azureポータルで「可用性セット」を選択。
    2. 「新規作成」をクリックし、フォルトドメイン数（最大3）と更新ドメイン数（最大5）を設定。
    3. 可用性セットにVMを追加。

• 可用性ゾーンの利用

  • ゾーンごとのリソース配置：異なる物理場所（ゾーン）にVMを配置し、高可用性を実現。例えば、ゾーン1、ゾーン2、ゾーン3にVMを分散。
  • 災害対策：一つのゾーンが利用不可でも、他のゾーンでサービスを継続。高可用性と耐障害性を確保。

• 可用性ゾーン対応VMの作成手順

  1. Azureポータルで「仮想マシン」を選択し、「作成」をクリック。
  2. 基本設定で新規VMを作成する際に、「可用性ゾーン」を指定。
  3. ゾーンごとにVMを配置し、異なるゾーンに同一サービスのVMを冗長化。

• 具体例

  • ミッションクリティカルなアプリケーション：高可用性が要求されるアプリケーションを可用性ゾーンに分散配置し、障害時の影響を最小化。
  • 地域横断的なサービス運用：異なる地域のゾーンにVMを配置し、地域全体の障害に対する耐性を向上。

2.1.4 Azure Arcを利用したハイブリッドVM管理

• Azure Arcの概要

  • ハイブリッドクラウド管理：オンプレミスや他のクラウドプロバイダーに存在するVMを、Azureポータルから一元管理。
  • ガバナンスとセキュリティの統一：Azure PolicyやAzure Monitorを使用して、複数の環境に対して統一的なガバナンスとセキュリティポリシーを適用。

• Azure Arcを利用した設定手順

  1. Azure Arcエージェントのインストール：オンプレミスのVMにAzure Arcエージェントをインストール。
  2. VMの登録：AzureポータルでAzure ArcにVMを登録し、リソースグループに追加。
  3. ポリシーとガバナンスの適用：Azureポータルから既存のポリシーをArcで管理されるVMに適用。

• 利用シナリオ

  • 統一された管理：オンプレミスとAzureのVMを一元的に管理し、リソース配分やセキュリティポリシーを統一。
  • スケールの拡張：クラウドだけでなく、オンプレミス環境もAzureの管理機能の下に統合し、スケールを無限に拡張。

2.1.5 Azure Spot VMの利用

• Azure Spot VMの概要

  • コスト効率の高いVM：不要な計算能力を利用して、通常価格よりも大幅に安価にVMを運用。
  • 一時的な計算ジョブに最適：バックグラウンド処理やバッチジョブなどの中断可能なタスクに適用。

• Spot VMの設定手順

  1. Azureポータルで「仮想マシン」を選択し、「作成」をクリック。
  2. 基本設定で「スポットインスタンス」を有効化。
  3. 価格制限と優先度の設定：利用可能な最安値に基づいて設定。

• 利用シナリオ

  • バッチ処理：一時的な大量データの処理や分析タスクをSpot VMで実行。
  • テスト環境：短期間で使用するテスト環境を低コストで提供。

• 注意点

  • 中断可能性：需要が高まるとSpot VMは中断されるため、タスクの中断に耐える設計が必要。
  • データの保持：永続的なデータは別のストレージに保管し、Spot VMの一時ストレージには依存しない。

2.2 バックアップとリカバリ

2.2.1 Azure Backup

• Azure Backupの概要

  • クラウドベースのバックアップサービス：VM、SQLデータベース、ファイルサーバーなどのデータを安全にバックアップ。
  • Recovery Services Vault：バックアップデータの保存先として機能。複数のバックアップポリシーを管理。

• バックアップポリシーの設定

  • レギュラーバックアップスケジュール：日次、週次、月次など、定期的なバックアップスケジュールを設定。
  • 保持期間の設定：短期保持（数日から数週間）と長期保持（数年）を組み合わせてデータを保持。

• バックアップの実行と管理

  • 初回バックアップ：完全バックアップを実行し、以降は増分バックアップで変更データのみを保存。
  • バックアップジョブのモニタリング：AzureポータルまたはAzure Monitorを使用してバックアップジョブの状態を監視。

• 具体的な設定手順

  1. Recovery Services Vaultの作成：
     • Azureポータルで「Recovery Services vault」を選択し、「作成」をクリック。
     • 必要な情報（名前、リージョン、リソースグループ）を入力して作成。
  2. バックアップポリシーの定義：
     • Vault内で「バックアップポリシー」を選択し、新規ポリシーを作成。
     • バックアップスケジュール（例：毎日午後2時）と保持期間を設定。
  3. バックアップ対象の登録：
     • Vault内で「バックアップ対象の選択」を行い、バックアップ対象（VM、SQLデータベースなど）を指定。

• 利用シナリオ

  • VMのバックアップ：重要な仮想マシンの定期的なバックアップを設定し、データ損失時に迅速に復元。
  • ファイルサーバーのバックアップ：企業内のファイル共有サーバーのデータを定期的にバックアップし、誤削除や障害時に復元可能。

2.2.2 Azure Site Recovery

• Azure Site Recoveryの概要

  • ディザスターリカバリサービス：オンプレミス環境や他のクラウド環境からAzureへのフェイルオーバーを管理。
  • ビジネス継続性の確保：災害時に迅速にサービスを復旧させるための計画と自動化。

• 設定手順

  1. Recovery Services Vaultの作成：Azureポータルで「Recovery Services vault」を作成。
  2. ディザスタリカバリエージェントのインストール：オンプレミスのサーバーやVMにエージェントをインストール。
  3. レプリケーションポリシーの設定：データのレプリケーションスケジュールや保持期間を定義。
  4. レプリケーションの開始：ポリシーに基づきデータをAzureにレプリケート。
  5. フェイルオーバーのテストと実行：定期的にテストフェイルオーバーを実施し、復旧手順を検証。

• 復旧ポイントと計画

  • 復旧ポイントの選択：最新のデータポイントや特定の時間点に基づいて復元を実行。
  • フェイルオーバーの種類：
    • プランドフェイルオーバー：計画的に復旧を実行。
    • テストフェイルオーバー：実際のフェイルオーバーとは別に、復旧手順を検証。

• 具体例

  • 主要アプリケーションのディザスターリカバリ計画：企業の主要アプリケーションをAzureにレプリケートし、災害時に迅速にフェイルオーバー。
  • データセンターの完全なディザスターリカバリ：オンプレミスの全サーバーをAzureにレプリケートし、災害発生時にAzure上で業務を継続。

2.3 Azure Arcを利用したハイブリッドVM管理

• Azure Arcの概要

  • ハイブリッドクラウド管理：オンプレミスや他のクラウドプロバイダーに存在するVMを、Azureポータルから一元管理。
  • ガバナンスとセキュリティの統一：Azure PolicyやAzure Monitorを使用して、複数の環境に対して統一的なガバナンスとセキュリティポリシーを適用。

• Azure Arcを利用した設定手順

  1. Azure Arcエージェントのインストール：オンプレミスのVMにAzure Arcエージェントをインストール。
  2. VMの登録：AzureポータルでAzure ArcにVMを登録し、リソースグループに追加。
  3. ポリシーとガバナンスの適用：Azureポータルから既存のポリシーをArcで管理されるVMに適用。

• 利用シナリオ

  • 統一された管理：オンプレミスとAzureのVMを一元的に管理し、リソース配分やセキュリティポリシーを統一。
  • スケールの拡張：クラウドだけでなく、オンプレミス環境もAzureの管理機能の下に統合し、スケールを無限に拡張。

---

3. 仮想ネットワークの構成と管理

3.1 ネットワークアーキテクト

3.1.1 サブネットとVNetの設定

• VNetの概要

  • Azure Virtual Network (VNet)：Azure内でリソースが通信するための論理的なネットワーク。VM、アプリケーション、サービスの間で安全かつ効率的な通信を可能にする。
  • IPアドレス空間の定義：CIDRブロックを使用して、ネットワークのIPアドレス範囲を指定。例：10.0.0.0/16 は65534個のIPアドレスを提供。

• サブネットの作成

  • CIDRブロックの割り当て：VNet内でのIPアドレス範囲をサブネットごとに分割。例：10.0.0.0/24 は254個のホストアドレスを提供。
  • サブネットごとの機能分離：管理、データ、アプリケーション用など、用途に応じたサブネットの設計。例えば、管理サブネット、データベースサブネット、Webアプリケーションサブネット。

• サブネットの設定手順

  1. Azureポータルで「Virtual Networks」を選択。
  2. 既存のVNetを選択するか、新規VNetを作成。
  3. 「サブネット」セクションで「サブネットの追加」をクリック。
  4. サブネット名とCIDRブロックを指定。重複しないように注意。
  5. 「作成」をクリックしてサブネットを追加。

• 仮想ネットワークピアリング

  • VNetピアリングの設定：異なるVNet間での通信を可能にする仮想接続。ピアリングされたVNetは同一のAzureバックボーンネットワーク上で直接通信。
  • ピアリングの制約：
    • アドレス範囲の重複禁止：ピアリングする2つのVNetは、互いに重複するIPアドレス範囲を持たない必要がある。
    • トランジティブ接続の非対応：VNet AがVNet Bとピアリングされ、VNet BがVNet Cとピアリングされていても、VNet AとVNet Cは直接通信できない。

• 具体例

  VNet: 10.0.0.0/16
  サブネットA: 10.0.0.0/24
  サブネットB: 10.0.1.0/24
  

  この例では、VNet 10.0.0.0/16 内に2つのサブネット 10.0.0.0/24 と 10.0.1.0/24 を作成し、それぞれ異なる用途に割り当てる。

3.1.2 DNS設定

• Azure DNSの利用

  • Azure DNSホストゾーン：カスタムドメイン名のDNS管理。例：contoso.com のDNSゾーンを管理し、Aレコード、CNAMEレコードなどを設定。
  • 名前解決の設定：VNet内のリソースが正しく名前解決を行えるよう、カスタムDNSサーバーやAzure提供のDNSを設定。

• カスタムDNSの設定

  • オンプレミスDNSとの連携：ハイブリッド環境での名前解決を確保するため、Azure DNSとオンプレミスDNSを統合。
  • カスタムDNSサーバーの指定：VNetの設定でカスタムDNSサーバーのIPアドレスを指定。例：内部DNSサーバーをAzure VNetに指定し、内部リソースの名前解決を管理。

• DNSオーバーレイネットワーク

  • プライベートDNSゾーン：VNet内でのみ解決可能なDNSゾーンを作成。例えば、内部サービス用のドメインを設定。
  • DNSリンク：プライベートDNSゾーンを複数のVNetにリンクし、一貫した名前解決を実現。

• 具体例

  • 内部アプリケーションの名前解決：プライベートDNSゾーンを使用して、内部アプリケーションのFQDN（例：app.contoso.com）を管理。
  • 外部アクセスの管理：カスタムDNSを使用して、外部ユーザーに公開するサービスのDNS設定を管理し、セキュリティを強化。

3.1.3 ネットワークセキュリティグループ (NSG)

• NSGの概要

  • トラフィックフィルタリング：インバウンドおよびアウトバウンドのネットワークトラフィックを制御するルールを定義。
  • ルールの順序：NSGは優先度に基づいてルールを評価し、最初に一致したルールを適用。優先度が低い数値ほど高い優先度。

• NSGの作成と適用

  • NSGの作成手順：
    1. Azureポータルで「Network Security Groups」を選択し、「作成」をクリック。
    2. 名前、リージョン、リソースグループを指定。
    3. 「作成」をクリックしてNSGをデプロイ。
  • ルールの作成：
    • カスタムルール：特定のIPアドレス、ポート、プロトコルに基づいた許可/拒否ルールを作成。
    • 例：

      ルール1: インバウンドTCP 80番ポートを許可（HTTPアクセス）
      ルール2: インバウンドTCP 22番ポートを拒否（SSHアクセスの制限）
      

  • NSGの適用：
    • サブネットに適用：VNet内の特定のサブネットにNSGを適用し、サブネット内の全リソースに対してルールを適用。
    • ネットワークインターフェイスに適用：個々のVMのネットワークインターフェイスにNSGを適用し、特定のVMに対してルールを適用。

• セキュリティポリシーのベストプラクティス

  • 最小権限の原則：必要最小限のアクセス権限を付与し、不要なポートやプロトコルへのアクセスを制限。
  • アプリケーションセキュリティ：アプリケーションごとに異なるNSGを設定し、適切なセキュリティを確保。

• 具体例

  • Webサーバーのセキュリティ：WebサーバーのサブネットにNSGを適用し、ポート80（HTTP）と443（HTTPS）へのアクセスを許可、その他のポートへのアクセスを拒否。
  • 管理アクセスの制限：管理用VMに対して特定のIPアドレス（例：社内IP）からのみSSHアクセスを許可するNSGルールを設定。

3.2 接続

3.2.1 VPNゲートウェイ

• VPNゲートウェイの役割

  • オンプレミスとAzureの接続：サイト間VPN（Site-to-Site VPN）やPoint-to-Site VPNを通じて安全に接続。
  • VPNプロトコル：IPsec/IKEを使用した暗号化通信。

• VPNゲートウェイの設定手順

  1. VPNゲートウェイサブネットの作成：
     • AzureポータルでVNet内に専用のサブネット（GatewaySubnet）を作成。推奨サイズは/27以上。
  2. VPNゲートウェイのデプロイ：
     • 「仮想ネットワークゲートウェイ」を作成し、必要なSKU（例：VpnGw1）を選択。
     • 「GatewaySubnet」を指定し、VPNタイプ（Site-to-Site または Point-to-Site）を選択。
  3. 接続の構成：
     • サイト間VPN接続：オンプレミスのVPNデバイス設定とAzure VPNゲートウェイを接続。
     • Point-to-Site VPN接続：個別ユーザーがAzureにリモートアクセスするための設定。

• 接続の種類

  • サイト間VPN：異なるネットワーク（オンプレミスとAzure間）の拡張。永続的な接続でデータセンターの拡張に最適。
  • Point-to-Site VPN：リモートユーザーがAzureに直接接続。モバイルユーザーやテレワーカー向け。

• 具体例

  • オンプレミスデータセンターとAzureの接続：オンプレミスのVPNデバイス（例：Cisco ASA）をAzure VPNゲートウェイと接続し、サブネット間の安全な通信を確立。
  • 開発者のリモートアクセス：Point-to-Site VPNを設定し、開発者が自宅からAzureリソースに安全にアクセス可能。

3.2.2 Azure ExpressRoute

• Azure ExpressRouteの概要

  • 専用回線による接続：インターネットを介さず、オンプレミスとAzureを直接接続。高速かつ低レイテンシな通信が可能。
  • 高帯域幅と信頼性：ミッションクリティカルなアプリケーションに適用。データセンター間の大容量データ転送に最適。

• ExpressRouteの設定手順

  1. ExpressRoute回線の取得：
     • Azureパートナー（ネットワークサービスプロバイダー）と契約し、専用回線を設定。
  2. ExpressRoute回線の構成：
     • 回線の種類：ブロードトランシット、マイクロトランジット、プライベート接続などから選択。
     • 冗長性：サービスレベルに応じてフェイルオーバーの設定を行い、高可用性を確保。
  3. VNetとの接続：
     • Azureポータルで「ExpressRoute」を選択し、作成した回線を既存のVNetに接続。

• 利用シナリオ

  • ハイブリッドクラウド環境：オンプレミス環境とAzureのリソースをシームレスに統合。
  • 大規模データ転送：ビッグデータや機械学習のワークロードで必要な大容量データの転送。

• 具体例

  • 企業のグローバル拠点間接続：複数の国にあるオフィス間をExpressRouteで直接接続し、高速かつ安全な通信を実現。
  • 金融機関の高セキュリティ接続：銀行や保険会社がExpressRouteを利用して、オンプレミスのデータセンターとAzure間で機密データを安全に転送。

---

4. ストレージアカウントとデータ管理

4.1 データストレージ

4.1.1 Azure Storageアカウントの管理

• Azure Storageの種類

  • BLOBストレージ：非構造化データの保存（画像、動画、バックアップ）。大容量データの格納に最適。
  • ファイルストレージ：共有ファイルシステム（SMBプロトコルを使用）。オンプレミスのファイル共有と容易に統合。
  • キューストレージ：大規模なメッセージングシステム（非同期通信）。アプリケーション間のメッセージングやジョブ管理に利用。
  • テーブルストレージ：大規模な構造化データのNoSQLストレージ。スケーラブルなデータベースとして利用。

• ストレージアカウントの作成と管理

  • ストレージアカウントの作成手順
    1. Azureポータルで「ストレージアカウント」を選択し、「作成」をクリック。
    2. 基本設定：
       • サブスクリプション、リソースグループを選択。
       • 名前を一意に設定。
       • リージョンを選択。
    3. パフォーマンスの選択：
       • Standard（HDDベース）または Premium（SSDベース）。
    4. アカウントの複製オプション：
       • LRS (Locally Redundant Storage)：単一データセンター内で3重冗長。
       • GRS (Geo-Redundant Storage)：地理的に離れた2つの地域で6重冗長。
       • ZRS (Zone-Redundant Storage)：異なる可用性ゾーンで冗長。
    5. オプションの設定：暗号化、アクセスレベルなどを設定。
    6. 「作成」をクリックしてストレージアカウントをデプロイ。

• アクセスキーと共有アクセス署名 (SAS)

  • アクセスキー：ストレージアカウントに対するフルアクセス権限を持つキー。セキュリティ上のリスクがあるため、必要最低限の使用に留める。
  • SAS (Shared Access Signature)：限定的なアクセス権限を持つトークン。期限やアクセス範囲を細かく設定可能。
    • 例：特定のBLOBコンテナへの読み取り専用アクセスを許可するSASを発行。

• ストレージアカウントの種類

  • 汎用 v2：すべてのストレージタイプ（BLOB、ファイル、キュー、テーブル）に対応。柔軟性とコスト効率が高い。
  • Blobストレージ：専用のBLOBストレージアカウント。特定のBLOB機能に最適化。
  • ファイルストレージ：専用のファイルストレージアカウント。高性能なファイル共有を提供。

4.1.2 階層型ストレージ戦略

• ストレージ階層の種類

  • ホット層：頻繁にアクセスされるデータ（例：アクティブなアプリケーションデータ）。パフォーマンス重視で高コスト。
  • クール層：まれにアクセスされるデータ（例：バックアップデータ、長期アーカイブ）。コスト重視で低パフォーマンス。
  • アーカイブ層：ほとんどアクセスされないデータ（例：法的データ保持、古いログ）。最低コストで長期保存に最適。ただし、アクセスには時間がかかる。

• 階層型ストレージの管理

  • データの分類：データの使用頻度に基づいてストレージ階層を設定。例：最新のログファイルはホット層、古いログファイルはクール層、ほとんどアクセスされないアーカイブデータはアーカイブ層に移動。
  • 自動ライフサイクル管理：Azure Storage Lifecycle Managementを使用して、データを自動的に適切な階層へ移動。例：30日以上アクセスされないBLOBをクール層に移動し、90日以上アクセスされない場合はアーカイブ層に移動。

• 具体例

  • ログファイルの保存：
    • ホット層：直近30日間のログファイル。
    • クール層：30日から90日のログファイル。
    • アーカイブ層：90日以上前のログファイル。
  • バックアップデータの管理：
    • ホット層：最新のバックアップ（例：過去7日間）。
    • クール層：過去30日間のバックアップ。
    • アーカイブ層：過去1年分のバックアップ。

4.2 データ保護

4.2.1 データの暗号化

• サーバーサイド暗号化 (SSE)

  • Azure Storage Service Encryption (SSE)：デフォルトでデータが暗号化。AES-256暗号が使用される。
  • カスタムキー暗号化 (SSE with Customer-Managed Keys)：
    • Azure Key Vault を使用して、顧客管理の暗号化キーを保存。
    • キー管理：キーの回転、削除ポリシーを設定し、暗号化キーのセキュリティを強化。

• クライアントサイド暗号化

  • データの事前暗号化：クライアント側でデータを暗号化し、暗号化されたデータをストレージに送信。例：アプリケーションレベルでのデータ暗号化。

• キー管理の技術

  • Azure Key Vault：暗号化キーやシークレットの安全な保管と管理。RBACやポリシーを使用してアクセス制御。
  • ローテーションポリシー：定期的なキーの更新と再生成。セキュリティベストプラクティスとして、キーの定期的なローテーションを推奨。

4.2.2 Azure Storage Firewalls and Virtual Networks

• ストレージファイアウォールの設定

  • IP制限：特定のIPアドレスまたはIPレンジからのアクセスのみを許可。例：企業の静的IPアドレスからのアクセスを許可し、その他のアクセスをブロック。
  • 仮想ネットワークルール：特定のVNetおよびサブネットからのアクセスを許可。VNet統合を使用して、内部ネットワークからのみストレージアカウントにアクセス可能に設定。

• セキュリティルールの設定

  • ファイアウォールとネットワークルールの適用：ストレージアカウントに対するアクセスを細かく制御。例えば、特定のサブネットからのみアクセスを許可し、他のサブネットからのアクセスを拒否。
  • プライベートエンドポイントの利用：ストレージアカウントへのアクセスをプライベートIP経由に限定。これにより、インターネット経由のアクセスを完全にブロックし、内部ネットワークからのみアクセスが可能に。

• 具体例

  • 内部アプリケーションのみアクセス許可：特定のVNetとサブネットからのみストレージアカウントにアクセス可能に設定。外部からのアクセスは全てブロック。
  • 全パブリックアクセスのブロック：ストレージアカウントの全てのパブリックエンドポイントを無効化し、必要な場合はプライベートエンドポイント経由のみアクセスを許可。

3.3 ネットワークサービスの高度な設定（追加）

3.3.1 Azure Firewall

• Azure Firewallの概要

  • クラウドベースのネットワークセキュリティサービス：インバウンドおよびアウトバウンドのトラフィックを制御。高度な脅威保護機能も提供。
  • ステートフルファイアウォール：接続の状態を追跡し、適切にトラフィックを許可または拒否。

• Azure Firewallの設定手順

  1. Azureポータルで「Azure Firewall」を選択し、「作成」をクリック。
  2. 基本設定：
     • サブスクリプション、リソースグループ、名前、リージョンを指定。
     • 仮想ネットワークと**サブネット（FirewallSubnet）**を選択。推奨サイズは/26以上。
  3. ファイアウォールポリシーの設定：
     • ネットワークルール、アプリケーションルール、DNATルールを定義。
  4. 設定の確認とデプロイ：設定内容を確認し、Azure Firewallをデプロイ。

• 利用シナリオ

  • 全社的なトラフィック管理：全VNetからのアウトバウンドトラフィックをAzure Firewallを通じて制御し、不正なアクセスを防止。
  • セキュアなインターネットアクセス：特定のアプリケーションやサービスへのアクセスのみを許可し、その他のアクセスをブロック。

• 具体例

  • 許可リスト方式のトラフィック管理：特定のIPアドレスやドメインからのトラフィックのみを許可し、他を全て拒否するポリシーを設定。
  • DNSフィルタリング：不正なDNSクエリをブロックし、悪意のあるサイトへのアクセスを防止。

3.3.2 Azure Load BalancerとApplication Gateway

• Azure Load Balancerの概要

  • TCP/UDPトラフィックのロードバランシング：L4（OSI層）のロードバランサーで、トラフィックをバックエンドプールのVMに分散。
  • 高可用性とスケーラビリティの提供：冗長構成と自動スケーリングにより、サービスの可用性を確保。

• Load Balancerの設定手順

  1. Azureポータルで「Load Balancer」を選択し、「作成」をクリック。
  2. 基本設定：
     • サブスクリプション、リソースグループ、名前、リージョンを指定。
     • SKU（BasicまたはStandard）を選択。
  3. フロントエンドIPの設定：公開IPアドレスまたは内部IPアドレスを設定。
  4. バックエンドプールの作成：ロードバランシング対象となるVMを指定。
  5. ロードバランシングルールの定義：トラフィックの振り分け方法（例：ラウンドロビン、最小接続数）。
  6. プローブの設定：バックエンドVMの健康状態を確認するためのヘルスプローブを設定。
  7. 確認および作成：設定内容を確認し、Load Balancerをデプロイ。

• Azure Application Gatewayの概要

  • L7（OSI層）のロードバランサー：HTTP/HTTPSトラフィックのロードバランシングとウェブアプリケーションファイアウォール (WAF) 機能を提供。
  • 高度なルーティング機能：URLパスベースのルーティング、マルチサイトホスティング、SSL終了など。

• Application Gatewayの設定手順

  1. Azureポータルで「Application Gateway」を選択し、「作成」をクリック。
  2. 基本設定：
     • サブスクリプション、リソースグループ、名前、リージョンを指定。
     • SKU（Standard、WAF、Standard_v2、WAF_v2）を選択。
  3. フロントエンドIPの設定：公開IPアドレスまたは内部IPアドレスを設定。
  4. バックエンドプールの作成：バックエンドのリソース（VM、App Service）を指定。
  5. HTTP設定の定義：プロトコル、ポート、Cookieベースのセッションアフィニティ。
  6. リスナーの設定：トラフィック受信ポート（通常は80および443）。
  7. ルーティングルールの作成：トラフィックをバックエンドプールにルーティングする方法を定義。
  8. WAF設定（必要に応じて）：ウェブアプリケーションファイアウォールを有効化し、セキュリティルールを設定。
  9. 確認および作成：設定内容を確認し、Application Gatewayをデプロイ。

• 利用シナリオ

  • Webアプリケーションの高可用性：複数のバックエンドインスタンスにトラフィックを分散し、負荷を均等化。
  • WAFによるセキュリティ強化：SQLインジェクションやクロスサイトスクリプティング (XSS) などのウェブ攻撃からアプリケーションを保護。
  • SSL終了：暗号化されたトラフィックをApplication Gatewayで解読し、バックエンドに平文で送信。

• 具体例

  • マルチサイトホスティング：Application Gatewayを使用して、app.contoso.com と shop.contoso.com のトラフィックをそれぞれ異なるバックエンドプールにルーティング。
  • URLパスベースのルーティング：contoso.com/images のトラフィックを特定のバックエンドサービスに、contoso.com/api のトラフィックを別のサービスにルーティング。

3.4 ネットワークサービスの拡張性と最適化

3.4.1 ネットワーク仮想アプライアンス (NVA)

• NVAの概要

  • VNet内でのサードパーティ製アプライアンスの利用：ファイアウォール、ルーター、プロキシなどをAzure VNet内で運用。
  • 高度なネットワーク機能の提供：VPN、ロードバランシング、セキュリティ強化などの追加機能を提供。

• NVAの導入手順

  1. Azure MarketplaceからNVAを選択：Fortinet FortiGate、Palo Alto Networks VM-Seriesなど。
  2. NVAのデプロイ：
     • Azureポータルで選択したNVAのテンプレートを利用してデプロイ。
     • 必要な設定（ライセンス、管理インターフェイス、ネットワーク設定）を行う。
  3. ネットワークルーティングの設定：VNet内のルートテーブルを設定し、トラフィックをNVA経由にルーティング。

• 利用シナリオ

  • 高度なセキュリティニーズ：企業のセキュリティポリシーに合わせた高度なファイアウォールルールを実装。
  • 複雑なルーティング要件：マルチリージョンやマルチVNet間のトラフィックルーティングを柔軟に制御。

• 具体例

  • データセンター間のセキュアな接続：NVAを介してオンプレミスのデータセンターとAzure VNet間のトラフィックを暗号化し、安全に接続。
  • アプリケーション層のセキュリティ強化：Webアプリケーションとデータベース間の通信をNVAでフィルタリングし、不正アクセスを防止。

3.4.2 ネットワークトラフィックの最適化

• Azure Traffic Managerの概要

  • DNSベースのトラフィック分散：複数のエンドポイントにトラフィックを分散し、高可用性とパフォーマンスを向上。
  • ルーティング方法：パフォーマンス、優先度、重み付けなど多様なルーティングポリシーを提供。

• Traffic Managerの設定手順

  1. Azureポータルで「Traffic Manager」を選択し、「作成」をクリック。
  2. 基本設定：
     • 名前、プロファイルタイプ（パフォーマンス、優先度、重み付け、地理的）を指定。
  3. エンドポイントの追加：複数のエンドポイント（Azure VM、Azure App Service、External Endpoint）を追加。
  4. ルーティングポリシーの選択：パフォーマンス重視、可用性重視などのポリシーを選択。
  5. 確認および作成：設定内容を確認し、Traffic Managerプロファイルをデプロイ。

• 利用シナリオ

  • グローバルアプリケーションの負荷分散：ユーザーの地理的位置に応じて最も近いエンドポイントにトラフィックを分散。
  • 冗長性の確保：主要なエンドポイントがダウンした場合、トラフィックを代替エンドポイントに自動的にルーティング。

• 具体例

  • ウェブサイトの高可用性：複数のAzureリージョンにホストされたウェブサイトに対してTraffic Managerを設定し、リージョン障害時にトラフィックを他リージョンにルーティング。
  • APIエンドポイントのパフォーマンス最適化：ユーザーの位置に基づき、最も低遅延なリージョンのAPIエンドポイントにトラフィックを分散。

---

5. 監視とレポート

5.1 Azure MonitorとLog Analytics

5.1.1 メトリックの収集

• Azure Monitorの概要

  • メトリック収集：Azureリソースからパフォーマンスメトリック（CPU使用率、メモリ使用量、ディスクI/Oなど）を収集。
  • ログ収集：診断ログ、アプリケーションログ、セキュリティログなどのログデータを収集し、分析。

• メトリックの使用

  • リソースのパフォーマンス監視：リアルタイムでリソースのパフォーマンスを監視し、異常を検出。
  • トレンド分析：長期的なパフォーマンスデータを基にトレンドを把握し、将来の需要を予測。

• Log Analyticsの概要

  • ログデータの集約と分析：複数のAzureリソースから収集されたログデータを集約し、クエリを通じて分析。
  • Kusto Query Language (KQL)：強力なクエリ言語を使用して、ログデータから有用なインサイトを抽出。

• 具体例

  • VMのCPU使用率の監視：Azure Monitorを使用してVMのCPU使用率をリアルタイムで監視し、閾値を超えた場合にアラートを発生。
  • アプリケーションログの分析：Log Analyticsでアプリケーションログをクエリし、エラーの頻度やパターンを分析。

5.1.2 アラートの作成と管理

• アラートの種類

  • メトリックアラート：特定のメトリックが閾値を超えた場合に発生。例：VMのCPU使用率が80%を超えた場合に通知。
  • ログアラート：Log Analyticsクエリの結果に基づいて発生。例：特定のエラーログが一定数発生した場合に通知。

• アラートの設定手順

  1. Azureポータルで「Azure Monitor」を選択。
  2. 「アラート」セクションで「新しいアラートルール」をクリック。
  3. 対象リソースの選択：アラートを設定するリソース（例：仮想マシン、ストレージアカウント）を指定。
  4. 条件の設定：閾値や監視するメトリック/ログを選択。例えば、CPU使用率が80%を超えた場合。
  5. アクショングループの設定：通知方法（メール、SMS、Webhook、Azure Functionなど）を設定。
  6. アラートルールの作成と有効化。

• アラートのベストプラクティス

  • 具体的な閾値設定：ビジネスニーズに合った閾値を設定し、不要なアラートを避ける。
  • 適切な通知方法の選択：重要なアラートには即時通知を設定し、非緊急のアラートには定期的なレポートを設定。
  • アクションの自動化：アラート発生時に自動でスクリプトを実行したり、VMをスケールアウトするなどのアクションを設定。

5.1.3 Azure Resource Manager (ARM)

• ARMの概要

  • インフラストラクチャのコード化：JSONテンプレートを使用してリソースを定義・デプロイ。リソースの一貫性と再現性を確保。
  • リソースの一括管理：リソースグループ単位での一括操作が可能。リソースグループは関連するリソースをまとめるコンテナ。

• リソースの展開と管理

  • テンプレートベースのデプロイ：
    • 一貫した環境構築：同一のARMテンプレートを使用して、同じ設定のリソースを複数回デプロイ。
    • 自動化：CI/CDパイプラインと連携し、コード変更に応じて自動デプロイ。
  • テンプレートのカスタマイズ：
    • パラメータ化されたテンプレート：テンプレート内でパラメータを定義し、柔軟なデプロイを実現。例：リージョンやVMサイズをパラメータとして指定。
    • 変数と出力の使用：テンプレート内で変数を定義し、デプロイ後の出力結果を取得。

• 監視との連携

  • デプロイメント監視：ARMテンプレートのデプロイ状況（成功、失敗）や詳細なログをAzureポータルで確認。
  • デプロイメントの問題解析：失敗したデプロイメントのエラーメッセージを基に、テンプレートの修正や再デプロイを実施。

• 具体例

  • Webアプリケーションのデプロイメント：ARMテンプレートを使用して、Webアプリケーションのインフラストラクチャ（VM、ストレージ、ネットワーク）を一括でデプロイ。
  • マルチリージョン展開：パラメータ化されたテンプレートを使用して、異なるリージョンにデプロイする際に必要な設定を動的に変更。

5.2 アラートと通知

5.2.1 アラートルールの詳解

• アラートルールの種類

  • マネージドメトリックアラート：Azureが提供する組み込みメトリック（例：CPU使用率、ディスクI/O）の監視。
  • カスタムメトリックアラート：ユーザーが定義したカスタムメトリック（例：アプリケーション特有のパフォーマンス指標）の監視。
  • ロギングアラート：Log Analyticsでクエリを実行し、その結果に基づいたアラート。例：特定のエラーログが一定数以上発生した場合にアラートを発生。

• アラートルールの管理

  • アラートルールの編集：既存のアラートルールの閾値や条件を変更。
  • アラートルールの削除：不要なアラートルールを削除し、アラートのノイズを減少。
  • アラートの重複防止：同じ条件で複数のアラートルールが存在しないように管理。

• アラートの優先順位設定

  • 高、中、低の優先度：アラートごとに優先度を設定し、重要度に応じた対応を可能に。
  • 緊急対応の設定：高優先度のアラートには即時対応が必要なアクションを設定。

5.2.2 アクショングループの活用

• アクショングループの概要

  • 通知方法の設定：メール、SMS、Webhook、Azure Logic Apps、Azure Functionsなど。
  • アクションの一括管理：複数のアラートルールで共通のアクショングループを使用可能。

• アクショングループの作成手順

  1. Azureポータルで「アクショングループ」を選択し、「作成」をクリック。
  2. 名称およびショートネームの設定。
  3. 通知メソッドの追加：
     • メール通知：特定のメールアドレスに通知を送信。
     • SMS通知：特定の電話番号にSMSを送信。
     • Webhook：外部サービスへのHTTPリクエストをトリガー。
     • Azure Function：特定のAzure Functionをトリガー。
  4. アクションの設定：必要な通知方法やアクションを順次追加。
  5. 作成を完了してアクショングループをデプロイ。

• アクショングループの利用シナリオ

  • 緊急アラートの通知：重要なシステム障害時に、管理者全員に即座に通知を送信。
  • 自動対応のトリガー：特定のアラート発生時に自動的にスクリプトやアプリケーションを実行。

• 具体例

  • システム障害時の対応：CPU使用率が急上昇した場合、管理者にメールで通知し、同時に自動スケールアウトスクリプトを実行。
  • セキュリティインシデントの通知：不正アクセスが検出された場合、セキュリティチームにSMSで即時通知を送り、関連するAzure Functionをトリガーしてログの収集を開始。

5.1.4 ダッシュボードと視覚化

• Azure Dashboardsの概要

  • カスタマイズ可能なダッシュボード：複数のAzureリソースのメトリックやログを一元的に視覚化。
  • ウィジェットの配置：グラフ、テーブル、カスタムウィジェットを使用して、情報をわかりやすく表示。

• ダッシュボードの作成手順

  1. Azureポータルで「ダッシュボード」を選択し、「新しいダッシュボード」をクリック。
  2. ダッシュボードにウィジェットを追加：
     • メトリックグラフ：CPU使用率、ネットワーク帯域幅などのメトリックをグラフとして表示。
     • ログクエリ結果：Log Analyticsクエリの結果を表やグラフで表示。
     • アラート一覧：現在のアラートステータスを一覧表示。
  3. レイアウトとデザインの調整：各ウィジェットの位置やサイズを調整し、見やすいレイアウトを構築。
  4. 保存と共有：ダッシュボードを保存し、必要に応じてチームメンバーと共有。

• 利用シナリオ

  • 運用監視：主要なAzureリソースのパフォーマンスと状態をリアルタイムで監視するためのダッシュボード作成。
  • ビジネスインテリジェンス：ビジネス指標やKPIをAzure Dashboardに統合し、ビジネスのパフォーマンスを可視化。

• 具体例

  • システム健全性ダッシュボード：VMのCPU使用率、メモリ使用量、ディスクI/Oを一目で確認できるダッシュボード。
  • セキュリティモニタリングダッシュボード：不正なログイン試行、ファイアウォールブロックイベント、WAFアラートなどを表示。

5.2 アラートと通知

5.2.1 アラートルールの詳解

• アラートルールの種類

  • マネージドメトリックアラート：Azureが提供する組み込みメトリック（例：CPU使用率、ディスクI/O）の監視。
  • カスタムメトリックアラート：ユーザーが定義したカスタムメトリック（例：アプリケーション特有のパフォーマンス指標）の監視。
  • ロギングアラート：Log Analyticsクエリの結果に基づいて発生。例：特定のエラーログが一定数以上発生した場合に通知。

• アラートルールの管理

  • アラートルールの編集：既存のアラートルールの閾値や条件を変更。
  • アラートルールの削除：不要なアラートルールを削除し、アラートのノイズを減少。
  • アラートの重複防止：同じ条件で複数のアラートルールが存在しないように管理。

• アラートの優先順位設定

  • 高、中、低の優先度：アラートごとに優先度を設定し、重要度に応じた対応を可能に。
  • 緊急対応の設定：高優先度のアラートには即時対応が必要なアクションを設定。

5.2.2 アクショングループの活用

• アクショングループの概要

  • 通知方法の設定：メール、SMS、Webhook、Azure Logic Apps、Azure Functionsなど。
  • アクションの一括管理：複数のアラートルールで共通のアクショングループを使用可能。

• アクショングループの作成手順

  1. Azureポータルで「アクショングループ」を選択し、「作成」をクリック。
  2. 名称およびショートネームの設定。
  3. 通知メソッドの追加：
     • メール通知：特定のメールアドレスに通知を送信。
     • SMS通知：特定の電話番号にSMSを送信。
     • Webhook：外部サービスへのHTTPリクエストをトリガー。
     • Azure Function：特定のAzure Functionをトリガー。
  4. アクションの設定：必要な通知方法やアクションを順次追加。
  5. 作成を完了してアクショングループをデプロイ。

• アクショングループの利用シナリオ

  • 緊急アラートの通知：重要なシステム障害時に管理者全員に即座に通知を送信。
  • 自動対応のトリガー：特定のアラート発生時に自動的にスクリプトやアプリケーションを実行。

• 具体例

  • システム障害時の対応：CPU使用率が急上昇した場合、管理者にメールで通知し、同時に自動スケールアウトスクリプトを実行。
  • セキュリティインシデントの通知：不正アクセスが検出された場合、セキュリティチームにSMSで即時通知を送り、関連するAzure Functionをトリガーしてログの収集を開始。

5.1.4 ダッシュボードと視覚化

• Azure Dashboardsの概要

  • カスタマイズ可能なダッシュボード：複数のAzureリソースのメトリックやログを一元的に視覚化。
  • ウィジェットの配置：グラフ、テーブル、カスタムウィジェットを使用して、情報をわかりやすく表示。

• ダッシュボードの作成手順

  1. Azureポータルで「ダッシュボード」を選択し、「新しいダッシュボード」をクリック。
  2. ダッシュボードにウィジェットを追加：
     • メトリックグラフ：CPU使用率、ネットワーク帯域幅などのメトリックをグラフとして表示。
     • ログクエリ結果：Log Analyticsクエリの結果を表やグラフで表示。
     • アラート一覧：現在のアラートステータスを一覧表示。
  3. レイアウトとデザインの調整：各ウィジェットの位置やサイズを調整し、見やすいレイアウトを構築。
  4. 保存と共有：ダッシュボードを保存し、必要に応じてチームメンバーと共有。

• 利用シナリオ

  • 運用監視：主要なAzureリソースのパフォーマンスと状態をリアルタイムで監視するためのダッシュボード作成。
  • ビジネスインテリジェンス：ビジネス指標やKPIをAzure Dashboardに統合し、ビジネスのパフォーマンスを可視化。

• 具体例

  • システム健全性ダッシュボード：VMのCPU使用率、メモリ使用量、ディスクI/Oを一目で確認できるダッシュボード。
  • セキュリティモニタリングダッシュボード：不正なログイン試行、ファイアウォールブロックイベント、WAFアラートなどを表示。

---

6. Azureバックアップと復元

6.1 データ保護戦略

6.1.1 Azure Backupの実装

• リカバリポイントの設定

  • 復元ポイントの作成：定期的にバックアップデータをスナップショットとして保存。例えば、毎日午前2時に完全バックアップを実行。
  • 保持ポリシーの設定：短期保持（例：日次バックアップを30日間保持）と長期保持（例：月次バックアップを12ヶ月間保持）を組み合わせてデータを管理。

• 復元手順

  1. Azureポータルで「バックアップ」を選択。
  2. Recovery Services Vaultを開く。
  3. リカバリポイントの選択：復元したいデータポイントを選ぶ。
  4. 復元操作の実行：
     • 元の場所へ復元：バックアップ時の設定に基づき、元の場所にデータを復元。
     • 別の場所へ復元：異なるリソースグループやリージョンにデータを復元。

• バックアップのベストプラクティス

  • 定期的なバックアップの実施：リスクに応じてバックアップの頻度と保持期間を設定。
  • バックアップの整合性確認：定期的にバックアップのテスト復元を実施し、データの整合性を確認。
  • アクセス制御の強化：バックアップデータには適切なアクセス権限を設定し、セキュリティを確保。

• 具体例

  • VMの定期バックアップ：重要な業務用VMを毎日バックアップし、30日間保持。必要に応じて最新のバックアップを即時に復元。
  • データベースのポイントインタイムリカバリ：SQLデータベースに対してポイントインタイムリカバリを有効化し、特定の時点にデータを復元可能にする。

6.1.2 Azure Site Recovery

• Azure Site Recoveryの概要

  • ディザスターリカバリサービス：オンプレミス環境や他のクラウドプロバイダーからAzureへのフェイルオーバーを管理。
  • ビジネス継続性の確保：災害時に迅速にサービスを復旧させるための計画と自動化。

• 設定手順

  1. Recovery Services Vaultの作成：Azureポータルで「Recovery Services vault」を選択し、「作成」をクリック。
  2. ディザスタリカバリエージェントのインストール：オンプレミスサーバーにSite Recoveryエージェントをインストール。
  3. レプリケーションポリシーの設定：データのレプリケーションスケジュール（例：10分毎）とデータ保持期間を定義。
  4. レプリケーションの開始：指定したポリシーに基づき、データをAzureにレプリケート。
  5. フェイルオーバーのテストと実行：ディザスター発生時にフェイルオーバーを実施。

• 復旧ポイントと計画

  • 復旧ポイントの選択：最新データポイントや特定の時点に基づいた復元を実行。
  • フェイルオーバーの種類：
    • プランドフェイルオーバー：計画的にフェイルオーバーを実行。
    • テストフェイルオーバー：実際のフェイルオーバーとは別に、復旧手順をテストして確認。

• 具体例

  • メインデータセンターの障害対策：主要データセンターが災害で利用不可になった場合、Azureでリカバリポイントを基にサービスを迅速に復旧。
  • アプリケーションの高可用性：予備の環境としてAzureにアプリケーションをレプリケートし、主要環境に障害が発生した際に自動的にフェイルオーバー。

• ベストプラクティス

  • ディザスタリカバリ計画の策定：重要システムやデータの復旧手順を詳細に文書化。
  • 定期的なテストフェイルオーバー：実際の災害時に備え、定期的にテストフェイルオーバーを実施し、計画通りに復旧できることを確認。
  • 監視とアラートの設定：Site Recoveryの状態を定期的に監視し、異常が検出された場合に通知を受けるように設定。

---

7. 費用管理とSLAs (サービスレベルアグリーメント)

7.1 コスト管理

7.1.1 Azure Cost Management and Billing

• コスト管理ツールの概要

  • Azure Cost Management and Billing：Azureリソースのコストと使用状況を監視し、管理するためのツール。
  • コストレポートの作成：特定期間内の支出を詳細に分析。サービス別、リソースグループ別、サブスクリプション別にコストを表示。

• コスト分析

  • コストレポートのカスタマイズ：期間やフィルターを設定して、詳細なコスト分析を実施。
  • 使用状況の分解表示：サービス別、リソースグループ別、タグ別に分解された使用状況を確認。

• 予算設定

  • 予算の作成：特定のリソースやプロジェクト、部門に対して予算を設定。例：マーケティング部門の予算を月額$10,000に設定。
  • 予算アラートの設定：予算の80%、90%、100%に達した際に通知を受け取るように設定。

• コストの最適化技術

  • 未使用リソースの識別：未使用のVMやストレージ、公開IPアドレスを特定し、削除または再利用。
  • 予約インスタンスの購入：長期的なリソース利用に対して予約インスタンスを購入し、割引価格でリソースを確保。例：1年または3年の予約インスタンスを購入。
  • スケールダウンの自動化：需要に応じてリソースのスケールアップ/スケールダウンを自動化し、コストを最適化。

• 具体例

  • サブスクリプションごとのコスト監視：プロジェクトごとにサブスクリプションを分け、各サブスクリプションのコストを個別に監視。
  • コストアラートの設定：予算超過を防ぐため、月次予算の90%に達した際に管理者にメール通知を設定。

7.2 サービスレベル契約 (SLAs)

• SLAsの概要

  • 可用性とパフォーマンスの保証：各Azureサービスには、サービスの可用性を保証するSLAが設定されている。例：VMのSLAは99.95%の可用性。
  • 補償ルール：SLAが未達成の場合、Azureからサービス料金の一部がクレジットとして提供される。

• VMのSLAs

  • 単一VMの可用性：99.9%の可用性が保証されている。
  • 可用性セットを利用したSLAsの向上：可用性セットを使用することで、SLAsが99.95%に向上。フォルトドメインと更新ドメインを分散することで、同時障害のリスクを低減。

• ストレージサービスのSLAs

  • 冗長性の種類に応じた可用性：
    • LRS (Locally Redundant Storage)：99.9%の可用性。
    • ZRS (Zone-Redundant Storage)：99.99%の可用性。
    • GRS (Geo-Redundant Storage) および RA-GRS (Read-Access GRS)：99.99%の可用性。
  • データ再取得の保証：各冗長性オプションに応じて、データの耐障害性と可用性が保証される。

• 具体例

  • VMの可用性設定：重要な業務用VMを可用性セットに配置して、99.95%の可用性を確保。
  • ストレージアカウントの冗長性選択：高可用性が求められるデータにはZRSまたはGRSを選択し、データの耐障害性を確保。

7.2.2 可用性と回復シナリオ

• 高可用性の実現方法

  • 可用性セットの利用：フォルトドメインと更新ドメインを分散させることで、複数のVMに対して冗長性を確保。例：同一サブスクリプション内で異なる更新ドメインにVMを配置。
  • 可用性ゾーンの利用：異なる地理的ゾーンにリソースを配置し、ゾーン単位の障害に対してもサービスを継続可能にする。例：ゾーン1とゾーン2に同じアプリケーションのVMを配置。

• 災害対策の計画

  • ディザスターリカバリプランの策定：重要リソースの優先順位付けと復旧手順を明確に定義。例：DBサーバーが最も優先度高く、アプリケーションサーバーが次に優先。
  • フェイルオーバーとフェイルバックのテスト：定期的にフェイルオーバーテストを実施し、計画通りに復旧できることを確認。また、フェイルバック手順も同様にテスト。

• 具体例

  • ディザスタリカバリプランの確立：主要なビジネスアプリケーションをAzure Site Recoveryにレプリケートし、オンプレミス障害時に迅速にAzureにフェイルオーバー。
  • マルチリージョン展開：Microsoft Azureの複数リージョンにアプリケーションを展開し、地域障害時に自動的に他リージョンからサービスを提供。

---

8. Azure Entra ID および関連リソース、プラン、ライセンスの詳細

8.1 Microsoft Entra ID の機能と役割

• アイデンティティ管理

  • ユーザー管理：ユーザーアカウントの作成、削除、プロビジョニング。ユーザー属性の管理やグループ割り当て。
  • グループ管理：アクセス制御のためのグループの作成と管理。動的グループを使用して属性に基づいた自動メンバーシップ管理。

• アクセス制御

  • RBAC (ロールベースのアクセス制御)：リソースに対するアクセス権限の細かな設定。標準ロールとカスタムロールの利用。
  • 条件付きアクセス：特定の条件下でのアクセス許可や制限。例：特定のデバイスレンジからのアクセス時のみMFAを要求。

• 認証

  • シングルサインオン (SSO)：複数のアプリケーションへの一括ログイン。ユーザーが一度の認証で複数のクラウドおよびオンプレミスアプリケーションにアクセス可能。
  • 多要素認証 (MFA)：セキュリティ強化のための追加認証手段。SMS、電話、Authenticatorアプリなどを利用。

8.2 Entra ID とライセンス管理

• 動的グループの利用

  • 属性に基づくメンバーシップルール：ユーザー属性（例：部署、役職）に基づいて自動的にメンバーを追加。例：「Department == 'Sales'」のユーザーを自動的にSalesグループに追加。
  • ライセンスの自動割り当て：動的グループに対してライセンスを割り当てることで、新たにグループに追加されたユーザーにも自動的にライセンスが適用される。

• ライセンスプランの種類

  • Microsoft 365 ライセンス：Officeアプリケーション、Teams、SharePoint、OneDriveなどを含む。
  • Azure AD Premium ライセンス：
    • Premium P1：条件付きアクセス、グループベースのアクセス管理、自己サービスのパスワードリセット。
    • Premium P2：ID保護、条件付きアクセスの高度な機能、エンタープライズアイデンティティ管理。

• 具体的な設定例

  • 動的グループの作成とライセンスの割り当て
    1. Azureポータルで「Microsoft Entra ID」を選択。
    2. 「グループ」 > 「新規グループ」をクリック。
    3. グループタイプ：セキュリティを選択。
    4. メンバーシップタイプ：動的ユーザーを選択。
    5. ルールの定義：ユーザー属性に基づいてメンバーを自動的に追加する条件を設定（例：「Department == 'Sales'」）。
    6. グループの作成を完了。
    7. 「ライセンス」 > 「ライセンスの割り当て」を選択。
    8. 対象のライセンス（例：Microsoft 365 E3）を選択。
    9. 「グループに割り当てる」を選択し、先ほど作成した動的グループを選択。
    10. 割り当ての確認を行い、適用。

• ライセンスの管理

  • ライセンス割り当ての確認：Azureポータルで各グループやユーザーに割り当てられたライセンスを確認。
  • ライセンスの再割り当てと解除：不要になったライセンスを再割り当てするか、解除してコストを最適化。

8.3 Entra ID の制約と考慮点

• ライセンスの管理

  • ライセンスの割り当てポリシー：動的グループのルール設定により、適切なユーザーに自動的にライセンスが割り当てられるよう設計。
  • ライセンスのスコープ：正確なライセンスの範囲と適用範囲を理解し、適切に管理。例えば、特定の部署だけにプレミアムライセンスを割り当てるなどの設定。

• 具体例と対策

  • ライセンスオーバープロビジョニングの防止：動的グループのルールを適切に設定し、必要以上にライセンスを割り当てないよう注意。定期的にライセンスの使用状況をレビュー。

---

9. Azure Active Directory (Entra ID) と関連リソースの詳細解説

9.1 Entra ID の属性と機能

• ユーザー属性

  • 標準属性：名前、メールアドレス、電話番号、部署、役職など。これらの属性はExcelやCSVからインポート可能。
  • カスタム属性：組織のニーズに合わせて追加する属性。Azure AD B2Cやカスタムディレクトリ拡張を使用して追加。

• リソースとプラン

  • 無料プラン：
    • 基本的なユーザー管理と認証機能。シングルサインオン（SSO）機能は一部制限あり。
  • 標準プラン（Azure AD Premium P1）：
    • 条件付きアクセス、動的グループ、自己サービスのパスワードリセット。
    • 組織全体でRBACの拡張。
  • プレミアムプラン（Azure AD Premium P2）：
    • ID保護、リスクベースの条件付きアクセスポリシー、エンタープライズアイデンティティ管理機能。
    • Privileged Identity Management (PIM) の機能も含む。

• 具体例

  • 基本的なユーザー管理：無料プランを使用して、新規ユーザーの作成と基本属性の管理。
  • 高度な条件付きアクセス：Premium P1を使用して、特定の条件（例：多要素認証が有効な端末からのアクセスのみ許可）でアクセスを制御。

9.2 Entra ID のライセンスとプランの違い

• Free vs. Premium P1 vs. Premium P2

  • Free：
    • 基本的なユーザー管理、シングルサインオンの一部機能、基本的なセキュリティ機能。
  • Premium P1：
    • 条件付きアクセス、多要素認証の高度な設定、グループベースのアクセス管理。
    • 自己サービスのパスワードリセット、高度なレポート機能。
  • Premium P2：
    • リスクベースの条件付きアクセス、ID保護機能、Privileged Identity Management (PIM)。
    • エンタープライズアイデンティティ管理機能、組織のセキュリティポリシーを強化。

• ライセンスの割り当て

  • ユーザーベースの割り当て：個々のユーザーにライセンスを直接割り当て。
  • グループベースの割り当て：動的グループを使用して自動的にライセンスを割り当て。これにより、ユーザー属性に基づいてライセンスが自動適用。

• 具体例

  • グループベース割り当て：特定の部門（例：営業部）の動的グループにPremium P1ライセンスを割り当て、部門のユーザーが自動的にライセンスを取得。
  • 個別ユーザー割り当て：一部のエキスパートユーザーにPremium P2ライセンスを直接割り当て、高度なID管理機能を提供。

9.3 Entra ID の制約とベストプラクティス

• 制約

  • ライセンスの管理コスト：Premiumライセンスは有料であり、必要なユーザーに対して適切に割り当てる必要がある。
  • スケーラビリティ：大規模組織ではライセンスの割り当てと管理が複雑化するため、グループベースの管理が推奨される。
  • 属性の制限：動的グループのルール設定には、Azure ADがサポートする属性に制限がある。必要な属性がサポートされていない場合、カスタム属性の追加が必要となる。

• ベストプラクティス

  • 最小権限の原則：ユーザーに必要最低限の権限を付与し、不要なアクセスを制限。
  • 定期的なレビュー：ユーザーのアクセス権限とライセンスの使用状況を定期的にレビューし、適切な調整を行う。
  • グループベースのライセンス割り当て：動的グループを使用して自動的にライセンスを管理し、手動での割り当てミスを防止。
  • セキュリティポリシーの強化：条件付きアクセスを活用し、セキュリティ基準に基づいたアクセス制御を実施。