Q.Studioに登録していたAPIキーが漏えいした可能性がある場合、どう対応すればよいですか？

外部サービス側で新しいAPIキーを先に発行し、Studioのデザインエディタで認証設定を更新したあと、古いキーを削除します。

1. 外部サービス（microCMSなど）で新しいAPIキーを発行する
2. Studioのデザインエディタで［接続］→［API］→［認証］を開き、値を新しいキーに書き換えて保存する
3. エンドポイントでその認証が選ばれていることを確かめ、［接続を確認］を押す
4. 公開サイトでも、外部のデータが表示されているか見る
5. 外部サービス側で古いキーを失効・削除する

認証の画面には「キー」と「値」の2つの欄があります。microCMSの場合、キーの欄はヘッダー名の X-MICROCMS-API-KEY のままでかまいません。書き換えるのは値の欄に入っている認証用の文字列です（StudioのmicroCMS連携手順）。

［接続を確認］に成功すると、画面の右側に取得したデータのサンプルが出ます。ただし、この確認は接続テストです。エンドポイントの設定を保存すると公開サイトにすぐ反映されるため、保存した後は実際のページも開いて確かめてください。

なお、microCMSでキーを作ったり消したりできるのは、管理者権限を持つユーザーだけです。新しいキーはAPIキー管理の一覧にある［追加］から作り、名前と権限を決めます（microCMSのAPIキー仕様）。また、プランごとに作成できるキーの上限数も定められており、Hobbyプランは1個、Teamプランは3個、Businessプランは10個、Enterpriseプランは20個となっています。新旧のキーを一時的に並行稼働させるためには、キー枠に空きがあるか事前の確認が欠かせません。自分のアカウントに管理者権限がなければ、先に権限を持つ人へ頼むことになります。

外部サービスと連携していないサイトでは、APIキーの差し替えは要りません。ただし、アカウント情報やデザインエディタ・CMSの内容は、すべての利用者について流出の可能性がある情報に入っています。外部サービスからデータを取得するAPI連携を設定していたサイトは、キーの確認と差し替えが必要です。

Studioのセキュリティ告知によると、Data Connect APIや旧API連携（Beta）の設定に登録されていた外部サービスのAPIキーやトークンについて、暗号化して保存されていたデータも含めて復号用の鍵が読み出され、第三者に知られた可能性があると公表されました。

• キーの差し替えが要らないケース：外部サービスと連携せず、Studioのデザインエディタや組み込みのCMSだけで完結しているサイト（アカウント情報やデザインエディタ・CMSの内容は、この場合も流出の可能性がある情報に含まれます）。
• キーの差し替えが必要なケース：Data Connect APIや旧API連携（Beta）を使い、microCMSやNotionなどの外部データを動的リストや動的ページへ読み込んでいるサイト。
• その他の確認項目：Embedボックスなどのカスタムコード内に、外部サービスの秘密トークンを直接記述しているサイト。

もうひとつ迷いやすいのが料金プランです。Data Connect APIはBusiness以上が対象です。旧API連携（Beta）で連携済みのデータは、引き続き全プランで使えますが、今後の継続利用は保証されていません（Data Connect APIの仕様）。今のプランがBusiness未満でも、過去に連携していればキーの差し替えが必要になりえますね。

ちなみに、Studioはアカウントのパスワード変更も求めています。GoogleログインやFacebookログインだけを使い、Studioのパスワードを一度も設定していない人は、変更しなくて大丈夫です。

Studioに登録していたAPIキーが勝手に使われていないかは、どうやって確かめればよいでしょうか。

使われたかどうかは、Studioではなくキーを発行したサービスの管理画面で見ます。利用履歴や利用状況のページを開き、心当たりのないアクセスや操作がないかを確かめてください。いつ以降の記録を見ればよいかは、上で挙げたStudioのセキュリティ告知で確かめておきましょう。おかしな利用が見つかったら、そのサービスの提供元と、Studioの問い合わせ窓口の両方に知らせます。

ここで気をつけたいのが、Studio側の機能とキー自体の権限の違いです。StudioのData Connect APIは、GETでもPOSTでもデータを取ってくるだけで、外部サービスのデータを作ったり消したりはしません。ただ、漏れたキーそのものは、Studioを通さずに直接使えます。microCMSでは、キーに付けた権限によって外部からの書き込みができたり、下書きのコンテンツが公開状態にされたりすることがあります。キーに書き込み権限を付けていたなら、記事の追加・変更・公開状態もあわせて見るほうがよいでしょう。

また、利用量に応じて従量課金が発生するサービスでも確認を急ぐ必要があります。Google Mapsのセキュリティガイドにあるように、制限をかけていないAPIキーが悪用された場合の利用料金は契約者自身の負担となってしまいます。

APIキーのローテーションとは、稼働中のシステムを止めずに新しいキーを発行して設定を移し替え、古いキーを無効化するセキュリティ対策のことです。一度発行したAPIキーを長期間使い続けるのではなく、Google Cloudの認証運用ガイドが示すように定期的な再発行と破棄を繰り返すことで、万が一の漏えいによるリスクを低減させる狙いがあります。

順番を守る理由は、Studioの場合はっきりしていますね。設定を更新する前に古いキーを失効させると、サイトの連携が止まることがあります。逆に、新しいキーを発行しただけで終えると、漏れた古いキーが生きたままになります。発行、Studioの更新、発行元での古いキーの失効まで終えて、ひと回りです。

入れ替えとあわせて、キーの権限と使い道も見直せます。microCMSでは初期設定の権限として取得（GET）のみを許可し、更新が必要な通信にだけ限定して書き込み権限を付与する運用が可能です。キーをウェブサイト用、iOS用、Android用のように分けておけば、用途ごとに入れ替えの時期やアクセスできる範囲を決められます。

Studioから別の環境へサイトを移したあと、キーをどこに置けばいいのでしょうか。再発防止の基本となるのは、秘匿すべき認証情報をブラウザから直接見える場所に配置せず、サーバーサイドの環境変数に格納して通信を中継させる仕組みの採用です。Webブラウザから外部APIを直接呼び出す構成を取ると、通信ログや画面のソースコードを解析することで誰でもキーの文字列を取得できてしまいます。

Cloudflare Workersには、暗号化した文字列をWorkerに設定するSecretsがあり、APIキーの保管に使えます。Astroの場合、PUBLIC_ で始まる環境変数はブラウザー側のコードからも使えるので、秘密のキーには付けません。astro:envでサーバー用のsecretとして定義した変数は、最終的な配布ファイルに含まれません。

どこに置いても、キーの権限は使う分だけに絞ります。microCMSなら必要最低限のGET権限、Google Maps Platformなら使うAPIやアプリへの制限です。

もっとも、すべてのキーをサーバーに隠す必要があるわけではありません。microCMSでは、標準の権限をすべて外し、公開してよいAPIにだけGETを許し、非公開のAPIには個別の権限を付けない設定にすれば、キーをそのままブラウザー側に埋め込む使い方も示されています。中継用のサーバーを作らずに済みますが、GETだけのキーでも非公開の情報を取れる設定なら安全とはいえません。