![[レポート] サーバーレスセキュリティのベストプラクティス #SVS301 #reinvent](https://devio2023-media.developers.io/wp-content/uploads/2021/11/eyecatch_reinvent2021_sessionreport.png)
[レポート] サーバーレスセキュリティのベストプラクティス #SVS301 #reinvent
いわさです。
AWS re:Invent 2021で行われた、「Serverless security best practices」のセッションレポートです。
この記事では、要点・見どころ・ポイントについてまとめてみました。
セッション概要
DESCRIPTION
This session explores how to think about security from the front to the back of a typical serverless application. How do you configure AWS serverless services to provide least-privileged access while ensuring functionality? How should you think about managing IAM policies for your AWS Lambda functions? We cover all this and more, leaving you with concrete examples applicable to almost any workload.
SPEAKERS
- Lia Vader
SESSION LEVEL
- 300 - Advanced
はじめに
サーバーレスアーキテクチャーは従来のアーキテクチャーに比べてAWS責任共有モデルにおけるユーザーが担う範囲が狭いというメリットがあります。
とはいえセキュリティに関して対応が不要なわけではありません。
このセッションを通してサーバーレスセキュリティにおけるベストプラクティスを学んでいきます。
なお、このセッションではセキュリティのベストプラクティスを考えるにあたって、OWASP Serverless Top10 と AWS Well-Architected Frameworkを原則としています。
- OWASP Serverless Top 10
- セキュリティの柱 - AWS Well-Architected フレームワーク - セキュリティの柱
- サーバーレスアプリケーションレンズ – AWS Well-Architected フレームワーク - サーバーレスアプリケーションレンズ
４つのベストプラクティスカテゴリ
原則を踏まえて、このセッションではベストプラクティスを以下4つのカテゴリに分けています
- 認証と承認
- データ暗号化と整合性
- ログ記録と監視、構成管理
- サービス拒否とインフラストラクチャの保護
1: 認証と承認
このカテゴリの対応内容は以下に該当します。
- OWASP Serverless Top 10
- S2:2017 Broken Authentication
- S5:2017 Broken Access Control
- AWS Well-Architected Framework
- Implement a strong identity foundation
- Apply security at all layers
API Gatewayで適切な認証と認可を行う
- CognitoユーザープールとOIDC, OAuthでのJWTオーソライザーのCognitoユーザープールオーソライザーあるいは標準のJWTオーソライザーを使ってトークン検証を行う
- IAMベースの認可の場合、最小権限の法則に従う
- Lambdaオーソライザーは最も柔軟な制御とポリシーのキャッシュが可能
最小特権モデルに従う
- CORSヘッダー
- ワイルドカード使わない。適切な範囲で許可を行う。
- Amazon API Gateway CORS Configurator (preview) などを活用できる
- Lambdaのリソースペースポリシーと実行ロール
AWS Secrets Managerなどにシークレットを保存
- IAMによるシークレットへの最小特権アクセスを強制する
- シークレットを定期的にローテーションする
セキュリティレイヤーとしてRDS Proxyを活用する
RDSに対してシークレットを使って接続する場合でもRDSプロキシを使ってIAM認証を適用することが可能。
Amazon RDS Proxy の使用 - Amazon Relational Database Service
2: データ暗号化と整合性
このカテゴリの対応内容は以下に該当します。
- OWASP Serverless Top 10
- S1:2017 Injection
- S3:2017 Sensitive Data Exposure
- S8:2017 Insecure Deserialization
- AWS Well-Architected Framework
- Protect data in transit and at rest
- Apply security at all layers
冒頭で、そもそも機密データの保存は必要最小限にすることを述べています。
その上で取り扱う場合の方法を紹介しています。
保存データを暗号化する。各レイヤーの暗号化方法がある
- API Gatewayキャッシュの暗号化を有効にする
- Lambda: 環境変数はデフォルト暗号化、一時領域を利用する場合は
/tmpを使う - クライアントサイドではAWS Encryption SDK を使って暗号化が可能
- データストアでの暗号化
- DynamoDBでKMSを利用
- RDSの暗号化
- S3のSSE-S3/SSE-KMS
転送データを暗号化する
- 全てのAWSエンドポイントはHTTPS経由になっている
- データベース接続時にTLSを使う
入力データを検証する
- API Gatewayの検証機能でパラメータ、クエリ文字列、ヘッダー、ペイロードをチェック
- Lambda関数内でのセキュアコーディング
- 入力値のデータ型検証を行う
- 安全なデシリアライズ
- Deserialization - OWASP Cheat Sheet Series
- AWS WAFを使った保護(DDos/SQLインジェクションなど)
- API Gatewayでは直接統合されている
アプリケーションの依存パッケージを管理する
- パッケージの脆弱性は狙われやすい。
- 未使用の依存関係は削除する。
- 依存パッケージの脆弱性をチェックする
- OWASP Dependency-Check Project | OWASP
- CI/CDパイプラインに統合し、常にチェック出来ると理想
3: ログ記録と監視、構成管理
このカテゴリの対応内容は以下に該当します。
- OWASP Serverless Top 10
- S6:2017 Security Misconfiguration
- S10:2017 Insufficient Logging and Monitoring
- AWS Well-Architected Framework
- Enable traceability
- Apply security at all layers
CloudWatch
- API Gatewayのエラーやレイテンシーなど重要な指標を監視
- Lambdaの過剰な呼び出しや長時間実行を監視
- API Gatewayのアクセスログ、LambdaのCloudWatch Logsを活用
CloudTrail
- 管理コンソール操作やAPI呼び出しの履歴を管理する
- すべてのAWSリソースにとって重要。全リージョン全アカウントで有効にすることを推奨
AWS Config
- 設定変更の管理
- コンプライアンス違反の検知（例：APIキャッシュ暗号化を無効に設定された、等）
X-Ray
- サービスコンポーネントのマップで構成を素早く把握する
4: サービス拒否とインフラストラクチャの保護
DDoS攻撃から防御
- API Gatewayのエンドポイント毎（エッジ最適化、リージョナル、プライベート）のCloudFrontディストリビューションを理解する
- セッション内では、一般公開されるAPIはCloudFrontを配置した上でリージョナルエンドポイントを使うことを推奨している
- WAFも有効化する
APIGatewayを介してスロットルとレート制限を常に実装する
- APIキーを使用してクライアントごと、メソッドごとにスロットルを構成する
- Amazon API Gateway ではトークンバケットアルゴリズムを使用してトークンでリクエストをカウントし、API へのリクエストを調整する
API リクエストを調整してスループットを向上させる - Amazon API Gateway
API GatewayのmTLS機能を使う
- 特定のデバイスやベンダーにAPIを提供する場合はmTLSが適切な場合がある
- API Gatewayの相互TLS(mTLS)機能を使える
- mTLSはカスタムエンドポイントでの提供になる
- デフォルトエンドポイントを無効にするのを忘れないこと
API Gatewayのプライベートエンドポイントを使ってVPC内のアクセスに制限する
- クローズドな内部APIの場合は、API Gatewayのプライベートエンドポイントが利用出来る場合がある
- VPC内にアクセスを制限出来るので内部サービスを保護することが出来る
- リソースポリシーを使ってVPCエンドポイントに制限する
まとめ
以下がワークロードの各コンポーネントでの対応内容になります。
様々なレイヤーで個別の対応が必要であること、そのための機能が各サービス提供されていることがわかります。
このセッションを通してそれらの対応の具体的な実装方法を学ぶことが出来ました。
また、このセッションではAWS上のサーバーレスにおけるものだけでなく、他社クラウドへも通用する考え方が多く含まれているように感じました。
一般的なAWSにおけるセキュリティだと、WAFや暗号化, CloudTrailやConfigがまず最初におもいつきますが、それらはもちろん含んでいますが、OWASPのツールを使った確認方法やアプリケーションレイヤーでの対応方法なども含まれており、見どころの多いセッションでした。
