© 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. アプリケーションエンジニアが学ぶ コンテナセキュリティ脅威の全体像 Ryota Yamada J A W S - U G コ ン テ ナ 支 部 Amazon Web Services Japan G.K.

© 2023, Amazon Web Services, Inc. or its affiliates. © 2023, Amazon Web Services, Inc. or its affiliates. アプリケーションエンジニアが学ぶ コンテナセキュリティ脅威の全体像 Ryota Yamada J A W S - U G コ ン テ ナ 支 部 Amazon Web Services Japan G.K.

© 2023, Amazon Web Services, Inc. or its affiliates. アジェンダ • 「NIST SP800-190 アプリケーションコンテナセキュリティガイド」でわかる脅威の全体像 • アプリケーションエンジニアがやっておくべき対策とベストプラクティス 3

© 2023, Amazon Web Services, Inc. or its affiliates. コンテナセキュリティの全体像 NIST Special Publication 800-190 リスクの分類 リスクの内容 イメージのリスク 3.1.1 イメージの脆弱性 3.1.2 イメージの設定の不備 3.1.3 埋め込まれたマルウェア 3.1.4 埋め込まれた平文の秘密情報 3.1.5 信頼できないイメージの使用 レジストリのリスク 3.2.1 レジストリへのセキュアでない接続 3.2.2 レジストリ内の古いイメージ 3.2.3 認証・認可の不十分な制限 オーケストレータのリスク 3.3.1 制限のない管理者アクセス 3.3.2 不正アクセス 3.3.3 コンテナ間ネットワークトラフィックの不十分な分離 3.3.4 ワークロードの機微性レベルの混合 3.3.5 オーケストレータノードの信頼 コンテナのリスク 3.4.1 ランタイムソフトウェア内の脆弱性 3.4.2 コンテナからの無制限のネットワークアクセス 3.4.3 セキュアでないコンテナランタイムの設定 3.4.4 アプリの脆弱性 3.4.5 未承認コンテナ ホストOSのリスク 3.5.1 大きなアタックサーフェス 3. 5.2 共有カーネル 3.5.3 ホスト OS コンポーネントの脆弱性 3.5.4 不適切なユーザアクセス権 3.5.5 ホスト OS ファイルシステムの改ざん https://www.ipa.go.jp/security/reports/oversea/ nist/ug65p90000019cp4-att/000085279.pdf 「3 コンテナ技術のコアコンポーネントの主なリスク」より引用

© 2023, Amazon Web Services, Inc. or its affiliates. コンテナセキュリティの全体像 NIST Special Publication 800-190 リスクの分類 リスクの内容 イメージのリスク 3.1.1 イメージの脆弱性 3.1.2 イメージの設定の不備 3.1.3 埋め込まれたマルウェア 3.1.4 埋め込まれた平文の秘密情報 3.1.5 信頼できないイメージの使用 レジストリのリスク 3.2.1 レジストリへのセキュアでない接続 3.2.2 レジストリ内の古いイメージ 3.2.3 認証・認可の不十分な制限 オーケストレータのリスク 3.3.1 制限のない管理者アクセス 3.3.2 不正アクセス 3.3.3 コンテナ間ネットワークトラフィックの不十分な分離 3.3.4 ワークロードの機微性レベルの混合 3.3.5 オーケストレータノードの信頼 コンテナのリスク 3.4.1 ランタイムソフトウェア内の脆弱性 3.4.2 コンテナからの無制限のネットワークアクセス 3.4.3 セキュアでないコンテナランタイムの設定 3.4.4 アプリの脆弱性 3.4.5 未承認コンテナ ホストOSのリスク 3.5.1 大きなアタックサーフェス 3. 5.2 共有カーネル 3.5.3 ホスト OS コンポーネントの脆弱性 3.5.4 不適切なユーザアクセス権 3.5.5 ホスト OS ファイルシステムの改ざん https://www.ipa.go.jp/security/reports/oversea/ nist/ug65p90000019cp4-att/000085279.pdf 「3 コンテナ技術のコアコンポーネントの主なリスク」より引用

© 2023, Amazon Web Services, Inc. or its affiliates. コンテナイメージにおける脅威 6 脅威 対策例 1.1 イメージの脆弱性 • ECR, Trivy を利用したコンテナイメージの脆弱性スキャン 1.2 イメージの設定の不備 • Dockle, Hadolint などのツールによって不備を検出 1.3 埋め込まれたマルウェア • ClamAVなどのツールによってマルウェアスキャン 1.4 埋め込まれた平文の秘密情報 • Dockle, git-secret といったツールによって秘密情報の検出 • AWS Secrets Manager や SSMパラメータストアを活用 1.5 信頼できないイメージの使用 • コンテナのデプロイの際には、イメージダイジェストを用いる • AWS Signerなどによってイメージに署名をする

© 2023, Amazon Web Services, Inc. or its affiliates. コンテナセキュリティの全体像 NIST Special Publication 800-190 リスクの分類 リスクの内容 イメージのリスク 3.1.1 イメージの脆弱性 3.1.2 イメージの設定の不備 3.1.3 埋め込まれたマルウェア 3.1.4 埋め込まれた平文の秘密情報 3.1.5 信頼できないイメージの使用 レジストリのリスク 3.2.1 レジストリへのセキュアでない接続 3.2.2 レジストリ内の古いイメージ 3.2.3 認証・認可の不十分な制限 オーケストレータのリスク 3.3.1 制限のない管理者アクセス 3.3.2 不正アクセス 3.3.3 コンテナ間ネットワークトラフィックの不十分な分離 3.3.4 ワークロードの機微性レベルの混合 3.3.5 オーケストレータノードの信頼 コンテナのリスク 3.4.1 ランタイムソフトウェア内の脆弱性 3.4.2 コンテナからの無制限のネットワークアクセス 3.4.3 セキュアでないコンテナランタイムの設定 3.4.4 アプリの脆弱性 3.4.5 未承認コンテナ ホストOSのリスク 3.5.1 大きなアタックサーフェス 3. 5.2 共有カーネル 3.5.3 ホスト OS コンポーネントの脆弱性 3.5.4 不適切なユーザアクセス権 3.5.5 ホスト OS ファイルシステムの改ざん https://www.ipa.go.jp/security/reports/oversea/ nist/ug65p90000019cp4-att/000085279.pdf 「3 コンテナ技術のコアコンポーネントの主なリスク」より引用

© 2023, Amazon Web Services, Inc. or its affiliates. コンテナレジストリにおける脅威 8 脅威 対策例 2.1 レジストリへのセキュアでない接続 • レジストリへのアクセスはTLS暗号化を実施 2.2 レジストリ内の古いイメージ • ECRのライフサイクルポリシーを設定し古いイメージを削除 2.3 不十分な認証・認可 • ECRではリソースベースポリシーによって権限を適切に管理 • VPC Endpointのセキュリティグループによってアクセス制御

© 2023, Amazon Web Services, Inc. or its affiliates. コンテナセキュリティの全体像 NIST Special Publication 800-190 リスクの分類 リスクの内容 イメージのリスク 3.1.1 イメージの脆弱性 3.1.2 イメージの設定の不備 3.1.3 埋め込まれたマルウェア 3.1.4 埋め込まれた平文の秘密情報 3.1.5 信頼できないイメージの使用 レジストリのリスク 3.2.1 レジストリへのセキュアでない接続 3.2.2 レジストリ内の古いイメージ 3.2.3 認証・認可の不十分な制限 オーケストレータのリスク 3.3.1 制限のない管理者アクセス 3.3.2 不正アクセス 3.3.3 コンテナ間ネットワークトラフィックの不十分な分離 3.3.4 ワークロードの機微性レベルの混合 3.3.5 オーケストレータノードの信頼 コンテナのリスク 3.4.1 ランタイムソフトウェア内の脆弱性 3.4.2 コンテナからの無制限のネットワークアクセス 3.4.3 セキュアでないコンテナランタイムの設定 3.4.4 アプリの脆弱性 3.4.5 未承認コンテナ ホストOSのリスク 3.5.1 大きなアタックサーフェス 3. 5.2 共有カーネル 3.5.3 ホスト OS コンポーネントの脆弱性 3.5.4 不適切なユーザアクセス権 3.5.5 ホスト OS ファイルシステムの改ざん https://www.ipa.go.jp/security/reports/oversea/ nist/ug65p90000019cp4-att/000085279.pdf 「3 コンテナ技術のコアコンポーネントの主なリスク」より引用

© 2023, Amazon Web Services, Inc. or its affiliates. コンテナオーケストレーターにおける脅威 10 脅威 対策例 3.1 制限のない管理者アクセス • IAMポリシーでECSに関する権限を最小権限で管理 • RBACでEKSに関する権限を最小権限で管理 3.2 不正アクセス • ECS/EKSといったマネージドサービスでIAMを利用する 3.3 コンテナ間ネットワークトラフィック の不十分な分離 • Security GroupやNetwork Policyで、最小限のトラフィッ クのみを許可 3.4 ワークロードの機微性レベルの混合 • コンテナ分離レベルを強化する(5.2参照) 3.5 オーケストレータノードの信頼 • Fargate を利用する • EC2インスタンスに付与するIAM Roleを最小権限に設定

© 2023, Amazon Web Services, Inc. or its affiliates. コンテナセキュリティの全体像 NIST Special Publication 800-190 リスクの分類 リスクの内容 イメージのリスク 3.1.1 イメージの脆弱性 3.1.2 イメージの設定の不備 3.1.3 埋め込まれたマルウェア 3.1.4 埋め込まれた平文の秘密情報 3.1.5 信頼できないイメージの使用 レジストリのリスク 3.2.1 レジストリへのセキュアでない接続 3.2.2 レジストリ内の古いイメージ 3.2.3 認証・認可の不十分な制限 オーケストレータのリスク 3.3.1 制限のない管理者アクセス 3.3.2 不正アクセス 3.3.3 コンテナ間ネットワークトラフィックの不十分な分離 3.3.4 ワークロードの機微性レベルの混合 3.3.5 オーケストレータノードの信頼 コンテナのリスク 3.4.1 ランタイムソフトウェア内の脆弱性 3.4.2 コンテナからの無制限のネットワークアクセス 3.4.3 セキュアでないコンテナランタイムの設定 3.4.4 アプリの脆弱性 3.4.5 未承認コンテナ ホストOSのリスク 3.5.1 大きなアタックサーフェス 3. 5.2 共有カーネル 3.5.3 ホスト OS コンポーネントの脆弱性 3.5.4 不適切なユーザアクセス権 3.5.5 ホスト OS ファイルシステムの改ざん https://www.ipa.go.jp/security/reports/oversea/ nist/ug65p90000019cp4-att/000085279.pdf 「3 コンテナ技術のコアコンポーネントの主なリスク」より引用

© 2023, Amazon Web Services, Inc. or its affiliates. コンテナにおける脅威 12 脅威 対策例 4.1 ランタイムソフトウェア内の脆弱性 • AWSによりサポートされているコンテナに最適化されたAMI または、Fargate を利用する 4.2 コンテナからの無制限の ネットワークアクセス • Security Groupまたは、Network Policyによってコンテナから のアウトバウンドトラフィックを最小限に設定 • NACL, Network Firewallによってアウトバウンドトラフィッ クを統制する 4.3 セキュアでない コンテナランタイムの設定 • コンテナの実行ユーザーをrootにしない • Read Only ファイルシステムを用いる • 特権コンテナと特権付与を避ける • 上記をAWS Config, Gatekeeper などを利用して確認する 4.4 アプリの脆弱性 • AWS WAF を利用する 4.5 未承認コンテナ • AWS Signerにより署名されたイメージのみを実行可能にする

© 2023, Amazon Web Services, Inc. or its affiliates. コンテナセキュリティの全体像 NIST Special Publication 800-190 リスクの分類 リスクの内容 イメージのリスク 3.1.1 イメージの脆弱性 3.1.2 イメージの設定の不備 3.1.3 埋め込まれたマルウェア 3.1.4 埋め込まれた平文の秘密情報 3.1.5 信頼できないイメージの使用 レジストリのリスク 3.2.1 レジストリへのセキュアでない接続 3.2.2 レジストリ内の古いイメージ 3.2.3 認証・認可の不十分な制限 オーケストレータのリスク 3.3.1 制限のない管理者アクセス 3.3.2 不正アクセス 3.3.3 コンテナ間ネットワークトラフィックの不十分な分離 3.3.4 ワークロードの機微性レベルの混合 3.3.5 オーケストレータノードの信頼 コンテナのリスク 3.4.1 ランタイムソフトウェア内の脆弱性 3.4.2 コンテナからの無制限のネットワークアクセス 3.4.3 セキュアでないコンテナランタイムの設定 3.4.4 アプリの脆弱性 3.4.5 未承認コンテナ ホストOSのリスク 3.5.1 大きなアタックサーフェス 3. 5.2 共有カーネル 3.5.3 ホスト OS コンポーネントの脆弱性 3.5.4 不適切なユーザアクセス権 3.5.5 ホスト OS ファイルシステムの改ざん https://www.ipa.go.jp/security/reports/oversea/ nist/ug65p90000019cp4-att/000085279.pdf 「3 コンテナ技術のコアコンポーネントの主なリスク」より引用

© 2023, Amazon Web Services, Inc. or its affiliates. ホストOSにおける脅威 脅威 対策例 5.1 大きなアタックサーフェイス • 定期的にAMIの更新を行う • Bottlerocket AMI を利用する 5.2 共有カーネル • seccomp, Bottlerocket によって、コンテナ分離レベルを強化 • 同一のインスタンスに別のコンテナをスケジュールしない 5.3 ホストOSコンポーネントの脆弱性 • 定期的なAMIの更新 5.4 不適切なユーザーアクセス権 • 特権コンテナと特権付与を避けるようタスク定義または、 Security Context を設定する • Falcoなどの振る舞いベースのマルウェア検知システムによっ て特権コマンドの実行などの異常な振る舞いを検知 5.5 ホストOSファイルシステムの改ざん • Falcoなどの振る舞い検知によって、機密性の高いホストディ レクトリ（例：/proc）へのマウントを検知する。 • AppArmorでホストディレクトリ内のファイルの実行を防ぐ ※ Fargate 起動タイプを利用する場合、お客様の対策不要

© 2023, Amazon Web Services, Inc. or its affiliates. コンテナセキュリティの全体像 NIST Special Publication 800-190 リスクの分類 リスクの内容 イメージのリスク 3.1.1 イメージの脆弱性 3.1.2 イメージの設定の不備 3.1.3 埋め込まれたマルウェア 3.1.4 埋め込まれた平文の秘密情報 3.1.5 信頼できないイメージの使用 レジストリのリスク 3.2.1 レジストリへのセキュアでない接続 3.2.2 レジストリ内の古いイメージ 3.2.3 認証・認可の不十分な制限 オーケストレータのリスク 3.3.1 制限のない管理者アクセス 3.3.2 不正アクセス 3.3.3 コンテナ間ネットワークトラフィックの不十分な分離 3.3.4 ワークロードの機微性レベルの混合 3.3.5 オーケストレータノードの信頼 コンテナのリスク 3.4.1 ランタイムソフトウェア内の脆弱性 3.4.2 コンテナからの無制限のネットワークアクセス 3.4.3 セキュアでないコンテナランタイムの設定 3.4.4 アプリの脆弱性 3.4.5 未承認コンテナ ホストOSのリスク 3.5.1 大きなアタックサーフェス 3. 5.2 共有カーネル 3.5.3 ホスト OS コンポーネントの脆弱性 3.5.4 不適切なユーザアクセス権 3.5.5 ホスト OS ファイルシステムの改ざん https://www.ipa.go.jp/security/reports/oversea/ nist/ug65p90000019cp4-att/000085279.pdf 「3 コンテナ技術のコアコンポーネントの主なリスク」より引用

© 2023, Amazon Web Services, Inc. or its affiliates. コンテナイメージにおける脅威 16 脅威 対策例 1.1 イメージの脆弱性 • ECR, Trivy を利用したコンテナイメージの脆弱性スキャン 1.2 イメージの設定の不備 • Dockle, Hadolint などのツールによって不備を検出 1.3 埋め込まれたマルウェア • ClamAVなどのツールによってマルウェアスキャン 1.4 埋め込まれた平文の秘密情報 • Dockle, git-secret といったツールによって秘密情報の検出 • AWS Secrets Manager や SSMパラメータストアを活用 1.5 信頼できないイメージの使用 • コンテナのデプロイの際には、イメージダイジェストを用いる • AWS Signerなどによってイメージに署名をする

© 2023, Amazon Web Services, Inc. or its affiliates. 1.1 コンテナイメージの脆弱性のスキャン 17 Basic Scanning Enhanced Scanning Scanning engine オープンソースの Clair プロジェクト Amazon Inspector (Snyk と連携、脆弱性 DB を拡張) Package coverage OS パッケージ OS パッケージ プログラミング言語パッケージ Scanning frequency on-push / マニュアル on-push / 継続的 AWS service integration Amazon EventBridge Amazon EventBridge AWS Security Hub AWS Organizations Cost 追加料金なし push : $0.11 per image re-scan : $0.01 per re-scan Amazon ECRには、コンテナイメージの脆弱性スキャンの機能がある。 Enhanced Scanning では、一般的なプログラミング言語のスキャンもサポートされている。

© 2023, Amazon Web Services, Inc. or its affiliates. 1.2 イメージ設定の不備の検出 18 https://docs.docker.jp/develop/develop-images/dockerfile_best-practices.html • ベースイメージには、信頼のできる軽量なイメージの使用 § Distroless, alpine などを検討 § マルチステージビルドによって、イメージを小さく保つ • USERを指定する • 実行時にパッケージをインストールしない § 脆弱性スキャンやマルウェアスキャンの意味がなくなるため • 秘匿情報をDockerfileに入れない • DockerfileのLinterを利用し、CIで確認する。 § hadolint § dockle

© 2023, Amazon Web Services, Inc. or its affiliates. 1.2 イメージ設定の不備の検出 – マルチステージビルド • マルチステージビルドとは、ステージを分けてビルドする機能です。 • 最後の段階のイメージのみが最終的な成果物となります。 FROM golang:1.12-alpine AS build #Install git RUN apk add --no-cache git #Get the hello world package from a GitHub repository RUN go get github.com/golang/example/hello WORKDIR /go/src/github.com/golang/example/hello # Build the project and send the output to /bin/HelloWorld RUN go build -o /bin/HelloWorld FROM golang:1.12-alpine #Copy the build's output binary from the previous build container COPY --from=build /bin/HelloWorld /bin/HelloWorld ENTRYPOINT ["/bin/HelloWorld"] 最終的な成果物 Source: https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/sample-docker.html

© 2023, Amazon Web Services, Inc. or its affiliates. 1.2 イメージ設定の不備の検出 – hadolint • hadolintを利用することで、ベストプラクティスに基づいた Dockerfileの作成をサポートすることが可能 • CLIからの利用とエディタからの利用が可能 • CIを利用してリリースフローに組み込むことで、 イメージ設定の不備を検出できるようになる。 • 指摘される項目については、wiki に詳しく記載されており修正が容易 § https://github.com/hadolint/hadolint/wiki https://docs.docker.jp/develop/develop-images/dockerfile_best-practices.html

© 2023, Amazon Web Services, Inc. or its affiliates. 1.3 埋め込まれたマルウェア – マルウェアスキャン シグネチャベース 振る舞いベース タイミング CIなどでのビルド時と署名時 稼働中 メリット 本番稼働前にスキャン可能 未知のマルウェアの検出が可能 後からコンテナにマルウェアを埋め込ま れても検出可能 デメリット 既知のマルウェアにしか対応できない システム負荷がかかる 代表的なサービス ClamAV YaraHunter Falco Sysdig Prisma Aqua TrendMicro 本番環境投入前にCIで検知できるシグネチャベースのマルウェアスキャンも併用を推奨。 一方で、振る舞いベースの方式では、未知のマルウェアやコンテナに埋め込まれたマルウェアにも対応可能 ReadOnlyコンテナであっても、インメモリなファイルレスマルウェアによって攻撃が可能 ファイルレスマルウェアによるRead-Only コンテナへの侵害 https://sysdig.jp/blog/containers-read-only-fileless-malware/

© 2023, Amazon Web Services, Inc. or its affiliates. 1.4 埋め込まれた平文の秘密情報 コンテナイメージ内にDBのパスワード、秘密鍵、APIキーなどの秘密情報を持たないようにする。 Secrets Revealed in Container Images:An Internet-wide Study on Occurrence and Impact では、 約8.5%のコンテナイメージに秘密情報が含まれていると報告されている。 Dockle を使用することにより、コンテナイメージに機密情報が混入していないか確認可能。 AWS では、Secrets Managerまたは SSMパラメータストア に秘密情報を入れる。 ECS { "containerDefinitions": [{ "secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:sec ret:secret_name-AbCdEf" }] }] } apiVersion: secrets-store.csi.x-k8s.io/v1alpha1 kind: SecretProviderClass metadata: name: nginx-deployment-aws-secrets spec: provider: aws parameters: objects: | - objectName: "MySecret" objectType: "secretsmanager" EKS https://github.com/aws/secrets-store-csi-driver-provider- aws/blob/1aace58f2a6e8a003e99d340cad36dd3b4e24a07/examples/ExampleSecretProviderClass.yaml#L1C1-L10C39 機密データの指定 - Amazon Elastic Container Service https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/specifying-sensitive-data.html

© 2023, Amazon Web Services, Inc. or its affiliates. 1.5 信頼できないイメージの使用 – イメージの署名を検証 • 署名によって、authenticity と provenance を得られる • 悪質なコンテナをクラスタ上で動かされる脅威に対する多層防御 § OCIレジストリの認証情報の流出によって、悪質なコンテナを公開される § DNSやネットワークの汚染によって、悪質なOCIレジストリを参照してしまう § クラスタの認証情報の流出によって悪質なコンテナを起動されてしまう • 適切な承認プロセスを得たコンテナのみを稼働させることが可能 § 社内の監査部門による厳密な検査を経たコンテナにのみ署名を付与 § 承認後にイメージを改ざんされていないことも確認できる https://aws.amazon.com/jp/blogs/news/cryptographic-signing-for-containers/

© 2023, Amazon Web Services, Inc. or its affiliates. 1.5 信頼できないイメージの使用 – イメージの署名を検証 https://aws.amazon.com/jp/blo gs/news/announcing-container- image-signing-with-aws-signer- and-amazon-eks/ Git repository Build Pipeline CI 脆弱性スキャン マルウェアスキャン Dockleによる検知 イメージへ署名 AWS Signer Sign Process 署名の検証 イメージの取得 Kyvernoまたは、Gatekeeperによって 実行するコンテナの署名を検証を強制 Admission Webhookにより実装されて いるPluginを提供 https://github.com/nirmata/kyverno-notation-aws https://ratify.dev/docs/1.0/quickstarts/ratify-with-aws-signer Container Registry

© 2023, Amazon Web Services, Inc. or its affiliates. 1.5 信頼できないイメージの使用 – イメージの署名を検証 Git repository Build Pipeline CI AWS Signer Sign Process Container Registry CD ECS自体には署名検証 の仕組みがないので デプロイ時に検証 脆弱性スキャン マルウェアスキャン Dockleによる検知 イメージへ署名

© 2023, Amazon Web Services, Inc. or its affiliates. 1.5 信頼できないイメージの使用 – 非決定的なデプロイ • イメージタグに latest などの汎用タグを参照している場合、 非決定的なイメージのデプロイメントを実施してしまう可能性がある • 具体的な事象 § イメージのスキャン後に特定のタグのコンテナイメージを変更される § 本番環境と開発環境で異なったコンテナイメージをPullしてしまう § ホストキャッシュなどの影響で、異なるコンテナイメージを起動してしまう § TOCTOU問題 – Admission Webhook と kubelet で参照するイメージが異なる • 解決策 § ECRの「タグのイミュータブル設定」を有効化する。(署名しない場合) § イメージタグではなく、イメージダイジェストを参照する。 また、AWS Config, Gatekeeperなどのツールによって強制する。

© 2023, Amazon Web Services, Inc. or its affiliates. コンテナイメージにおける脅威 27 脅威 対策例 1.1 イメージの脆弱性 • ECR, Trivy を利用したコンテナイメージの脆弱性スキャン 1.2 イメージの設定の不備 • Dockle, Hadolint などのツールによって不備を検出 1.3 埋め込まれたマルウェア • ClamAVなどのツールによってマルウェアスキャン 1.4 埋め込まれた平文の秘密情報 • Dockle, git-secret といったツールによって秘密情報の検出 • AWS Secrets Manager や SSMパラメータストアを活用 1.5 信頼できないイメージの使用 • コンテナのデプロイの際には、イメージダイジェストを用いる • AWS Signerなどによってイメージに署名をする

© 2023, Amazon Web Services, Inc. or its affiliates. Thank you! © 2023, Amazon Web Services, Inc. or its affiliates. Ryota Yamada [email protected]