ハッカーにとって、パッチ未適用のサーバーはまさに万能の武器です。HeartbleedからWannaCryまで、アップデートの遅いサーバーは攻撃者をレッドカーペットで招き入れるようなものです。深刻な侵害の多くはパッチ未適用のサーバーによって引き起こされており、アナリストたちは事態がさらに悪化すると予想しています。私たちは、これらの厄介なサーバーをアップデートする必要から解放される日は来るのでしょうか？
どうやら答えは「イエス」のようです！サーバーレスとその中核コンポーネントであるFunction-as-a-Service（FaaS）を使えば、コードを送信するだけで小規模なアプリ（関数）をデプロイできます。サーバーレスは明らかに裏でサーバーを利用しています。しかし、サーバーレスでは、プラットフォームを運営する「プロ」たちがパッチ適用を含むサーバー管理を私たちに代わって行ってくれ、短命なサーバーを更新することでセキュリティの抜け穴を塞ぐという素晴らしい仕事をしてくれています。
しかし、影には別のリスクが潜んでいます。Mavenやnpmなどのレジストリから取得された脆弱なライブラリが、関数に組み込まれているのです。Equifaxの情報漏洩やSpring Breakなどの事例からもわかるように、これらのパッケージはサーバーと同じくらい蔓延しており、同様に脆弱になる可能性があります。
これらのパッケージは、サーバーレスの世界における盲点に陥っています。プラットフォームとアプリケーションの所有者の両方が見落としており、インフラストラクチャとコードの間の曖昧な領域に陥っています。FaaSの採用が拡大し、関数が大量にデプロイされるにつれて、これらの関数は古くなり、脆弱になる可能性があります。では、パッチが適用されていない関数は、パッチが適用されていない新しいサーバーなのでしょうか？
関数をデプロイしてみませんか?
関数はスコープが小さく、記述も容易で、いくつかの簡単なコマンドでデプロイでき、実質的にあらゆるトラフィック量に合わせてスケールできます。しかも、ユーザーの手間は一切かかりません。このシンプルさだけでは魅力が足りないなら、サーバーレスは驚くほど安価でもあります。ほとんどのFaaSプラットフォームは、使用量に応じて課金し、100ミリ秒単位という極めて小さな粒度で課金するため、価格が大幅に抑えられています。サーバーレスは簡単かつ安価の典型であり、テクノロジー業界では急速に導入が進んでいます。この革新的なコストモデルは、「何をデプロイする価値があるのか？」という問いを根底から覆すものです。
「サーバーフル」の世界では、コードのデプロイには多大なコストがかかります。コードのデプロイには多大な労力（時間がかかります）、継続的なコンピューティングリソースの割り当て（費用がかかります）、継続的なキャパシティ監視の設定（さらに時間がかかります）、そしてさらに、これらのサーバーに継続的にパッチを適用し、外部の悪意のあるユーザーから保護する必要があります。これらのコストは、デプロイする価値があり、価格に見合うだけの価値があるコードのみをデプロイすることを意味します。
サーバーレスでは、関数をデプロイしない理由はほとんどありません。非常に簡単で、実際に関数が使用されるまではコストもほとんどかからず、継続的なキャパシティ監視も不要です。安価で簡単、そして美しい。実際、cronジョブを関数に変換し、ハッカソンで公開した本番環境用の関数をそのまま公開しているという話をよく耳にしますが、それは…なぜそうしないのでしょうか？
機能の導入は簡単ですが、削除は容易ではありません。誰がその機能に依存しているかわからないからです。たとえその機能がめったに呼び出されないとしても、災害復旧や年次報告書の作成に必要になるかもしれませんし、あるいは単に同僚が必要とする便利なユーティリティかもしれません。この質問への回答は、機能が長く存在するほど難しくなります。なぜなら、その機能とその役割に関する組織内の知識は薄れていくからです。サーバーの廃止にも同じ課題が伴いますが、機能にはコストがかからないため、労力を費やしたりリスクを負ったりするインセンティブはほとんどありません。
こうして、あっという間に、そして確実に、膨大な数の関数が蓄積されていくのがわかるでしょう。ちょっとしたユーティリティから本格的な本番環境サービスまで、AWS Lambdaのリストはどんどん増えていきます。請求書は横ばいかもしれませんが、リスクスコアは変わりません。
関数のセキュリティコスト
この新しい関数コレクションの趣味を構築する際に忘れているのは、デプロイするすべての関数がセキュリティ上のリスクになるということです。
まず、すべての関数は、特定のビジネスロジックを呼び出す新しいインターフェースを公開します。具体的なアクセスは、関数の設定またはフロントエンドAPIゲートウェイによって定義されます。ハッカーの観点から見ると、これは攻撃対象領域が拡大し、製品カタログのスクレイピング、転売目的のチケット予約、バックエンドシステムの過負荷によるユーザーサービス拒否など、意図しない利益を得るためにビジネスロジックを操作または悪用する機会が増えることを意味します。
ビジネスロジックの操作以外にも、あらゆる関数にはセキュリティ上の脆弱性が存在する可能性があり、実際に多くの関数がそうである可能性が高いです。関数の権限によっては、攻撃者はこうした脆弱性を悪用して顧客データを盗んだり、ビットコインマイニングのためにCPUサイクルを盗んだり、ネットワークのより深い部分に侵入したりする可能性があります。関数がそのような操作を許可するように設計されていたかどうかは問題ではなく、どのような権限が許可されていたかが問題です。
サーバーレス：怖がるべきか？そうかもしれない。馬鹿げた名前か？そうかもしれない。
続きを読む
権限もまた、増えることはあっても減ることはない、厄介な問題です。権限の追加は簡単ですが、削除は困難です。何が壊れるかわからないからです。さらに、細分化された権限の管理は煩雑で、多くの機能（そしてシステム全体）が、本来許可されるべき以上のことを実行できてしまいます。こうした権限の拡大はサーバーレス特有の問題ではありませんが、FaaSでは権限管理を必要とするエンティティ（つまり機能）の数が大幅に増加するため、リスクがさらに高まります。
最後に、そしておそらく最悪なのは、ほとんどの関数がオープンソースアプリケーションへの依存関係を含んでいることです。これらのライブラリは関数内に静的に埋め込まれているため、新しいバージョンのライブラリが公開されても古くなります。時間の経過とともに、これらの古いバージョンに脆弱性が発見され、中には深刻なものも含まれていますが、サーバーレスフローではその存在を通知されません。これを回避するには、攻撃者に悪用される前に、関数に大規模なパッチを適用し、繰り返し更新する必要があります。身に覚えがあるのではないでしょうか？
ここまで読んでいただければ、関数の数が多いことがなぜ懸念材料になるのか、少しはご理解いただけたかと思います。このリスクの一部は、本番環境で稼働するコードが増えていることに起因していますが、保護すべきものはコードだけだと考えることで、状況はさらに悪化しています。
インフラの散りばめ
サーバーレスは、関数を実行するサーバーが依然として存在するため、常に議論の的となってきました。実際には、「サーバー管理レス」を実現し、弾力的なキャパシティ管理やサーバーOSのセキュリティ維持といった負担を軽減します。しかし、サーバーを管理していないとはいえ、実際にはインフラストラクチャの管理は依然として行われているのです。
コードに関する懸念に加え、先ほど述べたセキュリティ上の懸念には、設定、権限管理、そして古い依存関係という3つの要素が含まれますが、これらはコードの問題ではありません。実際、これらの要素は、サーバー管理時に対処しなければならないリスクと非常によく似ており、その挙動も非常に似ています。
実のところ、これらは私たちの機能の中に散りばめられたインフラの断片です。完璧なインフラストラクチャ・アズ・コードとして、これらは多くの場合、機能プロジェクトの一部として定義・パッケージ化されていますが、適切に処理するには、それらがインフラストラクチャであるという本質を認識する必要があります。この視点は、このリスクを適切かつ大規模に管理する上で役立ちます。
関数内のインフラストラクチャだけでなく、関数自体の管理もインフラ管理に含まれます。基盤となるOSが私たちの手に渡ったとしても、サーバー、VM、コンテナと同様に、これらを管理する必要があります。
私たちはどこへ向かうのでしょうか？
業界が現状の軌道を辿れば、来年には数百、いや数千ものデプロイされた関数に囲まれて目を覚ますことになるでしょう。これらの関数の多くは過剰な権限と古くなった組み込みライブラリを持ち、その使用期間が長くなると、他の誰かが依存している機能を壊さずに削除することが困難になるでしょう。
幸いなことに、サーバーレスはまだ黎明期にあり、軌道修正の機会は豊富にあります。何を、そしてなぜデプロイするのかをしっかりと意識することが重要です。ある関数をデプロイする価値があるかどうかを自問自答し、将来どのように追跡、管理、そして廃止していくかを検討しましょう。サーバーレスは依然として強力な新しいトレンドであり、活用すべきですが、正しく実行する必要があります。
さらに、役立つツールやプラクティスがあります。Terraform、プラットフォームKMS、Snykなどのツールは、サーバーレスインフラストラクチャの管理に役立ちます。また、iRobotやNordstromなどのリーダーによるベストプラクティスも参考になります。®
