APIの始め方(日付、時間の管理)
前回は、APIのバージョン管理についてまとめました。今回は、Data/Time管理についてです。
API開発における時間の管理には、時間、分、秒、小数点以下の桁数(例:yyyy-MM-dd’T’HH:mm:ss.SSS’Z ‘)を含むISO 8601の時刻形式を使用します 。
RESTサービス本文の内容(リクエストとリスポンスの両方)上で表されるすべての日付に、ISO 8601を使用することが推奨されます。
因みに、ブラウザベースのUIを作成する場合、ECMAScript 5仕様には、JavaScript上でネイティブに、ISO8601の日付を解析して作成する機能が含まれています。その為、主流のブラウザは、このISO8601にすべて対応しています。
それらの日付をネイティブに解析しない古いブラウザをサポートしている場合は、JavaScriptライブラリやファンシーな正規表現が整っています。
JSのライブラリーとしては、次の2つが挙げられます。
HTTPの仕様によって、JSONとXML以外の形式データを扱うことができますが、常に次のようなTimeStampをつかって時間を扱う事が推奨されます。
// this is implemented in your request headers
Sun, 06 Nov 1994 08:49:37 GMTこの形式は、ミリセカンドまでを扱うことが出来ない、デメリットがあります。
次は、認証機能についてです。APIのセキュリティを向上させる為にも、認証された経路(ドメイン)からのみ、APIにリクエストを送れるようにします。
その為に、次の処理が必要になります。
- clientはリクエストを送る際、認証のTokenをリクエストに含ませる。
方法はX-Authorization headerまたは、クエリの引数に持たせる。 - サービスは、渡されるTokenの内容を解析して、Tokenの認証を行う
- サービスはTokenにもとづいて、認証機能を施行する処理を呼んで、リクエストされたデータを返すかどうかを決定します。
- 認証されたら、サービスは通常の処理を続けます。
3の処理は、キャッシュ可能なアクセス制御リスト(ACL)を使用すると、より簡単に実装できます。これによって、最新のACLをキャッシュして、リモート呼び出しを行う前に、ローカルで検証する認証clientを作成することが可能になります。
実際には、現在のベストプラクティスは、認証にOAuthを使用することです。
加えて、OpenIDを追加の認証オプションとして使用することが推奨されます。
OAuth2では、TLSを使用するために認証サーバーとaccess Tokenの資格情報が必要なことにも、注意します。
サービス自体の認可についても、アプリケーションの認可同様、認証機能をサポートするAuthenticationを構築します。そのサービスには、どの人やシステムがアクセスするのかを、認証サービスを通して制限します。
アプリのセキュリティに関しては、次の要件を満たすことがREST APIの条件になります。
- 全ての入力値を検証します。正しくない値は拒否する機能を実装します。
- SQLインジェクションを防ぎます。
- 既存のライブラリー(Anti-XSS, or OWASPなど)を使って、値をサニタイズさせます
- メッセージのサイズを制限します。
- エラーメッセージには、一般的なメッセージを表示します。
- ビジネスロジック攻撃を検討する。例えば、複数の処理を必要とする時は、それら処理を一つ一つ通ることを、サービスはユーザーに求めます。
- 疑わしい活動を記録する。
- JSONとXMLデータを検証して、不正なデータとの区別をつけます。
- HTTPメソッドは、許可されたものだけを使用できるようにします。また、それぞれのメソッドは、その機能にあった処理だけを行います。
- 競合状態に注意します。
- APIの使用状況を監視し、正常な使用パターンから逸脱するものが何であるかを確認します。
- 悪意のあるユーザーがAPIエンドポイントをダウン(DOS攻撃)できず、悪意のあるIPアドレスをブロックする為にも、APIの使用に制限をかけます。
- API keyは暗号化された保管場所に置きます。
以上がAPI設計時の、セキュリティ事項になります。
次はキャッシングについて、まとめていきたいと思います。
