クラウドは便利です。でも「全部クラウドに預ける」は、もはやデフォルトの正解とは言い切れません。
2024〜2025年にかけて、主要クラウドの大規模障害と、クラウド上のデータ漏洩が立て続けに起きています。本稿ではその現実を踏まえつつ、機密データだけを自前（オンプレ / 自社境界内）に置き、ポータルはマルチクラウドで冗長化するというハイブリッドなセルフホスティングを勧めます。
対象読者は、SaaS / クラウド一本槍の構成に不安を感じ始めているエンジニアやアーキテクトです。
目次
- 最近のクラウド障害が示すこと
- セキュリティ事件が示すこと
- だから「全部クラウド」が危ない
- 勧めたい形：データ主権境界つきのセルフホスティング
- 昔よりはるかに小さい設備で足りる
- 構成の要点
- トレードオフ（正直に）
- どこから始めるか
- まとめ
最近のクラウド障害が示すこと
ここ1年あまりで、AWS / GCP / Azure / Cloudflare いずれも「制御プレーンや設定のバグ」で広範囲が止まりました。ハードウェア故障ではなく、自動化と設定伝播の失敗です。
| 時期 | 事業者 | 概要 | 示唆 |
|---|---|---|---|
| 2025-06 | GCP | Service Control（API認可・クオータ）の NPE でグローバルに 503。約3時間 | 認可レイヤ1本が落ちると、リージョン分散していても同時に止まる |
| 2025-10 | AWS | DynamoDB DNS 自動化のレース条件で us-east-1 が長時間影響（約15時間規模） | 「一番大きいリージョン」への集中は、AZ冗長でも救えない |
| 2025-10 | Azure | Azure Front Door の設定不整合でエッジ全体が影響（数時間〜約9時間規模） | エッジ / 入口の単一障害点が、M365・管理ポータルごと巻き込む |
| 2025-11 | Cloudflare | Bot Management 由来の欠陥でグローバル障害（約6時間） | CDN / 入口も「全部預け」だと自社ブログまで道連れになる |
共通しているのは次の点です。
- 障害の震源はデータプレーンより制御プレーン（DNS、IAM、設定配信、エッジ設定）
- 単一プロバイダ内のマルチAZ / マルチリージョンでは足りないケースがある
- 復旧時間は「数十分」ではなく「数時間〜半日」になり得る
「うちはマネージドだから大丈夫」は、障害の原因がマネージド側の自動化である以上、通用しません。
セキュリティ事件が示すこと
可用性だけでなく、データがクラウドに集約されていること自体が攻撃面になっています。
Snowflake 顧客テナントへの大規模侵害（2024）
Mandiant が追跡した UNC5537 などによるキャンペーンでは、Snowflake 本体の脆弱性ではなく、窃取済み認証情報 + MFA 未強制の顧客テナントが次々と侵害されました。AT&T や Ticketmaster など、影響は広く報じられています。
教訓はシンプルです。
- クラウド上に「分析しやすい形で全部載せたデータ」は、認証が破られた瞬間に丸ごと持ち出される
- プラットフォーム側が無事でも、テナント境界の外側で盗まれたクレデンシャルで十分に落ちる
Change Healthcare（2024）
米国の医療請求基盤がランサムウェアで長期間麻痺し、影響を受けた個人情報は後に約1.9億人規模と報じられました。侵入経路のひとつは、MFA のないリモートアクセスでした。
クラウドかオンプレかの二項対立ではなく、「認証・境界・データの置き場」を設計し損ねると、インフラの種類を問わず致命傷になります。ただしクラウドに集約していると、被害の半径（blast radius）がテナント全体・顧客全体に広がりやすいのは事実です。
だから「全部クラウド」が危ない
障害とセキュリティを並べると、全部クラウド構成の弱点はこう整理できます。
| 全部クラウドの前提 | 現実 |
|---|---|
| プロバイダが可用性を保証する | 制御プレーン障害で数時間〜半日止まり得る |
| マルチAZで十分 | us-east-1 やグローバル制御系は AZ をまたいで落ちる |
| データは暗号化してあるから安心 | 正規クレデンシャルでのログインには効かない |
| IdP もマネージドで楽 | IdP 障害 = 全サービスログイン不能。しかも IdP に PII が集まる |
逆に、全部オンプレに戻すのも現代的ではありません。スケール、CDN、WAF、デプロイ速度でクラウドの利点は大きい。
なので勧めるのは 全部自前 でも 全部クラウド でもなく、次の分割です。
機密（認証情報・PII・マスタ）は自社境界内にセルフホストし、公開面のポータルだけをクラウド（できれば複数）に置く。
勧めたい形：データ主権境界つきのセルフホスティング
全体像は次の図です。
Portal + Multi-cloud Integrated Architecture（Data Sovereignty Ready）
ざっくり言うと3層です。
Internet / Users
↓ dual-provider GSLB（ヘルスチェックでどちらのクラウドへでも）
Cloud A (GCP) ⇄ Cloud B (AWS) ← 非機密のみ / active-active
↓ 冗長 VPN（OIDC 委任・暗号化トラフィックのみ）
On-premises ← 認証情報・PII・マスタは外に出さない
クラウドは「見せる・つなぐ」役、オンプレは「守る・正とする」役です。これを本稿ではセルフホスティングの実務的な形として推します。
昔よりはるかに小さい設備で足りる
「オンプレに戻す = かつての電算室を再建する」というイメージが、いまも意思決定を止めがちです。実際は、企業内に置くセルフホスティング設備は、10〜15年前と比べて桁違いに小さくて済みます。
理由は単純で、自前に残す範囲が変わったからです。
| 昔のオンプレ回帰 | いま勧めるセルフホスト | |
|---|---|---|
| 置くもの | Web・AP・DB・バッチ・ファイル・メール…ほぼ全部 | IdP・機微 DB・Writer / Sanitized Reader・監査など 機密パスだけ |
| 公開トラフィック | 自社回線・自社LBで受ける | クラウド側（WAF / SPA / BFF）が受ける |
| スケールの主戦場 | ラックを増やす | クラウド側で水平スケール。オンプレはスループットの天井設計 |
| ミドルウェア | 高価な商用スタック、専任運用 | コンテナ（k3s 等）+ Postgres + Ory 系など クラウドと同じ道具 |
| 物理イメージ | サーバルーム一式 | 冗長構成でも 数台〜片手で数えられるノード で足りる規模感 |
ポイントは次の3つです。
-
境界内に置くのは「正」と「鍵」だけ
ポータル UI / BFF / WAF はクラウドに出せるので、オンプレの CPU・帯域・ストレージは昔の全社システムほど要らない。 -
ソフトウェアの密度が上がった
かつてはアプライアンスや巨大ミドルウェアが占めていた IdP・API・DB が、いまはコンテナ数個に収まる。同じラック面積で扱える論理機能が違う。 -
運用モデルをクラウドと揃えられる
IaC・GitOps・Observable なスタックで境界内も載せられるので、「オンプレ専用の別世界」を新規に抱えなくてよい。
もちろん可用性のためにノード冗長・電源・回線の二重化は必要です。それでも「全業務システムを自社データセンターに載せる時代」の CAPEX / スペースとは別物です。
機密だけを小さく自前に置き、伸びる部分はクラウドに任せる——この分割ができるからこそ、いまセルフホスティングを勧められます。
構成の要点
1. オンプレ（データ主権境界）
ここに置くものだけを明確にします。
| コンポーネント | 役割 |
|---|---|
| IdP（例: Ory Hydra + Kratos） | OIDC / OAuth2 の発行元。ログインの正 |
| MFA / Passkeys（Kratos） | 認証強化。クレデンシャル単体突破を防ぐ |
| ID / User DB | 機微なユーザ属性 |
| Writer API | 書き込みの唯一の入口 |
| Core Data | マスタの source of truth |
| Sanitized Reader | クラウドへ返す前のフィールド allowlist |
| Audit Log | 改ざん耐性のある監査証跡 |
| Importer / Analysis | 取り込みと分析（機微データ近傍で実施） |
原則はひとつです。
credentials / PII / master data は境界の外に出さない。
クラウドに渡すのはトークンと、サニタイズ済みの読み取り結果だけです。JWT に PII を載せない（参照 ID 方式）、ログもマスク、という運用がセットになります。
2. クラウド（ポータルだけ、非機密だけ）
| Cloud A (GCP) | Cloud B (AWS) | |
|---|---|---|
| WAF | Cloud Armor | AWS WAF |
| UI | Cloud Storage 上の SPA | S3 上の SPA |
| API / BFF | Cloud Run | App Runner |
両方とも non-sensitive only。どちらか一方のクラウドが落ちても、もう一方でポータルを継続できるように active-active にします。
3. つなぎ方
- 冗長 VPN ×2（active-active）
- 渡るのは OIDC / OAuth2 の委任と、暗号化されたデータ同期だけ
- インターネット側は 中立な dual-provider GSLB（単一 DNS 事業者に寄せない）
DNS 障害でフリート全体が落ちた例は Dyn（2016）や Akamai（2021）など、何度も起きています。マルチクラウドにしても、入口の DNS が単一なら意味が半減します。
トレードオフ（正直に）
図中の Caveats はそのまま設計上の負債です。隠さずに書いておきます。
-
ログインと読み取りは毎回 VPN を跨ぐ
トンネルは冗長でも、オンプレサイト自体が落ちればポータル全体が止まる。 -
スループットの天井は IdP と Sanitized Reader
クラウド側をいくらスケールしても、境界内の読み出しがボトルネックになる。 -
サニタイズこそが主権の実体
allowlist 以外を返さないこと。join や集計で再識別できる設計にしてはいけない。 -
クラウド側キャッシュは楽だが、主権の主張を弱める
「一時的に非機密だけキャッシュ」と「実質マスタをクラウドに複製」は紙一重。 -
active-active は条件付き
- 中立 dual-provider GSLB、またはクライアント側フォールバック
- 各クラウドが単体で 100% トラフィックを捌けるサイズ
- 両スタック常時ホット
- 決済・プッシュ・レジストリ・監視などを単一クラウドに依存しない
「マルチクラウドにした」と言うだけでは足りず、単一障害点を意識的に潰す必要があります。
どこから始めるか
全部を一気にやると死にます。優先度は次の順が現実的です。
Phase 1 — データを分ける
- PII / 認証情報 / マスタをクラウド DB から剥がす
- 参照 ID 化し、JWT・ログから個人情報を除去する
- 「クラウドに残してよいフィールド」の allowlist を文書化する
Phase 2 — IdP を自前に寄せる
- マネージド IdP の便利さは残しつつ、機微属性とクレデンシャルの正は自社境界へ
- MFA / Passkeys をデフォルト強制（Snowflake 型の事故を正面から潰す）
- 監査ログを境界内に残す
Phase 3 — ポータルをマルチクラウド化
- SPA + BFF を第2クラウドへ複製
- GSLB またはクライアントフォールバック
- 監視・コンテナレジストリ・シークレットの単一クラウド依存を洗い出す
個人の趣味サーバなら、まず「認証とデータだけ自宅 / VPS 自前、フロントはどこでもよい」でも十分セルフホスティングの精神です。企業システムの場合は、上の Phase がそのままロードマップになります。
まとめ
- 最近の障害は「クラウドが未熟だから」ではなく、制御プレーンに集約した巨大システムの宿命として起きている
- セキュリティ事件は、クラウドに集めたデータが 正規認証の突破で一気に流出することを示している
- だから勧めるのは、レトロな全オンプレ回帰ではなく、
機密のセルフホスティング + 公開面のマルチクラウド という分割 - 自前設備は昔より大幅に小さくて済む——置く範囲を機密パスに絞れるから
- 成功条件はマルチクラウド宣言ではなく、データ主権境界・サニタイズ・中立 GSLB・単一依存の排除
クラウドを捨てる話ではありません。クラウドに 預けてはいけないもの を、もう一度——しかも昔より小さな設備で——自分の手に戻す話です。