前回は、サーバレスコンピューティングとは何か、そしてセキュリティの課題と対策の重要性について簡単に解説しました。
今回は具体的に、どのようなセキュリティ対策が必要かについて、基本的な考え方を紹介します。
本題に入る前にお知らせです！
＝＝＝＝＝＝＝
【CSPMマネージドサービス SmartOneCloudSecurity】
SmartOneCloudSecurityは、PrismaCloudを用いたCSPMマネージドサービスです。PrismaCloudの導入から設定変更まで、弊社技術担当者がお客様のCSPM対策をサポートします。CSPMの導入を検討中の方はもちろん、PrismaCloudを利用中だけど機能や運用面でもっと上手に活用したい、というような課題をお持ちな方は、お気軽に下記URLからお問い合わせください。PrismaCloudのPoCの相談も受けています。
New!! 2023/4より、CWPPの導入サポートも始めました！
１．何に対して対策をしないといけないか
セキュリティ対策を考える前に、どの領域が対象なのかを明確にする必要があります。
Lambdaの責任共有モデル
AWSが提供するLambdaの責任共有モデルを例にとって、サーバレス環境におけるユーザーのセキュリティ責任を探ります。このモデルによると、関数のコード、使用するライブラリ、関数の設定、Identity and Access Management（IAM）のセキュリティ対策がユーザーに求められます。また、AWSのドキュメントには記載されていませんが、データ保護と監視も重要です。つまり、データの暗号化やアプリケーションの性能監視といった対策も必要です。加えて、セキュリティという観点からは、実際にアプリケーションが稼働するワークロードの防御も考慮に入れなければなりません。
※出典：責任共有モデル
２．何を対策しないといけないか
次に、何を対策しないといけないかを考えます。サーバレスセキュリティ対策においては、AWSを例に取り、具体的な対策を整理するために次の２つのフレームワークが参考になります。
- AWS Well-Architected Framework Serverless Applications Lens
- CIS Benchmark
AWS Well-Architected Framework Serverless Applications Lens
AWS Well-Architected Framework Serverless Applications Lens は、セキュリティ、信頼性、パフォーマンス効率、コスト最適化の４つの主要な柱に基づいて、サーバレス特有のベストプラクティスを提供するガイドラインです。セキュリティの柱においては、以下のような対策を行うことが推奨されています。
- アイデンティティとアクセス管理
最小特権の原則は、サーバレスセキュリティの土台になります。IAMを用いて関数、データベース、その他リソースへのアクセスを細かく制御します。 - インフラストラクチャの保護
サーバレスアーキテクチャでは、アプリケーションが複数のサービスにまたがって稼働します。そのため、ネットワークのセグメンテーションが重要であり、LambdaのセキュリティグループやVPCの適切な設定によりアクセスを制限します。 - データの保護
サーバレスアプリケーションはデータが頻繁に移動するため、データは保管状態または転送中であっても暗号化が必須です。KMSを利用してキー管理を行うことで、データを安全に保持します。 - 検出制御
セキュリティ侵害を迅速に特定するためには、異常なアクティビティを検出する仕組みが必要です。CloudWatch、CloudTrail、またはサードパーティ製のツールを使用して監視を行います。
※現状、異常なアクティビティを防御しようとすると、サードパーティ製の製品を導入が必要 - インシデントレスポンス
セキュリティインシデントが発生した場合の迅速な対応は不可欠です。事前にインシデント対応計画を策定し、自動化された応答メカニズムを導入しておくべきです。
※参考：Security pillar
さらに、AWS Well-Architected Framework Serverless Applications Lensでは、サーバレスを構成する以下の８つのレイヤーについて記載があります。
- コンピュートレイヤー
- データレイヤー
- メッセージング・ストリーミングレイヤー
- ユーザー管理とアイデンティティレイヤー
- エッジレイヤー
- システムの監視とデプロイレイヤー
- デプロイアプローチ
- Lambdaのバージョン管理
これらのレイヤーは、上記の柱と連動しており、AWSサービスを用いて適切なセキュリティ対策を実施できるように設計されています。
アイデンティティとアクセス管理 ⇔ ユーザー管理とアイデンティティレイヤー
インフラストラクチャの保護 ⇔ コンピュートレイヤー、データレイヤー、メッセージング・ストリーミングレイヤー、エッジレイヤー
データの保護 ⇔ データレイヤー
検出制御 ⇔ システムの監視とデプロイレイヤー
各レイヤーに代表的なサーバレスサービスをマッピングしてみると以下のようになります。考え方のベースとなる柱に対して適切にサービスが散りばめられていて、こう見るとよくできているサービス構成に思えます。
CIS Benchmark
CognitoやIAMを用いた認証・認可の強化や、各サービスに対する最小限の権限付与、LambdaやRDSへのセキュリティ対策、CloudWatchやX-Rayによる監視・分析など、基本的なアプローチが明確になりました。次は、CISベンチマークを参考に、これらのサービスに具体的にどのような設定を適用すべきかを検討します。
CISベンチマークは、Center for Internet Security（CIS）によって策定された業界標準のベストプラクティス集です。他のコンプライアンスガイドラインと比較して、より実務に即した技術的設定に重点を置いており、具体的な手順が明確に示されています。
今回も例としてAWSに焦点を当てます。AWSに関するCISベンチマークのドキュメントには以下の4種類があり、各々からサーバーレスサービスに関する重要な記述を抜粋してみます。
- CIS Amazon Web Services Foundations Benchmark v2.0.0
- CIS AWS End User Compute Services Benchmark v1.1.0
- CIS AWS Compute Services Benchmark v1.0.0
- CIS Amazon Web Services Three-tier Web Architecture Benchmark v1.0.0
CIS Amazon Web Services Foundations Benchmark v2.0.0
| CIS No | 推奨事項 |
| 2.1.1 | S3 バケットポリシーが HTTP リクエストを拒否するように設定されていることを確認する |
| 2.1.2 | S3 バケットで MFA Delete が有効になっていることを確認する |
| 2.1.3 | Amazon S3内のすべてのデータが検出され、分類され、必要に応じて保護されていることを確認する。 ※Amazon S3バケットには機密データが含まれている可能性があり、セキュリティ目的のために発見、監視、分類、保護されるべきである。Macieと他のサードパーティツールは、Amazon S3バケットのインベントリを自動的に提供することができる。 |
| 2.1.4 | S3 バケットが「パブリックアクセスをブロック（バケット設定）」で構成されていることを確認する |
| 2.3.1 | RDSインスタンスで静止時の暗号化が有効になっていることを確認する |
| 2.3.2 | RDSインスタンスの自動マイナーバージョンアップグレード機能が有効であることを確認する |
| 2.3.2 | RDSインスタンスにパブリックアクセスが与えられないようにする |
| 3.6 | CloudTrail S3バケットでS3バケットアクセスロギングが有効になっていることを確認する |
| 3.10 | 書き込みイベントのオブジェクトレベルロギングがS3バケットで有効になっていることを確認する |
| 3.11 | S3 バケットで読み取りイベントのオブジェクトレベルロギングが有効になっていることを確認する |
| 4.1 | 未承認の API 呼び出しを確実に監視する |
| 4.8 | S3 バケットポリシーの変更を確実に監視する |
※CIS Amazon Web Services Foundations Benchmark v2.0.0 から引用、翻訳
CIS AWS Compute Services Benchmark v1.0.0
| CIS No | 推奨事項 |
| 4.1 | AWS ConfigがLambdaで有効になっていることを確認する |
| 4.2 | Cloudwatch Lambda insightsが有効になっていることを確認する |
| 4.3 | AWS Secrets Managerが設定され、データベース用のLambdaで使用されていることを確認する |
| 4.4 | ラムダ関数へのアクセスに最小特権が使用されることを保証する。 |
| 4.5 | すべてのラムダ関数が独自の IAM ロールを持つようにする |
| 4.6 | ラムダ関数が誰にでも公開されないようにする。 |
| 4.7 | ラムダ関数がアクティブな実行ロールを参照していることを確認する。 |
| 4.8 | Lambda関数でCode Signingが有効になっていることを確認する。 |
| 4.9 | AWSアカウント内に管理者権限を持つLambda関数がないことを確認する |
| 4.10 | ラムダ関数が、権限ポリシーによって未知のクロスアカウントアクセスを許可しないようにする。 |
| 4.11 | ラムダ関数に使用する実行環境のバージョンにサポート終了日がないことを確認する。 |
| 4.12 | Lambda環境変数で転送中の暗号化が有効になっていることを確認する |
※CIS AWS Compute Services Benchmark v1.0.0 から引用、翻訳
CIS Amazon Web Services Three-tier Web Architecture Benchmark v1.0.0
| CIS No | 推奨事項 |
| 1.4 | RDS 上で実行されるデータベースで、静止時の暗号化が有効になっていることを確認する |
| 1.16 | 全てのS3バケットで、バケットに格納されている全てのオブジェクトに対してサーバーサイドおよびトランジット暗号化を必須とするポリシーがあるか確認する |
| 3.5 | リレーショナルデータベースサービスがマルチAZで有効になっていることを確認する |
| 3.6 | リレーショナルデータベースサービスのインスタンスにおいて、自動マイナーバージョンアップグレードが有効であることを確認する |
| 3.8 | リレーショナル データベース サービスのバックアップ保持ポリシーが設定されていることを確認する |
| 3.11 | S3 バケットのバージョン管理が有効になっていることを確認する |
| 3.12 | CloudFront Viewer プロトコルポリシーを使用した HTTP から HTTPS へのリダイレクトが設定されていることを確認する |
| 3.13 | すべての CloudFront ディストリビューションで CloudFront と Web 層 ELB オリジンの間で HTTPS が必要であることを確認する |
| 4.1 | Cloudtwatch アラームおよび Auto-Scaling グループ (スコア付き) から通知を送信するための SNS トピックが作成されていることを確認する |
| 4.2 | RDS イベントから通知を送信するための SNS トピックが作成されていることを確認する |
| 4.3 | RDS イベント サブスクリプションがインスタンス レベルのイベントに対して有効になっていることを確認する |
| 4.4 | RDS イベント サブスクリプションが DB セキュリティ グループに対して有効になっていることを確認する |
| 5.3 | AWS Cloudfront Logging が有効になっていることを確認する |
| 5.5 | Cloudwatch ログ グループがアプリ層用に作成されていることを確認する |
| 5.7 | アプリ層の Cloudwatch ログ グループに保持期間があることを確認します |
| 6.4 | Cloudfront ディストリビューション内で地域制限が有効になっていることを確認する |
| 6.30 | RDS データベースがパブリックにアクセスできないことを確認する |
| 6.34 | RDS データベースがデータ層セキュリティ グループを使用するように構成されていることを確認する |
※CIS Amazon Web Services Three-tier Web Architecture Benchmark v1.0.0 から引用、翻訳
CISベンチマークでは、各サービスの具体的な設定方法が明確に示されており、さらにAWS Secrets ManagerやMacieなどの追加サービスを利用したセキュリティ対策も詳細に記述されています。セキュリティ設定に関して不明な点がある場合は、まずはこれらのガイドラインに従って設定を行うことをお勧めします。
３．対策の全体像
これまでの内容を基に、サーバレスセキュリティにおける対策を、サーバレスシステム構築の構成例に適用する形で整理してみます。
CISベンチマークでは、各サービスの詳細な設定推奨事項が記載されています。ここでそれらを全て取り上げるには量が多すぎますが、基本的には全てのサービスにおいて、各サービス固有のセキュリティベストプラクティスに従った適切な設定が必要です。なお、これらの設定が正しく行われていることを、CSPMソリューションで監視し、設定の不備をリアルタイムに検出することが重要です。
アイデンティティとアクセス管理では、Cognitoを使用して認証・認可を実施し、認証を通過した通信のみを許可します。また、IAMを用いて各サービスに必要最小限の権限を付与し、もし悪意あるユーザーが侵入しても、被害を最小限に抑える体制を整えます。
インフラストラクチャー保護のためには、エッジサービスであるCloudFrontやAPI GatewayにWAFを導入して防御対策を施します。データベースへの認証情報はSecrets Managerで管理し、Lambda関数にはSignerでの署名を用いて、データベースアクセスやLambdaの利用を承認されたユーザーに限定します。さらに、ワークロードとランタイムの保護には、CWPPソリューションを活用して実行環境の脆弱性管理と防御対策を実施します。
データ保護に関しては、保管場所だけでなく伝送中のデータも暗号化します。また、Macieを用いてS3に保存された機密データを特定し、そのアクセスを監視します。
検出制御の観点では、CloudWatchやX-Rayを使用して適切な監視と分析を行える状態にし、異常な状態を定義できればSNSでアラート通知させます。また、前提とした各サービス毎のセキュリティのベスプラに基づく適切な設定が行われていることを監視するために、Security Hubやサードパーティ製CSPMソリューションで脆弱な設定がないことを継続的に監視することも重要です。
ここまでで、サーバレスセキュリティの基本的な対策について考えてみました。サーバレスセキュリティの対策としては、ランタイムやライブラリの脆弱性の管理なども考える必要があるので、次回は更に一歩踏み込んで、脆弱性管理や実際にCWPP製品を使ってみて、どういった対策を行うことができるかを確認していきたいと思います。
