サーバーレスコンピューティングは、決して気楽なコンピューティングではありません。クラウドサービスプロバイダーへの請求を除けば、サーバーについて心配する必要はありません。しかし、アプリケーションのセキュリティについては、ある程度考慮することをお勧めします。
サーバーレス モデル (実際にはサーバーレスではありません。サービスとしてのプラットフォームですが、定期的な期間ではなくアプリケーションの実行時に課金されます) では、開発者は依然として自分のコードに対して責任を持つ必要があります。
AWSなどのサービスには、隠れたインフラを守るための運用担当者が多数在籍しているため、セキュリティに関する懸念は少ない。しかし、サーバーレス関数を開発する側は、すべてが順調だと安易に思い込むことはできない。
「アプリケーション自体とそのすべてのインターフェースは、アプリケーションを実行する顧客の責任です」と、イスラエルのテルアビブに拠点を置く設立2年のセキュリティ系スタートアップ企業PureSecの営業および事業開発担当副社長、ラン・ナミアス氏はThe Registerとの電話会見で説明した。
先週、サンフランシスコで開催された AWS サミットに合わせて、PureSec は、その責任を果たす方法として、サーバーレス セキュリティ ランタイム環境 (SSRE) をベータ版で提供しました (サインアップが必要)。
サーバーレス化をお考えですか？その方法を教えてください。そして世界に伝えましょう
続きを読む
PureSec のソフトウェアは、アプリケーションまたは関数と呼ぶサーバーレス コードを実行しているユーザーに、インジェクション攻撃、パス トラバーサル攻撃、リソースの構成ミス、依存関係のバグ、公開されたシークレットなど、一般的なアプリの脆弱性をリアルタイムで検出して軽減する機能を提供します。
HBO の現在のシーズンの「シリコンバレー」で適切に揶揄された、昔のラックマウント型エンタープライズ ハードウェアとは対照的に、PureSec はソフトウェアの形でセキュリティを販売しています。
コードはライブラリとして提供されており、プロジェクトにインポート行を1つ追加するだけで使用できます。また、サーバーレスモデルにふさわしく、課金は時間ではなく実際の使用量に応じてスケールします。クラウド関数を誰も使用していない場合は、料金が発生することはありません。
サーバーレス関数の脅威の例として、SQL インジェクションを使用して AWS Lambda 上の関数を呼び出す悪意のあるコマンドを考えてみましょう。
sls invoke -f insecure_app -d "{\"username\":\"foo' union select password from usersTable;--"}" -l
PureSec の SSRE はリクエストをインターセプトして実行を阻止し、攻撃に関する情報をログ ファイルとダッシュボードに渡します。
このソフトウェアには、トレーニング可能な基準から逸脱するパターンを検出するための行動エンジンも含まれています。
CTOのオリー・シーガル氏は、開発者が常に最小権限の原則に従っているわけではないと指摘しました。書き込み権限を持つAWS S3バケットが、読み取り権限のみを必要とするコードから呼び出された場合、PureSecのソフトウェアはこの矛盾を検出します。
シーガル氏は、AWS DynamoDBデータベースを利用するアプリケーションを例に挙げました。アプリケーションが特定のテーブルのみを必要としているにもかかわらず、より広範なアクセスを許可するように設定されている場合、これも検出されます。
PureSecが実施したオープンソースのサーバーレスプロジェクト1,000件のスキャンによると、21%に1つ以上の重大な脆弱性または設定ミスが見つかりました。（おそらく最も注目すべき発見は、DotNetプロジェクトの脆弱性が、Go、Java、Python、NodeJSといった他のランタイムで記述されたプロジェクトの2倍だったことです。）
シーガル氏は、PureSec のソフトウェア開発における課題は、ルートアクセスなしでソフトウェアを動作させる方法を見つけることだったと語った。
「既存のセキュリティソリューションはサーバーレスモデルには適合しません」と彼は述べた。「ここでの主な技術的障壁は、私たちも（クラウドの）ゲストユーザーであるという点です。」
一般発売は7月に予定されていると彼は述べた。®
