パブリックAPIセキュリティ：認証とレート制限など
私たちは、SaaS製品を調達して、企業が特定のクラスの商品/サービスの販売を設定および調整できるようにします。この製品は、そのコアにAPIを持ち、さまざまなアプリのエコシステムを持っています。これら一般向けのWebアプリ（サイト）、WebベースのCMS、営業スタッフ向けのiOSアプリなど、クライアントはこれらを使用するか、独自のアプリを作成してAPIと通信できます。
APIをどのように保護するかについては、私たちの間で長い議論がありました。認証（アプリのAPIキー/シークレットとユーザーのユーザー名/パスワードの両方）とロール/権限ベースの承認があります。現時点では、リクエスターが自身を認証しない限り、APIから（そのバージョンは別として）有用な応答を取得できません。 これには、販売アイテムのリストなど、一般に公開されているデータを返すエンドポイントが含まれます。
根本的なポイントは、APIが本質的にパブリックデータであるものに対して認証を必要とするかどうかです。
認証の引数：
- パブリックWebアプリを利用して情報を取得できたとしても、APIを呼び出したい人に公開したままにすることはできません。オープンAPIは、悪用されたり、ロード攻撃を受ける可能性があります。防御の最初の行となるクライアントアプリごとにキー/シークレットを発行することにより、誰がアクセス権を持つかを制御する方が良い。
認証に対する引数：
- とにかく公開されているものへのアクセスを制限しても意味がありません（「公開」の役割が組み込まれたキー/シークレットを備えた公開Webアプリケーションを介して）。
- 認証を要求しても価値はありませんが、パブリックアプリに認証クライアントの実装、キー/シークレットの保持、認証トークンの更新を要求することで、不要なオーバーヘッドが発生するだけです。アプリは、ユーザーがログインする必要がある場合にのみAPIに対して認証する必要があります（一部のクライアントは、ゲストのチェックアウトを使用するため、単に必要としません）。
- 不正使用の懸念（リクエストのレート制限の超過、負荷攻撃など）は、DDoS保護層、またはAPI、またはその両方で対処する必要があります。悪意のあるクライアントがアプリの資格情報を取得してAPIに問題を引き起こす可能性があるため、認証はこれからの適切な保護ではありません。もちろん、認証の試行率も制限する必要があります。
上記の2つのポジションのいずれかがひどく間違っているか、または深刻なAPIの市場で提示された場合に笑われるでしょうか？ここに正しいアプローチはありますか、または両方のアプローチがセキュリティの観点から賢明であり、利便性/実装の容易さなどの他の考慮事項に基づいて選択できますか？
TL; DR：レート制限が唯一の選択肢です。
APIクライアントとしてモバイルアプリとウェブサイトを使用するので、攻撃者によって制御される可能性のあるものを含め、APIキー/シークレットをクライアントデバイスに送信します。セキュリティを決定する際に、これらのキーの機密性を信頼することはできません。彼らはあまりにも簡単に妥協されています。もちろん、侵害されたキー/シークレットを無効にして再発行することはできますが、アーキテクチャを考えると、新しいキー/シークレットをクライアントに送信するだけで、クライアントは再び侵害されます。基本的に、あなたはもぐらたたきの無限のゲームにサインアップしています。
サードパーティのクライアントを許可することになるので、キー/シークレットが危険にさらされていなくても、設計の悪さやバグのために、大量のデータを要求する悪意のないクライアントから保護する必要があります。したがって、認証されたクライアントであっても、レート制限を実施する必要があります。
要するに、提案している認証はセキュリティを提供してもほとんど提供しません。その認証でさえ、適切なレート制限が必要です。 DoS保護はレート制限に基づいている必要がありますが、私は引き続きAPIキー/シークレットを使用して監視とデバッグを支援します。
重要なポイントが1つありません。パブリックAPIを利用する方がはるかに簡単です。高度な攻撃者がレート制限を回避するのは比較的簡単です。 SQLiやXXEのようなany種類の脆弱性がある場合、自動ツールによって検出され、かなり高速に悪用されます。 。
上記の2つのポジションのいずれかがひどく間違っているか、または深刻なAPIの市場で提示された場合に笑われるでしょうか？
APIから返されるデータが公開情報であることを考えると、「」という前提で、認証が必要な理由は実際にはわかりません。 data。 "は正しいです。 （その文の本質的にの部分は私に不思議に思わせます）
ステートメント：
「APIを呼び出したい人に公開したままにすることはできません」
理由が説明されていないため、不完全です。なぜ誰にでも公開できないのですか？あなたが恐れているのは何ですか？
レート制限は明確に実装する必要があり、DDoS防御層を使用する必要があるため、DDoS保護層で対処する必要があるという声明は不十分です。
つまり、考えられるすべてのレイヤーに（理由の範囲内で）保護機能を組み込みます。
オープンAPIは、悪用されたり、ロード攻撃を受ける可能性があります。
例としては、DDoS保護だけに依存するのではなく、レート制限付きのAPIを提供するWebサーバーを構成することも考えられます。
ここに正しいアプローチはありますか、または両方のアプローチがセキュリティの観点から賢明であり、利便性/実装の容易さなどの他の考慮事項に基づいて選択できますか？
はい、どちらも賢明であり、コスト/メリットのアプローチをここで適用できます。公共データを保護するためにどれだけの投資をしていくつもりですか。
上記の2つのポジションのいずれかがひどく間違っているか、または深刻なAPIの市場で提示された場合に笑われるでしょうか？ここに正しいアプローチはありますか、または両方のアプローチがセキュリティの観点から賢明であり、利便性/実装の容易さなどの他の考慮事項に基づいて選択できますか？
それらはどちらも妥当な位置であり、答えはyesです。適切なアプローチがあり、両方の位置をサポートできます。多くの認証サービスにはゲストまたは匿名がありますユーザー、これは認証されていないアクセスと同等です。
ベストプラクティスでは、ゲストユーザーが適切な承認アクセスルールでセットアップされている必要があります。 APIを使いやすくするために-認証資格情報が提供されていない場合、APIはゲストユーザーアクセスを想定します。ゲストの概念をサポートする認証サービスを選択することを強くお勧めします。これは、デフォルトでの実装がかなり安全であるためですが、構成の推奨事項に従うことをお勧めします。
それにもかかわらず、あなたが観察したように、APIの認証されていないアクセスを導入すると、悪用の可能性があります-ゲストユーザー（おそらく同じIPアドレスから）のみをレート制限すると、状況によっては緩和に役立つ場合があります。また、Redhatの apiman などのサードパーティのソリューションを調べて、クォータ/スロットリングを管理する方法を確認することをお勧めします。このアプローチでは、いつでもゲストユーザーを無効にすることができます。