- SSLMateのGoogle Cloudアカウントが3度目も予告なく停止され、サービス統合機能が繰り返し中断
- 顧客のCloud DNSおよびCloud Domains統合のため、Googleのドキュメントに従ってサービスアカウントを作成・委任する構成を使っていたが、この方式が継続的に停止対象となっている
- 1回目の停止（2024年）は、復旧プロセスの非効率さと原因の不明確さによって大きな混乱を招き、その後の2回の停止でも事前通知なしに自動メールだけが繰り返された
- 代替案として、長期キーを使った認証はセキュリティ上脆弱で、OIDC(OpenID Connect) は設定手順が過度に複雑
- 結果としてGoogle Cloud統合では、セキュリティ・利便性・安定性のうち2つしか選べない構造的限界が露呈
Google Cloudアカウントの繰り返し停止事例
- SSLMateのGoogle Cloudアカウントが2024年と2025年に、2回連続する金曜日ごとに事前通知なしで停止
- それ以前にも2024年に同様の停止があり、3回とも明確な理由や再発防止方法は提示されていない
- SSLMateは顧客のGoogle Cloudアカウントと統合するため、サービスアカウント委任方式を使用
- 顧客ごとにSSLMateのプロジェクト配下でサービスアカウントを作成し、顧客がそのアカウントにCloud DNSおよびCloud Domainsへのアクセス権を付与
- SSLMateは必要時にそのサービスアカウントを仮想的に偽装(impersonate) してアクセス
- この構成はGoogle公式ドキュメントの推奨方式に基づいており、長期資格情報なしで安全かつ設定が簡単な方式
1回目の停止（2024年）
- 1回目の停止時には顧客統合機能がすべて失敗し、コンソールへのアクセスも遮断
- Googleサポートは応答したものの、アカウントが無効化されていてメールが返送されるなど、復旧手順は非効率だった
- プロジェクトIDの提示を求められたが、コンソールにアクセスできず提供できなかった
- 電話番号認証後に一部プロジェクトだけが復旧し、翌日には再び自動メールでアクセス制限が通知された
- その後も複数の自動メールを経て、約19時間後に全面復旧
- Googleは停止理由を明らかにせず、事前のメール通知もなかった
- SSLMateはその後、統合エラー率を監視するヘルスチェック機能を追加して早期検知を試みた
2回目の停止（2025年10月ごろ）
- ヘルスチェックが失敗し、ほとんどの統合が**
Invalid grant: account not found** エラーを返した
- コンソールへのログインは可能だったが、各プロジェクトごとに「提供された情報に基づいて復旧された」というメールだけを受信
- 停止通知メールは依然として届かなかった
- その後、統合機能は正常化した
3回目の停止（2025年11月）
- 再びヘルスチェックが失敗し、コンソールアクセス時に新しい種類のエラーメッセージが表示
- 大半のプロジェクトが停止され、顧客統合用のプロジェクトも含まれていた
- 金曜日に異議申し立てを提出したが、日曜日にはアカウント全体の停止通知メールを受信
- 月曜日、この投稿がHacker Newsに載った直後に大半のプロジェクトが復旧し、数時間後に全面アクセスが回復
- 今回も停止原因や予防方法は示されなかった
例外的な顧客のケース
- すべての停止期間中でもある1社の統合だけは正常に動作
- 同じプロジェクト内のサービスアカウントを使っていたにもかかわらず影響を受けなかった
- 原因について追加説明はない
Google Cloud依存の問題と代替案
- SSLMateは本番環境でGoogleアカウントに依存できないと判断
- Googleのシステムは、アカウント・プロジェクト・またはGCP全体が任意に停止されうる構造になっている
- 代替案1: 顧客が直接サービスアカウントを作り、長期キー(long-lived key) でSSLMateに認証を提供
- 設定は簡単だが、キー漏えいリスクとローテーションしにくさのためセキュリティは弱い
- 代替案2: OpenID Connect(OIDC) を使用
- GitHub ActionsやAzure統合で使われる標準方式で、長期資格情報なしに安全なアクセスが可能
- しかしGoogle Cloudでの設定は7段階の手順で過度に複雑
OIDC設定の複雑さ
- OIDCを使うには次の手順が必要
- IAM Service Account Credentials APIを有効化
- サービスアカウントを作成
- Workload Identity Poolを作成
- Pool内にWorkload Identity Providerを作成
- SSLMateがサービスアカウントを偽装できるよう権限を付与
- サービスアカウントにロール(Role)を付与
- 作成したサービスアカウントとProvider IDをSSLMateに伝達
- 各手順で前段階のリソースIDが必要になるため、顧客が追従しにくい
- 筆者は次の点を不要な手順だと指摘
- サービスアカウントを作成しなくてもロールを直接付与できるべき
- 多くの場合PoolにはProviderが1つしか含まれないため、Pool作成自体が不要な重複作業
- Providerを作成しなくても、OIDC発行者URLとサブジェクト(subject) に直接ロールを付与できるべき
構造的な問題と結論
- 現在のGoogle Cloud統合では、次の3つのうち2つしか選べない
- 長期資格情報が不要
- 顧客が簡単に設定できる
- 任意停止から安全
- SSLMateのサービスアカウントベース方式はセキュリティと利便性は確保できるが、停止リスクがある
- サービスアカウント+キー方式は設定が簡単で停止リスクは低いが、セキュリティは弱い
- OIDC方式はセキュリティと停止耐性は高いが、設定が複雑
- GoogleがOIDCを第一級の統合方式として簡素化しない限り、安全で安定した統合は難しいという結論
読者コメント要約
- ある読者は「別のクラウドプロバイダを使え、GCPは最悪だ」と述べた
- 筆者は「顧客がGCPを使っているため、統合のために必要だ」と応答
- 別の読者は「セキュリティと信頼性は単純さと衝突する」として、単純さを優先する顧客には向かないと指摘
2件のコメント
"Android developer verification も結局こうなるだろう。多くの人が Android 向け開発を禁止されることになる。"
Hacker News の意見の中で最も印象に残ったものですね。そう遠くない話だと思います。
Hacker Newsの意見
人々はGoogleを信頼できるパートナーだと考えがちだが、実際には大規模な小売工場のように設計されたシステムである
数百万人を対象としており、誤った自動保護措置ひとつで数千人の生活が壊される可能性がある
顧客サポートの不在や自動化された無意味な返答は、単なるコスト削減ではなく法的責任を最小化する戦略に見える
たいていの人は、Googleアカウントがいつでも理由なく停止されうることを知っている
実際、周囲にアカウントへのアクセスを失った人を1人か2人は知っているものだ
何百万ドル規模の契約でもない限り、Googleを本当のパートナーと見る人はほとんどいないと思う
すべてのプラットフォームはスケール拡大を優先している
個々のユーザーと人間的な関係を維持しながら、麻薬ディーラー並みの収益性を保つのは不可能だ
善良な人が1人誤って引っかかっても「必要なコスト」と見なされる
昨日はWise、その前はGitHubのアカウントがこのように遮断された
企業は民主主義ではなく封建領地のように運営されている
自動化システムがあなたを犯罪者だと判断すれば、裁判もなく即座に罰する
実際の人間と話せて、単なるチャットボットではない
今はTuta Mailを使っているが、耐量子暗号と広告のない環境が気に入っている
自分のドメインで好きなだけエイリアスアドレスも作れる
数年前、私のYouTube Premiumアカウントがスパムを理由に停止された
単に動画を見ていただけなのに、アカウントは削除され、決済ページへのアクセスまで塞がれた
3週間ごとに1回しかできないロボット的な異議申し立て手続きを進めている間も、料金は請求され続けた
Google Oneの有料サポートも「別チームなので助けられない」と言うだけで無力だった
結局カードの解約で解決したが、数か月後に「間違いでした」というメッセージを受け取った
皮肉なことにWeChatは1日で人間と通話して解決できた — 検閲国家のカスタマーサポートのほうがましだと思わされた
問題はGoogleだけではなく、アルゴリズム依存型の巨大企業構造全般にある
Redditでも20年物の私のアカウントが理由もなくシャドウバンされた
異議申し立ては無視され、投稿もコメントもすべてフィルタリングされた
Fediverseはよりよい代替モデルを示している — 小さなコミュニティと高いモデレーター比率が鍵だ
#fediblockタグひとつで何百ものサーバーから自動的に遮断される仕組みは、無責任な検閲を繰り返すことになる
実際、私たちの街のMastodonインスタンスはそれで崩壊し、皆Blueskyへ移っていった
こうしたエッジケースを処理する人員を100人ほど置くくらい難しくない
だが利益率が下がるのでそうしない
金がないのではなく、使わないことを選んでいるだけだ
今後はGemini APIでもこうした問題が起きそうだ
顧客が規約に違反する画像を生成したら、その瞬間にビジネス用Gmailや個人の復旧用Gmailまで永久停止されかねない
Android開発者認証もこのような流れになりそうだ
多くの開発者が理由もなく開発者資格停止を食らう可能性が高い
以前、小規模企業の従業員たちの個人アカウントが「以前停止された開発者アカウントと関連している」という理由でまとめて遮断された事例を見た
プラットフォームに従属したままで専門性を維持するのは難しいと思う
私たちのサービスでも単に「Login with Google」ボタンを使っていただけなのに、突然アカウントが停止された
理由は「利用規約違反」という曖昧なものだけだった
異議申し立てを出し、ユーザー向けの代替ログイン手段を急いで用意していたところ、翌日突然「異議申し立て承認」のメールが来た
結果として復旧はしたものの、不信感が残った
私のAdSenseアカウントは、広告に感嘆符を1つ入れたという理由で3回停止された
最終的にアカウントは閉じたが、今でも「潜在的な不正アカウント」として追跡されている気がする
新規ユーザーが1時間で停止されるような構造なら、そもそもなぜ登録手続きをそこまで簡単にしているのか疑問だ
この状況ならGoogleを訴えるか、規制強化を求めるべきなのか考えてしまう
Googleが出廷しなかったり、TOSを根拠に言い訳して裁判官の心証を悪くしたりすることが多いと聞く
停止されたメールアカウントで登録したPasskey専用ログインアカウントはどうなるのか気になる
Google Password Managerに同期されたPasskeyがアカウント停止後も機能するのか、
それともメールアクセスが塞がれて復旧不能になるのか、試した人はほとんどいない気がする