一般的なAPI認証手法のユースケースとメリット
英語によるオリジナルはこちらでご覧いただけます。
企業が成長して知名度が高まってくると、必然的にAPIの攻撃対象領域が広がり、データ漏洩のリスクが高まります。クラウド通信の安全を確保し、転送中のデータを保護することは、企業にとって最優先事項です。
API認証を導入していれば、正規のユーザーのみがアプリケーションの機能やサービスにアクセスできるようになります。その際、自社のニーズに合わせた形で認証手法を取り入れることが重要です。社内で利用しているフレームワークを精査し、適応を図ることで、アプリケーションのインフラとユーザーの両方のセキュリティを大幅に強化できます。
API認証とは
APIはアプリケーション同士を接続する手段を提供し、すばやいデータ交換やサービスのやり取りを可能にします。しかし、企業がアプリケーションを拡大するなかで、APIはハッカーの標的となってきました。開発チームは、アプリケーションサービスにアクセスしようとするユーザーを認証する手段を講じる必要があります。そうすれば、盗まれた認証情報を使ったなりすましによるアクセスを防ぎ、確実な本人確認が可能になります。
API認証とは、アプリケーションにアクセスしようとするユーザーのアイデンティティ（身元）を、ソフトウェアのプロトコルにより検証するプロセスです。ユーザーがAPIコールを実行するときに、プロトコルに従ってログインの認証情報が暗号化形式でリモートサーバーに送られ、ユーザーの本人検証と、アクセス可否の判定が行われます。認証情報が不正であった場合、APIへのアクセスはブロックされます。こうして、悪意の可能性がある行為からAPIを守ることができます。
認証とは、企業側の尺度でアイデンティティを検証するプロセスです。これにより、APIセキュリティの土台とすることができます。
ベーシック認証
HTTPのベーシック認証は、非常にシンプルな認証方式です。APIコールごとにユーザー名とパスワードをHTTPヘッダーに格納して送信します。セッションIDやログインページ、Cookieは必要ありません。誰でも扱える単純明快なソリューションとなっています。
ベーシック認証のメリットとデメリット
メリット
- 実装が容易 — HTTPのベーシック認証の最大のメリットは、実装がシンプルで、システム間の互換性が保てるところです。メリットはそれだけだと考える人もいます。
デメリット
- 脆弱性 — 昨今では、認証手段としてベーシック認証のみ使用することは推奨されません。なぜなら、認証情報が暗号化されていないからです。ユーザー名とパスワードのペアを受け渡すたびに、攻撃者がその内容を傍受して中間者攻撃などの不正な行為に及ぶリスクが生じます。
- ログアウト機能 — ログアウト機能はありません。この問題を回避する手段もありますが、方法はブラウザごとに異なり、サポートされていない場合もあります。
- パスワードのリセット – ベーシック認証ではパスワードのリセットが難しいため、ユーザーが認証情報を紛失した場合にセキュリティ上の問題が生じます。
APIキー
APIキーとは、APIユーザーの認証に使う一意の識別コードです。APIキーは、個別のアクセス制御を確立するために各APIユーザーに割り当てるという点で、API認証における最も基本的な要素の1つです。
ユーザーは、APIにアクセスしようとするときに、一意のAPIキーをセキュリティシステムに渡します。（初めて利用するユーザーは、別途アイデンティティの検証を済ませ、APIキーを受け取っておく必要があります）。渡されたAPIキーが有効であれば、セキュリティシステムはアクセスを認め、そうでなければアクセスを拒否します。このプロセスは数秒足らずで完了するため、セキュリティプロトコルを効率化したい開発チームにとっては実用的な手段です。
APIキーのユースケース
APIキーは、認証プロトコルとして非常にシンプルかつ効果的であるのに加え、APIインターフェースに対するアクセスの制御や管理にも使われます。開発チームは、アプリケーションがアクセスされた理由や手段について情報を獲得し、不正な行為や権限の濫用を未然に防ぐことができます。
APIキーは、ユーザーの識別と認可だけでなく、プロジェクトの識別と認可にも対応します。呼び出し元のアプリケーションに認可が与えられているかどうかは、プロジェクトでそのAPIが有効化されているかどうかから特定できます。開発チームはこのプロセスの柔軟性を活かして、APIを特定の環境でのみ使用できるようにしたり、APIの使用状況に関する情報を統合したりできます。特に、適切なアクセス権を持たないプロジェクトからの呼び出しを拒否するためにも、APIキーは重要です。
APIキーのメリットとデメリット
メリット
- HTTPより強力 — APIキーは、一般に推測が非常に難しいという点で、HTTPのベーシック認証よりも優れています。特に、長いキーの推測は困難です。
- トラフィック制御 — APIクライアントが使用傾向を把握して、APIの呼び出し回数の制御を行えます。匿名トラフィックをブロックしたうえでの問題のトラブルシューティングやデバッグ、APIトラフィックの傾向分析を行うこともできます。
- フィルタリング — APIキーを使ってログを簡単にフィルタリングできます。
デメリット
- 認可への対応が不十分 — APIキーは、認可用として完璧とは言えないことが大きなマイナス面です。攻撃者がAPIキーを手に入れたてしまうと、アプリケーションのすべてのデータとサービスにアクセスできてしまいます。
- ユーザーの識別 — APIキーはユーザー個人ではなくプロジェクトのみを識別できます。
- プロジェクトの作成者 — APIキーはプロジェクトの作成者を特定できません
ダイジェスト認証
ダイジェスト認証は、サービス事業者がウェブブラウザを通じて個人の認証情報を検証するためのアクセス認証方式です。ベーシック認証を多少強力にして、パスワードの伝送を不要にしたバージョンと考えることができ、HTTPとSIPの両方で使われています。ダイジェスト認証では、暗号化した状態のユーザー名とパスワードをサーバーに保存しており、攻撃者に解読され得る形式でクライアントからパスワードを送信する処理を排除しています。具体的には、認証情報にハッシュ値を付加することによって、ユーザーのパスワードを平文で送らなくてもサーバー側で認証できる仕組みになっています。
ダイジェスト認証のメリットとデメリット
メリット
- 暗号化 — 平文ではなく、ハッシュで暗号化したパスワードをサーバーに送信できます。
- RFC 2617のナンス — RFC 2617で規定されたナンスを使うことで、悪質な脅威に対抗できます。
- クライアントの属性のチェック — クライアントのナンスの属性とタイムスタンプをサーバーでチェックします。
- 再利用の阻止 — ナンス値のリストを保持し、ハッシュ値を適用することで、再利用を防ぎます。
デメリット
- 攻撃対象領域 — ダイジェスト認証も中間者攻撃（MitM攻撃）を受ける可能性は依然として残っています。その場合、攻撃者がクライアントに対し、ベーシック認証を使用するよう指示する可能性が考えられます。
- サーバーの識別 — クライアントはサーバーのアイデンティティを検証できません。
- モードの混在 — 一部のセキュリティ項目は任意であるため、セキュリティ強度が低いモードでクライアントが運用される可能性があります。
- 可逆暗号化 — パスワードを保管する際に可逆暗号化を用いた場合、攻撃者に平文のパスワードを意図せず奪われる可能性があります。
OAuth 2.0
OAuth 2.0（Open Authorization）は、オンラインでの認可に使われている業界標準のプロトコルです。外部のウェブアプリケーションが保持しているリソースへのセキュアなアクセスや、外部のアプリケーションから受け入れるリソースアクセスの制御を、認証情報を共有することなく行えるように設計されています。アプリケーションが実行できる操作が制限されるよう、アクセスに関してユーザーの同意を得る仕組みが取り入れられています。
OAuth 2.0の仕組み
重要なのは、OAuth 2.0は認可のためのプロトコルであって、認証のためのプロトコルではないという点です。つまり、このプロトコルの主な役割は、ユーザーデータなどのリソースやアプリケーションへのアクセス権を付与することにあります。これを実現するために、OAuth 2.0ではアクセストークンを使用します。アクセストークンとは、ユーザーが認可を受けたしるしとなる、ひとまとまりのデータです。このトークンにデータを挿入することで、セキュリティはいっそう強固になります。
OAuthの処理の流れはこうです。クライアントは、サーバーから認可を得るためのリクエストを開始し、自らの身元を証明するクライアントIDを渡します。これを受けて認可サーバーは、そのクライアントを認証し、要求で示された一連のリソースにアクセス可能なクライアントであることを確認します。サーバーは、認可を与えてよいかどうかリソースオーナーに確認を取ったうえで、クライアントにアクセストークンや認可コードを返します。最終的にクライアントは、この新しいアクセストークンを使って、リソースサーバー内のリソースへのアクセスを要求できます。
OAuth 2.0のメリットとデメリット
メリット
- 汎用性 — OAuth 2.0はHTTP/HTTPSヘッダーでトークンを渡す仕組みになっているため、ウェブサイト、プラグイン、モバイルアプリ、デスクトップアプリなど、あらゆるソリューションに適応できます。
- SSL — OAuth 2.0は、暗号化の確保やユーザーのアクセストークンの保存のために、Secure Sockets Layer（SSL）を使用しています。
- セキュアなアクセス — OAuth 2.0は、認証情報や個人情報を明かすことなく、ユーザーデータのアクセス制御や共有を行います。
デメリット
- サービスの混在 — 各サービスでそれぞれ独自の実装が必要です。連携する相手ごとに別々のコードを作成することになる可能性があります。
- 検証のリクエスト — ユーザーの検証に必要な情報を取得するために、複数のリクエストが必要となる場合があります。
- 横並びの構造 — 中心的なハブとアカウントが複数のサイトにわたって連携しているため、いずれかが攻撃を受けた場合には、それらのサイトに影響が及びます。
- トークンデータ — トークンを盗んだ攻撃者は、そのトークン内の秘匿性の高いデータに一時的にアクセス可能となります。
JWT（JSON Web Token）
JSON Web Token（JWT）は、送信元と送信先の間でJSONオブジェクトを使って情報を安全かつセキュアに伝送する手段を提供するオープン標準です。暗号化したユーザーデータをJWTに格納し、アプリケーション間でニーズに合わせて伝送します。JWTはサイズが小さいため、HTTPヘッダーやURLに組み込んで迅速に送信できます。JWTには署名を付加できるため、クライアントはユーザー認証のうえで追加のデータを格納できます。ユーザーやエンティティに関する必要な情報すべてをトークンに格納することで、データベースに対して複数回にわたりクエリを送る必要がなくなります。
JWTのメリットとデメリット
メリット
- シンプルな実装 — JWTの署名アルゴリズムはXMLに比べてはるかにシンプルで、セキュリティ脆弱性も抑えられています。
- トークンのサイズ — JWTはエンコードした状態でのサイズがSAMLトークンよりも小さく、HTTPやHTMLの環境に理想的です。
- 使いやすさ — JWTの受信側は、トークン検証のためにサーバーを呼び出す必要がありません。またJWTは無効化も簡単です。
- 幅広い用途に対応 — 大半のプログラミング言語ではJSONパーサーを使ってドキュメントからオブジェクトへ明確にマッピングできることから、パーサーの扱いが簡単です。
デメリット
- APIコールのサイズ — APIリクエストのたびにヘッダーでJWTを渡す必要があるため、ネットワークのリクエストのペイロードが大きくなります。つまり、JWTを使用すると大半のAPIコールのサイズが増加します。
- キーのセキュリティ — トークンのアクセスキーを奪われた場合、システム全体が攻撃者にアクセスされる可能性があります。このため、キー自体や、キーにアクセス可能なユーザーに関するセキュリティマネジメントの負担が高まります。
- アクティブユーザー数の把握 — トークンを発行済みの状態のときに、サーバーはユーザーの状況を把握できません。代わりにユーザーがトークンを更新する必要があり、それによって初めてサーバーは情報を得られます。つまり、サーバーはアプリケーションのアクティブユーザー数を正確に特定できません。
- バックエンドでの管理 — バックエンドからのクライアント管理がより難しくなる場合があります。サーバーからユーザーに新しいJWTを割り当ててからでないと、アクセス権の編集や更新を行えません。
OpenID Connect
OpenID Connect（OIDC）はOAuth 2.0フレームワークを基盤とするオープン標準の認証プロトコルです。外部アプリケーションがユーザーIDの検証や基本的なユーザープロファイル情報の取得を効率的に行える仕組みとなっており、個別に認証情報を管理する必要がありません。OIDCは、保護されているリソースへのアクセスや、ユーザーに付与された認可をAPIサーバーに伝えるために、JSON Web Token（JWT）を使用します。
OpenID ConnectとOAuth 2.0の違い
OAuth 2.0とOIDCは連携して機能しますが、OAuth 2.0はリソースアクセスに主眼が置かれ、OIDCはユーザー認証に主眼が置かれています。OIDCによってユーザーのログインプロセスは効率化され、ウェブサイトにログインする必要があるユーザーはOpenIDのサイトにリダイレクトされます。そして、ユーザーの情報にアクセスする認可がOAuth 2.0に与えられた後で、ユーザーは元のサイトに戻されます。認証が完了したユーザーはアクセストークンを受け取ります。
OpenID Connectのメリットとデメリット
- 情報の保管が容易 — ユーザーが複数のサイトを利用する場合に、接続に必要な情報の保管をOpenIDに委ねられるため、自分のシステムに認証情報を保管しておく必要がありません。
- 認証の委託 — サイトへのログイン機能をユーザーに提供するときに、堅牢なセキュリティシステムを備えたOpenIDプロバイダにユーザー認証を任せられます。
- シンプルな実装 — OAuthを他の手法と組み合わせる実装に比べて、OpenIDの方が、プロセスがシンプルになります。
デメリット
- ユーザーデータの管理 — OpenIDは認証サービスであり、OAuthのような認可のシステムではないため、ユーザー情報の取得、削除、編集のためのリクエストを署名付きで行うことはできません。
- 攻撃者の水平展開 — OpenIDは非常にセキュアですが、ユーザーのOpenIDの認証情報が攻撃者の手に渡った場合に、攻撃者がネットワーク間を移動する可能性があり、発見や防御が難しくなります。
- 拡張機能 — OpenIDの拡張機能のサポートや、そうした拡張機能でアクセスできる情報は、OpenIDプロバイダごとに異なります。
HMAC（Hash-Based Message Authentication Code）
Hash-Based Message Authentication Code（HMAC）は、暗号鍵とハッシュ関数を使用するメッセージ暗号化手法の1つです。この認証手法では、サーバーとクライアントは、両者のみが知るプライベート鍵（共有シークレット）を使用します。元々のMessage Authentication Code（MAC）よりもセキュアな手法です。HMACのやり取りでは、クライアントとサーバーは、秘密鍵とハッシュ関数を使って、やり取りするメッセージを復号できます。
HMACのメリットとデメリット
メリット
- 攻撃対象領域の縮小 — HMACでメッセージを永続的にハッシュ化することにより、秘密鍵なしではメッセージにアクセスできなくなります。中間者攻撃やリプレイ攻撃など、悪意のある攻撃やセキュリティ侵害のリスクを抑えるうえで、このセキュリティ手法は効果的です。
- コンプライアンス — HMACの暗号アルゴリズムを使用し、信頼できるサービスのみがアプリケーションとやり取りできるようにすることで、企業はGDPRなどの基準を遵守しやすくなります。
- シンプルな統合 — HMACは広く利用され、多くのプログラミング言語がサポートしていることから、既存のワークフローとの統合が簡単です。
デメリット
- キー管理 — HMACは秘密鍵に依拠していることから、秘密鍵を手に入れた攻撃者はシステム全体を侵害できることになります。したがって、完全なキー管理のプロセスを組織として取り入れておく必要があります。
- 早期の検出 — HMACはメッセージの改ざんの検出能力という面でやや制約があることから、他のセキュリティプロトコルをあわせて導入して、包括的なアプリケーションセキュリティを確立する必要があります。
- 攻撃の阻止 — HMACは、リプレイ攻撃などの特定の攻撃を事前に特定することはできるかもしれませんが、攻撃の阻止はできない場合があります。
相互SSL/TLS認証
セキュアなオンライン通信について学んだ経験があれば、Secure Socket Layer（SSL）プロトコルは聞いたことがあると思います。SSLのもとでセキュアサーバーに接続しようとするブラウザは、公開鍵とプライベート鍵による暗号化を基盤として、サーバーの証明書を検証できます。また、相互認証の仕組みを利用することも可能です。その場合、クライアントとサーバーの双方が署名付き証明書を使用して、互いのアイデンティティの認証や検証を行います。
相互TLS（mTLS：Mutual Transport Layer Security）は、サーバー、アプリケーション、ユーザーの間のデータ伝送を認証するための暗号プロトコルであり、SSLの強化版です。mTLSでは、通信を行う双方がデジタル証明書を互いに認証し、暗号化されたTLS接続を確立します。mTLSはゼロトラストセキュリティのフレームワークにおいて組織内のデバイスやユーザーに適用される場合が多いほか、アプリケーションのクラウド環境を強化してAPIのセキュリティを維持する役割も担っています。
相互SSL/TLS認証のメリットとデメリット
相互SSL/TLSのメリット
- セキュアなデータ伝送 — 相互認証がない場合、ウェブサーバーとのデータのやり取りを攻撃者が傍受して改ざんする可能性があります。SSL/TLSの暗号化プロトコルを使用することで、不正な攻撃を防げます。
- ユーザー検証 — SSL/TLSを使用して、ウェブサイトのユーザーが本人であることを検証したうえでオンライン取引を進められるため、安全なビジネスが可能になります。
- 信頼性 — 相互SSL/TLSは広く信頼されているプロトコルであることから、顧客やビジネスパートナーからの信用につながります。
相互SSL/TLSのデメリット
- 初期コスト — 相互SSL/TLSの証明を得ることは簡単な作業ではありません。そのため、証明書の初期コストが高く思えるかもしれません。しかし、こうして実現されるセキュリティ機能には、その価値があります。
- モバイルへの実装 — SSL/TLSはもともとウェブアプリケーション向けとして考案されており、一部のモバイル構成は依然として機能が追いついていません。厄介なセットアップやモバイル向けモジュールが必要になる可能性もありますが、それでもSSL/TLS認証は最善の手段です。
- モードの移行 — SSL/TLSに移行する過程で、一部のファイルが引き続きHTTPで伝送される場合があります。データのセキュリティについての警告メッセージが表示されて、ユーザーが当惑する可能性があります。
まとめ
自社に合ったAPI認証方式を選択するにあたっては、API認証とAPI認可の違いを頭に入れておく必要があります。認証は、ユーザーのアイデンティティを検証します。認可は、ユーザーがアプリケーションにアクセスできることを確認します。
APIセキュリティにおいて、認証は不可欠な要素です。認証を行うことによって、アプリケーションのサービスが保護され、承認したユーザー、サーバー、アプリケーションのみがサーバーへのAPIコールを実行できます。適切な認証方式を選択するには、まずは自社のAPIのフレームワークやインフラにどの方式が適合するかを判断しましょう。そのうえで、包括的なセキュリティを実現できて、開発チームに過大な負担を与えることのないソリューションを選択します。
KongのクラウドネイティブAPIプラットフォームは、こうした一連のプロセスをお客様が容易に進められるよう支援します。複数の認証方式やセキュアなデータ伝送に対応するサービスがあり、盤石のAPIセキュリティ戦略を実現します。お客様は、製品やビジネスソリューションに専念する時間を増やすことができます。
アプリケーション開発を強化する方法の詳細については、Kongにお問い合わせください。