ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
移行後に古いAPIキーを安全に廃止する
以前のプロバイダーのAPIキーを廃止することは、移行の最後にある小さな、ほとんど事務的な作業のように感じられますが、タイミングをどちらの方向に誤っても実際の損失が生じます。依存するすべてのシステムが実際に移行する前に早く廃止しすぎると、まだ古いキーを呼び出している何かが予期せず壊れます。廃止が遅すぎたり、まったく廃止しなかったりすると、使われていないのにまだ有効な認証情報が、誰にも積極的に監視されないセキュリティ上のリスクとして残り続けます。
最も安全な手順は、キーの廃止を、主な移行作業の最後に付け足すものではなく、決まった順序を持つそれ自体の小さなプロジェクトとして扱うことです。
- 移行が完了したと思い込むのではなく、まず古いキーのトラフィックがゼロであることを確認する。ほとんどのプロバイダーは、キーごとの使用状況をある程度確認できるようにしています。移行のチェックリストが完了済みになっているからといって、古いキーが実際に使われなくなったと考えるのではなく、直接確認してください。
- 古いキーを、有効だが使われていない状態で一定の観察期間残しておく。移行が完了したと考えたら、新しいプロバイダーが稼働した瞬間に無効化するのではなく、この期間を設けます。トラフィックのパターンやリリースサイクルにもよりますが、通常は数週間のこの期間によって、忘れられていた呼び出し箇所、遅れているモバイルアプリの更新、まれにしか実行されないバッチジョブなど、まだ古い認証情報を参照しているものを見つけられます。
- プロバイダーが区別をサポートしている場合は、古いキーを削除するのではなく、まず無効化する。記録として残っている無効化されたキーは、予期しないことが起きた場合に、完全に削除されたキーよりも一時的に再有効化しやすく、観察期間を無期限に延ばすことなく安全の余裕を持たせられます。
- 決めた日付に古いキーを削除するか完全に失効させ、それを実施したことを記録する。無期限に無効化されたままのキーは、アカウント自体が侵害された場合に誰かが再有効化できる可能性のある、セキュリティ上の攻撃面であり続けます。本当に廃止した認証情報は、いつまでも宙ぶらりんの状態で放置するのではなく、最終的には完全に削除すべきです。
- 古いキーが保存されていた場所を監査する。構成管理システム、シークレットマネージャー、環境変数ファイル、そしてキーに言及している可能性のあるドキュメントやオンボーディング資料も含めます。廃止したキーがどこかに「APIキー」としてまだ書かれていると、キー自体が機能しなくなってからずっと後に、次にそのドキュメントを読む人を混乱させるからです。
My Geocodeへの移行では、すべてのレスポンスに含まれる割り当てヘッダー(X-Quota-Used、X-Key-IPs-Usedなど、/docs/rate-limits/に記載)を使って、初日から新しいキーの範囲を把握し、監視できます。そのため、古いキーを廃止するカウントダウンを始める前に、新しいキーが想定どおりのトラフィックを実際に処理していることを簡単に確認できます。認証情報の廃止をこの程度に慎重に扱うことは、わずかな追加の手順で、運用上のリスクと残存するセキュリティ上の露出の両方を大きく減らすことにつながります。