クラウドネイティブの時代、サーバレスは「安全な選択肢」として語られることが多くなりました。
特に AWS Lambda の登場以降、
- サーバ管理は不要
- パッチ適用は不要
- OSを触らない
- 自動スケールする
という言葉が並びます。
まるで、「インフラから解放されれば、セキュリティリスクも消える」かのように。
しかし本当にそうでしょうか？
この記事では、Lambdaは本当に安全なのか？ という問いを、Runtimeの観点から掘り下げていきます。
① サーバレス神話
まずは、サーバレスに対する"安心感"の正体を整理します。
■ サーバ管理不要
EC2のようにOSへログインする必要はありません。パッチ適用、ディスク管理、プロセス監視も不要。
「SSHを閉じる」どころか、そもそもSSHが存在しない。
これは確かに大きなセキュリティ向上です。
■ パッチ不要
OSの脆弱性？ ミドルウェアの更新？
それはAWS側が管理してくれます。利用者はアプリコードに集中できる。
ここもまた、従来の運用負担を劇的に減らしました。
■ OSを触らない
root権限？ カーネル？ iptables？
考える必要がありません。攻撃者がOSレベルで侵入する余地は従来より大きく減っています。
■ 自動スケール
負荷が増えれば自動でスケールする。DoS耐性も上がる。インフラの"弱点"は、確かに減っています。
では、もう安全なのか？
ここで重要な問いがあります。
「インフラを触らない = セキュリティ責任が消える」わけではない。
AWSはインフラを守ります。しかし、
- あなたのコード
- あなたのIAM設定
- あなたのデータアクセス設計
- あなたのイベントフロー
までは守ってくれません。
サーバレスは "責任共有モデルが消えた" のではなく、責任の重心が移動しただけ なのです。
② Lambdaの"本当の攻撃面"
サーバが消えたなら、攻撃も消えたのでしょうか？
答えはNoです。
攻撃面は消えていません。形を変えただけです。
■ API Gateway経由の不正入力
Lambdaの多くはAPI Gatewayから呼ばれます。
- SQLインジェクション
- コマンドインジェクション
- JSONパース悪用
- 型混乱
これらは依然として存在します。
■ IAM過剰権限
Lambdaは実行ロールを持ちます。もしそのロールが：
s3:*
dynamodb:*
kms:*
のように広すぎる場合、攻撃者はコード実行さえできればクラウド全体を操作できます。
■ 環境変数からのSecrets漏洩
Lambdaでは環境変数に：
- APIキー
- DBパスワード
- 外部サービスToken
が入っているケースも多い。入力悪用や例外ログ出力で漏洩するリスクがあります。
■ S3へのデータ流出
Lambdaはデータ処理の中心になります。
- 機密データ取得
- 加工
- 外部送信
これが悪用されたら？ "正常動作"のように見えてデータが抜かれる可能性があります。
■ ライブラリ脆弱性
LambdaはZIPやコンテナでデプロイされます。依存パッケージのCVEが存在すればそこが入口になります。
■ Event Injection
SQS / SNS / EventBridge 経由で悪意あるイベントを投入される可能性もあります。
重要なポイント
Lambdaは「サーバ」ではありません。Lambdaは コード実行環境 です。
つまり攻撃対象はインフラ層ではなく、
アプリ層 + Identity層
に集中します。
③ 最大の問題 ― "見えない"
ここが本質です。Lambdaには次の特徴があります。
■ ホストが見えない
OSにログインできません。プロセス一覧も見えません。
■ プロセスが見えない
実行されたコードがどのようなプロセスを生成したのか。確認できません。
■ syscallが見えない
- ファイルアクセス
- ネットワーク接続
- 権限昇格
低レベルの挙動は観測できません。
■ 実行時間が短い
数百ms〜数秒で終了。フォレンジックも困難。
■ コンテナが瞬間生成される
エフェメラル。侵害痕跡が残りにくい。
「検知できないものを、安全と呼べるか？」
④ 実際の侵害シナリオ ― すべてが"正常"に見える攻撃
ある典型的なLambda構成を想像してください。
API Gateway → Lambda → S3（機密データ）
実行ロールはやや広め（s3:GetObject）
攻撃の流れ
- 攻撃者がAPIへ細工した入力を送る
- Lambdaがそれを処理
- 想定外のS3オブジェクトを取得
- データを外部へ送信
このとき、
- エラーは出ない
- レイテンシも正常
- 例外ログも出ない
- スケールも正常
APM上は完全に"Healthy"。しかし実際には、データは抜かれています。
⑤ APMが見ている世界
APMが観測しているのは：
- レイテンシ
- エラーレート
- リクエスト数
- トレースの流れ
つまり、「どこが遅いか」「どこで失敗したか」は分かります。
しかし、
- なぜそのコードが実行されたのか
- そのアクセスは想定内だったのか
- 権限が濫用されたのか
- データが外部へ流れたのか
は分かりません。
APMは 健全性（Health） を見る。
セキュリティは 逸脱（Deviation） を見る。
ここに構造的な差があります。
⑥ Serverless × APM の構造的ギャップ
Lambda侵害の瞬間は、こうです。
- IAMは通常通り使用される
- API呼び出しも正常
- HTTP 200 が返る
- レスポンス時間も問題なし
APM的には：Everything is fine.
しかしセキュリティ的には：
- 想定外のS3アクセス
- 大量データ取得
- 不審な外部通信
これはパフォーマンス問題ではありません。これは "振る舞いの逸脱" です。
APMは結果を見る。Runtime Securityは行動を見る。
⑦ 攻撃は「遅く」ならない
ここが最大のポイントです。
攻撃の特徴：
- 正常API経由
- 正常IAM経由
- 正常レスポンス
- 正常メトリクス
攻撃は "異常値" を出さない。だからAPMでは守れない。
⑧ 可用性と防御は別問題
APMは本来、
- システムを止めない
- 遅くしない
- エラーを減らす
ためのものです。
しかし攻撃は、
- システムを止めない
- エラーを出さない
- むしろ正常に振る舞う
という性質を持ちます。攻撃は"健全"を装います。
だからAPMのダッシュボードは侵害中でも緑色になります。
⑨ Infrastructure → Identity → Runtime
クラウドネイティブで起きた本質的変化はこれです。
| 時代 | 侵害の流れ |
|---|---|
| 旧世界 | SSH侵入 → rootkit設置 → 永続化 → 横展開 |
| サーバレス | 入力悪用 → IAM濫用 → データ取得 → 外部送信 |
攻撃の重心が変わりました。しかし防御は、まだInfrastructure時代の発想に留まっています。
また、旧世界とサーバレスの対比で見ると：
| 旧世界 | サーバレス |
|---|---|
| パッチ漏れ | 権限漏れ |
| SSH侵入 | API悪用 |
| rootkit | IAM悪用 |
| 永続化 | データ流出 |
攻撃は OS → Identity + Event へ移動しました。
⑩ Runtime-Firstという思想
Runtime-Firstとは何か？
実行時の挙動を真実とする防御思想
設定ではなく、設計思想でもなく、「実際に何が起きたか」を見る。
従来モデル vs Runtime-First
| 視点 | APM | Runtime-First |
|---|---|---|
| 目的 | 可用性 | 防御 |
| 単位 | リクエスト | 振る舞い |
| 異常定義 | 遅い / エラー | 想定外 |
| タイミング | 事後分析 | 実行時 |
Runtime-Firstが見るもの
- どのLambdaが呼ばれたか
- 誰が呼んだか
- どのIAM権限を"使用"したか
- どのリソースにアクセスしたか
- どこへ通信したか
- それは想定内か
ここまで見なければ、本当の意味での防御とは言えません。
⑪ LambdaのRuntimeとは何か ― 層が変わった
ここで立ち止まる必要があります。
「syscallが見えないならRuntime監視は不可能」という結論は、間違いです。
正確には、こう言うべきです。
OS Runtime → API Runtime へ、層が変わった。
Kubernetesで行うような eBPF / sidecar / カーネル監視は、Lambdaには使えません。しかしそれは「Runtimeが消えた」のではありません。Runtimeの形が変わったのです。
LambdaのRuntimeとは何か
Lambda環境のRuntimeは、以下のAPIイベントの連鎖として現れます。
| 観測対象 | 意味 |
|---|---|
| Caller | 誰がこのLambdaを呼んだか |
| Identity | どのIAMロール・権限を実際に使ったか |
| Resource | 何にアクセスしたか（S3, DynamoDB, KMS...） |
| Network | どこへ通信したか（Egress先） |
| Data Flow | どれだけのデータが外へ出たか |
つまり：
Lambda の Runtime = Identity × Event × Data Flow
syscallではなく、振る舞いを見る。それがサーバレス時代のRuntime防御です。
具体的に何を見るか
① IAM使用のリアルタイム観測
設定レビューではなく、「どの権限が実際に使われたか」「それは通常の振る舞いか」を見る。Least privilegeは設計思想、Runtime-nativeは使用監視です。
② API行動の異常検知
- 突然の大量S3取得
- 深夜の管理API呼び出し
- 想定外リージョンでの実行
これがRuntimeの逸脱です。
③ データフローの可視化
どこからデータが来て、どこへ出ていったか。Egressを見なければ、防御とは言えない。
④ 呼び出しコンテキストの追跡
API Gateway経由か、EventBridgeか、SQSか、別アカウントか。"誰が呼んだか"をRuntimeで追う。
⑫ 切り札 ― Sysdig リアルタイムPosture
ここで、Sysdigが新たにリリースした機能が決定的な意味を持ちます。
リアルタイムPosture。
従来のPosture管理（CSPM）は、設定の静的スナップショットを見るものでした。
「このIAMロールは過剰権限だ」
「このS3バケットはパブリック公開されている」
これは大切です。しかし足りない。
なぜなら、設定上の問題が実際に悪用されているかどうかは分からないから。
リアルタイムPostureが変えること
Sysdigのリアルタイムポスチャーは、Runtimeの実行コンテキストとPostureを接続します。
| 従来のPosture | リアルタイムPosture |
|---|---|
| 設定ミスの列挙 | 設定ミスが"今"使われているか |
| 静的スキャン | 実行時のイベントと連動 |
| 全リスクを同列に並べる | 実際に動いているリスクを優先 |
| Build/Deploy時点 | Runtime時点 |
つまり、Lambdaに当てはめると：
- IAMの過剰権限が今この瞬間、実際に使われているか
- 想定外のリソースアクセスが今起きているか
- 異常なEgressがリアルタイムで発生しているか
これを静的設定ではなく、実行の文脈で可視化する。
「設定が間違っている」から「設定が今、悪用されている」へ。
これがリアルタイムPostureが切り札になる理由です。
⑬ Lambdaは安全か？ ― 結論
答えはこうです。
部分的に安全。だが本質的には"振る舞いが見えていない"。
安全とは：
- 見えること
- 検知できること
- 止められること
Lambdaはインフラを消しました。しかし、Runtimeは消えていない。形が変わっただけです。
最終結論
サーバレスはセキュリティを簡単にしたのではない。
セキュリティの重心を移動させただけだ。
その重心は今、
OS ではなく、Runtime Behavior にある。
APMでは守れない。静的なCNAPPだけでも不十分。
必要なのは、
Behavior-aware Runtime-native Security
syscallではなく、Identity・Event・Data Flowの連鎖を見る防御。そしてその設定上のリスクが今まさに動いているかどうかを教えてくれるリアルタイムPostureとの統合。
Sysdigはその答えを、すでに持ち始めています。
参考資料
本記事の背景となる思想・仕様・責任共有モデルについては、以下の公式資料を参照しています。
AWS 公式ドキュメント
AWS Lambda ベストプラクティス
https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html
AWS Shared Responsibility Model（責任共有モデル）
https://aws.amazon.com/compliance/shared-responsibility-model/
Lambda Execution Role（実行ロール設計）
https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html
Security Overview of AWS Lambda（ホワイトペーパー）
https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/security-overview-aws-lambda.html
クラウドネイティブセキュリティ文脈
CNCF Cloud Native Security Whitepaper
https://github.com/cncf/tag-security/blob/main/security-whitepaper/CNCF_cloud-native-security-whitepaper-Nov2020.pdf
MITRE ATT&CK Cloud Matrix
https://attack.mitre.org/matrices/enterprise/cloud/
NIST Zero Trust Architecture (SP 800-207)
https://csrc.nist.gov/publications/detail/sp/800-207/final
Observability / Monitoring 文脈
Google SRE Book – Monitoring Distributed Systems
https://sre.google/sre-book/monitoring-distributed-systems/
Runtime Security 関連
Falco Documentation（Runtime Security の概念理解）
https://falco.org/docs/
Sysdig Runtime Security Overview
https://sysdig.com/runtime-security/