Microsoft AZ-500: アプリケーションセキュリティと DevSecOps — 学習ガイド

By Laurynas Brazys · 12 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

こちらの一部です： Microsoft Azure Security Engineer Associate AZ-500 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

AzureにおけるアプリケーションセキュリティとDevSecOpsは、IDの不正使用の防止、イングレスとAPIの保護、パイプラインにおけるセキュリティのシフトレフト、保存中および転送中のシークレットの保護、そして堅牢なリリースガバナンスの徹底に重点を置いています。効果的な設計では、長期的なシークレットを排除し、最小権限を使用し、すべての呼び出し元を検証し、コード、依存関係、インフラストラクチャ、ランタイムにわたる継続的な検出と修復を制度化します。

アプリケーションID、イングレス、API保護のセキュリティ確保

Microsoft Entra ID (Azure AD)におけるアプリケーションIDのセキュリティ確保は、適切にスコープが設定されたアプリ登録と、正しいOAuth 2.0フローから始まります。

• 委任されたアクセス許可は、ユーザーがサインインしている場合に適用され、その同意は確認済み発行元のアプリまたは管理者承認済みのスコープのみに制限できます。アプリケーションのアクセス許可 (アプリ専用) は、ユーザーなしで動作するバックグラウンドデーモンやサービスを承認するため、常に管理者の同意が必要です。
• 必要な最小限のスコープまたはアプリケーションロールのみを付与し、同意要求の管理者レビューを必須とすることで、最小権限を徹底します。同意フィッシングを減らすために、エンドユーザーの同意を無効にするか、低リスクで確認済みの発行元のみに許可します。
• クライアントシークレットよりも証明書資格情報またはフェデレーションIDを優先します。証明書はより強力な保証と予測可能なローテーションをサポートします。短い有効期間を設定し、ローテーションを自動化します。必要でない限り、パブリッククライアントフローをブロックします。
• Azureサービスには、アプリのシークレットの代わりにマネージドIDを使用します。Key Vault Secrets UserやStorage Blob Data Readerなどのデータプレーンロールを割り当て、該当する場合はPrivate Endpointsを使用してネットワークアクセスを制限します。

Application Gateway WAF v2とAzure Front Door WAFは、パブリックなイングレスをOWASP Top 10の脅威から保護します。

• 最新のMicrosoft管理OWASPコア ルール セットを有効にし、チューニング後に防止モードで実行します。学習中の誤検知を減らすために、最初は異常スコアリングを使用します。
• geoフェンシング、IPレピュテーションブロック、ヘッダーの強制、要求サイズの制限のためのカスタムルールを構成します。Front Doorでは、クライアントIPごとのレート制限ルールを追加して、クレデンシャルスタッフィングや基本的なL7 DoS攻撃を鈍化させます。
• 強力な暗号スイートとポリシーでTLSを終端させ、オリジンまでエンドツーエンドTLSを使用します。mTLSが必要なシナリオでは、Application Gatewayリスナーでクライアント証明書の検証を構成します。
• WAFポリシーをリスナー/ルートに正確にアタッチします。ルールの除外は、誤検知を完全に理解した場合にのみ使用します。WAFログをLog Analyticsにストリーミングして、検出エンジニアリングとインシデント対応に活用します。

API Management (APIM)は、多層的なセキュリティ体制を確立します。

• ゲートウェイで、発行者、対象ユーザー、スコープを厳密にチェックしてOAuthトークンを検証します。すべての通信でHTTPSを必須とし、クライアントの信頼境界で必要な場合はmTLSを強制します。
• 多層防御とスロットリングIDのために、サブスクリプションキーとOAuthを組み合わせます。製品レベルのサブスクリプションキーを使用してコンシューマーを分割し、他のコンシューマーに影響を与えることなくキーをローテーションします。
• コンシューマーごと、スコープごと、またはサブスクリプションごとに粒度を設定して、レート制限とクォータを適用します。適切な場合は、IPフィルターを使用してパートナーネットワークを許可リストに登録します。
• 相互TLSまたはマネージドIDを使用してバックエンドサービスを保護します。シークレットは、設定内の平文を避けるために、Key Vault参照をバックエンドとする名前付きの値として保存します。

JWTスコープの強制とスロットリングのためのAPIMポリシーの例:

<policies>
  <inbound>
    <base />
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401" require-scheme="Bearer">
      <openid-config url="https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration" />
      <audiences>
        <audience>api://your-api-app-id</audience>
      </audiences>
      <required-claims>
        <claim name="scp">
          <value>read.items</value>
        </claim>
      </required-claims>
    </validate-jwt>
    <rate-limit-by-key calls="100" renewal-period="60" counter-key="@(context.Subscription?.Key ?? context.Request.IpAddress)" />
  </inbound>
  <backend><base /></backend>
  <outbound><base /></outbound>
  <on-error><base /></on-error>
</policies>

DevSecOpsパイプラインの強化とDefender for DevOps

Azure DevOpsとGitHub Actionsは、長期的なシークレットなしでAzureに認証する必要があります。

• サービス接続にはワークロードIDフェデレーション (OIDC) を使用します。Entra IDでアプリ登録/サービスプリンシパルを作成し、リポジトリ、ブランチ、ワークフロー/環境をIDにバインドするフェデレーション資格情報を追加します。これにより、保存されたシークレットなしで短期的なトークンが生成され、Azure RBACを介した最小権限のスコープ設定がサポートされます。
• パイプラインのアクセス許可をロックダウンします。サービス接続の使用には承認を要求し、パイプラインを保護されたブランチに制限し、必要でない限り「スクリプトによるOAuthトークンへのアクセスを許可する」を無効にします。マスク機能付きの変数グループとシークレットを使用し、ログコマンドによるシークレットのエコーを禁止します。GitHubでは、一元管理のためにリポジトリレベルのシークレットよりも環境および組織レベルのシークレットを優先し、該当する場合はホストされたランナーで「ログ内のシークレットを防止する」設定を使用します。
• 環境保護ルールを適用します。必須のレビュー担当者、チェック (例: 変更管理チケット、テスト合格)、時間ベースの承認などです。

Azure CLIでフェデレーション資格情報を作成する (GitHub OIDCの例):

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"github-oidc-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:org/repo:ref:refs/heads/main",
    "audiences":["api://AzureADTokenExchange"]
  }'

Microsoft Defender for DevOpsはAzure ReposおよびGitHubと統合し、以下の情報を表示します。

• 一般的な言語でのコードセキュリティの検出結果 (SAST)。プルリクエストのアノテーションは、リグレッションを防ぐために新しい問題を強調表示します。
• OSSライブラリに対する脆弱性インテリジェンスを使用した依存関係のリスク (SCA)。修正ガイダンスと修正済みバージョンが提供されます。
• 漏洩したトークン/キーに対するシークレット漏洩の検出と推奨されるローテーション。
• ARM/Bicep/TerraformにわたるInfrastructure-as-Codeの構成ミス (例: パブリックストレージ、寛容なNSG)。ポリシー主導のガバナンスとドリフト追跡機能付き。 検出結果は、優先順位付けのためにリポジトリとパイプラインのコンテキストとともにDefender for Cloudに集約されます。重大度のしきい値に基づいてリリースをゲートし、安全でないデプロイを停止します。

シークレット管理とプラットフォーム統合

Key Vaultは、シークレット、キー、証明書の一元管理と包括的な制御機能を提供します:

• 破壊的な損失を防ぐために、消去保護と論理的な削除 (ソフトデリート) を強制します。認可を統合するために、アクセスポリシーよりもRBACを優先します。可能な場合はPrivate Endpointを有効にし、パブリックネットワークアクセスを無効にします。安全なワークスペースへのログ記録を有効にします。
• App ServiceとFunctionsは、マネージドIDを使用してアプリ設定内でKey Vault参照を使用します。これにより、再デプロイなしでシークレットを透過的にローテーションできます。
• AKSは、Azure AD Workload Identity (推奨) によって認証され、Azure Key Vaultプロバイダーを備えたSecrets Store CSI Driverを介して、ランタイム時にシークレットを取得します。平文のシークレットをKubernetes Secretオブジェクトに配置することは避けてください。

App ServiceのKey Vault参照の例:

Name: DbConn
Value: @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnString/23a1...)

AKS SecretProviderClass (抜粋):

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: kv-secrets
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "false"
    useWorkloadIdentity: "true"
    keyvaultName: kv-prod
    tenantId: <tenant-id>
    objects: |
      array:
        - | 
          objectName: api-key
          objectType: secret

パイプラインは、ジョブの実行時にシークレットを取得する必要があります:

• Azure DevOps: マネージドIDベースのサービス接続を持つKey Vaultタスクを使用します。シークレットのダウンロードを最小限のステージに制限します。
• GitHub Actions: OIDC認証のためにazure/loginを使用し、必要なシークレット名のみを取得するためにazure/keyvaultを使用します。

← Microsoft Sentinel とセキュリティオペレーション · すべてのドメイン · ハイブリッドおよびマルチクラウドのセキュリティ →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Microsoftを閲覧 →