サードパーティ使用のためのAPIの保護
一連のマイクロサービスがあり、これらのサブセットからエンドポイントを公開して、サードパーティが使用できるようにしたいと考えています。このため、すべてのサービスのアクセス制御メカニズムとして機能するAPIゲートウェイを構築します。
howアクセスの制御に関して、私は次のことを考えましたが、それらの間で適切な解決策を決定できません。
A。 APIキー、つまりこれが通常行われる標準的な方法。不利な点は、APIキーが盗まれ、知らないうちに使用される可能性があることです。
B。 Oauth2。 Oauthは、ユーザーに代わってユーザーデータにアクセスするための回答です。この統合では、サードパーティが、顧客が注文したアイテム。
C。アクセスを可能にする署名付きJWTを使用して、サードパーティのユーザーアカウント用のデータベースを用意します。私はこれをRBAC（役割ベースのアクセス制御）モデルの実装と見なしています。 RBACは従来、多数のユーザーがいるソリューションとして機能するため、サードパーティのユーザーが1人いるため、これはソリューションの過剰な可能性があります。
D。 AWSのAPIゲートウェイ。私は、これがどれほど優れているかを判断できる個人的な経験はありません。また、ほとんどのソフトウェアは内部でホストされているため、ゲートウェイはおそらく遅延を増加させる内部サーバーにトラフィックをルーティングする必要があります-Amazonがこのオプションもサポートしている場合。
-
どのオプションが最も効果的だと思いますか？ A-Dである必要はありません。あなたが提案することができるさらなる読書があるならば、遠慮なくそうしてください。
私は通常、この種のことの最も重要な懸念は「サードパーティが何をサポートするか」であることに気づきました。
oauthまたはclient ssl certsのようなものを実行できる場合は、プラットフォームがサポートする標準のセキュリティライブラリに何でも入れることができます。
すべてのセキュリティ問題と同様に、答えは常に信頼できるソースからの標準の既製のパッケージを使用することです。異常なアプローチを必要とするこの相互作用には、特別なことは何もありません。
ただし、一部のユーザーは基本認証しか行えず、FTPが必要な場合や、自宅のPCから毎月第3火曜日に「暗号化された」Excel 97ファイルをメールで送信したい場合もあります。
対処すべき重要な点は次のとおりです。
- non-repudiation：ユーザーは、アクションが自分のものであることを否定できないはずです。これは、IDが誰かに簡単に盗まれることはなく、提供されたトークンが正しいことを検証できることを意味します。
- auditable：不正な動作をしているユーザーがあるかどうかを判断し、その場合はアクセスを終了する必要があります。
- controllable：これは、レート制限を課したり、必要に応じてアクセス権限を減らしたりできることを意味します。
- enforceable：または、ユーザーがアクションを実行できるようにするための認証が実施されます。
そのために、複数のレイヤーがあり、それらの各テクノロジーには、セキュリティ体制全体の一部が整っています。 OAuthの良い点は、それが標準ベースであるため、システムが統合を構築しやすくなることです。ただし、本当に必要がない場合は、それを使用せずにこれらすべての保証を提供できます。
APIキー
encrypted通信を使用しない場合、APIキー自体が簡単に盗聴され、盗まれる可能性があります。つまり、APIキーを盲目的に使用することも適切なソリューションではありません。簡単ですが、通信に鍵を公開する層がある場合は、なりすましも簡単です。
少なくとも、APIキーがverifiableであることを確認する必要があります。 OAuthこれは、外部システムにクライアントIDとシークレットキーを提供することでこれを行います。クライアントIDを提供するための特定のルールがあります通信を暗号化するルールを含む秘密鍵。
OAuthでは、外部システムから提供されたキーを使用して交渉 aセッショントークンになります。セッショントークンは、ベアラートークンとしてAuthentication HTTPヘッダーで提供されます。 10回のうち9回、セッショントークンは[〜＃〜] jwt [〜＃〜]です。
OAuth2
OAuthは、エンドユーザーを検証するための非常に堅牢な基盤を提供し、以降のすべての通信に限定使用のセッショントークンを提供します。セッショントークンを生成するプロバイダーである場合は、JWTを使用して、アプリケーションがユーザーを識別するだけでなく、ロールや、アクセスの決定に使用するその他の属性を埋め込むために必要な情報を埋め込むことができます。トークンに署名することをお勧めします。
認証アクセス用のDB
これは実装の詳細です。 AWS CognitoやAtlassian Crowdなどのマネージドサービスを使用して、すべての重要な詳細を処理し、サードパーティのID管理ソリューションに対応できます。 Cognitoには、目的に応じて生成されるJWTセッショントークンを制御できるという追加の利点があります。
AWS APIゲートウェイ
API Gatewayが提供する最大の利点は、API呼び出しをレート制限する機能です。 AWS Cognitoを使用している場合は、AIMロールをユーザーのトークンに自動的に関連付けることができ、APIゲートウェイを介してそれが続きます。AIMロールはアクセスするバケットなどを制御するために使用されます。
しかし、私はゲートウェイを強制レイヤーとは見なしていません。アプリケーションのスケーリングを支援するトラフィック制御層として、それをもっと見ています。
私は規範的すぎないように努めています
私の回答の冒頭で説明した特性を持っている限り、アプリケーションを保護するための優れた作業を行うことができます。 JWTセッショントークンを使用したOAuth2が一般的なソリューションである理由はいくつかあります。彼らはあなたのアクセス制御の必要性の大部分をかなりチェックします。
[〜＃〜] hmac [〜＃〜] は、オプションAの拡張機能であり、認証キーが「ネットワーク上で」盗まれるのを防ぎ、リプレイ攻撃やメッセージ改ざん攻撃から保護します。それはあなたのニーズには十分良い解決策かもしれませんが、私の経験では、そのプラットフォームで利用可能な既成の HMAC実装 がない場合、そのサードパーティに開発の負担をかける可能性があります。 HMACはメッセージの認証のみを提供することを覚えておいてください。承認が必要な場合は、何らかのID /許可の検索を追加することになります。この場合、ベリンの回答に詳述されているように、BまたはCの方が適している場合があります。