In Silico

クラウド

IaaS・PaaS・SaaSの違いを代表例と責任の範囲でわかりやすく解説

2026/10/13 （更新: 2026/10/13） シリーズ「クラウド入門」 第2回 / 全4回

🤖 AIを使用して執筆

  • IaaS・PaaS・SaaS
  • IaaS
  • PaaS
  • SaaS
  • 責任共有モデル
  • クラウド
  • 責任分界
  • NIST
  • AWS
  • Azure
  • Google Cloud
  • Amazon EC2
  • Amazon S3
  • Azure App Service
  • App Engine
  • Microsoft 365
  • Salesforce
  • 運命の共有
  • 多要素認証
  • 設定不備
  • 仮想マシン
  • ASP
  • セキュリティ
  • アクセス管理
目次
背景・問い・要点
背景

クラウドは、計算資源を必要なときに必要な分だけ借りる仕組みである。ただ、「借りる」といっても、借りるものの大きさはさまざまである。機械だけを借りて OS から上を自分で入れることもあれば、アプリを動かす土台まで借りることも、出来上がったアプリそのものを借りることもある。この違いを表すのが、IaaS・PaaS・SaaS という三つの言葉である。

借りる範囲が変わると、何かが壊れたり破られたりしたときに、誰が直すのかも変わる。この分担を、クラウドの事業者は責任共有モデルと呼んで説明している。本稿は、ある小売の会社の注文受付のアプリを、IaaS・PaaS・SaaS の三通りに載せる例を取り、三つのモデルの違いと代表例を、米国国立標準技術研究所（NIST）の定義と各社の責任共有モデルをもとに説明する。

問い

IaaS・PaaS・SaaS は何が違い、それぞれの代表例は何か。借りた部分で事故が起きたとき、どこまでが事業者の責任で、どこからが利用者の責任なのか。

要点

IaaS・PaaS・SaaS の違いは、事業者がどの層まで管理するかの違いで、SaaS に近いほど利用者が管理する範囲は狭くなる。ただし、データ、アカウント、アクセスの管理はどのモデルでも利用者の責任で、線の位置はサービスごとに違う。 IaaS では、利用者が仮想マシン（一台の機械の中にソフトウェアで作った機械）の OS から上を管理する。PaaS では、OS とミドルウェア（データベースのように、OS とアプリの間で働くソフトウェア）を事業者が管理し、利用者は自分のアプリとその設定を管理する。SaaS では、アプリまで事業者が管理し、利用者はアカウントやデータの設定を管理する。AWS、Microsoft、Google Cloud の三社と総務省は、この分担を責任共有モデルとして示している。どの文書も、線の位置は使うサービスによって違うと書き、総務省は利用の条件や契約によっても変わるとしている。クラウドでは、利用者が事業者の担当者とやり取りせずに資源を用意し、設定を変えられる。その分、設定が適切かどうかを確かめるのは、主に利用者の仕事になる。2024 年には、Snowflake の利用者が相次いでデータを盗まれた。調査にあたった Mandiant によると、攻撃者は事業者の基盤を破ったのではなく、多要素認証を設定していない利用者のアカウントから入っていた。

モデル・例示

同じ注文受付のアプリを三通りに載せる

※ この節の数値は説明のための仮定で、測定値ではありません。

ここでは、オンラインと実店舗で商品を売る、ある小売の会社を例に考える。この会社は、注文受付のアプリを社内のサーバー室で動かしている。機械は、アプリのサーバー、注文と在庫を記録するデータベースのサーバー、商品の画像と領収書の PDF を置くファイルサーバーの三つである。サーバー室では、建物の鍵から、機械、OS、データベース、アプリ、社員のアカウントまで、すべてを会社が管理している。

このアプリをクラウドに載せる方法は、大きく三つある。

  • IaaS に載せる：事業者から仮想マシンを借り、そこに OS、データベース、アプリを自分で入れる。サーバー室の機械を、借りた機械に置き換える形である。
  • PaaS に載せる：アプリの実行と、データベースの運用を、事業者のサービスに任せる。会社は自分のアプリのプログラムと、注文と在庫のデータを預ける。商品の画像と PDF は、事業者の保存のサービスに置く。
  • SaaS に乗り換える：自前のアプリをやめ、ネットショップを開くための出来上がったサービスを月額で借りる。会社は商品と注文のデータを登録し、社員のアカウントを作る。

三つの違いが表に出るのは、何かが起きた日である。たとえば、広く使われている OS に弱点が見つかり、修正が公開された日と、社員のパスワードが盗まれた日を考える。

  1. 事業者会社の担当者1. OS の弱点の修正が公開されたと知らせる
  2. 会社の担当者借りた環境2. IaaS では、借りた仮想マシンの OS に自分で修正を当てる
  3. 事業者借りた環境3. PaaS と SaaS では、事業者が OS とミドルウェアに修正を当てる
  4. 会社の担当者借りた環境4. どのモデルでも、社員のアカウントに多要素認証を設定する
  5. 会社の担当者借りた環境5. どのモデルでも、誰がどのデータを見てよいかを決める
※概念図（やりとり）：本文の手順を図式化したもの。

OS の修正は、IaaS では会社の仕事で、PaaS と SaaS では事業者の仕事になる。一方で、パスワードが盗まれたときの備えは、三つのどれを選んでも会社の仕事である。多要素認証は、パスワードに加えて、手元のスマートフォンなど別の手段でも本人を確かめる仕組みで、パスワードだけが盗まれても入られにくくする。借りる範囲を広げるほど会社の仕事は減るが、ゼロにはならない。

IaaS・PaaS・SaaS の違い：NIST の定義

三つのモデルは、NIST が 2011 年に公開したクラウドの定義の文書で、サービスモデルとして定められている1。日本語では、情報処理推進機構（IPA）の訳がある2。NIST は三つのモデルを、利用者が何を管理し、何を管理しないかで分けている。

三つを並べると、IaaS、PaaS、SaaS の順に、下の層から事業者の側へ移っていく。利用者が管理するのは、IaaS では OS から上、PaaS では自分のアプリとその設定、SaaS では利用者ごとの設定だけになる。モデルの名前の「as a Service」は、その層をサービスとして借りる、という意味である。

ただし、NIST の定義は、利用者が何を管理できるかを定めたもので、事故が起きたときに誰が責任を負うかは書いていない。分担を「責任」という言葉で説明しているのは、主に事業者の文書である。

AWS・Azure・Google Cloud での代表例

三社の主なサービスを、各社が自社の文書で示している分類に従って並べる。

並べると、分類が会社によってずれる箇所がある。データを保存するサービスは、Google は Cloud Storage を IaaS に、Microsoft は Azure Storage を PaaS に置き、AWS は S3 を「抽象化されたサービス」と呼ぶ。関数を動かすサービスも、Microsoft は Azure Functions を PaaS に置き、Google Cloud は FaaS（サーバーレス）という別の区分を立てて、責任の分担は SaaS に近いとしている45。三つのモデルは、サービスをきれいに3つの箱に分けるものではなく、利用者が何を管理するかの目安である。

三つのサービスモデルが現れた順序

三つのサービスモデルは、同時に現れたわけではない。先に現れたのは、アプリをまるごと貸す形である。2000 年前後には、アプリを自社のデータセンターから回線越しに貸す事業者があり、ASP（アプリケーション・サービス・プロバイダ）と呼ばれた8。米国のソフトウェアの業界団体 SIIA は 2001 年 2 月の文書で、ASP をはじめ似た呼び名が乱立しているので、混乱を避けるために、まとめて Software as a Service と呼ぶと書いている8。Salesforce は 2000 年 2 月に、「ソフトウェアの終わり」を掲げた催しで正式にサービスを公開した9。

機械を貸す形が広く知られたのは、2006 年 8 月に Amazon EC2 がベータとして始まってからである10。アプリを動かす土台を貸す形は、その後に続いた。Heroku は 2007 年に創業し、Salesforce による買収の発表は、Heroku を platform-as-a-service と呼び、「仮想マシンを管理する必要も、ソフトウェアを入れる必要も、ハードウェアを管理し調整する必要もない」と説明している11。Google は 2008 年 4 月に、自社の基盤の上でウェブのアプリを動かせる App Engine を、最初の 1 万人の開発者に向けたプレビューとして公開した12。

三つのサービスモデルは、こうして別々の時期に、別々の会社のサービスとして現れた。NIST の 2011 年の定義は、それらを、利用者が何を管理するかという一つの軸の上に並べ直したものと言える。

責任共有モデルとは

責任共有モデルとは、クラウドのセキュリティと運用の責任を、事業者と利用者で分けて持つという考え方である。AWS は、自社の責任を「クラウドのセキュリティ」、利用者の責任を「クラウドにおけるセキュリティ」と呼び分けている3。AWS は、すべてのサービスを動かすハードウェア、ソフトウェア、ネットワーク、施設を守り、利用者は、その上に自分が載せたものと設定を守る、という分け方である3。

この分け方は、言葉より先にあった。仮想マシンでは、事業者が物理的な機械の上で動かす OS をホストの OS、借りた仮想マシンの中で利用者が動かす OS をゲスト OS と呼ぶ。AWS の 2008 年 9 月のセキュリティの白書は、仮想マシンは利用者が完全に制御し、AWS の管理者は利用者のゲスト OS にログインできない、とすでに書いている13。この白書のうち、「責任共有」という言葉を確認できた最も古い版は、2010 年 8 月の版である14。その版は、EC2 を使う利用者について、AWS はホストの OS と仮想化の層から施設の物理的なセキュリティまでを運用し、利用者はゲスト OS（更新とセキュリティの修正を含む）と、その上のアプリ、ファイアウォールの設定を担う、と書いている14。今の AWS のページの説明は、この段落をほぼそのまま受け継いでいる3。

Microsoft も、同じ分担を、オンプレミス、IaaS、PaaS、SaaS の4つの列に分けて示している4。物理的なホスト、ネットワーク、データセンターは、IaaS から先は Microsoft の責任になる。OS は、PaaS から先は Microsoft の責任になる。アプリは、PaaS と SaaS では Microsoft と利用者が分けて持つ。ネットワークの制御は、PaaS では分けて持ち、SaaS では Microsoft の責任になる4。そして、どの配置でも利用者が常に持つ責任として、データ、端末、アカウント、アクセス管理の4つを挙げている4。

日本では、総務省が 2022 年 10 月に公開したガイドラインが、事業者と利用者が責任を共有するこの考え方を責任共有モデルと呼び、多くの事業者が採用していると説明している15。同じガイドラインは、SaaS ではアプリの動作に関わる設定は事業者が責任を負い、利用者のアカウントや業務のデータの設定は利用者の責任になるとし、IaaS では OS を含むすべてのソフトウェアの管理が利用者の責任になるとしている15。

線はサービスごとに動く

三つのモデルの線は、きれいに3本に分かれているわけではない。AWS は、利用者の責任は選んだサービスによって決まると書き、例を二つ挙げている3。IaaS に分類される EC2 では、利用者はゲスト OS の更新、自分で入れたアプリ、ファイアウォールの設定まで管理する。一方、ストレージの S3 やデータベースの DynamoDB のような「抽象化されたサービス」では、AWS が OS とプラットフォームまで運用し、利用者は自分のデータの管理、暗号化の選択、権限の設定を担う3。同じ AWS の中でも、サービスによって線の位置が変わる。

Google Cloud も、PaaS では IaaS より多くの管理を Google が担うが、その範囲は使うサービスと機能によって変わると書いている5。総務省のガイドラインは、責任の範囲と内容は一律に決まらず、サービスの内容や利用の条件ごとに違うので、事業者の免責事項などで責任分界を確かめる必要がある、としている15。日本に多い形として、システム開発の会社（SI 事業者）が利用者と事業者の間に入る場合には、分担がさらに複雑になるので、契約でよく確かめるよう勧めている16。同じガイドブックは、SI 事業者が行った設定であっても、最終的な責任は利用者が負うとしている16。

Microsoft は、自社の表の「責任」は、誰が設定し、運用し、監視するかという意味で使っており、法的な結論を示すものでも、契約の条件を変えるものでもない、と断っている4。責任共有モデルの図は、分担を理解するための見取り図であり、最終的な線は、それぞれのサービスの文書と契約が決める。

どのモデルでも利用者の責任になるもの

線の位置はサービスごとに違うが、一つだけ、各社と政府機関の文書がそろって同じことを書いている点がある。データ、アカウント、アクセスの管理は、どのモデルでも利用者の責任だということである。Microsoft は、データ、端末、アカウント、アクセス管理を、配置の種類に関係なく利用者が常に持つ責任として挙げる4。Google Cloud も、事業者は常に基盤のネットワークとインフラストラクチャに責任を持ち、利用者は常に自分のアクセスの方針とデータに責任を持つと書く5。米国国家安全保障局（NSA）の 2024 年の文書も、どのモデルでも利用者は通常、データ、端末、アカウントの安全と、アクセス制御の方針を管理する、としている17。日本の政府の方針も、政府のシステムについて、利用する側の責任を、業務のアプリ、利用者の端末、運用、クラウドの設定、アカウントなどに限っている18。

この点が実際に問題になったのが、2024 年の Snowflake の事件である。Snowflake は、大量のデータを保存して分析するためのデータウェアハウスのサービスで、複数のクラウドの上で動く7。Google の Mandiant は、攻撃者が盗んだ利用者の認証情報（ログインに使う名前とパスワードなど）を使って、Snowflake の利用者の環境に次々と入り込んでいると報告した7。Mandiant と Snowflake は、被害を受けたおそれのある組織として、約 165 の組織に通知した7。Mandiant が対応した事件は、どれも原因をたどると、Snowflake の社内の環境が破られたことではなく、盗まれた利用者の認証情報に行き着いた7。入り込まれたアカウントには多要素認証が設定されておらず、正しい名前とパスワードだけで入れた7。認証情報は、主に、Snowflake の所有でない端末に入り込んだ情報窃取のマルウェア（端末に保存されたパスワードなどを盗むプログラム）から盗まれており、何年も変えられていないものもあった7。Mandiant は侵入が相次いだ主な要因を三つ挙げており、残る一つは、信頼できる場所からの接続だけを許すネットワークの許可リストを、被害を受けた利用者の環境に置いていなかったことである7。

Snowflake の側でも、元社員のデモ用のアカウントに攻撃者が入っていたことが分かっている。ただし、そのアカウントは本番の仕組みにつながっておらず、機密のデータもなかったと Snowflake は説明している19。注文受付のアプリでいえば、SaaS に乗り換えても、社員のパスワードが盗まれ、多要素認証がなければ、注文と顧客のデータは持ち出されうる。SaaS は OS の修正を事業者に移すが、アカウントとアクセスの管理は移さない。

なぜ誤解が起きるのか：人の手を通らない設定

NIST が挙げるクラウドの特徴の一つ、オンデマンド・セルフサービスは、利用者が事業者の担当者とやり取りせずに、計算資源を自分で用意できることを指す1。これは利点であると同時に、設定が適切かどうかを、事業者の担当者が一件ずつ確かめる段階がないことも意味する。NSA は、クラウドの事業者の基盤は高度に自動化されていて、利用者に言われたことを、事業者の側の人の確認なしにそのまま実行すると書いている17。

そのうえで NSA は、利用者は、本来は事業者の責任でない部分まで事業者が守っていると思い込みがちだと指摘する17。2020 年の NSA の文書も、クラウドの資源の設定の誤りは今も最も多い弱点で、方針の誤りや責任共有の誤解からしばしば生じると書いている20。総務省のガイドラインは、日本でも、クラウドを使う事業者の設定不備から顧客の個人情報が流出するおそれのある事案が増えていると、冒頭で述べている15。

数字で示されることも多いが、性質の違う数字が混ざっている。調査会社の Gartner は 2019 年に、2025 年までのクラウドのセキュリティの失敗の 99% は利用者の過失になると書いた21。これは予測であり、実際の事故を数えた結果ではない。総務省のガイドラインが引く IPA の届け出の集計では、不正アクセスの原因のうち設定の不備は約 17.7% で第3位だったが、これはクラウドに限らない不正アクセス全体の数字である15。設定の誤りが重い問題だという点では各文書が一致しているが、クラウドの事故の何割が利用者の側から起きるかを測った中立の数字は、確かめられていない。

外から見た責任共有モデル

責任共有モデルを支持する見方は、分担をはっきりさせることに価値を置く。NSA の 2024 年の文書は、題そのものが「クラウドの責任共有モデルを守れ」であり、事業者の文書と利用規約が分担を示しているので、利用者はそれを理解して自分の側の対策を取るよう求めている17。日本の政府の方針も、責任分界を合理的に定めたうえで、サーバーや OS のセキュリティを信頼できる事業者に任せれば、利用者はサービスの利用に集中できると書いている18。

留保を付ける見方は、線を引くだけでは足りないと考える。三社の中で立場がはっきり分かれるのが、Google Cloud である。Google は、責任共有モデルでは利用者がより良いセキュリティの結果を得るのに十分でないとして、「運命の共有（shared fate）」を掲げている5。責任共有モデルを理解するには、使うサービスごとの設定の選択肢と、事業者が何をしているかを深く知る必要があり、最適な設定を決めるのは難しい、というのがその理由である5。多くの企業は複数の種類のサービスを組み合わせて使っており、セキュリティの事故への対応のように、どちらの責任かを簡単に定められない領域もあると Google は書く5。そのうえで、安全な初期の構成を用意し、推奨する設定をはっきり示し、保険会社と組んだサイバー保険の仕組みを提供すると説明している5。運命の共有は責任共有モデルの上に築くものだと Google は書くが、目指すのは、標準の責任共有の枠組みから、より良いモデルへ進むことだとしている5。

もう一つは、事業者が、利用者の設定に任せていた対策を義務づける方向に動き出した例である。Snowflake は事件の直後、特に強い権限を持つ利用者のアカウントについて、多要素認証やネットワークの制限のような対策を利用者に義務づける計画を立てていると発表した19。その後、パスワードでログインする人のアカウントすべてに二つ目の認証を求める段階的な計画を公開し、ウェブの操作画面である Snowsight では 2025 年 9 月から 2026 年 1 月にかけて、例外なく必須にする予定を示している22。同じ動きは大手のクラウドにもある。Microsoft は 2024 年 10 月から、Azure の管理画面で操作するアカウントに多要素認証を必須にした23。AWS は 2024 年半ばから組織の管理アカウントのルートユーザーに多要素認証を求めると発表し、Google Cloud は 2025 年 5 月から、Google Cloud で使う個人の Google アカウントに二段階認証を求めている2425。

総務省のガイドラインも、片側だけを責めてはいない。設定の不備は、直接には利用者の単純なミスと考えることもできるが、真の原因を考えると、利用者の側の理解不足や管理の体制の不十分さと、事業者の側の情報やツールの提供不足、ミスを起こしにくい設計への配慮不足が、重なり合って起きていると考えられる、としている15。そのうえで、利用者と事業者の双方が、自分の責任の範囲と役割を理解し、共通の認識にすることを求めている15。

並べると、どの見方も、データ、アカウント、アクセスの管理が利用者の責任だという点は争っていない。違いは、その責任を果たすために、事業者がどこまで手を貸すべきかにある。注文受付のアプリでいえば、IaaS・PaaS・SaaS のどれを選んでも、会社が最初に決めなければならないのは、誰がどの操作をしてよいかである。この「誰が何をしてよいか」をクラウドの上でどう決めるのかが、次の問いである。

出典25件

  1. Peter Mell, Timothy Grance「The NIST Definition of Cloud Computing」NIST SP 800-145、2011年9月、2026年10月13日取得. https://csrc.nist.gov/pubs/sp/800/145/final — 三つのサービスモデルと、オンデマンド・セルフサービスの定義。 ↩ ↩2

  2. IPA 訳「NIST によるクラウドコンピューティングの定義」2011年12月掲載、2026年10月13日取得. https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/begoj9000000buyd.pdf — SaaS・PaaS・IaaS の訳。 ↩ ↩2 ↩3 ↩4

  3. AWS「責任共有モデル」2026年10月13日取得. https://aws.amazon.com/jp/compliance/shared-responsibility-model/ — クラウドのセキュリティとクラウドにおけるセキュリティ、EC2 と S3・DynamoDB の例。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  4. Microsoft「Shared responsibility in the cloud」2026年8月24日更新、2026年10月13日取得. https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility — 4列の分担表と、常に利用者が持つ4つの責任。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  5. Google Cloud「Shared responsibilities and shared fate on Google Cloud」2023年8月21日確認、2026年10月13日取得. https://cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate — 運命の共有。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11

  6. Salesforce「Our Story」2026年10月13日取得. https://www.salesforce.com/company/our-story/ — 1999年、SaaS の先駆けとする自社の説明。 ↩

  7. Mandiant「UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion」2024年6月11日、2026年10月13日取得. https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  8. SIIA「Software as a Service: Strategic Backgrounder」2001年2月、2026年10月13日取得（アーカイブ）. https://web.archive.org/web/20090304134636id_/http://www.siia.net/estore/ssb-01.pdf — ASP などの総称として SaaS と呼ぶ。 ↩ ↩2

  9. Salesforce「The History of Salesforce」2025年1月更新、2026年10月13日取得. https://www.salesforce.com/news/stories/the-history-of-salesforce/ — 2000年2月7日「The End of Software」で開始（同社の回顧）。 ↩

  10. AWS「Announcing Amazon Elastic Compute Cloud (Amazon EC2) - beta」2006年8月24日、2026年10月13日取得. https://aws.amazon.com/about-aws/whats-new/2006/08/24/announcing-amazon-elastic-compute-cloud-amazon-ec2---beta/ — ベータ版の開始の告知。 ↩

  11. Salesforce「Salesforce.com Signs Definitive Agreement to Acquire Heroku」2010年12月8日、2026年10月13日取得. https://www.salesforce.com/news/press-releases/2010/12/08/salesforce-com-signs-definitive-agreement-to-acquire-heroku/ — 2007年創業。 ↩

  12. Google App Engine Blog「Introducing Google App Engine + our new blog」2008年4月7日、2026年10月13日取得. https://googleappengine.blogspot.com/2008/04/introducing-google-app-engine-our-new.html — プレビュー版。 ↩

  13. AWS「Overview of Security Processes」2008年9月、2026年10月13日取得（アーカイブ）. https://web.archive.org/web/20080906113916id_/http://s3.amazonaws.com/aws_blog/AWS_Security_Whitepaper_2008_09.pdf — ゲスト OS は利用者が制御。 ↩

  14. AWS「Amazon Web Services: Overview of Security Processes」2010年8月、2026年10月13日取得（アーカイブ）. https://web.archive.org/web/20101012000304id_/http://awsmedia.s3.amazonaws.com:80/pdf/AWS_Security_Whitepaper.pdf — 「Shared Responsibility Environment」。 ↩ ↩2

  15. 総務省「クラウドサービス利用・提供における適切な設定のためのガイドライン」2022年10月、2026年10月13日取得. https://www.soumu.go.jp/main_content/000843318.pdf — 責任共有モデル、SaaS・PaaS・IaaS の設定の分担、設定不備の真因。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  16. 総務省「クラウドの設定ミス対策 ガイドブック」2024年4月、2026年10月13日取得. https://www.soumu.go.jp/main_content/000944467.pdf — SI 事業者が入ると責任分担が複雑になり、その設定でも最終的な責任は利用者が負う。 ↩ ↩2

  17. NSA「Uphold the Cloud Shared Responsibility Model」2024年3月、2026年10月13日取得（アーカイブ）. https://web.archive.org/web/20240311090653id_/https://media.defense.gov/2024/Mar/07/2003407863/-1/-1/0/CSI-CloudTop10-Shared-Responsibility-Model.PDF ↩ ↩2 ↩3 ↩4

  18. デジタル庁 DS-310「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」2025年5月27日、2026年10月13日取得. https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/a612d406/20250619_resources_standard_guidelines_guideline_08.pdf — 責任共有モデル。 ↩ ↩2

  19. Snowflake（Brad Jones, CISO）「Detecting and Preventing Unauthorized User Access」2024年5月31日、2026年10月13日取得. https://snowflake.discourse.group/t/detecting-and-preventing-unauthorized-user-access/8967 — 多要素認証の義務化の計画。 ↩ ↩2

  20. NSA「Mitigating Cloud Vulnerabilities」2020年1月22日、2026年10月13日取得（アーカイブ）. https://web.archive.org/web/20200123181435id_/https://media.defense.gov/2020/Jan/22/2002237484/-1/-1/0/CSI-MITIGATING-CLOUD-VULNERABILITIES_20200121.PDF ↩

  21. Gartner「Is the Cloud Secure?」2019年10月10日、2026年10月13日取得（アーカイブ）. https://web.archive.org/web/20210108070908/https://www.gartner.com/smarterwithgartner/is-the-cloud-secure — 2025年までの予測。 ↩

  22. Snowflake「Planning for the deprecation of single-factor password sign-ins」2026年10月13日取得. https://docs.snowflake.com/en/user-guide/security-mfa-rollout — 人の利用者への多要素認証の必須化の段階と予定時期。 ↩

  23. Microsoft「Mandatory multifactor authentication for Azure and admin portals」2026年4月3日更新、2026年10月13日取得. https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication — 2024年10月からの管理画面での多要素認証の必須化。 ↩

  24. AWS Security Blog「Secure by Design: AWS to enhance MFA requirements in 2024」2023年10月3日、2026年10月13日取得. https://aws.amazon.com/blogs/security/security-by-design-aws-to-enhance-mfa-requirements-in-2024/ — 管理アカウントのルートユーザーへの多要素認証の要求。 ↩

  25. Google Cloud「2-step verification requirement for Google Cloud」2026年10月9日更新、2026年10月13日取得. https://cloud.google.com/docs/authentication/mfa-requirement — アカウントの種類ごとの二段階認証の要求の開始日。 ↩

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。