サーバー間のAPI認証問題を考えてみました。

仮に、サーバーと複数のクライアントが有るとします。

サーバー上でAPIのパッケージを実行したいとします。このAPIは複数のクライアントに使用される場合が有ります。ただ、誰でも使えるわけではなく、認証されたクライアントのみに使用できます。この場合はどのように認証をするかを考えてみました。

IP制限

もっとも簡素な方法の一つとしては、IP制限になります。ただし、IP制限はよりコントロールされたネットワークの中では有効で、IP Spoofingに遭遇しましたら、一溜まりも有りません。クライアントのサーバーを同一のLANに制限することは非現実的なので、IP制限を避けたほうがいいと思います。もう一点は、IP制限はサーバー移行やIP変更の時に結構漏れやすいです。動的IPのクライアントさんには全く通用しません。

非対称のキー

もっとも有名な非対称キーは多分RSAでと思います。PKCS#1としてネットの一つの標準になっています。クライアントがサーバーの認証を求めたい場合は、サーバーの公開キーを使って、IDとパスワードを送信します。サーバーは秘密キーを使って暗号化のパスワードを解読して、IDとパスワードをチェックします。有効なIDとパスワードだと確認できた場合は、一時アクセスキーを発行します。その後の一定期間において、この一時アクセスキーを利用して、個々のコールの認証を行います。

RSAで暗号化できる文字列の長さは限られますから、一時アクセスキーを発行せざるを得ません。

しかし、このパタンに一つ致命的な問題が有ります。毎回送信される暗号文は同じです。この暗号文され取られれば、認証は撃破されます。一つ簡単な改善策はIDとパスワード以外に、今の時間を一緒に送ります。つまり、IDとパスワードと時間を一つの組として暗号化されます。そうすれば、時間の経過とともに、認証用の暗号文は失効します。再利用はできなくなります。安全性は多少上がります。ただ、これもやはり甘いです。原因は簡単です。ネットではデータ転送のスピードはある程度不可知です。発信の時刻と着信の時刻はどのくらいの差が有るか、明確ではありません。このため、時間により有効性チェックは全部有る程度の含みを残します。この含みは落とし穴になります。ハッキングはリアルタイムで進行しますから、暗号文を取られてから即時にハッキングに使用されます。こうなれば、時間のチェックを通過できるようになります。不当に認証される異になります。

上記の考えで、この方式も却下されました。

データダイジェストの問答式

どんな認証方式であっても、サーバーとクライアントの間に共通の秘密を保持する必要が有ります。「非対称キー」の問題はその秘密を直接に送信している点に有ります。この問題は毎回変わらないから、不正のアクセスに利用されやすいです。このため、毎回送信の内容をランダムに変化させます。一回送信の内容は一回しか使用できません。ハッカーは一回の認証用暗号文を取得できたとしても、再利用はできず、元のパスワードを推測する事もほぼ不可能です。安全性は高いです。

この方式にも問題点が有ります。一回のみ有効のものはサーバーとクライアントは共有していないため、クライアントがサーバーに請求して、もらってくる必要が有ります。つまり、一回多くAPIをコールする必要が有ります。

具体に、一回目のコールにサーバーからランダムの問題文を発行します。二回目のコールでクライアントはパスワードを使って問題文を処理した結果を回答をサーバーに送信します。サーバーは回答を確認して、一時アクセスキーを発行します。

一時アクセスキーについて

一時アクセスキーはただ往復に送信されては、前の同様な問題が発生します。このため、コールに一定のシリアル番号又はその暗号を保持したほうがいいかもしれません。ただ、同一サーバーから複数の平行コールを許したい場合は、この方式はできなくなります。

APIコールは一般にHTTPSを介するので、認証後の情報漏洩する場合は少ないかもしれません。最初の認証ステップはパスワードを特に厳重に守るものです。

実際は一時アクセスキーも一回だけネットを介したほうがいいです。必要であれば、一時アクセスキーをクライアントの公開キーで暗号化して送信します。しかし、運用上、クライアントに非対称キーを発行させることはあまり考えられません。サーバーで発行して、秘密キーを送るか、初回でHTTPS以外に暗号化せずに送信するか……

毎回一時アクセスキーを送ることを避けたいのであれば、一時アクセスキーを使って、APIのパラメータのメッセージダイジェストを算出して、このダイジェストを一緒に送信すればサーバーは個々のコールに検証できるようになります。

纏め

セキュリティを考えますと、いろいろとやらなくては、……

Leave a Reply

Your email address will not be published. Required fields are marked *