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

2009/06/21

AmazonのEC用WebサービスAPIが Product Advertising API (俗称 PAAPI ?)
に変更され、APIコールに秘密鍵から生成された電子署名(Signature)を
付けることが必須になったというお話しをしました。
 
■2009/05/09 [Amazon APIが電子署名必須の「Product Advertising API」に変更、その目的は?
Amazon APIが電子署名必須の「Product Advertising API」に変更、その目的は?]
しかし、今回の秘密鍵は、厳密に開発者に対して対外への 秘匿義務 が課せられます。
そのとき問題となったのは、従来、
 
 ・javascriptのブログパーツ
 ・FLASHのブログパーツ
 ・ブックマークレット
 ・Greasemonkey
 ・ユーザ配布型クライアントソフト (フリーウェア等)
 
などに 開発者IDを埋め込んで APIをコールしていたサービス/ソフトウェアの
扱いはどうなるのか? 全て使えなくなってしまうのか? という点でしたが、
このたび開発者向けフォーラムで現時点での公式回答が出ました。
 
■Re: 秘密キーまたはパスワードの「公開」の範囲について
http://developer.amazonwebservices.com/connect/thread.jspa?messageID=133111#133111
お待たせいたしました。開発チームからの見解が出ましたので、お伝えします。
今までにお問い合わせいただきました、
(中略)
のいずれのケースについても、理想的な方法とは言えませんが、条件付きで利用可能 であるという見解となります。
 
上記の実装を行っていただくにあたっての条件は以下の通りです。
1) すでにご質問においても提起されていますが、ユーザが何らかの方法を利用して秘密キーを参照・悪用するような事態が発生した場合に、速やかに秘密キーを変更(AWSアカウントページで随時変更可能です)いただくこと。。
2) 秘密キー変更後、速やかに新しい秘密キーを含んだ新しいアプリを既存ユーザに配布できるようご手配いただくこと。
もし、hack行為によってお持ちのIDが不正利用されているにもかかわらず、秘密キーの変更が速やかに行われなかった場合、Product Advertising APIチームによってアカウントがロックまたは停止され、このIDを利用したアプリが一切動作しなくなる危険性がありますのでご注意ください。

ちょっと順を追って説明します。秘密鍵を必要とする新APIでは、
基本的に自前のサーバ運用者からのAPIコールが前提でした。
これをどうしても開発者本人のサーバではなく、開発者が開発した
ソフトの配布を受けたクライアントユーザ側のPCからAPIコールを
行いたい場合、秘密鍵自体を 何らかの形で分かりにくいように
暗号化? して埋め込んでよいのかどうか、また、それがクラック
されたらどうなるのか? というのが質問のポイントでした。
 
その回答が上記になります。すなわち、Amazon側としては
秘密鍵をクライアントソフトに埋め込むことは 推奨しない 方式ではあるものの、
埋め込んで使うことは可能である、ただし、秘密鍵が他人にバレてそれが
他人に使われるような事態が発覚した場合、すみやかに 秘密鍵の無効化/再発行 を行い、
新しい秘密鍵を使ったバージョンを配布する義務がある、ということになります。
 
 
これは前回の記事で私が想像していたこととほぼ同じです。
 
■2009/05/09 [Amazon APIが電子署名必須の「Product Advertising API」に変更、その目的は?
Amazon APIが電子署名必須の「Product Advertising API」に変更、その目的は?]
すなわち、今度の秘密鍵は、その秘密鍵で作られた署名を持ったAPIコールは間違いなく「本人」が発した APIコールであるという責任を持ちなさい、ということになります。
秘密鍵がバレてはいけない、ということよりも、秘密鍵を他人に使われたら、
それは 自分がコールしたこととして記録 され、その責任も
負うことになる、ということのほうが押さえるべきポイントになります。
 
では、その責任とはどのようなことでしょうか。
幾つかあるとは思いますが、たとえばこんなコトが考えられます。
 
・AmazonAPIのサーバに 過度の負荷 を掛けない (目安 1コール/秒まで)
・AmazonのECサイトに誘導する 目的以外 で利用しない (規約に明記)
 
もちろん他にもいろいろあるとは思います。普通にAPIを使っている人であれば
そんなに気にしなくても良い条件かもしれませんが、もし秘密鍵がバレて
第三者にこのような使い方をされた場合、それを放置していたら自分の
アカウントが停止 になるかもしれないということは注意する必要があります。
 
また、前の記事でも言及したとおり、第三者に秘密鍵そのものがバレなくても、
自分の秘密鍵で第三者(クライアントユーザ)にソフトを使わせることで
発生したAPIコールは、全て自分の開発者IDの責任として受け止める必要が
あるでしょう。最も危険なのはやはり負荷の問題で、
 
■2009/05/09 [Amazon APIが電子署名必須の「Product Advertising API」に変更、その目的は?
Amazon APIが電子署名必須の「Product Advertising API」に変更、その目的は?]
一番顕著な例は ブログパーツ だと思いますが、
(中略)
これをやられると、たとえばそのパーツがもし 100万PV/day の大手サイトに貼られると、その ページが表示されるたびにAPIが 呼び出されることになります。すなわち1日100万回のAPIコールが生まれるわけです。

このような状態になった場合、秘密鍵がバレなければ済むという問題ではなく、
「あなたの秘密鍵からコールされすぎなので止めます」
という制御をAmazon側でしやすくなったということが今回の改正のポイントです。
 
だとしたら、秘密鍵の埋め込みは上記のフォーラムの通り「一応可能」では
ありますが、おそらくは1つの秘密鍵から生まれるコールが莫大な数に
なるケースでは制約を受ける可能性が低くないでしょう。
むしろ、おそらくはそうしたケースに制約を入れるための改正だからです。
 
 
ところで、javascript等に秘密鍵をバレないように埋め込むのは非常に
難しいでしょう。そこで、その解決方法の1つとして、tDiaryの作者で
有名なただただしさんが サーバ型proxy CGI を試作されています。
 
■Amazon API認証のPROXYを書いたよ(AmazonのAPI認証導入はOSSに対する挑戦だよなぁ(4))CommentsAdd Star
http://sho.tdiary.net/20090619.html
 
これは本来あるべき姿に戻ったというか、javascriptなどから直接APIを
呼んでいたケースについてはこのように自前のサーバ(CGI等)をクッションとして
クライアント直コール型から サーバ型に変換されるべき という意味で
非常にいい仕組みだと思います。
 
ただし、これで従来のクライアント型のアクセスがproxy経由なら問題なく
使えるようになって問題が全くなくなった、ということではありません。
クライアント型かサーバ型かというのはAmazonにとってはどうでも良いことで、
キーポイントは「誰の秘密鍵から何回コールされたか」ということです。
このproxy経由で 大量のコール が行われれば停止措置を受けるかもしれません。
 
そもそもこうしたproxyを開発者本人が運用してみると、おそらく何気なく
作って公開していたソフトウェア、ブログパーツ、Greasemonkeyなどがいかに
大量のAPIコールを生み出していたかということに開発者自ら気づかされること
になるでしょう。proxyをレンタルサーバ上に置いたら、いきなりproxy CGIの
負荷だけで レンタルサーバ側のアカウント停止 になったりするかもしれません。
(自分の作ったブログパーツが「痛ニュー」などいくつかの巨大サイトに貼られた
シーンを想像してみてください。 1日百万回のCGIコール は有り得る数字です)
 
そうなったら、きっとこうしたproxyも、ただ受け取ったコールをsignature
だけ付けて本家APIに流すのではなく、できるだけ proxy内部でキャッシュを
使って 負荷を軽くする努力をせざるを得なくなるでしょう。
 
こうした負荷軽減のための努力と責任を、開発者たる秘密鍵の持ち主に負わせて、
API提供者とAPI利用者が 「持ちつ持たれつ」 であることを理解させること、
また、それを理解せず悪びれずに何百万回もコールする利用者をシャットアウト
することこそが、この新APIの目的だとすれば、こうしたproxyを「巧く」作ることは
結果的に「持ちつ持たれつ」に貢献することになるのかもしれません。
逆に、クエリを単に右から左への受け渡しするようなオープンproxyは、それを公開
している本人のアカウント停止を早めるだけという気がしますので考えものです。
 
今回の Product Advertising API への移行は、Amazonが大量アクセスへの制御権を
持つための準備という話だと推測されますので、もしAmazon APIが無尽蔵に使える
共有DBだというイメージで気軽に使われていた方にとっては若干認識を見直す必要が
出てくるかと思います。ただ、これはあくまで憶測ですが、いきなり 1秒1回ルールを
厳密に適用してくるような厳しいお話ではないとは思っています。あくまで DDoSレベル
大量すぎるコールを発生させた人だけをカットするために活用されるのではと想像しています。
 
ちなみに私のほうは一応Signature付きへの移行を完了させました。ただ、
時々クエリの内容によって Signatureエラー が出ることがあって対処中です。。。

※追記 2009/06/24 23:55
Signatureエラーの原因を発見しました。
■署名の作成方法 Amazon アソシエイト(アフィリエイト) - ヘルプ
https://affiliate.amazon.co.jp/gp/associates/help/t126/a10
Perl におけるメモ: 一般に使われるURI:Escape CPANモジュールは、RFC2396を使用しています。ここでは、5つの追加予約文字が使用されています。アスタリスク(*)、右括弧(()および左括弧())、シングルクオート(’)およびエクスクラメーションマーク(!)。RFC3986を使用する場合は、以下をご利用ください: URI::Escape::uri_escape( $parameter_value, "^A-Za-z0-9\-_.~" )
そ・・・そんな罠が・・・ orz この通りにしたらピタッとエラーがなくなりました。


2009/06/21 [updated : 2009/06/21 23:59]


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




« MP4の映像/音声をコマンドラインでmuxできる「MP4Box」を試す。

トップに戻る

新サーバ組み立て計画妄想中 - あの頃最強だった Core 2 Duo E6700 は・・・ »


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

tinsep19 2009/06/25
負荷軽減のための努力と責任を開発者たる秘密鍵の持ち主に負わせてAPI提供者とAPI利用者が「持ちつ持たれつ」であることを理解させること、それを理解せず何百万回もコールする利用者をシャットアウトすることが目的
nilab 2009/06/25
Product Advertising API の秘密鍵とクライアント型ソフトに関する公式見解:「単に右から左への受け渡しするようなオープンproxyは、それを公開 している本人のアカウント停止を早めるだけという気がしますので考えものです」
horisanu 2009/09/13
Amazon Product Advertising APIについてのお話。
はてなブックマークで
コメントしましょう


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を複数指定できたというお話


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

ピックアップタグ




ブログ内検索



▼ コメント ▼


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