Azure Monitor ログのデータ セキュリティ
この記事では、Azure Monitor がログ データを収集、処理、セキュリティで保護する方法を説明し、Azure Monitor 環境をさらにセキュリティで保護するために使用できるセキュリティ機能について説明します。 この記事の情報は、Azure Monitor ログ固有の情報であり、Azure トラスト センターに関する情報を補完します。
Azure Monitor ログは、次の方法を使用して、クラウドベースのデータを安全に管理しています。
- データの分離
- データの保持
- 物理的なセキュリティ
- インシデント管理
- コンプライアンス
- セキュリティ基準認定
セキュリティ ポリシーを含め、次の情報に関するご質問やご提案、問題がある場合は、Azure のサポート オプションに関するページを参照してください。
TLS を使用して安全にデータを送信する
Azure Monitor に転送中のデータのセキュリティを確保するには、エージェントを、少なくともトランスポート層セキュリティ (TLS) 1.2 を使用するように構成することを強くお勧めします。 以前のバージョンの TLS/SSL (Secure Sockets Layer) は脆弱であることが確認されています。現在、これらは下位互換性を維持するために使用可能ですが、推奨されていません。さらに、業界はこれらの以前のプロトコルのサポートを中止する方向へ急速に動いています。
PCI Security Standards Council は、2018 年 6 月 30 日を期限として、TLS/SSL の以前のバージョンを無効にし、より安全なプロトコルにアップグレードすることを求めています。 Azure がレガシー サポートを廃止した場合、エージェントが TLS 1.3 以上で通信できないと、Azure Monitor ログにデータを送信できなくなります。
お使いのエージェントで TLS 1.3 のみを使用するように明示的に設定することは、絶対必要ない限りお勧めしません。 エージェントによる今後のセキュリティ標準の自動検出、ネゴシエートを許可し、利用できるようにしておくことをお勧めします。 そうしないと、新しい標準によるセキュリティ強化が使用できなくなり、TLS 1.3 が廃止され、新しい標準が採用されたときに、問題が発生する可能性があります。
プラットフォーム固有のガイダンス
| プラットフォーム/言語 | サポート | 詳細情報 |
|---|---|---|
| Linux | Linux ディストリビューションでは、TLS 1.2 のサポートに関して OpenSSL に依存する傾向があります。 | OpenSSL の Changelog を参照して、使用している OpenSSL のバージョンがサポートされていることを確認してください。 |
| Windows 8.0 - 10 | サポートされています。既定で有効になっています。 | 既定の設定を使用していることを確認します。 |
| Windows Server 2012 - 2016 | サポートされています。既定で有効になっています。 | 既定の設定を使用していることを確認します |
| Windows 7 SP1 および Windows Server 2008 R2 SP1 | サポートされていますが、既定では有効になっていません。 | 有効にする方法の詳細については、「トランスポート層セキュリティ (TLS) のレジストリ設定」を参照してください。 |
データの分離
Azure Monitor によってデータが取り込まれた後、データはサービス全体のコンポーネントごとに論理的に分離されます。 すべてのデータはワークスペースごとにタグ付けされます。 このタグ付けはデータのライフ サイクルにおいて継続され、サービスの各層で強制されます。 データは、選択したリージョンのストレージ クラスター内の専用データベースに格納されます。
データの保持
インデックス設定済みのログの検索データは、価格プランに従って保持されます。 詳細については、「 ログ分析の価格」を参照してください。
サブスクリプション契約 の一環として、Microsoft は契約の条項に従ってデータを保持します。 顧客データが削除されるときに、物理ドライブは破棄されません。
次の表では、利用できるソリューションの一部と、収集するデータの種類の例を示しています。
| ソリューション | データ型 |
|---|---|
| 容量とパフォーマンス | パフォーマンス データとメタデータ |
| 更新管理 | メタデータと状態のデータ |
| ログの管理 | ユーザー定義のイベント ログ、Windows イベント ログ、IIS ログ |
| 変更の追跡 | ソフトウェア インベントリ、Windows サービスと Linux デーモン メタデータ、Windows/Linux ファイルのメタデータ |
| SQL と Active Directory の評価 | WMI データ、レジストリ データ、パフォーマンス データ、SQL Server の動的管理の表示結果 |
次のテーブルでは、データの種類の例を示しています。
| データの種類 | Fields |
|---|---|
| アラート: | アラート名、アラートの説明、BaseManagedEntityId、問題 ID、IsMonitorAlert、RuleId、ResolutionState、優先度、重大度、カテゴリ、所有者、ResolvedBy、TimeRaised、TimeAdded、LastModified、LastModifiedBy、LastModifiedExceptRepeatCount、TimeResolved、TimeResolutionStateLastModified、TimeResolutionStateLastModifiedInDB、RepeatCount |
| 構成 | CustomerID、AgentID、EntityID、ManagedTypeID、ManagedTypePropertyID、CurrentValue、ChangeDate |
| Event | EventId、EventOriginalID、BaseManagedEntityInternalId、RuleId、PublisherId、PublisherName、FullNumber、番号、カテゴリ、ChannelLevel、LoggingComputer、EventData、EventParameters、TimeGenerated、TimeAdded 注: カスタム フィールドを使ってイベントを Windows のイベント ログに書き込むと、それらのイベントは Log Analytics によって収集されます。 |
| Metadata | BaseManagedEntityId、ObjectStatus、OrganizationalUnit、ActiveDirectoryObjectSid、PhysicalProcessors、 NetworkName、IPAddress、ForestDNSName、NetbiosComputerName、VirtualMachineName、LastInventoryDate、HostServerNameIsVirtualMachine、IP Address、NetbiosDomainName、LogicalProcessors、DNSName、DisplayName、DomainDnsName、ActiveDirectorySite、PrincipalName、OffsetInMinuteFromGreenwichTime |
| パフォーマンス | ObjectName、CounterName、PerfmonInstanceName、PerformanceDataId、PerformanceSourceInternalID、SampleValue、TimeSampled、TimeAdded |
| State | StateChangeEventId、StateId、NewHealthState、OldHealthState、コンテキスト、TimeGenerated、TimeAdded、StateId2、BaseManagedEntityId、MonitorId、HealthState、LastModified、LastGreenAlertGenerated、DatabaseTimeModified |
物理的なセキュリティ
Azure Monitor は Microsoft の担当者によって管理され、すべてのアクティビティ ログが記録されています。このログを監査することができます。 Azure Monitor は、Azure サービスとして動作し、すべての Azure コンプライアンスとセキュリティの要件を満たしています。 Azure の資産の物理的なセキュリティに関する詳細は、「 Microsoft Azure セキュリティの概要」の 18 ページを参照してください。 転送や終了を含む Azure Monitor サービスへの責任がなくなったユーザーに対する、領域をセキュリティで保護する物理的なアクセス権は、1 営業日以内に変更されます。 使用されるグローバルな物理インフラストラクチャについては、Microsoft データ センターを参照してください。
インシデント管理
Azure Monitor には、すべての Microsoft サービスが準拠するインシデント管理プロセスがあります。 まとめると次のようになります。
- セキュリティ責任の一部が Microsoft に属し、一部が顧客に属する責任の分担モデルの使用
- Azure のセキュリティ インシデントの管理:
- インシデントの検出によって開始される調査
- 待機中のインシデント対応チームメンバーによる、インシデントの影響と重要度の評価。 証拠に基づいて、評価がセキュリティ対応チームにさらにエスカレーションされるかどうかが決まります。
- 技術的な、または法医学的な調査の実施、コンテインメント、緩和策、および回避策の戦略の特定を行うための、セキュリティ対応エキスパートによるインシデントの診断。 顧客データが不正なまたは権限のない個人に公開されている可能性があるとセキュリティ チームが考える場合は、顧客インシデント通知プロセスの実行が並行して開始します。
- 安定化とインシデントからの復旧。 インシデント対応チームは、問題を緩和するために、復旧計画を作成します。 影響を受けたシステムの隔離などの危機管理手順は、診断と並行して直ちに実行してもかまいません。 より長期的な軽減策を計画するのがよいでしょう。これは、差し迫ったリスクが収まった後で実行します。
- インシデントの終了と事後分析の実施。 インシデント対応チームは、イベントの再発防止を目的として、ポリシー、手順、プロセスを変更するため、問題の詳細を示す事後分析を作成します。
- 顧客へのセキュリティ インシデントの通知:
- 影響を受ける顧客の範囲の特定、および該当の顧客への可能な限り詳細な通知の提供
- 顧客に詳細な情報を提供し、顧客側で調査を実行してエンドユーザー側で作成されたコミットメントを満たして、通知プロセスを過度に遅延させないようにするための通知の作成
- 必要に応じたインシデントの確認と宣言
- 不適切な待機時間のない、法的コミットメントまたは契約コミットメントに従ったインシデント通知による顧客への通知。 セキュリティ インシデントは、Microsoft が選択した (電子メールを含む) 方法によって、1 人以上の顧客側の管理者に配信されます。
- チームの準備とトレーニングの実施:
- Microsoft の担当者は、疑いのあるセキュリティ上の問題の特定と報告に役立つ、セキュリティと認識のトレーニングを完了する必要があります。
- Microsoft Azure サービスで作業しているオペレーターは、顧客データをホストする機密性の高いシステムへのアクセスに関連する、追加のトレーニングを受ける義務があります。
- Microsoft セキュリティ対応担当者は、役割に対する専門的なトレーニングを受けます。
非常にまれですが、顧客データが大量に失われた場合、Microsoft は 1 日以内にそれぞれのお客様に通知します。
Microsoft のセキュリティ インシデントへの対応の詳細については、「Microsoft Azure Security Response in the Cloud (クラウドでの Microsoft Azure のセキュリティ対応)」を参照してください。
コンプライアンス
Azure Monitor ソフトウェア開発およびサービス チームの情報セキュリティとガバナンスのプログラムは、Microsoft Azure トラスト センターと Microsoft トラスト センター コンプライアンスで説明されているように、ビジネス要件をサポートし、法律と規定を順守しています。 また、Azure Monitor によるセキュリティ要件の確立方法、セキュリティ制御の識別方法、リスクの管理と監視方法についても説明されています。 Microsoft では、ポリシー、標準、手順、およびガイドラインのレビューを毎年行っています。
開発チームの各メンバーは、正規のアプリケーション セキュリティのトレーニングを受けています。 内部的には、ソフトウェア開発用に、バージョン管理システムを使用しています。 各ソフトウェア プロジェクトは、バージョン管理システムによって保護されています。
Microsoft には、Microsoft のすべてのサービスを監視して評価する、セキュリティとコンプライアンスのチームがあります。 情報セキュリティ責任者がチームを構成します。彼らは、Log Analytics を開発するエンジニアリング チームとは関係ありません。 セキュリティ責任者には独自の管理チェーンがあり、製品とサービスについて独立した評価を行い、セキュリティとコンプライアンスを確保します。
Microsoft の取締役会には、Microsoft におけるすべての情報セキュリティ プログラムに関する年次報告書が提出されます。
Log Analytics ソフトウェアの開発とサービスのチームは、Microsoft の法律および法令遵守チーム、その他の業界パートナーと積極的に連携し、さまざまな認定資格を取得しています。
認定と認証
Azure Log Analytics は、次の要件を満たしています。
- ISO/IEC 27001
- ISO/IEC 27018:2014
- ISO 22301
- PCI Security Standards Council による Payment Card Industry (PCI 準拠) データ セキュリティ基準 (PCI DSS)。
- Service Organization Controls (SOC) 1 Type 1 および SOC 2 Type 1 に準拠している
- HIPAA および HITECH (HIPAA Business Associate Agreement を締結している企業向け)
- Windows の一般的なエンジニアリング条件
- Microsoft の信頼できるコンピューティング
- Azure Monitor で使用されるコンポーネントは、Azure のサービスとして、Azure の準拠要件に従います。 詳細については、Microsoft トラスト センターのコンプライアンスを参照してください。
注意
Azure Monitor は、一部の認定および認証において、以前の名前である Operational Insights として表示されています。
クラウド コンピューティングのセキュリティ データ フロー
次の図は、企業の情報フローを例にしたクラウドのセキュリティ アーキテクチャです。情報が Azure Monitor に移動する間にどのように保護され、最終的に Azure portal 内に表示されるかを示しています。 各手順の詳細は図の後で説明します。
1. Azure Monitor にサインアップし、データを収集する
組織が Azure Monitor ログにデータを送信できるようにするには、Azure 仮想マシン、または自身の環境や他のクラウド プロバイダーの仮想または物理コンピューターで実行される Windows または Linux エージェントを構成します。 Operations Manager を使用する場合は、管理グループから Operations Manager エージェントを構成します。 ユーザー (あなた、他のユーザー、または複数ユーザーのグループの場合があります) は、次のアカウントのいずれかを使用して 1 つ以上の Log Analytics ワークスペースを作成し、エージェントを登録します。
Log Analytics ワークスペースは、データが収集、集計、分析、表示される場所になります。 ワークスペースは、主にデータをパーティション分割するための手段として使用されます。各ワークスペースは一意になります。 たとえば、実稼働データをワークスペースの 1 つで管理し、テスト データを別のワークスペースで管理する場合があります。 ワークスペースは、ユーザーのデータへのアクセスを管理者が制御する際にも役立ちます。 ワークスペースごとに複数のユーザー アカウントを関連付けることができます。また、各ユーザー アカウントは複数の Log Analytics ワークスペースにアクセスできます。 データ センターのリージョンに基づいてワークスペースを作成します。
Operations Manager の場合、Operations Manager 管理グループは、Azure Monitor サービスとの接続を確立します。 管理グループ内のエージェントで管理されるどのシステムがデータの収集とサービスへのデータ送信を許可されるかを構成します。 ソリューションからのデータは、有効にしているソリューションに応じて、Operations Manager 管理サーバーから Azure Monitor サービスに直接送信される場合と、エージェント管理システムで収集されるデータ量の関係で、エージェントからサービスに直接送信される場合があります。 Operations Manager によって監視されていないシステムでは、それぞれ安全に Azure Monitor サービスに直接接続します。
接続されたシステムと Azure Monitor サービスの間の通信はすべて暗号化されます。 暗号化には TLS (HTTPS) プロトコルが使用されます。 Log Analytics が最も最近の暗号化プロトコルを使用して最新の状態であるようにするため、続けて Microsoft SDL の手順が行われます。
エージェントの種類ごとに、Azure Monitor のログ データが収集されます。 収集されるデータの種類は、お使いのワークスペースの構成と、Azure Monitor のその他の機能によって異なります。
2.エージェントからデータを送信する
登録キーを使用してすべての種類のエージェントを登録すると、証明書ベースの認証とポート 443 による TLS が使用され、エージェントと Azure Monitor サービスの間にセキュリティで保護された接続が確立します。 Azure Monitor では、キーの生成と管理にシークレット ストアが使用されます。 秘密キーは 90 日ごとに交換されて Azure に格納され、厳密な規制およびコンプライアンス手順に従う Azure オペレーターによって管理されます。
Operations Manager では、Log Analytics ワークスペースに登録されている管理グループは、Operations Manager 管理サーバーとのセキュアな HTTPS 接続を確立します。
Azure Virtual Machines 上で実行される Windows または Linux エージェントの場合、Azure テーブルの診断イベントを読み取るために、読み取り専用のストレージ キーが使用されます。
Azure Monitor に統合されている Operations Manager 管理グループに報告するエージェントでは、管理サーバーがなんらかの理由でサービスと通信できない場合、収集されたデータは管理サーバー上の一時的なキャッシュにローカルに格納されます。 2 時間にわたって 8 分ごとにデータを再送信しようとします。 管理サーバーをバイパスし、Azure Monitor に直接送信されるデータの場合、その動作は Windows エージェントと一貫性があります。
Windows または管理サーバー エージェントのキャッシュされたデータは、オペレーティング システムの資格情報ストアによって保護されています。 2 時間が経過してもサービスがデータを処理できない場合、エージェントはデータをキューに格納します。 キューがいっぱいになると、エージェントはパフォーマンス データから順にデータ型を削除し始めます。 エージェントのキューの上限はレジストリ キーであるため、必要に応じて変更できます。 収集されたデータは圧縮され、負荷を追加しないように Operations Manager 管理グループ データベースをバイパスして、サービスに送信されます。 収集したデータが送信されると、データはキャッシュから削除されます。
前述のように、管理サーバーまたは直接接続エージェントからのデータが TLS 経由で Microsoft Azure データセンターに送信されます。 必要に応じて、ExpressRoute を使用してデータのセキュリティを強化できます。 ExpressRoute は、ネットワーク サービス プロバイダーによって提供されるマルチ プロトコル ラベル スイッチング (MPLS) VPN などの、既存の WAN ネットワークから Azure に直接接続する方法です。 詳細については、ExpressRoute に関するページと、「エージェントのトラフィックでは、Azure ExpressRoute の接続が使用されますか?」を参照してください。
3. Azure Monitor サービスでデータを受信して処理する
Azure Monitor サービスでは、Azure 認証で証明書とデータの整合性を検証することにより、入力されるデータが信頼できる発行元からのものであることを確認します。 未処理の生データは、リージョンの Azure Event Hubs に格納され、データは最終的に保存されます。 保存されているデータの種類は、インポートしてデータを収集するために使用したソリューションの種類によって異なります。 次に、Azure Monitor サービスは、生データを処理して、データベースに取り込みます。
データベースに格納されている収集済みデータのリテンション期間は、選択された料金プランによって異なります。 無料プランの場合、収集されたデータは 7 日間使用できます。 "有料" プランの場合、収集したデータは既定で 31 日間利用でき、730 日まで延長できます。 データは機密性を保証するために、暗号化されて Azure ストレージに保存されます。データはローカル冗長ストレージ (LRS) や、サポートされているリージョンのゾーン冗長ストレージ (ZRS) を使用して、ローカルのリージョン内にレプリケートされます。 過去 2 週間以内のデータは SSD ベースのキャッシュにも格納されます。このキャッシュは暗号化されます。
データベース ストレージのデータは、取り込んだ後に変更することはできませんが、purge API パスで削除することはできます。 データを変更することはできませんが、一部の認証では、データを不変の状態に保ち、ストレージ内で変更や削除ができないようにする必要があります。 データの不変性は、不変ストレージとして構成されているストレージ アカウントへのデータ エクスポートを使用して実現することができます。
4. Azure Monitor を使用してデータにアクセスする
Log Analytics ワークスペースにアクセスするには、設定済みの組織アカウントまたは Microsoft アカウントを使用して Azure portal にサインインします。 ポータルと Azure Monitor サービスの間のトラフィックはすべて、セキュリティで保護された HTTPS チャネル経由で送信されます。 ポータルを使用する場合、セッション ID がユーザーのクライアント (Web ブラウザー) で生成され、データはセッションが終了するまでローカル キャッシュに保存されます。 セッションが終了すると、キャッシュが削除されます。 個人を特定できる情報が含まれないクライアント側の Cookie は、自動的に削除されません。 セッションの Cookie は HTTPOnly としてマークされ、セキュリティで保護されます。 あらかじめ決められたアイドル期間の後は、Azure portal セッションが終了します。
カスタマー マネージド セキュリティ キー
Azure Monitor のデータは、Microsoft マネージド キーを使用して暗号化されます。 カスタマー マネージド暗号化キーを使用して、ワークスペース内のデータと保存済みクエリを保護できます。 Azure Monitor のカスタマー マネージド キーを使用すると、ログへのアクセス制御をより柔軟に管理できます。
構成が完了すると、リンクされたワークスペースに取り込まれた新しいデータは、Azure Key Vault または Azure Key Vault マネージド "HSM" に格納されているキーで暗号化されます。
非公開ストレージ
Azure Monitor ログは、特定のシナリオで Azure Storage に依存しています。 プライベート/カスタマー マネージド ストレージを使用して、個人の暗号化されたストレージ アカウントを管理します。
Private Link ネットワーク
Azure Private Link ネットワークを使用すると、Azure Monitor を含む Azure のサービスとしてのプラットフォーム (PaaS) サービスを、プライベート エンドポイントを使用して仮想ネットワークに安全にリンクできます。
Microsoft Azure 用カスタマー ロックボックス
Microsoft Azure 用カスタマー ロックボックスには、顧客データへのアクセス要求を確認し、承認または拒否するインターフェイスが用意されています。 これは、お客様から開始されたサポート チケットまたは Microsoft によって特定された問題に対応しているかどうかにかかわらず、Microsoft のエンジニアが顧客データにアクセスする必要がある場合に使用されます。 カスタマー ロックボックスを有効にするには、 専用クラスターが必要です。
改ざん防止と不変性
Azure Monitor は追加専用のデータ プラットフォームですが、コンプライアンスのためにデータを削除する規定が含まれています。 Log Analytics ワークスペースにロックを設定して、データを削除できるすべてのアクティビティ (消去、テーブルの削除、テーブル レベルまたはワークスペース レベルのデータ保持の変更) をブロックすることができます。 ただし、このロックは削除することもできます。
監視ソリューションの改ざんを完全に防止するには、変更不可のストレージ ソリューションにデータをエクスポートすることをお勧めします。
よく寄せられる質問
このセクションでは、一般的な質問への回答を示します。
エージェントのトラフィックでは、Azure ExpressRoute の接続が使用されますか?
Azure Monitor へのトラフィックでは、Microsoft ピアリングの ExpressRoute 回線が使用されます。 さまざまな種類の ExpressRoute トラフィックについては、ExpressRoute のドキュメントをご覧ください。