Amazon APIが電子署名必須の「Product Advertising API」に変更、その目的は?

2009/05/09

■Amazon.co.jp Product Advertising API ライセンス契約
https://affiliate.amazon.co.jp/gp/advertising/api/detail/agreement.html
 
一部で話題になっていますが、AmazonのWebサービスAPIが変更になり、
「Product Advertising API」 になるそうです。具体的には
8/15以降は署名を付けていないAPIコールは受け付けなくなるようです。
 
具体的なやり方などは以下のサイトでまとめてくださっていますので、
AmazonのWebサービスAPIを使ってシステム開発をされている方はぜひ
ご確認ください。簡単にいうと、これからコールするAPIのパラメータ一式を、
開発者ごとの 秘密鍵を使ってハッシュ し、それを「Signature」
というパラメータとして追加するということになります。
 
■[を] アマゾンAPIを使うのに2009年8月15日から認証が必要になるらしい
http://chalow.net/2009-05-09-1.html
■404 Blog Not Found:perl - URI::Amazon::APA released!
http://blog.livedoor.jp/dankogai/archives/51211577.html
 
さて、なぜ突然こんな面倒な仕組みが導入されたのか、というのが
気になる方はとても多いと思います。実際、本家Amazonからは
「名称変更に伴い」 という何とも理由になっていない理由しか
伝えられてきませんので、真意がどこにあるのか定かではありません。
 
ただ、あくまで憶測ではありますが、こちらでブックマークコメント
されていました理由が、一番筋が通っていそうな気がしました。
 
■はてなブックマーク - [を] アマゾンAPIを使うのに2009年8月15日から認証が必要になるらしい
http://b.hatena.ne.jp/entry/http://chalow.net/2009-05-09-1.html
betelgeuse : クライアントからAPIを使われるのは金の無駄なので対策する、という意味のレター。サーバーで使っている人たちへの今後の方法の案内
「クライアントからAPIを使われる」 というのは、開発者本人のサーバから
ではなく、エンドユーザのPCから直接実行されるものを指します。具体例としては、
 
 ・javascriptのブログパーツ
 ・FLASHのブログパーツ
 ・ブックマークレット
 ・Greasemonkey
 ・ユーザ配布型クライアントソフト (フリーウェア等)
 
といったところが挙げられます。他にもいろいろあるかもしれません。
 
一番顕著な例は ブログパーツ だと思いますが、たとえば現在ですと
Amazonの商品の「価格」を取得するにはAPIを使うしかありません。そこで、
とあるサービスが発行するブログパーツに価格を表示させようとして、貼り付け
タグの中に 直接APIコールのURLを含めて いたりする場合があります。
 
これをやられると、たとえばそのパーツがもし 100万PV/day の大手サイトに
貼られると、その ページが表示されるたびにAPIが 呼び出される
ことになります。すなわち1日100万回のAPIコールが生まれるわけです。
 
厄介なのは、このAPIコールが、その大手サイトから行われるのではなく、
その大手サイトを「閲覧」している 個々のユーザのブラウザから
発せられるという点です。すなわち、意味的な構造からすると1つの大手サイトに
よって大量のAPIコールが発行されているにも関わらず、実際のシステム構造的には
大量のクライアントPCから分散アクセスを受ける構図になってしまいます。
 
このようなパターンが常態化すると、「一部のサービス開発者だけが使うもの」
として作られていたAPIが、「ウェブ全体の ページビューに比例して
無数のエンドユーザがコールするもの」になり、API受付側がパンクしかねないので、
厳密化を図る必要が出てきたではないかとというのが私の憶測です。
 
APIをコールする際には今までも開発者用の AccessKeyID が必要でしたので、
それをキーにして大量アクセスを防ぐことは可能でしたが、今までのAmazonは
こういうパターンを黙認していたようです。というのも、AccessKeyIDは
厳密に秘匿する義務があるものとして認識されていなかったため、
javascriptやフリーソフトのコードなどに普通に見える形で混ぜている人も
多かったり、そもそもAPIコール自体のパラメータとして 平文で含まれている
ものでしたので、どこの誰に自分のAccessKeyIDを勝手に使われても、
それが開発者本人の責任であるとはいえない状態だったためです。
 
しかし、今回の秘密鍵は、厳密に開発者に対して対外への 秘匿義務 が課せられます。
 
■Amazon.co.jp Product Advertising API ライセンス契約
https://affiliate.amazon.co.jp/gp/advertising/api/detail/agreement.html
秘密キーであるアカウント識別子またはパスワードであるデータフィードアクセスID は、お客様個人の利用のためものであり、お客様は、お客様の秘密キーの秘密性およびセキュリティの管理をしなければなりません。お客様は、お客様の秘密キーまたはパスワードを、他の個人または事業体に販売、譲渡、サブライセンスまたは公開してはいけません。
お客様は、お客様のアカウント識別子および/または、データフィードアクセスID の適用ある方に基づき発生する全ての活動につき、かかる活動がお客様または他の個人もしくは事業体のいずれによりなされたものであるかを問わず、全面的に責任を負います。従って、お客様以外の者がお客様の秘密キーまたはパスワードを使用している可能性があると思った場合、またはお客様の秘密キーまたはパスワードが公開されたか、紛失または盗まれた場合、お客様は直ちに当方に連絡しなければなりません。
すなわち、今度の秘密鍵は、その秘密鍵で作られた署名を持ったAPIコールは
間違いなく「本人」が発した APIコールであるという責任を持ちなさい、
ということになります。万が一、秘密鍵が漏れた疑いがあって、自分の署名を
他人に作られてしまったような形跡がある場合は、クレジットカードと同じように
自分から申告してアカウントの一時無効化をしてくださいということのようです。
 
これだといわゆる 「リプレイ攻撃」 (APIコールを署名まで完全に傍受・コピー
してそのまま他人が使う) はどうなるの?という話もありますが、そこで地味に、
 
■[を] アマゾンAPIを使うのに2009年8月15日から認証が必要になるらしい
http://chalow.net/2009-05-09-1.html
(1) 今までのようにリクエストURLを作ります。Timestamp も付けます。
というように Timestampパラメータが必須 になっています。おそらく古いTimestampの
リクエストは受け付けないことになるでしょう。そしてTimestampを書き換えようにも、
それを含んだパラメータ全体を秘密鍵でハッシュし直さなければならないのですから、
秘密鍵を知っている本人しか作り直しようがないということになります。
これでリプレイ攻撃も有り得ないことになり、「正しいAPIコールができる人」
イコール、「秘密鍵を知っている本人」という図式が成り立ちます。
 
これにより、前記のブログパーツにAPIコールを含むような形態を取って
ページにアクセスする個々のユーザがばらばらにAPIを叩いたとしても、
それは署名から判断して全て元のサービス開発者のコールとみなされることになり、
すなわち、大量アクセスが生じたときには場合によっては受付停止措置を
受けることもありえるということになるわけです。
 
ちなみに今回の変更を開発者に通知するメールの本文は、挨拶文のあと、
Amazon では、アソシエイト・プログラムを通じて、Amazon の商品を広告して下さっている Web サイトに、年間数千万ドルを投じています。
という一文から始まります。これには紹介料もそうですが、サーバリソース
という意味も含まれるでしょう。要するに、AmazonのAPIは何百万回叩いても
へっちゃらの 魔法のサーバ ではないぞ、ということですね。
特に不況が深刻化している今、このコスト意識がより強く現れてきたのかも
しれません。本来、AmazonのAPIは 1秒に1回 以上のペースでは叩かない
でください、という規約文があります。これが厳密に適用されるかどうかは
分かりませんが、無尽蔵なAPIコールを量産していたケースについては、
この今回の変更によって大きな影響を受ける可能性があるかもしれません。
 
なお、上記はあくまで 「状況からの憶測」 です。今回の変更が必要になった
本当の理由については実際のところは分かりませんので、その点はご注意ください。
 
さて、私もプログラムの改修があちこちに必要になるのでした・・・。


2009/05/09 [updated : 2009/05/09 23:59]


この記事を書いたのは・・・。
CK@デジモノに埋もれる日々 @ckom
ブログ「デジモノに埋もれる日々」「アニメレーダー」「コミックダッシュ!」管理人。デジモノ、アニメ、ゲーム等の雑多な情報をツイートします。




« 4系統分配器「XVI-2」を使ってゲームのプレイ画面をそのまま録画!

トップに戻る

ひとやすみ: 東京駅の「一旦ドア閉め」、東京に現れた「巨大な虹」 »


▼ はてなブックマークのコメント ▼

はてなブックマークで
コメントしましょう
hengsu 2009/05/12
なるほど
IwamotoTakashi 2009/05/12
真意は知りませんが https://affiliate.amazon.co.jp/gp/advertising/api/detail/faq.html のQ4に理由が書いてあります。
AmaiSaeta 2009/05/13
ぐぬぬそうなるとサーバ環境持ってない俺とかが困るんだぜ……いや理解出来るけどさ……
kamm 2009/05/13
『しかし、今回の秘密鍵は、厳密に開発者に対して対外への 秘匿義務 が課せられます』 これってクライアントソフトだと解析されないようにするのが大変でわ…
lizy 2009/05/13
「このAPIコールが、その大手サイトから行われるのではなく、 その大手サイトを「閲覧」している 個々のユーザのブラウザから 発せられる」 悪意のないDDoS?
TakamoriTarou 2009/05/13
お行儀の悪い使われ方が増えて、すでに支えられない所まで来ているので、そういった使われ方がされないように手を打ったというわけか。一部の迷惑をかける人のために、全体が不便になるのはよくあること…なのか?
sho 2009/05/13
まぁ、これくらいしか想像できないわなぁ。
falseh 2009/05/13
細々手を入れて使ってきたaws.plもそろそろ終わりにするか
tsupo 2009/05/13
APIコールが、その大手サイトを「閲覧」している 個々のユーザのブラウザから発せられるという点 / API受付側がパンクしかねないので、厳密化を図る必要が出てきた (という推測)
nilab 2009/05/13
Amazon APIが電子署名必須の「Product Advertising API」に変更、その目的は?:クライアント(開発者本人のサーバではなくエンドユーザのPC)からAPIを使われないための対策:JavaScriptブログパーツなど:秘密鍵の秘匿義務
kurumigi 2009/05/13
名称変更の通り、『Product Advertising』でないアクセスは切り捨てたいのかもなあ。
tinsep19 2009/06/25
APIコール自体のパラメータとして 平文で含まれている ものでしたが、今回の秘密鍵は、厳密に開発者に対して対外への 秘匿義務 が課せられます。
kgbu 2009/07/15
認証のためのシステム変更の初期投資もあるだろうし、認証自体のコストも大丈夫なのかしら。認証後のrequestに対してはRESTfulに対応してcacheは効くのかな。出遅れた自分もそろそろ対応しなくちゃ。
supermomonga 2011/01/18
なるほどーなっとく
はてなブックマークで
コメントしましょう


AmazonのProduct Advertising API、旧バージョンは2/22から全て「2011-08-01」扱い


Product Advertising API の仕様変更アナウンス - ItemSearchで10ページ制限?!など


Amazon API で11/9からカスタマーレビュー取得不可?! 代替はiframeのURL


Amazonの Product Advertising API 『新ガイドライン』に注意! 施行は10/15から


AmazonのAPIから返ってくる2つの発売日「PublicationDate」と「ReleaseDate」


Amazon APIの”ItemLookup”は、ItemIdを複数指定できたというお話


Product Advertising API の秘密鍵とクライアント型ソフトに関する公式見解

ピックアップタグ




ブログ内検索



▼ コメント ▼


★コミックダッシュ! 10,000人突破ありがとうキャンペーン!(9/18~10/23)
 
デジモノに埋もれる日々 : (C) CKWorks