Open3
いま自分に必要な、Azureのサービスについてまとめていく
Mark- エッジ/公開
- Azure Front Door Standard/Premium（WAF 付き）
- Azure DNS (独自ドメインなら)
- コンテナ基盤
- Azure Container Apps (ACA) + ACA Environment
- Azure Container Registry (ACR)
- データ層
- Azure Database for MySQL
- Azue Cache for Redis
- Azure Storage (Blob)
- ネットワーク/セキュリティ
- VN (Hub - Spoke)
- Private Endpoint
- NSG
- Azure Firewall
- NAT Gateway
- Microsoft Entra ID
- Azure Key Vault
- 監視／ログ／セキュリティ態勢
- Azure Monitor / Diagnostic Settings
- Log Analytics Workspace
- Application Insights
- アラート（Alerts / Action Group）
- Microsoft Defender for Cloud
Mark1. エッジ/公開
Azure Front Door Standard/Premium（WAF 付き）
グローバルに展開されているエッジサーバを利用し、Web アプリケーションのパフォーマンス、セキュリティおよび可用性を向上させることができます。
Standard と Premium の2つのレベルがあり、それぞれにWeb アプリケーション ファイアウォール (WAF) を組み込むことができます。
主な機能
- グローバル負荷分散: ユーザーに最も近いバックエンド（オリジン）にトラフィックをルーティングし、低遅延を実現します。
- コンテンツ配信ネットワーク（CDN）: 静的コンテンツをエッジサーバーにキャッシュして高速配信します。
- WAF: OWASP Top 10 の脅威など、一般的な Web 攻撃からアプリケーションを保護します。
OWASP top 10 について (ChatGPT)
OWASP（Open Web Application Security Project）は、ウェブアプリケーションのセキュリティに関する啓発・ツール提供する非営利コミュニティです。
Top 10 は、Web アプリケーションにおいて“よくある重大な脆弱性”をリスク視点で整理したリストで、開発者・セキュリティ技術者の注意喚起やチェックリスト的利用を目的としています。
| 番号 | 名称 | 内容・狙われる脆弱性 | 対策のポイント | |
|---|---|---|---|---|
| A01: Broken Access Control（アクセス制御の不備） | 認可やアクセス制御が不十分で、認証済ユーザが許されない操作・データへアクセスできる | 典型例：IDOR（Insecure Direct Object Reference）、URL 改変、強制型パラメータ変更、未チェックの HTTP メソッド利用など | 全てのアクセス制御チェックをサーバ側で実施。フロント側（UI や JavaScript）だけで制御しない。最小権限原則、オブジェクトレベル／フィールドレベルの制御、ペネトレーションテストやコードレビューで穴を探す (blackduck.com) | |
| A02: Cryptographic Failures（暗号化失敗） | データ保護のための暗号化・ハッシュ・鍵管理が不適切で、機密情報が漏えいする | 平文通信、弱い暗号アルゴリズム（例：MD5、SHA1、古い暗号モード）、ハードコーディング鍵、証明書検証不備など | TLS の適切利用（最新のバージョン・強い暗号スイート）、鍵／証明書の安全管理、暗号アルゴリズム／モードの選定、データの整合性チェックや MAC、暗号操作ライブラリの利用（自前実装回避） (blackduck.com) | |
| A03: Injection（インジェクション） | 外部から入力されたデータが SQL／LDAP／OS コマンド等として解釈され、意図しない命令実行やデータ操作がされる | 例：SQLインジェクション、OS コマンドインジェクション、LDAP インジェクション、テンプレートインジェクション、NoSQL インジェクション、ログインインジェクションなど | 入力値の検証・エスケープ／パラメータ化クエリ（プレースホルダ使用）、ホワイトリスト検証、プリペアドステートメント使用、入力長制限、最小権限での DB 接続、異常系テスト（ペネトレーション）を行う (OWASP) | |
| A04: Insecure Design（安全でない設計） | セキュリティを考慮せずにシステム・アーキテクチャを設計・モデリングしてしまう | 脅威モデリングがない、セキュリティ設計が後付け、設計段階でのリスク分析不足など | 「セキュリティ・バイ・デザイン（Security by Design）」を採用、脅威モデリング、セキュア設計パターン／参照アーキテクチャ採用、設計レビュー、仕様段階でのセキュリティ要求定義を明確化する (blackduck.com) | |
| A05: Security Misconfiguration（セキュリティ設定ミス） | ミドルウェア／OS／フレームワーク／アプリケーション設定が不適切で、意図しない挙動や情報漏洩につながる | デフォルト設定放置、デバッグモード有効、不要な機能有効、不要なポート開放、管理画面公開、CORS や HTTP ヘッダ不適切設定など | セキュアな初期設定、不要機能の無効化、構成管理（Infrastructure as Code 等）、定期的な構成チェック、自動化チェックツール（lint、セキュリティ構成スキャナ等）導入 (blackduck.com) | |
| A06: Vulnerable and Outdated Components（脆弱・古いコンポーネント使用） | 外部ライブラリ／モジュール／フレームワークなどの既知脆弱性を含むバージョンを使ってしまう | 旧バージョンライブラリ、未修正の OSS、既知 CVE を含むモジュール、依存関係のチェーンでの脆弱性転嫁など | ソフトウェア構成管理（SCA：Software Composition Analysis）を導入、定期的なアップデート／パッチ適用、不要依存の削除、脆弱性アラート対応、サプライチェーンリスク管理 (Mend.io) | |
| A07: Identification and Authentication Failures（識別・認証の失敗） | 認証機構（ログイン、セッション管理、マルチファクターなど）に不備があって、なりすましや認証回避が可能になる | 弱いパスワード許容、パスワードリスト攻撃耐性なし、セッション ID 漏洩、セッショントークン固定、認証フロー不備など | 強力な認証方式（多要素認証、OAuth2, OIDC 等の信頼フレームワーク利用）、セッション管理安全化（期限・再生成・セキュア属性設定）、パスワード強制ポリシー、アカウントロックアウト、異常ログイン検知など | (blackduck.com) |
| A08: Software and Data Integrity Failures（ソフトウェア・データ完全性の失敗） | ソフトウェア更新、データストレージ、依存関係管理において改ざんや不正挿入が起き得る | 不正なアップデート（マルウェア混入）、署名検証なし、コンテナイメージの信頼性欠如、ビルドチェーンの改ざん、データの整合性チェックなし | ソフトウェア署名／チェックサム／ハッシュ検証、信頼できる DevOps パイプライン、CI/CD のセキュリティ、イミュータブルインフラ、コードサプライチェーン（SBOM 等）管理 | (Mend.io) |
| A09: Security Logging and Monitoring Failures（セキュリティログ & モニタリングの失敗） | セキュリティ事象を適切に記録・監視できず、侵入後の検知や対応が遅れる | ログを残さない、ログの不十分な内容、モニタリングやアラート未設置、ログ改ざん耐性なしなど | 重要イベントを適切にログ出力、ログの保護と不変性、リアルタイム監視・アラート、SIEM／ログ分析システム導入、侵入検知体制、定期レビューとフォレンジック対応体制確立 | (blackduck.com) |
| A10: Server-Side Request Forgery (SSRF)（サーバー側リクエスト偽装） | サーバーの機能（バックエンドアクセス、API 呼び出しなど）を通じて、攻撃者が任意の URL にリクエストさせ、内部システムや機密ネットワークにアクセスする | 外部 URL を受ける API により、不正な内部アドレスやメタデータ取得、クラウドメタデータ API へのアクセス、内部ネットワークスキャンなど | 受け付ける URL ホワイトリスト化、外部アクセスの制限、プロキシ経由制御、URL 検証／正規化、タイムアウト制御、ネットワークレベルでアクセス制御（FW/VPC ACL）など | (Mend.io) |
- DDos保護: レイヤー3/4およびレイヤー7のDDos攻撃に対する保護を提供する。
レイヤー別のDDos攻撃
レイヤー3/4
通信そのものを大量に発生させてネットワークやサーバの帯域・CPU・メモリを枯渇させる攻撃です。
「通信レベルでの妨害」と考えると理解しやすいです。
| 攻撃名 | 層 | 内容 |
|---|---|---|
| ICMP Flood（Ping Flood） | L3 | ICMP（ping）を大量送信して帯域を圧迫 |
| UDP Flood | L4 | UDPパケットをランダムなポートに大量送信してリソースを圧迫 |
| TCP SYN Flood | L4 | TCP接続の「SYN」パケットだけ送り続け、サーバが「SYN-ACK」を返したまま未完了接続を大量に保持させる（半開状態DoS） |
| IP Fragmentation攻撃 | L3 | 分割されたIPパケットを大量送信して再構築処理を過負荷にする |
特徴
- 通常は ネットワーク機器レベル（ファイアウォール、ロードバランサ、CDN、WAFの前段） で防御。
- トラフィック自体をブロック・制限するのが目的。
- 攻撃量は「Gbps」「pps（パケット毎秒）」単位で計測されることが多い。
レイヤー7
通信自体ではなく、アプリケーションの処理能力を狙う攻撃です。
HTTPやDNSなどのアプリ層プロトコルを悪用して、正常リクエストに見せかけた攻撃を行います。
| 攻撃名 | 層 | 内容 |
|---|---|---|
| HTTP Flood | L7 | 「/search?q=...」など通常のHTTPリクエストを大量送信し、アプリサーバのCPU・DBクエリ・メモリを消費させる |
| Slowloris 攻撃 | L7 | HTTPヘッダを極端にゆっくり送ってサーバの接続スレッドを占有する |
| DNS Query Flood | L7 | DNSサーバに大量の問い合わせを送りつける |
| API Abuse / Bot攻撃 | L7 | APIエンドポイントへボットで大量アクセス（たとえば /login に連続POST） |
特徴
- 通常は WAF（Web Application Firewall）やCDN（例：Azure Front Door, AWS CloudFront） が防御を担当。
- 攻撃をリクエスト内容単位で検知・遮断する。
- 攻撃量は「RPS（リクエスト毎秒）」単位で計測される。
- SSL オフロード: エッジサーバーでSSLハンドシェイクを処理し、バックエンドの負荷を軽減します。
- プライベートリンク対応: プライベートエンドポイント経由でバックエンドに接続し、セキュリティを強化します（Premiumのみ）。
Premium と Standardの接続方法
Front Door Premiumとプライベートエンドポイント接続の仕組み
Azure Front Door Premiumでプライベートエンドポイントを利用する場合、以下のような流れでバックエンドと接続されます。
- 接続要求: ユーザーがFront Door Premiumにアクセスすると、Front Doorはバックエンドへの接続を試みます。
- プライベートエンドポイント作成: Front Doorは、バックエンド側（ユーザーの仮想ネットワーク内）に、Front Doorが管理するプライベートネットワークからプライベートエンドポイントを作成するよう要求します。
- 接続承認: バックエンド側（例: App ServiceやStorage Account）では、このプライベートエンドポイント接続要求を承認します。
- プライベート接続確立: 接続が承認されると、Front Doorとバックエンドの間でMicrosoftのバックボーンネットワークを経由したプライベートな接続が確立します。
- トラフィックの流れ:
- ユーザーのリクエストはFront DoorのグローバルPOP（Point of Presence）に到達します。
- そこから、Microsoftのバックボーンネットワークを通り、Front Doorが管理するプライベートネットワークに転送されます。
- 最終的に、バックエンドのプライベートエンドポイントを経由して、バックエンド（App Service、Storage Accountなど）に到達します。
Standardの場合
Azure Front Door Standardは、バックエンドへの接続にパブリックIPアドレスまたはパブリックに解決可能なDNS名を使用します。Private Linkを利用したプライベート接続はできないため、バックエンドはインターネットに公開されている必要があります。
バックエンドをインターネットに公開することになりますが、セキュリティを確保するためのいくつかの方法があります。
1. Front Door のサービス タグを使用する
- 方法: バックエンドのリソース（例: App Service）のネットワークセキュリティグループ（NSG）またはファイアウォールで、AzureFrontDoor.Backendというサービス タグからのトラフィックのみを許可するように設定します。
- 仕組み: AzureFrontDoor.Backendサービス タグには、Front Doorのバックエンド通信に使用されるIPアドレス範囲が含まれています。これにより、Front Doorからの正当なトラフィックだけがバックエンドに到達できるようになります。
- 利点: Front Doorからのトラフィックのみを許可することで、バックエンドを保護できます。
- 欠点: サービス タグはIPアドレス範囲の管理を簡素化しますが、バックエンドは依然としてインターネットからアクセス可能な状態にあります。
2. IPアドレスの制限とSSL証明書の検証
- 方法:
- IPアドレスの制限: Front Doorがバックエンドにアクセスする際に使用するIPアドレス範囲を特定し、バックエンドのファイアウォールでその範囲からの接続のみを許可するように設定します。
- SSL証明書の検証: Front Doorがバックエンドに接続する際、バックエンドのSSL証明書がFront Doorのドメインと一致することを強制することで、中間者攻撃を防ぎます。
- 仕組み: これらの設定を組み合わせることで、Front Doorからの通信が正当であることを確認できます。
- 利点: トラフィックの正当性をより厳密に検証できます。
- 欠点: サービス タグを使用する場合と同様、バックエンドはインターネットに公開されます。
3. Front Door と Application Gateway を組み合わせる
- 方法:
- Front Door: グローバルな負荷分散、WAF、CDNとして機能します。
- Application Gateway: Front Doorからのトラフィックを受け取り、バックエンドの仮想ネットワーク内のリソースにルーティングします。
- 仕組み: Application Gatewayをバックエンドとして設定し、そのApplication GatewayのIPアドレスをFront Doorのバックエンドとして登録します。
- 利点:
- Application GatewayとFront Doorの連携により、より高度なトラフィック管理とセキュリティ機能を利用できます。
- Front DoorからApplication Gatewayへのトラフィックは、上記のサービス タグやIPアドレス制限で保護できます。
- 欠点: アーキテクチャが複雑になり、コストが増加します。
最低限の設定
- 独自ドメイン・TLS（AFD管理証明書 or Key Vault連携）
- ルーティング（/→WP、/api→Laravel、/media→Blob）
- WAFポリシー（OWASP、Rate limit、管理画面パスの誤検知除外）
Azure DNS (独自ドメインなら)
サービスの名前を IP アドレスに変換する (解決する) 役割を担います。 Azure DNS は、Microsoft Azure インフラストラクチャを使用して、アプリケーションの DNS ホスティング、解決、負荷分散を提供します。
Mark2. コンテナ基盤
Azure Container Registry (ACR)
Azure Container Apps (ACA) + ACA Environment
マイクロサービスやイベント駆動型のアプリケーションを、Kubernetesの複雑性を意識せずに実行できるサーバレスなコンテナー実行環境です。
ACAのデプロイは、ACA Environmentという概念に基づいており、この環境がACAのイフらを管理しています。
ACAの概要はこちらのサイトを参照
ACA Environment
ACA Environmentは、コンテナーアプリを実行するためのインフラを管理する基盤であり、同じ環境内のコンテナーアプリは相互に安全に通信できます。
環境で管理されるインフラ
- ネットワーク: コンテナーアプリ間の通信や、仮想ネットワーク（VNet）との統合、Private Linkの設定などを管理します。
- ログ: 環境内のすべてのコンテナーアプリのログを集約します。
- 共有リソース: Daprなどの分散アプリケーション機能の共有リソースを管理します。
Daprとは
Dapr（Distributed Application Runtime）は、マイクロサービスや分散アプリケーションの構築を容易にするためのポータブルなイベント駆動型ランタイムです。開発者は、Daprが提供するAPIを利用することで、マイクロサービスに必要な共通機能を、プラットフォームや言語に依存することなく実装できます。
ACAのメリット
- 開発の簡素化: Kubernetesの知識がなくても、コンテナーアプリを簡単にデプロイ・管理できます。
- 高いスケーラビリティ: HTTPリクエストやイベントに基づいて、コンテナーアプリを自動的にスケールできます。
- コスト効率: 従量課金モデルにより、アイドル時のコストを削減できます。
- 柔軟なワークロード: ワークロード プロファイルを活用することで、サーバーレスから専用リソースまで、多様な要件に対応できます。
- セキュアなネットワーク: VNet統合やPrivate Linkにより、強固なネットワークセキュリティを確保できます。