サーバーレスセキュリティの影響：インフラからOWASPまで

Serverless（FaaS）は、その性質上、今日の大きなセキュリティ懸念のいくつかに対処します。インフラ管理をなくすことで、セキュリティ上の懸念をプラットフォームプロバイダーに移します。しかし、攻撃者がただ諦めることはなく、新たな環境に適応します。具体的には、FaaSによって攻撃者の関心はサーバーから、OWASPが指摘するアプリケーションの課題へと移り、ディフェンダーもそれに応じて優先事項を変える必要があります。

この記事では、Serverlessが解決に役立つセキュリティ上の懸念と、そうでないものについて説明します。以下の各項目は、それぞれ単独で記事にできるほどの内容があります（いずれ書くかもしれません！）。ただし今回は、大局的な見方を優先し、修正やリスク管理の詳細には深く踏み込みません。

懸念事項をひと目で把握できるよう、簡単にまとめました。

それでは、詳しく見ていきましょう！

Serverlessはセキュリティにどう役立つのか？

Serverlessでは、サーバー管理の責任がアプリケーション所有者からプラットフォームプロバイダーに移ります。厄介なサーバーのセキュリティ確保は非常に難しいことで知られていますが、プラットフォームを管理する専門家はこれをうまく処理できます。そのため、Serverlessによって大幅に緩和されるセキュリティ脅威を3つ紹介します。

1. パッチ未適用のサーバーも、脆弱なバイナリもない

何よりもまず、Serverlessは現在、攻撃が成功する主な原因であるパッチ未適用のサーバーを事実上なくします。こうしたサーバーでは、依存関係の最新セキュリティ更新が適用されておらず、既知の脆弱性を持つバイナリが使われています。大半の調査結果によると、既知の脆弱性を持つ依存関係が、現在成功している攻撃の大多数を占めています。

Serverlessを使ってもサーバーを最新の状態に保つ必要がなくなるわけではありませんが、この懸念はプラットフォームプロバイダーに移ります。サーバー管理はプロバイダーの中核的な専門分野であるため、マシンが最新の状態でない可能性はかなり低くなります。

2. サービス拒否が課金の問題になる

サービス拒否（DoS）攻撃は、正当なリクエストをサーバーが処理できないようにし、リクエストを処理できるサーバーがすべて利用不能になるまで攻撃を繰り返します。FaaSでは、サーバーは必要に応じてプロビジョニングされ、破棄されるため（プラットフォーム固有のパフォーマンス最適化はここでは考慮しません）、「サーバーをダウンさせる」という考え自体に意味がありません。正当かどうかにかかわらず新しいリクエストが届くたびに、プラットフォームはサーバーをプロビジョニングして、要求された関数を実行します。

概念上、Serverlessは可用性を脅かすDoSをなくしますが、プラットフォームには把握しておくべき同時実行数の制限があります。AWS Lambdaでは現在、デフォルトで同時関数実行数が600に制限されています。また、DoS攻撃によって利用料金が膨大になる可能性もあり、DoS攻撃と同じくらい厄介です。そのため、実行時間やReDoSの脆弱性を軽視しないでください。

3. イミュータビリティによって侵害されたサーバーがなくなる

多くの攻撃では、脆弱性の悪用は最初の一歩にすぎません。攻撃者は攻撃を繰り返すのではなく、サーバーを侵害して悪意のあるエージェントを仕込み、そこからさらに深く攻撃することを狙います。SonyやTargetへの侵害など、最も甚大な被害をもたらす攻撃には、こうした侵害済みサーバーが関与しています。

FaaSではサーバーはイミュータブルで、稼働期間も短いため、長期間にわたって侵害された状態のサーバーが存在する可能性を事実上なくせます。この保護によって攻撃の成功率が大きく下がるわけではありませんが、侵害後に可能となる行為を大幅に抑え、攻撃による被害を軽減できます。

変わらないセキュリティ上の懸念とは？

ここまで見てきたように、Serverlessはアプリケーション所有者にとって大きな脅威をいくつか取り除きます。では、攻撃者はServerlessベースのアプリを諦めるのでしょうか？もちろん、そんなことはありません。

Serverlessでは解決できない、セキュリティ上の主な懸念を3つ紹介します。FaaSによってこれらの懸念が悪化するわけではありませんが、先ほどの脅威が取り除かれることで、攻撃者にとっての優先順位は自然と高まります。そのため、これらのリスクを把握し、対処することがこれまで以上に重要です。

4. コードの脆弱性は残る

Serverlessは周辺環境の負担の大半を取り除きますが、自分のコードと、その脆弱性は残ります。クロスサイトスクリプティングやSQLインジェクションなどのアプリケーションレベルの脆弱性は、悪用されれば依然として深刻です。入力検証やプログラムによるDBアクセスなどの緩和策も、これまでと変わらず重要です。

ここでのベストプラクティスは従来と変わりません。静的（SAST）および動的（DAST）セキュリティテストツールを使い、入力検証を容易にし、可能な限りホワイトリスト方式を採用する、といった対策です。このテーマについては、OWASP Top Tenガイドやチートシートに役立つアドバイスが多数掲載されています。

5. 脆弱なアプリケーション依存関係が含まれる

一見すると、FaaSの関数は自分のコードだけで構成されているように見えますが、正確にはそうではありません。関数には、npm（Node.js）、PyPI（Python）、Maven（Java）などのプラットフォームから取り込まれるアプリケーション依存関係も含まれます。これらのコードパッケージは、アプリケーションに組み込まれた小さなインフラのようなものです。

アプリケーション依存関係は、悪用されることの多いサーバー依存関係とよく似ています。広く使われ、毎月何十億回もダウンロードされています。使用しているパッケージを把握するのは難しく、新たな脆弱性が定期的に公開されるため、脆弱なものも少なくありません。攻撃者はすでに脆弱なアプリケーション依存関係を悪用していますが、脆弱なサーバー依存関係という簡単な経路を断たれれば、同様の対象への攻撃を一斉に強めるでしょう。

既知の脆弱性は、攻撃者と同じように簡単に見つけることができます。アプリケーション依存関係を保護するには、信頼できるデータベースと、新たな脆弱なパッケージの導入を継続的に防ぎ、新たに公開された問題を通知する自動化ツールが必要です。Snykなら、これらすべてを簡単に実現できます。ぜひ試してみてください！それ以外の場合も、自分と利用プラットフォームに合ったツールを選び、この問題を放置しないでください。

6. 保存データへのアクセスしやすさは変わらない

最後に、Serverlessを使っても、攻撃者がデータベースに近づけなくなるわけではありません。先ほど挙げた脆弱性、漏えいした認証情報、内部関係者の侵害など、どのような経路であれ、攻撃者がデータにアクセスできれば、FaaSによる影響はまったくありません。

機密情報を保存する場合は、適切に暗号化してください。オープンソースの暗号アルゴリズムは広く利用でき、使わない理由はありません。また、全員にDBへのアクセス（読み取り専用であっても）を与えるのではなく、本当に必要な人やシステムだけに権限を付与してください。FaaSではこの点をより細かく制御でき、DBを直接利用する関数だけにアクセスを制限できます。最後に、データストアをインターネットに直接公開しないでください。最近のMongoDBへの攻撃やRedisによる明確な声明からもわかるように、これらのシステムは内部利用を前提に設計されています。

Serverlessは保存データのセキュリティを損なわないため、この問題は「変化なし」としました。ただし、関数は常にステートレスなので、場合によっては状態（そこに保存されている機密データを含む）がローカルストア（ファイルシステムやメモリなど）からネットワークストア（Redisやキューなど）に移動します。DBのような永続ストレージと同じデータセキュリティ対策を、こうした一時ストレージにも適用してください。

Serverlessによって悪化するセキュリティ上の懸念とは？

Serverlessによって新たなセキュリティ上の懸念が生まれるわけではありませんが、いくつかの懸念が増幅されます。Serverlessが促すアーキテクチャでは、特定のプラクティスをより多く実践することになり、それに伴い、内在するセキュリティ上の懸念も大きくなります。Serverlessによってセキュリティが難しくなる主な領域を3つ見てみましょう。

7. サードパーティサービスと転送中のデータ

FaaSを使っても保存するデータ量は増えませんが、データをやり取りする量は確実に増えます。従来はマシン内にとどまっていたデータが、関数間を何度も移動し、多くの場合、呼び出しごとに少しずつ変更されます。また、関数の細分化とステートレスな性質によって、サードパーティサービスの利用が増えるため、ネットワーク経由でデータを送受信する必要も生じます。

データをやり取りするたびに、漏えいや改ざんの可能性が生じます。また、通信のたびに、送受信するデータを相手に預けることになり、その信頼が悪用される機会も生まれます。FaaSでは通信の量が増えるため、この懸念にいっそう注意し、より適切に防御する必要があります。

データセキュリティは幅広い分野ですが、特に暗号化と信頼の2点に注目することをおすすめします。まず、HTTPSまたは鍵とKMSを使用して、すべてのデータを暗号化してください。どちらの方法でも、通信相手の身元をある程度検証できます。次に、たとえ相手が別の関数であっても、やり取りする関数やサービスからの入力をすべて信頼しないでください。関数が別の関数を、ましてやサードパーティサービスを暗黙に信頼すると、どれか1つのコンポーネントが悪意あるものになったり侵害されたりしたときに、すぐ破綻する脆弱な連鎖が生まれます。

8. 柔軟性が高まるほど、攻撃対象領域も広がる

Serverlessの主な利点の1つは柔軟性です。制御フローをクライアント側に移すことで、サーバー側のコードを変更せずに、より多くのユースケースに対応できます。しかし、柔軟性が高まると、攻撃者がシステムに意図しない動作をさせる機会も増えます。Mark Nunnikhovenの言葉を借りれば、「開発者は問題の解決に注力し、セキュリティは、その解決策がほかに何に利用されるかを考える」のです。

この懸念に対処する唯一の方法は、各関数を独立したセキュリティ境界として扱うことです。つまり、各関数で入力と出力をサニタイズし、データを保護し、コードと依存関係のセキュリティを確保する必要があります。現在の多くのシステムは、境界の外側は堅牢でも、内側は脆弱です。FaaSではこの境界が大きく広がるため、より幅広い防御策が必要になります。

幸い、FaaSにはこうした幅広い保護を実現する大きな機会が2つあります。第一に、関数は本質的に小さいため、アプリケーション全体と比べて、できることとできないことを定義し、コードやユニットテストで徹底しやすくなります（簡単ではありませんが）。第二に、関数は通常、API Gateway経由で外部から呼び出されます。API Gatewayでは呼び出しに必要なモデルやスキーマを定義し、許可する入力と出力をより厳しく制限できます。これらの機会を活用し、各関数を個別に保護してください。

9. セキュリティ監視が極めて困難になる

Serverlessでは、コードを驚くほど簡単にデプロイできます。本番環境への関数のデプロイは実質無料で、実行コストもごくわずかかつ細かく設定されているため、利用量の少ない関数は請求額にほとんど反映されません。そのため、関数のデプロイを控える経済的な動機がなく、一度デプロイした関数を削除する理由もありません。さらに、誰が関数を使っているかを追跡する簡単な方法もないため、一度デプロイした関数を削除するのは非常に危険です。その結果、ほとんど使われない関数が何千もデプロイされることになりかねません。

デプロイのハードルが下がることは生産性の向上につながりますが、セキュリティ上の大きな問題も生みます。デプロイされた各関数が攻撃対象となり、脆弱性を悪用してプライベートネットワークへの侵入やデータベースの改ざん、さらにはあなたになりすました攻撃が行われる可能性があります。関数に組み込まれたアプリケーションの依存関係は次第に古くなり、新たな脆弱性も発見されるため、こうした攻撃を自動化しやすくなります。監視システムが複雑なため、脆弱な依存関係は悪用されやすく、対策も困難です。

さらに、既存のセキュリティ監視ソリューションはServerless環境では機能しません。多くのソリューションは、（もはや存在しない）長時間稼働するサーバーへのエージェント導入を必要とし、FaaSで許容できる範囲を超える起動時・実行時のオーバーヘッドが発生します。また、Serverlessプラットフォームのようにオンデマンドでスケールできません。加えて、こうしたソリューションはエンドツーエンドのアプリを前提に設計されているため、そのロジックやインターフェースはServerless特有のきめ細かさに対応していません。

この課題はエコシステム全体に関わるものであり、新たなアプローチが必要です。どの関数がデプロイされ、誰が利用し、どの依存関係を使っているのかを、常に把握しておきましょう。関数の実行コストは低くても、使われていないコードや脆弱なコード、古いコードが本番環境に残るリスクの増大を含め、総所有コストを考慮する必要があります。

今後、セキュリティランタイム監視ソリューションは、エージェント不要で、オーバーヘッドを抑え、大規模にスケールできるよう進化していく必要があります。また、すべての関数にわたって脆弱なアプリケーション依存関係を追跡し、問題のある関数の更新や削除を支援する、インフラ監視ソリューションに代わる手段も必要です。Snykもその実現に取り組んでおり、脆弱なアプリケーション依存関係を検出するCI/CDソリューションを拡張し、デプロイ済みの関数を直接監視できるよう開発を進めています。ベータ版への参加をご希望の場合は、ぜひお知らせください！

まとめ

Serverlessは素晴らしく、アプリケーションの運用方法に変革をもたらしています。一方で、セキュリティの世界にも同様の大きな変化をもたらし、ある課題を解消する一方で、別の課題を深刻化させ、その他の課題の優先順位も変えています。この記事では、他のクラウドコンピューティング手法と比べて、FaaSがWebセキュリティのどの領域で優れているのか、変わらないのか、劣っているのか、主な3つの観点からまとめました。以下の表をご覧ください。

Serverlessはまだ新しい技術です。だからこそ、Serverlessアプリケーションの構築において、セキュリティ対策やツールを自然に取り入れる機会があります。運用とセキュリティの両面で、Serverlessが大きな可能性を発揮しながら成長していくことを、個人的にも楽しみにしています。