# パブリックエンドポイントによるワークロードの保護
パブリックにアクセス可能なワークロードに対して、AWS は、特定のリスクを軽減するのに役立つ多くの機能とサービスを提供しています。このセクションでは、アプリケーションユーザーの認証と認可、および API エンドポイントの保護について説明します。
## 認証と認可
認証はアイデンティティに関連しており、認可はアクションを指します。認証を使用して Lambda 関数を呼び出すことができるユーザーを制御し、認可を使用して実行できる操作を制御します。多くのアプリケーションでは、両方の制御メカニズムを管理するのに IAM で十分です。
ウェブアプリケーションやモバイルアプリケーションなどの外部ユーザーを持つアプリケーションでは、[JSON ウェブトークン (JWT)](https://jwt.io/introduction/) を使用して認証と認可を管理するのが一般的です。従来のサーバーベースのパスワード管理とは異なり、JWT はすべてのリクエストでクライアントから渡されます。これらは、クライアントから渡されたデータを使用してアイデンティティとクレームを検証する暗号的に安全な方法です。Lambda ベースのアプリケーションの場合、認証を中央サーバーに依存することなく、各 API エンドポイントへのすべての呼び出しを保護できます。
登録、認証、アカウント復旧、その他の一般的なアカウント管理オペレーションを処理できるユーザーディレクトリサービスである [Amazon Cognito を使用して JWT を実装](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)できます。[Amplify Framework](https://docs.amplify.aws/start/getting-started/auth/q/integration/react) は、このサービスをフロントエンドアプリケーションに簡単に統合するためのライブラリを提供しています。[Auth0](https://auth0.com/) などのサードパーティーのパートナーサービスを使用することも検討できます。
ID プロバイダーサービスの重要なセキュリティ上の役割を考慮すると、アプリケーションを保護するために専門的なツールを使用することが重要です。認証または認可を処理するために独自のサービスを作成することはお勧めしません。カスタムライブラリに脆弱性があると、ワークロードとそのデータのセキュリティに大きな影響を与える可能性があります。
## API エンドポイントの保護
サーバーレスアプリケーションの場合、バックエンドアプリケーションをパブリックで提供する方法には、Amazon API Gateway を使用することをお勧めします。これにより、悪意のあるユーザーやトラフィックの急増から API を保護できます。
API Gateway では、サーバーレスデベロッパー向けに [REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html) と [HTTP API](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html) という 2 つのエンドポイントタイプを用意しています。どちらも [AWS Lambda を使用した認証](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)、IAM、Amazon Cognito をサポートしています。IAM または Amazon Cognito を使用する場合、受信リクエストが評価され、必要なトークンが欠落しているか、無効な認証が含まれているとリクエストは拒否されます。これらのリクエストは課金されず、スロットリングクォータにもカウントされません。
未認証の API ルートには、パブリックインターネット上の誰でもアクセスできる可能性があるため、未認証 API の使用は制限することをお勧めします。未認証 API を使用する必要がある場合、[サービス拒否](https://en.wikipedia.org/wiki/Denial-of-service_attack) (DoS) 攻撃などの一般的なリスクから保護することが重要です。[これらの API に AWS WAF を適用](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)すると、アプリケーションをSQL インジェクションおよびクロスサイトスクリプティング (XSS) 攻撃から保護できるようになります。API Gateway は API キーが使用されるとき、AWS アカウントレベルおよびクライアントごとのレベルで[スロットリング](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)も実装します。
多くの場合、未認証 API が提供する機能は、代替アプローチで実現できます。例えば、ウェブアプリケーションでは、ログインしていないユーザーに対して DynamoDB テーブルから顧客向け小売店舗のリストを提供するとします。このリクエストは、フロントエンドのウェブアプリケーションから、または URL エンドポイントを呼び出す他のソースから発信される可能性があります。この図は、3 つの解決策を比較したものです。
![\[セキュリティオペレーションの図 5\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/security-ops-figure-5.png)
1. この未認証 API は、インターネット上の誰でも呼び出すことができます。サービス拒否攻撃では、API スロットリング制限、Lambda 同時実行数、または基盤となるテーブルにおける DynamoDB でプロビジョニングされた読み取り容量を使い果たす可能性があります。
1. 適切な[有効期限](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) (TTL) 設定を持つ API エンドポイントの前に CloudFront 配信を配置すると、データを取得するための基盤となるソリューションを変更することなく、DoS 攻撃のトラフィックをほとんど吸収します。
1. または、まれに変更される静的データの場合、CloudFront 配信は Amazon S3 バケットからのデータを処理できます。