Azure Monitor ログの刷新による DevOps への対応、きめ細かいアクセス制御、Azure 統合の強化
執筆者: Meir Mendelovich (Principal Program Manager, Azure Monitor)
このポストは、2019 年 5 月 22 日に投稿された Transforming Azure Monitor Logs for DevOps, granular access control, and improved Azure integration の翻訳です。
現代のデジタル世界において、ログはさまざまなシナリオで不可欠であり、監視、トラブルシューティング、使用状況とサービス レベルの分析、監査、セキュリティなどのメトリックと併用されています。そのため、アプリケーションの開発計画や IT 環境の構築計画にはログの設計も欠かせません。
ログのアーキテクチャ
ログには、主に 2 つの方式があります。
- 集約型: すべてのログを単一のリポジトリに一元的に保管します。このシナリオでは、複数のリソースにまたがる検索を簡単に実行してログを相互に関連付けることができますが、これらのリポジトリは肥大化しやすく、あらゆる種類のソースからのログが含まれるため、リポジトリへのアクセス制御を維持することが困難です。このような理由から、集約型のログを一切使用しない組織もあります。集約型のログを使用している組織では、ごく少数の管理者にしかアクセスできないよう制限すると、大半のユーザーがログを活用できなくなります。
- サイロ型: ログをリソース内に保管するか、一元的に保管してリソースごとに分離します。このシナリオでは、リポジトリのセキュリティが確保され、アクセス制御とリソースへのアクセスに一貫性を持たせられますが、ログを相互に関連付けることは困難または不可能です。多数のリソースについて幅広く把握する必要があっても、インサイトを生成することができません。最新のアプリケーションは問題やインサイトの範囲が複数のリソースにわたるため、サイロ型の価値は非常に限定されます。
多くの組織では、セキュリティとログの関連付けという相反するニーズに対応するために、両方の方式を並行して実装してきました。その結果、環境が複雑になりコストがかさみ、保守も困難になり、ログの範囲にすきまが生じています。さらには、組織でのログ データの使用率が低下し、データに基づく意思決定ができなくなっています。
Azure Monitor ログの新しいアクセス制御オプション
先日、両方の方式のメリットを得られるようにする Azure Monitor ログの新機能を発表 (英語) しました。これにより、お客様はログを一元的に保管しながら、Azure とロールベースのアクセス制御 (RBAC) メカニズムにシームレスにログを統合できます。これを「リソース中心ログ」と名付けました。この機能を既存の Azure Monitor ログのエクスペリエンスに無条件に追加し、既存のエクスペリエンスと API も維持する予定です。新しいログ モデルは段階的に提供しますが、今からでもこの新しいエクスペリエンスの利用を開始できます。今後数か月のうちに、Azure Monitor のすべてのコンポーネントの整合性を強化する予定です。
リソース中心ログの基本的な考え方は、Azure リソースから出力されたすべてのログ レコードをそのリソースに自動的に関連付けることです。ログは一元管理されたワークスペース コンテナーに送信され、このコンテナーにはリソースに基づく範囲の設定と RBAC が適用されます。ユーザーがデータにアクセスするオプションは 2 つあります。
- ワークスペース中心: 特定のワークスペース (Azure Monitor ログ コンテナー) 内のすべてのデータを照会できます。ワークスペースへの権限が適用され、リソースへのアクセス権を問わずログにアクセスする必要のある管理チームに適しています。また、リソース中心ログをサポートしていないコンポーネントや Azure 以外のリソースにこのモードを使用できますが、これらのコンポーネントについては近日中に新しいオプションが利用できるようになります。
- リソース中心: リソースに関連するすべてのログを照会できます。リソースへの権限が適用されます。ワークスペースを指定しなくても、そのリソースのデータを格納しているすべてのワークスペースのログが対象となります。ワークスペースのアクセス制御によって許可されている場合は、ユーザーにワークスペースへのアクセス権を付与する必要はありません。このモードは、特定のリソース、特定のリソース グループ内のすべてのリソース、特定のサブスクリプション内のすべてのリソースに使用できます。ほとんどのアプリケーション チームと DevOps は、このモードでログを利用することになるはずです。
ユーザーの選択に応じて、Azure Monitor が自動的に適切なモードを決定します。ユーザーがワークスペースを選択した場合、クエリはワークスペース中心モードで送信されます。ユーザーがリソース、リソース グループ、サブスクリプションを選択した場合は、リソース中心モードが適用されます。選択範囲は常に Log Analytics 画面の左上のセクションに表示されます。
リソース グループ画面から、特定のリソース グループ内のすべてのリソースのログを照会することも可能です。
近日中には、サブスクリプション全体を照会範囲に設定することもできるようになります。
ログは、広く簡単に活用できるよう、多数の Azure リソース エクスペリエンスに統合されています。リソース メニューからログ検索を開くと、検索の範囲が自動的にそのリソースに設定され、リソース中心モードが適用されます。ユーザーがリソースにアクセスできる場合は、そのリソース内のログにアクセスできます。ワークスペースの所有者は、ワークスペースのアクセス制御モードを設定して、そのアクセスをブロックまた許可することができます。
もう 1 つの新機能は、ログを格納しているテーブルごとにアクセス許可を設定する機能です。既定では、ユーザーにワークスペースまたはリソースへのアクセスが許可されている場合、すべての種類のログを閲覧できます。新しいテーブル レベルの RBAC により、管理者は Azure のカスタム ロールを使用して、ユーザーに対する制限付きアクセスを定義し、一部のテーブルのみにアクセスを制限できます。また、管理者が特定のテーブルへのアクセスをブロックすることもできます。この機能は、たとえば、ネットワーク チームがワークスペースまたはサブスクリプション内のネットワーク関連テーブルのみにアクセスできるようにしたい場合などに適しています。
これらの変更により、組織はモデルを単純化して、ワークスペースの数を減らすと共に、アクセス制御をさらに強化できます。ワークスペースは管理可能なコンテナーの役割を担うようになり、管理者は自社環境を簡単に管理できるようになります。また、ユーザーは Azure の操作中に自然な形でログを表示して、日常業務に活用できるようになります。
Azure Monitor ログのアクセス制御の強化により、使いやすさとセキュリティを犠牲にすることなく、両方のメリットを同時に活かすことができます。一元管理を担当するチームはすべてのログへのフル アクセスが可能な一方で、DevOps チームはチームのリソースのログのみにアクセスできます。これは、数多くのお客様が利用している強力なログ分析、統合、スケーラビリティ機能によって実現されています。
次のステップ
Azure Monitor ログの利用を開始する手順は以下のとおりです。
- すべてのデータを格納するために使用するワークスペースを決定します。請求、規制、データ所有権を考慮してください。
- ワークスペースのアクセス制御モードを [リソースまたはワークスペースのアクセス許可を使用] に変更して、リソース中心のアクセスを有効にします。2019 年 3 月以降に作成されたワークスペースは、既定でこのモードに構成されています。
- アプリケーション チームと DevOps チームのワークスペースへのアクセス許可を削除します。
- ユーザーにログの利用方法を学んでいただきます。