マルチAzureAD環境の検討（ログ集約編）by Lighthouse
はじめに
AWSでは、システム全体を構成するのに複数アカウントを作成し、各アカウントに「ログ管理」「セキュリティ対策」「ユーザー管理」「サブシステムA」「サブシステムB」…と使い分けることが普通になっています。
一方Azureでは、マルチサブスクリプションやマルチAzureADと言うのは基本的に推奨されていませんでした※
そこで「AzureADのマネージドな機能を利用して、マルチAAD環境を作ってみよう」という想定で、必要な機能とその実現方式をまとめてみたいと思います。
別の記事でSSOについてまとめてみましたが、今回は第2段として「ログの集約管理」を考えてみます。
ログの集約
一般的に、Azureの世界で最低限取得し・保管や分析、通知したいログと言うと下記の通りです。
- サブスクリプション：アクティビティログ
- AzureAD：サインインログ、監査ログ
これらのログは「診断設定」機能を使ってエクスポートすることができ、ストレージアカウントに出力して保管、LogAnalyticsで分析、あるいはEventhubs経由でFunctionsなどにつないでデータ処理…といったことができます。
しかし、単純に設定しようとすると、設定しているユーザー（Azureポータルにサインイン中のユーザー）に見えるリソースしか出力先に選べません。
1AzureADマルチサブスクリプションの場合は、Azure RBACによる権限設定さえできていれば特に困らずに「ログ集約」サブスクリプションのストレージアカウントをターゲットにする…ということが可能なのですが、（下図参照）
ところがマルチAzureAD、マルチサブスクリプションとなると、簡単にはログを一か所に集約することができません。ということで実現方法を考えてみました。
想定する環境
以下のような構成を考えます。一番左に「ログ集約管理サブスクリプション」を配置し、ここで書く環境で発生するログを集約します。
利用するサービス（Azure Lighthouse）
今回の検討で利用するのは「Azure Lighthouse」です。
Lighthouseは本来「お客様が、環境の運用をサービスプロバイダに委任する」ために使われることが想定されています。
順委任
特に公式でこういう用語が使われているわけではないのですが、想定されている使い方をここでは「順委任」と呼んで説明します。
Lighthouseの参考となる公式ドキュメントは下記の通りです。
かみ砕いて、イメージ図を作成します。
「お客様環境の①特定リソース（サブスクリプションやリソースグループ）の管理を、②サービスプロバイダー側のユーザー（グループ）に、③指定した権限で委任する」という設定を行います。
サービスプロバイダ側のユーザーからすると、あたかも自分のAADテナントの配下に対象リソースがあるかのように見え、他のリソースと並べて管理することができます。従来はこういった業務を行うためには「お客様テナント側にゲスト招待してもらったユーザー」で、いちいちAzureADテナントを切り替えて操作する必要がありました。
しかしLighthouseを使う場合は、ホームテナント側にサインインした状態で、委任を受けたリソースを参照することができます。この状態で、サービスプロバイダーはリソースの構築や監視といった運用を行うことで、複数テナントの管理も容易になるわけです。
業務の委任方向と、リソースの委任方向が同じ向きなので「順委任」と呼びます。
逆委任
さて、今回の検討では、リソースの委任を逆方向で設定します。
別のAADテナントのログを集約するために、以下のように【サービスプロバイダーが】ログ保存先となるリソースの管理を委任します。
サービスプロバイダー（ログ集約管理サブスクリプション）とお客様テナント（ログ発生側サブスクリプション）と考えると、リソースの委任方向と、ログ管理業務の委任方向が逆向きになるので「逆委任」
と呼びます。（繰り返しますがオリジナル用語です）
「お客様AAD」側では「委任を受けたストレージアカウント」に対して、ログの出力設定を行います。異常により、ログ集約側（サービスプロバイダー）のリソース上にログが収集されます。
実際にやってみる
１：１のログ転送
先ほどの「逆委任」構成の通り、あるテナントで発生するログを、ログ集約サブスクリプション上のストレージアカウントに保存します。
リソースの準備
ログ集約サブスクリプション側に、事前にストレージアカウントを作成しておきます。
Lighthouseの設定
※手順詳細はこちら
まず、設定に必要となるARM Templateを作成します。
Azureの「マイ カスタマー」＞「概要」＞「ARMテンプレートを作成」から作成します。設定値を埋め込む都合上、委任を受ける側（サービスプロバイダー）で作成する方が便利です。
※自力で作ることもできますし、以前は公式ドキュメント内からテンプレートの素をＤＬしてきて作成したものですが、今はポータルから作成できます。圧倒的に楽になりました。
続けて、委任する側（お客様環境）で「サービスプロバイダー」＞「サービスプロバイダーのオファー」から、上で作成したテンプレートをデプロイします。この通り作っていればポチポチするだけです。
なお、ドキュメント上は「顧客テナントのユーザー」と明記されていますが、ゲストユーザーでも作業することが出来ました。
設定確認
Lighthouse設定のデプロイが成功すると、下記のような設定が確認できます
お客様（ログを保管するリソースを持つ側）
「サービスプロバイダー」に、委任先の設定が見えます
サービスプロバイダー（ログを保管したい側）
委任されたリソースが見えるようになります。元々存在していた2サブスクリプションに加えて、今回委任されたリソースグループが存在するサブスクリプションが見えるようになりました。
また、「マイ カスタマー」＞「顧客」メニューにも表示されるようになります。
サービスプロバイダー側テナントのログ保存設定
診断設定により、ログのエクスポートを行います。
ここまでの設定がうまくできていれば「お客様側」のサブスクリプション・ストレージアカウントがプルダウンに出てきますので、それを指定して保存するだけです。
スクリーンショットはActivitylogのものですが、AADのログ（SigninLogsなど）も同じように設定可能です。
懸念事項
診断設定が解除されてしまうとこのままでは気づけません。
管理される側（ログを保管したい側／サービスプロバイダー側）が悪意を持っていると、ログが欠損してしまう恐れがあり、今回の構成では100%の統制とはなりません。
さらに追加で考える必要がありそうですが、1企業内で設定して1か所にログを集約するなどユーザーや権限管理ができている環境においては、問題ないと言えると思います。
おわりに
今回はマルチAzureAD環境の「ログ集約編」ということで、ログを1か所に集約し分析可能にする方法を検討しました。若干懸念事項はあるものの1か所にまとめてくることは可能で、マルチAzureAD環境の実現に一歩近づけたと思います。
ただ、今回は１：１の環境の検証までしかできていませんので、次回１：多の環境でログ収集する場合の検討を行いたいと思います。
でも本音を言うと、AWSで言うところのCloudtrailの「組織の証跡」みたいな機能が欲しいなぁ…
Discussion