mcpField
A
azure-arc

azure-arc

github.com/vinayaklattheクラウド・DevOps17976 回インストール1 日前に更新
リポジトリ

azure-arc について

azure-arc は、オンプレミス、マルチクラウド、エッジのリソースを Azure Resource Manager に取り込むためのガイダンススキルです。ハイブリッド環境全体に Azure のガバナンス、セキュリティ、監視、更新管理を適用できます。

主な機能

  1. 01ハイブリッドサーバーと Kubernetes の登録
  2. 02Azure Policy とマシン構成の適用
  3. 03Defender for Cloud による保護の拡張
  4. 04監視と更新管理の統合
  5. 05Azure RBAC によるアクセス管理
  6. 06登録に必要なネットワークとプロキシの計画

活用シーン

  1. 01オンプレミスサーバーを Azure ガバナンスに追加
  2. 02マルチクラウドマシンへのセキュリティポリシー適用
  3. 03非 AKS Kubernetes クラスターの一元管理
  4. 04ハイブリッドサーバー群の監視と更新

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill azure-arc

インストール後、Claude Code で/azure-arcを入力して読み込まれたか確認します。

詳細

Azure Arc

Azure Arc は、オンプレミス、マルチクラウド、エッジのリソースを Azure Resource Manager に投影し、Azure ネイティブのリソースと同じコントロールプレーンでガバナンス、セキュリティ保護、管理を行えるようにします。これにより、Azure Policy、Microsoft Defender for Cloud、Azure Monitor をハイブリッド環境に拡張できます。

使用する場面

Azure 以外のサーバー、Kubernetes クラスター、データサービスに、一貫した Azure のガバナンスとセキュリティを適用する場合に使用します。ハイブリッド/マルチクラウドのマシンを一元的に可視化し、ポリシーを適用する必要がある場合に、このスキルを使用してください。

このスキルを使用しないでください。Azure ネイティブの VM(ARM を直接使用してください)、Intune で管理されるエンドポイント(intune-device-mgmt)、または Azure Stack HCI のデプロイには使用しません。

リソースの種類に応じた Arc 機能の選択

リソースの種類Arc サービス利用できる機能
オンプレミス/AWS/GCP のサーバーArc-enabled serversDefender for Cloud、Policy、Update Manager、Monitor、RBAC
AKS 以外の Kubernetes(オンプレミス、EKS、GKE)Arc-enabled KubernetesFlux による GitOps、Policy、Monitor、Defender for Containers
オンプレミス/他のクラウドの SQL ServerArc-enabled SQL Serverインベントリ、ベストプラクティス評価、Defender
エッジの PostgreSQL/SQL MIArc-enabled data servicesエッジでのマネージド PaaS のようなエクスペリエンス
ハイブリッドアプリプラットフォーム(コンテナー化)Arc-enabled App Services / FunctionsArc 対応 K8s 上の PaaS ランタイム

経験則: まずはハイブリッド環境への対応として、Arc-enabled servers から始めましょう。最も価値が高く、導入の負担が最も少ないステップです。Connected Machine エージェントを使うと、アウトバウンド HTTPS 接続だけで、ハイブリッド環境全体に Defender for Cloud と Azure Policy を適用できます。

アプローチ

  1. オンボーディングの範囲と ID を計画する — Arc リソースを配置するサブスクリプション/リソースグループを決定します。リージョンごと/事業部門ごとの対象リソースグループを定義します。スクリプトで大規模にオンボーディングする場合は、事前にサービスプリンシパルを作成します。 確認:対象 RG が存在し、オンボーディング ID に Azure Connected Machine Onboarding ロールが割り当てられていること。

  2. ネットワークとプロキシの要件を計画する — Connected Machine エージェントは、定義された Microsoft エンドポイントのリストへのアウトバウンド HTTPS(443)接続を必要とします。サーバーが社内プロキシの背後にある場合は、エージェントにプロキシと認証を設定します。一部のエンドポイントでは、ファイアウォールでの許可リスト登録が必要です。 確認:パイロットサーバーが *.his.arc.azure.com、*.guestconfiguration.azure.com、*.dp.kubernetesconfiguration.azure.com(K8s の場合)に接続でき、エージェントのインストールが完了すること。

  3. サーバーを大規模にオンボーディングする — まず、Windows と Linux をそれぞれ 1 台含む 5~10 台のサーバーを手動でパイロット導入します。その後、ロールアウトをスクリプト化します。Windows では GPO/Ansible/Configuration Manager、Linux では cloud-init/Ansible を使用します。エージェントのスクリプトには、サービスプリンシパルとタグを指定できます。 確認:Arc リソースが対象 RG に表示され、状態が Connected で、タグが適用されていること。

  4. Azure Policy とマシン構成でガバナンスを適用する — リソースグループ/サブスクリプションのスコープで Azure Policy イニシアティブ(例:Azure Security Benchmark)を割り当てます。**マシン構成(旧称 guest configuration)**は、Azure VM と同様に Arc マシン上の OS 内設定を監査します。 確認:ASB イニシアティブに Arc マシンのコンプライアンス状態が表示され、OS 内監査で結果(パスワードの複雑さなど)が返されること。

  5. Defender for Cloud を拡張する — Arc リソースを含むサブスクリプションで Defender for Servers Plan 2 を有効にします。Defender は、MDE、ファイル整合性監視、適応型制御を Arc マシンにデプロイします。 確認:Defender for Servers で Arc マシンが保護対象として表示され、MDE でオンボーディング済みと表示されること。

  6. 監視と更新を統合する — Azure Monitor Agent(拡張機能)を介して、Arc マシンのログを Log Analytics に送信します。Azure Update Manager を使用して、ハイブリッド環境全体の更新プログラムを Azure から評価およびデプロイします。

  7. Azure RBAC でアクセス権を付与する — Arc マシンは ARM リソースです。Azure RBAC と PIM を使用して、管理権限を持つユーザーを制御します。Arc エージェントは、Azure サービスへのアウトバウンド呼び出しに使用するマネージド IDもマシン上で有効にします。

ガードレール

  • Connected Machine エージェントとそのアウトバウンド接続を保護し、管理対象 ID の権限を最小限にします。 エージェント ID が侵害されると、Azure への横方向の侵入経路になります。
  • 大規模なオンボーディングの前に、ネットワーク/プロキシとファイアウォールの要件を計画します。 エージェントが失敗しても通知されず、環境が正常に見えているだけで、実際には監視できていない状態になります。
  • Arc を使用してセキュリティ態勢を統一し、ハイブリッドサーバーを Defender for Cloud の対象外にしないでください。 「ハイブリッドは後で対応する」という隙間に、ランサムウェアが潜んでいます。
  • Arc Policy はオンプレミスの Policy と同じです。 Azure VM に適用するポリシーと同じものを Arc マシンにも適用できます。継承させるには、管理グループ/サブスクリプションレベルで割り当てます。
  • Arc リソースには Azure ネイティブのリソースと一貫したタグを付けます。 そうしないと、コストレポート、所有権、Defender の優先順位付けに支障が出ます。
  • Defender for Servers Plan 2 はマシンごとに課金されます。 コストを考慮してオンボーディングし、まずパイロット導入を行います。

よくあるアンチパターン

  • 「ファイアウォールの計画をせずにサーバーをオンボーディングする」 - エージェントは通知なしに失敗し、環境が管理されていないように見えます。まず許可リストを設定してください。
  • 「5,000 台のサーバーを手動でオンボーディングする」 - 維持できません。SP とタグを使ってスクリプト化してください。
  • 「Defender for Servers Plan 1 のみを使う」 - Plan 1 には MDE/脆弱性管理/ファイル整合性の機能がありません。本番環境には Plan 2 を使用してください。
  • 「Arc エージェントをリモート実行用のバックドアとして使う」 - 魅力的に見えますが、セキュリティモデルに反します。RBAC で管理される ARM 経由の Run Command を使用してください。
  • 「Arc マシンに Azure VM とは異なるタグを付ける」 - レポートに差異が生じます。同じタグ付け方式を使用してください。
  • 「レガシーな DC はいずれ廃止されるため、サーバーをオンボーディングしない」 - 思っているほど早く廃止されることはありません。管理されていない DC が侵害の発生源になります。

プロンプト例

  • オンプレミスのサーバーを Azure に Azure Arc でオンボーディングし、Defender for Cloud を適用してください。
  • Azure Arc を使って、Azure からマルチクラウドのマシンを管理するにはどうすればよいですか?
  • サービス プリンシパルを使って Azure Arc エージェントを大規模にデプロイし、セキュリティポリシーを適用してください。
  • Flux GitOps を使って、Arc 対応 Kubernetes クラスターを一元的なガバナンスの対象にしてください。
  • Azure Security Benchmark イニシアティブを Arc 対応サーバーに適用してください。
  • Arc の大規模なオンボーディングの前に、ネットワークとプロキシの要件を計画してください。

Microsoft Learn

コメント