PE部PE課の礒です。毎日寒くても心は実家のこたつの中です。
今回私が視聴したセッションはこちらです。
「Best practices for securing your serverless applications」
私はよくサーバーレスアプリケーションを作るのですが、動画を視聴してみて今まで実践できていなかったベストプラクティスを学ぶことができました。
(特に「トレードオフを考える」の内容が勉強になりました！)
本記事では、そんなこちらのセッションの概要を紹介させていただきます。
是非、上記リンクから実際にご覧ください。
アジェンダ
サーバーレスアプリケーション VS 従来のモノリシックなアプリケーション
- セキュリティ面での相違点 (10:00~)
- セキュリティ面での共通点 (15:00~)
サーバーレスアプリケーションのセキュリティについて
- 一般的なセキュリティガイド (20:10~)
- AWSサービスごとのセキュリティガイド (24:00~)
- トレードオフを考える (34:00~)
セキュリティ面での相違点
画像の点線枠部分はAWSが責任を持つため、ユーザーは価値ある機能を作ることに集中出来る
きめ細やかなセキュリティ制御ができる
- セキュリティのリスクは以下の3つの軸で表現できる
- complexity(複雑性)
- resources(アプリケーションのアクセス先)
- dependencies(依存性)
- セキュリティのリスクは以下の3つの軸で表現できる
よく設計されたサーバーレスアプリケーションでは、
コードのユニットごとにこれらは分割されているため上記リスクがすべて軽減される。
ただし、それでもリスクは存在する。
セキュリティ面での共通点
「セキュリティリスクがある」ところが双方の共通点。
サーバーレスアプリケーションのセキュリティについて、「OWASP TOP 10」(セキュリティ団体OWASPが発行しているレポート)に沿って以下を解説。
- アプリケーションレイヤーのセキュリティ
- 認証・認可
- データの暗号化と完全性
- モニタリングとロギング
一般的なセキュリティガイド
サーバーレスのメリットをぜひ活かすため、以下の「しない」が重要
- 必要以上の権限を付与しない
- モノリシックなLambdaファンクションを作らない
- 書き込み権限と読み込み権限を1つのリソースに付与しない
- アクセスが必要でないデータにアクセスしない
- 不要な依存性を持たせない
AWSサービスごとのセキュリティガイド
AWS Lambda
ポリシーをとてもシンプルに表現できるポリシーテンプレートを使えるAWS SAMがおすすめ
API Gateway
オーソライザーでのアクセスを制御が可能
- Lambda オーソライザー
- Amazon Cognitoユーザープール
- リソースポリシー
Amazon DynamoDB
アイテムのキーがカスタマーIDから始まる場合のみアクセスを許可するポリシー「LeadingKeys」の紹介
Amazon S3
- パブリックアクセスの許可はやめる
- より厳重なアクセス制御が求められる場合はS3アクセスポイントを利用する
AWS Step Functions
スケジュール実行する場合はAmazon EventBridgeにStep Functionsのinvoke権限付与が必要なので注意
(これには私もハマったことがあります)
トレードオフを考える
- 特別な理由がなければ、アプリケーションを拡張する際は新しくLambdaファンクションを追加する
- 「将来必要になるであろう権限・機能」はつけない(YAGNI)
- 1つの関数が1つのことにだけ責任を持つように設計する
といっても、実際のビジネスロジックは複雑。
↓そこで推奨されるベストプラクティスがこちら↓
- Lambdaファンクションは「ハッピーパス」(理想的な条件下で実行されたケース)だけを処理するようにする
- エラーハンドリングはStep Functionsでおこなう
- ビジネスロジックを冷酷に分解する
- サービス統合で可能な限りコードを減らす
おわりに
以上、セッションレポートでした。
個人的に、この解説で一番耳寄りだったのは「Step FunctionsからLambdaをinvokeせずにDynamoDBを操作することができる」でした・・！
SDKでもそんなに大変ではないですが、そのコードすら書かなくてもいいんですね。
動画では、そんな具体的なTipsや詳しい説明が凝縮されています。
45分の動画ですが、説明前後は待機画面になっており実質20分ほどでサクッと見ることができますのでぜひご覧ください！
