なぜMIXIはゼロトラスト基盤として クラウドフレアを選んだのか - Cloudflare Peer Point SASE User Voices

2026/7/23 Cloudflare Peer Point SASE User Voices で発表した内容です。
公開に当たっては、Cloudflare社の許可を得ています。

イベント詳細
https://fieldmarketing.www.cloudflare.com/special-peer-point-sase-user-voices

Transcript

1. なぜMIXIはゼロトラスト基盤として クラウドフレアを選んだのか 2026/07/23 Peer Point SASE User Voices 株式会社 MIXI / 開発本部 / たんぽぽ室 / 基盤システムグループ 多羽田 俊 株式会社 MIXI / はたらく環境推進本部 / コーポレート ITサービス部 / 環境整備グループ / 環境整備チーム 岡村 凌兵 ©MIXI
2. スピーカー紹介 多⽻⽥ 俊 / Shun Tabata 開発本部 / たんぽぽ室 / 基盤システムグループ 略歴‧担当領域 2021年に株式会社ミクシィ（現MIXI）に⼊社。主に会社の基盤システムの開発‧保 守‧運⽤や、プロジェクトへの DevOps ⽀援を⾏う。社内ITやセキュリティ室など とも連携し、全社で取り扱うシステムのエンジニアリングを担当。 ©MIXI 2
3. 会社概要 エモーションと コミュニケーションで 「⼼もつながる」場と機会を 創造し続けます。 MIXI GROUPは、ただ「つながればいい」という効率的な機能の提供ではなく、歓喜 や興奮、温かな思い、幸せ、居⼼地の良さの共有を通じて、その先に、もっと深くて 濃く豊かな、⼼のつながりを⽣み出すような、サービスの開発‧提供を⽬指していま す。 ライフスタイル事業 スポーツ事業 プロスポーツチーム運営および 公営競技ビジネスの推進 インターネットを活⽤し、 ⼈々の⽣活に密着したサービスの提供 3領域を中⼼に “「⼼もつながる」場と機会” を創造する事業を推進 デジタルエンターテインメント事業 現在、スポーツ‧ライフスタイル‧デジタルエンターテインメントの3領域を中⼼に事 業を展開しており、それぞれの主な事業内容は右の通りです。 スマホゲームを中⼼としたゲームの提供 また、近年の投資活動の拡⼤と重要性を勘案し、FY2023からはスタートアップやファ ンド出資等の投資活動を事業化しました。 ©MIXI 3
4. 会社概要 ©MIXI 会社名 株式会社MIXI（MIXI, Inc.） 所在地 〒150-6136 東京都渋⾕区渋⾕2-24-12 資本⾦ 9,698百万円(2026年3⽉末現在) 代表者 代表取締役社⻑ 上級執⾏役員 CEO ⽊村 弘毅 事業内容 デジタルエンターテインメント スポーツ ライフスタイル 投資 従業員数 2,116名（連結‧正社員のみ）※2026年3⽉末現在 主なグループ会社 株式会社チャリ‧ロト 株式会社スフィダンテ 株式会社千葉ジェッツふなばし 株式会社ネットドリーマーズ 東京フットボールクラブ株式会社 アイ‧マーキュリーキャピタル株式会社 株式会社MIXI EMPOWERMENT 株式会社ラブグラフ 株式会社picon PointsBet Holdings Limited 渋⾕スクランブルスクエア36F 4
5. 本⽇のアジェンダ ©MIXI 01 02 03 04 05 06 課題 検討‧選定 導⼊ タイムライン 利⽤パターン 導⼊トラブル 導⼊後の成果 07 08 09 10 VPN の代替 実装① ネットワーク設計 実装② 認可 今後の展望 5
6. 既存環境の課題 01 既存ゼロトラスト環境の限界と運⽤ 負荷 既存のゼロトラスト環境における3つのボトルネック 02 既存VPN環境のセキュリティリスク と運⽤負荷 既存のVPN環境における4つの弱点 フルマネージドではないため、⾃社運⽤保守コス トが肥⼤化 • • 接続⽤コネクターのサーバー維持費‧管理リソー スが重荷に • • IaC⾮対応‧API制約により、プロビジョニング⾃ 動化が困難 • • 監視システムが脆弱で、通知もメールのみ • ©MIXI アプライアンス∕エンドポイント機器が DoS‧RCE 攻撃の標的になりやすい リプレイス‧バージョンアップ作業の稼働で保守 コストが上昇 物理機器依存のため、停電がそのまま接続断に直 結 6
7. 検討‧選定：重視したこと 選定の進め⽅と候補 【参考】検討時に設定した選定評価軸（⽐較⼀覧） 要件の定量スコアリング⽐較 必須∕⽤途別（L7プロキシ‧Alt VPN）∕任意の3層 × ◯△× で詳細に評価（右表参照） ⽐較検討した主な候補 • • • • クラウド⾃前構成（AWS∕Google Cloud） 他社ゼロトラスト製品 既存のネットワーク基盤 Cloudflare など多数のソリューション 特に重視した評価軸と選定結果 • 認証‧認可ロジックを⾃前実装せずマネージドに寄せたい • 送信元リクエストIPの固定（Egress IP制限）ができる • プロトコルがHTTPに限定されず、幅広いシステムに対応 • フルマネージドによる運⽤負荷の軽減とコスト効率化 • path単位の細粒度アクセス制御、および複数IDPへの対応 💡 結果：総合スコアリングで Cloudflare が最⾼評価となり採⽤ ©MIXI 7
8. 導⼊タイムライン PROJECT DURATION 検討開始から全ての本番移⾏完了 まで 14 検討‧実機PoC ゼロトラスト段階移⾏ 既存VPNの完全停⽌ 2025.07 - 11 2026.02 2026.09 必須要件の検証実施。 11/10OK判断 移⾏概ね完了。2⽉末 に既存環境完全解約 全移⾏の完了に伴う、 旧VPN設備の完全撤去 ‧廃⽌ ヶ⽉ ゼロトラスト段階移⾏ VPN の段階的移⾏ 2025.12 - 01 2026.04 - 08 1/5DNS切り替え、各 PJ移⾏推進 既存のVPN環境から新 環境への段階的移⾏ • 2025年7⽉より本格検討 • 実機PoCにて全要件を検証 • 2026年2⽉末にゼロトラスト解約 • 2026年8⽉末にVPN移⾏完了 ©MIXI 8
9. 利⽤パターン：既存ゼロトラストの利⽤マッピング Cloudflare 構成 2×2 マトリクス全体像 固定IP クライアント無 (ブラウザ等) クライアント有 ©MIXI 閉域到達 ① CDN + Dedicated CDN Egress IPs(Aegis) ③ Gateway HTTP + Tunnel HTTPSアクセス時のEgress GIPを固定化。 ブラウザ認証のみで社内閉域HTTPへセキュア接続。 [既存ゼロトラスト代替‧社外SaaS] [社内Web‧汎⽤SaaS] ② WARP + Gateway IP ④ WARP + cloudflared 特定の接続先に対して出⼝IPを固定制限。 閉域TCP/RDP等、⾮Webシステムに安全到達。 [主要社内IT‧制限先Web] [AD‧管理RDP‧開発環境] 9
10. 固定IPでIP制限先へ到達（①②） ① クライアント無 ② クライアント有 CDN + Dedicated CDN Egress IPs(Aegis) WARP + Gateway Egress IP 概要：CDNの出⼝IPを固定 概要：WARPクライアント経由で送信元IPを固定IP 接続先：全社利⽤の特定の許可IP制限がかかった外部 HTTPサイト等 接続先：事業部利⽤の特定の許可IP制限がかかったシステ ム メリット：ブラウザ経由のため、WARPの導⼊不要で⼿軽 にセキュア接続が可能 メリット：端末（ブラウザ外の通信含む全体）から透過的 に送信元IPを制限先に固定して、安全な到達性を確保 デメリット：ちょっとお⾼い デメリット：WARPの導⼊が必要 💡 ユースケースによる使い分けの基準 全社で利⽤、かつHTTPでアクセスするサイトは「① CDN + Aegis」を適⽤し、事業部が固定IPでアクセス制御するものは 「② WARP + Gateway Egress IP」を選択します。 ©MIXI 10
11. 閉域環境のリソースへ到達（③④） ③ クライアント有 ④ クライアント無 Gateway(WARP) + cloudflared Gateway(HTTP) + cloudflared 概要：WARP端末からcloudflaredコネクタ経由で接続 概要：ブラウザ等からのHTTPアクセスをcloudflared経由で接続 接続先：閉域TCP/RDP、SSH、および各種内部Webシステム 接続先：社内イントラWeb、主要な社内ポータル等 メリット：WARPクライアントによる透過的なルーティングで、ブラ ウザ以外の各種社内プロトコルにも安全に到達可能 メリット：端末へのクライアントソフト（WARP）導⼊が不要。端末 環境を選ばずブラウザのアイデンティティ認証のみで安全にアクセス 💡 cloudflared コネクタの共通性と接続⽅式の対⽐ 社内ネットワーク側に設置する「cloudflared コネクタ⾃体は共通」のものを利⽤します。その上で、全プロトコルを透過的にカバーする常時接続 の「③ Gateway(WARP) 経由（クライアント有）」と、⼿軽にブラウザから利⽤できる「④ Gateway(HTTP) 経由（クライアント無）」を⽤途に 合わせて対⽐‧併⽤して到達させます。 ©MIXI 11
12. 導⼊トラブル（導⼊フェーズ） 01 02 HTTP通信の"よしなに"書き換え SSL暗号スイートの⾮対応 従来のゼロトラストがHTTPのbodyやheaderを⾃動で書き換えて いたことが判明。 移⾏に伴い、Cloudflare Snippetsを⽤いた実装で対応を実施。 社内のレガシーシステムにおいて、SSL/TSLが古い暗号スイートし か利⽤できない⼀⽅、cloudflaredコネクタが古い暗号化⽅式 （RSA）に⾮対応であった。 その際、⽂字コード考慮不⾜による⽂字化けなど、実装時の⼤きな ハマりどころとなった。 stunnelというTLS通信をプロキシしてくれるツールを導⼊して対 応。 💡 導⼊フェーズにおける教訓と総括 単純なインフラ移⾏と捉えず、既存EAAの「⾒えない挙動（HTTP書き換え）」の⼗分な洗い出しと、レガシー証明書の事前アップデートが必要とな ります。また、クラウドベンダー⾃体の障害可能性を考慮し、フェーズアウト設計には⼀定のバッファと検証期間を設けることが肝要です。 ©MIXI 12
13. ある意味で最⼤のトラブル、それは… 契約⼿続きの真っ最中に、 Cloudflare ⼤規模障害が発⽣ ©MIXI 13
14. 導⼊後の成果 運⽤‧コスト ⾃動化‧設計 網羅性‧柔軟性 フルマネージド化と最適化 IaC化によるデプロイの⾃動化 4つの⽤途パターンを吸収 フルマネージド化により従来の運⽤管理⼯ 数から完全に解放。 IaC対応（Terraform）を完全に実現。 GIP制限、閉域TCP、HTTP/S中継など、社 内の多様な要件を4つの接続パターンで漏 れなくカバー。 cloudflaredコネクタの採⽤で、中継⽤ サーバーに要していたサーバーコストを 20万円/⽉の削減。 サーバー運⽤にかかっていた⼯数も加味す ると、既存ゼロトラストよりも断然安い。 変更管理がGit管理となり、レビューとプ ロビジョニングのデプロイサイクルが快適 に機能。 安全な設定変更がミスなく迅速に⾏える 環境へ。 クライアントあり/なしを適材適所で使い 分けられる⾼いアーキテクチャの柔軟性を 実証。 移⾏時の懸念をすべて払拭し、綺麗に統合 完了。 💬 担当者の⽣々しい本⾳と今後のロードマップ 「正直、運⽤保守の負荷軽減とコスト削減は期待どおり」で満点ですが、「監視まわりやIaCの対応範囲はまだ発展途上」と感じる部分もあり、 今後の進化やさらなるチューニングに期待しています。 ©MIXI 14
15. スピーカー紹介 岡村 凌兵 / Ryohei Okamura はたらく環境推進本部/コーポレートITサービス部/環境整備グループ/環境整備チーム 略歴‧担当領域 2025年8⽉、株式会社MIXI⼊社。主に社内IT範疇のNW領域 構築‧運⽤‧保守を⾏う傍 ら、全社展開中のVPN‧認証装置の⼊れ替えを担当。また、開発本部やセキュリティ 室とも連携し、業務DXを担当。 ©MIXI 15
16. 次の挑戦：VPN を Cloudflare で代替する 課題：既存オンプレミスVPNの排除がしたい • • 運⽤保守コストの上昇と、アプライアンス機器への DoS‧RCE攻撃を懸念 停電対応のたびに復旧確認を⾏う必要がある 代替策としてCloudflareを採⽤ • 運⽤コスト削減‧接続安定性そのままに閉域接続と 社内リソースへのアクセスを実現可能 MIXI社内 Cloudflare Tunnel Cloudflared Gateway Access [DNS] [ACL] 社内DNS WARP MIXI社外 社内リソース （オリジンサーバー） Webサイト ©MIXI 16
17. 実装① ネットワークの設計と苦労 NW到達性の課題課 解決策：社内DNSに解決させる ▪ NW経路そのものについて ▪ソリューション Cloudflaredを社内に置くことでNW経路を確⽴ ‧Gateway Resolver Policiesを使⽤する ‧Custom IPを使えば社内DNSに⾶ばせる！？ ▪DNSについて どこのリゾルバで解決させるかが課題 ▪導⼊‧検証 ‧Cloudflare内部に書くか ‧Cloudflaredで張った経路で社内DNSに到達できた ‧社内DNSに解決させるか ‧社内DNSにアクセスするので、⼆重管理問題も解決 ▪課題 社内DNSとCloudflare内の⼆重管理 💡 検証のポイント：LocalDomainFallbackか、ResolverPoliciesを使うかはログが取れるかどうかという観点でも悩んだ ©MIXI 17
18. 実装① ネットワーク：実装図 MIXI社内 Cloudflare Tunnel 自宅・委託先 Cloudflared Gateway Access 社内DNS Resolver Policies WARP 社内リソース （オリジンサーバー） Split先 MIXI社外 Webサイト Meetなど ©MIXI 18
19. 実装② 認可：ポリシー設計 直⾯した課題 VPN の ACL 踏襲と⼿探りの設計 「Firewall Policy でできるらしい」からのスタート • 既存のVPNで運⽤していたACL（IP系）のポリ シー定義を、CloudflareのFirewall Policyへと 移⾏‧踏襲する⽅法を模索。 • しかし、「何がどう設定できるのか」の全貌が ⾒えづらく、初期設計は完全に⼿探り状態。 ポリシーの癖と検証状況 暗黙の All Deny ではない仕様への対応 • ⼀般的なファイアウォール製品で主流の「最後 に暗黙の All Deny があり、通すものだけ許可 する」挙動ではない可能性が浮上。 • 明⽰的に Block ルールを⼊れないと意図しな い通信が通るという特有の「癖」があるため、 ポリシー定義の順序と設計思想の慎重な検証が 必要と判明。 💡 設計のポイント：Cloudflare Firewall Policy 固有の評価ロジックや「明⽰的な Block 設定が必要」といった癖を正しく理解し、 ゼロベースで安全な認可ポリシーを再設計することが極めて重要でした。 ©MIXI 19
20. 実装② 認可：デバイスポスチャの壁 ⽬指した安全な認可 デバイスポスチャによるBYOD排除 証明書の有無で「会社PC」のみを確実に識別 • 証明書あり 証明書を持たない私物PC（BYOD）からアクセス させたくないリソースに対して、確実にアクセス をブロックする構成。 Gateway Access Firewall policies 証明書ありのみ アクセス可 WARP オリジンサーバー 直⾯した苦労‧トラブル 証明書なし インポート仕様の「壁」に激突 GUIから証明書を登録できない • • Gateway クライアント証明書の信頼設定が管理画⾯ （GUI）から直接アップロード‧インポートでき ない Access Firewall policies WARP 導⼊検証における設計と確認のスピードが低下 する結果に。 CFさん、仕様の検討をお願いします🙏 ©MIXI 20
21. 今後の展望 ⽬指すゴールと展開 VPNの完全撤廃と⽤途拡⼤ 他部⾨展開など前向きなフェーズへ これからの期待 脆弱性‧アプデ運⽤の解放 本質的な運⽤負荷の劇的な軽減へ • VPN代替が実現したため、リリースを実施 • VPN機器の脆弱性対応や、保守コストからの解放 • セキュリティと利便性を両⽴し、さらなる⽤途 拡⼤や他部⾨への積極的な横展開を推進中。 • 2026年7⽉に本番リリースしました！ • トラブルの際はCFさん、全⼒でのサポートを よろしくお願いいたします！🙏 💡 これから導⼊する⼈への⼀⾔：ゼロトラスト移⾏は「壁」も多いですが、VPNの呪縛から解放された先には圧倒的に安全で運⽤しやすい未来が 待っています。⼀緒に頑張りましょう！ ©MIXI 21
22. ©MIXI
23. Appendix ©MIXI 23