%201.svg){kind=logo}
AWS Lambda 関数は、クラウド上でアプリケーションを迅速に開発・デプロイするための代替的なアプローチを提供します。Lambda関数を使ってアプリケーションを構築する場合、インフラのプロビジョニングや管理に関する多くの作業をクラウドプロバイダーであるAmazon Web Services（AWS）に委ねることになります。この委任によってAWS Lambdaのセキュリティに関する懸念の一部は軽減されますが、完全に解消されるわけではありません。
本記事では、サーバーレスアプローチを採用する際に注意すべきAWS Lambdaに関連する潜在的な脆弱性について解説します。また、Lambdaを利用したアプリケーションをどのように保護するか、そしてAWSが提供するこのサービスを最大限に活用するためのその他のセキュリティベストプラクティスについても紹介します。
Lambda関数とは？
AWS Lambda では、DynamoDB イベントや SQS メッセージなど、AWS リソースからの Web リクエストやイベントを入力として受け取る関数を作成できます。Lambda は、データベースへのデータ書き込みなどのアクションを含むイベントを処理し、関数の出力を返します。Lambda を使用する利点は、基盤となるインフラストラクチャのプロビジョニングを気にする必要がなく、負荷増加に対応するための関数のスケーリングも不要であることです。
例えば、以下のようなシナリオで Lambda 関数をご利用いただけます：
- 新しい画像ファイルを バケット に追加した後。このイベントにより、サムネイル画像を生成し別のバケットに保存する Lambda 関数がトリガーされます。
- データベースに新しいユーザーレコードを追加する HTTP リクエストが送信された時。異なる関数でレコードの更新や削除が可能です。
- 認証を処理できる対話型ウェブサイト において、Lambda 関数への呼び出しを使用してウェブページを提供する場合。
自動スケーリングや基盤インフラのプロビジョニング不要といった利点に加え、AWS Lambda にはその他のメリットもございます。Lambda のコンピューティング時間はサブ秒単位で計測されるため、関数の実行時間のみが課金対象となります。アカウントの無料利用枠が終了した後も、最初の 100 万リクエストは無料です。その後は、100 万リクエストごとに 0.20 ドル のみ課金されます。
ただし、AWS Lambdaにも制限は存在します。Lambda関数の最大実行時間は15分間です。アカウントのデフォルト設定では同時実行数は1,000に制限されていますが、AWSサポートと連携することでこの制限値を引き上げることが可能です。また、Lambda関数ではコールドスタート遅延が発生する可能性がありますが、使用言語によってはこれを軽減できます。
ユースケースやアーキテクチャ内での実装方法によっては、クラウドベースのニーズに対する費用対効果の高いソリューションとなり得ます。ただし、Lambdaソリューションを安全に実装すること、またLambda関数をサポートするために必要となる可能性のある他のサービスのコストも考慮に入れることが不可欠です。
先に進む前に、料金や制限事項は時間の経過とともに変更される可能性があることをご留意ください。ご自身のケースに応じたより正確な情報が必要な場合は、公式AWSページで詳細をご確認ください。それでは、さらに一歩踏み込んで、AWS Lambdaのセキュリティとその要件について見ていきましょう。
Lambdaはセキュリティ対策が必要ですか？
AWS Lambdaを利用することで、責任分担モデルの一部はAmazonに移行しますが、Lambda実装の所有者であるお客様が責任を負うべき側面も依然として存在します。まずは責任共有モデルがAWS Lambdaのセキュリティにどのように適用されるかを検討しましょう。その後、セキュリティとコンプライアンスに関するお客様の責任、および悪意のある攻撃者、偶発的な情報漏洩、過剰なコストからインフラを保護するためのベストプラクティスについて議論します。
共有責任セキュリティモデルの理解
共有責任モデルは、クラウドインフラストラクチャの各部分について、その維持とセキュリティ確保の責任が誰にあるかを定めています。AWS仮想サービス（EC2など）をご利用の場合、インスタンスのセキュリティ確保と維持に関する責任の大部分はお客様に帰属します。ただし、AWS Lambdaに関しては、AWSが追加の責任を負います。
AWS Lambdaをご利用のお客様には、以下の責任が課せられます。
- 関数コードおよび使用される依存関係やライブラリ
- リソースの設定
- アイデンティティとアクセス管理（IAM）
AWSが維持および保護する責任を負うのは以下の通りです。
- コンピューティングリソース
- 実行環境
- ランタイム言語
- ネットワークインフラストラクチャ
- サーバーソフトウェア
- 基盤となるハードウェア
これらの責任範囲と、それらがもたらす潜在的な脆弱性を理解することで、Lambda実装のセキュリティ対策をより効果的に進めることができます。
AWS Lambdaの脆弱性
Lambdaは小さく明確に定義されたコード片で構成されていますが、それでもコードであることに変わりはなく、他の環境で実行されるアプリケーションコードと同様の注意が必要です。開発者の人的ミスや経験不足によって生じる可能性のあるバグやその他の問題を排除するため、コードの徹底的なテストとスキャンを実施してください。
さらに、Lambdaコードにはライブラリやその他の依存関係が含まれる可能性があります。外部ライブラリの利用はコーディング時間を短縮し、アプリケーションに十分にテストされ検証済みのコードを導入できる利点があります。しかしながら、誰もが同じライブラリを使用しているからといって、それらが安全であるとは限りません。決して安全であると仮定すべきではありません。開発プロセスやデプロイメントパイプラインに依存関係チェックを組み込むことは、Lambda関数を保護する上で極めて重要です。
脆弱なAWS Lambdaファンクション – クラウド攻撃における初期アクセスで実証したように、攻撃者はこの設定ミスのあるAWS Lambda関数を悪用し、AWSアカウントを完全に制御する可能性があります。
Lambda関数は本質的にミニアプリケーションです。他のアプリケーションと同様に、許可されたユーザーのみがアクセス可能であることを保証し、処理前にあらゆる入力を厳重に検証する必要があります。また、特に環境の高度なスケーラビリティと正当なユーザーへのサービス提供の必要性を考慮すると、LambdaがDDoS攻撃の標的とならないよう確保することも重要です。
AWS Lambdaのセキュリティに関するベストプラクティス
Lambda関数がどのような脆弱性を持つ可能性があるかをご理解いただいたところで、関数のデプロイおよび設定時にこれらの脆弱性から保護するために従うべきベストプラクティスについてご説明いたします。
アイデンティティとアクセス管理（IAM）
Lambda関数をデプロイする際には、その関数のユーザーがどのように、どこからアクセスできるかを定義するIAMロールを割り当てます。このロールは、Lambda関数がアクセスできるリソースも決定します。他のリソースに対するIAMのベストプラクティスと同様に、Lambda関数に関連付けられたロールには、その関数が機能するために必要な最小限のアクセス権のみを割り当てるようにしてください。ロールには、resource.*
単一責任の原則
Lambda関数は、1つのアクションのみを実行するように設計すべきです。この単一責任の原則により、Lambda関数のシンプルさが向上し、エラー発生の可能性が低減され、万一侵害された場合の被害範囲も縮小されます。
HTTP アクセス
Lambda を Web リクエスト経由で呼び出すことを想定している場合、これらのリクエストは AWS API Gateway 経由でルーティングすることをお勧めいたします。API Gateway は、DDoS 攻撃や、ウェブの闇に潜む悪意ある攻撃者によるその他の悪意ある攻撃からの保護など、いくつかの安全対策を提供します。
クリーンアップ
一般的なルールとして、Lambda関数はローカルディスクへの書き込みを行いません。例外として、一時データを書き込める/tmpフォルダが利用可能です。ただし、このフォルダの内容が関数呼び出し完了時に確実に消去される保証はありません。従いまして、Lambdaの実行フェーズが終了する前に、このフォルダに書き込まれた内容を意図的に削除することを推奨いたします。
入力の精査
このベストプラクティスは全てのアプリケーションに適用されますが、Lambda関数への移行時に複雑性を削減する過程で見落とされないよう、改めて言及する価値があります。Lambda関数は、入力が適切に検証・浄化されるまでは、全ての入力を潜在的に有害なものと見なすべきです。受信ペイロードが想定される基準に適合しない場合、処理を行わず、LambdaはDevOpsエンジニアによる分析のためにその試行をログに記録すべきです。
権限制限付きVPC内へのLambda関数のデプロイ
他のクラウドリソースと同様に、Lambda関数が効果的に動作するために必要な最小限の権限で構成された仮想プライベートクラウド（VPC）を設定することがベストプラクティスです。上記で挙げた他のベストプラクティスと同様に、これにより、攻撃者がLambda関数を利用してアカウント内の追加リソースにアクセスする機会をさらに低減できます。
効果的な監視計画の設計と実装
DevOpsエンジニアの皆様は、ダッシュボード上でLambdaに関連する統計情報を確認できる必要があります。CloudWatchが提供する機能を利用するか、サードパーティ製ソリューションを活用し、Lambdaの呼び出し回数や実行時間に関するメトリクスと分析情報を表示することが可能です。ダッシュボードでは、消費されるメモリとコンピューティングリソースの可視化も行うべきであり、基準値を超える異常が発生した際には運用チームへ通知するアラートを設定する必要があります。
コンプライアンスの維持
Lambda関数が攻撃や設定ミスに対して安全であることを確保するだけでなく、システム内で個人情報、医療情報、決済情報、その他の機密データを扱う場合、コンプライアンス要件の対象となる可能性もあります。AWS Lambdaをご利用になるお客様には、コンプライアンスの検証と確保が責任範囲に含まれます。これを支援するため、AWSでは多くの一般的なフレームワーク向けにコンプライアンスプログラムを提供しており、お客様のアプリケーションが適用される法令に準拠していることを確認するためにご利用いただけます。
AWS Lambdaセキュリティ対策の継続的な取り組み
これまで、AWS Lambdaに関連する多くの潜在的な脆弱性と、実装を保護し安全に使用するために実施できるベストプラクティスについてご説明しました。現実として、AWS Lambdaはアプリケーション開発プロセスの維持管理をより容易にします。しかしながら、アプリケーションを簡素化し個々の関数に分解する過程において、確立された開発ベストプラクティスを見失わないことが極めて重要です。加えて、常にセキュリティを最優先とする考え方で開発を開始すべきです。