この記事は『CRESCO Advent Calendar 2022』 11日目の記事です。

 

こんにちは。第２クロステックセンターの長田 修次と申します。

AWSを活用することでスケーラビリティあるコンテナアプリケーションを構築する案件が増えており、コンテナワークロードを活用したいお客様へコンテナワークロードのセキュリティについてご紹介する機会があったのでまとめました。

本記事ではAmazon ECS on Fargateを使用した環境のセキュリティ対策を中心にご紹介します。

１．使用するAWSのサービス

AWSサービスにおいてのコンテナ開発では以下のサービスを中心に使用します。

・Amazon Elastic Container Service (Amazon ECS)：マネージドコンテナオーケストレーションサービス。コンテナの実行環境を提供。

・Amazon Elastic Container Registry (Amazon ECR)：フルマネージド Docker コンテナレジストリ。コンテナイメージの管理する機能を提供。

・AWS Fargate：ホストOSの管理をAWSに任せることができるサーバレスサービス。

２．責任共有モデル

ECSではコンテナを制御するコントロールプレーンとそのインフラストラクチャを中心にAWSが管理します。ECSの実行環境はEC2起動タイプとFargateタイプが選択でき、Fargateを利用するとコンテナの実行環境において、ホストOSに対するセキュリティ管理をAWSへ任せることが出来ます。

AWS公式のAmazonECSベストプラクティスガイドは次のリンクを参照　AWS の責任共有モデル

３．コンテナワークロードにおけるセキュリティガイドライン

新規事業でコンテナを導入するお客様も多いことから社内基準がない現場もあるかと思います。以下のガイドを参考にするのが一般的です。

米国国立標準技術研究所（NIST)によって作成された「NIST SP800-190 アプリケーションコンテナセキュリティガイド」があります。IPAから翻訳されたガイドが公開されています。

[アプリケーションコンテナセキュリティガイド(IPA日本語翻訳版)]
https://www.ipa.go.jp/security/publications/nist/index.html

インターネット・セキュリティの標準化に取り組む CIS（Center for Internet Security）がDockerのセキュリティベストプラクティスガイドラインである「CIS Docker Benchmarks」を公開しています。資料請求をする必要ありますが、後ほど紹介するツールでもセキュリティチェックが出来ます。

[CIS Docker Benchmarks]
https://www.cisecurity.org/benchmark/docker

AWSからも「Amazon Elastic Container Serviceのベストプラクティスガイド」が公開されており、セキュリティ設計の考慮事項が記載されているので一読しておくことをお勧めします。

[Amazon Elastic Container Serviceのベストプラクティスガイド – セキュリティ]
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/bestpracticesguide/security.html

４．ECS on Fargate環境のセキュリティリスクについて

以下にNIST SP800-190で記載しているセキュリティリスクから主要な観点を選定しました。
それぞれの対策を説明します。

リスク項目（NIST SP800-190） Fargate環境の責任範囲
大項目 小項目 Customer AWS
イメージ イメージの脆弱性 ① 　
　 イメージの設定の不備 ② 　
　 埋め込まれたマルウェア ③ 　
　 埋め込まれた平文の秘密情報 ④ 　
　 信頼できないイメージの使用 ⑤ 　
レジストリ レジストリへのセキュアでない接続 　 ✓
　 レジストリ内の古いイメージ ⑥ 　
　 認証・認可の不十分な制限 ⑦ 　
オーケストレータ 制限のない管理者アクセス ⑦ 　
  不正アクセス ⑦ 　
  コンテナ間ネットワークトラフィックの不十分な分離 ⑧ 　
  ワークロードの機微性レベルの混合 ⑨ 　
  オーケストレータノードの信頼 　 ✓
コンテナ ランタイムソフトウェア内の脆弱性 　 ✓
　 コンテナからの無制限のネットワークアクセス ⑧ 　
　 セキュアでないコンテナランタイムの設定 　 ✓
　 アプリの脆弱性 ⑩ 　
　 未承認コンテナ ⑪ 　
ホスト OS  大きなアタックサーフェス   ✓
  共有カーネル   ✓
  ホスト OS コンポーネントの脆弱性   ✓
  不適切なユーザアクセス権   ✓
  ホスト OS ファイルシステムの改ざん 　 ✓

①イメージの脆弱性

Amazon ECRのイメージスキャン機能を活用して定期的にコンテナイメージの脆弱性スキャンを行うことが出来ます。

[Amazon ECR イメージスキャン]
https://docs.aws.amazon.com/ja_jp/AmazonECR/latest/userguide/image-scanning.html

無償のベーシックスキャンではOSSのClair脆弱性データベースを使用した手動およびイメージPushのスキャン、有償の拡張スキャンではAmazon Inspectorダッシュボードに統合されたSnyk脆弱性データベースを使用したスキャンが行えます。

CI/CDなどでコマンドライン制御したい要件がある場合は、代表的なツールとしてAqua Security社がスキャン可能なOSSツールTrivyを公開しており活用出来ます。

[Trivy (Aqua Security)]
https://github.com/aquasecurity/trivy

それぞれコストと活用用途により、実装手段をご検討いただければと思います。

②イメージの設定の不備

開発者はDockerfileのべスト・プラクティスに従ってコンテナイメージの設計・作成を行います。

[Dockerfile のベストプラクティス]
https://docs.docker.jp/develop/develop-images/dockerfile_best-practices.html

AWSの公式ではありませんが検証するOSSツールが公開されており、Dockleが対応範囲広く活用出来ます。コンテナのセキュリティの一部のベストプラクティスやCIS Docker Benchmarksを検証してイメージの設定不備を抽出することが出来ます。

[Dockle]
https://github.com/goodwithtech/dockle

③埋め込まれたマルウェア

マルウェア検知が要件にある場合は現在のAWSの機能だけでは不十分であるため、商用のコンテナセキュリティ製品の採用をご検討することをお勧めします。ベストプラクティスガイドのAWSパートナーにおいては、Aqua Security社、Palo Alto Networks社、Sysdig社の３製品が紹介されています。

[AWSパートナー]
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/bestpracticesguide/security-partners.html

④埋め込まれた平文の秘密情報

AWS Secrets ManagerまたはAmazon EC2 Systems Manager Parameter Storeを使用して秘密情報をパラメータ化して暗号化します。

[シークレット管理]
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/bestpracticesguide/security-secrets-management.html

⑤信頼できないイメージの使用

Amazon ECRを使用して検証済みのコンテナイメージを管理します。開発者が提供元の不明なイメージを使用しないように開発ガイドラインなどで周知します。例えばDockerHubであれば「Docker Official Images」タグが付与されているものになります。

[Docker公式イメージ]
https://hub.docker.com/search?q=&image_filter=official

⑥レジストリ内の古いイメージ

Amazon ECR のライフサイクルポリシー機能を活用し、不要な古いコンテナイメージが残らないよう対策することが出来ます。

[Amazon ECR ライフサイクルポリシー]
https://docs.aws.amazon.com/ja_jp/AmazonECR/latest/userguide/LifecyclePolicies.html

⑦認証・認可の不十分な制限／制限のない管理者アクセス／不正アクセス

セキュリティベストプラクティスを参考にIAMの適切な設定を行います。

[Amazon ECS AWS Identity and Access Management]
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/bestpracticesguide/security-iam.html

[Amazon ECS タスクでの IAM ロールの使用]
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/bestpracticesguide/security-iam-roles.html

不正アクセスがあった場合の検知、ログ記録、調査のため、Cloudwatchの設定およびGuardDuty、CloudTrail、Amazon Detectiveを有効化します。

⑧コンテナ間ネットワークトラフィックの不十分な分離／コンテナからの無制限のネットワークアクセス

セキュリティベストプラクティスを参考にACLやセキュリティグループ、AWS PrivateLinkを活用して適切なネットワーク設定を行います。

[ネットワークセキュリティ]
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/bestpracticesguide/security-network.html

AWS Security Hubを有効化することで一部の設定において、ベストプラクティスを確認したり自動修復することが出来ます。

[AWS Foundational Security Best Practices コントロール]
https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html

⑨ワークロードの機微性レベルの混合

ECSのタスクやサービスの設計において、機能や役割をアプリケーション単位で機微情報のレベルによって分離することで混合を防ぐことができます。

⑩アプリの脆弱性

Fargate環境であってもアプリケーションの脆弱性は対処できないため、AWS WAF（ウェブアプリケーションファイアウォール）の使用やセキュアコーディングに配慮することが必要です。ウェブアプリケーションでない場合は必要に応じてコンテナワークロードに対応したアプリケーションファイアーウォール製品をご検討ください。

⑪未承認コンテナのリスク

コンテナイメージにタグを付与し変更禁止に設定することで、攻撃者が変更または更新したバージョンのコンテナイメージに対し、同じタグを使用してイメージリポジトリにプッシュされるのを防ぐことが出来ます。

[イメージタグの変更可能性]
https://docs.aws.amazon.com/ja_jp/AmazonECR/latest/userguide/image-tag-mutability.html

５．さいごに

記載したOSSのツールを上手く活用したり商用のセキュリティツールを導入すれば、ほとんどのセキュリティベストプラクティスはキャッチアップすることができます。

AWSのコンテナワークロードにおける機能は日々進歩しており常にアップデートされます。
GitHubにてロードマップが公開されているのでそちらも合わせてご確認いただければと思います。

[aws/containers-roadmap]
https://github.com/aws/containers-roadmap/projects/1

クラウド関連のセキュリティ技術についても、今後何かアップデートがありましたらご紹介していきたいと思いますので、宜しくお願い致します。