アプリ、Webサービスと数多くのインターネットを使ったサービスが登場するのに比例してWeb APIも次々と作られています。Web APIのマーケットが拡がっていくことで認知が高まり、さらにWeb APIが開発されていくという好循環が生まれています。
その一方で乱立することによって、Web APIの品質が問題になってきます。Web APIではWebブラウザを使ったアクセスとは異なり、基本的にプログラムからのアクセスを考えなければなりません。そのため不用意なセキュリティホールがあったりすると、あっという間に大きな問題（データの消失であったり、乗っ取りであったり）が発生する可能性を秘めています。
そこで私たちはWeb APIの設計に際して標準規則を策定しています。その規則に沿ってWeb APIの開発を進めることで、可用性はもちろん堅牢性や安全性を意識した情報の提供ができるようになります。これまでのインタフェース、データフォーマット、バージョン管理、同期・非同期に続き、今回は セキュリティ について規則の一部を紹介します。
認証処理の種類
Web APIの種類によって以下の選択肢が考えられます。
- OAuth 2.0
- HMAC
- APIトークン
- SSLクライアント証明書
認証なしでのWeb API利用やBasic認証での利用は原則としてお勧めしません。
通信はHTTPS
外部に公開されるものについては正規のSSL/TLS証明書を用いますが、社内システム間や社内の接続元が保証される場合においては独自の証明書でも可能としています。しかしデータ漏洩防止の観点から、Web APIはHTTPS接続のみと言うのが安心でしょう。
定期的な監査、クリーニングの実施
Web APIの利用時はアカウント、またはアプリケーションごとにトークンを発行します。しかしこの手の運用として不要となった時に適切に削除されていないことが多々あります。トークンの利用状況について一覧できる画面または機能を予め用意した上で定期的に整理するのが重要です。
また、ログを適切に残すことにより不正アクセスに対して対応することができます。ここでいう不正アクセスとは例えば、
- パラメータ改ざん
- DoSアタック
などが考えられます。パラメータ改ざんについてはシステム側でのバリデーション、SQLインジェクションチェックなどを適切に行うことで回避が可能です。DoSや大量アクセスについてはWeb APIという仕様上致し方ない部分もありますが、閾値を超えた段階でそのためのエラーコードを返したり、予めレスポンスをキャッシュする機構を組み入れておく必要があるでしょう。
レスポンスは200ms以下で
Web APIのレスポンスは基本、200ms以下であるべきと考えています。これは一定の基準であって、システムによって異なる場合があります。ただし基準を設けることで性能劣化に気づくことができたり、重たいWeb APIについては機能を分割すると言った工夫もできるようになるでしょう。
Web APIはシステムから自動的に操作されることが多いため、問題があると一気にすべてのデータが漏洩したり、削除されたりする可能性を秘めています。そのためセキュリティ要件については特に慎重に考える必要があるでしょう。
ぜひ皆さんのWeb API設計において参考にしてください。
