[レポート]サーバレスアプリケーションのセキュリティを学ぶワークショップ #SVS305 #reinvent

本ブログはAWS re:Invent 2019のワークショップ『How to secure your serverless applications』のレポートです。現地でワークショップに参加はできていませんでしたが、ワークショップの資料が公開されていたので実際にやってみました。

AWS re:Invent 2019

#Amazon API Gateway

#AWS SAM

#AWS

Kitano Yuichi

2020.03.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

本ブログはAWS re:Invent 2019のワークショップ『How to secure your serverless applications』のレポートです。

現地でワークショップに参加はできていませんでしたが、ワークショップの資料が公開されていたので実際にやってみました。

セッション概要

In this workshop, you learn techniques for securing a serverless application built with AWS Lambda, Amazon API Gateway, and Amazon Aurora. We cover the AWS services and features that you can leverage to improve the security of serverless applications across five domains: identity and access, application code, data encryption, infrastructure, and logging & monitoring. You will wear the hat of a security engineer for Wild Rydes, a unicorn ride hailing company (fictitious, of course). You get to pick your own adventure in hardening a serverless application against OWASP top ten vulnerabilities.

このワークショップでは、AWS Lambda、Amazon API Gateway、およびAmazon Auroraで構築されたサーバーレスアプリケーションをセキュアにするためのテクニックを学びます。アイデンティティとアクセス、アプリケーションコード、データ暗号化、インフラストラクチャ、ロギングとモニタリングの5つのドメインでサーバーレスアプリケーションのセキュリティを向上させるために活用できるAWSのサービスと機能について説明します。あなたはユニコーンに乗る会社であるWild Rydesのセキュリティエンジニアとして働くことになります（もちろん架空のものです）。 OWASPのトップ10の脆弱性に対してサーバーレスアプリケーションを強化するための冒険にでかけましょう。

ワークショップ資料

スライド

SVS305: How to secure your serverless applications

ワークショップ

GitHub - aws-samples/aws-serverless-security-workshop

レポート

ワークショップ概要

このワークショップでは最初に、次のような構成でサーバレスアプリケーションのためのAPIエンドポイントを構築します。

しかし、このAPIエンドポイントはまったくセキュアな構成になっていません。

ワークショップを通して、このサーバレスアプリケーションのどこがセキュアでないのか？ そして、どうやってセキュアにするのか？について学んでいきます。

Module 0: Inital Setup

まずはサーバレスアプリケーションを開発するための環境として、Cloud9の構築をします。その後、AWS SAM (Serverless Application Model)を利用してREST APIのデプロイをします。最後に、Postmanを使用してAPIリクエストのレスポンスが問題なく返ってくるかを確認します。

ちなみに、PostmanはAPIのテストクライアントツールです。詳しくは弊社ブログを御覧ください。

Module 1: Add Authentication and Authorization

この章では、REST APIに認証と認可の機能を追加します。

パートナー会社を管理するユーザーと、各パートナー会社のユニコーンを管理するユーザーと、２種類のユーザーを構築することになります。
このユーザーの区別は、Cognitoユーザープールのクライアントを分けることで実現しています。

POST /partner APIは、パートナー会社を管理するユーザーが使用します。このAPIにPOSTすることで、新しいパートナー会社用の環境が自動的に構築されます。パートナー会社専用のCognitoユーザープールのクライアントも自動的に構築します。

POST /partner以外の APIは、各パートナー会社のユニコーンを管理するユーザーが使用します。新しいパートナー会社用の環境を作成した際、専用のCognitoユーザープールが構築されるので、そのクライアントを通してアクセストークンを取得して操作します。
そして、API GatewayでLambdaのカスタムオーサライザーを利用して、DynamoDBからCognitoユーザープールのクライアントIDに対応するCompany IDを取得します。そのComapny IDに基づいて、その会社で管理しているユニコーンのデータのみ操作できる環境を実現しています。

Module 2: Securely storing our database credentials with AWS Secrets Manager

この章では、ハードコーディングしているDB接続情報（ホスト名、パスワード）を、AWS Secrets Managerから取得するよう変更します。

DBの接続情報をハードコーディングすることはベストプラクティスではありません。セキュリティの観点からだけでなく、運用の観点からもよくないです。 CI / CDパイプラインで異なるステージ間のコードをデプロイする場合、ハードコードされた値は自動化が難しくなります。

それを解決するため、AWS Secrets Managerを使用してDBの接続情報を取得するようにします。あわせて、AWS Secrets Managerでパスワードを自動的にローテーションするようにしています。

Module 3: Input validation on API Gateway

この章では、SQLインジェクションをAPI Gatewayで検証して防ぐ機能を追加します。

最初の環境ではSQLインジェクションを防ぐような実装になっていません。そのため、APIにPOSTするBodyの値に、悪意のある値（例："2); INSERT INTO Socks (NAME,PRICE) VALUES ('Bad color', 10000.00"）を設定されると、SQLインジェクションが発生します。

そこで、API GatewayのModelを利用して、POST時の各パラーメーターがサーバー側の想定したとおりであることを検証するようにします。
例えば、Bodyに含まれる値が次のような想定であれば、それを正規表現でModelに定義します。

imageUrl: 有効なURLであるべき
socks, horn: 数値で構成されるIDであるべき

モデルの設定をしてAPI Gatewayが想定していないパラメーターを受け取った場合、400 Bad Request response を返すようになり、SQLインジェクションを防げます。

Module 4: Use SSL in-transit for your DB connections

この章では、LambdaとRDS間の通信を暗号化（SSL化）します。

VPC内Lambdaを使用しており、トラフィックはVPC内でプライベートです。しかし、コンプライアンス要件によっては、データ転送中に暗号化が必要になる場合があります。この暗号化によって、データベースとの通信時のデータが保護されます。

Module 5: Usage Plan

この章では、API GatewayのUsage Planを利用して、不正なクライアントによる悪用から保護する機能を追加します。

Usage Planについては、弊社ブログを御覧ください。

API Gatewayは会社毎のAPIキーを使用することになり、APIキーを持たない不正なアクセスをブロックしたり、会社毎にリクエスト数の制限をかけることができます。

一点だけ、注意点があります。

Module 5B: Update API Gateway to enforce API keys で tempalte.yaml を修正する際、GitHubのページからコピーすると、タブ文字が混じっているためエラーになります。ワークショップを実施する際は、コピーではなく直接入力してください。

Module 6: WAF

この章では、AWS WAFを構築して、API Gatewayと連携します。

AWS WAFを利用することで、SQLインジェクションとクロスサイトスクリプティング（XSS）に一致するリクエストを拒否できます。さらに、ルールを使用して、IPアドレス、地理的エリア、リクエストサイズ、文字列または正規表現パターンに基づいてWebリクエストをフィルタリングできます。また、AWS Marketplaceのマネージドルールを活用することで、OWASPトップ10セキュリティリスクやCommon Vulnerabilities and Exposures（CVE）などの一般的な脅威から保護することもできます。

実際にWAF構築後、SQLインジェクションが起こりうるPOSTをしてみて、ブロックされることが確認できます。