AzureADのログ保管(Azure Storage と Log Analytics、Sentinel)

# 前置き

クラウド時代においては非機能要件の検討と実装はだいぶ楽になりました。
ActiviDirectoryをオンプレミスで構築するならば
- 可用性(稼働率をどうするか等)
- 性能拡張性(レスポンスはどれくらいで、等)
- 運用保守性(メンテナンス時間やバックアップなどどうするか)
- セキュリティ

などなどを考慮しなければいけませんでした。
が、AzureADならば 可用性 と 性能拡張性 はほぼほぼ Microsoft が担保してくれます。
しかしながら 運用保守性 と セキュリティ は
引き続きユーザサイドで検討しなければいけないことが多い状況となります。
このうち、特にセキュリティのログ保管、管理について少し書いていきたいと思います。

# AzureAD におけるログ保管期間
Azure AD のログ保管期間は有償アカウント(P1/P2)でも30日です。
| 1 | 2 | 3 | 4 |
|:-:|:-:|:-:|:-:|
|   |Entra ID Free|Entra ID P1|Entra ID P2|
|監査ログ|7日   |30日   |30日   |
|サインイン|7日   |30日   |30日   |

https://learn.microsoft.com/ja-jp/entra/identity/monitoring-health/reference-reports-data-retention

一方、非機能要件で求められるログ保管期間は、それより長いのが基本です。
例えば IPA から出ている 非機能要求グレード2018 に記載のある
ログ保管期間は少なくとも6か月がベースとして書かれており、
PCIDSS4.0ならば
"監査ログの履歴を少なくとも 12 カ月間保持し、
少なくとも直近の 3 カ月間は分析のために直ちに利用できるようにする。"
とあります。AzureAD のデフォルト設定ではこれを満たせませんので、これを満たす方法の例を記載してみます。

# 案1 監査ログの保持ポリシー
こちらは Office E3 等ならば180日保存可能です。
E5になれば最大1年、さらに監査ログ保持のアドオンライセンスがあれば10年間保存可能です。
・・・が、各ユーザーにライセンスが必要になります。
表にまとめると以下になります。
| 1 | 2 | 3 | 4 | 5 | 6 |
|:-:|:-:|:-:|:-:|:-:|:-:|
|   |Entra ID Free|Entra ID P1/P2| E3ライセンス | E5ライセンス | アドオン | 
|監査ログ|7日   |30日   |180日   |1年   |10年   |

# 案2 Azure Storage に保管
AADのログは 診断設定 より Azure Storage のストレージアカウント、
Log Analytics ワークスペースに保存することが可能です。
ストレージアカウントの場合、永久保存が可能で、かつLog Analyticsより基本的には安価です。
(特に何も設定しなかった場合、永久保存されます。
逆に言うと保存され続けコストがかさみます...
保持期間を定める場合、ライフサイクルの設定が必要。)

この方法ですと、もちろんストレージアカウントが必要であり、
かつログは1日ごとに json 形式で保存されます。
つまり、ログの追跡はなかなか手間がかかります。

保存は以下の様にテナントごとにされています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/8230a0c5-6985-c056-161a-f6b21e04b9f0.png)

jsonの中身はこのようになっています。中見るだけでもちょっと大変です・・・
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/9593c499-f6e9-20b4-967c-90af3811e031.png)

さて、設定方法ですがまずストレージアカウント作成からです。
## ストレージアカウント作成
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/4032fac9-8d40-01ff-b334-895642541049.png)
適当なサブスクリプションとリソースグループを選択して、
ストレージアカウント、地域(リージョン、東日本なら Japan East)を設定します。
パフォーマンスはログ保管用途なら Standard でよいでしょう。
冗長性は今回はテスト用ですので LRS に設定します。ここは要件に応じ選択しましょう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/cd279161-a500-9e6c-0c88-60820fd2657d.png)

詳細設定～タグまでは今回はテストですのですべてデフォルトで設定しました。
ただ詳細設定のBLOB ストレージのアクセス層はホットでなくクールにしてもよさそうです。
このようにストレージアカウントを作成したら次はいよいよ診断設定から
AADログをストレージアカウントに転送するように設定します。
## 診断設定
Microsoft Entra ID の左ペイン監視の診断設定より、「診断設定を追加する」から設定可能です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/2ea90168-8b93-acfa-4fce-34ff88ba4e8c.png)
診断設定で名前を設定したら保存したいログ(今回は AuditLogs と SignInLogs)を選択し、
あて先の詳細ではストレージアカウントへのアーカイブにチェックを入れ
ストレージアカウントを作成したサブスクリプション、作成したストレージアカウントを設定して
保存すれば無事設定完了です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/ae6c7954-f1be-1f76-6047-3d14005d0de6.png)

以上で最初に書いたように設定後のサインインログ、監査ログがストレージアカウントに
json形式で保存されるようになります。なお、設定前のログは保存されるわけではないのでご注意ください…

# 案3 Log Analytics を利用
Log Analyticsの場合、デフォルトでは保持期間30日、この期間は無料であり以降の費用は
ストレージアカウントより幾分か高いです。
しかし、それを補って余りあるのがログ分析機能が利用可能であることで、
KQL(kustoクエリ)機能によるログ分析やダッシュボードを利用して可視化が可能です。

たとえば、日毎のサインイン回数をカウントし、これをグラフにするならば以下の様になります。
・kustoクエリでログ分析
```
let now = now();
let requireWeek = datetime_add('week', -2, todatetime(now));
let startDateTime = startofweek(requireWeek);
let endDateTime = todatetime(now);
SigninLogs 
| where TimeGenerated between(startDateTime .. endDateTime)
| summarize Hourly_Singin = count () by Location, bin(TimeGenerated, 1h) 
```
・結果
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/b6f66ad5-6d50-79ed-5289-81451e8c51b3.png)

・グラフ化しダッシュボード化(上記の図の"ピン留め先"から可能です)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/9ac63848-8e1b-c1e5-8391-c2be161afec8.png)

## Log Analytics ワークスペース作成
Log Analytics の設定方法です。
・Log Analytics ワークスペースより作成
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/9a4538ef-1022-04bf-ea43-268fdb06c3d8.png)
・サブスクリプション、リソースグループを指定、名前、リージョンを指定
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/e7893347-48c9-7f33-21d5-02eb9bdf18f6.png)
Log Analytics ワークスペースを作成するのはこれだけです。簡単ですね。

## 診断設定
次に診断設定です。ストレージアカウントの時とほぼ同様です。
今回はあて先を Log Analytics ワークスペースへの送信にします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/ee3193f2-f485-43c8-2780-10d6f53e7a31.png)
以上で Log Analytics からログ分析できるようになります。
なお、やはりこちらも設定前のログは保存されるわけではないのでご注意ください…

## Sentinelの利用
先ほどから紹介している Sentinel を利用すればもっと簡単にログ分析、可視化が可能になります。
例えば Entra ID サインイン数や Azureアクティビティの回数を可視化してみます。
・Entra ID サインイン数
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/8b641959-0f26-b0fc-0910-f1fdda3b89f5.png)
・Azureアクティビティ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/6f9068c9-512d-5eb4-643f-8c7a370b3712.png)
その他、ハンティングクエリであらかじめプリセットされたクエリで
怪しいログをハントすること等もできるようになります。(今回のスコープ外)

Sentinel の設定方法ですがSentinel より log analytics ワークスペース を追加、
もしくは改めて作ってこれに Sentinel を設定、ができます。
今回はまず上で作った log analytics ワークスペースを Sentinel に追加してみましょう
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/a8b3a293-3243-7e0f-7f71-62d7e1fdfc88.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/98fa2327-ff71-fb3f-17cf-062099729a9a.png)
その後、Sentinelのコンテンツハブより Microsoft Entra ID をインストールすれば完了です。
すでに log analytics の設定で AzureAD のログは log analytics ならびに sentinel に転送されるよう
設定されていますからデータコネクタの設定は特に不要です。
※私の環境は管理と出てしまってますが、インストールしていないならばインストールと出ます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/494ae3a6-6636-5e8a-fe58-a7034d580a01.png)
あとは、ブックにあるテンプレートより、Microsoft Entra ID Sign-in logs を表示すれば
上記に示したグラフが確認可能です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/0e9e0e53-d0e8-fc80-94db-eb5947caf4e0.png)

次に AzureActivity ですが、こちらもコンテンツハブよりインストールしましょう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/1f16a2f5-cbc9-db85-fda8-d924dd30f7de.png)
ただ、こちらは log analytics でログの転送設定をしていません。
データコネクタから設定してみます。Azureアクティビティを選択し、コネクタページを開くを押しましょう。
※こちらは既に接続済みになってますが、最初はそうはなっていません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/fe1b5342-bb04-fb58-dbb2-5cb296c2c12b.png)
データコネクタでは Azure Policy で作ることになります。
Azure Policy では環境がポリシーに従っているかチェックできるのですが、今回は
Azure Monitor の設定で Azure アクティビティ の設定を転送する設定が入っているか検証し、
入っていなければ修復ポリシーでその設定を入れるということを行います。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/f751c203-caf8-7829-dba1-122898c714fa.png)
基本で Azureアクティビティを送るサブスクリプションを選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/5c0de757-4ee2-89b6-7e3e-e45b581d0d0d.png)
詳細は特に弄る必要なし
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/2c831b50-e85f-6b82-fa4a-d2182899dc59.png)
パラメータでAzureアクティビティを送る log analytics ワークスペースを指定
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/db860de0-f7d4-96f2-9663-8391f830801a.png)
修復で「修復タスクを作成する」にチェックを入れておき、あとはシステム割り当てIDの場所も
Azureリソースを作っているリージョンに合わせておきましょう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/b9e7dc6e-beee-b236-a5eb-e23784fe3706.png)
非準拠メッセージは特に弄る必要はないです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/857684d6-f7a0-bf0e-d2fc-7f696cd484e6.png)

そして、最後に確認および作成で最終確認して作成すると、しばらくして
AzureAcitivityの転送設定が行われ、Sentinel のブックのテンプレートより
Azure Activity から先ほどのグラフが見れるようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/48113080-2573-89e5-4704-a442c8cae76f.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/1e54160e-a256-e151-277c-01d2f854d096.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2742796/be56a7ec-63ee-fc6d-f7c1-8f4925576d3e.png)

# 費用について
最後に費用について計算式を簡単にまとめます。

・監査ログの保持ポリシー
　ライセンス月額xユーザ数x月数
　ライセンスはそう安くはなく、ユーザ数要るのがなかなかコストかかりそうです…

・ストレージアカウント
　従量課金。ログ容量xストレージアカウント設定(冗長性や速度等)が月額としてかかる
　ログ容量増えるとコストがかさみますね。ちゃんとコストチェックしてライフサイクルの設定が必要です。

・Log Analytics(+Sentinel)
　データ保持料金：30日(Sentinel使ってるなら90日)以上保持したログについて
　　容量 x データ保持層(対話型 or アーカイブ)

　データインジェスト
　　Log Analytics：月5Gまで無料。移行は取り込んだログ容量(GB単位) x プラン(Analytics or Basic)
　　+Sentinel：取り込んだログ容量(GB単位)※Log Analyticsのインジェストとは別にかかる

　ログの検索
　　対話型のAnalytics logなら無料。
　　Basic logだと基本ログ検索クエリ費用が、
　　アーカイブ層に移ってしまったログについても検索ジョブ費用
　　(アーカイブから対話型に復元するにしても復元費用が掛かる)

以上を踏まえ、以下が無料範囲です。
　・Log Analytics なら 月5GBまでの取り込み、かつ保管期間30日なら無料
　・Sentinelも利用するなら、一部のログの取り込みに限れば
　　(Azure のアクティビティログなど。なおAADのサインインログではないようです...)
　　月5GBまでの取り込み、かつ保管期間90日(Sentinel使ってると延びます)なら無料です。
　　※M365E5ユーザならAADのサインインログでも以下までは無料。
  　　1日5MB(ユーザ単位)まで、月5GBまで、保管期間90日

# まとめ
上述の通り、Log Analyticsだけなら月5GBまでの取り込み、かつ保管期間30日なら無料です。
サブスクリプションこそ設定しなければなりませんが、まずは試してはどうでしょうか。
さらに+Sentinelをしてもログがそう多くないなら大した費用はかかりません。
Azure のアクティビティログだけ等にするなら保存期間90日に伸びたうえでの無料になるので
こちらもぜひためしてみてはどうでしょうか。