このエントリは2021/04/18現在の情報に基づいています。将来の機能追加・変更に伴い、記載内容との乖離が発生する可能性があります。

先日、パターンに当てはめるというよりは、自由な発想を促すことを目的として、「様々なユースケースでどんな解決策が考えられるか？」というアイデア出しの機会があった。縛りは以下。

• Azureのサービスを可能な限り使う
• コストは法外でなければOK

で、出てきたお題の一つがこちら。

現在、証跡データを保持するためにAzure Blob StorageのImmutable storage機能を使っている。ただ、データ量（blobの個数）が膨大になっており、証跡確認、検索がなかなか大変である。コストをあまりかけずに証跡確認のパフォーマンスを向上する方法はないか？

現在は定期バッチでblobデータを読み取り、インメモリに蓄えて検索サービスを提供するアプリケーションを作成し、利用できるようにしている。パフォーマンス的には問題ないが、今後大量のblobを処理していくとOut-of-memoryエラーが発生する可能性が高く、できるかぎり検索性能を落とさずに大量データに対応できるようにしたい。また、定期バッチでblobを読み取っているため、直近のデータが検索対象に入らないことがあり、できれば直近のデータも検索対象に入れたい…。

Immutable Storageとは以下のエントリで記載したもの。

Azure Blob StorageをImmutableにする
https://logico-jp.io/2020/01/28/blob-immutable-storage/

blobの内容

以下のようなデータが1ファイルに1件以上入っている。見る限り、データ操作の証跡ログのよう。xxxxxというユーザーがログインしてからログアウトまでの操作情報を記録している。

{
  "user":"xxxxx",
  "enteredAt": "2021-01-14T18:25:43.511Z",
  "operations" : [
    {
      "type": "ログイン",
      "result": "成功",
      "detail": "なし",
      "date": "2021-01-14T18:25:43.511Z"
    },
    {
      "type": "データ書き換え",
      "result": "失敗",
      "detail": "○○のデータがロックされています",
      "date": "2021-01-14T18:43:21.087Z"
    },
    {
      "type": "データ読み取り",
      "result": "成功",
      "detail": "○○のデータ",
      "date": "2021-01-14T18:44:06.182Z"
    },
    {
      "type": "データ書き換え",
      "result": "成功",
      "detail": "○○のデータ",
      "date": "2021-01-14T18:45:01.432Z"
    },
    {
      "type": "ログアウト",
      "result": "成功",
      "detail": "なし",
      "date": "2021-01-14T18:49:43.511Z"
    }
  ],
  "leftAt": "2021-01-14T18:49:43.511Z"
}

要件

まとめると以下のような感じ。

1. blobの個数が増大しても証跡チェックや検索のパフォーマンスが損なわれないようにしたい
2. 前回の監査以後、できる限り直近までに蓄えたblobを検索対象にしたい
3. 監査までの期間に改ざんされないようにしたい
4. 前回以前の監査対象のデータはアーカイブし、最終的には削除したい

考えられる対応策

Blob Storageの機能を使う想定の場合、1については、blob内のデータを簡単に検索できるようにするために、データを何らかの検索可能なデータストアに格納したり、検索サービスを使うことで解決できそうである。2〜4はImmutable Storage機能、論理削除、アクセス層の変更などを組み合わせて対応することになりそう。

もし作り直しが可能なのであれば、「そもそもBlob Storageに格納する仕組みでよいのか？」という疑問から、証跡データの機密性を吟味した上で、Log Workspaceに出力するのがよさそう。

go live後で、どうしてもblobに入れる仕組みを変更できない（認められない）のであれば、Blob StorageをEvent Gridとつなぎ、さらにAzure Data Explorerと連携することで、blob着信のタイミングでData Explorerに取り込むことができる。具体的には以下のドキュメントを参照。

Event Grid データ接続 / Event Grid data connection
https://docs.microsoft.com/azure/data-explorer/ingest-data-event-grid-overview

このアイデア出しの時は、以下のような結論に至った。

• 既存実装への変更を少なくするのであれば、Blob StorageとAzure Data Explorerの間にEvent Gridを挟んで着信blobを流し込む。検索はData Explorerから実施する。
• もちろん、作り替えるならLog Analyticsが一番スマート。とはいえ、Retention Periodを超えるデータ保持が必要な場合はBlob Storageを使わざるを得ない。

で、このアイデア出しの会の後、実際にどういう感じになりそうか、ちょっと調べてみた。以下は、Cognitive SearchをBlob Storageと組み合わせて使う場合に利用しそうな機能をまとめた備忘録。

Azure Data Explorerの概要は以下。

Azure Data Explorer とは / What is Azure Data Explorer?
https://docs.microsoft.com/azure/data-explorer/data-explorer-overview

Blob Storageを対象にCognitive Searchを構成する

これは以下のドキュメントの通り構成すればOK。

Azure Blob Storage のコンテンツを検索する / Search over Azure Blob storage content
https://docs.microsoft.com/azure/search/search-blob-storage-integration
Azure Cognitive Search で BLOB インデクサーを使用して JSON BLOB のインデックスを作成する方法 / How to index JSON blobs using a Blob indexer in Azure Cognitive Search
https://docs.microsoft.com/azure/search/search-howto-index-json-blobs

このとき、データソースの形式をJSONと設定すれば、全文検索だけでなく、JSONの要素で検索したり、必要な要素だけピックアップすることもできる。インデックス作成の最小インターバルは5分なので、Functionsと組み合わせた仕組みに比べると直近のデータへの対応は少々遅いが、現行の定期バッチに比べると十分に追随できるレベル。

削除されたBlobが検索に現れないようにする

blobを論理削除した場合にはインデックスから自動削除させることも可能（Preview）。これにより、論理削除されたblobのデータは検索結果に現れなくなる。blobのメタデータを使ってCognitive Searchに対してインデックスを作成しないように指示することもできる。

Azure Cognitive Search のインデックス作成で BLOB の変更と削除の検出を設定する方法 / How to set up change and deletion detection for blobs in Azure Cognitive Search indexing
https://docs.microsoft.com/azure/search/search-howto-index-changed-deleted-blobs

証跡データの保護

証跡データを格納するBlob Storageは追加のみを許容するようにしておく。監査時期が決まっていない場合には、保持期間を固定するよりは訴訟ホールドで保護するほうが都合がよい。Blob Storageは論理削除を有効にしておけば、仮に訴訟ホールドを解除した際に誤ってblobを削除したとしても、論理削除なのでblobを救出できる。また、Blobコンテナーも論理削除を有効にできる（Preview）。

不変ストレージを使用してビジネスに不可欠な BLOB データを保存する / Store business-critical blob data with immutable storage
https://docs.microsoft.com/azure/storage/blobs/storage-blob-immutable-storage
BLOB ストレージの不変ポリシーを設定および管理する / Set and manage immutability policies for Blob storage
https://docs.microsoft.com/azure/storage/blobs/storage-blob-immutability-policies-manage
BLOB の論理的な削除の有効化と管理 / Enable and manage soft delete for blobs
https://docs.microsoft.com/azure/storage/blobs/soft-delete-blob-enable
コンテナーの論理的な削除を有効にして管理する (プレビュー) / Enable and manage soft delete for containers (preview)
https://docs.microsoft.com/azure/storage/blobs/soft-delete-container-enable

アクセスの監視

Blob Storageへのアクセスは、Azure Defender for Storageで監視できる。

Azure Defender for Storage を構成する / Configure Azure Defender for Storage
https://docs.microsoft.com/azure/storage/common/azure-defender-storage-configure

証跡データのアーカイブ

監査が終了したら、証跡データを削除してもよいが、Cool TierもしくはArchive Tierに移動することもできる。監査が終わればデータアクセスがほぼない、ということであれば、アクセス層を切り替えてコストを抑え、十分に時間が経過してから削除することもできる。

Azure Blob Storage のアクセス層 – ホット、クール、およびアーカイブ / Access tiers for Azure Blob Storage – hot, cool, and archive
https://docs.microsoft.com/azure/storage/blobs/storage-blob-storage-tiers