はじめに
Log Analytics ワークスペースは、Azure におけるログデータの保存・分析を担うストレージのようなもので、KQL クエリを使用して収集したログを分析・可視化できます。
一方で、ストレージ アカウントなどの他の PaaS と比較すると、細かいネットワーク制御ができないという課題があります。そこで Log Analytics ワークスペースのネットワーク制御方法を最近パブリック プレビューが開始されたネットワーク セキュリティ境界を含め考えていきます。
Log Ananlytics ワークスペースのネットワークアクセス制御
一旦、ネットワーク セキュリティ境界抜きで考えていきます。現在、Log Analytics ワークスペースを含む Azure Monitor でネットワーク制御するには Azure Monitor Private Link Scope (AMPLS) を使用する必要があります。
こちらを利用すれば、制限事項や考慮すべき項目は多いですが、プライベート エンドポイントを利用して、VNET 内でプライベート構成を取ることが可能です。また、Log Analytics ワークスペースへのログ インジェストやクエリの実行を VNET 内からのみに制限することが可能になります。
ただしこちらを実施すると AMPLS に接続されている VNET の外部のマシンからクエリが実行できなくなり、ブックの表示などにも支障が出ます。また、バックエンドでクエリを実行している Sentinel の各種機能が正常に動作しないなどの課題があります。
Log Analytics ワークスペースでは、ストレージ アカウントのようなグローバル IP アドレスの制御やサービス エンドポイント+ VNET によるアクセス制御、信頼されたサービスのアクセス許可などができません。そのため、各種分析・可視化機能を維持しつつ、リソースレベルでネットワーク制御を行うことが困難でした。
参考：ストレージ アカウントのネットワーク制御設定
ネットワーク セキュリティ境界
こちらを解決する手段として期待されるのがネットワーク セキュリティ境界 (Network Security Perimeter: NSP) となり、パブリック プレビューで提供開始しています。
特徴は以下です。
- 送信アクセス、受信アクセスの制御設定を含む一つのプロファイルを複数のタイプの PaaS リソースにまとめて適用可能
- 受信アクセスはパブリック IP アドレスとサブスクリプションが指定可能
- サブスクリプションを指定した場合、その中に含まれるリソースでマネージド ID が有効化されており、かつ適切な RBAC が設定されていることがアクセス許可の条件
- 送信アクセスは FQDN を指定
- 同一プロファイル内の PaaS リソース間はマネージド ID が有効化されており、かつ適切な RBAC が設定されていれば暗黙的にアクセス許可される
- PaaS リソース個々のネットワーク制御設定とマージ (学習モード) もしくは上書き (強制モード) とすることができる
- プライベート リンク/プライベート エンドポイントからの受信アクセスはこの構成の影響を受けない
参考リンク
Log Analytics ワークスペースに適用
実際にネットワーク制御に活用可能か確認していきます。参考情報は以下です。
Azure Monitor でサポートするリソースは以下です。受信アクセス、送信アクセスの該当機能は想定で記載しています。
| 項目 | 受信アクセス | 送信アクセス |
|---|---|---|
| Log Analytics ワークスペース | ログ インジェスト、クエリ実行 | Eventhub、ストレージ アカウントへのデータ エクスポート |
| データ収集エンドポイント | ログ インジェスト | なし？ |
| ログ クエリ アラート | なし？ | Log Analytics ワークスペースへのクエリ実行 |
| アクション グループ ※ | なし？ | Eventhub へのアクション実行 |
※ リージョン アクション グループのみサポート、アクションの種類は Eventhub のみ
設定
プレビュー機能登録をします。
Microsoft.Network を再登録します。
NSP のリソースを作成します。
受信アクセスの許可を設定します。
送信アクセスの許可を設定します。
なお、受信アクセスをサブスクリプションベースの設定する場合の注意事項は以下です。
リソース作成後、診断設定を行うことでアクセスログが取得可能です。(PaaS へのアクション単位で取得できます)
関連するリソースを見てみると以下のような警告が出ています。ただ、Log Analytics ワークスペースはマネージド ID の機能を持ってないので、対処のしようがないですが。
プロファイル内のリソース個々にパブリック ネットワーク アクセスの構成が可能です。なお、こちらはNSP 固有の設定ではなく、リソース固有のネットワーク制御の設定と連動しています。
アクセスモードの変更もリソース単位で設定可能です。Learning = 学習モード (リソース固有設定とマージ)、Enforced = 強制モード (リソース固有設定を上書き) になっています。
検証
まずは以下のように何も制限がかかってない状態でログがインジェストされていることを確認します。
NSP を適用します。Log Analytics ワークスペースのアクセス制御自体は [すべてのネットワークから有効] のままとしています。NSP は学習モードのため、この時点ではアクセス制御がかからない想定です。
ログ インジェストは継続していることが確認できています。
[境界によって保護] に切り替えます。これで基本的に NSP 内および許可された通信のみが可能になります。
許可された IP アドレスからはクエリ可能です。
許可された IP アドレス以外からはブロックされます。
ただし、しばらくすると診断ログの記録が止まってしまいました。API キーを使ったアクセスと見なされているのでしょうか。ただ診断ログのインジェスト元のグローバル IP が不明で Denied のログも出ないため、許可のやりようがありません...
別の Log Analytics ワークスペースでは記録されていることを確認しています。
ドキュメント上にも信頼されたアクセスが非サポートであることが書いてありますので、診断ログを許可するのは難しいかもしれません。(強制モードの記載がありますが、[境界によって保護] かつ学習モードでも同様かと思います。)
なお、StorageBlobLogs の記録はされていました。こちらは同一プロファイル内に該当のストレージ アカウントを紐づけているからと思われます。実際にストレージ アカウントをプロファイルから削除するとログ記録が止まりました。
DCR を付与して AMA 経由での記録を確認してみます。
Denied のログが出始めました。
Denied になったものをサンプルで追加してみます。
Allowed に変わり、Heartbeat のログを確認できました。IP アドレスが NSP のログの IP アドレスと一致していることが確認できます。
ちなみに事前にロール付与を試しましたがサブスクリプションのルールでは許可されず (ログが出ないので想定)、グローバル IP レベルの許可が必要となるようです。
診断ログの記録が復旧するように [すべてのネットワークから有効] に戻します。
しかしながら、診断ログの記録が復旧しません。
クエリのアクセスも許可された IP アドレス以外からは引き続きエラーになってしまいます。このことから、正常に設定が反映されていない可能性があります。
この状態の場合、NSP の関連付けを解除することで回復することを確認しています。
ちなみに Sentinel の Log Analytics ワークスペースで試したところ、正常に動作しないことも確認しています。
以下のように分析ルールが保存できません。
ドキュメントにリソース間クエリはサポートされないと記載があるため、Sentinel 自体はサポート外かもしれないです。
結局どうする？
現時点では NSP だと様々な Log Analytics ワークスペースの要件をすべて満たすことは厳しい印象ですので、いまある機能でできることを整理します。
ログ インジェストのネットワーク制御
AMPLS 経由のみでログ インジェストを制限した場合でも診断ログは影響を受けません。
そのため、以下のようにネットワーク制御をかけることが可能です。
- AMPLS を有効化し、VNET 内にプライベート エンドポイントを設定
- Log Analytics ワークスペースでインジェスト アクセスをプライベートのみに設定
- Azure VM などはこちらのプライベート エンドポイントを利用
- オンプレミス機器は ExpressRoute 経由でログを書き込み
- 3rd Party SaaS などの外部ログは VNET 統合した Azure Functions などを活用し、VNET を経由してログを書き込み
※ Sentinel を利用する場合、診断ログに当たらないコネクタも多数あるため、取得するログによっては上記の構成は難しく、パブリックに許可する必要があります。
クエリのネットワーク制御
クエリの場合には AMPLS でプライベート化してしまうと、運用上支障が出るケースが多いので、粒度が粗いですが、以下のような設定が落としどころかと思います。
- 対象の Log Analytics ワークスペースを閲覧できるユーザーを制限
- 対象のユーザーに対して Entra ID 条件付きアクセスで [Windows Azure Service Management API] を対象アプリとしてグローバル IP の制御や端末の制御を設定
※ 上記の場合、特定の Log Analytics ワークスペースのクエリだけではなく、Azure 操作全般に制限がかかる形になります。
もしリソース間のクエリを使用しないということであれば、動作が安定することが前提にはなりますが、 NSP でクエリ側だけグローバル IP アドレス制御を入れるのは選択肢になるかと思います。
Discussion