有効期限のないAPIキーの問題点
何年も前に発行され、一度もローテーションされず、今も有効なキーは、便利なものではありません。何年も誰も実際に確認していない負債です。
IPv6が利用可能になってから十分に長い時間がたっており、それを二次的な関心事として扱うことは、もはや妥当なエンジニアリング上の近道ではありません。それでも多くのIP関連ツールは、いまだにIPv4こそが本当のトラフィックで、IPv6は時間が余れば対応する例外であるかのように振る舞っています。これは細かいところに表れます。IPv6について同等のよく練られた概念がないまま、IPv4式のアドレスブロックを前提に書かれたレート制限のロジックや、例の中でIPv4のアドレス形式を暗黙のうちに前提とし、IPv6の扱いを言外の後回しにしているドキュメントなどです。
私たちは、ネットワーク単位の割り当ての追跡を、IPv4優先のロジックに後付けしたIPv6のパッチとしてではなく、意図的に両方のアドレスファミリーを軸に構築しました。すべてのネットワークに共有の無料枠があり、IPv4アドレスでは/24ブロック、IPv6アドレスでは/48ブロックが単位です。どちらか一方が主たる設計でもう一方が便宜的な対応というのではなく、両方が同等のグループ単位として扱われます。/24と/48という区別は恣意的なものではありません。ブロックの割り当てを担う地域インターネットレジストリが、それぞれのアドレスファミリーを実際にどのように割り当てているかを反映しており、どちらの場合もグループ単位は実務上同じもの、つまり妥当な規模のネットワークを意味します。
これを誤ることは、位置情報とIPデータのAPIにとって特に重大です。ネットワーク単位やIPに基づく検索というカテゴリー全体が、両方のアドレス形式にわたって正しく解析し、照合し、レート制限することに依存しているからです。IPv6を暗黙のうちにエッジケースとして扱うAPIは、IPv6のトラフィックに対して、一貫しない割り当ての挙動、誤ったネットワークのグループ分け、あるいは明白な解析の失敗を起こしやすくなります。それも、IPv6の普及が進み続け、実際のリクエストのかなりの割合がIPv4ではなくIPv6で届いている、まさにその時期にです。
業界全体でこれへの投資が不足している理由の1つは、多くのサービスにとってIPv4のトラフィックがいまだに総量の大きな割合を占めていることです。そのため、IPv6のエッジケースは、本当に正しく対応するための労力と比べて優先度が低く感じられます。私たちは、その考え方は傾向線を軽視しすぎていると考えます。増え続けるトラフィックの割合は、それを恒久的な少数派のケースとして扱うインフラでは十分に対応できません。そして、システムの中核となるロジックがIPv4をデフォルトとして想定して構築される期間が長くなるほど、IPv6の扱いを適切に修正するコストは増える一方です。
これは大げさな主張ではありません。APIが技術的には構文エラーなくIPv6アドレスを受け付けると示すコンプライアンス上のチェックボックスだけでなく、レート制限、割り当ての追跡、検索ロジックの実際の設計において、IPv6をIPv4と同じくらい真剣に扱ってほしいというお願いです。あるアドレス形式を受け付けることと、より一般的な形式と同じ注意をもってそれを扱うことは、別の達成事項です。そしてこの業界の多くのインフラは、本当の意味では前者しか達成できていません。