概要
AWS re:Invent 2022 で AWS Lambda に対して、 Amazon Inspector によるスキャンが対応したため、その機能を検証しました。
結論
本機能は、他サービス向けの Inspector と同様に『既知の脆弱性』を検知するサービスとなります。
よって、以下のようなサービス分類となります。
| リスク | サービス | 備考 |
|---|---|---|
| ライブラリの既知の脆弱性 | Amazon Inspector （本機能） | 主に CVE ベースの検知 |
| コードの不備やバグ | Amazon CodeGuru Reviewer | プログラムミスの検知 |
| プログラムの乗っ取りなど | Prisma Cloud など | ワークロードセキュリティ製品の利用 |
Amazon Inspector による AWS Lambda 検知
詳細は上記のブログにありますが、この機能は Lambda Functions や Lambda Layer に対する アプリケーションパッケージの依存関係におけるソフトウェアの脆弱性 を検知するためのものです。
これは、例えばログ出力のためライブラリ (Log4J) や、文字色の制御のためのライブラリ (colors.js) などの脆弱性を検知可能となります。
本機能はソフトウェアの依存関係を調査しているため、コード自体のミスや脆弱性は検知できないことに注意が必要です。
自社で開発するコードの品質担保には、AWS CodeGuru Reviewer などの SAST (静的コード診断) を組み合わせることが必要です。
また、これらの対策を行なっていても、実行中のプログラムの動作不備 (ワークロードセキュリティ) を担保することはできないため、Prisma Cloud などの ワークロードセキュリティ製品も組み合わせることが重要となります。
実際の画面
スキャンの有効化
スキャンの有効化は上記の記事に記載があります。
- https://console.aws.amazon.com/inspector/v2/home で Amazon Inspector コンソールを開きます.
- ページの右上隅にある AWS リージョン セレクタを使用して、Lambda スキャンを有効にするリージョンを選択します。
- ナビゲーションペインで、 [設定] を選択し、 [アカウント管理] を選択します。
- AWS ページの上部にある [Select a Region] メニューから、Lambda 関数のスキャンを有効にするアカウントのリージョンを選択します。
- [アカウント管理] ページで、Lambda 関数のスキャンを有効にするアカウントを選択します。
- アカウント メンバーは、自分のアカウント内で Lambda 関数のスキャンを有効にできます。
- 委任された管理者は、組織内の任意のアカウントに対して Lambda 関数のスキャンを有効にすることができます。
- [有効にする] を選択して、これらのアカウントで Lambda 関数のスキャンを有効にします。
- (推奨) Lambda 関数の Amazon Inspector スキャンを有効にする各 AWS リージョンでこれらの手順を繰り返します。
今回は、東京リージョン (ap-northeast-1) で登録を行なってみましたが、簡単に設定が可能でした。
検知結果
検知は、Inspector の検出結果 Lambda 別から確認できます。
テスト用に Python と NodeJS の関数を適用しましたが、実際に検知されていることが確認できました。
検知結果の詳細は、インスタンスなどと同様に確認することが可能となります。
脆弱性のタイトルをクリックすることで、 CVE ベースの情報や、検知した場所、対応済みのバージョンなども表示する事が可能となります。
総評
現在のプログラムは、オープンソースの恩恵を強く受けており、nodejs の npm、python の pip、Java の maven などにより、プログラム作成が容易になったことは周知の事実かと思います。
しかし、これによりライブラリの依存関係が複雑化して、管理が難しくなっているというのも実情です。
例えば、 aws-sdk をインストールして利用していただけだとしても、おおよそ 50近いライブラリが依存して利用されるようになります。 (参考1)
これらすべての脆弱性を手動で組織横断的に実施することは不可能です。
これを、 Amazon Inspector で収集し、 Security Hub で集約し、 組織のセキュリティを一元管理することは、組織のリスク管理として有意であると考えられます。
最後に、改めての案内ですが、 Amazon Inspector は Lambda 関数に導入するだけで安全に利用できるような製品ではありません。
複数の製品を組み合わせて、リスクを総合的に管理していくことが大切になります。
以上
参考
参考1 aws-sdk の依存関係 (2022-12-01 現在)
├─┬ aws-sdk@2.1265.0 │ ├─┬ buffer@4.9.2 │ │ ├── base64-js@1.5.1 │ │ ├── ieee754@1.1.13 deduped │ │ └── isarray@1.0.0 │ ├── events@1.1.1 │ ├── ieee754@1.1.13 │ ├── jmespath@0.16.0 │ ├── querystring@0.2.0 │ ├── sax@1.2.1 │ ├─┬ url@0.10.3 │ │ ├── punycode@1.3.2 │ │ └── querystring@0.2.0 │ ├─┬ util@0.12.5 │ │ ├── inherits@2.0.4 │ │ ├─┬ is-arguments@1.1.1 │ │ │ ├─┬ call-bind@1.0.2 │ │ │ │ ├── function-bind@1.1.1 │ │ │ │ └─┬ get-intrinsic@1.1.3 │ │ │ │ ├── function-bind@1.1.1 deduped │ │ │ │ ├─┬ has@1.0.3 │ │ │ │ │ └── function-bind@1.1.1 deduped │ │ │ │ └── has-symbols@1.0.3 deduped │ │ │ └─┬ has-tostringtag@1.0.0 │ │ │ └── has-symbols@1.0.3 │ │ ├─┬ is-generator-function@1.0.10 │ │ │ └── has-tostringtag@1.0.0 deduped │ │ ├─┬ is-typed-array@1.1.10 │ │ │ ├── available-typed-arrays@1.0.5 │ │ │ ├── call-bind@1.0.2 deduped │ │ │ ├─┬ for-each@0.3.3 │ │ │ │ └── is-callable@1.2.7 │ │ │ ├─┬ gopd@1.0.1 │ │ │ │ └── get-intrinsic@1.1.3 deduped │ │ │ └── has-tostringtag@1.0.0 deduped │ │ └─┬ which-typed-array@1.1.9 │ │ ├── available-typed-arrays@1.0.5 deduped │ │ ├── call-bind@1.0.2 deduped │ │ ├── for-each@0.3.3 deduped │ │ ├── gopd@1.0.1 deduped │ │ ├── has-tostringtag@1.0.0 deduped │ │ └── is-typed-array@1.1.10 deduped │ ├── uuid@8.0.0 │ └─┬ xml2js@0.4.19 │ ├── sax@1.2.1 deduped │ └── xmlbuilder@9.0.7
元記事はこちら
re:Invent 2022 Lambda の Inspector 対応を検証してみた
著者：@Shirousa
アイレットなら、AWS で稼働するサーバーを対象とした監視・運用・保守における煩わしい作業をすべて一括して対応し、経験豊富なプロフェッショナルが最適なシステム環境を実現いたします。AWS プレミアティアサービスパートナーであるアイレットに、ぜひお任せください。
その他のサービスについてのお問合せ、お見積り依頼は下記フォームよりお気軽にご相談ください。
https://www.iret.co.jp/contact/service/form/
