クラウドストレージを導入してから1〜2年が経過したころ、ISMSやPマークの更新審査、または社内監査で「アクセスログをどのように確認していますか」と問われ、「取得はしていますが、定期的な確認はできていません」と答えた経験はないでしょうか。ログを保管していること自体は正しい対応です。しかし、保管しているだけでは、異常を検知する監視体制があるとは言えません。

社外からの不審なアクセスが後から発覚し、確認まで数日かかってしまった―そうした事態が起きてから初めて、「ログを取っているのに何も気づけなかった」という構造的な問題に直面する組織は少なくありません。

この記事では、「ログ保管＝監視できている」という思い込みがなぜ生まれるのか、SaaS型クラウドストレージの監査ログや通知機能をどのように活用すべきか、さらに必要に応じてSIEM（複数のシステムログを集約し、不審な操作を検知・通知する監視基盤）と連携する際に何を確認すべきかを、情報システム担当者の視点から具体的に解説します。 

「ログは保管している」が監視になっていない理由

ログを保管していれば、インシデントが発生したときに遡って調査できます。これ自体は重要な取り組みです。ただし、「保管」と「監視」は根本的に異なる行為です。

保管とは過去の操作を記録すること、監視とはログをもとに異常の兆候を一定時間内に検知し、確認・対応につなげることです。この区別が曖昧なまま運用を続けると、次のような状態が生まれます。

  • ログファイルはストレージに蓄積されているが、誰も定期的に見ていない
  • 何か問題が起きてから「さかのぼって確認する」だけで、予防や早期検知には使えていない
  • 審査や上司への報告時に「ログは取っています」と言えるが、「何を検知していますか」と問われると答えられない

情報システム担当者が2〜3名しかいない組織では、毎日ログを手動で確認する時間的余裕はほぼありません。そのため、まず確認すべきなのは、利用中のSaaS型クラウドストレージに、監査ログの検索機能や管理者向けの通知・アラート機能が備わっているかどうかです。

たとえば、誰が、いつ、どのファイルにアクセスしたのか、ダウンロードしたのか、共有リンクを発行したのかといった操作が、意味のあるイベントとして確認できるサービスであれば、まずはその標準機能を使って監視対象を定めることが現実的です。

一方で、複数システムのログを横断して相関分析したい場合や、社内のSOC・MDR運用に組み込みたい場合は、SIEM連携を検討する段階になります。ただし、SIEMに接続しただけでは、実効性のある監視にはなりません。標準の監査機能で何を見られるのか、SIEM側で何を補うのかを切り分ける必要があります。

監査機能とSIEM連携を使い分ける際の3つの落とし穴 

SaaS型クラウドストレージでは、製品標準の監査ログや通知機能だけで確認できることもあれば、SIEMなど外部の監視基盤と連携しなければ実現しにくいこともあります。

重要なのは、すべてのログをSIEMに流し込むことではなく、「クラウドストレージ側で検知できること」と「SIEM側で相関分析すべきこと」を切り分けることです。この切り分けが曖昧なまま運用すると、次のような落とし穴が発生します。

落とし穴①：標準の監査機能で見られることを確認しないままSIEM連携に進む 

SaaS型クラウドストレージでは、アクセスログが単なる生ログではなく、「誰が・いつ・どのファイルを・どのように操作したか」というイベントとして整理されていることがあります。また、製品によっては、大量ダウンロード、共有リンク発行、権限変更などの操作を管理者へ通知できる監査・アラート機能を備えている場合もあります。

そのため、最初からSIEM連携を前提にするのではなく、まずはクラウドストレージ側の標準機能で、どの操作を確認できるのか、どの条件で通知できるのか、ログをどの期間保存できるのかを確認することが重要です。

SIEM連携は、複数システムのログを横断して分析したい場合や、既存のセキュリティ監視基盤にクラウドストレージのイベントを組み込みたい場合に検討します。標準機能で完結できる監視と、SIEMで補うべき監視を分けて考えることが、過剰な運用負荷を避けるポイントです。

落とし穴②：クラウドストレージ側の通知条件が業務実態に合っていない 

監査ログやアラート機能が備わっていても、通知条件が業務実態に合っていなければ、期待した検知にはつながりません。

たとえば、大量ダウンロードの通知条件が厳しすぎると、通常業務でも頻繁にアラートが発生します。逆に条件が緩すぎると、本来気づくべき不審な操作を見逃す可能性があります。共有リンク発行や権限変更についても、どの操作を即時通知の対象にし、どの操作を定期レビューの対象にするかを分けて設計する必要があります。

SIEMに連携する場合も同様です。クラウドストレージ側で意味のあるイベントとして整理されているログを、SIEM側でどのように扱うのかを決めなければ、通知が多すぎる、または必要な通知が出ないという状態になります。

落とし穴③：アラートを受け取る体制が整っていない

監視ルールを設定してアラートが発生しても、それを受け取る担当者が不在、または通知先が設定されていない状態では意味がありません。

よくあるケースとして、SIEMのダッシュボード上にアラートが表示されているが、誰もダッシュボードを開いていないというものがあります。また、通知メールが届いても「誤検知が多いため」に無視されるようになってしまうケースも見られます。アラートが届いたときに誰が、どの程度の時間内に、どのように対応するかを定めておかないと、アラート監視の仕組みが形骸化します。

クラウドストレージのアクセスログ：監視すべき項目と優先順位

SIEMへの連携が正しく機能しているとして、次に「何を監視するか」を決める必要があります。クラウドストレージのアクセスログには多様な操作記録が含まれますが、すべてに等しくルールを設定するとアラート数が膨大になり、運用が崩壊します。

情報システム専任が少ない組織では、監視対象を絞り込み、確実に対応できる範囲で運用することが継続の条件です。以下に、優先度別で整理した監視項目を示します。

優先度：高

  • 業務時間外の大量ダウンロード：深夜や休日に特定ユーザーが通常より多くのファイルをダウンロードしている場合、内部不正や不正アクセスの兆候として確認対象にします
  • 短時間での連続ログイン失敗：同一アカウントへのブルートフォース攻撃や、認証情報の不正使用を検知するための基本ルールです
  • 共有リンクの外部公開設定：ファイルやフォルダに対して「リンクを知っている全員がアクセス可能」といった広い共有設定が行われた場合、通知対象にします

優先度：中

  • アクセス元IPアドレスの異常：普段と異なる国や地域からのアクセス、または登録されていないIPアドレスからの操作を検知します
  • 権限外のフォルダへのアクセス試行：アクセス権限のないフォルダへのアクセスエラーが繰り返されている場合、意図的な探索行動の可能性があります
  • 管理者権限の変更：ユーザーの権限が突然昇格した場合、不正な操作またはアカウント乗っ取りの可能性を検討します

優先度「高」の3項目から始め、誤検知の調整が落ち着いてから「中」の項目を追加するという段階的な設計が、運用継続に向いています。

最低限設定すべき監視ルール3選と初期設定例

優先度「高」の3項目について、監視ルールの設定例を示します。ここで示す閾値は、あくまで初期設定のたたき台です。実際には、自社の通常操作量、勤務時間、運用体制、利用しているクラウドストレージのログ仕様に合わせて調整してください。

監視ルール①：業務時間外の大量ダウンロード

設定例：
たとえば、平日の22時〜翌7時、または土日祝日に、同一ユーザーが30分以内に20件以上のファイルをダウンロードした場合をアラート対象にする方法があります。この数値は業界横断の統一基準ではなく、初期設定の一例です。

実際の運用では、自社の通常操作量のログを2〜4週間分確認し、通常の一括操作（会議前の資料取得、月次処理、バックアップ作業など）を明らかに上回る量を基準として調整してください。

注意点：
バックアップ処理やデータ移行作業など、システムアカウントによる定期的な大量アクセスが存在する場合は、そのアカウントを例外対象として整理したうえで有効化します。

監視ルール②：連続ログイン失敗

設定例：
たとえば、同一アカウントに対して10分以内に5回以上のログイン失敗が発生した場合をアラート対象にする方法があります。この閾値も初期設定の一例であり、自社の認証環境や利用者数に合わせた調整が必要です。

その後、同じアカウントでログイン成功が続いた場合は、第三者が試行錯誤の末にログインした可能性もあるため、重大度を上げた追加アラートを設定することも検討します。

注意点：
パスワード変更直後や、複数端末からの同時利用環境では誤検知が発生しやすくなります。初期運用期間中は「通知のみ」とし、実際に対応フローへ乗せるかどうかは担当者が判断する運用から始めると、過剰なアラートを避けやすくなります。

監視ルール③：全体公開の共有リンク発行

設定例：
「リンクを知っている全員がアクセス可能」といった広い共有設定で、ファイルまたはフォルダの共有リンクが発行された場合に通知対象とします。このルールは件数の閾値を設けるよりも、発生した操作を確認対象にする方が適しています。

注意点：
業務上、外部共有が必要なケースはあります。そのため、発生しただけで即インシデント扱いにするのではなく、「担当者が翌営業日までに操作理由を確認し、問題なければクローズする」という軽量な手順を用意しておくと、アラート対応を継続しやすくなります。

アラート後の対応フロー設計：社内完結かアウトソースか

監視ルールを設定してアラートが届き始めたとき、次に必要なのは「誰がどう動くか」の手順です。この対応フローが定まっていないと、アラートが来るたびに担当者が判断に迷い、徐々に無視されるようになります。

社内完結で対応できる条件

以下をすべて満たせる場合は、社内完結での運用を検討できます。

  • アラートを受け取る担当者が特定されており、業務時間内であれば一定時間内に初期確認ができる
  • 初期確認（該当ユーザーへの聞き取り、操作ログの詳細確認）を実施できる権限と時間がある
  • 「誤検知であればクローズ、要対応であれば上長報告」という判断基準が文書化されている

前述の3条件が整っていれば、セキュリティ監視を専門に行う担当者がいない組織でも、限定した範囲から運用を始めやすくなります。 

アウトソースを検討すべき条件

以下のいずれかに当てはまる場合は、外部のセキュリティ監視サービスの活用を検討してください。たとえば、MDR（検知・調査・初動対応を支援するサービス）や、SOCアウトソーシング（セキュリティ監視業務の外部委託）などが選択肢になります。 

  • 夜間・休日のアラートに対応できる担当者がいない
  • アラートの内容を判断できる技術的な知識が社内にない
  • 月に数十件以上の確認対象アラートが発生し、本来業務と並行した対応が困難になっている

アウトソースする場合でも、「何をアウトソースし、何を社内で判断するか」の境界線を契約前に定めることが重要です。「すべてお任せ」にすると、インシデント発生時に社内側の判断材料や改善点が残りにくくなるため、再発防止策の立案が難しくなります。

運用を継続させるチューニング習慣

SIEMの監視ルールは、設定して終わりではありません。業務パターンの変化（在宅勤務の増加、新拠点の追加など）に応じて、閾値や対象アカウントを定期的に見直す必要があります。推奨するのは、月に1回、30分程度の「アラートレビュー」を定例化することです。具体的には次の3点を確認します。

  • 先月のアラート件数と内訳（誤検知率が高いルールの特定）
  • 誤検知が多いルールの閾値調整またはホワイトリスト更新
  • 業務上の変化（新しい共有フォルダの運用開始など）に伴うルールの見直し

このレビューを継続することで、アラート疲れを防ぎながら、監視精度を段階的に高められます。最初から完璧な設定を目指すより、「今月は誤検知を1件減らす」という小さな改善の積み重ねが、運用を継続させる現実的な方法です。

Fleekdriveの監査機能とログ連携時の確認ポイント

SaaS型オンラインストレージでは、SIEM連携の前に、サービス標準の監査機能でどこまで確認・通知できるかを把握することが重要です。Fleekdriveには、設定したポリシーに反する操作をユーザーが実行した場合に、監査管理者へ通知できる監査機能が備わっています。たとえば、ファイルのダウンロード、共有リンクの発行、権限変更など、外部共有や情報持ち出しにつながりやすい操作を監査対象として確認できれば、日常運用の中で不審な操作に気づきやすくなります。

まずは、Fleekdrive側でどの操作ログを確認できるのか、どの条件で管理者へ通知できるのか、監査ログをどの期間保存できるのかを確認します。そのうえで、社内に既存のSIEMやSOC運用がある場合は、必要なログを外部の監視基盤に連携できるかを検討します。

つまり、FleekdriveのようなSaaS型オンラインストレージでは、最初からSIEM連携ありきで考えるのではなく、標準の監査機能で日常的な監視を行い、複数システムを横断した分析が必要な場合にSIEM連携を検討する、という順番で整理すると運用に落とし込みやすくなります。

まとめ：ログを「保管」から「監視」に変えるために

アクセスログは、保管しているだけでは不審な操作の早期発見にはつながりません。監視体制として機能させるには、どの操作を確認できるのか、どの条件で通知するのか、アラート後に誰が対応するのかを決めておく必要があります。まずは、次の3点を確認してください。

  • 利用中のクラウドストレージで、どの操作ログを確認できるか
  • 大量ダウンロード、ログイン失敗、広範な共有リンク発行など、優先度の高い操作を通知・確認できる設定になっているか
  • アラート発生時に、誰が確認し、誰へ報告するかが文書化されているか

FleekdriveのようなSaaS型オンラインストレージでは、まず標準の監査機能や通知機能を使って、日常的に確認すべき操作を監視対象にすることが現実的です。そのうえで、複数システムを横断した相関分析や既存SOCとの連携が必要な場合に、SIEM連携を検討します。

大規模な監視体制を最初から整える必要はありません。まずは標準機能で検知対象を絞り、対応できる範囲から運用を始めることが、ログ保管から実効性のある監視へ移行する第一歩になります。