AWS API Gatewayのカスタム認可は役に立ちますか？

Question

私は、ユーザー認証のためにカスタムAPIゲートウェイオーソライザを使用するAWS Lambda/zappaに「serverless api server」を使用しようとしています。サーバレスのAWSラムダサービスでは、発行されたJWTトークンをコードコントローラで直接チェックするのではなく、カスタムオーソライザを使用する際にかなりのセキュリティまたはコスト上の利点がありますか？私はコードをチェックする方が便利かもしれません。

UPDATE 私は事前リクエストフックに行ってきましたが、ヘッダーレベルのオーソライザがありますが、CORSで使用する方が簡単ですが、zappaではサポートされていません。また、オプションのmock APIを設定することはswagger uploadを介して可能であり、成功した場合には更新されます。

Answer 1

厳密に言えば、セキュリティやコストの面で利点はないと思います。利点は、それがあなたの認可を処理する単一の場所、コードの単一の部分であることです。これにより、APIの背後に配置するすべてのラムダ関数で、その認証コードを複製する必要がなくなります。また、認証ロジックを変更するために単一の機能を更新することができます。

許可ロジックにsingle source of truthを提供し、separation of concernsを実装できるという観点からは、アプリケーションのセキュリティを強化すると言えるでしょう。

つまり、API全体が1つのラムダ関数で構成されている場合、そのメリットはやや疑わしいものです。あなたのAPIに多くのラムダ機能がある場合や、APIゲートウェイが従来のHTTPサーバーの前に座っている場合、APIゲートウェイカスタムオーソライザが本当に有益になると思います。

Answer 2

@マークBは優れた点を作っています。私は彼の答えで何も論争していません。それにもかかわらず、私は会話に貢献したいと思います。

JWTがどこから来たのか、そして取得、使用、更新される方法によって、より具体的な回答が得られる可能性があります。カスタム承認者を使用すると、これらのシナリオでは意味をなさないことがありますが、認可のいくつかの異なる味の後ろに単一ラムダを確保したい場合は

ユースケース1人の

カスタム承認者に役立ちます。たとえば、3つの異なるAPIゲートウェイエンドポイントを作成して、それぞれ同じラムダを呼び出すが、別個の承認者を使用することができます。これは、DRYのメリットについてMarkの要点と関連しています。

ユースケース2人の

カスタム承認者は、あなたの承認者コードにインラインIAM権限を構築する能力を与えます。既存のIAMロールを発信者に割り当てるのではなく、好きな任意の権限セットを作成できます。何らかの形で（信頼できない）ユーザー入力を使用してIAM権限を割り当てていると、これは簡単に厄介な攻撃ベクトルになる可能性があることに注意してください。

ユースケース3

ラムダは、秘密を隠すための素晴らしいです。たとえば、フロントエンドのJSアプリがあり、クライアントIDとクライアントの秘密を必要とするOAuth 2.0のフローに参加する必要があります。または、ある種のAPIキーを必要とするエンドポイントを呼び出す必要があります。 明らかに、これらの秘密をブラウザに公開することはできません。

これらの値は、ラムダ関数に固有のencrypted and stored in environment variablesです。このアプローチをバックエンドラムダで確実に実行することができますが、代わりにオーソライザを使用すると、次のような利点があります。

私はこれらの秘密の範囲を可能な限り厳密に制限できるのが好きです。オーサライザを使用することで、私のアプリケーションはこれらの秘密を幸せに知らないままになります。これはマークのポイントに関心の分離に関するものです。

IAMと最小特権私は私のバックエンド・コードは、権限のない者によって呼び出されることは決してありませんことを好む

。このため、実際に作成するすべてのAPIゲートウェイリソースで、ある種の認可者を使用します。私はカスタムオーソライザを使用しましたが、私の最後の手段です。私は、Cognitoを使用して一時的なIAMクレデンシャルのトークンを交換することで、ほとんどの場合IAM認可を得ます。

認可者ではなく、バックエンドのラムダで認可を実行する場合、バックエンドラムダの周りにIAM contolを定義するときに制限を受けることはできません。これはprinciple of least privilegeの違反です。これは単なるコード構成とアプリケーションアーキテクチャの問題ではありません。正当なセキュリティ上の懸念事項です。基本的には、あなたがしなければならないより多くの攻撃面を露出しています。

さらに、バックエンドが大きくなるとIAMの真のパワーが光ります。バックエンドラムダは、S3への書き込み、他のLambdasの呼び出し、SNSまたはSQSへの公開、RDSまたはDynamoDBとの対話などが必要な場合があります。このアクセスのすべてが厳格なIAMによって管理されていることを「ベストプラクティス」ポリシー。私の経験上、これを達成する最も簡単な方法は、（必ずしもカスタムではない）APIゲートウェイ・オーソライザを使用してロールを割り当てることです。