責任共有とログ｜クラウドの基本・IAM・責任

このページはプロモーション（広告）を含みます。

クラウドの基本・IAM・責任（中級・読む35分＋演習40分）

この授業のゴール

• 責任共有モデルにもとづき、IaaS・PaaS・SaaSそれぞれで利用者が担う項目（データ・権限・公開設定・OSなど）を表にできる
• 保存場所の公開設定を「意図した公開」と「事故」に分け、公開する場合に記録すべき理由・範囲・承認を書ける
• 監査ログの項目（時刻・主体・操作・資源・結果）を読み、UTCの時刻を日本時間に直して、危険な操作をPythonで抽出できる
• ログに秘密情報や個人情報を書かない、改ざんされにくい場所に保管する、といったログ自体の扱いを説明できる

仕事でどう使うか

「クラウドの提供者が守ってくれるはず」という思い込みは、情報漏洩の典型的な原因です。提供者と利用者は守る範囲を分担しており、その境界を知らないと、誰も守っていない場所が生まれます。そして事故が起きたときに「誰が・いつ・何をしたか」を答えられるかは、ログを残していたかどうかで決まります。

この授業の責任分担は一般的なモデルで、実際の境界はサービスや契約ごとに異なり、変わり得ます。導入時には提供者の公式の説明と契約書で確認してください。ログの形式は教材用の簡略版で、分析はPythonによる模擬です。

前提

次の内容を使います。

• IaaS・PaaS・SaaS → クラウドとオンプレミス
• オブジェクト保存・受信ルール → 計算・保存・ネットワーク
• IAMポリシー（主体・操作・資源） → IAMと最小権限
• 漏洩時の対応と監査ログの考え方 → 「漏洩時の対応」（有料版）
• UTC（協定世界時）：世界共通の基準時刻。日本時間（JST）は UTC より9時間進んでいる（UTC 0時 ＝ JST 9時）。

Pythonでは、辞書のリスト、for 文、datetime モジュールを使います。

身近な状況：解答ファイルが検索で見つかった

あおば学習で、ある受講者から「テストの解答ファイルが検索エンジンで見つかる」と連絡がありました。調べると、解答を置いていた保存場所 edu-answers が「誰でも読める」公開設定になっていました。

関係者の最初の反応はばらばらでした。

• 開発担当：「クラウドの提供者のセキュリティ事故ではないか」
• 配信係：「公開している教材サイトと同じ設定にしただけ」
• 管理者：「いつ、誰が公開にしたのか分からない。記録の保存を止めた形跡もある」

答えは次のとおりです。

1. 提供者の基盤には問題がなかった。保存場所の公開設定は利用者が行う設定で、利用者の責任範囲。
2. 教材サイトは意図して公開するもの、解答は公開してはいけないもの。同じ「公開」でも、データの区分で判断が変わる。
3. 監査ログが有効なら、「3月3日 2時40分（日本時間）、user/aoki が公開設定に変更し、その25分後に記録を停止した」と特定できる。

この授業では、責任の境界を表にし、監査ログから危険な操作を見つける方法を学びます。

直感的な説明：貸し倉庫の管理会社と借り主

貸し倉庫にたとえます。

• 管理会社（提供者）が守るもの：建物、外壁、警備員、電気、消火設備。借り主がどれだけ注意しても、建物が崩れたら管理会社の責任です。
• 借り主（利用者）が守るもの：自分の区画の鍵を誰に渡すか、扉を開けっぱなしにしないか、何を保管するか、出入りの記録を付けるか。扉に「ご自由にお持ちください」と貼れば、管理会社の警備が完璧でも中身は持ち出されます。

借りる範囲が広がるほど（区画だけ→家具付き→何でも込み）、管理会社の担当は増えますが、「鍵を誰に渡すか」と「何を置くか」は最後まで借り主の担当です。これが責任共有モデルの中心です。

ログは防犯カメラと入退室記録です。事故を防ぐ装置ではありませんが、「誰が・いつ・何をしたか」を後から確かめ、同じ事故を防ぐ手がかりになります。カメラの電源を切った記録そのものが、重要な手がかりになることもあります。

たとえ話の限界：実際のクラウドでは、「区画の扉」に当たる設定がたくさんあり（公開設定、受信ルール、IAM、暗号の設定など）、どれか1つの誤りで露出します。また、ログは自動では全部残らず、何を記録するかを利用者が選ぶものがあります。

正確な定義：責任共有モデルとログの種類

• 責任共有モデル（shared responsibility model）：クラウドのセキュリティと運用の責任を、提供者と利用者で分担する考え方。一般に、提供者はクラウドそのもの（施設・機器・基盤ソフトウェア）を、利用者はクラウドの中に置くもの（データ・アカウントと権限・設定・自分のアプリ）を守ると説明されます。

• 公開設定：保存場所やファイルを、認証なしで誰でも読める状態にするかどうかの設定。公開は例外として扱い、公開するなら「対象・理由・データ区分（公開してよい情報か）・承認者・見直し日」を記録します。期限付きで特定の相手に渡したいときは、公開ではなく、権限や期限付きのURL（署名付きURLなどと呼ばれる）を使います。
• ログの種類：

• 監査ログの基本項目：時刻（多くはUTC）、主体（誰が）、操作（何を）、資源（何に対して）、結果（成功・拒否）、送信元（どこから）。
• ログの扱い：(1) 秘密情報（パスワード・キー）や不要な個人情報を書かない、(2) 操作する人とは別の権限・別の場所に保管し、削除や改ざんをしにくくする、(3) 保存期間を決める、(4) 重要な操作（公開設定、権限付与、ログ停止）は検知して通知する。

段階付き例題：監査ログから危険な操作を見つける

問題：次の5件の監査ログ（教材用の簡略形式）から、(1) 成功した危険な操作、(2) 拒否された権限変更の試み を見つけ、日本時間で報告する。

ステップ1：危険な操作を定義する。ここでは storage:PutBucketPolicy（公開設定の変更）、iam:AttachPolicy（権限の付与）、logging:StopLogging（記録の停止）を「重要な操作」とします。

ステップ2：UTCを日本時間に直す。datetime.fromisoformat() は 2026-03-02T17:40:00Z のような文字列を時刻のオブジェクト（datetime型）に変換します（末尾の Z はUTCの意味）。.astimezone(JST) で日本時間に変換します。

ステップ3：条件で絞る。

from datetime import datetime, timezone, timedelta
JST = timezone(timedelta(hours=9))
events = [
  {"id": "e1", "time": "2026-03-02T01:10:00Z", "principal": "user/aoki",      "action": "storage:PutObject",       "resource": "bucket/edu-site/l1.html", "result": "success"},
  {"id": "e2", "time": "2026-03-02T17:40:00Z", "principal": "user/aoki",      "action": "storage:PutBucketPolicy", "resource": "bucket/edu-answers",      "result": "success", "detail": {"public_read": True}},
  {"id": "e3", "time": "2026-03-02T17:42:00Z", "principal": "svc/web-app",    "action": "storage:GetObject",       "resource": "bucket/edu-site/l1.html", "result": "success"},
  {"id": "e4", "time": "2026-03-02T17:50:00Z", "principal": "user/unknown01", "action": "iam:AttachPolicy",        "resource": "role/admin",              "result": "denied"},
  {"id": "e5", "time": "2026-03-02T18:05:00Z", "principal": "user/aoki",      "action": "logging:StopLogging",     "resource": "trail/main",              "result": "success"},
]

SENSITIVE = {"storage:PutBucketPolicy", "iam:AttachPolicy", "logging:StopLogging"}

def jst(t):
    return datetime.fromisoformat(t).astimezone(JST).strftime("%m/%d %H:%M")

for e in events:
    if e["action"] in SENSITIVE:
        mark = "要確認(成功)" if e["result"] == "success" else "試行(拒否)"
        print(jst(e["time"]), e["principal"], e["action"], e["resource"], mark, e.get("detail", ""))

出力：

03/03 02:40 user/aoki storage:PutBucketPolicy bucket/edu-answers 要確認(成功) {'public_read': True}
03/03 02:50 user/unknown01 iam:AttachPolicy role/admin 試行(拒否)
03/03 03:05 user/aoki logging:StopLogging trail/main 要確認(成功)

ステップ4：意味を読む。

深夜2時台の公開設定の変更と、直後の記録停止は、本人の誤操作だけでなく認証情報の盗用も疑うべき組合せです。UTCのまま「17時40分」と読むと夕方の通常作業に見えてしまう点にも注意してください。

操作して理解する：公開設定の点検表を作る

保存場所の一覧から、公開の妥当性を点検します。data_class（データ区分）が public（公開してよい情報）以外のものが公開されていたら事故、public でも理由の記録がなければ要修正、と判定します。

buckets = [
    {"name": "edu-site",    "public_read": True,  "data_class": "public",       "reason": "教材サイトの配信（承認: 管理者 2026-01）"},
    {"name": "edu-answers", "public_read": True,  "data_class": "confidential", "reason": None},
    {"name": "edu-logs",    "public_read": False, "data_class": "internal",     "reason": None},
    {"name": "edu-banner",  "public_read": True,  "data_class": "public",       "reason": None},
]
for b in buckets:
    if not b["public_read"]:
        verdict = "OK（非公開）"
    elif b["data_class"] != "public":
        verdict = "事故：公開してはいけない区分"
    elif not b["reason"]:
        verdict = "要修正：公開の理由・承認の記録なし"
    else:
        verdict = "OK（意図した公開）"
    print(f"{b['name']:<12} {verdict}")

出力：

edu-site     OK（意図した公開）
edu-answers  事故：公開してはいけない区分
edu-logs     OK（非公開）
edu-banner   要修正：公開の理由・承認の記録なし

試してみましょう。

• edu-answers に理由を書き足しても、判定は「事故」のままです。理由があれば公開してよいのではなく、公開してよい区分かが先だからです。
• edu-logs を公開にすると、区分が internal なので「事故」になります。ログには操作した人の情報が含まれるため、ログの保存場所も非公開が原則です。

発展：ログの保護・保存期間・検知の設計

• ログの保護：攻撃者や誤操作で記録が消されないよう、ログを別のアカウント（または別の管理単位）の保存場所に送り、通常の担当者には削除権限を与えない構成が一般的です。一定期間は上書き・削除できない設定（書き込み1回・読み取り多数の保存）を持つサービスもあります。
• 保存期間：調査に必要な期間と、個人情報を必要以上に持たない要請のバランスで決めます。法令・業界の基準・社内規程で求められる期間がある場合はそれに従います（内容は変わり得るため、最新の公式情報や社内の担当部署で確認）。
• 既定の記録範囲：管理操作の監査ログは既定で一定期間記録されるサービスが多い一方、データアクセスの記録は既定で無効だったり、費用がかかったりすることが一般的です。「記録されているはず」と思い込まず、何が記録されているかを一度確認して文書に残します。
• 検知と通知：重要な操作（公開設定、権限付与、記録の停止、多数の拒否）を検知したら担当者に通知する規則を作ります。通知が多すぎると無視されるため、まず少数の重要な操作から始めます（監視とエスカレーションは 「検知とエスカレーション」（有料版））。
• ログの中の個人情報：アプリケーションログに入力内容をそのまま書くと、メールアドレスや問い合わせ本文が残ります。必要な項目だけを書き、識別子は仮名化します（「匿名化と再識別」（有料版））。

よくある失敗

失敗1：「クラウドだから提供者が守る」と公開設定を確認しない

誤った判断：PaaSのデータ分析サービスにCSVを置き、「マネージドサービスだから安全」として共有設定を確認しなかった。実際は「リンクを知っている人は誰でも閲覧可」になっていた。

なぜ誤りか：責任共有モデルの表で、公開設定・共有範囲はIaaS・PaaS・SaaSすべてで利用者の責任です。マネージドサービスが肩代わりするのは、OSや基盤ソフトウェアの更新などです。

直し方：新しいサービスを使い始めるときに、責任分担表の「利用者」の行（公開設定、権限、データの分類、ログ）を1つずつ確認するチェックリストを作る。共有は「誰でも」ではなく、特定の主体への権限で行う。

失敗2：UTCのログを日本時間と思って読む

誤った読み方：監査ログの 2026-03-02T17:40:00Z を見て「3月2日の夕方、業務時間内の作業」と判断し、調査対象から外した。

from datetime import datetime, timezone, timedelta
t = datetime.fromisoformat("2026-03-02T17:40:00Z")
print("UTC:", t.strftime("%Y-%m-%d %H:%M"))
print("JST:", t.astimezone(timezone(timedelta(hours=9))).strftime("%Y-%m-%d %H:%M"))

出力：UTC: 2026-03-02 17:40、JST: 2026-03-03 02:40。

なぜ誤りか：末尾の Z はUTCを表します。日本時間では翌日の深夜2時40分で、通常の業務時間外です。日付まで変わるため、日別の集計もずれます。

直し方：ログを読む・集計する前に、時刻のタイムゾーンを確認し、報告書ではタイムゾーンを明記する（「JST」「UTC」）。集計の日付の区切りをどちらで行うかも決めておく。

失敗3：調査のためにログへ秘密情報や個人情報を書く

誤った実装：認証エラーの原因を調べるため、アプリのログにリクエスト全体を出力した。

# 誤り：パスワードやトークン、メールアドレスがログに残る
log.info(f"login failed: {request_body}")
# request_body = {"email": "user@example.com", "password": "…", "token": "…"}

なぜ誤りか：ログは多くの人が読め、長く保存され、別のシステムに転送されます。秘密情報が残れば、ログを読めるすべての人が認証情報を得られます。個人情報は、必要以上に複製されることになります。

直し方：ログに書く項目を決めておく（例：時刻、要求ID、仮名化した利用者ID、結果、エラーの種類）。パスワード・トークンは絶対に書かず、出力前に伏せ字にする処理（「鍵と秘密情報」（有料版））を通す。誤って書いてしまった場合は、秘密情報を失効・再発行し、ログの扱いを漏洩時の手順（「漏洩時の対応」（有料版））に沿って判断する。

まとめ

• 責任共有モデル：提供者はクラウドそのもの、利用者はクラウドに置くもの（データ・権限・設定・アプリ）を守る。
• 公開設定・共有範囲・権限・データの分類・ログの有効化は、IaaS・PaaS・SaaSのすべてで利用者の責任。
• 公開は例外。まずデータ区分で可否を判断し、公開するなら理由・承認・見直し日を記録する。
• 監査ログは時刻・主体・操作・資源・結果を読む。UTCは日本時間に直し、拒否された試行や記録の停止も確認する。
• ログに秘密情報や不要な個人情報を書かず、別の権限・別の場所で保護し、保存期間を決める。

用語

責任共有モデル（shared responsibility model）

クラウドの安全と運用の責任を、提供者（クラウドそのもの）と利用者（クラウドに置くもの）で分担する考え方。

公開設定（public access setting）

保存場所やファイルを、認証なしで誰でも読める状態にするかどうかの設定。

監査ログ（audit log）

設定変更や権限付与など、資源の管理操作を記録したログ。

データアクセスログ（data access log）

データの読み書きを、誰がいつ行ったか記録したログ。

UTC（協定世界時）（Coordinated Universal Time）

世界共通の基準時刻。日本時間はUTC＋9時間。

よくある質問

なぜ責任の境界を表にする必要があるのですか？

「誰かがやっているはず」の項目が生まれるのを防ぐためです。提供者・委託先・自社の情報システム部門・分析チームのように関係者が増えるほど、OSの更新、ログの確認、権限の棚卸しなどが抜けやすくなります。表にして担当者名まで書くと、抜けが見えるようになります。

監査ログとアプリケーションログの違いは何ですか？

監査ログはクラウドの資源に対する管理操作（設定変更・権限付与など）を提供者の仕組みが記録するもの、アプリケーションログは自分のアプリが自分で書く処理の記録です。事故調査では両方を時刻で突き合わせます。

ログの確認でどこを間違えやすいですか？

タイムゾーン（UTCと日本時間）の取り違え、拒否された操作を無視すること、サービスの主体（svc/）の操作を見落とすこと、記録の停止そのものを見逃すことです。読む前に「時刻の基準」「主体の種類」「結果の値」を確認します。

マネージドサービスに切り替えたら、確認すべき項目は減りますか？

OSの更新など一部は提供者に移りますが、公開設定・権限・データの分類・ログの有効化は残ります。新しいサービスは既定の設定が自分の要求と合っているか（公開範囲、記録の範囲）を必ず確認します。

仕事で公開設定の事故を見つけたら、まず何をしますか？

(1) 非公開に戻して拡大を止める、(2) 公開されていた期間と、その間の読み取り記録を確認する、(3) 公開した操作の主体と経緯を監査ログで特定する、(4) 漏洩時の手順（「漏洩時の対応」（有料版））に沿って報告・判断する、の順です。証拠となるログは消さずに保全します。

確認問題

次に学ぶこと

次は 費用と停止 で、クラウドの費用の内訳と、使い終わった資源の止め方・消し方を学びます。

漏洩が疑われるときの手順は 「漏洩時の対応」（有料版）、保存場所のアクセス制御と鮮度は 「鮮度とアクセス制御」（有料版）、ログ・メトリクス・トレースによる監視は 「ログ・メトリクス・トレース」（有料版） で深めます。