本記事は主に技術者向けです。今回は高いセキュリティを持つ RESTful API の設計方法について考察したいと思います。
RESTful すなわち REST (Representational State Transfer) モデルの API (アプリケーション・プログラミング・インターフェイス) とは、インターネットを介しHTTPアーキテクチャを用いたサーバ間のリクエスト通信を指します。
最近はインターネット＝Webページというイメージを持つユーザが多くなってきていると思いますが、イコールという概念は間違いです。WebページはHTTPというプロトコルで通信しています。インターネットの利用方法のひとつにHTTP（プロトコル）があるだけで、HTTPはインターネットに内包しているという関係性です。HTTPの他にFTPやSSHなどインターネット上に幾つかのプロトコルが存在します。
前述の通りHTTP通信を用いて他のサーバに対しデータリクエストを行うのが RESTful API ですが、他のサーバとの通信をする以上、ネットワークセキュリティの確保が最優先事項となります。よく新聞テレビで官公庁や企業のサーバから情報漏洩したというニュースがあります。もちろん悪いのは攻撃者のハッカー（厳密には悪意を持ったハッキングをする者はクラッカーといいます）ですが、自転車の鍵を掛けずに駅前駐輪場に置いていた被害者に１００％責任が無いとは言えないように、クラッキングを受けた被害者にも最低必要なセキュリティを確保する義務があるわけです。
漏洩した組織は多くの場合、最低必要なセキュリティが確保されていなかった為に情報漏洩が発生しています。国の機関でも有名大手企業でもセキュリティ確保の重要性を認識しているにも関わらず、漏洩事故が発生するのは、エンジニアがネットワーク・セキュリティ分野に関してスキル不足であるからに他ありません。意外とネットワーク・セキュリティに精通したエンジニアはそう多くないのが実情です。それは一般の方には信じられないと思いますが大手ＩＴ企業でさえハイレベルのネットワークセキュリティエンジニアが居ないケースもあるのです。
さて、そろそろ本題に入りましょう。この記事で国内のインターネットセキュリティの多少の貢献が出来ることを願いつつ執筆したいと思います。
RESTful API の設計にあたり、システムのフロントエンドとバックエンドは常に意識しなければなりません。フロントエンドは常に漏洩危険性は高いハイリスク側、バックエンドはローリスク側とイメージしてください。バックエンド＝サーバ側ですが、クラッキングルートとしてバックドアを仕掛けられるような事は本記事はあくまでもAPI設計という趣旨から外れるので他の文献を参照してください。それを前提とします。
まず個人情報など重要データのアクセスは、必ずパスワード付きのログイン機構を経由するよう設計します。ログイン機構はOAuth 2.0 や OpenID で確保してください。簡易的方法であれば Basic認証でも良しとしますが、その場合、必ずSSL通信で行ってください。SSLと言っても現時点の場合、TLS 1.2 もしくは TLS 1.3 であることがポイントです。これで一定のセキュリティを確保できます。
ログイン機構で認証成功したら、Token をクライアントへ送り Token が有効であるクライアントのみに対し重要データを送信するようにしましょう。もしクライアント側で Token をCookie保存させる場合、必ず Cookie には Secure 属性と HttpOnly 属性を付加してください。
あらゆる RESTful API へのリクエスト偽装は可能です。よくあるケースとしてHTTPリファラーで安全性を担保している勘違いが散見されますが、HTTPリファラーは偽装することができることに注意してください。
また、CORS（Cross Site Request Forgery – オリジン間リソース共有）をサーバ側で設定すれば安全という考えもNGです。CORSはあくまでもブラウザ側で解釈しているに過ぎません。攻撃者のbotプログラムはCORSをスルーすることに注意してください。
パブリック向けWebシステムではなく、組織内のプライベートシステムであれば、IPアドレスでの制限は有効です。サーバで受け取れる REMOTE HOST はアプリケーションサーバのIPアドレスではなく、ユーザ端末のIPアドレスなので、パブリック向けシステムで IPアドレスでの規制はほぼ意味を為さないでしょう。
APIキー方式でのアクセスが通常よく使われます。多くの場合、40バイト程度のAPIキーとHTTPリファラー、CORS を結び付けて一定の安全性を担保することはできますが、このパターンはクラッカーにとって何の障害にならないことに注意してください。重要データをやり取りするケースでは、必ず認証してTokenを渡し、Tokenでデータリクエストするというプロセスが必須です。
しかし上記以外にも方法が存在します。公開鍵（パブリックキー）と秘密鍵（プライベートキー）を用いて電子署名する方法です。
RESTful API のアプローチでは APIサーバ、アプリケーションサーバ、クライアントの３者が存在します。APIサーバに公開鍵、アプリケーションサーバに秘密鍵を持たせ、アプリケーションサーバがAPIサーバへリクエストする際、秘密鍵で電子署名して暗号化して送信することで、認証プロセスを省略しつつも安全性を担保できる設計となります。
ただしこの公開鍵＆秘密鍵のやりとりはクライアント側で実施することはパブリックシステムの場合、現実的ではありません。秘密鍵が公開された状態になるからで、秘密鍵を漏洩したのではセキュリティにならないからです。
認証方式の場合、HTTPSでユーザが入力したパスワードは本人とサーバ以外に漏洩することはまず無いと考えて良いでしょう。なので、直接パスワードを送ってその時点で認証プロセスを完了させるという設計はセキュリティ的に安全です。
秘密鍵、公開鍵方式は、サーバ間でHTTPS通信して行うので、安全に情報をやりとりすることが可能です。なお秘密鍵、公開鍵は現時点であれば 2048ビット長で確保したいところです。
思い付いたところでは、このような感じでしょうか。
また気付いた点があれば、本記事を更新したいと思います。
そして当然ですが、これらの技術は FormOK に既に取り入れています。
FormOK 技術チーム
