yuj1osm's tech blog

クラウドやセキュリティなど

Amazon CloudWatch Logs のフィルターパターンで正規表現が使えるようになりました

Amazon CloudWatch Logs のフィルターパターンで正規表現が使えるようになったので、検証してみました。

aws.amazon.com

アップデート概要

  • フィルターパターンで正規表現が使えるようになり、複雑な条件のログ検索や突合処理が可能

  • サポートされている正規表現はドキュメントに記載されています。

docs.aws.amazon.com

正規表現でログを抽出してみる

今回は以下のフィルターパターンとサンプルログで試してみます。

フィルターパターン
statusCodeが400番台を抽出します。

{ $.statusCode=%4[0-9]{2}% }

サンプルログ

[83078518-fcc1-4d30-9573-8b9737671438] BENCHMARK : Running Start Crawl for Crawler TestCrawler2
[83078518-fcc1-4d30-9573-8b9737671438] BENCHMARK : Classification complete, writing results to database mygluedatabase
[83078518-fcc1-4d30-9573-8b9737671438] INFO : Crawler configured with SchemaChangePolicy {"UpdateBehavior":"UPDATE_IN_DATABASE","DeleteBehavior":"DEPRECATE_IN_DATABASE"}.
{ "statusCode": "403" }
[83078518-fcc1-4d30-9573-8b9737671438] INFO : Created table gluetest in database mygluedatabase
{ "statusCode": "404" }
{ "statusCode": "500" }
[83078518-fcc1-4d30-9573-8b9737671438] BENCHMARK : Finished writing to Catalog
[83078518-fcc1-4d30-9573-8b9737671438] BENCHMARK : Crawler has finished running and is in state READY

適当なロググループとログストリームを作成します。

サンプルログを使ってログイベントを作成します。

「フィルターバー」にフィルターパターンを入力して検索してみます。
statusCodeが400番台のみ抽出され、想定通りの結果です。

サブスクリプションフィルターでも試してみます。
サブスクリプションフィルター」→「作成」から任意のフィルターを選択します。

サブスクリプションフィルターのパターン」にフィルターパターンを入力します。
そして、「イベントメッセージをログ記録に」サンプルログを入力し、「パターンをテスト」を押下します。
こちらもstatusCodeが400番台のみ抽出され、想定通りの結果です。

まとめ

フィルターパターンで正規表現を使うことで、ログ検索ができました。
従来、複雑な条件でログ検索したいときには、Lambdaで正規表現の処理をする方法がありました。
今回のアップデートにより、標準機能で手軽に複雑な処理を行うことができるようになったので、ぜひ活用してみてください。

「Amazon Style」と「amazon fresh」で最新のCX(カスタマー・エクスペリエンス)を体験してきた

先日アナハイムで開催されたAWS re:Infroce 2023へ、ジャパンツアーで参加しました。
そのツアー中に、「Amazon Style」と「amazon fresh」に立ち寄ったので、そこで体験した最新のCX(カスタマー・エクスペリエンス)についてご紹介します。

Amazon Style

Amazon Styleは、米アマゾンがロサンゼルスにある衣料品の実店舗です。

Amazon Style店内の様子

入り口にはおしゃれなオブジェがあります。

広々とした店内ですが、一見変わった様子はありません。

しかし、商品に近づいてみると何やらQRコードがついています。

このQRコードを専用アプリで読み込むと、サイズや色展開などの詳細情報を確認することができます。
試着したい商品はボタンを押すことで、自分専用の試着室が確保されます。

レコメンド商品も届けてくれる試着室

確保された番号の試着室に行ってみます。

スマホからとロックを解除すると、試着室に入れます。
試着室は広く、中にはディスプレイがあり、自身の名前が表示されています。

試着室内にはクローゼットがあり、しばらくすると売り場で選んだ商品と、レコメンド商品も一緒に入っています。
このクローゼットは裏からも空けられるようになっており、独自のアルゴリズムにより顧客の趣向に合う商品も届けられます。 顧客側の扉が閉まっている間だけ、裏から商品を届けてくれる仕組みなので、プライバシーは守られるようになっています。

クローゼット内のディスプレイにもレコメンド商品が表示されるので、ここからさらに商品を選択して届けてもらうことが可能です。
つまり、わざわざ売り場に戻る必要が無く、クローゼットの中で商品の選択と試着が完結する形になっています。
購入したい場合はレジに商品を持っていき、専用アプリで決済用のQRコードを使って購入できます。

amazon fresh

amazon freshは、ロサンゼルス郊外にあるテクノロジーを駆使した食品スーパーです。

amazon fresh店内の様子

店内は非常に広々としており、品揃えもよいです。

商品の記録から清算までしてくれるカート

入り口にはアマゾン・ダッシュカートというものがあります。
カートにはカメラや重量センサー、タッチスクリーンが搭載されています。

まずは、専用のアプリでカートに利用者情報を読み込ませます。

売り場では、バーコードをカメラに向けてカートに入れていくだけです。
カートがカメラや重量から商品を認識して、商品名や数量、価格がタッチスクリーンに表示されます。
清算の際は、専用のレーンを通ります。
この専用レーンにはセンサーが設置されていて、カートを検知したら自動的に精算が終わります。

レジに並ぶ必要がないので、非常に簡単に買い物ができます。

まとめ

Amazon Style」と「amazon fresh」で最新のCXを体験することができました。
両者とも最新のテクノロジーが駆使されており、楽しく手軽に買い物ができるように工夫されていました。
今後の技術発展に伴い、さらに面白い体験ができると思われます。
ロサンゼルスに行った際は、ぜひ立ち寄ってみてください。

re:Inforceのハンズオンセッション参加レポート

アナハイムで開催されたAWS re:Infroce 2023のハンズオンセッションについてご紹介します。

ハンズオンセッションとは

re:Inforceはハンズオンセッションが非常に多く、手を動かして学びたい人にとって非常におすすめです。
ハンズオンは「AWS Workshop Studio」を利用し、一時的なAWSアカウントと手順書が与えられるので、料金の心配もありません。
以下のような少人数のテーブルに分けられて、各テーブルにAWSの技術者がつきます。
手順で困ったり疑問があればすぐに質問することができます。

当日発表された新サービスを体験するセッションもあり、いち早く試すことができます。
また、参加者同士の交流もあり様々な意見を聞けることが、現地ならではの体験です。

ハンズオンセッションのご紹介

今回体験したハンズオンをいくつかご紹介します。

[GRC351] Build an end-to-end DevSecOps pipeline on AWS

セキュリティとコンプライアンスのテストが開発プロセスに統合されたDevSecOps CI/CDパイプラインを構築します。
Amazon CodeCatalystを使用してポリシー検証を実行し、パイプラインのデプロイメントに一貫性があり、組織のコンプライアンス基準を満たしていることを確認します。

以下が構成図です。

Amazon CodeCatalystでリポジトリを作成し、環境やワークフローの設定を行います。

チェックで失敗するようになっているので、チェックが通るように修正していきます。

[TDR251] Streamline and centralize security operations with AWS Security Hub

AWS Security Hubのアラートの優先順位付けや調査方法などを学びます。

すでにたくさんの検知があるSecurity Hubダッシュボードです。

どのようにアラートを調査して、どのようなアプローチが取れるかを考察していきます。

[GRC353] Build a security posture leaderboard using AWS Security Hub

AWS Security Hubの調査結果を使用して、堅牢で包括的なリーダーボードを作成する手法を学びます。

最終的にこのようなものができます。

以下が構成図です。
Security HubのイベントをEventBridgeとKinesis Firehose経由でS3に保存し、Glue、Athena、QuickSightを使ってダッシュボードを作成します。

Glueクローラーでデータを検出し、Athenaで分析します。

そして、QuickSIghtでダッシュボードを作成していきます。

まとめ

用意された環境で、いち早く新サービスを試せたり、ベストプラクティスや工夫した手法を学習できるため、非常に楽しく勉強できました。
その場で議論や質問ができるのも現地でハンズオンをする醍醐味ですね。
手を動かして学びたい方は、ぜひ現地でハンズオンセッションに参加してみてください。

Security Hub automation rulesで検出結果を更新または抑制できるようになりました

Security Hub automation rulesで検出結果を更新または抑制できるようになったので、検証してみました。

aws.amazon.com

アップデート概要

  • 検出結果のさまざまなフィールドの自動更新、検出結果の抑制、重大度やワークフローステータスの更新、メモの追加が可能

事前準備

Security Hubのメニューに「オートメーション」が追加されています。

今回は更新と抑止を検証したいので、それぞれの共同を確認するために、ブロックパブリックアクセスを無効にしたS3バケットを2つ用意します。

検出結果の重要度を変更する

S3バケット「test1-automation-rules-bucket」のブロックパブリックアクセスが無効であることを検出させ、その重要度を変更します。

「オートメーション」→「ルールを作成」から、ルールテンプレート「Elevate severity of findings that relate to important resources」を選択します。

条件で、ResourceIdにS3バケットに「test1-automation-rules-bucket」のARNを指定します。

重要度はデフォルトで「CRITICAL」になっています。

ルールステータスが「有効」になっていることを確認し、「ルールを作成」を押下します。

複数のコントロールで検出されるため、今回は「AWS基礎セキュリティのベストプラクティス v1.0.0」から「[S3.8] S3 Block Public Access setting should be enabled at the bucket level」に絞って確認します。
SecurityHubの定期チェック後に検出結果を確認してみると、本コントロールの重要度は通常HIGHですが、CRITICALに変更されていることが分かります。
また、自動アクションに記載されているノートが反映されています。

詳細の画面も同様に変更されています。

また、履歴タブから「オートメーション」が重要度とノートを変更したことが記録されています。

JSONログを確認すると、元の重要度はSeverity.Originalに保持され、Severity.Labelに変更後の値が記録されています。
また、Noto.Textにノートが記録されています。

{
  "SchemaVersion": "2018-10-08",
  "Id": "arn:aws:securityhub:ap-northeast-1:xxxxxxxxxxxx:subscription/aws-foundational-security-best-practices/v/1.0.0/S3.8/finding/xxxxxxxxxxxx",
  "ProductArn": "arn:aws:securityhub:ap-northeast-1::product/aws/securityhub",
  "ProductName": "Security Hub",
  "CompanyName": "AWS",
  "Region": "ap-northeast-1",
  "GeneratorId": "aws-foundational-security-best-practices/v/1.0.0/S3.8",
  "AwsAccountId": "xxxxxxxxxxxx",
  "Types": [
    "Software and Configuration Checks/Industry and Regulatory Standards/AWS-Foundational-Security-Best-Practices"
  ],
  "FirstObservedAt": "2023-06-26T04:04:35.301Z",
  "LastObservedAt": "2023-06-26T04:04:42.291Z",
  "CreatedAt": "2023-06-26T04:04:35.301Z",
  "UpdatedAt": "2023-06-26T04:04:35.301Z",
  "Severity": {
    "Product": 70,
    "Label": "CRITICAL",
    "Normalized": 70,
    "Original": "HIGH"
  },
  "Title": "S3.8 S3 Block Public Access setting should be enabled at the bucket-level",
(省略)
  "Note": {
    "Text": "This is a critical resource. Please review ASAP.",
    "UpdatedBy": "sechub-automation",
    "UpdatedAt": "2023-06-26T04:04:45.635Z"
  },
(省略)

検出結果を抑制する

S3バケット「test2-automation-rules-bucket」のブロックパブリックアクセスが無効であることを検出させ、その検出を抑制します。

「オートメーション」→「ルールを作成」から、ルールテンプレート「Suppress informational findings」を選択します。

条件で、ResourceIdにS3バケットに「test2-automation-rules-bucket」のARNを指定します。

ワークフローステータスはデフォルトで「SUPPRESSED」になっています。

ルールステータスが「有効」になっていることを確認し、「ルールを作成」を押下します。

先ほどと同様、「AWS基礎セキュリティのベストプラクティス v1.0.0」から「[S3.8] S3 Block Public Access setting should be enabled at the bucket level」に絞って確認します。
ワークフローのステータスが「SUPPRESSED」に変更されています。
また、自動アクションに記載されているノートが反映されています。

詳細の画面も同様に変更されています。

また、履歴タブから「オートメーション」がステータスとノートを変更したことが記録されています。

JSONログを確認すると、Workflow.Statuslに抑制を表す「SUPPRESSED」が記録されています。
また、Noto.Textにノートが記録されています。

{
  "SchemaVersion": "2018-10-08",
  "Id": "arn:aws:securityhub:ap-northeast-1:xxxxxxxxxxxx:subscription/aws-foundational-security-best-practices/v/1.0.0/S3.8/finding/xxxxxxxxxxxx",
  "ProductArn": "arn:aws:securityhub:ap-northeast-1::product/aws/securityhub",
  "ProductName": "Security Hub",
  "CompanyName": "AWS",
  "Region": "ap-northeast-1",
  "GeneratorId": "aws-foundational-security-best-practices/v/1.0.0/S3.8",
  "AwsAccountId": "xxxxxxxxxxxx",
  "Types": [
    "Software and Configuration Checks/Industry and Regulatory Standards/AWS-Foundational-Security-Best-Practices"
  ],
  "FirstObservedAt": "2023-06-26T04:04:35.301Z",
  "LastObservedAt": "2023-06-26T04:04:40.573Z",
  "CreatedAt": "2023-06-26T04:04:35.301Z",
  "UpdatedAt": "2023-06-26T04:04:35.301Z",
(省略) 
  "Workflow": {
    "Status": "SUPPRESSED"
  },
  "RecordState": "ACTIVE",
  "Note": {
    "Text": "Automatically suppress this bucket",
    "UpdatedBy": "sechub-automation",
    "UpdatedAt": "2023-06-26T04:04:42.523Z"
  },
(省略)

まとめ

Security Hub automation rulesで検出結果を更新または抑制することができました。
これまで、手動で対応していた運用を、事前にルールを定義することで自動化することができます。
きめ細やかな条件を指定できることで運用が楽になると思うので、ぜひ活用してみてください。

Amazon EC2 Instance Connect Endpoint経由でEC2インスタンスのプライベートIPアドレスにSSH接続する

Amazon EC2 Instance Connectで、パブリック IP アドレスなしのSSHおよびRDP接続ができるようになりました。

aws.amazon.com

今回はプライベートサブネットに配置したEC2インスタンスに、Amazon EC2 Instance Connect Endpoint経由でSSH接続をしてみます。
以下が今回作成する構成図です。

アップデート概要

  • EC2 Instance Connect Endpoint (EIC エンドポイント) を使用すると、パブリック IP アドレスを使用せずに EC2 インスタンスSSHおよびRDP接続が可能
  • プライベートサブネット内のインスタンスにリモート接続できるため、接続にパブリックIPv4アドレスを使用する必要がない

事前準備

構成図のセキュリティグループを作成しておきます。

EC2 Instance Connect Endpoint用のセキュリティグループ

セキュリティグループ名 : test-eic-sg
 インバウンドルール : なし
 アウトバウンドルール : セキュリティグループ「test-ec2-sg」宛のSSH(22)

EC2インスタンス用のセキュリティグループ

セキュリティグループ名 : test-ec2-sg
 インバウンドルール : セキュリティグループ「test-eic-sg」からのSSH(22)
 アウトバウンドルール : 0.0.0.0/0宛の全ポート

VPCの「エンドポイント」→「エンドポイントの作成」から、「EC2 Instance Connect Endpoint」を選択します。

事前に作成した、EC2 Instance Connect Endpoint用のセキュリティグループ「test-eic-sg」を選択し、サブネットを指定して、「エンドポイントを作成」を押下します。

EC2に接続する

それでは、AWSマネジメントコンソールから接続するEC2インスタンスを選択し、Amazon EC2 Instance Connect Endpoint経由でSSH接続してみます。
「EC2 Instance Connect」タブから、「EC2 Instance Connectエンドポイントを使用して接続する」を選択し、エンドポイントを指定して、「接続」します。

接続できました。

CloudTrailログを確認する

AWS CloudTrailで接続ログを取得しているので、いつ誰がどのインスタンスに接続したかを調査することができます。
イベント名は「OpenTunnel」です。

Trailログの例

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": "xxxxxxxxxxxx",
        "arn": "arn:aws:iam::xxxxxxxxxxxx:user/xxxxxxxxxxxx",
        "accountId": "xxxxxxxxxxxx",
        "accessKeyId": "xxxxxxxxxxxx",
        "userName": "xxxxxxxxxxxx"
    },
    "eventTime": "2023-06-25T05:09:44Z",
    "eventSource": "ec2-instance-connect.amazonaws.com",
    "eventName": "OpenTunnel",
    "awsRegion": "ap-northeast-1",
    "sourceIPAddress": "xxxxxxxxxxxx",
    "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/114.0",
    "requestParameters": {
        "instanceConnectEndpointId": "eice-xxxxxxxxxxxx",
        "maxTunnelDuration": "3600",
        "remotePort": "22",
        "privateIpAddress": "10.0.128.161"
    },
    "responseElements": null,
    "requestID": "xxxxxxxxxxxx",
    "eventID": "xxxxxxxxxxxx",
    "readOnly": false,
    "resources": [
        {
            "accountId": "xxxxxxxxxxxx",
            "type": "AWS::EC2::InstanceConnectEndpoint",
            "ARN": "arn:aws:ec2:ap-northeast-1:xxxxxxxxxxxx:instance-connect-endpoint/eice-xxxxxxxxxxxx"
        }
    ],
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "xxxxxxxxxxxx",
    "eventCategory": "Management"
}

SSM Session Managerとの違い

以前、SSM Session Managerを使ってEC2インスタンスに接続する方法を紹介しました。

yuj1osm.hatenablog.com

SSM Session ManagerはIAMポリシーでアクセスコントロールをしているのに対し、Instance Connect Endpointはセキュリティグループでアクセスコントロールしています。
要件に応じて使い分ければ良いと思います。

また、SSM Session Managerは3つのVPCエンドポイントが必要で費用が掛かりますが、Instance Connect Endpointは無料になります。
費用面を気にする場合は、このメリットは大きいと思います。

まとめ

プライベートサブネットに配置したEC2インスタンスに、Amazon EC2 Instance Connect Endpoint経由でSSH接続することができました。
プライベートサブネットのEC2インスタンスに対して、手軽に安全に接続できるため、非常に使い勝手が良いと思います。
SSM Session Managerとの違いを意識しながら、要件に応じて使い分けていただければと思います。

Amazon InspectorでSBOMエクスポートができるようになりました

Amazon InspectorでSBOMエクスポートができるようになったので、検証してみました。

aws.amazon.com

SBOM(Software Bill of Materials、ソフトウェア部品表)とは、ソフトウェアを構成するコンポーネントや互いの依存関係、ライセンスデータなどをリスト化した一覧表であり、ソフトウェアサプライチェーンリスク管理等に利用されます。

アップデート概要

  • Amazon Inspectorで監視されているすべてのリソースのSBOMを、CycloneDxやSPDXなどの業界標準形式でエクスポート可能
  • ソフトウェアパッケージに関する詳細と、関連する脆弱性情報が含まれている

検証

事前準備

Inspectorのメニューに「Export SBOMs」があります。

SBOMに脆弱性情報を含ませるため、マーケットプレイスから古いAMIを取得し、EC2インスタンスを起動します。

202個の脆弱性が検知されました。

出力先のS3バケットとKMSキーを用意します。
S3バケットとKMSキーのポリシーが適切に設定されていないとエラーになるので、以下のドキュメントを参考に設定します。

docs.aws.amazon.com

バケットポリシー

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "allow-inspector",
            "Effect": "Allow",
            "Principal": {
                "Service": "inspector2.amazonaws.com"
            },
            "Action": [
                "s3:PutObject",
                "s3:PutObjectAcl",
                "s3:AbortMultipartUpload"
            ],
            "Resource": "arn:aws:s3:::<S3バケット名>/*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "<AWSアカウントID>"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:inspector2:<リージョン>:<AWSアカウントID>:report/*"
                }
            }
        }
    ]
}
                

KMSキーポリシー

{
    "Sid": "Allow Amazon Inspector to use the key",
    "Effect": "Allow",
    "Principal": {
        "Service": "inspector2.amazonaws.com"
    },
    "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey*"
    ],
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "aws:SourceAccount": "<AWSアカウントID>"
        },
        "ArnLike": {
            "aws:SourceArn": "arn:aws:inspector2:<リージョン>:<AWSアカウントID>:report/*"
        }
    }
}        

SBOMをエクスポートする

「Export SBOMs」に戻り、エクスポートの設定を行います。
「Add filter」でエクスポート対象を選択することができます。

利用できるフィルターは以下ドキュメントで確認できます。

docs.aws.amazon.com

今回はタグを使って、先ほどのEC2インスタンスを選択します。

事前準備で作成したS3バケットとKMSキーを選択し、「Export」を押下します。

エクスポートが始まります。

数分後にエクスポートが完了します。

S3バケットにSBOMが出力されました。

ファイルを確認します。
EC2インスタンスの情報から、ソフトウェア情報と検知された脆弱性情報が分かります。

{
    "bomFormat": "CycloneDX",
    "specVersion": "1.4",
    "version": 1,
    "metadata": {
        "timestamp": "2023-06-25T02:34:37Z",
        "component": {
            "type": "operating-system",
            "name": "AMAZON_LINUX_2"
        },
        "properties": [
            {
                "name": "amazon:inspector:ami",
                "value": "ami-xxxxxxxxxxxx"
            },
            {
                "name": "amazon:inspector:arch",
                "value": "x86_64"
            },
            {
                "name": "amazon:inspector:account_id",
                "value": "xxxxxxxxxxxx"
            },
            {
                "name": "amazon:inspector:resource_type",
                "value": "AWS_EC2_INSTANCE"
            },
            {
                "name": "amazon:inspector:instance_id",
                "value": "i-xxxxxxxxxxxx"
            },
            {
                "name": "amazon:inspector:resource_arn",
                "value": "arn:aws:ec2:ap-northeast-1:xxxxxxxxxxxx:instance/i-xxxxxxxxxxxx"
            }
        ]
    },
    "components": [
        {
            "type": "application",
            "name": "elfutils-libelf",
            "purl": "pkg:rpm/elfutils-libelf@0.176-2.amzn2?arch=X86_64&epoch=0&upstream=elfutils-libelf-0.176-2.amzn2.src.rpm",
            "version": "0.176",
            "bom-ref": "ddf56a513c0e76ab2ae3246d9a91c463"
        },
        {
            "type": "application",
            "name": "libffi",
            "purl": "pkg:rpm/libffi@3.0.13-18.amzn2.0.2?arch=X86_64&epoch=0&upstream=libffi-3.0.13-18.amzn2.0.2.src.rpm",
            "version": "3.0.13",
            "bom-ref": "7815cd0f8a2522a9c1bfa22c7c75e0d5"
        },

(省略)

    "vulnerabilities": [
        {
            "id": "CVE-2022-40304",
            "affects": [
                {
                    "ref": "d767c0d05ad199c30aa487f4c139fc94"
                },
                {
                    "ref": "1ec2a0f3c6035ce88b5256faa942a09d"
                }
            ]
        },
        {
            "id": "CVE-2022-32221",
            "affects": [
                {
                    "ref": "49a798c08887e728538e676d0702a3d8"
                },
                {
                    "ref": "4b5db358ca74293f49fb57d2a0bef249"
                }
            ]
        },

    ]
}

エクスポートされたファイルに含まれる脆弱性の数が、Inspectorで確認したものと一致するか確認しておきます。
下記のコマンドで202個という結果なので、一致しています。

$ aws s3 cp s3://test-sbom-export-bucket/CYCLONEDX_1_4_outputs_xxxxxxxxxxxx/account=xxxxxxxxxxxx/resource=AWS_EC2_INSTANCE/i-xxxxxxxxxxxx_CYCLONEDX_1_4.json - | jq '.vulnerabilities[].id' | wc -l
202

まとめ

Amazon InspectorのSBOMエクスポート機能を確認しました。
脆弱性情報だけでなく、ソフトウェアパッケージの構成情報まで出力できるようになり、Inspectorの幅が一気に広がりました。
昨今のソフトウェア構成の複雑化により、SBOMの重要性がさらに増しているので、脆弱性管理の一貫としてぜひ活用してみてください。

Amazon InspectorでLambda関数のコードスキャンができるようになりました

AWS re:Inforce 2023にて、AWSセキュリティサービスについてたくさんのアップデートがありました。
Amazon InspectorでLambda関数のコードスキャンができるようになったので、検証してみました。

aws.amazon.com

本アップデートは2月にプレビュー版がリリースされていましたが、今回の発表で一般提供開始になりました。

aws.amazon.com

アップデート概要

  • ユーザが作成したLambda関数内のコードをスキャンして、インジェクションの欠陥、データ漏洩、弱い暗号化、または暗号化の欠落などのコードセキュリティの脆弱性をスキャン
  • Lambdaのスキャンは、レイヤーを対象とした「標準スキャン」とコードを対象とした「コードスキャン」があり、今回のアップデートは後者のコードスキャン
  • スキャンタイミングは、Lambda関数のデプロイ時、Lambda関数の更新時、新しい脆弱性 ( CVE ) の公開時

詳細は以下のドキュメントに記載されています。

docs.aws.amazon.com

検証

事前準備

Inspectorの「アカウント管理」にて、「AWS Lambdaスキャン」の項目があります。
依然は「標準スキャン」だけでしたが、「コードスキャン」の記載が増えており、非アクティブ(無効化)になっていることが分かります。

「アクティブ化」から「AWS Lambda標準スキャン + AWS Lambdaコードスキャン」を押下します。

しばらくすると、「コードスキャン」もアクティブ(有効化)になりました。

Organizationを使っていれば、Inspector委任管理者アカウントから全アカウントまとめて有効化できます。 新しいメンバーアカウントを追加したときに、コードスキャンが有効化になるように、「AWS Lambdaコードスキャン」にチェックを入れて保存しておきましょう。

検知させてみる

脆弱なコードで含むLambda関数を作成します。
今回は、「Amazon CodeGuru, Detector Library」から以下の「Improper privilege management」を検知させてみます。

docs.aws.amazon.com

サンプルコード

import os

def lambda_handler(event, context):
    root = 0
    # Noncompliant: the process user is set to root.
    os.setuid(root)

しばらくすると、検知がありました。

詳細画面から、関連するCWE情報やコードの脆弱な部分がハイライトされています。

まとめ

Amazon Inspectorで簡単にLambda関数のコードスキャンができるようになりました。
コードのどこに脆弱性があるかも示してくれるため、非常に使い勝手が良いサービスです。
Inspectorの機能も増えてきているので、今後の動向に注目です。