クラウド監査の方法:オンプレとの違いと実務対応April 29, 2026 · 3 分
クラウド監査の方法:オンプレとの違いと実務対応
目次

はじめに:なぜ今、クラウド監査が重要なのか

「クラウドに移行したけど、監査はどうすればいいのか」——これは、私がIT監査の現場で最も多く受ける相談のひとつです。

総務省の調査によると、2025年時点で日本企業のクラウドサービス利用率は約77%に達しています。もはやクラウドは「検討するもの」ではなく「当たり前に使うもの」になりました。しかし、監査の現場では依然としてオンプレミス時代の手法をそのまま適用しようとして、壁にぶつかるケースが後を絶ちません。

本記事では、クラウド環境特有の監査アプローチについて、オンプレミスとの違いを明確にしながら、実務で使える具体的な手順とポイントを解説します。IT監査担当者、内部監査人、情報システム部門の方々が、明日から使える知識を持ち帰っていただけることを目指しています。


背景・概要:クラウド監査を取り巻く環境

クラウドサービスの分類と監査への影響

まず、クラウドサービスの基本分類を整理しておきましょう。監査アプローチは、利用するサービス形態によって大きく異なります。

サービス形態概要代表例監査で見るべき範囲
IaaSInfrastructure as a Service。仮想サーバー・ストレージを提供AWS EC2、Azure VM、GCP Compute EngineOS以上のレイヤー全般
PaaSPlatform as a Service。アプリ開発・実行環境を提供AWS Lambda、Azure App Service、Herokuアプリケーションと設定
SaaSSoftware as a Service。完成したアプリケーションを提供Microsoft 365、Salesforce、Google Workspace利用設定とアクセス管理

この分類を「責任共有モデル(Shared Responsibility Model)」と組み合わせて理解することが、クラウド監査の出発点です。

責任共有モデルとは

責任共有モデルとは、クラウド環境におけるセキュリティ責任を、クラウド事業者と利用者で分担する考え方です。

IaaSでは利用者の責任範囲が広く、SaaSでは狭くなります。監査担当者は、この責任分界点を正確に把握したうえで、監査範囲を決定する必要があります。

オンプレミスとクラウドの根本的な違い

オンプレミス環境とクラウド環境では、監査の前提条件が根本的に異なります。

オンプレミス環境の特徴:

クラウド環境の特徴:

この違いを理解せずに従来の監査手法を適用すると、「サーバールームの入退室ログを見せてください」といった的外れな要求をしてしまうことになります。


具体的な手順と要点:クラウド監査の7つのステップ

ステップ1:利用サービスの棚卸しと責任範囲の明確化

何をするか: 自社が利用しているすべてのクラウドサービスを洗い出し、それぞれのサービス形態と責任範囲を明確にします。

実務ポイント:

  1. IT資産管理台帳の確認:正式に契約しているサービスをリストアップ
  2. シャドーIT調査:従業員が勝手に利用しているクラウドサービスを特定
  3. 責任分界点の文書化:各サービスについて、どこまでが事業者責任で、どこからが自社責任かを明文化

具体例: ある製造業A社(従業員500名)では、IT部門が把握していたクラウドサービスは12個でしたが、ネットワーク通信ログの分析により、実際には47個のクラウドサービスが利用されていることが判明しました。このうち23個は「シャドーIT」でした。

使えるツール:

ステップ2:第三者保証報告書(SOCレポート)の入手と評価

何をするか: クラウド事業者が取得しているSOCレポートを入手し、統制の有効性を評価します。

SOCレポートの種類:

種類対象利用シーン
SOC1財務報告に関連する内部統制J-SOX対応
SOC2セキュリティ、可用性、処理のインテグリティ、機密保持、プライバシー一般的なセキュリティ監査
SOC3SOC2の概要版(一般公開用)簡易的な確認

また、Type IとType IIの違いも重要です:

実務ポイント:

  1. SOC2 Type IIを優先的に入手する
  2. 報告書の対象期間が、監査対象期間をカバーしているか確認する
  3. 「例外事項」「発見事項」欄を重点的にチェックする
  4. 補完統制(CUEC:Complementary User Entity Controls)の実施状況を確認する

注意点: SOCレポートには「Bridge Letter」と呼ばれる補足文書が必要な場合があります。これは、レポートの対象期間終了後から現在までの間に重大な変更がないことを証明するものです。

ステップ3:アイデンティティとアクセス管理(IAM)の監査

何をするか: クラウド環境におけるアカウント管理とアクセス制御の適切性を検証します。

重点確認項目:

  1. 特権アカウントの管理

    • ルートアカウント/管理者アカウントの使用状況
    • MFA(多要素認証)の設定状況
    • 最終ログイン日時の確認
  2. 最小権限の原則

    • 過剰な権限が付与されていないか
    • 使われていない権限が残っていないか
  3. アカウントライフサイクル管理

    • 退職者のアカウント無効化プロセス
    • 定期的なアカウント棚卸しの実施状況

具体例: ある金融機関B社のAWS環境監査では、以下の問題が発見されました:

監査手続きの例(AWS環境):

# IAMユーザーのMFA設定状況を確認するAWS CLIコマンド
aws iam generate-credential-report
aws iam get-credential-report --output text --query Content | base64 -d

このコマンドで生成されるレポートには、各ユーザーのMFA設定状況、パスワード最終使用日、アクセスキー最終使用日などが含まれます。

ステップ4:ネットワークセキュリティとデータ保護の監査

何をするか: クラウド環境のネットワーク設計とデータ保護施策の適切性を検証します。

ネットワークセキュリティの確認ポイント:

  1. 仮想ネットワークの設計

    • VPC(Virtual Private Cloud)のセグメンテーション
    • パブリックサブネットとプライベートサブネットの分離
  2. セキュリティグループ/ファイアウォールルール

    • 不要なインバウンドルールがないか
    • 0.0.0.0/0(全許可)設定の有無
  3. 外部公開リソースの把握

    • パブリックIPが付与されたリソース一覧
    • 公開S3バケット/BLOBストレージの有無

データ保護の確認ポイント:

  1. 暗号化の実施状況

    • 保存データ(At Rest)の暗号化
    • 通信データ(In Transit)の暗号化
    • 暗号鍵の管理方法
  2. バックアップと復旧

    • バックアップの取得頻度と保持期間
    • リージョン間バックアップの有無
    • 復旧手順のテスト実施状況

実務ポイント: クラウド環境では、設定ミスによる意図しないデータ公開が頻発しています。2023年の調査では、企業のS3バケットの約12%に何らかの設定ミスがあったという報告もあります。

具体例: EC社のAzure環境監査で発見された問題:

ステップ5:ログ管理と監視体制の監査

何をするか: セキュリティイベントの記録と監視の仕組みが適切に機能しているか検証します。

確認すべきログの種類:

ログ種類内容主要サービス
監査ログ管理操作の記録AWS CloudTrail、Azure Activity Log、GCP Cloud Audit Logs
アクセスログリソースへのアクセス記録S3 Access Logs、Azure Storage Analytics
フローログネットワーク通信の記録VPC Flow Logs、NSG Flow Logs
アプリケーションログアプリ固有の記録CloudWatch Logs、Azure Monitor

監査手続き:

  1. ログ取得設定の確認

    • 監査ログが全リージョンで有効化されているか
    • ログの保持期間は適切か(規制要件を満たすか)
  2. ログの完全性保護

    • ログファイルの改ざん防止機能(ログ整合性検証)の有効化
    • ログ保存先への書き込み専用アクセス設定
  3. 監視とアラートの設定

    • セキュリティイベントに対するアラート設定
    • アラート発生時の対応プロセス

具体例: D社のGCP環境監査での発見事項:

実務ポイント: クラウドのログは従量課金のため、コスト最適化を理由にログ取得を絞っているケースがあります。しかし、監査やインシデント対応の観点では、必要なログが取得できていないことは重大なリスクです。コストと必要性のバランスを文書化して判断することが重要です。

ステップ6:構成管理と変更管理の監査

何をするか: クラウド環境の構成が適切に管理され、変更が統制されているか検証します。

クラウド特有の課題:

オンプレミスでは、サーバーの追加や設定変更に物理的な作業や承認プロセスが必然的に介在しました。しかし、クラウドでは開発者がAPIやコンソールから数秒で本番環境を変更できてしまいます。この「変更の容易さ」が、統制上の新たな課題を生みます。

確認ポイント:

  1. Infrastructure as Code(IaC)の利用状況

    • Terraform、CloudFormation、ARM Templateの利用
    • コードレビューと承認プロセス
    • 本番環境への手動変更の禁止ポリシー
  2. ドリフト検出

    • 定義された構成と実際の構成の乖離の検出
    • ドリフト発生時の是正プロセス
  3. 変更履歴の追跡

    • すべての構成変更が記録されているか
    • 変更の承認者と実施者の記録

実務ポイント: IaCを導入している企業でも、「緊急対応」を理由に手動変更を許容しているケースがあります。監査では、緊急変更の件数と内容、事後承認の実施状況を確認しましょう。

参考指標: 成熟度の高い組織では、本番環境の構成変更のうち、IaC経由の変更が95%以上を占めます。手動変更が20%を超えている場合は、構成管理に課題がある可能性が高いです。

ステップ7:コンプライアンス対応と継続的モニタリング

何をするか: 規制要件への対応状況と、継続的なセキュリティ監視の仕組みを検証します。

規制要件との関連:

規制・基準クラウド監査での考慮点
個人情報保護法データの保存場所(国・リージョン)、委託先管理
GDPREU域外へのデータ移転、データ処理の法的根拠
PCI DSSカード会員データ環境(CDE)の分離、暗号化要件
FISC安全対策基準金融機関向け、外部委託管理、可用性要件

クラウドセキュリティ態勢管理(CSPM):

CSPM(Cloud Security Posture Management)とは、クラウド環境のセキュリティ設定を継続的に監視し、ベストプラクティスからの逸脱を検出するソリューションです。

主要なCSPMソリューション:

監査での活用:

  1. CSPMツールの導入状況と設定内容を確認
  2. 検出された問題の件数と傾向を分析
  3. 問題の是正プロセスと対応状況を検証

具体例: E社では、AWS Security Hubを導入した結果、以下が可視化されました:

監査では、この数値を経時的に追跡し、改善傾向にあるか、重大な問題が放置されていないかを確認しました。


よくある質問(FAQ)

Q1:クラウド事業者のデータセンターを視察することはできますか?

回答: 原則として、主要なパブリッククラウド事業者(AWS、Azure、GCP)のデータセンターへの顧客立ち入りは認められていません。これは、数百万の顧客を抱えるクラウド事業者として、物理的なセキュリティと運用効率を維持するための方針です。

代替手段:

  1. SOCレポートの活用:物理セキュリティに関する統制はSOC2レポートで検証可能です
  2. ISO/IEC 27001認証:認証範囲にデータセンターが含まれているか確認
  3. CSAのCCM(Cloud Controls Matrix):クラウドセキュリティのベストプラクティスへの準拠状況
  4. コンプライアンスプログラム:各社が公開しているコンプライアンス情報(AWS Artifact、Azure Compliance Manager、GCP Compliance Reports Manager)

監査では、「自社で確認できないからダメ」ではなく、「第三者保証をどう活用するか」という発想の転換が必要です。

Q2:マルチクラウド環境の監査はどのように進めればよいですか?

回答: 複数のクラウドを利用している環境では、以下のアプローチを推奨します。

1. 統一的なセキュリティベースラインの策定

2. クラウド横断的な可視化ツールの活用

3. 各クラウドの専門知識を持つ監査メンバーの配置

実務ポイント: マルチクラウドの監査では、「同じ統制目標を各クラウドでどう実現しているか」という観点で整理すると、比較しやすくなります。例えば、「管理者アカウントへのMFA強制」は、AWSではIAM Policy、AzureではConditional Access、GCPではOrganization Policyで実現します。

Q3:SaaSの監査は具体的に何を見ればよいですか?

回答: SaaSは最も責任範囲が狭いサービス形態ですが、「設定と利用方法」は利用者の責任です。

SaaS監査の重点項目:

  1. アクセス管理

    • シングルサインオン(SSO)の設定状況
    • MFAの強制設定
    • アカウントの棚卸し状況
    • 外部共有設定(ゲストユーザー、外部コラボレーション)
  2. データ保護設定

    • データのエクスポート制限
    • DLP(Data Loss Prevention)ポリシー
    • 保持ポリシーと削除設定
  3. 監査ログの取得

    • 管理者操作ログの有効化
    • ユーザーアクティビティログの取得
    • ログのエクスポートと保管
  4. セキュリティ設定

    • パスワードポリシー
    • セッションタイムアウト
    • モバイルデバイスからのアクセス制限

具体例(Microsoft 365の監査チェックリストの一部):


まとめ:クラウド監査を成功させるために

本記事のポイント整理

  1. 責任共有モデルの理解が出発点

    • IaaS/PaaS/SaaSで責任範囲が異なる
    • 自社の責任範囲を正確に把握する
  2. 第三者保証を効果的に活用

    • SOC2 Type IIレポートを優先的に入手
    • 補完統制(CUEC)の実施状況も確認
  3. クラウド特有の監査観点を持つ

    • IAMとアクセス制御が最重要
    • 構成の変更容易性に対する統制
    • ログ管理と継続的モニタリング
  4. 自動化ツールを活用

    • CSPMソリューションの導入状況を確認
    • 継続的コンプライアンスの仕組みを評価

監査担当者へのアドバイス

1. 技術知識のアップデート クラウド監査には、従来のIT監査とは異なる技術知識が必要です。各クラウドベンダーが提供する無料のトレーニング(AWS Skill Builder、Microsoft Learn、Google Cloud Skills Boost)を活用しましょう。

2. コミュニケーションの重視 クラウドの設定は、IT部門だけでなく、開発チームが直接管理しているケースも多いです。監査対象部門との早期のコミュニケーションで、利用実態を正確に把握することが重要です。

3. 継続的な監査への移行 クラウド環境は日々変化します。年次の定点監査だけでなく、CSPMツールを活用した継続的なモニタリングと、問題発生時の迅速な対応が求められます。

次のステップ

クラウド監査を始めるにあたって、まずは以下から取り組むことをお勧めします:

  1. 自社のクラウドサービス利用状況の棚卸し
  2. 主要サービスのSOCレポートの入手
  3. IAM設定の簡易チェック(MFA設定状況、休眠アカウント)
  4. CSPMツールの評価・導入検討

クラウド監査は、一見すると複雑に見えますが、「責任範囲の明確化」と「適切なツールの活用」によって、効率的かつ効果的に実施できます。本記事が、皆様の実務の一助となれば幸いです。


関連キーワード: クラウド監査、IT監査、SOCレポート、責任共有モデル、AWS監査、Azure監査、CSPM、クラウドセキュリティ、IAM、コンプライアンス、内部統制

IT監査 セキュリティ