サーバレスは、現代のインフラストラクチャ界におけるエキサイティングな出来事のひとつに数えられます。システムコストの大幅な削減、総所有コストの簡素化と低廉化に加えて、(私のような)古参者が“スラッシュドット・モーメント”と呼ぶ、トラフィックの突然かつ大規模なスパイクに対してシームレスな拡張性を備えた、高度にエラスティック(elastic)なシステムの実現を可能にします。
サーバレスサービスはその廉価性により、採用数をますます向上させています。多くの企業が実運用で使用し始めて、熟練度の低い開発者や監視プラクティスの不足への対処と、運用コストの削減に成功しています。このようなトレードオフは、労力と成果のバランスを考えれば合理的ではありますが、大きな不安がひとつ残ります — セキュリティです。
この記事では、サーバレスの世界におけるセキュリティに関して、広範な情報を提供したいと思っています。サーバレスのセキュリティを強化する方法、セキュリティが変化する領域、それによって生じるセキュリティ上の懸念、といったことを検討します。
FaaSのサーバレスが話題なのか？
サーバレスの持つ意味は人それぞれですが、中心的なものは次の２つです。
- ファンクション・アズ・ア・サービス(FaaS)プラットフォーム — デプロイされたファンクションを、オンデマンドでプロビジョニングするプラットフォーム(あるいは同じように、小さな計算ユニットをエラスティックに管理する、AWS Auroraや各種のフックなどのプラットフォーム)。
- イベントベース実行モデル — さまざまなアクティビティに応答してファンクションをトリガする場合に使用される。
イベントベースのコミュニケーションも多少はセキュリティに影響しますが、FaaSがセキュリティに及ぼす影響に比べれば、極めて限定的で、範囲も限られています。そこで本記事では、イベントではなく、FaaSのセキュリティに注目したいと思います。記事を読みやすくするため、以降ではサーバレスとFaaSとを同じ意味で使用します。
分類法が確立できたところで、さっそく本題に入りましょう。
サーバレスはいかにセキュリティを向上させるか？
まずは肯定的な面から — サーバレスによって、セキュリティはどれほど向上するのでしょう？
OSパッチの管理が不要
サーバレスというのは、非常に議論の多い名称です。コードはどこかで実行しなければならないのですから、実行するためにサーバが必要なのは明らかです。より正確に言うならば(あまりキャッチではないにせよ)、サーバマネージメントレスというべきです。FaaSを使用する場合は、基盤となるプラットフォームがサーバのプロビジョンや管理、監視などの作業を、あなたの代わりに行ってくれます。
サーバの提供と合わせて、FaaSはサーバの“パッチ当て” — オペレーティングシステムやその依存関係が新たに公開された脆弱性に影響される場合に、安全なバージョンにアップデートする作業の責任も負ってくれます。既知の脆弱性に対してパッチの適用されていないサーバやアプリは、システムが悪用される最も大きな要因になりますが、規模の大きなアプリケーションやサーバのアップデートは、パッチの頻度やデプロイメントの広範さからも大変な作業です。
サーバレスでは、パッチされていないサーバのリスクが管理者の手を離れて、プラットフォームを運用する“プロ”の手に移ります。そうすることで24時間、システムをより安全に運用することができるのです。HerokuやCloud Foundryのようなプラットフォーム・アズ・ア・サービス(PaaS)ソリューションも、現在は同じようなことを行っています。ですから、まったく新しいコンセプトではないのですが、それでもサーバレスを使うことによって、セキュリティの大幅な向上を簡単に手に入れられることに違いはありません。
サーバレスはOS依存関係のパッチをオフロードしてくれますが、脆弱性のあるアプリケーションの依存関係には何もしてくれない、という点を理解しておくことは重要です。これについては後ほど、もっと詳しく議論します。
短命なサーバは長期間侵入されることがない
サーバレスの提供するソフトウェア運用方法は固定的で、さまざまな制約が課されています。その中でおそらく最も重要なもののひとつが、ファンクションはステートレスでなければならない、という制約です。FaaS環境においては、自分のファンクションの実行がどのサーバに割り当てられるかは分かりませんし、気にする必要もありません。プラットフォームがファンクションに合わせて、サーバをプロビジョニングあるいはデプロビジョニングします。生成された(仮想)サーバが数秒後に破棄されることも珍しくありません。
映画で見るものとは違って、セキュリティ漏洩が１度のパスで起こることはほとんどありません。ほとんどの攻撃では、ハッカーはまず抜け穴を見つけ、それを利用して、ターゲットマシンに悪意のあるエージェントのインストールを試みます。停止状態のこのエージェントは — できる限り静かに — そのシステムの深部に入り込み、アクセス可能なデータや他のシステムの探索を開始します。Targetやパナマ文書で見られたような大規模なデータ漏洩は、このような時間を要する潜入とデータの漏出の結果なのです。
サーバレスは攻撃者に時間の余裕を与えません。マシンを繰り返しリセットすることにより、侵入されたサーバは排除されます。攻撃者は侵入を何度も繰り返さなければならず、その度に失敗や発覚のリスクに晒されることになります。すべてのFaaSファンクションがステートレスで短命であることは、本質的に、任意の時点において侵入されている可能性を低減することによって、セキュリティ情勢における即物的な勝利を可能にします。
究極の弾力性(elasticity)はすなわちDoS耐性である
FaaSの宣伝文句の最後は、即時的でシームレスなファンクションのプロビジョニングです。この自動セットアップは、ユーザが眠っている間はサーバを稼働させない — 従って費用も発生しない — 一方で、膨大な要求でも処理が可能であるという、究極的な弾力性を実現しています。
正常な要求の処理を可能にするものと同じスケーラビリティは、悪らつな要求への対処にも威力を発揮します。攻撃者は、計算集約型あるいはメモリ集約型のアクションを大量に送り付けてサーバの負荷を最大化し、正規ユーザのアプリケーション利用を妨害することでシステムダウンを図る場合があるのです。
このようなDoS(Denial of Service)攻撃は、(想定上は)無限の能力を持つサーバレスサービスによって自然に阻止されます。多くのリクエスト — 正悪に関わらず — に対しては、単にプラットフォームがより多くのアドホックサーバを用意するため、正規のユーザには引き続きサービスが提供されます。とは言っても、その実行費用はすべてあなたが支払うことになるのですが ... ですから、銀行口座へのアクセスが拒否されないためにも、そういった行動を監視する価値はやはりあるのです！
ただし、サーバレスはDoS排除を支援はしても、完全に排除する訳ではありません。プラットフォームの能力も実際には無制限ではありませんし、DDoS(Distributed Denial of Service)などある種のDoSでは、アプリケーションではなくネットワーク帯域幅やDNSを攻撃対象とする場合もあります。こうした懸念に対処するには、AkamaiやFastly、Incapsula、あるいはクラウド自体が提供するDDoS防御ソリューションを使用するとよいでしょう。
サーバレスはセキュリティをどう変えるのか？
ここまでは、サーバレスによって -- 排除はされなくても -- 緩和される、セキュリティの問題について議論してきました。その他の分野で、サーバレスがセキュリティを向上あるいは低下させることはありませんが、変化させる、すなわち優先度や詳細な部分に影響する場合はあります。このように変化する、おもな領域について見てみましょう。
詳細なアクセス管理は諸刃の刃である
サーバレスはある意味で、マイクロサービスの極端な例です。巨大なモノリシックアプリをデプロイする代わりに、多数の小さな(あるいは小さめの)ファンクションをデプロイして組み合わせているのです。
この分割によって、各コード部分のパーミッションを詳細化することが可能になります。 各ファンクションに対して、どのデータにアクセス可能か、どのアクションを実行できるか、最初に起動できるのは誰か、といったことを明示的に指定できるのです。このように粒度を細かくすることで、“最小権限(least privilege)”を適切に設定して、不正アクセスされたファンクションによるダメージを最小限に抑えることが可能になります — 理屈の上では。
しかしながら現実問題として、数百ないし数千というファンクションのパーミッションを詳細に管理するというのは、非常に困難な作業です。そのため開発者は、必然的にファンクションをまとめてグループ化し、必要な権限の総和を与えるようになります。
詳細なアクセス管理はFaaS導入のメリットですから、自動化されたスケーラブルなファンクションの権限管理に投資することを強くお勧めします。これらのプラクティスが簡単に実行可能である限り、これはセキュリティの変化ではなく、改善であると考えられます。何から手を付ければよいのか分からなければ、Aaron Kammerer氏の講演を見ることをお勧めします。サーバレスの運用に関する話題の中で、iRobot社がLambdaのパーミッションを自動設定する方法について紹介されています。
ステートレスサーバには優れたデータセキュリティが必要である
ファンクションはステートレス(一部のキャッシュを除く)ですが、アプリケーションのロジックでは、セッション情報やパフォーマンス向上のためのキャッシュなどのデータが必要な場合がよくあります。ステートフルなアプリケーションであれば、このような情報は要求を処理するマシン上のメモリや、場合によっては外部ディスクに保持されます。しかしながら、ステートレスであるファンクションで呼び出し間で情報を永続化する場合は、外部ストレージ(Elasticacheなど)を使用することになります。
同じマシン上にデータを持たないことによるパフォーマンス上の影響は、一般的にはさほど大きなものではありませんが、機密性の高いデータをサーバ外部に置くことは、セキュリティに大きく影響します。データが転送時に危険にさらされますし、長期的に存在することで他のマシンからもアクセスしやすくなります。データストアに侵入された場合には、より多くのユーザが一度に影響を受けます。簡単に言ってしまえば、データをマシン外に置くことは、内部におく場合に比べてよりリスクが高くなるのです。
外部ストレージを使用するのはサーバレスだけではありませんが、頻度が高くなるため、データのセキュリティはより重要になります。セッションでストアするデータを暗号化する、短期的なキャッシュを使用する、誰がリポジトリにアクセスするかを慎重に管理する、などの処置を検討しましょう。AWSに組み込まれている転送データ暗号化機能を使用するなどして、転送データの暗号化にも注意してください。
アプリケーションのセキュリティが大幅に向上する
FaaSがサーバレベルのセキュリティ問題を自動的に処理するのは素晴らしいのですが、それで攻撃者がギブアップすると思ってはいけません！攻撃者は別の領域に意識を向けるでしょう — その中で最初となるのが、アプリケーションそのものです。
ファンクションにSQLインジェクションやクロスサイトスクリプティング、あるいはコマンドインジェクションといった脆弱性が存在する確率は、サーバレスになることで変わる訳ではありませんが、FaaSでは特に、このような方向に攻撃者の目が向けられますから、防御する側としても、特別な注意を払う必要があります。
ファンクションは一般的に機能の範囲が狭いため、入力値の可否をより厳密にコントロールすることができます。このようなコントロールはコードでも記述できますが、APIゲートウェイでスキーマやホワイトリストを作成すれば、悪意のある入力が発生する機会をさらに削減することが可能になります。もっと広範な入力をサポートする必要のある場合は、予想される攻撃パターンの自動テストを作成して、ファンクションのデプロイメントパイプラインに組み入れておくとよいでしょう。
内部に潜む脆弱なアプリケーション依存関係
プラットフォームが保護するサーバと、開発者が保護するアプリケーションの間には、3つ目のグループ — アプリケーションの依存関係(dependency)があります。これらはnpmやPyPl、Mavenなどからプルされるオープンソースライブラリで、最小限の労力とコストで優れた機能を提供してくれます。プラットフォームが管理も保護もしないため、ライブラリはアプリとコードの間のトワイライトゾーンに埋没しているのですが、インフラストラクチャの一部のように盲目的にプルされています。
ファンクションは一般的に機能粒度が高いため、デプロイされるファンクションのコードの大半をこの種のライブラリが占めることも珍しくありません例えば、ファイルをフェッチしてS3に格納する25行のサンプルでは、2つのライブラリを使用していますが、これらがさらに19のライブラリを使用しているため、全体のコードは190,000行に達しています。このようなコード量の違いは、一般論として、アプリケーションのコード自体よりもライブラリの脆弱性リスクが高いことを意味します。
アプリケーションライブラリにある既知の脆弱性には、FaaSが自動的に対処しているサーバの依存関係のものと同じ程度のリスクがあります。さらに、FaaSがOSレベルで提供する本質的な保護機能は、次の“簡単な方法”として、アプリケーションの依存関係に攻撃者の目を向けさせることになるため、そのセキュリティはさらに重要なものになります。Mavenライブラリのリモートコマンド実行によって起こされたEquifaxのデータ漏が、その被害の大きさを実証しています。
アプリケーションライブラリの脆弱性に対象する責任は、ファンクションの開発者たるあなたにあります。ファンクションの開発においては、SnyxやVictims DB、OWASP Dependencyチェックなどのツールを利用して、ライブラリの既知の脆弱性に常に注意し、修正してください。この件に関する詳細は拙著“ecuring Open Source Libraries”、あるいは一連のO’Reillyブログの記事でも紹介しています。
サーバレスはセキュリティにおいてマイナスなのか？
サーバレスは本質的にセキュリティを棄損するものではありませんが、そのスケールの大きさが極めてリアルなセキュリティリスクを顕在化させます。目を向けるべき重要なものをここで紹介しましょう。
サードパーティサービスへの依存度が高い
サーバレスアプリがFaaS上のみに構築されることはほとんどなく、イベントやデータで結合されたサービスのメッシュに依存する形式が一般的です。それらの一部は独自のファンクションですが、多くは他の誰かが運用しているものです。 実際に、ファンクションのスコープの狭さとステートレス性が高まるに伴って、クラウドプラットフォームのものや外部サービスなど、サードパーティ製サービスの利用も大幅に増加しています。
サードパーティサービスは潜在的な侵入ポイントです。それぞれがデータの受信や提供を行ない、ワークフローに影響し、リッチで複雑な情報をシステムにもたらします。このようなサービスが悪意の有るものである場合、あるいは単に侵入された可能性のある場合、大きなダメージを被ることがあります。10のサービスを利用していれば、そのわずか0.1パーセントにハッキングされる可能性があったとしても、システム自体が侵入されたサービスを利用する可能性は1パーセントということになるのです ...
このリスクをコントロールするためには、各サービスを検証し、侵入された場合の影響を最小化する必要があります。推奨されるステップをいくつか紹介しましょう。
- 有効なTLS証明書を要求して、通信するサービスが想定する本来のサービスであることを検証(および転送するデータを保護)すること。Let’s Encryptを使用すれば、すべてのサービスが検証済み(自己署名ではない)証明書を適切に提供することができます。
- サードパーティサービスからの応答に入力検証を適用すること。ユーザ入力が厳密に管理されているシステムでも、この種の応答については盲目的に処理されることが少なくありません。
- サービスに送信するデータは最小化および匿名化して、正常な動作のために必要なもののみに限定すること。
これらは単に、サードパーティサービスを潜在的な悪意のあるアクタとして考える上で必要となる、幅広い考え方のいくつかの例に過ぎません。
すべてのファンクションが攻撃面を拡張する
ファンクションは技術的には互いに独立していますが、大部分はアプリ内の限られたシーケンスによってのみ起動されます。結果として多くのファンクションは、事前に他のファンクションが実行されて、何らかの方法でデータをサニタイズしているという前提の下で動作しています。言い換えれば、ファンクションは、自身入力が信頼できるソース — 別のファーストパーティファンクション — から来たものと信じて動作しているのです。
このアプローチでは、セキュリティは極めて脆弱なものになります。第1に、これらのファンクションは、たとえそれがビジネスロジック的には理にかなわないものだとしても、攻撃者によって直接起動される可能性があります。第2に、明日の新しいフローに、入力をサニタイズしないファンクションが追加されるかも知れません。そして第3には、攻撃者が他のファンクションのひとつに侵入して、防御の手薄な他のファンクションに容易かつ直接的にアクセスする可能性があります。最後の2つのポイントは、ネットワークアクセスにも当てはまる点に注意してください — ファンクションに新たにAPIゲートウェイが追加されたならば、その入力も検証しなくてはなりません。
最も弱いファンクションがシステムの強度の決定項にならないように、すべてのファンクションを独立したエンティティとして扱って、セキュアな防護線を備えることが大切です。これが難しければ、開発チームの作業が容易になるように、入出力の検証や機密リソースへのアクセスを行なう共有ライブラリを用意して、潜在的なリスクのあるオペレーションに適用してください。ファンクションの防御が簡単になれば、チームがそれを実施してくれる可能性も高くなります。
デプロイメントの容易さがファンクションの急増を呼ぶ
アプリケーションのデプロイはコストを要する作業です。作業時間やハードウェアコスト、さらにはやっかいな書類も必要になります。それに対してファンクションのデプロイは、簡単で自動化されている上、多用しなければ費用もありません。低コストのため、なぜデプロイするのかではなく、なぜデプロイしないのかが問題となるのです。
この敷居の低さが、大量のファンクションのデプロイされ、しかもその大部分が利用度の極めて低いものであるという状況を発生させています。一度デプロイされたファンクションは、誰が利用しているか分からないので、十分なトラッキングをしなければ、削除することは非常に難しくなります。過度に付与された権限も、同じような理由で制限することは困難です。結果として、削除し難い大量の、しかも必要以上に強力なファンクションが、攻撃者にとって好都合の攻撃面をますます提供することになります ... サーバの世話が大変だと弱音を上げるのは、10,000のファンクションがデプロイされてからにしてください！
この問題に対処するには、(事実上の)ゼロ運用コストとゼロ所有コストは意味が違うということ、ファンクションにはセキュリティ上のリスクが伴うこと、この２つを忘れてはなりません。将来的な問題を回避するには、デプロイされたファンクションのプロセスと管理に十分な注意を払う必要があります。考慮すべきヒントをいくつか紹介しましょう。
- すべての機能をファンクションとしｙてデプロイしないこと。機能がファンクションとしてデプロイ可能であるというだけでは、そうすべき理由にはなりません。
- 重要でないファンクションは別のアカウントやリージョンにデプロイすること。
- 命名規則を利用するとともに、機能を十分に説明したREADMEファイルを提供すること。
- ネットワークとリソースの利用状況、アプリケーション層のアクティビティなどのセキュリティリスクを、すべてのファンクションについて監視し、その中の脆弱性のあるライブラリをスキャンすること。
まとめ
サーバレスは、インフラストラクチャの世界におけるエキサイティングな革命です。他のインフラストラクチャモデルと比較して、それ自体がセキュリティ面で優れていたり、あるいは劣っていたりすることはありませんが、ソフトウェアの運用方法を変えるものであることから、セキュアな採用が求められるのです。
この記事では、FaaSによって向上する、低下する、あるいは変化する、セキュリティの10の側面を見てきました。簡単にまとめましょう。
- サーバレスによって軽減されるセキュリティリスク
- OSパッチの管理が不要
- サーバの短命化により、長期間侵入されることがない
- 究極の弾力性(elasticity)であるDoS耐性の実現
- サーバレスによって変化するセキュリティリスク
- 詳細なアクセス管理は諸刃の刃
- ステートレスサーバには優れたデータセキュリティが必要
- アプリケーションのセキュリティの大幅な向上
- 脆弱なアプリケーション依存関係の隠蔽
- サーバレスによって増大するセキュリティリスク
- サードパーティサービスへの依存度の高さ
- すべてのファンクションが攻撃面を拡張
- デプロイメントの容易さに伴うファンクションの急増
私としては、FaaSを使用するかどうかを決定する上で、セキュリティをおもな理由として見ないことをお勧めします。関連するセキュリティツールがまだ初期段階であることを考えれば、セキュリティ上のメリットとデメリットは他のアプローチと大きな違いはありません。しかしながら、サーバレスによってセキュリティの優先順位がどのように変わるかを理解し、それに応じたセキュリティリソースへの投資を行うことを強く推奨します。
最後にひとつ、私の考えを述べたいと思います。ベストプラクティスやツールを含むサーバレスエコシステムは、形になりつつあるところです。正しい注意を払い、コミュニティとして協力することで、セキュリティをFaaSの世界での開発のごく自然な部分にすることが可能になります。それが実現できれば、究極のサーバレスセキュリティが達成されるでしょう。
著者について
Guy Podjarny (@guypod)氏はSnykの共同創設者兼CEOとして、オープンソースの利用とセキュリティ確保に注目しています。氏はAkamiが自身のスタートアップであるBlaze.ioを買収した後に同社のCTOとなり、最初のWebアプリファイアウォールとセキュリティコードアナライザを開発しました。数多くのカンファレンスで講演する他、O’Reillyの“Securing Open Source Libraries”、“Responsive & Fast”、“High Performance Images”の著者でもあります。