Azure Table Storageアクセスログ有効化設定について

このブログシリーズ 「クラウドセキュリティ 実践集」 では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか?」 というリスクの解説から、 「どうやって直すのか?」 という具体的な修復手順(コンソール、AWS CLI、Terraformなど)まで、分かりやすく解説します。

この記事では、Azure Table Storageのアクセスログ設定について、リスクと対策を解説します。

ポリシーの説明

Azure Table Storageは、NoSQL構造化データを格納するストレージサービスで、大量の半構造化データを低コストで保存できます。アクセスログは、テーブルサービスに対するすべての読み取り(QueryEntities、QueryTables)、書き込み(InsertEntity、UpdateEntity、MergeEntity)、削除(DeleteEntity、DeleteTable)操作を記録する重要なセキュリティ機能です。

このログ機能により、誰が(CallerIPAddress)、いつ(TimeGenerated)、どのデータに(Uri)、どのような操作を(OperationName)実行し、その結果(StatusCode)を詳細に追跡できます。Azure Storage Analyticsログ(クラシック)またはAzure Monitor診断設定(推奨)を通じて、包括的な監査証跡を確立することが不可欠です。

修復方法

コンソールでの修復手順

Azure コンソールを使用して、Table Storageのアクセスログを有効化します。

ステップ1: Azure Portalにアクセス

  1. Azure Portal (https://portal.azure.com) にログイン
  2. 左側のナビゲーションメニューから「ストレージアカウント」を選択
  3. ログを有効化したいストレージアカウントをクリック

ステップ2: 診断設定(クラシック)の構成

  1. ストレージアカウントのメニューで「監視(クラシック)」セクションを探す
  2. 「診断設定(クラシック)」をクリック
  3. 診断設定画面が表示される

    ※ 注意: Azure Storage Analyticsログ(クラシック)は2024年以降新規作成が推奨されないため、新規構築の場合はステップ6のAzure Monitor診断設定を使用してください

ステップ3: Table Storageログの有効化

  1. 「状態」を「オン」に設定
  2. 「テーブル」セクションで以下のチェックボックスをすべて選択:
    • 読み取り:すべての読み取り操作(QueryEntities、GetEntity等)をログ記録
    • 書き込み:すべての書き込み操作(InsertEntity、UpdateEntity、MergeEntity等)をログ記録
    • 削除:すべての削除操作(DeleteEntity、DeleteTable等)をログ記録

ステップ4: データ保持期間の設定

  1. 「データを削除する」チェックボックスをオンにする
  2. 保持期間を設定(1~365日)
    • 推奨設定
      • 一般的な組織: 90日
      • PCI-DSS準拠: 90日以上(オンライン環境は1年)
      • HIPAA準拠: 6年(2190日)
      • 金融機関: 365日以上
    • 新規ストレージアカウントのデフォルトは7日
  3. 保持期間を無制限にする場合はチェックボックスをオフのままにする
    • ※ コスト増加に注意: ログストレージは月単位で課金されます

ステップ5: 設定の保存

  1. 「保存」ボタンをクリック
  2. 設定の適用には最大1時間かかる場合がある
  3. 保存完了メッセージを確認

ステップ6: Azure Monitor診断設定(推奨方法) より高度な分析機能を利用するため、Azure Monitor診断設定の使用を強く推奨:

  1. ストレージアカウントメニューで「監視」→「診断設定」を選択
  2. 「Table Services」を選択し、「+ 診断設定を追加する」をクリック
  3. 診断設定の名前を入力(例:table-storage-audit-logs)
  4. ログカテゴリで以下をすべて選択:
    • StorageRead: QueryEntities、QueryTables等の読み取り操作
    • StorageWrite: InsertEntity、UpdateEntity、MergeEntity等の書き込み操作
    • StorageDelete: DeleteEntity、DeleteTable等の削除操作
  5. 送信先を選択(複数選択可):
    • Log Analytics ワークスペース
      • KQLクエリでのリアルタイム分析
      • アラートとダッシュボード作成
      • 保持期間: 30日~730日
    • ストレージアカウント
      • 長期アーカイブ用
      • 別のストレージアカウントを使用(同一アカウントは不可)
      • ライフサイクル管理でコスト最適化
    • イベントハブ
      • SIEM(Splunk、QRadar等)へのリアルタイム連携
      • サードパーティ監視ツールとの統合
  6. 「保存」をクリック

ステップ7: ログの確認

  1. Storage Analyticsログの場合
    • ストレージアカウント内の「$logs」コンテナに保存
    • パス構造: $logs/table/YYYY/MM/DD/hhmm/<counter>_<service>_<operation>_<status>.log
    • Azure Storage Explorerまたはポータルのストレージブラウザーでアクセス
  2. Azure Monitorログの場合
    • Log AnalyticsワークスペースでKQLクエリを実行
    • テーブル名: StorageTableLogs
    • リアルタイムでデータを分析可能
  3. 初回ログ生成までの時間
    • 設定後最大1時間
    • 実際のテーブル操作が必要

最後に

この記事では、Azure Table Storageのアクセスログ有効化について、実装手順、トラブルシューティング、ベストプラクティスを詳細に解説しました。

アクセスログの有効化により得られるメリット:

  • セキュリティインシデントの早期検出と対応
  • コンプライアンス要件の充足と監査対応
  • 不正アクセスパターンの特定と防御
  • フォレンジック分析能力の確保
  • データガバナンスの強化

アクセスログは単なるコンプライアンス要件ではなく、組織のセキュリティポスチャーを大幅に向上させる重要な投資です。特にクラウドネイティブ環境では、包括的な監査証跡の確立がゼロトラストセキュリティの基礎となります。

この問題の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。 運用が非常に楽に出来る製品になっていますので、ぜひ興味がある方はお問い合わせお待ちしております。 最後までお読みいただきありがとうございました。この記事が皆さんの役に立てば幸いです。

CSPMについてはこちらで解説しております。併せてご覧ください。

参考情報

この記事をシェアする

クラウドセキュリティ対策実践集一覧へ戻る

貴社の利用状況に合わせた見積もりを作成します。

料金プランを詳しく見る